From Access to Exfiltration: How Detection Engineers Actually Catch Attackers

Introduction

Attackers don’t break in with magic tricks. They follow predictable behavioral loops — the same loops that have been documented in adversary frameworks for over a decade, the same loops that show up in incident response reports from Fortune 500 companies and small businesses alike.

The core thesis is simple, and it’s one I learned the hard way: prevention will inevitably fail at the perimeter. There will always be a zero-day, a misconfiguration, a credential that ends up on a dark web forum. The job of a detection engineer isn’t to build an impenetrable wall. It’s to create choke points at every phase of an intrusion so that attackers cannot succeed silently.

I didn’t come to detection engineering through a traditional cybersecurity career path. I earned an associate degree in cybersecurity and spent years as a systems administrator at 2SOPS, where I was responsible for securing a mixed environment of Solaris, Red Hat Linux, Windows Server, and Unix workstations. The rules were strict — they had to be, in a military environment — but more importantly, security wasn’t a separate team’s job. It was part of the daily work of keeping the systems running. That mindset — security as an operational discipline, not a compliance checkbox — is what drew me into detection engineering.

Most people in this field describe their job as “monitoring alerts.” That’s not wrong, but it’s incomplete. A passive alert-monitor is a human IDS. A detection engineer builds the things that generate those alerts — the telemetry pipelines, the rule logic, the correlation engines, the threat models that tell the rules what to look for in the first place.

This article walks through how I approach detection engineering: mapping the attacker lifecycle to real detection opportunities, dissecting the techniques that actually matter, and building the kind of defenses that assume the adversary is already inside.

Mapping the Attacker Lifecycle to Detection Opportunities

The attacker lifecycle — recon, initial access, execution, persistence, lateral movement, exfiltration — isn’t just a slide in a threat intel briefing. It’s a checklist of places where your security stack can intercept.

Reconnaissance & Initial Access

What the adversary does: The adversary doesn’t start by deploying custom malware. They start by looking. They scan your public attack surface, harvest your email addresses from LinkedIn and GitHub, try credential stuffing against your login portals, and wait for someone to click a link or open an attachment.

What the telemetry shows: Every one of these actions leaves a signal if you’re listening.

Authentication anomalies: Repeated failed logins followed by a success from an unusual geolocation. A user who normally logs in from New York at 9 AM suddenly authenticates from Lagos at 3 AM. These aren’t always malicious — VPNs exist — but they’re the first data point in a chain.
Edge proxy logs: The requests that hit your public endpoints before they ever reach your application. Rate anomalies, unusual user-agent strings, patterns that look like automated scanning.
Mail gateway telemetry: Attachment sandbox results, URL rewrite logs, SPF/DKIM/DMARC failures. The mail gateway is often the first and last line of defense against phishing — and it generates rich logs that most organizations underutilize.

The key insight here is that reconnaissance is noisy by nature. Attackers have to interact with your systems to find weaknesses, and every interaction is a potential detection. The question isn’t whether you can detect recon — it’s whether your rules are tuned to catch the specific patterns your environment produces.

Execution & Persistence

What the adversary does: Once they’re in, they need to run something. And that something needs to survive a reboot. So they write scripts, schedule tasks, modify registry keys, or set up cron jobs. They’re trying to establish persistence with minimal footprint.

What the telemetry shows: This is where process telemetry becomes critical.

Process parent-child lineage: The classic example is well-known for a reason. winword.exe spawning powershell.exe with encoded command-line arguments is suspicious. chrome.exe launching cmd.exe is more so. The pattern matters more than the individual process — it’s the relationship between processes that tells the story.
Binary launches from writable directories: When an executable runs from AppData\Local\Temp or /tmp instead of Program Files or /usr/bin, that’s a strong signal. Legitimate software almost never does this.
Scheduled task and cron modifications: Changes to the Windows Task Scheduler database, modifications to /etc/crontab or /etc/cron.d/, new entries in user crontabs. These are low-noise, high-signal events because legitimate automation is usually planned and documented.

The engineering challenge here is noise management. In a large environment, process creation events are voluminous. You can’t write a rule for every suspicious parent-child relationship. Instead, you build baselines — you learn what normal looks like in your environment, and you alert on deviations.

Lateral Movement & Exfiltration

What the adversary does: Now they’re inside and they want to move deeper. They use RDP, SMB, WMI, and PsExec to hop between systems. They dump credentials and tokens to expand their access. And eventually, they stage data for exfiltration — compressing it, encrypting it, and sending it out.

What the telemetry shows: This is the phase where network telemetry and endpoint telemetry converge.

Non-standard internal connections: A workstation that suddenly initiates RDP connections to five different servers in an hour. A database server that starts making SMB connections to a system it’s never talked to before. Internal network flows that violate the expected communication patterns.
DNS anomalies: A sudden spike in outbound DNS requests from a single host, especially to domains with high-entropy names (DNS tunneling) or domains registered within the last few days.
Outbound traffic patterns: Large outbound transfers to unfamiliar IPs, especially to jurisdictions that don’t match the organization’s business patterns. Encrypted traffic to destinations that don’t match any known CDN or cloud provider.

The detection engineering work at this stage is about context. A single alert about an outbound connection is noise. A pattern of reconnaissance-like behavior followed by credential access followed by lateral movement followed by data staging — that’s a kill chain, and it’s what you’re building your rules to catch.

Dissecting Common Attack Techniques

Phishing & Credential Access

Phishing remains the most effective initial access method, not because it’s technically sophisticated, but because it exploits the one system that can’t be patched: human psychology.

But the real technical story is what happens after the credential is captured.

Credential dumping on Windows is a technique I’ve seen in countless incident reports. Tools like Mimikatz target lsass.exe — the Local Security Authority Subsystem Service — because it holds plaintext credentials and Kerberos tickets in memory. The attacker opens a handle to lsass.exe with PROCESS_VM_READ access, reads the memory, and extracts credentials.

Traditional antivirus catches this because it knows the hash of Mimikatz. But the detection engineering approach is more powerful: alert on unauthorized process access handles to lsass.exe, regardless of what process is making the call.

The Sysmon event type for this is Event ID 10 (Process Access). A Sigma rule that flags any process accessing lsass.exe with VM_READ or DUP_HANDLE access — excluding only known EDR agents and system processes — will catch Mimikatz, LaZagne, and any future credential dumper that hasn’t been written yet. You’re detecting the behavior, not the artifact.

Living off the Land (LotL)

Living off the Land binaries — certutil, powershell, wmic, bash, curl — is the adversary’s best friend because these tools are installed on every system they target. They don’t need to drop malware; they just need to run the tools that are already there.

The detection engineering challenge is baseline exclusions. You can’t just alert on every use of powershell.exe — your automation scripts, your admins, your deployment tools all use it. If you alert on everything, you get alert fatigue, and alert fatigue is how attackers go undetected.

The trick is in the command-line arguments:

certutil -urlcache -split -f http://... — downloading files disguised as certificate operations
powershell -encodedcommand — obfuscated script execution
wmic process call create — launching processes from WMI
bash -c 'base64 -d' — decoding and executing base64-encoded payloads
curl -o /tmp/ followed by execution — the classic download-crun pattern

Your rules need to be specific enough to catch these patterns without drowning in false positives. That means understanding your environment’s normal use of these tools and writing rules that distinguish between the legitimate admin doing their job and the adversary using the same tools for a different purpose.

The Defensive Tooling & Engineering Pipeline

MITRE ATT&CK as an Engineering Spec

MITRE ATT&CK is widely misunderstood as a compliance checklist. It’s not. It’s a unit test plan for your security stack.

Each ATT&CK technique is a test case. The question isn’t “do we have coverage for T1059 (Command and Scripting Interpreter)?” The question is: if an adversary ran T1059.001 (PowerShell) right now, would we detect it? If the answer is “we might” or “probably,” then you have a gap.

The engineering workflow is:

Pick a technique from ATT&CK that’s relevant to your environment (prioritize techniques used in attacks against organizations like yours).
Identify the telemetry that would capture that technique (Sysmon Event ID, Windows Event Log, network flow data, cloud trail logs).
Write the detection rule (Sigma rule, SIEM query, EDR search) that would trigger on that telemetry.
Test it — with a red team exercise, a Purple Team lab, or a controlled simulation.
Tune it — reduce false positives, adjust thresholds, add exclusions for known-good activity.
Document it — link the rule back to the ATT&CK technique so future engineers can reason about coverage.

This turns ATT&CK from a static matrix into a living test suite that evolves with your environment.

SIEM & Pipeline Architecture

The software engineering problem in detection engineering is scale. A mid-sized enterprise might generate millions of events per hour. Your pipeline needs to:

Ingest these events reliably — no data loss, no back-pressure that drops events because the SIEM was busy.
Normalize them into a common schema — Elastic Common Schema (ECS) or Open Cybersecurity Schema Framework (OCSF) — so that a Windows Event Log, an AWS CloudTrail event, and a Linux auditd event can be correlated in the same query.
Process them with low latency — if your correlation rules run on data that’s 30 minutes stale, you’ve lost the window for real-time response.
Query them efficiently — your engineers need to hunt in hours, not days. Index design, retention policies, and query optimization matter.

The correlation rules themselves are software. They have logic, they have edge cases, they have performance characteristics. A well-written Sigma rule is declarative and portable. A well-written SIEM query (KQL, SPL, Sigma, YARA-L) is performant and maintainable. Treat them like code: review them, test them, version them.

Endpoint Detection and Response (EDR)

EDR agents are the eyes on the ground. They hook into system calls, monitor process creation, track file modifications, and observe network connections in real time. The engineering work is in what you observe and how you interpret it.

Modern EDR platforms provide APIs that let you:

Query process trees with full parent-child lineage
Search for file modifications in specific directories
Correlate network connections with the process that initiated them
Export raw telemetry for custom analysis

The bridge between threat intelligence and detection engineering happens here. A threat report says “APT group X uses technique Y to deploy backdoor Z.” You translate that into:

IOC-based detections: Hashes, domains, IPs — useful but short-lived.
Behavioral detections: TTP-based rules that catch the technique regardless of the specific artifact — these have longer shelf life and catch variants.
Custom Sigma or YARA-L rules that encode the behavioral patterns from the threat report, tested against your environment’s telemetry, and deployed to your SIEM or EDR platform.

The best detection engineers don’t wait for threat reports. They think like attackers and build detections for what could happen, not just what has happened.

Conclusion

Detection engineering isn’t about building a perfect defense. It’s about building a resilient one — one that assumes the perimeter has been breached and focuses on making the attack visible at every stage.

The attackers who succeed are the ones who can move through the lifecycle without triggering anything. The attackers who fail are the ones who hit a choke point — a process creation rule, an anomalous network flow, an impossible travel alert — and either get caught or have to change tactics, which leaves more traces.

Your job is to put enough choke points in place that the cost of the attack — in time, in noise, in risk of detection — exceeds the value of the target.

What I’m Working On

I build detection rules and security tooling for a living, and I share what I learn publicly. If you’re interested in seeing my work:

Check out my GitHub for detection rules, Sigma templates, and home lab setups
Follow my blog for deep dives into specific techniques and detection engineering approaches
Reach out on LinkedIn if you’re building a Detection & Response, Threat Intel, or Security Software Engineering team and want someone who understands both the theory and the keyboard

The threat landscape doesn’t wait for permission. Neither should your defenses.

Written by Cynthia. Systems administrator turned detection engineer. Built on Omarchy Linux.