In this section
Why Linux Incident Response Differs From Windows
What changes when the host is Linux
Linux incident response uses the same methodology as any other incident response and almost none of the same mechanics. The lifecycle you know carries over unchanged; where the evidence lives, how you collect it, and what normal looks like do not. This sub is about that gap, because closing it is the difference between an analyst who freezes on an unfamiliar Linux host and one who knows exactly where to look.
It teaches no investigative command yet. It teaches the three architectural facts that make Linux its own discipline, so that everything taught afterward, the logs, the live system, the persistence locations, lands on a frame that already makes sense.
The first thirty minutes on an unfamiliar host
An alert says a public-facing server has been making outbound connections to an address with no business reason. The server is Linux, you have SSH access, and the clock is running, because if the box is compromised the attacker may still be on it and evidence is decaying as you read.
If your training is on Windows or Microsoft 365, your first instincts now lead nowhere. Each reflex that works on Windows hits either a dead end or a completely different mechanism on Linux.
Three of the four reflexes hit nothing on Linux, and the fourth changes shape entirely. The analysts who struggle are the ones who keep reaching for the dead ends. This sub replaces all four with what actually works.
This is not a harder problem than Windows IR. It is a different one, and Linux turns out to be more transparent than Windows once you know where to look. Three facts do most of the damage to a Windows-trained instinct, 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, all different channels but one subsystem, one query interface, one place to pivot from. Linux has nothing equivalent, and this is the adjustment that catches people hardest. The evidence is split across separate, independent sources that share no console, no join key, and no common format.
Windows hands you an assembled picture; Linux hands you the raw sources and leaves the assembly to you. This is more work, and it is also why an attacker who scrubs one source usually misses another, leaving the disagreement between them as evidence.
This independence is not neglect. Linux grew from the Unix tradition of small programs that each do one thing and write plain text, composed by the administrator rather than integrated by a vendor. The investigative consequence is that correlation is your job, not the platform's, and Module 3 is built around that skill. To see what it means in practice, watch four independent sources tell one story.
No tool drew this. You read the login from the auth log, confirmed the session in the journal, dated the dropped file from its filesystem timestamps, and tied the connection to the process from the network state. Each row is partial; the sequence is the finding. Building this quickly is most of what separates a confident Linux investigation from a stalled one.
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 where the same evidence lives across distributions 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 many route through the registry: Run keys, services, scheduled tasks in known locations. You learn the autorun locations and check them.
Linux has no registry, no single store of system configuration. Configuration is scattered across plain-text files, and "run this at startup" or "run this on a schedule" can be arranged in many independent places, each a legitimate mechanism the system depends on, which is exactly why attackers use them.
The Windows habit of checking one autoruns store has no Linux equivalent. What replaces it is knowing the locations, and that knowledge is durable because the set changes slowly. Section 0.6 gives you the first-look list; Module 7 works through each.
The investigative habit to build now: persistence on Linux is found by enumerating known locations and asking, of each entry, "should this be here?"
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 rarely needs to bring malware. The tools to download a payload (curl, wget), decode it (base64), run it (bash, python3), schedule it (cron, systemd), and move on (ssh, scp) all ship with the system and are used constantly by administrators.
Nothing in that list is malware; curl and bash are on every server. What makes lines 2148 and 2151 evidence is the context, and an administrator who knows the host sees four separate signals fire at once.
No single signal is conclusive; together they are a confident finding. Each is visible only because you know what its absence looks like, which is why this course spends so long teaching what normal is. The anomaly is only legible against the baseline.
This is the reframe 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 connection, "is this what 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 is easy to read those three facts 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 connections, the file each process was launched from, the user behind it, all exposed directly by the kernel, 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, which is what makes the time you spend here transfer to your own servers rather than to a single course scenario. The next sub puts the facts in motion: a real compromise from first access to objective, and the evidence it leaves at each step.