Sysmon Event ID 3: Network Connection Explained

Sysmon Event ID 3 is the network connection event: it logs a TCP or UDP connection and ties it to the process that made it. It answers the question firewall logs and NetFlow cannot: not just "which IP did this host talk to", but "which program, run by which user, opened that connection".

It is also disabled by default, and in most real deployments it is filtered hard because of volume. So the first thing to check on any investigation is whether it was even collecting. This guide covers the fields, the attack patterns it exposes, searches you can paste, and the false positives that waste your time.

What Sysmon Event ID 3 logs

Microsoft describes the event as logging TCP/UDP connections on the machine, linked to a process through ProcessId and ProcessGuid. These are the fields you will use most:

• Image: the full path of the program that made the connection. This is the whole point of the event. powershell.exe talking to the internet is one thing; rundll32.exe doing it is another.
• User: the account the process ran as. A service account browsing to a file-sharing site, or SYSTEM talking to a rare IP, stands out.
• Protocol: tcp or udp.
• Initiated: true if the host started the connection (outbound), false if it received it (inbound). Most hunting starts with Initiated=true.
• SourceIp and SourcePort: the local side. Source ports are usually random high numbers, so you rarely filter on them.
• DestinationIp: where the connection went. Check it against threat intel and look at how rare it is across your estate.
• DestinationHostname: the name Sysmon resolved for the destination, if any. It comes from a reverse DNS lookup (controlled by the DnsLookup setting), so it can be empty or misleading. Do not treat it as the name the process actually asked for.
• DestinationPort: 443 and 80 are expected. A process connecting out on 4444, 8080 or a random high port deserves a look.
• ProcessGuid: lets you jump to the Event ID 1 for the same process and see its command line and parent.

The event also carries RuleName, UtcTime, ProcessId, SourceIsIpv6, SourceHostname, SourcePortName, DestinationIsIpv6 and DestinationPortName. Timestamps are in UTC.

What it does not log: the data sent, the URL, or the DNS name the process queried. For the name, pair it with Event ID 22.

What it catches

Living-off-the-land binaries talking to the internet

Some built-in Windows tools almost never need to reach the internet. When rundll32.exe, regsvr32.exe or mshta.exe makes an outbound connection, something told it to fetch or send data. Signed binary proxy execution is tracked in MITRE ATT&CK as T1218.

Image: C:\Windows\System32\regsvr32.exe
User: CORP\jsmith
Protocol: tcp
Initiated: true
SourceIp: 10.1.20.45
SourcePort: 52144
DestinationIp: 203.0.113.50
DestinationHostname: -
DestinationPort: 443

Here regsvr32.exe has no business on port 443. Take the ProcessGuid to Event ID 1 and read the command line.

Beaconing to a rare destination

Malware that checks in with its command-and-control server makes connections at regular intervals from the same process to the same destination. In Event ID 3 that shows up as many events with the same Image, the same DestinationIp and a steady gap between timestamps. Application layer protocols for C2 sit under T1071.

Count connections per host, process and destination, then look for the odd one out: a single workstation talking to an IP no other machine contacts, hundreds of times a day, from a process that is not a browser.

Connections on unusual ports

Attackers often use default ports from their tooling. Reverse shells commonly land on ports like 4444, which is the default listener port in some well-known frameworks, though a smart attacker will pick 443 to blend in.

Image: C:\Users\jsmith\AppData\Local\Temp\update.exe
User: CORP\jsmith
Protocol: tcp
Initiated: true
DestinationIp: 198.51.100.23
DestinationPort: 4444

Two things are wrong at once: an executable running from a user's Temp folder, and an odd port. Either alone is a lead. Together it is a case.

Searching for it

These searches are examples to adapt, not detections to deploy as is. Test them against your own data.

Splunk

This assumes Sysmon data in sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational". Field names are the ones from the Sysmon event itself; check how your Splunk Add-on for Sysmon version extracts them.

sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 Initiated=true
(Image="*\\rundll32.exe" OR Image="*\\regsvr32.exe" OR Image="*\\mshta.exe" OR Image="*\\powershell.exe")
| stats count min(_time) as first_seen max(_time) as last_seen by host, User, Image, DestinationIp, DestinationPort
| sort - count

This lists outbound connections from processes that are rarely meant to reach the internet, grouped so repeated beacons stand out by count.

KQL

This assumes Microsoft Sentinel with Sysmon forwarded into the Event table, and pulls fields out of the EventData XML.

Event
| where Source == "Microsoft-Windows-Sysmon" and EventID == 3
| extend Image = extract(@'<Data Name="Image">([^<]+)</Data>', 1, EventData),
         Initiated = extract(@'<Data Name="Initiated">([^<]+)</Data>', 1, EventData),
         DestinationIp = extract(@'<Data Name="DestinationIp">([^<]+)</Data>', 1, EventData),
         DestinationPort = extract(@'<Data Name="DestinationPort">([^<]+)</Data>', 1, EventData)
| where Initiated == "true"
| where Image has_any ("rundll32.exe", "regsvr32.exe", "mshta.exe", "powershell.exe")
| summarize Connections = count() by Computer, Image, DestinationIp, DestinationPort
| order by Connections desc

Same idea: outbound connections from suspicious binaries, counted by destination.

False positives

• PowerShell and admin tooling. PowerShell downloads modules, talks to Microsoft 365 and runs management scripts. Look at the destination and the user: a known Microsoft range for an admin is routine, an unknown IP for a receptionist's account is not.
• rundll32.exe and svchost.exe. Windows legitimately runs services and components through them, so you will see traffic. Check the destination and the command line in Event ID 1 before judging.
• Software updaters. Chrome, Teams and other updaters make regular, repeated connections that look like beacons. The difference is the destination: vendor-owned and common across many hosts, versus rare and seen on one machine.
• Security and monitoring agents. EDR and backup tools check in constantly. Allowlist them by Image path and signer, not by name alone, since an attacker can name a file anything.

A good rule: the process path, the user, the destination and the timing should all make sense together. When one does not, dig in.

How it fits with other Sysmon events

Event ID 3 tells you a connection happened. The other events tell you why.

• Event ID 1 (process creation): use the ProcessGuid to find the command line and parent process. See Sysmon Event ID 1.
• Event ID 22 (DNS query): shows the name the process asked for, which fills the gap DestinationHostname leaves.
• Event ID 11 (file create): shows what was written to disk around the same time, such as a dropped payload. See Sysmon Event ID 11.
• Event ID 10 (process access): if the same process also touched lsass.exe, you may be looking at credential theft before data leaves. See Sysmon Event ID 10.

For the full map of IDs, read the Sysmon Event IDs cheat sheet.

FAQs

Is Sysmon Event ID 3 enabled by default?

No. Microsoft's documentation says the network connection event is disabled by default. You turn it on through a NetworkConnect rule in your configuration file.

Why is Event ID 3 so noisy?

Every TCP or UDP connection from every process can generate an event, and a busy workstation makes a lot of them. That is why community configs such as SwiftOnSecurity's or Olaf Hartong's sysmon-modular filter it, logging specific processes, ports or destinations rather than everything. Check your own config to see what is covered.

What is the difference between Event ID 3 and Event ID 22?

Event ID 3 logs the connection itself: process, IPs and ports. Event ID 22 logs the DNS query a process made. Together they tell you what name was looked up and what the process connected to.

Can Event ID 3 show inbound connections?

Yes. The Initiated field is false for inbound connections. Most hunting looks at outbound traffic (Initiated=true), but inbound entries help when you suspect a service is listening where it should not be.

TL;DR

Sysmon Event ID 3 logs TCP and UDP connections and links each one to a process, user and destination. It is off by default and usually filtered, so confirm it was collecting before you rely on it. Hunt for unusual processes making outbound connections, repeated connections to rare destinations, and odd ports. Then pivot to Event ID 1 and 22 to explain what you found.

How EpicDetect Can Help

Reading about Sysmon events only gets you so far. Adventures drops you into a story-driven SOC investigation where endpoint evidence like this is how you crack the case. Season Zero is free.

Want the fuller picture? The EpicDetect Atlas maps out what to learn next, from SOC fundamentals to detection engineering.