Phishing Triage Lab (Identity + Email + DNS Workflow for Beginners)

The scenario can run with sample logs, fabricated event lines, or a controlled lab environment you own. The point is to practice the workflow — not the technical depth of the phishing kit.

The workflow is: user report, then suspicious link or domain review, then identity and auth event review, then timeline, then containment recommendation, then documentation. Running through that sequence under a controlled scenario is the skill.

Keep everything defensive and lab-safe. You are learning to investigate and communicate a phishing incident, not to build one.

Start with the initial signal: user report, suspicious email forward, or login prompt complaint. Record the timestamp, the reported behavior, and which account or system might be involved.

Pull DNS and proxy logs and identity and auth events for the same time window. Look for repeated MFA prompts, unusual sign-in locations, new session creation, or forwarding rules added after an unusual access event. Each of those is a separate data point that needs its own source.

Build a short timeline table before making any containment recommendation. A table forces you to identify exactly what you know, what you are inferring, and what you still need to check.

A strong triage note has: what was observed, what is suspected, what evidence supports the suspicion, what evidence is missing, and what the recommended next action is. Five elements. If any are missing, the note is incomplete.

Keep direct evidence separate from inference. A lookalike domain in the browser history raises suspicion. Identity and session context is what determines whether impact occurred. Conflating the two leads to over-escalation on benign events or under-reaction on real ones.

Run the scenario twice — once with a benign outcome, once with a confirmed compromise. Calibrating when not to escalate is as important as knowing when to.