How to Audit and Inspect UDP Endpoints in Windows 11 Using PowerShell

In enterprise Windows systems administration, network security audits, and application troubleshooting, inspecting active UDP communication endpoints is critical for maintaining infrastructure integrity. Unlike connection-oriented TCP, the User Datagram Protocol (UDP) is stateless: it establishes no persistent handshake sessions, maintains no sequence numbers, and operates without continuous connection states. As a result, standard TCP socket inspection tools cannot report UDP activity effectively.

Critical network services rely exclusively on UDP—including DNS name resolution (port 53), DHCP client negotiation (ports 67/68), Network Time Protocol synchronization (NTP port 123), Simple Network Management Protocol (SNMP port 161), and modern QUIC/HTTP3 web traffic. Furthermore, rogue applications, command-and-control beacons, and peer-to-peer malware frequently use stateless UDP listening ports to evade casual observation. Windows 11 includes the Get-NetUDPEndpoint PowerShell cmdlet within the native NetTCPIP module. This tool queries the kernel network stack directly to expose active UDP sockets, bound interfaces, and owning Process IDs (PIDs). This guide shows how to audit and inspect UDP endpoints in Windows 11 using PowerShell.

Querying Active UDP Endpoints

The Get-NetUDPEndpoint cmdlet audits open UDP listening ports and bound socket interfaces across the local operating system.

Listing All Open UDP Sockets

1. Right-click the Start button on Windows 11 and choose Terminal (Admin) or PowerShell (Admin).
2. Execute the basic query:

Get-NetUDPEndpoint

Windows outputs a formatted summary table of all active UDP endpoints:

LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      53        1840
0.0.0.0      68        2045
0.0.0.0      123       1120
0.0.0.0      5353      3112
0.0.0.0      5355      1428
192.168.1.50 137       4
192.168.1.50 138       4

Interpreting Core UDP Properties

• LocalAddress: The network IP interface bound to the socket. A value of 0.0.0.0 (IPv4) or :: (IPv6) indicates the socket is listening across all network adapters simultaneously.
• LocalPort: The UDP port number opened by the application or system daemon.
• OwningProcess: The Process ID (PID) of the application hosting the UDP listener.

Filtering by Port Number and Address Family

To inspect specific network services or audit vulnerable protocols, filter query results using cmdlet parameters:

Auditing Common DNS, DHCP, and Discovery Endpoints

To check if local multicast discovery listeners like mDNS (port 5353) or LLMNR (port 5355) are active:

Get-NetUDPEndpoint -LocalPort 5353, 5355 | Format-Table LocalAddress, LocalPort, OwningProcess

Filtering by IPv4 vs IPv6

To restrict queries strictly to IPv4 or IPv6 endpoints:

Get-NetUDPEndpoint -AddressFamily IPv4 | Sort-Object LocalPort

Correlating Endpoints with Process Names and Executable Paths

A numeric OwningProcess PID is of limited diagnostic use without identifying the underlying software binary. Correlate Get-NetUDPEndpoint with Get-Process to resolve friendly executable names and disk paths:

Get-NetUDPEndpoint | Select-Object LocalAddress, LocalPort, OwningProcess, @{Name="ProcessName"; Expression={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}}, @{Name="Path"; Expression={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).Path}} | Sort-Object LocalPort | Format-Table -AutoSize

This command outputs the exact process name (e.g. svchost, spotify, or chrome) and its physical storage path (e.g. C:\Windows\System32\...) for every open UDP listener.

Auditing External vs Loopback Listening Endpoints

From a security perspective, endpoints bound strictly to loopback addresses (127.0.0.1 or ::1) are accessible only from within the local computer. Sockets bound to physical IP addresses or 0.0.0.0 are exposed across the local network subnet.

Isolating Externally Exposed UDP Sockets

Filter out internal loopback endpoints to audit your system’s network attack surface:

Get-NetUDPEndpoint | Where-Object { $_.LocalAddress -ne "127.0.0.1" -and $_.LocalAddress -ne "::1" } | Select-Object LocalAddress, LocalPort, OwningProcess, @{Name="Process"; Expression={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} | Format-Table -AutoSize

This allows administrators to verify that internal services are not inadvertently exposing listening ports to untrusted network subnets.

Monitoring Live Endpoint Registrations Dynamically

To track UDP endpoints opened dynamically by games, VoIP software, or VPN tunnels, run an automated sampling loop that monitors the socket table every 2 seconds:

while ($true) {
    Clear-Host
    Write-Host "Active UDP Endpoints at $(Get-Date -Format 'HH:mm:ss'):" -ForegroundColor Cyan
    Get-NetUDPEndpoint | Where-Object { $_.LocalAddress -ne "127.0.0.1" } | Select-Object LocalAddress, LocalPort, @{Name="Process"; Expression={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} | Sort-Object LocalPort | Format-Table -AutoSize
    Start-Sleep -Seconds 2
}

Press Ctrl+C to exit the monitoring loop.

Administrative Security and Operational Guidelines

• Elevated Administrator Privileges: While standard users can query basic network properties, resolving system service PIDs (such as PID 4 System or Core Windows Services) requires launching PowerShell as an Administrator.
• Non-Disruptive Inspection: The Get-NetUDPEndpoint cmdlet performs read-only inspection of kernel memory and will not drop, delay, or interfere with active UDP datagram transmission.
• Firewall Rule Auditing: If an endpoint is listed in Get-NetUDPEndpoint, verify corresponding inbound firewall rules with Get-NetFirewallRule to confirm whether external network packets can reach the listening port.