Windows Network Auditing: Finding the Process, Service, Port and IP Behind the Firewall Rule

Windows firewall troubleshooting is rarely as simple as allowing one executable and one port. An application may appear to use TCP 443, but the actual connection can be created by a Windows service, a child process, System, or one of the services running inside svchost.exe.

The Network Process tools help expose that relationship by capturing Windows network endpoints and correlating them with processes, executable paths, command lines, services, ports and IP addresses.

There are 2 versions - https://github.com/Tenaka/Windows-Network-Analysis-Tool/tree/main

• Network Process – Lite v2

• Network Process – InDepth v2

Both produce the same core CSV reports, making it easy to start with Lite and move to InDepth when more evidence is required.

What the tools capture

The scripts repeatedly query the Windows TCP and UDP endpoint tables during a configurable capture period.

They record:

• TCP connections and listeners

• UDP endpoints

• Local and remote IP addresses

• Local and remote ports

• TCP connection states

• Process IDs and process names

• Executable paths and command lines

• Parent processes

• Windows services hosted by each process

• First and last observation times

• The number of times each endpoint was seen

They also inventory running processes, Windows services and configured network interface addresses.

This provides a useful link between the network connection and the Windows component responsible for creating it.

Lite or InDepth?

The Lite version is designed for quick audits and routine fault finding.

By default, it runs for 30 seconds and samples network endpoints every 500 milliseconds. It collects the core connection, process, service, IP address and port data without performing signature checks, DNS lookups or raw event logging.

Lite is suitable when the problem is easy to reproduce and the objective is simply to identify the applications, services, ports and destinations involved.

The InDepth version runs for 60 seconds by default and samples every 250 milliseconds. It also enables:

• Reverse DNS lookups

• Process owner collection

• Executable file metadata

• Authenticode signature checks

• Raw endpoint samples

• Connection event tracking

The faster sampling gives InDepth a better chance of detecting short-lived connections during authentication, certificate validation, service discovery or application startup.

SHA-256 file hashing is available but disabled by default because it increases disk access and processing overhead.

Running the tools

Run the scripts from an elevated Windows PowerShell session.

& ".\network process - lite v2.ps1"

For a longer capture:

& ".\network process - lite v2.ps1" `
    -DurationSeconds 120 `
    -OutputFolder "C:\Logs\NetworkAudit"

For a more detailed investigation:

& ".\network process - indepth v2.ps1" `
    -DurationSeconds 300 `
    -OutputFolder "C:\Logs\NetworkAudit"

Start the capture immediately before reproducing the fault. Launch the application, perform the login or connection attempt and continue until the failure occurs.

Starting the script after the problem has happened may miss the connections that caused it.

Understanding the reports

The main report is Connections.csv.

It shows the network endpoint together with the process, executable, service, local address, local port, remote address and remote port.

Ports.csv presents the same evidence from a port-focused view, while IPAddresses.csv lists interface addresses and all IP addresses observed during the capture.

Processes.csv shows the processes present during the audit and summarises their network activity.

Services.csv links Windows services to the process IDs, ports and addresses they used.

The InDepth version also produces Raw.csv and Events.csv. These show individual samples and connection changes such as when an endpoint first appeared, changed state or disappeared.

Firewall troubleshooting

The main purpose of the tools is to show what Windows is actually using rather than relying on the visible application name.

For example, a VPN client may display its own executable, but parts of the authentication process may be performed by:

svchost.exe
System
a background service
a web authentication component
a child process

Allowing only the visible VPN executable through the firewall may therefore allow the connection to start but fail when the application reaches MFA, certificate validation or another Windows-hosted dependency.

The reports can help answer:

• Which executable opened the connection?

• Which service was running inside svchost.exe?

• Which remote address and port were used?

• Did the connection appear only during login?

• Was the destination public, private, loopback or IPv6?

• Was the executable digitally signed?

This evidence can be used to create a more targeted firewall rule instead of broadly allowing all traffic from svchost.exe.

Interpreting ports correctly

For a normal outbound HTTPS connection, the local port will usually be a temporary high-numbered port and the remote port will be TCP 443.

The temporary local port should not normally be added to the firewall rule. It is automatically selected by Windows and changes between connections.

A TCP listener is different. The local port is the port on which the computer is waiting for inbound connections.

The reports label TCP entries as Connected or Listener, but they do not claim that every connected session is specifically inbound or outbound. Direction must be inferred from the local and remote ports, the application role and the firewall context.

Working with svchost.exe

A single svchost.exe process can host one Windows service or several services.

The tools list all services associated with the process ID. When the svchost.exe command line identifies a specific service, the script can attribute the traffic to it.

When several services share the same process and there is no clear service identifier, the report records the process as shared rather than guessing.

This is intentional. A shared service process narrows the investigation, but it does not always prove which individual service created the connection.

What the tools cannot prove

These scripts are endpoint auditing tools. They are not packet analysers and they do not read firewall decisions.

They cannot prove that:

• A firewall allowed or blocked a packet

• A remote server received the connection

• A TLS handshake completed

• Authentication succeeded

• A certificate was accepted

• Data was returned by the remote service

• Packet loss or routing failure occurred

A connection stuck in SYN-SENT may indicate that Windows attempted to connect but received no reply. The cause could be a firewall, routing issue, unavailable server or incorrect destination.

The results should therefore be compared with firewall logs, application logs, VPN gateway logs or packet capture when deeper evidence is required.

Known limitations

Both scripts use polling. A connection that opens and closes entirely between two samples may be missed.

The InDepth version reduces this risk by sampling more frequently, but it cannot guarantee capture of every connection.

UDP reporting is also limited. Windows exposes the local UDP endpoint, but the standard endpoint table does not provide the remote UDP peer. The scripts can show which process owns the local UDP port, but not where the UDP traffic was sent.

Reverse DNS results should also be treated carefully. A returned name may belong to a CDN, proxy, cloud provider or load balancer and may not be the hostname originally requested by the application.

Applications using proxies, secure web gateways or VPN tunnels may show only the gateway or proxy address rather than the final destination.

Choosing the right tool

Use Lite for quick checks, repeatable faults and initial firewall baselines.

Use InDepth when:

• The fault is intermittent

• Authentication fails partway through

• svchost.exe is involved

• Connections are very short-lived

• Process ownership or signature information is required

• A detailed event timeline is needed

These tools do not replace Wireshark or firewall logging. They provide the Windows process and service context that those tools often lack.

That context is frequently the missing piece when an application has already been allowed through the firewall but still fails to work.

Instead of asking only:

Which port does this application need?

the better questions become:

Which process opened the connection?

Was it the application, a child process, a service or svchost.exe?

Which local and remote addresses were used?

Was the port a listener, a destination port or an ephemeral source port?

Did the dependency exist for the whole session or only during authentication?

Answering those questions makes it possible to create firewall rules that are narrow enough to remain secure and complete enough to let the application work.