Host Security and the Attack Lifecycle

• Host Security and the Attack Lifecycle
  • From a foothold to total control
  • The map: MITRE ATT&CK tactics
  • Host attacks, step by step
    • Initial access and execution
    • Discovery and internal recon
    • Privilege escalation
    • Credential access
    • Persistence
    • Lateral movement, collection, exfiltration, and impact
  • Host defenses
    • Reduce the attack surface (prevention)
    • Detection: signatures vs. anomalies
    • Allowlisting vs. blocklisting
    • Software signing and verified boot
    • Isolation and recovery (limiting the blast radius)
  • Key takeaways
  • References

From a foothold to total control

The social-engineering page ends where this one begins: an attacker has tricked someone, exploited a service, or stolen a credential and now has a foothold — code running on one host as one user. A single unprivileged shell is rarely the goal. What turns a foothold into a breach is everything the attacker does next: escalating privilege, looking around, stealing credentials, spreading to other machines, establishing persistence, and finally acting on their objective (stealing data, deploying ransomware).

That sequence is the attack lifecycle, and host security is the discipline of detecting and disrupting it at every step. The key defensive insight is that a competent attacker must complete many steps, each of which can be observed or blocked. You do not have to stop the initial break-in perfectly (you won’t); you have to make sure that the dozen actions that follow leave evidence and hit walls. That is defense in depth on the host.

This page uses Linux for the worked examples (the course VM), but the lifecycle is platform-independent.

The map: MITRE ATT&CK tactics

The industry-standard model of the lifecycle is the MITRE ATT&CK framework, which organizes real-world adversary behavior into tactics (the attacker’s goal at each stage) and techniques (the specific how). The ATT&CK reference page covers the framework itself; here are the enterprise tactics in roughly the order an intrusion moves through them:

You do not need to memorize the IDs. The point is the shape: intrusions are a chain, and each link is a detection-and-prevention opportunity.

Host attacks, step by step

Initial access and execution

The attacker arrives via one of a handful of doors: a phishing payload, an exploited internet-facing service, a stolen credential, or a malicious supply-chain dependency. However they get in, they then need to execute code — drop a script, spawn a reverse shell, abuse a built-in interpreter (Python, PowerShell, bash). “Living off the land” (using tools already on the box) is favored precisely because it blends in.

Discovery and internal recon

A careful attacker’s first move on a new host is to look around — quietly. This is the on-host counterpart to network recon:

$ id; whoami                      # who am I, what groups
$ uname -a; cat /etc/os-release   # kernel & distro (→ which exploits apply)
$ sudo -l                         # what can I run as root WITHOUT a password?
$ ps aux; ss -tulpn               # running services & listening ports
$ ls -la /home/*; cat /etc/passwd # other users and accounts

sudo -l is the single highest-value command: a misconfigured sudoers entry is the most common clean path to root.

Privilege escalation

Escalation is, at its core, a failure of least privilege — the attacker finds something more powerful than it should be. The classic Linux hunting grounds:

# SUID binaries: run as their owner (often root) regardless of caller.
# A SUID binary that can spawn a shell or write files = instant root.
$ find / -perm -4000 -type f 2>/dev/null
/usr/bin/passwd          # expected
/usr/bin/find            # NOT expected — find can run commands → root shell

# World-writable files owned by root, weak service unit perms, etc.
$ find / -writable -type f 2>/dev/null | grep -vE '^/proc|^/sys'

Other common vectors: passwordless sudo entries, writable cron scripts running as root, a vulnerable setuid program (memory corruption), an exposed kernel exploit, or secrets sitting in a readable config file. Tools like LinPEAS and linux-smart-enumeration automate this entire sweep — defenders run them too, to find the holes first.

Credential access

With or without root, stealing credentials lets the attacker expand and persist. On Linux: reading /etc/shadow (root only — the hashes then go to hashcat/john), harvesting SSH private keys from ~/.ssh/, scraping passwords from history files, config files, and environment variables, or dumping process memory.

Persistence

The attacker wants to survive a reboot or a password reset. Every persistence mechanism is something a defender can enumerate and monitor:

# cron — a job that re-establishes a backdoor every minute
$ crontab -l; ls -la /etc/cron.* /var/spool/cron/

# systemd — a malicious service or timer that starts at boot
$ systemctl list-units --type=service; ls -la /etc/systemd/system/

# an added SSH key = passwordless login forever
$ cat ~/.ssh/authorized_keys

# a new or modified account / a backdoored shell profile
$ cat /etc/passwd; ls -la ~/.bashrc ~/.profile

Lateral movement, collection, exfiltration, and impact

From one host the attacker pivots to others — reusing the SSH keys and passwords just stolen (lateral movement shows up in network flow data), collects the data they came for, exfiltrates it (often tunneled over HTTPS or DNS to evade egress filtering), and finally delivers impact: ransomware encryption, destruction, or quiet long-term espionage.

Host defenses

Defenses map onto the lifecycle: some prevent steps, some detect them, some limit the blast radius when prevention fails.

Reduce the attack surface (prevention)

• Patch management — close the vulnerabilities used for initial access and privilege escalation. The cheapest, highest-impact control.
• Least privilege & hardening — minimal installed packages, no unnecessary services, restrictive file permissions and access control, and Mandatory Access Control (SELinux/AppArmor) so a compromised service is confined and cannot reach what it does not own.
• Strong authentication — phishing-resistant MFA, SSH keys over passwords, no shared accounts — shrinking the initial-access and lateral-movement surface.

Detection: signatures vs. anomalies

Two complementary philosophies underpin every detection tool:

• Signature / blocklist detection — match known-bad: a malware hash, a Suricata/Snort rule, a known C2 IP. Precise and low-noise, but blind to anything novel — it can only catch what someone has already catalogued.
• Anomaly / behavioral detection — model “normal” and flag deviations: a web server suddenly spawning bash, a user logging in at 3 a.m. from a new country, an unexpected outbound connection. Catches novel attacks but generates false positives.

The tools that implement these:

• HIDS (Host-based IDS) — e.g. OSSEC/Wazuh, auditd, AIDE (file-integrity monitoring) — watch the host itself: file changes, log events, privileged actions.
• NIDS/NIPS — Suricata, Snort — watch the wire for exploit and C2 traffic.
• EDR (Endpoint Detection & Response) — modern agents combining behavioral detection, process-tree visibility, and the ability to respond (kill a process, isolate the host). The data flows into a SIEM/SOC.

A practical Linux example — watch for tampering with the password file with the kernel audit system:

# Tell auditd to log every write/attribute change to /etc/passwd
$ sudo auditctl -w /etc/passwd -p wa -k passwd_changes

# Later, review what tripped the rule
$ sudo ausearch -k passwd_changes

This is a detective control implementing complete mediation over a sensitive object — the same reference-monitor idea from access control, applied as monitoring.

Allowlisting vs. blocklisting

• Blocklisting denies known-bad and allows everything else — fails open the moment something new appears (the weakness of pure signatures).
• Allowlisting permits only known-good and denies everything else — far stronger, the fail-safe-default design principle in action. Application allowlisting (only approved binaries may execute) shuts down most malware, at the cost of administrative effort.

Software signing and verified boot

Code signing lets a host verify that software genuinely comes from its claimed publisher and has not been tampered with — the digital-signature primitive applied to executables and packages (Linux package signing, Windows Authenticode, macOS notarization). Extended down the stack, Secure Boot and measured boot verify the bootloader and kernel before they run, resisting low-level persistence (bootkits/rootkits).

Isolation and recovery (limiting the blast radius)

• Virtualization & containerization — VMs and containers confine a compromise to one isolated unit; sandboxing runs risky code in a disposable environment.
• Backups — tested, offline/immutable backups are the definitive answer to ransomware impact: if you can restore, encryption loses its leverage. Untested backups are not backups.
• Full-disk encryption — protects confidentiality of data at rest if a device is lost or stolen (a different threat than a live remote attacker, but part of host security).

When prevention and detection both fail, you are in incident response — containment, eradication, and recovery.

Key takeaways

• A foothold is the beginning, not the end. The damage comes from the attack lifecycle: execution → discovery → privilege escalation → credential access → persistence → lateral movement → exfiltration → impact.
• MITRE ATT&CK is the shared map of that lifecycle; each tactic is a chance to detect or disrupt. You only need to break the chain, not prevent the first step perfectly.
• On Linux, escalation and persistence are concrete and enumerable: sudo -l, SUID hunting (find / -perm -4000), cron/systemd units, and authorized_keys — defenders run the same checks attackers do.
• Detection rests on two pillars — signatures (precise, blind to novelty) and anomaly/behavioral (catches the new, noisier) — delivered by HIDS, NIDS, and EDR feeding a SIEM.
• Limit the blast radius with least privilege + MAC, allowlisting, code signing, isolation, and above all tested offline backups — defense in depth, because any single layer will eventually fail.

References

• MITRE ATT&CK — Enterprise Matrix (tactics and techniques). https://attack.mitre.org/matrices/enterprise/
• Lockheed Martin, Cyber Kill Chain. https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
• NIST SP 800-123, Guide to General Server Security. https://csrc.nist.gov/pubs/sp/800/123/final
• CISA, Cross-Sector Cybersecurity Performance Goals (CPGs). https://www.cisa.gov/cross-sector-cybersecurity-performance-goals
• Linux auditd / auditctl(8) — the Linux Audit system. https://man7.org/linux/man-pages/man8/auditctl.8.html
• find(1) — SUID enumeration with -perm -4000. https://man7.org/linux/man-pages/man1/find.1.html
• PEASS-ng (LinPEAS) — privilege-escalation enumeration. https://github.com/peass-ng/PEASS-ng
• Wazuh — open-source HIDS/XDR documentation. https://documentation.wazuh.com/
• NSA/CISA, Secure Boot and firmware-protection guidance. https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/Boot_Security_Modes_and_Recommendations.pdf

Related course pages: MITRE ATT&CK Framework · Social Engineering · Access Control and Authorization · Memory Corruption · Suricata IDS/IPS · SIEM and SOC · Incident Response · Containerization

🛠️ Maintenance note: MITRE ATT&CK is versioned and revised periodically — re-verify the tactic list and any technique IDs against the current matrix each term. The enumeration commands (sudo -l, find -perm -4000, auditd) are stable, but confirm tool names (Wazuh, LinPEAS/PEASS-ng) haven’t moved repos.