Windows Event ID 3 — Network Connection

MITRE ATT&CK

Why It Matters

Network connections are the external expression of what a compromised process is doing — C2 beacons, lateral movement, data exfiltration, and payload downloads all generate Sysmon 3 events. No native Windows event provides equivalent process-to-connection mapping with this fidelity. Sysmon 3 enables detections that require correlating process identity with network behavior: powershell.exe connecting to an external IP, rundll32.exe making an outbound SMB connection, or a process beaconing to the same IP at regular intervals.

Key Fields

Normal vs Suspicious

Investigation Tips

1. 1.Process-to-connection anomalies: powershell.exe, wscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, certutil.exe, or any Office application making outbound TCP connections to external IPs. These processes have no legitimate business connecting externally in most environments.
2. 2.C2 beacon pattern: the same process connecting to the same destination IP at regular intervals (every 60s, 300s, etc.). Use a time-series analysis on Sysmon 3 events grouped by Image + DestinationIp — regular periodicity with low jitter is a beacon signature.
3. 3.Newly registered or high-entropy domain names in DestinationHostname — DGA domains (e.g. xkqjfmzbn.com) and freshly registered domains (< 30 days old) are common C2 infrastructure. Enrich with passive DNS or domain age data.
4. 4.Unexpected outbound SMB (port 445) from a workstation to another workstation — Sysmon 3 from rundll32.exe or cmd.exe to port 445 on an internal host = UNC path DLL loading or lateral movement attempt.
5. 5.High-volume DNS queries (UDP port 53) from processes that don't normally use DNS — DNS tunneling for data exfiltration or C2 generates unusually high query rates from non-browser processes.
6. 6.Inbound connections (Initiated = false) to non-server processes on workstations — a reverse shell waiting for a C2 callback appears as an inbound connection to cmd.exe or powershell.exe.

How Attackers Evade This Event

• →Domain fronting — C2 traffic sent over HTTPS to a legitimate CDN (Cloudflare, Azure Front Door); DestinationHostname shows CDN domain, actual C2 destination is in the HTTP Host header (not visible to Sysmon 3)
• →HTTPS C2 on port 443 — encrypted traffic is indistinguishable from legitimate web browsing without TLS inspection; DestinationPort = 443 blends with normal browser traffic
• →DNS over HTTPS (DoH) — C2 commands embedded in DNS queries sent via HTTPS; appears as port 443 traffic to DNS provider IPs (8.8.8.8, 1.1.1.1) from unexpected processes
• →Living-off-the-land downloading — using certutil, bitsadmin, or Invoke-WebRequest for C2; the connecting Image looks like a legitimate system tool
• →Short-lived connections — C2 beacons that connect briefly and disconnect; periodic pattern analysis is needed since individual events look benign
• →Disabling Sysmon network monitoring — removing the Sysmon network connection rule from config eliminates Event 3 entirely without stopping other Sysmon events

Related Event IDs

Frequently Asked Questions

Why is Sysmon Event 3 better than Windows Firewall Event 5156 for detecting C2 traffic?

Windows Firewall Event 5156 records network connections allowed by the firewall, but it only fires for connections that the firewall policy processes — and it lacks process context in a usable form. Sysmon 3 fires for every connection regardless of firewall rules, includes the full Image path of the connecting process, and is correlated with the Sysmon process tree (linking back to Event 1 via ProcessId). This means Sysmon 3 can answer 'which process made this connection and what was its full launch chain' in a single query. With 5156 alone, you know a connection was allowed; with Sysmon 3, you know exactly which process initiated it and can immediately assess whether that process should be making that connection.

How do I detect C2 beaconing using Sysmon Event 3?

Group Sysmon 3 events by Image + DestinationIp + DestinationPort and compute the time delta between consecutive connections. C2 beacons show regular intervals (e.g. every 60 seconds ± a small jitter). Legitimate traffic is bursty — browsers make many connections in short windows, then go quiet. In KQL: use bin() on TimeGenerated at the suspected interval, count Sysmon 3 events per bucket per Image+Destination pair, and look for consistent non-zero counts across all time buckets. C2 beacons maintain presence even during off-hours when legitimate traffic drops to near-zero.

Sysmon Event 3 is generating enormous log volume — how do I make it manageable?

Sysmon 3 is the highest-volume Sysmon event on most systems. Three filtering strategies: (1) Network-based exclusion in the Sysmon config — exclude connections to known-good IP ranges (corporate DNS, patch servers, cloud CDNs) by DestinationIp or DestinationPort. (2) Process-based exclusion — exclude connections from high-volume, low-risk processes (browsers, update agents, AV) by Image path. (3) Ingest selectively — collect Sysmon 3 only for processes in your high-risk watchlist (powershell.exe, cmd.exe, wscript.exe, mshta.exe, rundll32.exe, certutil.exe, Office applications) and discard the rest at the collector. This reduces volume by 80–95% while preserving coverage of the processes attackers actually use.