Forensics · Lesson 12
Network Connections & Listening Services
Learn how to map listening ports and active connections to processes, services, users, executable paths, and firewall context on Windows and Linux.
Network evidence becomes useful when you connect the socket to the process, the process to the service or user, and the service to the scenario requirement.
Lesson Snapshot
Learning objectives
Connect network state to process and service evidence
Explain the difference between listening sockets, established connections, and remote endpoints.
Map network activity to the process and account responsible for it.
Recognize common Windows and Linux tools for reviewing local ports and connections without changing system state.
Distinguish expected services from unexpected exposure using scenario context, service configuration, and process evidence.
Correlate network connections with processes, services, logs, scheduled activity, and executable paths.
Preserve network-state evidence before stopping services, killing processes, or changing firewall rules.
Core idea
Map socket → PID → process → service → scenario
The strongest network conclusion comes from connecting the local endpoint to the owning process, executable, account, service, and expected system role.
Competition caution
Preserve the listener before you block it
Record addresses, ports, PID, executable, service, account, logs, and firewall context before stopping services or changing rules.
Network principles
Interpret sockets without overclaiming
A port is only one clue
A port number does not prove which application is using it or whether the activity is legitimate. Map the socket to a process, executable, account, and service.
Listening is different from connected
A listening socket waits for incoming traffic. An established connection shows active communication with a remote endpoint.
Local and remote addresses matter
The local bind address shows where a service is exposed. The remote address identifies the peer for established connections.
Process ownership matters
Network activity becomes more meaningful when you know the PID, executable path, command line, user, and parent process.
Expected services can still be misconfigured
A required service may still be listening on an unnecessary interface or port.
Preserve before hardening
Stopping a service or changing a firewall rule can erase the current state that explains what was listening or connected.
Connection states
Know what the socket state actually means
LISTEN / Listening
A local process is waiting for inbound connection attempts.
Forensic value
Useful for identifying exposed services and mapping ports to processes.
ESTABLISHED
A connection is currently active between the local system and a remote endpoint.
Forensic value
Useful for connecting process activity to remote systems.
TIME_WAIT
The local stack is temporarily retaining a recently closed TCP connection.
Forensic value
Can show recent communication but not an active session.
CLOSE_WAIT
The remote side closed the connection, but the local application has not fully closed it yet.
Forensic value
May help explain application or service behavior.
SYN_SENT / SYN_RECV
A TCP connection is being established.
Forensic value
Shows connection setup activity but not a fully established session.
Address meaning
Bind address changes exposure context
127.0.0.1 / ::1Loopback only. The service is reachable from the local machine but not directly from other hosts.
0.0.0.0IPv4 wildcard bind. The service may listen on all available IPv4 interfaces.
::IPv6 wildcard bind. Depending on platform and configuration, this can expose the service broadly.
Specific local IPThe service is bound only to a selected interface/address.
Remote IPFor an established connection, identifies the remote peer.
Remote portShows the service port used on the remote side of the connection.
Windows
Inspect sockets and owning processes
List TCP connections
Get-NetTCPConnection
Shows local/remote addresses, ports, connection states, and owning process IDs.
Show listeners only
Get-NetTCPConnection -State Listen
Filters to listening TCP sockets.
Compact network view
Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess
Displays the most useful network-state fields.
Map PID to process
Get-Process -Id 4312
Maps an owning process ID to a process name.
Process path and command line
Get-CimInstance Win32_Process -Filter "ProcessId=4312" | Select-Object ProcessId,ParentProcessId,ExecutablePath,CommandLine
Adds executable path, parent process, and command-line context.
Classic view
netstat -ano
Shows TCP/UDP endpoints, states, and PIDs using a widely available Windows command.
Linux
Inspect sockets and owning processes
Listening sockets with processes
sudo ss -lntup
Shows listening TCP/UDP sockets and process information where permissions allow.
Active TCP connections
sudo ss -ntup
Shows active TCP connections and associated processes.
All sockets
sudo ss -auntp
Shows listening and connected TCP/UDP sockets with process context.
Process command
ps -fp 4312
Shows process owner and command for one PID.
Executable path
readlink -f /proc/4312/exe
Resolves the executable used by a running process.
Service relationship
systemctl status example.service
Shows whether a process belongs to a systemd service.
Process mapping
Move from socket to executable and service
Record the socket
Write down protocol, local address, local port, remote address, remote port, state, and PID.
Resolve the PID
Identify process name, executable path, command line, parent PID, and user.
Check service context
Determine whether the process belongs to a Windows service, systemd unit, scheduled task, or user session.
Validate the executable
Record path, hash, ownership, permissions, and installation/package context.
Check logs
Look for service starts, process launches, authentication, firewall, or application events around the same time.
Compare with scenario requirements
Determine whether the service or connection is expected and necessary.
Common ports
Use port numbers as hints, not conclusions
Common for secure remote shell access, especially on Linux.
Common for name-resolution services.
Common for web services.
Common for encrypted web services.
Common for Windows Remote Desktop.
Common for Windows file and printer sharing.
Port cautions
Why memorized ports are not enough
Ports are conventions
Applications can use nonstandard ports, and different applications can reuse the same port number on different hosts.
A known port does not prove the service
Always map the socket to the process and service configuration.
An unfamiliar port is not automatically suspicious
Custom applications, development tools, monitoring agents, and vendor software often use high-numbered ports.
UDP differs from TCP
UDP has no connection state like ESTABLISHED, so interpretation relies more on process, service, and application context.
Windows service links
Connect listeners to service configuration
PID belongs to a process launched by services.exe
The process may belong to a Windows service.
Next: Check Get-CimInstance Win32_Service for matching ProcessId or executable path.
Service PathName matches the executable path
The service configuration and process point to the same binary.
Next: Record service name, start mode, account, state, and relevant System events.
Event 7045 exists shortly before first listener
A newly installed service may explain the new network exposure.
Next: Correlate install time, binary metadata, process start, and scenario requirements.
Linux service links
Connect sockets to systemd and scheduling
PID appears as MainPID for a systemd service
The process is directly managed by that unit.
Next: Inspect systemctl status, systemctl cat, and the service journal.
Executable path matches ExecStart
The unit definition and running process refer to the same program.
Next: Check unit ownership, package source, user, enablement, and logs.
Timer or cron launches the same executable
Scheduled activity may explain periodic network connections.
Next: Correlate trigger times with process and socket timestamps.
Reasoning
Say only what the network evidence supports
0.0.0.0:8080 is listening
Supported
A process is listening on TCP port 8080 across available IPv4 interfaces.
Not supported
The service is malicious or internet-accessible from everywhere.
127.0.0.1:5000 is listening
Supported
The service is bound to local loopback on port 5000.
Not supported
Remote hosts can directly reach it.
PID 4312 owns port 3389
Supported
Process 4312 currently owns that socket.
Not supported
The process is definitely the Windows RDP service without further mapping.
Process has an established connection to 203.0.113.50:443
Supported
The process is currently communicating with that remote endpoint over TCP port 443.
Not supported
The remote service is trustworthy or malicious based on the port alone.
UDP socket is bound to port 53
Supported
A local process has bound UDP port 53.
Not supported
It is necessarily a DNS server without process/service confirmation.
Service is required but bound to all interfaces
Supported
The service may be more broadly exposed than necessary.
Not supported
It should be disabled without checking the scenario and network requirements.
Firewall context
Listener state and firewall state answer different questions
Listening does not guarantee reachability
A local firewall can block inbound traffic even when a service is listening.
Firewall rule does not prove a listener
An allow rule may exist even if no service is currently bound to that port.
Outbound rules matter too
Established connections can be influenced by outbound policy and application behavior.
Preserve first
Record the listener and owning process before changing firewall or service state.
Windows firewall
Inspect policy without changing it
Enabled firewall profiles
Get-NetFirewallProfile
Shows Windows Defender Firewall profile state.
Enabled firewall rules
Get-NetFirewallRule -Enabled True
Lists enabled firewall rules for review.
Rule details
Get-NetFirewallRule -DisplayName "Example Rule" | Get-NetFirewallPortFilter
Shows protocol and port filters associated with a selected rule.
Linux firewall
Inspect policy without changing it
UFW status
sudo ufw status verbose
Shows Ubuntu-family UFW state and configured rules.
nftables ruleset
sudo nft list ruleset
Shows nftables configuration where nftables is in use.
Question-to-evidence map
Choose the right artifact for the network question
What is listening?
Local address, local port, protocol, state, and owning PID.
Which process owns the listener?
PID mapped to process name, executable path, command line, and user.
Why is the process running?
Service, task, cron, timer, startup source, parent process, and logs.
Is the service required?
Scenario requirements, role, dependencies, and application purpose.
Was there remote communication?
Established connection records, application logs, process state, and firewall/network evidence.
Was the exposure broader than necessary?
Bind address, firewall policy, service configuration, and network role.
Preserve before action
Capture the live network state before changing it
Record protocol.
Record local address and local port.
Record remote address and remote port for active connections.
Record connection state.
Record owning PID.
Record process name, path, command line, user, and parent.
Record service or scheduler relationship.
Record executable hash when useful.
Record relevant firewall state.
Record related logs and timestamps.
Check whether the service is required by the scenario.
Only then stop, disable, or firewall the service if appropriate.
Correlation
Connect sockets to services, users, schedules, and logs
Service installed at 09:10 + process starts at 09:11 + listener appears on 0.0.0.0:8088
Supported conclusion
The newly installed service likely explains the new listener.
Cron executes script at 10:00 + child process starts + outbound connection appears at 10:00
Supported conclusion
The scheduled job likely explains the process and connection.
RDP logon at 11:02 + user process starts at 11:05 + established connection at 11:06
Supported conclusion
The network activity occurred during the remote interactive session.
Package install + systemd service start + TCP listener on expected application port
Supported conclusion
The package installation likely introduced the service and listener.
Unexpected listener + executable in user Temp + scheduled task points to same executable
Supported conclusion
The process, path, task, and listener belong to one recurring execution chain.
Required service + wildcard bind + firewall allows all inbound sources
Supported conclusion
The service may be more broadly exposed than necessary even if it is required.
Common mistakes
Network-analysis mistakes that weaken forensic conclusions
Assuming port equals application
Ports are conventions. Map the socket to the process and service before naming the application.
Stopping the service before recording the socket
You can lose the current listener and connection evidence.
Ignoring bind address
Loopback-only exposure is very different from listening on all interfaces.
Treating every remote IP as suspicious
Backups, updates, cloud services, monitoring, and legitimate applications all create remote connections.
Ignoring the process path
The executable location often determines which evidence source to inspect next.
Confusing firewall rule with active service
An allow rule may exist even when nothing is listening.
Disabling required services
Competition scenarios can require services to remain available.
Forgetting your own changes
Firewall and service changes create new state that should be recorded separately.
Fictional network lab
Reconstruct a required service and evaluate its exposure
Fictional service LabReporter starts on CP-WIN-14.
reporter.exe runs as PID 5520 from C:\ProgramData\LabReporter\reporter.exe.
PID 5520 listens on 0.0.0.0:8099.
A rule allows inbound TCP 8099 on the current profile.
LabReporter records a connection from fictional client 192.0.2.80.
The fictional scenario states LabReporter is required but should only be reachable from the local management subnet.
Task 01
What proves the service is actually listening?
The network-state record showing PID 5520 listening on 0.0.0.0:8099.
Task 02
What connects the listener to the service executable?
The owning PID maps to reporter.exe, which matches the LabReporter service process.
Task 03
Why does 0.0.0.0 matter?
It indicates the service is listening across available IPv4 interfaces rather than only loopback.
Task 04
Does the inbound firewall rule prove a client connected?
No. The application log provides the separate evidence that a client connection occurred.
Task 05
Should the service simply be disabled?
No. The scenario says the service is required. The defensive issue is limiting exposure appropriately.
Task 06
What should be preserved before changing the firewall rule?
Listener details, PID/process mapping, service configuration, firewall rule, application log, scenario requirement, and timestamps.
Lesson checklist
Before moving on
I distinguish listening sockets from established connections.
I record local and remote addresses and ports.
I record protocol and connection state.
I map the socket to an owning PID.
I map the PID to process name, path, command line, and user.
I check service or scheduler context.
I compare executable path and hash where useful.
I review firewall state separately from listener state.
I check whether the service is required.
I correlate network evidence with logs and process timing.
I preserve evidence before stopping or blocking anything.
I record my own defensive changes separately.
Reflection
Check your network reasoning
Question 1
Why does a port number fail to prove which application is running?
Question 2
What does 127.0.0.1 listening tell you that 0.0.0.0 listening does not?
Question 3
Why should firewall state and listener state be reviewed separately?
Question 4
How would you connect an established connection to a user or service?
Question 5
Why can a required service still create a security problem?
Question 6
What evidence should you preserve before disabling a listener?
Carry this forward
Map the socket to the process, map the process to its service or user, compare the exposure with the scenario, and preserve the live state before making defensive changes.