The Attack Lifecycle, Mapped to What You Can See

Every intrusion follows the same rough arc — get in, persist, move, collect, exfiltrate. Frameworks like the Lockheed kill chain and MITRE ATT&CK exist to describe it, but their real value for a defender is different: each stage produces observables. If you can't see a stage, you can't detect it. This lesson walks the lifecycle from the defender's side of the glass.

The stages, in operator terms

Initial access. Someone gets code execution or credentials: a phished user, an exploited web app, a leaked key in a repo. On Linux, look for shells spawned by services that shouldn't spawn shells (www-data running bash), authentication anomalies in journalctl -u sshd, and new processes under /tmp or /dev/shm. On Windows, Event ID 4688 (process creation) with command-line auditing is gold — enable it via Group Policy: Audit Process Creation plus Include command line in process creation events.

Execution and persistence. Attackers need to survive reboots and logouts. Common mechanisms: new systemd units (/etc/systemd/system/*.service), cron entries (crontab -l for every user plus /etc/cron.d/), new authorized_keys, or a writable ~/.bashrc. On Windows: services, scheduled tasks, and Run keys under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Sysmon (free, from Microsoft Sysinternals) logs all of this when configured — the SwiftOnSecurity baseline config is the usual starting point.

Lateral movement. SSH with stolen keys, wmiexec/psexec-style remote execution, or RDP to a better host. Signals: logins from a machine that never authenticates to this one, Event ID 4624 with logon type 3 (network) from unexpected sources, or sshd accepting a key for a service account that "never logs in."

Collection and exfiltration. Data gets staged — look for large archive creation, tar/zip/rclone/7z runs, reads of credential stores — then leaves via HTTPS, DNS, or a cloud bucket. Signals: egress spikes, DNS queries with long entropic subdomains, curl/wget to freshly-registered domains.

MITRE ATT&CK as your index

ATT&CK is a matrix of tactics (the why: persistence, privilege escalation…) and techniques (the how: T1053 scheduled task, T1078 valid accounts). Don't try to cover the whole matrix. Pick the ten techniques most relevant to your stack — for a typical Linux web tier, that's things like T1078 (valid accounts), T1059 (command interpreter), T1560 (archive collected data) — and ask for each: what would this look like in my logs?

Try this

On a Linux VM you own, run sudo apt install auditd, add sudo auditctl -w /usr/bin/curl -p x -k curl_exec, run curl https://example.com, then search with sudo ausearch -k curl_exec. You just built a stage-of-the-lifecycle detector. Now try catching nc or ssh the same way.

Field notes

• The kill chain is a model, not scripture. Modern intrusions skip stages and happen in minutes; use it to organize detection coverage, not to argue about whether ransomware "did recon."
• The most useful single log source on Linux is boring: centralized auth plus process events. Most orgs get data exfiltrated long before they notice — because nobody was watching stage one.