Log Dejargonizer

Sysmon · Event 3

Sysmon Event 3: Network connection detected

A process made a network connection, and Sysmon recorded which process, which account, and where to. It is the event that ties network activity to the specific program responsible — something a firewall log can never do.

Also written as Sysmon 3Sysmon Event ID 3Network connection detectedSysmon NetworkConnect

What it means for you

On a personal computer

You would only see this if you installed Sysmon yourself. It records which programs on your PC talk to the internet, which is useful after something goes wrong but blocks nothing.

For an analyst

Off by default in most configurations because the volume is enormous. Filter at the configuration level to the processes that matter — shells, scripting engines, system binaries, and anything running from a user-writable directory. Note that connections are recorded at initiation, so a blocked connection still appears here.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Network connection detected:
  RuleName: -
  UtcTime: 2026-08-28 09:14:07.442
  ProcessGuid: {a1b2c3d4-0000-0000-0000-00000000abcd}
  ProcessId: 7412
  Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  User: CORP\jbrooks
  Protocol: tcp
  Initiated: true
  SourceIsIpv6: false
  SourceIp: 192.0.2.44
  SourceHostname: LAPTOP-J7X2.corp.example
  SourcePort: 51993
  DestinationIsIpv6: false
  DestinationIp: 198.51.100.203
  DestinationHostname: -
  DestinationPort: 443
  DestinationPortName: https

The fields that decide it

Everything else in the log line is context.

Image
The program that made the connection. This is the field that makes the event worth having.
  • powershell.exe or cmd.exeA shell reaching the network. Legitimate for administration, and a hallmark of download cradles.
  • rundll32.exe or regsvr32.exeSystem binaries with no ordinary reason to make outbound connections.
  • A binary in a temp or user profile directoryPrograms running from these locations rarely have a legitimate reason to connect out.
  • A browser or mail clientOrdinary application traffic, and the bulk of the volume.
DestinationIp
Where the connection went.
DestinationPort
The port. Unusual ports from unusual processes are the combination worth looking at.
  • 443HTTPS. Where most traffic goes, including most command and control.
  • 4444A common default for several offensive frameworks. Not proof, but worth reading.
  • 445SMB. Outbound to the internet on this port should never happen.
  • 3389Remote Desktop, outbound.
DestinationHostname
The resolved name, when Sysmon could resolve it. Frequently empty.
Initiated
Whether the connection was outbound from this machine. Outbound is the interesting direction for most detection.
User
The account the connecting process runs under.
ProcessGuid
The stable process identifier. Join on it to pull the process creation event and see the full command line.

Ordinary reasons this happens

Most of the time it is one of these.

  • Ordinary application traffic — browsers, mail, chat, and streaming, which is most of the volume.
  • Software updaters and telemetry connecting on a schedule.
  • Management and monitoring agents reporting to their servers.
  • Domain-joined machines talking to domain controllers constantly.
  • Backup software transferring data on a nightly schedule.
  • Administrative scripting that legitimately downloads files or calls APIs.

When it is not ordinary

A download cradle fetching a payload.

What gives it awayA shell or scripting engine connecting outbound, usually to an address with no hostname and immediately after a document was opened.

ATT&CK T1105

Command and control beaconing.

What gives it awayRegular, evenly spaced connections from one process to one destination. The regularity is the signal, not the destination.

ATT&CK T1071.001

A system binary used as a network proxy.

What gives it awayrundll32, regsvr32, mshta, or similar making outbound connections. These have essentially no legitimate reason to do so.

ATT&CK T1218

Data being moved out of the network.

What gives it awayLarge sustained outbound transfers from a process that does not normally transfer data, particularly outside working hours.

ATT&CK T1041

Internal reconnaissance.

What gives it awayOne process connecting to many internal hosts on administrative ports in a short window.

ATT&CK T1046

What to do next

  1. Read the Image first. The process is what makes this event more useful than a firewall log.
  2. Join on ProcessGuid to the Sysmon Event 1 for the full command line and the parent process.
  3. Check whether the destination is internal or external, and whether it resolves to anything.
  4. Look at the timing pattern. Evenly spaced connections over hours are beaconing; bursts are usually transfers.
  5. Check whether the same process and destination pair appears on other machines. Widespread means it is your software.
  6. Pull Sysmon Event 22 for the same process to see what it looked up before connecting.

Queries to run

kql Shells and system binaries making network connections. Short list, and most of what it returns deserves reading. 
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 3 | extend Proc = tostring(split(Image, '\\')[-1]) | where Proc in~ ('powershell.exe','cmd.exe','wscript.exe','cscript.exe','mshta.exe','rundll32.exe','regsvr32.exe','certutil.exe') | project TimeGenerated, Computer, Proc, DestinationIp, DestinationPort, User
kql Beaconing, expressed as low variance in the interval between connections. Tune the thresholds to your environment. 
Event | where Source == 'Microsoft-Windows-Sysmon' and EventID == 3 | summarize connections = count(), spread = stdev(datetime_diff('second', TimeGenerated, prev(TimeGenerated))) by Image, DestinationIp, bin(TimeGenerated, 1d) | where connections > 50 and spread < 30
sigma System binaries making outbound connections. Very few legitimate hits in most environments. 
detection:
  selection:
    EventID: 3
    Image|endswith:
      - '\\regsvr32.exe'
      - '\\rundll32.exe'
      - '\\mshta.exe'
    Initiated: 'true'
  condition: selection
splunk Rarest process and destination pairs first, which surfaces the unusual without knowing what to look for. 
index=sysmon EventCode=3 | stats count by Image dest_ip dest_port | sort count asc | head 50

Common questions

Why does Sysmon Event 3 produce so much data?

Because every network connection from every process generates one, and an ordinary desktop makes thousands per hour. Most Sysmon configurations disable it by default for exactly this reason. Filter it in the configuration to specific processes rather than collecting everything and filtering later.

What is the difference between Sysmon Event 3 and firewall logs?

Sysmon knows which process made the connection; a firewall only sees the packet. That single difference is what makes Event 3 worth the volume — 'something connected to this address' is far less actionable than 'powershell.exe connected to this address'.

Does Sysmon Event 3 show blocked connections?

It records connection attempts as the process initiates them, so a connection later blocked by a firewall still appears here. That is useful — it shows what a process tried to do, not just what succeeded.

How do I detect command and control beaconing with Sysmon Event 3?

Look for regularity rather than destination. Beacons connect at consistent intervals, so grouping by process and destination and measuring the variance in the gaps between connections surfaces them. Low variance over many connections is the signal; the destination itself is usually unremarkable.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026