Alert chapter quiz
Twelve questions to test how you would apply the Alert chapter to fresh scenarios. Select an option to see the result.
Quiz: did the chapter stick?
No grades. The point is to push your thinking. Some questions are harder than they look.
An EDR anomaly engine fires at 02:14 local time with 64% confidence. The user's baseline shows they routinely work overnight. What is the right next step?
B. The overnight baseline answers only the environmental check; the other three are still open.
C. For a user who routinely works overnight, the hour alone is not evidence; validate first.
D. Parsing comes later; first, three validation checks are still unanswered.
The user's overnight baseline speaks to one validation check: environmental context. Agreement on one check is not validation. Technical fidelity, threat intelligence, and business impact are still unchecked; check all four, then decide. The 64% is the engine reporting how unusual the activity is, not a verdict on whether it is malicious; it does not stand in for the other three checks. And if context does clear it, the close is a benign true positive, not a false positive: the engine saw a real deviation.
Two alerts land at once, and you can open only one in the next 15 minutes. Alert 1: a lobby kiosk laptop with no sensitive access, where an Office-to-PowerShell chain is corroborated by a proxy record and a beacon is still running. Alert 2: a domain controller with a single low-confidence anomaly, a login at an unusual hour and nothing else. Which do you open first?
Need a nudge?
What would you have to defend in a post-mortem?
A. Criticality weighs what is at stake if an alert is real; it does not let a lone weak anomaly outrank a live, corroborated intrusion.
B. Blast radius matters once the activity is real, and a single unusual-hour login is not yet evidence of anything.
C. Alert 1 is already validated: an independent proxy record corroborates it and the beacon is still running.
Criticality weighs how much an alert matters if it is real; it does not make a weak signal strong. Alert 1 is malicious activity corroborated by an independent record and not contained by any control: the beacon is still running. That meets escalation criterion 1 on any host, so the escalation tripwire applies whatever the host's criticality. Alert 2 comes next, and its criticality is why it should not wait long, but a single unusual-hour login is an anomaly to validate, not an intrusion in progress. In a post-mortem, leaving a live beacon running to look at a lone anomaly is the choice you could not defend.
An adversary uses living-off-the-land binaries with no custom malware. Which detection approach is built to catch this, and what form does it usually take in practice?
Need a nudge?
Think about which layer of the activity is actually abnormal: the binaries, the single events, or the sequence.
A. LOLBins are signed system binaries, so their hashes match nothing bad.
B. Each single LOLBin run usually sits inside normal tolerance; the sequence is what stands out.
D. A hand-written rule can be behavioral by content; the labels are not exclusive.
Every binary in the chain is signed and individually unremarkable, so hashes match nothing bad and single events sit inside tolerance. What is detectable is the sequence: the parent-child chain and its context. The family label can be plural here: a deterministic Sigma-style rule that encodes that chain is rule-based by construction and behavioral by content. Name both when both apply; what matters for triage is reading the logic that fired, not picking its one true family.
A signature engine reports an exact match on a known-bad SHA-256. At the same moment, a UEBA (user and entity behavior analytics) engine flags the same host for 'unusual process activity'. Before any investigation, how should the analyst calibrate trust in the two signals?
Need a nudge?
The chapter assigns each detection family a starting posture: a prior, not a verdict.
A. Skepticism is right, but the mechanism sets a different starting prior.
C. A learned anomaly is real signal, but it stays ambiguous until something corroborates it.
D. How recently an engine was tuned says nothing about how precise its signal is.
This is the trust-calibration posture from the detection-mechanisms page. The mechanism label sets a prior, not a verdict. An exact indicator match starts higher because it is precise about the artifact, but turning that prior into confidence requires the calibration facts: is the indicator fresh, from a credible source, and rare here, or a stale hash on a dual-use tool? The anomaly is genuine signal that stays ambiguous until something corroborates it. Either way, the label is a prompt to read the logic that fired, not proof.
An alert reports an outbound TLS connection to a domain registered three days ago. The process is signed certutil.exe. The user is a developer. What would most raise your confidence that this is malicious?
B. New domains have many benign uses; age alone is weak.
C. certutil legitimately connects out to fetch CRLs and certificate updates.
D. Most outbound traffic is encrypted, so TLS does not separate malicious from benign.
In this environment each signal is weak alone: new domains and certutil both have benign uses (certutil fetches CRLs and certificate updates). The combination of a new domain, a download utility this user has no reason to run, and no documented business reason is the classic certutil-as-LOLBin pattern. That combination is what raises confidence, not any single signal. TLS adds nothing: most outbound traffic is encrypted, so it does not separate malicious connections from benign ones.
An EDR alert shows: powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQA... What does -enc tell you, and what is the right parsing move?
Need a nudge?
Encoded and encrypted are different words for a reason. The command-line parsing page covers this flag.
A. -EncodedCommand is Base64 encoding, not encryption; it decodes locally with no key.
B. Legitimate automation uses -enc too; the decoded payload decides, not the flag.
C. Dropping it throws away the one field that shows what actually ran.
-EncodedCommand takes a Base64-encoded UTF-16LE string. That is an encoding, not encryption, so it decodes locally with no key. The surrounding flags (-nop, -w hidden, abbreviated names) raise suspicion, and legitimate automation does use -enc, which is exactly why the decoded payload, not the flag, decides. Here the decoded text begins with IEX and New-Object, the classic download-and-execute-in-memory prefix.
A parsed process tree reads: explorer.exe → WINWORD.EXE → msdt.exe. A second branch on the same host shows svchost.exe → sdiagnhost.exe → conhost.exe. Which link is the anomaly?
Need a nudge?
Ask what business each parent has spawning its child. The process-relationships parsing page covers this lineage.
A. Explorer launching Word is a normal user double-click.
B. svchost.exe launching sdiagnhost.exe is how Windows normally runs troubleshooters.
D. Signed binaries can still form an abnormal lineage; that is why lineage, not identity, is parsed.
Explorer launching Word is a normal user double-click. svchost.exe launching sdiagnhost.exe (the Scripted Diagnostics host) with a conhost.exe child is how Windows normally runs troubleshooters. The break in the story is the middle link of the first branch: a word processor has no business spawning the Microsoft Support Diagnostic Tool, and that parent-child pair is the signature of the Follina exploit (CVE-2022-30190). In a live Follina case the payload then appears as a shell or LOLBin child of sdiagnhost.exe, which is the second place to look. Every node being signed by Microsoft is exactly why lineage, not identity, is what you parse. Follina was patched in 2022 and Microsoft has deprecated MSDT itself, but the lesson outlives the bug: an Office application spawning a system utility is the anomaly to parse for, whatever the utility.
An analyst pivots to Windows Security Event 4688 to reconstruct process creations, but the CommandLine field is blank on every event. What is the most likely reason?
A. Fileless activity still creates processes, and 4688 records a command line for each one once capture is on.
C. Event logs are cleared whole, not field by field; a field blank on every event points to configuration.
D. 4688 has a CommandLine field; it stays blank until the Group Policy setting is enabled.
4688 does have a CommandLine field, but populating it requires the Group Policy setting 'Include command line in process creation events' (Computer Configuration > Administrative Templates > System > Audit Process Creation), which is off by default, on top of the Audit Process Creation audit policy that makes 4688 fire at all. If it was never enabled, every historical event is blank and no retroactive fix exists. It is a telemetry gap you discover exactly when you need the data. The compensating sources are EDR process telemetry and Sysmon Event 1 (now also a built-in optional feature on Windows 11 and Windows Server 2025), and only if they were already running when the activity happened. This is why parsing includes knowing what your telemetry was configured to capture.
Review: Command line analysis: when there is no command line to parse
An identity provider flags a session token for a sales manager, presented from a new hosting-provider ASN with no sign-in prompt. Twelve minutes later the mail tenant's audit log records a new inbox rule on her mailbox. No host or process appears in either record. What should you join the two events on?
Need a nudge?
Which field would still match if the attacker changed networks between the two events?
B. Addresses change with proxies and VPNs, and the attacker can switch networks between events.
C. Timing alone joins coincidences, and tenant audit records can arrive long after the event.
D. MFA proves a human authenticated once, not who presented the token afterward.
With no host or PID in the story, the account and the session are the join keys. A session ID that appears on both records ties the replayed token to the action taken with it. A shared IP is weaker: addresses change with proxies and VPNs, and unrelated users can share one. Timing alone joins coincidences, and tenant audit records can arrive in the SIEM long after the event, so read event time, not arrival time. MFA satisfied proves a human authenticated once; it says nothing about who presented the token afterward, which is exactly how a stolen session is used. The cloud and identity parsing page covers this join.
A rule fires on exactly the behavior it describes: a signed backup agent reads every file in a user's home directory and uploads over TLS. Validation shows the agent is approved, deployed by IT, and behaving as its vendor documents. How should the alert be recorded?
A. The rule matched exactly what it was written to match; its logic did not misfire.
B. The telemetry was accurate: the agent really did read and upload the files.
D. Validation already showed the agent is approved and behaving as documented; record that evidence and close.
The detection did its job: the behavior it describes really happened. On the detection axis that is a true positive, and the activity axis records why it is not a threat: authorized, which ASSURED calls a benign true positive. A false positive means the rule matched something it was not meant to match (logic) or fired on bad telemetry (data); neither is the case here. The label matters downstream: a benign true positive is cleared by context (a pattern entry or a scoped, expiring exception) and the rule stays as written, while a false positive is a defect in the rule or the data. Record the evidence that showed the activity was authorized, so the close stays defensible.
On a managed macOS developer laptop, a behavioral EDR rule fires: Cursor Helper (Plugin), the IDE's extension host, launched a child process that opened TLS connections. The binary is signed with the vendor's Developer ID and notarized. Which parsed field moves the investigation forward most?
A. Signing and notarization show who published the binary and that Apple scanned it, not which extension or agent code it ran.
C. The parent name describes the container; the extension host runs third-party code under that name.
D. Port 443 carries most traffic, good and bad; it does not say what code opened the connection.
The IDE runs extension code, MCP servers and agent commands under the vendor's signature, so the signature, the parent name, and the port all describe the container, not the code. The child's script path (inside the signed app bundle, in a user-writable directory, or in a third-party extension folder) is what tells you which code launched the connections. It also points to the next lookups: the extension inventory, the MDM record for the installed version and hash, and the destinations against the vendor's published allowlist. Signed and notarized proves who published the binary, not what it ran.
A draft Alert handoff reads: 'Validated alert: encoded PowerShell from Word, beacon to a new domain, corroborated by proxy logs. Recommendation: isolate the host and reset the user's password.' What is the main problem with it?
A. Containment belongs to IR; Alert hands forward leads and flags, and without approval only reversible pre-authorized actions run.
B. Leads and flags are what Subject needs; a handoff that names only the alert forces a cold read.
C. Naming the corroborating source belongs in the validated alert; it is what makes the claim checkable.
Alert hands forward the validated alert, leads for Subject and Uncover (including the working hypothesis and known gaps), and flags for Scope, Risk, and Escalation. This draft skips the leads and flags and puts a containment plan in their place. Unless the alert closes at intake (a Level 0 pattern close, or a no-signal false-positive close), the verdict belongs to later phases, and containment always does. Here the evidence describes confirmed malicious activity that no control has contained, so the flag that matters is escalation criterion 1, met: the escalation tripwire fires, IR is paged, evidence is preserved, and only pre-authorized actions run. A password reset needs IR approval. A confirmed escalation criterion escalates from any phase, but escalation is a handoff, not a verdict.
Worth revisiting
Technical details verified . Product names, defaults and retention change; check your own tenant.