Post-incident reviews all start to sound the same after a while. Someone pulls up the timeline, points at a gap, and says: “We had a sensor for that. We just weren’t sending the logs to the SIEM.”
Almost every breach retro we’ve run has one thing in common: the data that would have caught it earlier already existed somewhere in the environment. It just wasn’t flowing into a place anyone was watching.
This is the SOC log sources checklist we now run against every new client environment — the five sources that are missing far more often than they should be, and the exact attack pattern each one would have caught.
1. DNS Query Logs
What it catches: C2 beaconing, DNS tunneling, and data exfiltration disguised as normal-looking traffic.
Why it’s missing: DNS is treated as “just infrastructure” rather than a security telemetry source. Most orgs log firewall traffic religiously and never touch the DNS resolver logs sitting right next to it.
What we’d have seen: a steady, regularly-timed pattern of queries to a newly-registered domain, or subdomains with unusually long, high-entropy names — a near-textbook signature of tunneling or beaconing that firewall logs alone would never surface.
2. PowerShell / Command-Line Process Logging
What it catches: fileless malware, living-off-the-land attacks, and the exact moment a phishing payload executes.
Why it’s missing: default Windows event logging doesn’t capture full command-line arguments unless it’s explicitly enabled (Event ID 4688 with command-line auditing, or PowerShell Script Block Logging). Most environments never turn it on.
What we’d have seen: the full, decoded command an attacker ran — not just “PowerShell executed,” but exactly what it downloaded and where it tried to send data. This is frequently the single highest-value log source in an entire investigation, and it’s off by default.
3. Authentication Logs From SaaS and Cloud Identity Providers
What it catches: account takeover, impossible travel, MFA fatigue attacks, and OAuth token abuse.
Why it’s missing: SOCs frequently monitor on-prem Active Directory closely but treat SaaS platforms — email, file storage, CRM, HR systems — as someone else’s problem, especially when each tool has its own separate admin console.
What we’d have seen: a login from a new device/location immediately followed by a mail-forwarding rule change or a mass file download — the classic account-takeover pattern that’s invisible if you’re only watching on-prem identity logs.
4. Endpoint Detection and Response (EDR) Process-Tree Logs
What it catches: the full attack chain from initial execution to lateral movement — not just “malware detected,” but the parent-child process relationships that show intent.
Why it’s missing: many organizations run EDR in “detect and alert” mode but don’t forward the full telemetry stream into the SIEM for correlation — so the SOC only sees the final alert, not the process tree that led to it.
What we’d have seen: the moment a spawned from an Office document, which then spawned a network connection — a chain that, viewed together, is an obvious compromise, but viewed as isolated alerts looks like three unrelated low-priority events.
5. Cloud Infrastructure and Storage Access Logs
What it catches: misconfigured storage buckets, unauthorized API calls, and bulk data downloads from cloud environments.
Why it’s missing: cloud access logging (like object-level access logs on storage buckets, or detailed API call logs) is often not enabled by default and carries its own storage cost, so it gets skipped during initial cloud setup and never revisited.
What we’d have seen: a spike in read/list operations against a storage bucket from an IP address that has never touched that bucket before — exactly the signature of someone who stumbled onto exposed data and started pulling it.
The Pattern Behind All Five
Notice what these five have in common: none of them are exotic. None require a six-figure tool. They’re mostly logs that already exist somewhere in your environment — they’re just not being collected, forwarded, or correlated.
That’s the actual lesson from every retro where this list comes up: the gap usually isn’t detection capability. It’s log source coverage. A SOC can have the best analysts and the best SIEM in the world and still miss an attack if the right data never made it into the pipeline.
Before your next tabletop exercise or audit, pull up your current log source inventory and check it against this list. If any of these five are missing or only partially enabled, that’s the fastest, cheapest visibility improvement you can make this quarter — faster than any new tool purchase.
Related reading: 10 Real Attacks a SOC Analyst Sees Every Single Day — see how several of these exact log sources would have caught the attacks on that list.
Leave a Reply