Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
▾
Linux Endpoint Investigation: Course Orientation
Module 0
Introduction
This is the free preview of a course about investigating Linux hosts, and it is a course in its own right rather than a sample of one.
Most orientations describe what is coming. This one does the job differently, because it was written last: the nine modules that follow already existed, so every figure here was measured rather than promised, and the principles it sets out were derived from working the material rather than planned in advance.
Ten sections. What makes Linux investigation a different job, what an intrusion leaves and for how long, every source of evidence ranked on two axes, the design decision that makes a host readable and the trap inside it, what the logs never record, where persistence lives, how an investigation is actually ordered, the nine ways this course decides what comes first, the estate the examples use, and the lab you will run everything in.
By the end you will know what this course teaches, what it leaves to other courses, and you will have a machine on which every command in it works.
What is in this module10 sections · 10 examiner exercises · 1 lab build
No prior Linux forensics. Every concept is explained at first use, and the only thing assumed is comfort with a command line.
Nothing about your estate. The techniques are readings against paths that exist on any mainstream distribution, and where an estate's choices matter the module says so rather than assuming.
A willingness to run things. This is a practical course and the orientation ends with a lab build, because the techniques become yours by being run rather than by being read.
What you will be able to do
Ask questions a Linux host can answer. What was managed, what is unmanaged and what is running are three answerable questions where what is installed is not.
Say what a reading actually claims. A process listing is accurate at the moment taken and describes a host that has already moved.
Place any source on two axes. How fast it changes and how long the old version is kept are independent, and a stable source can still expire.
Order work by what cannot be repeated. Collection costs milliseconds and is irreversible; everything expensive in an investigation can be run again.
Build a lab and start. One virtual machine, one snapshot, three baselines and an account that can become root.
Start here
Begin with 0.1. It establishes what Linux does not give an investigator and what it gives instead, which every later section depends on, and it is the point at which habits imported from other platforms stop transferring.
Do I already know this material?
Six quick scenarios across the full range of this course, from live triage of a Linux server to recovering a deleted-but-running binary. Answer them to find out where you sit, and whether this course fits or it will sharpen knowledge you already have.
You are first to a running, possibly compromised Linux server. What should guide your first collection steps?
Power it off immediately and image the disk.
Capture volatile state first, running processes, open network connections, loaded modules, and memory, before any action that loses it, because shutting down or rebooting destroys that evidence.
The most fragile evidence on a live host is its running state. Processes, sockets, loaded modules, and memory disappear at shutdown, so you capture them before disk, which survives a power-off.
Reboot it into a clean state first.
Read only the application logs.
You want to find authentication activity and privilege escalation during the incident window on a Linux host. Where do you look?
The system authentication and session logs, such as the auth log and the journal, plus the login and escalation records, which capture who authenticated and what was elevated.
Linux records logins, failures, and sudo or su escalation in its authentication and session logs. That is where you place who was on the system, when, and when they gained higher privilege.
The kernel source tree.
The desktop environment settings.
The package manager cache only.
You suspect an attacker established persistence on a Linux host. Which set of locations is most important to examine?
Only the user's home directory.
The screensaver configuration.
The common persistence points: cron jobs and timers, systemd service units, shell startup files, and authorized_keys, where attackers most often survive a reboot.
Persistence on Linux clusters in a handful of places that run automatically: scheduled jobs, services, login scripts, and trusted SSH keys. Checking those first finds most footholds that outlast a reboot.
The font cache.
On a compromised Linux host you are tracing how the attacker became root. Which is a classic local privilege-escalation vector to check?
The wallpaper settings.
Misconfigured sudo rules and unexpected SUID binaries, which can let a normal user execute code as root.
Most Linux privilege escalation runs through misused trust: an over-broad sudo rule or a SUID binary that can be coerced into running attacker code as its owner. Those are the first things to enumerate.
The number of open browser tabs.
The hostname.
A suspicious process is running, but the binary it was launched from no longer exists on disk. How do you still recover and analyze it?
Conclude it cannot be analyzed.
Reinstall the operating system.
Wait for it to write itself back to disk.
Recover the executable through the kernel's live view of the process, the deleted binary is still mapped for the running process via /proc, and capture its memory.
Deleting a file that is still running only removes the directory entry; the kernel keeps the file open for the live process. You can read it back through that process's /proc entry and capture its memory before it exits.
Working on a live compromised host, what is the key discipline that keeps your evidence sound?
Edit files freely; it is your investigation.
Reboot between each step.
Minimize and record your own footprint: prefer read-only and trusted tooling, capture before you change anything, and document every action, since your activity alters the very state you are collecting.
On a live system the investigator is part of the evidence. Trusted, read-only tools, capturing before changing, and a record of every command keep your footprint small and known, so findings survive scrutiny.
Run the attacker's tools to see what they do.
This course is for you.
You will build Linux investigation from forensic foundations through filesystem and log analysis, server compromise, escalation and persistence, containers and cloud, memory analysis, and live response.
You have the fundamentals. The value here is the harder half.
You know the foundations and where Linux records activity, so the payoff is the back half: server compromise, escalation and lateral movement, container and cloud compromise, memory and malware analysis, and live volatile-data triage.
You handled volatile-first triage, persistence and escalation vectors, recovering a deleted-but-running binary, and live-response discipline, the senior end of the discipline. Take the course to sharpen what you have, close the gaps you did not expect, and turn strong instincts into sound investigations.
You are a student of this course now, so start by deciding what you want from it. Are you here to extend forensic skills onto Linux, to be ready when a cloud or container workload you own is compromised, or to build a real Linux IR capability from the ground up? Name that outcome, then turn it into a study plan: which environments and scenarios matter most to your work, how much time you will give it each week, and what you want to be able to handle by the time you finish.
The rest of Module 0 sets you up to do exactly that. Work through it to see why Linux IR differs, how a Linux compromise unfolds, the evidence landscape and the everything-is-a-file model, where attackers hide, the IR lifecycle, the reference environment, and the toolkit and lab you will use. Then begin Module 1.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
