I85PREP
⌘ K
CFR-410 study materials
CFR-410 study resources

CFR-410: Analyze: Logs, Monitoring, Threat Analysis, and Forensics

CFR-410 · Work through your exam, one topic at a time.

All guide sections

Analyze: Logs, Monitoring, Threat Analysis, and Forensics

Domain 2 - Analyze

The Analyze domain tests whether you can turn raw telemetry into a defensible finding: which log source holds the answer, what normal looks like, and how to preserve and interpret evidence so the conclusion survives scrutiny.

Log sources that matter most

  • Windows Security log: 4624 successful logon (Type 2 interactive, 3 network, 10 RemoteInteractive/RDP, 5 service), 4625 failure, 4672 special privileges assigned, 4688 process creation (command line only if auditing is enabled), 4697 and 7045 service installation, 4720 account created, 4768/4769 Kerberos ticket requests.
  • Sysmon: 1 process create (with hashes and parent), 3 network connect, 7 image load, 8 CreateRemoteThread, 10 process access, 11 file create, 13 registry set, 22 DNS query. Events 8 and 10 are your injection and credential-dumping signals.
  • Linux: /var/log/auth.log or /var/log/secure for SSH and sudo, journald, cron logs, and shell history (never sufficient alone).
  • Network: firewall, proxy, DNS, flow records, and packet capture where available.

Active monitoring and threat analysis

Detection logic should target behaviors (indicators of attack) rather than only atomic indicators, because hashes, addresses, and domains are trivial for an attacker to change. Baseline first: normal parent-child process relationships, normal service accounts, normal beacon intervals. Correlate across sources - a single alert is a hypothesis until two independent logs agree.

Digital forensics fundamentals

  • Order of volatility: processor state and memory first, then network connections, then disk, then remote and archived logs. Memory capture preserves encryption keys, injected code, and live connections that vanish at shutdown.
  • Integrity: image through a write blocker, hash before and after (SHA-256), record the hash in the chain-of-custody documentation, and analyze only copies.
  • Timeline: normalize everything to UTC, then correlate filesystem MACB times, event logs, and network records. On NTFS, compare $STANDARD_INFORMATION against $FILE_NAME timestamps and the $UsnJrnl; timestomping typically shows SI values older than FN values.
  • Corroborate: Prefetch, Amcache, Shimcache, SRUM, UserAssist, and browser artifacts separately establish executed, existed, and was used. None alone proves intent.

Worked example

Security logs show 4625 Type 3 forty times for svc_backup from one workstation within two minutes, then 4624 Type 3, then 4688 launching cmd.exe /c powershell -enc <base64>, then 4624 Type 10 from the same address. Reasoning: password guessing succeeded, the encoded PowerShell is execution, and the Type 10 logon is RDP lateral movement. The base64 decodes to a download cradle, so the next investigative step is DNS and proxy egress at that timestamp - that is where the payload was fetched from.

Traps

Assuming 4624 alone proves interactive use; forgetting that 4688 command lines require policy enablement; trusting file timestamps without checking for timestomping; mixing local and UTC times in one timeline; and hashing the original disk instead of the acquired image.