CS0-004 · Security Operations

Use analysis tools to evaluate suspicious evidence

Objective 1.3 · Use analysis tools to evaluate suspicious evidence.

18 learning blocksNext unfinished block 1 · about 15 minutes58 key conceptsOriginal practice · Review pending
ProgressNot started0/18 blocks learned and checked
Learn

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.

0/18blocks complete
Your notesPrivate to you
Up to 1,000 characters. Active writing time is recorded; idle time is excluded.
Block 1 of 18

SIEM correlation · Clock skew · Event normalization · Correlation key

Next · 15 min

No 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

This records your study. Passing the check is still required for course progress.
Block 2 of 18

Packet capture · Flow metadata · Process telemetry · Network five-tuple

15 min

No 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

This records your study. Passing the check is still required for course progress.
Block 3 of 18

Correlate logs without losing event identity

8 min

Required 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.

Optional ITForMe notes and practice
Optional ITForMe teaching · about 8 minutes with 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.

Optional support
Worked example
Situation

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.

Evidence
  • 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
Reason it through

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.

Expected result

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.

Optional practice
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
  1. Record a timestamped fact table from the supplied evidence.
  2. Test the two most plausible explanations against every observation.
  3. 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.

Technical references

Required block check · Block 3

Required for course progress · Pass with 2 of 2 correct

Your confirmation records study. Passing the check is still required for course progress.
Block 4 of 18

Choose packet and host evidence for the question

18 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 18 minutes with practice

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.

Optional support
Worked example
Situation

A server has repeated outbound TCP sessions. The analyst must determine which process owns the socket before deciding whether it is expected.

Evidence
  • 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
Reason it through

The connection table bridges the network tuple to PID 4420, and the process record supplies the executable identity.

Expected result

Preserve the three records and validate agent.exe against inventory; do not infer payload content from encrypted flow metadata.

Optional practice
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
  1. Record a timestamped fact table from the supplied evidence.
  2. Test the two most plausible explanations against every observation.
  3. 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.

Hands-on lesson practice

Work through the scenario

Practice simulation

Use the case evidence to complete the tasks, then check objectives.

Practice limits and saved work

Guided practice is optional. You can start required case practice directly; it counts toward the readiness checklist. Neither exercise completes the lesson or its checkpoint. Checks evaluate the supplied scenario and modeled configuration, not live systems or traffic. Work is saved in this browser session. Human technical review is pending.

Optional guided practice

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
Objectives
  1. Interpret the supplied evidence without overclaimingpending
  2. Choose the bounded evidence-supported actionpending
  3. Select evidence that verifies security and operational outcomepending
CySA+ defensive evidence workbench
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.

Read full options
  • Treat one isolated clue as conclusive without correlation.
  • Assume missing telemetry proves the activity did not occur.
  • Regular unapproved queries support a beacon hypothesis but do not identify payload content.
Read full options
  • Pivot to the initiating process and domain history before containment.
  • Apply an organization-wide disruptive change beyond the stated scope.
  • Close the case without retaining the supplied evidence.
Read full options
  • Declare success without retesting the affected behavior.
  • Process telemetry ties the queries to a binary and domain history confirms disposition.
  • Confirm only that a configuration value was entered.

Fictional, disposable SOC evidence. No production system or external service is contacted.

Report an issue with this exercise

Your report is private to you and the review team because lesson exercises can contain answers.

Required case practice

Required for the readiness checklist · Pass at 100%

Required case practice

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
Objectives
  1. Interpret the supplied evidence without overclaimingpending
  2. Choose the bounded evidence-supported actionpending
  3. Select evidence that verifies security and operational outcomepending
CySA+ defensive evidence workbench
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.

Read full options
  • Treat one isolated clue as conclusive without correlation.
  • Assume missing telemetry proves the activity did not occur.
  • The string can belong to the legitimate session; compromise is not established.
Read full options
  • Apply an organization-wide disruptive change beyond the stated scope.
  • Close the case without retaining the supplied evidence.
  • Preserve the capture and correlate token use, process ancestry, and remote sessions.
Read full options
  • Confirm only that a configuration value was entered.
  • Identity and endpoint queries show whether replay or process injection occurred.
  • Declare success without retesting the affected behavior.

Fictional, disposable SOC evidence. No production system or external service is contacted.

Report an issue with this exercise

Your report is private to you and the review team because lesson exercises can contain answers.

Technical references

Required block check · Block 4

Required for course progress · Pass with 2 of 2 correct

This records your study. Passing the check is still required for course progress.
Block 5 of 18

Parse evidence before automating conclusions

10 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 10 minutes with practice

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.

Optional support
Worked example
Situation

A copied alert contains a Base64 PowerShell argument and a YAML inventory whose unquoted value on becomes a boolean in one parser.

Evidence
  • Original encoded argument retained with SHA-256
  • Decoded command reads one registry path and posts the value
  • Inventory parser changes host label on to true
Reason it through

The reproducible decode reveals suspicious collection and egress; the YAML type conversion is a separate data-quality defect that can mis-scope automation.

Expected result

Preserve the source, record the decode recipe, correct the quoted inventory scalar, and run a read-only parser on a copied fixture.

Optional practice
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 on to true
  1. Classify each supplied fact by the concept it supports and record what it does not establish.
  2. Choose the least disruptive authorized action that tests the leading explanation.
  3. 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.

Technical references

Required block check · Block 5

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 6 of 18

Choose packet, detection, and log tools by evidence need

8 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 8 minutes with practice

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.

Optional support
Worked example
Situation

An IDS alerts on a file signature, Zeek logs an HTTPS session, and the SIEM shows the endpoint event six minutes late.

Evidence
  • 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
Reason it through

The records support one network session and delayed ingestion; the encrypted Zeek record cannot independently confirm file content.

Expected result

Align on event time and five-tuple, retrieve the bounded packet/endpoint evidence, and document the sensor and encryption limits.

Optional practice
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
  1. Classify each supplied fact by the concept it supports and record what it does not establish.
  2. Choose the least disruptive authorized action that tests the leading explanation.
  3. 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.

Technical references

Required block check · Block 6

Required for course progress · Pass with 2 of 2 correct

This records your study. Passing the check is still required for course progress.
Block 7 of 18

Use intelligence and reputation services without outsourcing judgment

8 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 8 minutes with practice

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.

Optional support
Worked example
Situation

A community pulse labels an IP as command infrastructure, but current registration and Geo-IP place it in a shared cloud range.

Evidence
  • 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
Reason it through

The old reputation is weak current evidence, while the process and rare path justify a host-focused investigation without attributing the cloud tenant.

Expected result

Preserve platform provenance, investigate the local process and request path, and avoid a provider-wide block unless scoped evidence supports it.

Optional practice
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
  1. Classify each supplied fact by the concept it supports and record what it does not establish.
  2. Choose the least disruptive authorized action that tests the leading explanation.
  3. 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.

Technical references

Required block check · Block 7

Required for course progress · Pass with 2 of 2 correct

This records your study. Passing the check is still required for course progress.
Block 8 of 18

Combine endpoint, file, and sandbox evidence

9 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 9 minutes with practice

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.

Optional support
Worked example
Situation

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.

Evidence
  • 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
Reason it through

No reputation and a quiet sandbox do not clear the file; YARA plus later endpoint behavior and access deviation justify containment and scoping.

Expected result

Contain the endpoint session, preserve the file and headers, validate the YARA condition, and scope the behavior across XDR data without uploading confidential content.

Optional practice
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
  1. Classify each supplied fact by the concept it supports and record what it does not establish.
  2. Choose the least disruptive authorized action that tests the leading explanation.
  3. 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.

Technical references

Required block check · Block 8

Required for course progress · Pass with 3 of 3 correct

This records your study. Passing the check is still required for course progress.
Block 9 of 18

Validate email paths and behavior baselines

8 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 8 minutes with practice

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.

Optional support
Worked example
Situation

A service account sends an invoice message through an unexpected relay, then receives a high anomaly score during a documented month-end job.

Evidence
  • 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
Reason it through

The mail route supports an unauthorized-message hypothesis; the login-hour anomaly is explained partly by approved work and needs separate corroboration.

Expected result

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.

Optional practice
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
  1. Classify each supplied fact by the concept it supports and record what it does not establish.
  2. Choose the least disruptive authorized action that tests the leading explanation.
  3. 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.

Technical references

Required block check · Block 9

Required for course progress · Pass with 2 of 2 correct

This records your study. Passing the check is still required for course progress.
Block 10 of 18

Interpret CyberChef, Wireshark, tcpdump, Snort output

11 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 11 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • 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
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 10

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 11 of 18

Interpret Suricata, Zeek, SIEM, OTX output

11 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 11 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • {"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
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 11

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 12 of 18

Interpret MISP, OpenCTI, EDR, XDR output

11 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 11 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • 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
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 12

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 13 of 18

Interpret MDM, WHOIS, AbuseIPDB, Geo-IP output

11 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 11 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • 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
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 13

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 14 of 18

Interpret strings, VirusTotal, YARA, Joe Sandbox output

11 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 11 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • 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
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 14

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 15 of 18

Interpret Cuckoo Sandbox, Regular expressions, Suspicious commands, MXToolbox output

11 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 11 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • 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
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 15

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 16 of 18

Interpret UEBA, OpenUBA, JSON, XML output

10 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 10 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • 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
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 16

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 17 of 18

Interpret YAML, EVTX, Python, PowerShell output

11 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 11 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • 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
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 17

Required for course progress · Pass with 3 of 4 correct

This records your study. Passing the check is still required for course progress.
Block 18 of 18

Interpret Shell script output

6 min

No provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.

Required ITForMe lesson
Concept brief · about 6 minutes with practice

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.

Optional support
Worked example
Situation

An analyst receives four sanitized outputs during an authorized objective 1.3 browser lab.

Evidence
  • Command: grep -E 'status=(fail|deny)' auth.log | Output: 14:22 user=lab status=fail | exit=0
Reason it through

For each artifact, identify the observation first, then separate an alert, match, score, or state from unsupported claims about compromise, attribution, prevention, or remediation.

Expected result

A complete answer names the decisive field, gives the narrow supported conclusion, and records one limitation or follow-up validation.

Optional practice
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
  1. Open each evidence card and highlight the field that carries the observation.
  2. Choose the supported interpretation and explain why each alternative overstates or misreads the output.
  3. 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.

Technical references

Required block check · Block 18

Required for course progress · Pass with 1 of 1 correct

This records your study. Passing the check is still required for course progress.
Optional recap

Review this lesson

Use only this lesson's worked example and key concepts for a quick self-check.

  1. Restate the worked example in your own words.
  2. Name the lesson concepts that explain the result.
  3. Explain why the closest alternative does not fit.
Your next milestone

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.

Complete the lesson checks first.A score of 70% or higher advances the course. Today shows the remaining requirements for your daily goal.
Official blueprint references
CompTIA CySA+ CS0-004 V4 exam objectives, version 2.0CompTIA ↗CompTIA CySA+ V4 official exam overview and parent objectivesCompTIA ↗
Report an issue with this lesson

Your report is private to you and the review team because lesson exercises can contain answers.