Start your lesson
Study the required lesson for each block, then take its short check. Guided exercises are optional. Required case practice within the blocks counts toward the readiness checklist, not lesson completion.
Your notesPrivate to you
Block 1 of 18SIEM correlation · Clock skew · Event normalization · Correlation key
Practice savedNext · 15 min
SIEM correlation · Clock skew · Event normalization · Correlation key
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
SIEM correlation
Joins normalized events using time, identity, host, request, or session fields to identify a sequence that separate records may not reveal.
Clock skew
Describes a source clock's offset from trusted time, which can make recorded event order differ from the actual sequence.
Event normalization
Converts source fields into consistent time, identity, host, and action meanings while retaining the original record for later validation.
Correlation key
Uses a shared request, session, process, principal, or network value that directly connects records relevant to the investigative question.
Required block check · Block 1
Required for course progress · Pass with 3 of 4 correct
Block 2 of 18Packet capture · Flow metadata · Process telemetry · Network five-tuple
Practice saved15 min
Packet capture · Flow metadata · Process telemetry · Network five-tuple
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Packet capture
Retains packets observed at a collection point for protocol, sequence, header, timing, and visible payload analysis.
Flow metadata
Describes connection endpoints, ports, protocol, duration, and volume while omitting most or all application content.
Process telemetry
Records executable identity, process identifier, user, parentage, command line, and lifecycle events on an endpoint.
Network five-tuple
Identifies a flow through source address, source port, destination address, destination port, and transport protocol.
Required block check · Block 2
Required for course progress · Pass with 3 of 4 correct
Block 3 of 18Correlate logs without losing event identity
Practice saved8 min
Correlate logs without losing event identity
Practice savedRequired provider lesson
Study the lesson below before taking this block's check.
For this block: Read Event attributes, including the interaction identifier and original event time, then Event collection's Note C about clock synchronization, offsets, and timestamp confidence. About 8 minutes. If you have already studied this lesson, you can go to the check.
Read Event attributes, including the interaction identifier and original event time, then Event collection's Note C about clock synchronization, offsets, and timestamp confidence. About 8 minutes.
Provider links open in a new tab. Confirm what you studied when you return. Time on external sites is not recorded automatically.
Optional ITForMe notes and practice
Correlate logs without losing event identity
By the end, you can
- Analyze supplied evidence for correlation key selection.
- Analyze supplied evidence for clock-skew correction.
Correlation joins events only after normalizing time, identity, and field meaning. Preserve original timestamps, time zones, event IDs, and raw records. A shared IP can represent NAT, a shared account can represent automation, and a hostname can be reassigned, so correlation keys should match the question being asked.
Clock skew changes apparent order. Compare authoritative time sources or known request identifiers before concluding causality. Aggregation is useful for pattern detection, but retain the events behind a count so an analyst can inspect failures, successes, and collection gaps.
Worked example
A raw WAF timestamp appears four minutes after its matching identity event, but both carry request ID req-7391 and the WAF clock is four minutes fast; normalization places both records in the same minute.
- WAF 14:06+00 req-7391 allowed POST /login
- Identity 14:02+00 req-7391 token issued
- Time check: WAF clock +00:04 relative to trusted source
Subtracting the known four-minute skew moves the WAF record from 14:06 to 14:02, the same minute as the token event. One forwarded sign-in request that the identity service answered fits both records, and the shared request ID supports the join.
Retain raw timestamps and record the correction; reconstruct the forwarded sign-in and its token issuance as one transaction at 14:02 rather than a token issued four minutes before its request.
Reasoning self-check
A raw WAF timestamp appears four minutes after its matching identity event, but both carry request ID req-7391 and the WAF clock is four minutes fast; normalization places both records in the same minute.
- WAF 14:06+00 req-7391 allowed POST /login
- Identity 14:02+00 req-7391 token issued
- Time check: WAF clock +00:04 relative to trusted source
- Record a timestamped fact table from the supplied evidence.
- Test the two most plausible explanations against every observation.
- Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
- Retain raw timestamps and record the correction; reconstruct the forwarded sign-in and its token issuance as one transaction at 14:02 rather than a token issued four minutes before its request.
- The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
- If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
- If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 3
Required for course progress · Pass with 2 of 2 correct
Block 4 of 18Choose packet and host evidence for the question
Practice saved18 min
Choose packet and host evidence for the question
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Choose packet and host evidence for the question
By the end, you can
- Analyze supplied evidence for socket-to-process attribution.
- Analyze supplied evidence for packet-capture evidence limit.
Packet capture shows what crossed a collection point: addresses, ports, flags, timing, sizes, and any visible protocol fields. It does not reveal activity that never reached that point or decrypted content it cannot see. Host process records can connect a socket to an executable and user but may omit traffic details.
Use the narrowest tool that can resolve the unknown. A connection-state table answers whether a host has a live session; DNS logs answer name resolution; process telemetry answers program ancestry; a capture answers retransmission or protocol sequence. Collecting everything can delay containment and increase sensitive-data exposure.
Worked example
A server has repeated outbound TCP sessions. The analyst must determine which process owns the socket before deciding whether it is expected.
- Flow: 10.50.2.9:49822 -> 203.0.113.20:443 every 5 minutes
- Host connection table: PID 4420 owns 10.50.2.9:49822
- Process record: PID 4420 path C:\ProgramData\sync\agent.exe signer Unknown
The connection table bridges the network tuple to PID 4420, and the process record supplies the executable identity.
Preserve the three records and validate agent.exe against inventory; do not infer payload content from encrypted flow metadata.
Reasoning self-check
A server has repeated outbound TCP sessions. The analyst must determine which process owns the socket before deciding whether it is expected.
- Flow: 10.50.2.9:49822 -> 203.0.113.20:443 every 5 minutes
- Host connection table: PID 4420 owns 10.50.2.9:49822
- Process record: PID 4420 path C:\ProgramData\sync\agent.exe signer Unknown
- Record a timestamped fact table from the supplied evidence.
- Test the two most plausible explanations against every observation.
- Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
- Preserve the three records and validate agent.exe against inventory; do not infer payload content from encrypted flow metadata.
- The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
- If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
- If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Work through the scenario
Use the case evidence to complete the tasks, then check objectives.
Guided: Validate a DNS-beacon hypothesis
A workstation makes regular DNS queries. Select the analysis that tests periodicity without assuming every repeated query is malicious.
- Threat analystactor
- DNS timing analysiscontrol
- User workstationresource
- analystinterpretsevidence
- evidencedescribesasset
Objectives
- Interpret the supplied evidence without overclaimingpending
- Choose the bounded evidence-supported actionpending
- Select evidence that verifies security and operational outcomepending
Evidence 1
Resolver log: host queries sync-updates.example every 300 seconds for four hours.
Evidence 2
Asset inventory: no approved agent uses that domain.
Evidence 3
Packet metadata: response size 44 bytes; no payload capture is available.
Fictional, disposable SOC evidence. No production system or external service is contacted.
Report an issue with this exercise
Required case practice
Required for the readiness checklist · Pass at 100%
Interpret a memory-string hit
A memory triage tool finds a credential-like string in a browser process. Decide what corroboration is required.
- Forensic analystactor
- Memory and session evidencecontrol
- HR browser sessionresource
- analystinterpretsevidence
- evidencedescribesasset
Objectives
- Interpret the supplied evidence without overclaimingpending
- Choose the bounded evidence-supported actionpending
- Select evidence that verifies security and operational outcomepending
Evidence 1
Memory scan: one string matches the token pattern.
Evidence 2
Browser log: active authenticated session to the approved HR portal.
Evidence 3
No process injection, child shell, or token use from another device is recorded.
Fictional, disposable SOC evidence. No production system or external service is contacted.
Report an issue with this exercise
Required block check · Block 4
Required for course progress · Pass with 2 of 2 correct
Block 5 of 18Parse evidence before automating conclusions
Practice saved10 min
Parse evidence before automating conclusions
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Parse evidence before automating conclusions
By the end, you can
- Explain and apply bounded decoding.
- Explain and apply structured-format semantics.
- Explain and apply pattern and command interpretation.
- Explain and apply defensive scripting boundary.
Decoding changes representation, not trust. Preserve the original value, record each transformation, and validate whether the output is text, binary, compressed, or another encoding. JSON, XML, YAML, and EVTX carry structure differently; flattening them too early can discard types, namespaces, nesting, event IDs, or provenance.
A regex finds text patterns and can produce false matches. Command analysis needs the interpreter, escaping rules, decoded arguments, parent, user, and host. Defensive scripts should default to read-only inputs, bounded files, explicit encodings, predictable error handling, and a reviewable output record before any response action is considered.
Worked example
A copied alert contains a Base64 PowerShell argument and a YAML inventory whose unquoted value on becomes a boolean in one parser.
- Original encoded argument retained with SHA-256
- Decoded command reads one registry path and posts the value
- Inventory parser changes host label
onto true
The reproducible decode reveals suspicious collection and egress; the YAML type conversion is a separate data-quality defect that can mis-scope automation.
Preserve the source, record the decode recipe, correct the quoted inventory scalar, and run a read-only parser on a copied fixture.
Reasoning self-check
A copied alert contains a Base64 PowerShell argument and a YAML inventory whose unquoted value on becomes a boolean in one parser.
- Original encoded argument retained with SHA-256
- Decoded command reads one registry path and posts the value
- Inventory parser changes host label
onto true
- Classify each supplied fact by the concept it supports and record what it does not establish.
- Choose the least disruptive authorized action that tests the leading explanation.
- Write the observable result that would confirm success and one result that would reopen the investigation.
Compare your reasoning
Expected answers
- Preserve the source, record the decode recipe, correct the quoted inventory scalar, and run a read-only parser on a copied fixture.
- The reproducible decode reveals suspicious collection and egress; the YAML type conversion is a separate data-quality defect that can mis-scope automation.
If you got stuck
- If two explanations remain possible, request the smallest missing evidence source.
- Do not convert a tool label, score, or absence of data into proof.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 5
Required for course progress · Pass with 3 of 4 correct
Block 6 of 18Choose packet, detection, and log tools by evidence need
Practice saved8 min
Choose packet, detection, and log tools by evidence need
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Choose packet, detection, and log tools by evidence need
By the end, you can
- Explain and apply packet and network-monitoring tool.
- Explain and apply siem investigation.
Wireshark and tcpdump capture or inspect packets at an observation point. Snort and Suricata evaluate traffic against rules and can produce alerts; deployment mode determines whether they only detect or also block. Zeek commonly creates protocol-oriented logs and supports network-security monitoring. None sees traffic that misses its sensor or plaintext hidden by encryption.
A SIEM centralizes and searches records, but normalization can merge unlike meanings and ingestion can be delayed. Keep the raw timestamp, normalized timestamp, source, sensor placement, query, exclusions, and retention window. Correlate on identifiers supported by the protocol or application rather than proximity alone.
Worked example
An IDS alerts on a file signature, Zeek logs an HTTPS session, and the SIEM shows the endpoint event six minutes late.
- Suricata alert references packet timestamp 09:11
- Zeek TLS log has the same five-tuple but no decrypted payload
- SIEM ingest_time 09:17; event_time 09:11
The records support one network session and delayed ingestion; the encrypted Zeek record cannot independently confirm file content.
Align on event time and five-tuple, retrieve the bounded packet/endpoint evidence, and document the sensor and encryption limits.
Reasoning self-check
An IDS alerts on a file signature, Zeek logs an HTTPS session, and the SIEM shows the endpoint event six minutes late.
- Suricata alert references packet timestamp 09:11
- Zeek TLS log has the same five-tuple but no decrypted payload
- SIEM ingest_time 09:17; event_time 09:11
- Classify each supplied fact by the concept it supports and record what it does not establish.
- Choose the least disruptive authorized action that tests the leading explanation.
- Write the observable result that would confirm success and one result that would reopen the investigation.
Compare your reasoning
Expected answers
- Align on event time and five-tuple, retrieve the bounded packet/endpoint evidence, and document the sensor and encryption limits.
- The records support one network session and delayed ingestion; the encrypted Zeek record cannot independently confirm file content.
If you got stuck
- If two explanations remain possible, request the smallest missing evidence source.
- Do not convert a tool label, score, or absence of data into proof.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 6
Required for course progress · Pass with 2 of 2 correct
Block 7 of 18Use intelligence and reputation services without outsourcing judgment
Practice saved8 min
Use intelligence and reputation services without outsourcing judgment
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Use intelligence and reputation services without outsourcing judgment
By the end, you can
- Explain and apply threat-intelligence platform role.
- Explain and apply registration and reputation evidence.
OTX, MISP, and OpenCTI can distribute indicators and relationships, but a platform name does not confer truth. Retain producer, collection time, markings, confidence, relationship direction, and local sightings. Shared infrastructure and recycled addresses require local corroboration before blocking or attribution.
WHOIS or RDAP describes registration records, AbuseIPDB aggregates reports, and Geo-IP estimates location. Privacy services, cloud hosting, carrier NAT, reassignment, VPNs, and stale databases limit inference. Query time matters: an address's present owner or location may differ from the incident window.
Worked example
A community pulse labels an IP as command infrastructure, but current registration and Geo-IP place it in a shared cloud range.
- OTX pulse: report is 14 months old
- Abuse reports: none in the past 90 days
- Local EDR: one unsigned process contacted a rare path on that IP
The old reputation is weak current evidence, while the process and rare path justify a host-focused investigation without attributing the cloud tenant.
Preserve platform provenance, investigate the local process and request path, and avoid a provider-wide block unless scoped evidence supports it.
Reasoning self-check
A community pulse labels an IP as command infrastructure, but current registration and Geo-IP place it in a shared cloud range.
- OTX pulse: report is 14 months old
- Abuse reports: none in the past 90 days
- Local EDR: one unsigned process contacted a rare path on that IP
- Classify each supplied fact by the concept it supports and record what it does not establish.
- Choose the least disruptive authorized action that tests the leading explanation.
- Write the observable result that would confirm success and one result that would reopen the investigation.
Compare your reasoning
Expected answers
- Preserve platform provenance, investigate the local process and request path, and avoid a provider-wide block unless scoped evidence supports it.
- The old reputation is weak current evidence, while the process and rare path justify a host-focused investigation without attributing the cloud tenant.
If you got stuck
- If two explanations remain possible, request the smallest missing evidence source.
- Do not convert a tool label, score, or absence of data into proof.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 7
Required for course progress · Pass with 2 of 2 correct
Block 8 of 18Combine endpoint, file, and sandbox evidence
Practice saved9 min
Combine endpoint, file, and sandbox evidence
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Combine endpoint, file, and sandbox evidence
By the end, you can
- Explain and apply endpoint control and detection.
- Explain and apply static file analysis.
- Explain and apply sandbox analysis.
EDR observes and can respond on endpoints, XDR correlates across multiple security domains, and MDM manages device posture; their coverage and authority differ. Strings reveal readable content, VirusTotal-style services provide multi-source reputation, and YARA matches defined byte/text conditions. A sandbox observes one sample in one environment, so environment-aware malware can behave differently.
Static analysis preserves a file hash, strings, metadata, and exact YARA rule and condition so another analyst can reproduce the lead without executing the sample. Joe Sandbox or Cuckoo-style dynamic analysis also needs the image, network mode, duration, inputs, observed process/file/network behavior, and cleanup record. A quiet run is bounded negative evidence, not proof that the file is safe.
Worked example
A finance attachment has no reputation hits, matches a narrow YARA rule, stays quiet in a sandbox, and is followed by a UEBA alert on its recipient.
- Strings: PowerShell fragment references invoice directory
- Sandbox: no child process in five minutes
- EDR/XDR: recipient later launches the fragment; UEBA marks a new data-access pattern
No reputation and a quiet sandbox do not clear the file; YARA plus later endpoint behavior and access deviation justify containment and scoping.
Contain the endpoint session, preserve the file and headers, validate the YARA condition, and scope the behavior across XDR data without uploading confidential content.
Reasoning self-check
A finance attachment has no reputation hits, matches a narrow YARA rule, stays quiet in a sandbox, and is followed by a UEBA alert on its recipient.
- Strings: PowerShell fragment references invoice directory
- Sandbox: no child process in five minutes
- EDR/XDR: recipient later launches the fragment; UEBA marks a new data-access pattern
- Classify each supplied fact by the concept it supports and record what it does not establish.
- Choose the least disruptive authorized action that tests the leading explanation.
- Write the observable result that would confirm success and one result that would reopen the investigation.
Compare your reasoning
Expected answers
- Contain the endpoint session, preserve the file and headers, validate the YARA condition, and scope the behavior across XDR data without uploading confidential content.
- No reputation and a quiet sandbox do not clear the file; YARA plus later endpoint behavior and access deviation justify containment and scoping.
If you got stuck
- If two explanations remain possible, request the smallest missing evidence source.
- Do not convert a tool label, score, or absence of data into proof.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 8
Required for course progress · Pass with 3 of 3 correct
Block 9 of 18Validate email paths and behavior baselines
Practice saved8 min
Validate email paths and behavior baselines
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Validate email paths and behavior baselines
By the end, you can
- Explain and apply email infrastructure analysis.
- Explain and apply behavior-analytics baseline.
Mail-analysis services can validate DNS, sending infrastructure, and authentication configuration, but a display name or one lookup cannot authenticate a message. Preserve full headers and compare relay order, envelope identities, SPF/DKIM/DMARC results, and the expected business workflow before concluding spoofing or compromise.
UEBA compares an entity with its own history, peers, or a learned population. The model features and time window matter: shared accounts, sparse history, job changes, and seasonal work can create deviations. Treat a score as a triage lead, then corroborate it with identity, endpoint, and resource evidence before tuning or response.
Worked example
A service account sends an invoice message through an unexpected relay, then receives a high anomaly score during a documented month-end job.
- Header: alignment fails and relay IP is outside the approved mail route
- UEBA: login hour is rare over 30 days
- Change record: month-end job was approved, but sending mail was not
The mail route supports an unauthorized-message hypothesis; the login-hour anomaly is explained partly by approved work and needs separate corroboration.
Preserve headers and DNS results, verify the account's mail permission and relay activity, and tune the behavior model only after comparing approved month-end history.
Reasoning self-check
A service account sends an invoice message through an unexpected relay, then receives a high anomaly score during a documented month-end job.
- Header: alignment fails and relay IP is outside the approved mail route
- UEBA: login hour is rare over 30 days
- Change record: month-end job was approved, but sending mail was not
- Classify each supplied fact by the concept it supports and record what it does not establish.
- Choose the least disruptive authorized action that tests the leading explanation.
- Write the observable result that would confirm success and one result that would reopen the investigation.
Compare your reasoning
Expected answers
- Preserve headers and DNS results, verify the account's mail permission and relay activity, and tune the behavior model only after comparing approved month-end history.
- The mail route supports an unauthorized-message hypothesis; the login-hour anomaly is explained partly by approved work and needs separate corroboration.
If you got stuck
- If two explanations remain possible, request the smallest missing evidence source.
- Do not convert a tool label, score, or absence of data into proof.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 9
Required for course progress · Pass with 2 of 2 correct
Block 10 of 18Interpret CyberChef, Wireshark, tcpdump, Snort output
Practice saved11 min
Interpret CyberChef, Wireshark, tcpdump, Snort output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret CyberChef, Wireshark, tcpdump, Snort output
By the end, you can
- Interpret a sanitized CyberChef result without overstating it.
- Interpret a sanitized Wireshark result without overstating it.
- Interpret a sanitized tcpdump result without overstating it.
- Interpret a sanitized Snort result without overstating it.
CyberChef: Read the recipe from top to bottom and compare Input with Output. 'From Base64' is a reversible decoding operation; it supplies neither a key nor an authenticity check. Wireshark: The display filter retains initial SYN packets and excludes SYN-ACK packets. Clear the filter or follow the TCP stream before deciding that replies are absent from the capture. tcpdump: Flags [S] is an initial TCP SYN. The footer's 'dropped by kernel' count describes capture loss, not packets blocked by a firewall. Snort: The bracketed values are generator ID, signature ID, and revision; the classification labels the rule. An alert line does not say that inline blocking occurred.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- Input: VXNlcj1hbGljZTtSb2xlPXJlYWRlcg== | Recipe: From Base64 | Output: User=alice;Role=reader
- Filter: tcp.flags.syn==1 && tcp.flags.ack==0 | Rows: 10.0.5.22 -> 10.0.8.10 TCP 51514 > 443 [SYN], repeated 6 times; no SYN-ACK shown
- 14:22:01 IP 10.0.5.22.51514 > 10.0.8.10.443: Flags [S], seq 40, win 64240; footer: 18 packets captured, 7 dropped by kernel
- [1:900001:2] LAB Possible admin URI [Classification: Web Application Attack] {TCP} 10.0.5.22:51514 -> 10.0.8.10:8080
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- Input: 25504446 | Recipe: From Hex | Output begins: %PDF
- Filter cleared | 10.0.5.37 -> 10.0.8.24 [SYN]; reverse [SYN, ACK]; forward [ACK]
- 14:25:00 IP 10.0.5.37.52000 > 10.0.8.24.443: Flags [S]; reverse Flags [R.]; footer: 2 captured, 0 dropped
- [1:900001:2] LAB Possible admin URI {TCP} 10.0.5.37 -> 10.0.8.24 | action: block
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- CyberChef: The hex operation identifies a PDF file signature; it still does not authenticate or decrypt the file. Why: The operation and resulting file signature differ from the Base64 text example.
- Wireshark: The visible three-way handshake supports a completed TCP connection, unlike the SYN-only filtered view. Why: Clearing the filter exposes the reply and final acknowledgement.
- tcpdump: The observed reset shows the destination rejected this attempt, and zero capture drops strengthens this bounded trace. Why: A reset and complete capture replace the loss-limited SYN-only case.
- Snort: The rule matched and this inline record reports a block; it still does not prove compromise. Why: The exercise explicitly supplies enforcement evidence absent from the alert-only example.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 10
Required for course progress · Pass with 3 of 4 correct
Block 11 of 18Interpret Suricata, Zeek, SIEM, OTX output
Practice saved11 min
Interpret Suricata, Zeek, SIEM, OTX output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret Suricata, Zeek, SIEM, OTX output
By the end, you can
- Interpret a sanitized Suricata result without overstating it.
- Interpret a sanitized Zeek result without overstating it.
- Interpret a sanitized SIEM result without overstating it.
- Interpret a sanitized OTX result without overstating it.
Suricata: In EVE JSON, event_type says this is an alert and alert.action records the enforcement result. action=allowed means the matching flow was not blocked by this event. Zeek: conn_state summarizes the TCP exchange Zeek saw: S0 is a connection attempt with no reply, REJ is an attempt that was rejected, and SF is normal establishment and termination. A retransmitted SYN gives an S0 row a duration of seconds. orig_bytes and resp_bytes count payload bytes in each direction and say nothing about maliciousness. SIEM: Treat the rule window, event count, and entities as a correlation summary. Open the six underlying events before attributing the successful sign-in. OTX: pulses counts community collections containing the indicator; validation and modified carry different meanings. Neither field counts attacks against this organization.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- {"event_type":"alert","src_ip":"10.0.5.22","dest_port":8080,"alert":{"signature_id":900001,"action":"allowed"}}
- conn.log: id.orig_h=10.0.5.22 id.resp_h=10.0.8.10 id.resp_p=443 proto=tcp duration=3.0 orig_bytes=0 resp_bytes=0 conn_state=S0 orig_pkts=2 resp_pkts=0
- Rule: 5 failed sign-ins then success | Entities: user=lab-reader, IP=203.0.113.19 | Events: 6 | Window: 8m
- Indicator 198.51.100.44 | pulses=2 | validation=[] | modified=2026-08-10
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- {"event_type":"alert","alert":{"signature_id":900001,"action":"blocked"}}
- conn.log: orig_h=10.0.5.37 resp_h=10.0.8.24 resp_p=443 duration=4.2 orig_bytes=540 resp_bytes=8120 conn_state=SF
- Rule window expired | 5 failures at 09:00; success at 11:40 from managed device | events grouped=5, success ungrouped
- Indicator 203.0.113.88 | pulses=0 | validation=[whitelisted] | modified=2026-09-29
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- Suricata: The signature matched and action=blocked records that this rule dropped (IPS mode) or rejected the traffic; it is not necessarily the flow's final verdict. Why: The decisive action changes from allowed to blocked.
- Zeek: SF with bytes in both directions supports a normally established and closed TCP session. Why: Connection state and byte counts change from unanswered S0 to a completed flow.
- SIEM: The success falls outside this correlation window and needs separate context rather than attribution to the failure cluster. Why: Timing changes whether the rule links the success.
- OTX: No pulse membership plus a whitelist validation lowers this source's suspicion, though local evidence can override reputation. Why: Community context changes from two pulse memberships to an explicit validation.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 11
Required for course progress · Pass with 3 of 4 correct
Block 12 of 18Interpret MISP, OpenCTI, EDR, XDR output
Practice saved11 min
Interpret MISP, OpenCTI, EDR, XDR output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret MISP, OpenCTI, EDR, XDR output
By the end, you can
- Interpret a sanitized MISP result without overstating it.
- Interpret a sanitized OpenCTI result without overstating it.
- Interpret a sanitized EDR result without overstating it.
- Interpret a sanitized XDR result without overstating it.
MISP: to_ids marks an attribute as suitable for detection-system export; it does not deploy a block. Correlations are linked attributes/events, and TLP governs sharing. OpenCTI: An observable stores a fact such as an IP value. An indicator adds a detection pattern, confidence expresses producer confidence, and valid_until bounds intended use. EDR: Read FileName with InitiatingProcessFileName to reconstruct parent-child lineage. ProcessCommandLine records the launch string; AccountName is execution context, not proof of who typed it. XDR: An incident groups alerts using shared entities and logic across security domains. status=Active is workflow state; it does not report host isolation or validate every alert.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- event=742 attribute=domain|ip portal.example|198.51.100.44 to_ids=true tags=[tlp:amber] correlations=3
- Observable: ipv4-addr 198.51.100.44 | Indicator: [ipv4-addr:value='198.51.100.44'] | confidence=55 | valid_until=2026-10-15
- DeviceProcessEvents: FileName=powershell.exe InitiatingProcessFileName=winword.exe ProcessCommandLine='powershell -enc <redacted>' AccountName=labuser
- Incident 218: endpoint alert + identity alert + cloud-app alert | entities: LAB-22, labuser | status=Active
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- event=751 attribute=domain training.example to_ids=false tags=[tlp:clear] correlations=0
- Observable: ipv4-addr 203.0.113.88 | no linked Indicator | first_observed=2026-09-30
- FileName=powershell.exe | InitiatingProcessFileName=management-agent.exe | CommandLine='powershell -File signed-inventory.ps1' | Signature=Valid
- Incident 219 | endpoint alert=FalsePositive | identity alert=Resolved | cloud alert=Informational | status=Resolved
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- MISP: This attribute is not marked for IDS export, has no listed correlations, and is shareable under TLP:CLEAR. Why: Detection suitability, correlation, and sharing fields all change.
- OpenCTI: The platform records an observed IP fact without a detection pattern or maliciousness assertion. Why: The indicator, confidence, and validity fields are absent.
- EDR: Managed parentage, a named script, and a valid signature support an administrative hypothesis that still needs authorization context. Why: The parent and command change from an encoded document-child process to a transparent managed task.
- XDR: The incident's component dispositions and resolved workflow state support closure after evidence review. Why: Alert dispositions replace the unresolved Active grouping.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 12
Required for course progress · Pass with 3 of 4 correct
Block 13 of 18Interpret MDM, WHOIS, AbuseIPDB, Geo-IP output
Practice saved11 min
Interpret MDM, WHOIS, AbuseIPDB, Geo-IP output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret MDM, WHOIS, AbuseIPDB, Geo-IP output
By the end, you can
- Interpret a sanitized MDM result without overstating it.
- Interpret a sanitized WHOIS result without overstating it.
- Interpret a sanitized AbuseIPDB result without overstating it.
- Interpret a sanitized Geo-IP result without overstating it.
MDM: compliance, reason, and lastCheckIn belong together. The record says which policy failed at the last evaluation, not whether malware exists now. WHOIS: Created is registration time, Registrar is the registration provider, and privacy-redacted registrant data is simply unavailable. None identifies hosting or first abuse. AbuseIPDB: abuseConfidenceScore is AbuseIPDB's confidence measure and totalReports counts submitted reports. These are community reputation fields rather than a malware percentage or breach count. Geo-IP: country and city are estimates; accuracy_radius communicates geographic uncertainty. The record locates an IP allocation approximately, not a person or device precisely.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- Device LAB-PHONE-7 | compliance=Noncompliant | reason=OS version below minimum | lastCheckIn=2026-09-30T13:10Z
- Domain: login-lab.example | Created: 2026-09-28 | Registrar: Example Registrar | Registrant: REDACTED FOR PRIVACY
- ipAddress=198.51.100.44 abuseConfidenceScore=62 totalReports=9 lastReportedAt=2026-09-29
- IP 198.51.100.44 | country=US | city=Riverton | accuracy_radius=100km
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- Device LAB-PHONE-7 | compliance=Compliant | OS meets minimum | lastCheckIn=2026-09-30T15:02Z
- Domain: training.example | Created: 2012-04-10 | Registrar: Example Registrar | Registrant organization: Example Training Org
- ipAddress=203.0.113.88 abuseConfidenceScore=0 totalReports=0 lastReportedAt=null
- IP 203.0.113.88 | country=US | city=null | accuracy_radius=1000km
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- MDM: A fresh evaluation reports the device meets the stated compliance policy; this still is not a malware verdict. Why: Fresh compliant state supersedes the stale failed OS evaluation.
- WHOIS: Long registration age and visible organization reduce the specific new-domain concern but do not prove benign content. Why: Registration age and disclosure differ from the recent privacy-redacted case.
- AbuseIPDB: This service has no reports or confidence signal for the address; absence of reports is not proof of safety. Why: The reputation service returns no adverse community evidence.
- Geo-IP: Only broad country-level context is supportable; no city or precise location should be inferred. Why: The missing city and much wider radius reduce location precision.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 13
Required for course progress · Pass with 3 of 4 correct
Block 14 of 18Interpret strings, VirusTotal, YARA, Joe Sandbox output
Practice saved11 min
Interpret strings, VirusTotal, YARA, Joe Sandbox output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret strings, VirusTotal, YARA, Joe Sandbox output
By the end, you can
- Interpret a sanitized strings result without overstating it.
- Interpret a sanitized VirusTotal result without overstating it.
- Interpret a sanitized YARA result without overstating it.
- Interpret a sanitized Joe Sandbox result without overstating it.
strings: strings extracts printable byte sequences from a file. A printed URL is a triage lead; only execution or network evidence can show that the program used it. VirusTotal: last_analysis_stats counts vendor classifications at last_analysis_date. 'undetected' means no detection from those engines at that time, not a clean-file proof. YARA: The output names the matching rule, string identifiers, and offsets. The condition explains why the rule matched; it does not record execution or authorship. Joe Sandbox: Start with concrete Behavior and Network observations, then use the verdict score as a summary. A single sandbox environment may miss gated or evasive behavior.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- Command: strings -n 8 sample.bin | Output: update-check; hxxps://portal.example/a; Content-Type
- sha256=<labhash> last_analysis_stats={malicious:3,suspicious:1,undetected:66} last_analysis_date=1780000000
- Rule Lab_Dropper matched sample.bin | $mz at 0x0 | $uri at 0x2a10 | condition: $mz and $uri
- Verdict: suspicious 62/100 | Behavior: creates Run key | Network: DNS portal.example | Environment: Windows 11 lab
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- Command: strings -n 8 sample.bin | Output: This program cannot be run in DOS mode
- sha256=<labhash2> last_analysis_stats={malicious:0,suspicious:0,undetected:70} last_analysis_date=1780005000
- Rule Lab_Dropper did not match sample2.bin | $mz at 0x0 | $uri absent | condition: $mz and $uri
- Verdict: clean 5/100 | Behavior: no persistence observed | Network: none | Environment: Windows 11 lab
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- strings: The generic executable string supplies file-format context but no URL or behavior lead. Why: The suspicious URL and protocol text are absent.
- VirusTotal: No vendors classified this hash at that time, which is an absence of detections rather than proof the file is clean. Why: The vendor classification counts change to zero detections.
- YARA: The missing required $uri string makes the AND condition false, so this rule does not match this sample. Why: One required string is absent, changing the rule result.
- Joe Sandbox: This run observed no listed persistence or network behavior; evasion and environment limits still prevent a universal clean claim. Why: Concrete behaviors and the summary differ from the suspicious run.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 14
Required for course progress · Pass with 3 of 4 correct
Block 15 of 18Interpret Cuckoo Sandbox, Regular expressions, Suspicious commands, MXToolbox output
Practice saved11 min
Interpret Cuckoo Sandbox, Regular expressions, Suspicious commands, MXToolbox output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret Cuckoo Sandbox, Regular expressions, Suspicious commands, MXToolbox output
By the end, you can
- Interpret a sanitized Cuckoo Sandbox result without overstating it.
- Interpret a sanitized Regular expressions result without overstating it.
- Interpret a sanitized Suspicious commands result without overstating it.
- Interpret a sanitized MXToolbox result without overstating it.
Cuckoo Sandbox: behavior.processes, network.dns, and signatures are observations from this run. info.score summarizes them but is neither CVSS nor proof of successful compromise. Regular expressions: The word boundaries constrain tokens and the alternation matches two encoded-command flags. A regex selects text; it neither decodes the payload nor decides intent. Suspicious commands: Combine parent process, command switches, and child network behavior. -NoP and -EncodedCommand are suspicious context, while the sequence provides the useful lead. MXToolbox: Read each authentication result and every Received hop from the original header. SPF checks the sending server, DKIM checks a signature, and DMARC passes only when one of them passes and aligns with the From domain. None of them reports attachment execution.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- info.score=6.2 | behavior.processes=[invoice.exe, powershell.exe] | network.dns=[portal.example] | signatures=[creates_autorun]
- Pattern: (?i)\bpowershell(?:\.exe)?\b.*(?:-enc|-encodedcommand)\b | Match: powershell.exe -enc SQBFAFgA | Nonmatch: powershell documentation
- Parent=winword.exe | Command=powershell.exe -NoP -EncodedCommand <redacted> | Network child connects 198.51.100.44:443
- From=payroll.example | SPF=fail | DKIM=none | DMARC=fail | Received: unknown-host -> lab-mx
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- info.score=1.0 | behavior.processes=[invoice.exe] | network.dns=[] | signatures=[]
- Pattern: (?i)\bpowershell(?:\.exe)?\b.*(?:-enc|-encodedcommand)\b | Text: powershell documentation | Result: no match
- Parent=management-agent.exe | Command=powershell.exe -File signed-inventory.ps1 | Signature=Valid | Network child=none
- From=payroll.example | SPF=pass | DKIM=pass | DMARC=pass | Received: approved-relay -> lab-mx
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- Cuckoo Sandbox: This run records only the sample process and no listed DNS or signatures; it may justify lower priority, not proof of safety. Why: The child process, DNS, and autorun signature are absent.
- Regular expressions: The benign phrase correctly fails because it lacks an encoded-command flag. Why: This is the negative sample the boundaries and required flag are meant to exclude.
- Suspicious commands: The transparent signed inventory task and managed parent support likely administration; verify authorization before closing. Why: Obfuscation and follow-on network behavior are absent.
- MXToolbox: Passing SPF, DKIM, and DMARC through the expected relay support sender authenticity, while message content still requires normal review. Why: All authentication results and the path change from failure to expected.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 15
Required for course progress · Pass with 3 of 4 correct
Block 16 of 18Interpret UEBA, OpenUBA, JSON, XML output
Practice saved10 min
Interpret UEBA, OpenUBA, JSON, XML output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret UEBA, OpenUBA, JSON, XML output
By the end, you can
- Interpret a sanitized UEBA result without overstating it.
- Interpret a sanitized OpenUBA result without overstating it.
- Interpret a sanitized JSON result without overstating it.
- Interpret a sanitized XML result without overstating it.
UEBA: entity, anomaly feature, peer group, and score explain why activity differs from a learned baseline. The score ranks deviation and is not a compromise probability. OpenUBA: model identifies the analytic, observed_hour is the event feature, and baseline_hours is learned history. anomaly_score measures model deviation rather than exploit likelihood. JSON: Braces contain an object, brackets an array, and unquoted false is Boolean. Syntax validity says nothing about source authenticity. XML: The root event element has a source attribute and user/result child elements. Well-formed XML obeys syntax but may still lack schema validation or trust.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- Entity=svc-report | anomaly=Rare login time | score=0.81 | peers=service accounts | evidence=02:03 login
- model=login_hour_v1 entity=svc-report observed_hour=2 baseline_hours=[8,9,10] anomaly_score=0.79
- {"event":"login","success":false,"ports":[443,8443]} | Parser: valid object
- <event source="vpn"><user>lab</user><result>deny</result></event> | Parser: well-formed
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- Entity=svc-audit | anomaly=None | score=0.08 | evidence=09:03 login | approved schedule=09:00
- model=login_hour_v1 entity=svc-audit observed_hour=9 baseline_hours=[8,9,10] anomaly_score=0.05
- {"event":"login","success":"false","ports":"443,8443"} | Parser: valid object
- <event source="vpn"><user>lab</event> | Parser: not well-formed: mismatched tag
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- UEBA: The event aligns with learned and approved timing and has a low deviation score, so this model supplies little anomaly evidence. Why: The feature and score no longer show rare behavior.
- OpenUBA: The observed hour sits inside the learned baseline and the model reports low deviation. Why: The observed feature moves into baseline hours.
- JSON: Both values are strings in this variant; consumers must not treat them as a Boolean and numeric array. Why: Quotes change the data types while syntax remains valid.
- XML: The mismatched closing tag prevents XML parsing; no element interpretation should proceed until corrected. Why: The document changes from well-formed to a structural parse error.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 16
Required for course progress · Pass with 3 of 4 correct
Block 17 of 18Interpret YAML, EVTX, Python, PowerShell output
Practice saved11 min
Interpret YAML, EVTX, Python, PowerShell output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret YAML, EVTX, Python, PowerShell output
By the end, you can
- Interpret a sanitized YAML result without overstating it.
- Interpret a sanitized EVTX result without overstating it.
- Interpret a sanitized Python result without overstating it.
- Interpret a sanitized PowerShell result without overstating it.
YAML: Indentation nests values, hyphens introduce sequence items, and false is a Boolean scalar here. Parsing structure does not verify provenance. EVTX: Channel and EventID identify the event class: 4625 is a failed logon and 4624 a successful one. LogonType gives the method, such as 2 interactive, 3 network, and 10 RemoteInteractive (Remote Desktop). On a 4625 for a wrong password, Status is 0xC000006D and SubStatus 0xC000006A refines it; SubStatus 0xC0000064 means the account name does not exist. Correlate with host, time, and account before calling one event an attack pattern. Python: json parsing preserves number types and should surface exceptions. A rejected line is a visibility gap to quarantine and inspect, not evidence to discard silently. PowerShell: ConvertFrom-Json turns JSON members into object properties and Select-Object chooses displayed properties. Neither cmdlet authenticates the source or contacts the IP.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- event: login success: false tags: - remote - denied | Parser: mapping
- Channel=Security EventID=4625 TimeCreated=2026-09-30T14:22:01Z TargetUserName=lab LogonType=3 Status=0xC000006D SubStatus=0xC000006A
- Input line: {"src":"198.51.100.44","count":3} | Script output: src=198.51.100.44 count=3 | rejected malformed line 7
- Command: $e | ConvertFrom-Json | Select-Object src,count | Output: src=198.51.100.44 count=3
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- event: login success: false | Parser error: mapping values are not allowed here
- Channel=Security EventID=4624 TimeCreated=2026-09-30T15:02:01Z TargetUserName=lab LogonType=2
- Input line: {bad json} | Script output: JSONDecodeError line 1 column 2; record quarantined
- Command: 'not-json' | ConvertFrom-Json | Output: error Invalid JSON primitive
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- YAML: Unexpected indentation makes this document invalid for the parser; do not infer an event structure from it. Why: Indentation changes from a valid mapping to a parser error.
- EVTX: Event 4624 records a successful logon and LogonType 2 is interactive, at the console; it requires context rather than failure-code analysis. Why: The EventID and fields change from failed to successful logon.
- Python: The parser rejected and quarantined malformed input, preserving a visible processing gap for investigation. Why: The exercise tests error handling rather than successful typed parsing.
- PowerShell: Conversion failed, so there are no trustworthy object properties to select or analyze. Why: Malformed input changes successful conversion into an explicit error.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 17
Required for course progress · Pass with 3 of 4 correct
Block 18 of 18Interpret Shell script output
Practice saved6 min
Interpret Shell script output
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Interpret Shell script output
By the end, you can
- Interpret a sanitized Shell script result without overstating it.
Shell script: grep prints matching lines and returns exit status 0 when at least one line was selected, 1 when none was, and 2 on an error. It filters a file; it does not block logins or count attackers.
For these tools, first name the exact field or operation, then translate only that field into a claim. Preserve the raw output and collection scope. Confirm inferred identity, behavior, exposure, prevention, or remediation with another evidence source or a bounded retest.
Worked example
An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.
- Command: grep -E 'status=(fail|deny)' auth.log | Output: 14:22 user=lab status=fail | exit=0
For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.
A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
Reasoning self-check
Review the changed practice cards; they use different fictional entities or collection values from the worked example.
- Command: grep -E 'status=(fail|deny)' auth.log | Output: <none> | exit=1
- Open each evidence card and highlight the field that carries the observation.
- Choose the supported interpretation and explain why each alternative overstates or misreads the output.
- Write one bounded follow-up query or retest using only the fictional lab assets.
Compare your reasoning
Expected answers
- Shell script: Exit 1 means grep selected no lines; confirm the file and pattern scope before claiming no failures exist. Why: The exit status changes from match found to no selection.
- A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.
If you got stuck
- If a score is unfamiliar, read its field definition before ranking it.
- If output is silent, check scope and collection loss before concluding absence.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 18
Required for course progress · Pass with 1 of 1 correct
Review this lesson
Use only this lesson's worked example and key concepts for a quick self-check.
- Restate the worked example in your own words.
- Name the lesson concepts that explain the result.
- Explain why the closest alternative does not fit.
Check the whole objective
This unlocks objective 1.3 for recall. The latest checkpoint needs 70% or higher; a lower result puts the lesson back near the front of your timeline.