Network correlation

About 9 min read

A single PowerShell PowerShell Microsoft's shell and scripting language: Windows PowerShell 5.1 on .NET Framework, cross-platform PowerShell 7 on .NET. The most abused interpreter on Windows (ATT&CK T1059.001). Triage tells: -EncodedCommand or -enc (Base64 of UTF-16LE text), -NoProfile, -WindowStyle Hidden, IEX with a download cradle, and an Office or browser parent. Script Block Logging (Event ID 4104) records de-obfuscated script content. process may look legitimate. A burst of HTTPS traffic may look harmless. Together, they show the process making regular, automated connections to a newly registered domain: the shape of beaconing Beaconing Periodic network communication from an infected host to a C2 server. Legitimate software beacons too (updaters, telemetry and EDR agents), so baseline known-good cadences before you pivot. , and a hypothesis neither event earned alone.

Two perspectives, one picture

Where each half comes from

Correlation is a join, and a join needs both halves and a key.

• Process half: Sysmon Event ID 3 (network connection) and 22 (DNS query), or the EDR’s network events. These carry the process, the user, and the ProcessGuid. Sysmon’s network logging is off unless the configuration turns it on.
• Wire half: proxy and secure web gateway logs, firewall logs, Zeek conn, dns and ssl logs, NetFlow or IPFIX, and cloud flow logs such as VPC Flow Logs.
• The join: host plus source port plus destination plus a time window. Behind NAT or an explicit proxy, the firewall sees only the translated address or the proxy itself; the proxy log holds the real client. The correlation join keys in Uncover cover the trap in detail.

UtcTime=2026-03-10 14:22:05.001  ProcessGuid={6a1f0c3e-2b7d-65f0-4c1a-000000001a00}  ProcessId=8128
Image=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe  User=CORP\jdoe  Protocol=tcp  Initiated=true
SourceIp=10.20.4.17  SourcePort=51544  DestinationIp=198.51.100.23  DestinationPort=443

{"ts":1773152525.004,"uid":"CjX4a21kP0nQ3Vv7Ue","id.orig_h":"10.20.4.17","id.orig_p":51544,
 "id.resp_h":"198.51.100.23","id.resp_p":443,"proto":"tcp","service":"ssl",
 "duration":0.41,"orig_bytes":517,"resp_bytes":3870,"conn_state":"SF"}

Telemetry to analyze

Five telemetry views, each with its own signal patterns:

A finance workstation that normally talks only to internal ERP systems, suddenly opening TLS sessions to a low-reputation cloud storage provider after hours, is a strong exfiltration Exfiltration The unauthorized transfer of data out of the environment (ATT&CK TA0010): over the C2 channel, to cloud storage or a file-sharing service, by email, or through DNS. Triage signals are volume and destination: outbound bytes far above the host's baseline, a first-seen upload destination, and staging (archives appearing in temporary folders) shortly before the transfer. Confirmed exfiltration is an escalation criterion, and when the data is regulated it can start notification clocks. hypothesis. It stays a hypothesis until two questions are answered. What actually moved? (Byte counts show volume; only DLP or the storage provider’s object logs show content.) Did anyone authorize the destination? A sanctioned backup migration leaves the same trace. The decisive queries: which process opened the sessions, how the volume compares with the host’s own baseline, and who owns the destination tenant.

Correlation strategies

Three dimensions to weigh on every connection:

A PowerShell process repeatedly reaching out via HTTPS to a newly registered domain using a self-signed TLS certificate carrying a generic common name is a classic obfuscated-C2 pattern. An internal tool polling a just-provisioned dev endpoint can match it field for field, which is why the pattern opens an investigation rather than closing one. The process’s parent and the destination’s owner are the queries that split the two. Do not require the shady certificate, though: modern commodity C2 fronts with valid certificates from free CAs or hides behind CDNs, which is why domain age, prevalence, and a fingerprint rare for this host carry more weight than certificate hygiene. Increasingly, C2 rides on reputable services (Telegram bots, GitHub, Cloudflare tunnels, cloud storage APIs; ATT&CK T1102), where domain age and reputation are useless. There, the questions are which process talks to the service and whether that process ever should. Without combining process-level context, network metadata, and reputation scoring, the same activity might pass for ordinary HTTPS traffic.

Command-and-control indicators

Adversaries hide C2 inside legitimate protocols (HTTPS, DNS; ATT&CK T1071), and current frameworks (Cobalt Strike, Sliver, Havoc, Mythic) make that the default. The automation underneath leaves fingerprints.

An internal database server that suddenly sends gigabytes of zipped data to a generic cloud storage provider at 02:30 is a strong signal that data is leaving. It is a hypothesis of theft, not proof of it. Volume, timing, and destination establish that something large moved somewhere unusual; they cannot establish intent, and a DBA’s ad-hoc backup to a newly provisioned storage tenant leaves the identical trace. What separates the cases: a change record or maintenance window, ownership of the destination, and the process and identity that initiated the transfer. If those come back empty on a database server, do not wait for a motive: an unexplained bulk transfer from a high-value asset is High impact at no less than Medium likelihood, so the matrix places the case at P2 or higher, and the Escalation decision escalates on the evidence you have.

Check yourself

A Zeek conn log shows 10.20.4.17 opening a TLS session to 198.51.100.23:443 every 60 seconds, give or take 4, for six hours. The EDR’s network events for that host show OneDriveStandaloneUpdater.exe and an unsigned svcupd.exe from %LOCALAPPDATA% both talking to port 443 in that window. Parse it before you open the answer: which half tells you what, and what would you query next?