Sign In
In this section

LX0.5 The Attacker's Perspective

3-4 hours · Module 0 · Free

Why Attackers Target Linux — and What They Do When They Get In

Operational Objective
The Attacker Model Question: you are investigating a compromised Linux server. To reconstruct what happened, you need to think like the attacker. Why did they target this server? What was their objective — cryptomining, data theft, lateral movement, ransomware staging? What is their typical workflow from initial access through persistence to objective execution? Each step in the attacker's workflow leaves artifacts in predictable locations. If you know the workflow, you know where to look. If you do not know the workflow, you search randomly and miss evidence that was right in front of you.
Deliverable: The ability to predict attacker behavior on a compromised Linux system — mapping the typical post-exploitation workflow (reconnaissance → persistence → privilege escalation → objective execution) to specific evidence locations, and using this prediction to prioritize investigation activities.
⏱ Estimated completion: 25 minutes

Why Linux Gets Compromised

Linux has a reputation for security that is partially earned and partially mythological. The earned part: Linux's permission model, mandatory access control frameworks (SELinux, AppArmor), and open-source visibility make it possible to build extremely hardened systems. The mythological part: the assumption that Linux does not get compromised because it is inherently more secure than Windows.

The reality in production environments is different. Linux servers get compromised for reasons that have nothing to do with the operating system's theoretical security model and everything to do with how they are deployed and managed in practice.

# Trace the attacker's typical post-exploitation workflow
# Each command checks for evidence of a specific attack phase

# Phase 1: Initial access — how did they get in?
grep -E "Accepted|Failed" /var/log/auth.log | tail -30
# Brute force: hundreds of "Failed" then one "Accepted"
# Stolen credentials: "Accepted password" from unusual IP/geolocation

# Phase 2: Reconnaissance — what did they look for?
grep -E "whoami|id|uname|ifconfig|ip addr|cat /etc/passwd" /home/*/.bash_history /root/.bash_history 2>/dev/null
# Standard recon: whoami → id → uname -a → ip addr → cat /etc/passwd

# Phase 3: Persistence — how did they stay?
find /etc/systemd/system/ -name "*.service" -newer /etc/os-release 2>/dev/null
find /home /root -name "authorized_keys" -newer /etc/os-release 2>/dev/null
# Services or SSH keys created AFTER OS install = suspicious

# Phase 4: Objective indicators
ss -tnp | grep -E ":3333|:4444|:8333|:14444"  # Mining pool ports
find /tmp /dev/shm -name "*.tar*" -o -name "*.zip" 2>/dev/null  # Data staging
Expand for Deeper Context

Internet-facing services with known vulnerabilities. Linux runs the majority of the world's web servers, mail servers, DNS servers, and application infrastructure. Every internet-facing service is an attack surface. When a vulnerability is published for Apache, Nginx, PHP, WordPress, Jenkins, GitLab, Redis, Elasticsearch, or any of the thousands of applications that run on Linux servers, the window between publication and exploitation is measured in hours. The organization that patches in weeks has a weeks-long exposure window. The Northgate Engineering scenario in this course's opening begins with exactly this pattern — a vulnerable PHP application behind an Nginx reverse proxy.

Weak SSH credential management. SSH brute force is the most common attack against Linux servers because it works. Organizations deploy servers with password authentication enabled, use weak or default passwords for service accounts, leave root SSH login enabled, and fail to implement key-based authentication or fail2ban rate limiting. The attacker does not need a sophisticated exploit — they need patience and a password list. LX4 investigates this pattern in detail.

Infrequent patching. Linux servers are often treated as "deploy and forget" infrastructure. The web server was deployed in 2022, configured once, and has not been updated since. The kernel has known privilege escalation vulnerabilities. The web application has known remote code execution vulnerabilities. The organization's patch management process covers Windows endpoints and ignores Linux servers because "Linux is more secure." LX6 investigates the privilege escalation patterns that result from this assumption.

No endpoint detection. The majority of Linux servers in production environments do not have EDR (Endpoint Detection and Response) agents installed. The Windows endpoints in the same organization have CrowdStrike, SentinelOne, or Defender for Endpoint. The Linux servers have nothing — no process monitoring, no network monitoring, no file integrity monitoring, no behavioral detection. The attacker who compromises a Linux server operates in an environment with near-zero detection capability. This course teaches you to investigate without EDR — using the native Linux evidence sources that exist regardless of whether a security agent is installed.

Container and cloud misconfigurations. Docker containers running as root. Kubernetes pods with privileged access. AWS EC2 instances with overly permissive IAM roles. Azure VMs with managed identity access to Key Vault. GCP instances with service account keys stored in environment variables. These misconfigurations are not Linux vulnerabilities — they are deployment errors that give the attacker a path from initial access to infrastructure-wide compromise. LX9 and LX10 investigate these patterns.

The Attacker's Typical Workflow

Understanding the attacker's workflow is not just academic — it directly informs the investigation sequence. Attackers follow a predictable pattern, and each step leaves specific artifacts in specific locations.

Step 1: Initial access. The attacker gains a foothold on the system through one of four primary vectors: SSH credential compromise (brute force, password spray, or stolen credentials), web application exploitation (SQL injection, file upload bypass, deserialization vulnerability, SSRF), exposed service exploitation (Redis without authentication, Elasticsearch without authentication, vulnerable Jenkins instance), or supply chain compromise (malicious package, compromised container image, poisoned CI/CD pipeline).

The evidence of initial access depends on the vector. SSH compromise leaves trails in auth.log and wtmp. Web application exploitation leaves trails in web server access logs and error logs. Exposed service exploitation may leave trails in the service's own log files (Redis logs, Elasticsearch logs) or may be entirely silent if the service does not log connections. Supply chain compromise is the hardest to detect because the malicious code arrives through a trusted channel.

Step 2: Reconnaissance. Within minutes of gaining access, the attacker runs commands to understand the environment: whoami (what user am I?), id (what groups am I in?), uname -a (what kernel version — are there known privilege escalation exploits?), cat /etc/os-release (what distribution and version?), cat /etc/passwd (what other user accounts exist?), ss -tlnp (what services are listening?), df -h (what filesystems are mounted, how much data is there?), cat /etc/crontab (what scheduled tasks exist?), sudo -l (what can I run as root?).

These commands may appear in .bash_history if the attacker uses an interactive shell. They will appear in auditd logs if auditd is configured. They will not appear anywhere else — this is the "dark zone" of Linux forensics where activity occurs but is not recorded by default. One of the core recommendations of this course is deploying auditd rules that illuminate this dark zone before the next incident occurs.

Step 3: Persistence. The attacker establishes mechanisms to maintain access: SSH key deployment (adding their public key to ~/.ssh/authorized_keys), cron job creation (a scheduled task that re-downloads and executes their payload), systemd service installation (a service that starts on boot), or more advanced techniques like shared library injection (/etc/ld.so.preload) and PAM module backdoors.

The evidence of persistence exists in the persistence mechanisms themselves — each is a file on the filesystem with a creation timestamp that correlates with the compromise timeline. LX7 investigates every persistence mechanism in detail.

Step 4: Privilege escalation. If the attacker gained access as a non-root user (common with web application compromise, where the initial shell runs as www-data), they escalate to root. The most common techniques: exploiting a SUID binary with a known vulnerability (PwnKit, DirtyCOW successors), exploiting a kernel vulnerability, abusing a sudo misconfiguration, or escaping a container to the host.

The evidence of privilege escalation appears in auditd logs (if configured) as execve system calls for SUID binaries by non-root users, in kernel logs (dmesg, kern.log) as crash reports or unusual kernel messages, and in filesystem artifacts as newly created files owned by root in directories writable by the attacker's initial user.

Step 5: Objective execution. The attacker achieves their goal: deploying a cryptominer for revenue, exfiltrating data for sale or espionage, deploying ransomware for extortion, establishing a persistent foothold for future operations, or using the server as a pivot point for lateral movement to higher-value targets.

The evidence of objective execution varies by objective. Cryptominers leave process artifacts, network connections to mining pools, and high CPU utilization records. Data exfiltration leaves file access records (if auditd is configured), network connection records, and potentially command history showing tar, scp, curl, or wget commands. Ransomware leaves encrypted files, ransom notes, and the encryption binary. Lateral movement leaves SSH connection records in auth.log on both the source and destination systems.

ATTACKER WORKFLOW → EVIDENCE CREATED INITIAL ACCESS SSH brute force Web app exploit → auth.log, access.log → RECON whoami, uname -a sudo -l, cat /etc/ → .bash_history, auditd → PERSIST SSH key, cron job systemd service → filesystem, timestamps → ESCALATE SUID exploit Kernel vuln, sudo → auditd, dmesg, files → OBJECTIVE Mine / Exfil Ransom / Pivot → proc, net, logs ANTI-FORENSICS — what the attacker does to cover their tracks truncate auth.log → wtmp + journal survive unset HISTFILE → auditd still records touch -t (fake timestamps) → ctime reveals the lie rootkit (hide processes) → memory forensics sees all Principle: every anti-forensic technique has a counter — the attacker must defeat ALL evidence sources to avoid detection
Figure LX0.5 — Why attackers target Linux systems. Internet-facing services (web, database, mail) present the largest attack surface. Weak credential management, infrequent patching, and minimal EDR deployment in most Linux environments create opportunities that Windows environments have closed.

The Anti-Forensics Problem — and Why It Fails

Attackers know about auth.log and .bash_history. The more capable ones attempt to destroy this evidence. But complete evidence destruction on Linux is harder than most attackers realize, because the evidence is distributed across so many independent sources.

An attacker who truncates auth.log (> /var/log/auth.log) removes the authentication event history — but wtmp still records their login sessions, the systemd journal still contains the SSH events in a separate binary file, and if auditd is running, the authentication events are also recorded in audit.log. To truly eliminate all authentication evidence, the attacker must address four independent log sources. Most attackers address one or two.

An attacker who runs unset HISTFILE prevents their commands from being written to .bash_history — but auditd (if configured with -a always,exit -F arch=b64 -S execve) records every command execution at the system call level, regardless of what the shell does with its history. The attacker can defeat bash history but cannot defeat auditd without root access and specific knowledge of how to disable it without being logged doing so.

An attacker who uses touch to backdate a file's modification time can fool a naive investigator who only checks mtime — but the ctime (inode change time) updates automatically and cannot be set by userspace tools. The discrepancy between mtime and ctime is itself evidence of tampering.

An attacker who installs a rootkit to hide processes from ps can evade userspace detection tools — but a memory dump analyzed with Volatility 3 reads the kernel's process list directly, bypassing the rootkit's userspace hooks. The rootkit hides the process from ps. It cannot hide it from a memory dump.

The principle: the attacker must defeat every evidence source simultaneously. Missing even one source leaves a trail. Investigators who check multiple sources catch the evidence that the attacker's anti-forensic technique did not cover. This is why the cross-correlation approach — checking authentication across auth.log AND wtmp AND journal AND auditd — is the foundation of Linux investigation methodology.

Worked artifact — Attacker workflow reconstruction template:

Complete this timeline as you identify evidence of each attack phase.

Case: INC-2026-XXXX System: [hostname]

Initial access: Method: ___ | Source: ___ | Timestamp: ___ Reconnaissance: Commands: ___ | Evidence: bash_history / auditd Persistence: ☐ SSH key ☐ Cron ☐ Systemd ☐ ld.so.preload ☐ Other Privilege escalation: Method: ___ | Root achieved: ☐ Yes ☐ No Objective: ☐ Cryptomining ☐ Data exfil ☐ Lateral movement ☐ Ransomware ☐ Botnet Anti-forensics: ☐ History deleted ☐ Logs truncated ☐ Timestamps faked ☐ Rootkit

Beyond this investigation: LX11 (Lateral Movement Campaign) reconstructs a multi-host attack from the attacker's perspective, tracing their decisions across 5 hosts over 8 weeks and revealing how each pivot expanded their access.

Myth: "Linux servers are targeted less frequently than Windows, so they need less monitoring."

Reality: Linux runs 96% of the world's top 1 million web servers, the majority of cloud infrastructure, and nearly all container workloads. The perception that Linux is "less targeted" comes from lower visibility — most Linux servers lack EDR agents and centralized logging. Servers are compromised at comparable rates; the compromises are detected less often and later. Cryptomining campaigns specifically target Linux because always-on, high-CPU servers are ideal for mining — and the absence of monitoring means miners run undetected for weeks.

Decision points: predicting the next attack phase

If you have identified initial access, predict the next steps: SSH brute force → check authorized_keys + bash history + /tmp for tools. Web exploit → check web root for web shells + process tree for reverse shells + privesc to root. Stolen cloud creds → check CloudTrail for API calls + new IAM roles + lateral movement to other resources.

Troubleshooting: when the attacker's workflow is unclear

No bash history and no auditd. Pivot to: filesystem timestamps (find -mtime), package manager logs, network connections, /proc enumeration.

Multiple persistence mechanisms found. Attackers deploy redundant persistence — document ALL before recommending eradication. Missing one means the attacker returns.

Try it yourself

Exercise

On a Linux system, run the attacker workflow trace commands from the code block above. Check whether your system has evidence of reconnaissance commands in any user's bash history. Check whether any systemd services or authorized_keys files were created after the OS installation. Check for outbound connections on common mining pool ports. You are practicing the same evidence checks you will use in every investigation scenario in this course.

Beyond this investigation

The attacker perspective in this subsection frames every investigation scenario in the course. LX4 (SSH Brute Force) follows the exact initial access → reconnaissance → persistence → objective pattern described here. LX5 (Web Application Compromise) shows how the attacker workflow differs when the entry point is a web vulnerability rather than SSH. LX7 (Persistence Mechanisms) catalogs every persistence technique the attacker's playbook includes — SSH keys, cron jobs, systemd services, PAM backdoors, kernel modules. LX13 (Malware Analysis) examines the tools the attacker deploys after gaining access. Understanding the attacker's workflow is not academic — it is the investigation roadmap.

2. An attacker gains access via SSH brute force, deploys an SSH key for persistence, and then truncates auth.log. What evidence of their activity still exists? 3. What reconnaissance commands does a typical attacker run immediately after gaining access, and where might the evidence of these commands be found? 4. Why is the absence of an EDR agent on a Linux server both a disadvantage for detection and a non-issue for investigation methodology?

Subsection artifacts: Attacker workflow → evidence map diagram. Anti-forensics counter-technique reference. Use the workflow diagram to guide your investigation sequence: trace the attacker's steps from initial access through objective execution, checking the evidence sources at each stage.

Interactive lab: your first Linux investigation

Before diving into the methodology, try investigating a real compromise. This SSH brute force scenario gives you a terminal where you can run investigation commands and examine the evidence. Type help if you get stuck.

Decision point

You are investigating a Linux server and discover evidence of both a cryptominer (resource abuse) and an SSH key theft (lateral movement preparation). The cryptominer is consuming 95% CPU and impacting production. Which do you address first?

Address the lateral movement first. The cryptominer is visible, noisy, and contained to this server — it is causing performance impact but not spreading. The SSH key theft is silent, potentially already exploited, and may have given the attacker access to additional servers. Contain the lateral movement risk: rotate the stolen SSH keys, check the target servers for unauthorized access, and apply network restrictions. Then address the cryptominer: kill the process, remove the binary and persistence mechanisms. Prioritizing the noisy but contained threat over the silent but spreading threat is the most common Linux IR prioritization mistake.

© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.
Unlock the Full Course See Full Course Agenda
← Previous Next →