JUMP TO SECTIONChoose a lesson section
Four alerts. Several possible stories.
It is 09:22 at fictional Northstar Services. Payroll reporting is unavailable following overnight maintenance. Meanwhile, security operations reports a successful privileged sign-in and an unexpected finance-related role change. A former contractor's application session appears to work after offboarding. Endpoint protection also displays a critical alert for a suspicious helper.
Management wants the system online immediately. Your responsibility is broader than restoring a green dashboard: identify which evidence shows active unauthorized access, which alerts were prevented, which problems are operational, and what has not been observed. Respond without damaging trust boundaries or overwriting incident evidence.
Use everything you've learned.
Each curriculum phase contributes to one connected investigation. The phases below describe what you will be evaluated on—not the sequence of individual corrective actions or the specific answer to the incident.
Understand the risk
Identify the business service, assets, trust boundaries and which recorded outcomes actually matter.
What credible validation looks like
You can distinguish an attempted access, a successful role change, and an unknown data export.
Recognize the activity
Classify credible identity exposure, false-positive signals and service failures without forcing unrelated records into one attack chain.
What credible validation looks like
You can explain why a blocked EDR attempt differs from successful malicious execution.
Apply the right defenses
Choose least-privilege identity changes, actual application-session controls and correct trusted DNS/TLS endpoints.
What credible validation looks like
The unauthorized grants are removed while approved identities, endpoint protections and certificate validation remain effective.
Detect and investigate
Read original event results across multiple simulated systems, normalize UTC and escalate based on evidence and impact.
What credible validation looks like
You preserve source references, mark audit gaps as unknown and avoid claiming an unverified breach.
Respond and recover
Obtain scoped authority, test protected backups and key access, reconcile business records and prove both permitted and prohibited actions.
What credible validation looks like
Monitoring, legitimate payroll and denied unapproved access are verified before you document recovery and residual risk.
One case. Six fictional systems.
The exercise uses the same desktop-focused JoeLearns Labs mission runner as our other advanced scenarios. Choose connected systems, examine the provided ticket attachments, run quick commands in the simulated terminal, inspect records, and consider the consequences of each change before applying it.
The investigation tracker shows requirements that must be verified before you can close the case. A completed action does not automatically count as a successful test. Validate Resolution works only after the required evidence and outcomes have been addressed.
Urgency doesn't erase change control.
This capstone intentionally includes tempting high-impact shortcuts. They are part of the learning experience, not recommended real-world behavior. In the simulation, unsafe decisions can create an incident consequence that must be rolled back before closure.
Use the fictional evidence and attachments before making a change. The source event result is more important than a headline severity.
Treat the environment as six separate reporting systems; compare identities, UTC times, resource actions and change approvals rather than attributing by proximity.
High-impact changes require the right Northstar incident owner and a bounded target. Broad policy bypasses, mass account isolation and deleting records can escalate the simulated incident.
The simulated terminal runs only supported fictional commands; it never reaches a tenant, endpoint, network device or live backup.
A completed health check does not establish that the user can work, that unauthorized access is denied or that recovery objectives were met.
An uncollected audit category is an explicit uncertainty, not proof that data was or was not exported. Record it in the final handoff.
Build the case before closing the ticket.
Begin with the incident and change attachments, then read the source records in UTC. For each observation, ask who or what reported it, which operation was attempted, the recorded outcome, and which separate source could corroborate or contradict it. An outcome of BLOCKED is different from SUCCESS; uncollected auditing is different from a confirmed negative.
The finish line is evidence, not speed.
A successful capstone ends when the fictional incident is narrowed to defensible findings, corrective actions have the appropriate authority, essential service is restored securely, and the incident handoff reflects both proven and unproven outcomes.
Record original identity, endpoint, DNS/TLS and application evidence with their true observed outcomes.
Show named incident and service approvals before impactful simulated identity and gateway changes.
Restrict the suspect privileged session and role, and revoke the contractor's app-local access without disabling all users.
Confirm the endpoint event was blocked and keep it separate from the continuing finance privilege and the operational outage.
Correct the payroll destination and TLS identity; validate the backup point, historical key, data integrity and required business operations.
Demonstrate positive and negative access, healthy monitoring, and a case record with remaining export uncertainty and accountable owners.
If you choose a harmful action, investigate its consequence and reverse it through the simulation. That recovery process is itself valuable training. The exercise does not time-limit your reasoning or require trial-and-error attacks on real technology.
Take ownership of SEC-204.
Launch the complete applied Lab in a separate tab. Your briefing stays available for reference, and Labs supports optional local session recovery if you choose to enable it. Desktop is recommended for the full simulated investigation.
All work is fictional and self-contained. Your selections do not touch real accounts, applications, networks, security controls or backups.