Triage Lab Reference Environment

Why the course needs a named environment

To show triage on real evidence, the course has to point at concrete log sources, real query languages, and actual tools. Abstraction does not teach. "Check the authentication logs" is a platitude until you see which log, what a real entry looks like, and which field answers the question. So the course commits to a specific default environment and works its examples there.

That commitment creates a tension worth naming, because it is the tension the whole course is built to resolve. A triage course welded to one vendor's stack would teach that vendor, not triage. You would finish it fluent in one console and stranded the moment you sat in front of a different one. But a course too abstract to name a tool teaches nothing you can execute. The resolution is a named-but-swappable reference environment: a concrete default stack, paired at every layer with its equivalent in the other common tools, so the examples are real and reproducible while the method stays portable.

The default stack

This is the environment the course's evidence examples assume. You do not need to run exactly this to follow along, the next sub covers building a lab, but when a sub shows a query, this is the stack it shows it in by default, with the swap column telling you where the same thing lives in the tools you might actually use.

The default leans Microsoft for two honest reasons. Most of this course's audience works in Microsoft-heavy environments, so the examples land for the majority without translation. And the entire stack, a tenant, a SIEM, the endpoint telemetry, can be stood up for free, so following along costs you time rather than money. Neither reason makes this a Microsoft course. The method you learn maps straight onto the swap column, and the queries prove it by appearing in more than one language every time they matter.

Artifact types, not products

Here is the habit that actually makes triage transfer, and it is worth slowing down on because it is the difference between an analyst who freezes in an unfamiliar stack and one who does not. You name evidence by what it is, not by which product happens to hold it.

Every environment has an authentication log. The triage question "did this account authenticate successfully, and from where?" is the same question in all of them. What differs is only the address: in the default stack it is Entra SigninLogs, on a Windows host it is the Security event log, on a Linux box it is /var/log/auth.log. Same artifact, same question, three addresses. The analyst who thinks "I need the authentication log" walks into any environment and finds it. The analyst who thinks "I need to run a SigninLogs query" is helpless the moment there is no Sentinel.

You met this in TR0.1 already. Here it is again as the deliberate point rather than a passing demonstration: one fixed triage question, three environments, the artifact constant while the source and syntax change underneath.

When a sub later says "pull the authentication log" or "check process creation," it means the artifact. It will show you the default-stack query and at least one equivalent, and your job is to recognise which of your own sources is the authentication log, the process-creation telemetry, the EDR alert, and run the version that fits your stack. That recognition, artifact first and product second, is the single habit that lets you triage in an environment you have never used. The course trains it on purpose, from here on.

The next sub turns this into something you can build: a free lab that lets you run these queries against real data instead of only reading them.