What Is Local Process Packet Monitoring? (Host Audits)
Local process packet monitoring links host network activity to the process, user, and time involved. It combines process-start records with operating-system socket or connection telemetry, then correlates those records with network data. It does not mean each packet contains a process ID. Good host audits test attribution, track gaps, protect logs, and retain only evidence needed for a defined purpose.
Efficient monitoring starts with a narrow question: which programs make network connections on these hosts, and can an investigator connect an observed flow to its source? Collecting every packet by default can consume storage and capture sensitive content without improving process attribution. A focused audit can use lower-volume connection and process events first, adding packet capture only when a documented need calls for it.
I treat “local process packet monitoring” as a practical label, not a single standard feature. The key is to distinguish process-linked connection records from packet capture. A connection record can show that a process opened a network connection. A packet capture records traffic at a network point, but the packet itself does not inherently identify the originating process.
Plan Host Audit Scope and Telemetry
A host audit defines which devices, events, and investigation questions are in scope. Before enabling collection, document the operating systems and sensor versions, expected traffic, privacy limits, required fields, log access, and retention period. This plan supports NIST SP 800-53 Rev. 5 audit and monitoring controls without collecting more data than the audit needs.
Start with the investigation task. For example: “Identify which process on this workstation connected to this remote address at this time.” That question needs reliable process identity, connection details, and timestamps. It does not automatically require payload capture.
NIST controls offer a useful frame:
- AU-2 covers choosing which events to audit.
- AU-3 covers the information an audit record should contain.
- AU-12 covers generating audit records.
- SI-4 covers monitoring systems for signs of compromise or misuse.
Set a scope for each host group. Record the OS build, sensor name and version, network interfaces, time zone, clock source, and expected services. Note whether the host uses a proxy, VPN, container, or network address translation (NAT), since these can affect how a connection appears in different records.
Set retention based on the investigation need, privacy rules, storage limits, and applicable policy. RFC 5424 defines a common syslog message format for transport; it does not define process attribution or mandate a retention period. Keep the retention decision in writing and restrict access to the collected records.
Check Process, Socket, and Flow Correlation
Correlation means joining separate records that describe a process, a socket, and network activity. It is an inference supported by identifiers and time, not a property carried inside every packet. Strong audits preserve process-start identity and flow context, then mark uncertain matches instead of presenting them as proven facts.
On Windows, Sysmon provides three useful event types. Event ID 1 records process creation and its context. Use the process GUID when available because a PID can be reused after a process exits. Event ID 3 records network connections associated with a process, but network connection logging is disabled by default and must be enabled in the Sysmon configuration. It is connection telemetry, not full packet capture.
Sysmon Event ID 22 records DNS queries associated with a process. It can show that a process asked for a name, but it does not prove that a later connection used the address returned by that query. DNS answers may change, arrive asynchronously, or be handled through a resolver or proxy.
Windows ETW/WFP telemetry and Linux eBPF or socket telemetry can provide operating-system-level connection context. Coverage depends on the OS, sensor, configuration, permissions, and version. Check the vendor or platform documentation for the exact event fields and loss behavior; do not assume that a sensor sees every interface or network path.
| Record | Useful for | Key limit |
|---|---|---|
| Process start | Process identity, parent, user, start time | A PID alone may be reused |
| Socket or connection event | Local and remote endpoints, process association | May miss events or paths, depending on sensor |
| DNS query | Process-linked name lookup | Does not prove which later connection used the result |
| Packet capture | Packet headers and, if not encrypted, possible payload data | Packet does not inherently identify its process |
Attribution can become ambiguous when a process exits quickly, a PID is reused, DNS and connection events arrive out of order, or traffic passes through a proxy or NAT. Event loss creates another gap. Preserve timestamps, process-start identity, socket or flow attributes, and sensor health data. If the join is incomplete, report “possible association” or “unknown,” not certainty.
Deploy and Configure Collection
Deployment should add only the telemetry needed for the stated audit. Enable process-start and socket or connection events, synchronize host clocks, and protect the logs from unauthorized change. Add packet capture only when connection records cannot answer the documented question and the extra collection has suitable access and retention controls.
A practical sequence is:
- Record a baseline. List hosts, interfaces, expected services, OS and sensor versions, privacy constraints, required fields, and retention.
- Enable collection. Configure process-start and connection events. Add DNS events when name lookups matter. Use packet capture only for a specific, approved investigative need.
- Protect time and records. Use the organization’s clock-sync method, record time zones, limit log access, and forward records to a protected store where appropriate.
- Correlate and test. Join records using stable process identifiers, socket or flow attributes, and timestamps. Test IPv4, IPv6, loopback, encrypted traffic, and short-lived processes.
- Operate the audit. Alert on defined behavior, watch sensor health and event loss, and review configuration after system or policy changes.
For Sysmon, use the official Sysmon package and a reviewed configuration. A basic installation command is:
Sysmon64.exe -i .\sysmonconfig.xml
To apply a revised configuration to an installed service:
Sysmon64.exe -c .\sysmonconfig.xml
The configuration must explicitly include the network connection event rule; installation alone does not enable Event ID 3. Confirm the rule and event fields against the Sysmon version in use. For a quick Windows check, query recent relevant records from an elevated PowerShell session:
Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-Sysmon/Operational'
Id = 1, 3, 22
StartTime = (Get-Date).AddHours(-1)
}
On Linux, ss -tpn can show current TCP sockets and process details when permissions allow. It is a point-in-time diagnostic, not a historical audit trail. For history, use a supported OS or sensor method that records connection events, and test its coverage and loss reporting on the actual distribution and kernel.
Do not apply a universal numeric threshold for clock drift or event loss. Set limits based on the time precision and evidence needs of the investigation, then measure actual performance. A practical audit check compares generated test connections with received records and reports missing events, timestamp gaps, and sensor restarts.
Verify Coverage, Attribution, and Retention
Verification tests whether the host actually records the events the audit depends on. A successful installation is not proof of complete coverage. Generate known test activity, compare it with collected records, inspect sensor health, and document what the sensor cannot observe.
Use a controlled test plan, with approved test destinations and accounts. Include a short-lived process, a long-running process, IPv4 and IPv6, loopback traffic, and expected encrypted connections. Check that process identity, user, start time, local and remote endpoints, protocol, and event time are present where the sensor supports them.
Compare each test action with the records received by the collector. Track the number of test connections generated and the number represented in the audit log. Investigate mismatches; do not treat a sample test as proof of universal coverage. Review sensor-specific loss counters, service status, and configuration after updates.
| Test | Evidence to inspect | Pass condition |
|---|---|---|
| Short-lived process | Process start and connection event | Records can be joined, or the limitation is documented |
| IPv4 and IPv6 | Endpoint family and address | Both are visible if used in scope |
| DNS followed by connection | Query and later flow records | Correlation is labeled as supported or uncertain |
| Proxy or NAT path | Host and network-side records | Translation or proxy effects are documented |
| Sensor interruption | Health and loss records | Gap is visible and investigated |
Use UTC or another documented time standard consistently. Check synchronization status and compare timestamps across host and collector. Choose an acceptable clock offset from the investigation requirement; there is no universal threshold suitable for every environment. Preserve the measured offset with the audit record when precision matters.
Protect logs with role-based access, change controls, and documented retention. Review who can view or export records, when logs are deleted, and how configuration changes are approved. Avoid broad payload collection when connection metadata is enough. The audit is ready for routine use only when coverage, uncertainty, retention, and sensor health have an owner.
Practical Audit Scenarios and Takeaways
These scenarios illustrate how to apply host auditing without implying that one sensor or configuration fits every network. They are test patterns, not claims about a specific installation. For each one, define the expected evidence first, run controlled activity, and record any uncertainty or coverage limit.
A workstation with a brief outbound connection: The process starts, opens a socket, and exits quickly. A process-start event plus a connection event may support attribution, especially when a process GUID and timestamps are available. A later PID-only lookup may be unreliable if the operating system has reused that PID.
A name lookup followed by a remote connection: A DNS event can identify the process that requested a name. The connection record may show the remote address, but the DNS record alone cannot prove that the connection used the returned address. Treat the relationship as a correlation unless the available telemetry directly supports a stronger conclusion.
Traffic routed through a proxy: The host may record a connection to the proxy rather than to the final destination. Network-side logs may describe the next leg of the traffic. Keep both views, note their different roles, and avoid claiming the host connection record identifies the final destination unless the proxy provides that evidence.
Conclusion and FAQ
Local process packet monitoring is best understood as host-based attribution supported by process, socket, and network records. It is not a promise that every packet can be assigned to a process. Define the question, collect proportionate telemetry, test correlation, and label uncertainty. Review sensor health and retention as part of normal operations.
Is a process ID included in every network packet?
No. Packets do not inherently contain the originating process ID. Host telemetry and correlation are needed to connect network activity to a process, and some cases remain uncertain.
What is the difference between connection logging and packet capture?
Connection logging records details about a connection, often including endpoints and process context. Packet capture records packets seen at a capture point. It may include more detail, but does not inherently identify the process that created each packet.
Does Sysmon Event ID 3 capture packet contents?
No. Event ID 3 records network connection activity associated with a process. It is not a full packet capture. It is disabled by default and must be enabled in the Sysmon configuration.
Does Sysmon Event ID 22 prove a DNS result was used?
No. It records a DNS query associated with a process. It does not prove that a later connection used the returned address, so treat that relationship as a correlation unless stronger evidence is available.
Why use a process GUID instead of only a PID?
A PID can be reused after a process exits. A process GUID, where available, helps distinguish one process instance from another and supports safer joins between process and connection records.
Can Linux ss -tpn provide a historical audit?
No. It displays current socket information and may show process details when permissions allow. It is a point-in-time diagnostic, not a record of connections that have already ended.
Should I capture all payloads to improve attribution?
Not by default. Payload capture may collect sensitive data and still may not identify the originating process. Use it only for a documented need, with access controls and a defined retention period.
How long should host audit records be retained?
There is no universal retention period set by RFC 5424. Choose a period based on investigation needs, policy, privacy requirements, and storage limits, then document access and deletion rules.
How can I tell whether the sensor is missing events?
Run controlled tests, compare generated activity with collected records, and inspect sensor health or loss counters. Confirm behavior for the specific OS and sensor version, and document known gaps rather than assuming complete coverage.
(This article was written by one of our staff writers, Garrett Vance. Visit our Meet the Team page.)
