How to Audit Active UDP Listening Ports and Sockets in Windows 11 Using PowerShell

Auditing active network sockets is an essential task for systems administrators, network engineers, and security analysts troubleshooting service availability or investigating potential security anomalies. While TCP connections maintain persistent connection states such as ESTABLISHED, SYN_SENT, or TIME_WAIT, the User Datagram Protocol (UDP) is connectionless. UDP sockets do not form handshakes or track session lifecycles; they simply bind to local IP addresses and ports to listen for incoming datagrams.

Historically, administrators relied on legacy command-line tools like netstat -ano to audit network endpoints. In modern Windows 11 and Windows Server environments, PowerShell offers the native Get-NetUDPEndpoint cmdlet from the NetTCPIP module. This cmdlet provides structured, object-oriented telemetry, allowing administrators to filter by local port, identify responsible process IDs (PIDs), correlate process executables, and isolate untrusted network listeners with precision.

Understanding Get-NetUDPEndpoint Architecture

The Get-NetUDPEndpoint cmdlet queries the Windows TCP/IP networking stack directly via Windows Management Instrumentation (WMI) and Common Information Model (CIM) interfaces. When executed, it returns an array of MSFT_NetUDPEndpoint objects containing critical metadata attributes:

• LocalAddress: The local IP address bound to the socket. Values of 0.0.0.0 (IPv4) or :: (IPv6) indicate that the service listens across all available network interfaces.
• LocalPort: The UDP port number opened by the application or operating system service.
• OwningProcess: The numeric Process Identifier (PID) of the Windows service or process that initiated the socket binding.
• CreationTime: The exact timestamp when the UDP socket was created by the operating system.

Querying All Active UDP Endpoints

To inspect all active UDP listening sockets currently registered in Windows 11, launch PowerShell as an Administrator and execute:

Get-NetUDPEndpoint

To produce a cleaner, structured summary table focused on essential networking details, pipe the results to Select-Object and sort by local port:

Get-NetUDPEndpoint | Select-Object LocalAddress, LocalPort, OwningProcess, CreationTime | Sort-Object LocalPort

Filtering UDP Sockets by Specific Port Numbers

When verifying whether standard network services—such as DNS (port 53), DHCP (port 67/68), NTP (port 123), or SNMP (port 161)—are actively bound, query the port directly using the -LocalPort parameter:

Get-NetUDPEndpoint -LocalPort 53

To check multiple ports simultaneously, pass an array of integers:

Get-NetUDPEndpoint -LocalPort 53, 67, 123, 161, 500, 4500

If an unknown process is occupying a high-numbered ephemeral port, query that specific port to extract its process ID:

Get-NetUDPEndpoint -LocalPort 50505 | Format-List *

Filtering Sockets by IP Address Version and Binding Interface

By default, Get-NetUDPEndpoint returns both IPv4 and IPv6 sockets. To restrict the audit strictly to IPv4 or IPv6 listening endpoints, leverage the -AddressFamily parameter:

Get-NetUDPEndpoint -AddressFamily IPv4

To isolate listening sockets that expose the host to the external local area network—rather than internal loopback bindings (127.0.0.1)—filter using Where-Object:

Get-NetUDPEndpoint -AddressFamily IPv4 | Where-Object { $_.LocalAddress -ne '127.0.0.1' } | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort

Resolving Process Names from OwningProcess IDs

Knowing the numeric OwningProcess PID is helpful, but identifying the actual application name, executable path, and service account provides actionable insight. In PowerShell, you can join the output of Get-NetUDPEndpoint with Get-Process dynamically:

Get-NetUDPEndpoint -AddressFamily IPv4 | ForEach-Object {
    $proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        LocalAddress = $_.LocalAddress
        LocalPort    = $_.LocalPort
        PID          = $_.OwningProcess
        ProcessName  = if ($proc) { $proc.ProcessName } else { "System / Terminated" }
        Path         = if ($proc) { $proc.Path } else { "N/A" }
    }
} | Sort-Object LocalPort | Format-Table -AutoSize

This script outputs a clean table displaying the port, PID, process name, and filesystem path for every active UDP socket, making it simple to differentiate trusted system binaries (such as svchost.exe or lsass.exe) from third-party tools.

Auditing Windows Services Bound to UDP Ports

Many system-level UDP endpoints are hosted within generic svchost.exe shared service instances. To identify the specific Windows Service running inside the host process, correlate the PID against Get-CimInstance Win32_Service:

$TargetPort = 123
$endpoint = Get-NetUDPEndpoint -LocalPort $TargetPort -ErrorAction SilentlyContinue

if ($endpoint) {
    Get-CimInstance Win32_Service | Where-Object { $_.ProcessId -eq $endpoint.OwningProcess } | 
    Select-Object Name, DisplayName, State, StartMode, PathName | Format-List
} else {
    Write-Output "No active UDP endpoint found on port $TargetPort"
}

Exporting UDP Audit Logs for Security Audits

For infrastructure compliance documentation or baseline change tracking, export the active UDP socket state to a CSV file:

Get-NetUDPEndpoint | Select-Object LocalAddress, LocalPort, OwningProcess, CreationTime |
    Export-Csv -Path "$HOME\Documents\UDP_Socket_Audit.csv" -NoTypeInformation -Encoding utf8

Auditing UDP endpoints using native PowerShell cmdlets ensures thorough visibility into connectionless network services across Windows 11 endpoints without relying on deprecated utilities.