OSDA Exam: Ten Detection Phases in 24 Hours

Most OffSec exams ask you to break in. OSDA asks you to explain what broke in, when, on which host, and how you would detect it next time. That inversion is why offensive-security candidates find it harder than expected, and why defenders sometimes find it more natural than they anticipated.

The exam runs for 24 hours and is structured as ten phases, each containing a series of attacker actions that must be detected, understood, and documented against a SIEM with endpoint integration.

What the day looks like

• Duration: 24 hours, proctored over a private VPN.
• Environment: a simulated corporate network with a SIEM and endpoint telemetry.
• Structure: ten phases, each with attacker actions to identify.
• Deliverable: a written analysis per action — what happened, where the evidence sits, how it was detected, and what it means.
• Course: SOC-200, nineteen modules and more than a dozen challenge labs.
• Validity: does not expire.

The clock is generous by offensive standards and tight by analytical standards. Ten phases in 24 hours means roughly two hours per phase, including writing.

The first hour: orient before you query

Do not open the SIEM and start searching. The first hour is for orientation:

1. Map the environment: which hosts, which users, which log sources are ingesting.
2. Confirm telemetry is complete — endpoint, network, authentication, and application logs.
3. Read the first phase description twice. Note the entities named in it.
4. Set up a working document with one section per phase before you find anything.

Candidates who skip orientation spend the day writing queries against sources that were never ingesting, and mistaking missing data for absent activity.

How to work a phase

A repeatable loop keeps quality consistent across ten phases:

Step	Question	Output
Hypothesis	What would this action look like in logs?	Expected event types and fields
Query	Which source and filter proves or disproves it?	Saved query and result
Correlate	Does another source confirm the same event?	Timeline entry with host and user
Assess	What did the attacker achieve?	Impact statement
Document	Would a reviewer reproduce this?	Finding with evidence

The correlation step is where strong answers separate from weak ones. A single log line is an alert. Two independent sources agreeing on host, user, and time is a finding.

Writing that scores

Each attacker action needs more than “detected”. The documentation should answer:

• What happened — the action in plain language, with the technique named.
• Where — host, user account, process, or network segment.
• When — timestamp with timezone, and the sequence relative to other actions.
• Evidence — the query used and the result that supports it.
• Detection logic — what rule or query would catch this in production, and what would cause a false positive.
• Response — containment, eradication, or monitoring recommendation.

The detection logic line is consistently underweighted. Anyone can report that PowerShell ran. Explaining which parent process, command-line pattern, and user context makes it malicious — and what benign activity looks similar — is the actual analyst skill.

Pacing ten phases

Hours	Phases	Note
0–2	Orientation, phase 1	Do not rush the environment map
2–10	Phases 2–4	Establish the query patterns you will reuse
10–14	Break	Sleep or rest; analysis quality collapses without it
14–22	Phases 5–8	The heaviest analytical block
22–24	Phases 9–10, review	Evidence check and submission

Two hours per phase is an average, not a rule. Early phases usually take longer because you are learning the environment; later ones go faster because the query patterns are established.

What is actually being tested

Not tool memorisation. SOC-200 covers ELK and Splunk, Windows and Linux telemetry, network evidence, malware analysis basics, and vulnerability management. The exam tests whether you can move from a vague phase description to a defensible conclusion using evidence.

Three skills carry most of the score:

1. Knowing where evidence lives. Authentication events, process creation, network connections, file writes, and application logs each answer different questions.
2. Building a timeline. Attack actions are sequential. A finding out of order is a finding that will be questioned.
3. Communicating uncertainty. “No evidence of execution in available telemetry” is a stronger answer than a guess, provided you state which sources you checked.

Preparation that transfers

• Practise with the challenge labs under time pressure. The labs teach tools; the timer teaches judgement.
• Write one-page incident reports. Take a lab attack and document it as if for a client: timeline, evidence, detection rule, response.
• Learn the log sources, not just the interface. Knowing that a process creation event includes a parent process is worth more than memorising a dashboard layout.
• Rehearse the false-positive conversation. For every detection rule you write, describe one benign scenario that would trigger it.

Common traps

• Reporting alerts instead of actions. The phase describes an attacker action; the answer must explain it, not list alerts.
• No timeline. Isolated findings lose points when the sequence matters.
• Missing host or user attribution. “Suspicious PowerShell” is incomplete without the account and machine.
• Ignoring phases that look empty. Absence of evidence is a finding if you state which sources you checked.
• Writing at the end. Ten phases reconstructed in the final two hours produce shallow analysis.

Where to go next

For the certification overview, pricing, and available study material, see the OSDA certification hub. For the analysis mistakes that cost the most points, read OSDA common mistakes. If you work both sides of the engagement, the OSCP hub covers the offensive counterpart.

Certification names belong to OffSec. This is independent study material, not official course content.