BTL1 study materials
BTL1 study resources

BTL1 cheat sheet

BTL1 · Keep the key ideas within reach.

Quick reference

Phishing Analysis

  • Header order matters: Received lines are prepended by each hop, so read them bottom-up to trace the true originating server; the topmost Received is the last hop before delivery.

  • SPF checks the envelope MAIL FROM domain against DNS TXT records; a pass only authorizes the sending IP, not the visible From header, so SPF pass does not prove the display name is legitimate.

  • DKIM validates a cryptographic signature over specified headers and the body hash, keyed to the d= domain; a valid signature proves integrity and domain signing, not sender intent.

  • DMARC aligns SPF or DKIM with the From header domain and applies policy (none/quarantine/reject) plus reporting via the rua address; alignment failure is the key signal.

  • Reply-To differing from From is a classic impersonation indicator; the recipient's reply goes to an attacker-controlled mailbox while the display name mimics a trusted brand.

  • URL analysis: check for punycode (xn--), lookalike homoglyphs, credential-in-URL tricks (user@host), excessive subdomains, and mismatched anchor text versus href.

  • Attachment red flags: double extensions, macro-enabled Office formats, password-protected archives, LNK/ISO/IMG containers, and HTML smuggling that writes a payload via JavaScript blobs.

  • Defanging conventions for safe handling: hxxp://, [.] and [@] replacements prevent accidental clicks while preserving the indicator for intelligence sharing.

Quick reference

Threat Intelligence

  • The intelligence cycle: direction, collection, processing, analysis, dissemination, and feedback; each stage feeds the next and feedback restarts direction.

  • Pyramid of Pain ranks indicators by attacker cost to change: hashes are trivial, IPs and domains easy, network/host artifacts harder, TTPs hardest, so prioritize TTP-based detection.

  • Indicator types: atomic (IP, hash, domain), computed (ja3, imphash), and behavioral (TTPs); atomic indicators decay fastest and require short TTLs.

  • Diamond Model relates adversary, capability, infrastructure, and victim; pivoting across vertices reveals related activity and supports attribution hypotheses.

  • Confidence versus probability: analytic confidence reflects source reliability and corroboration, while probability estimates likelihood; keep them separate in reporting.

  • TLP markings: RED is limited to named recipients, AMBER to the organization, GREEN to the community, CLEAR is public; marking governs sharing scope, not classification level.

  • MITRE ATT&CK tactics describe why (goal) and techniques describe how; mapping detections to technique IDs enables coverage gap analysis.

  • Indicator hygiene: verify age, first-seen and last-seen dates, and false-positive history before deploying a blocklist; stale indicators generate noise and block legitimate services.

Quick reference

Digital Forensics

  • Order of volatility: CPU registers and cache, RAM, network state, running processes, disk, remote logs, archival media; collect most volatile first.

  • Chain of custody documents who handled evidence, when, and how; a hash (SHA-256) taken at acquisition proves integrity if recomputed later and matched.

  • NTFS artifacts: $MFT records file metadata and timestamps, $UsnJrnl tracks changes, $LogFile journals transactions, and $I30 indexes directory entries including deleted names.

  • Windows registry hives: SYSTEM holds services and timezone, SOFTWARE holds installed applications, SAM holds local accounts, NTUSER.DAT holds per-user activity.

  • Prefetch shows execution count and last-run times; Amcache and ShimCache record program presence and execution traces; SRUM records per-app network and resource usage.

  • Timestomping detection: $STANDARD_INFORMATION timestamps can be altered by user-mode tools, while $FILE_NAME timestamps are harder to change, so mismatches indicate manipulation.

  • Memory forensics: process lists can hide injected or unlinked processes, so cross-check with pool scanning and look for RWX regions and anomalous parent-child relationships.

  • Event log identifiers: 4624 logon, 4625 failed logon, 4634 logoff, 4648 explicit credentials, 4672 special privileges, 4688 process creation, 4720 account created.

Quick reference

Security Information and Event Monitoring (SIEM)

  • Correlation rules combine multiple events within a time window; a threshold rule fires when count exceeds N in T, while a sequence rule requires ordered events.

  • Log source onboarding requires normalization to a common schema (for example ECS or CIM) so fields like user, src_ip, and process_name are consistently searchable.

  • False positive tuning: baseline normal volume, whitelist known-good service accounts and scanners, and tune thresholds rather than disabling rules outright.

  • Sigma is a vendor-neutral detection rule format that converts to SIEM queries; it encodes logsource, detection logic, and false-positive notes.

  • Key Windows fields for detection: EventID, Channel, Computer, SubjectUserName, TargetUserName, Image, CommandLine, ParentImage, and LogonType.

  • LogonType values: 2 interactive, 3 network, 4 batch, 5 service, 7 unlock, 8 network cleartext, 9 new credentials, 10 remote interactive (RDP), 11 cached interactive.

  • Alert triage order: validate the alert is not a duplicate, enrich with asset criticality and threat intel, determine true or false positive, then escalate or close with rationale.

  • Time synchronization matters: uncoordinated clocks across sources break sequence correlation, so verify NTP health before trusting timeline joins.

Quick reference

Incident Response

  • NIST SP 800-61 phases: preparation; detection and analysis; containment, eradication, and recovery; post-incident activity.

  • Containment options: isolate host from network, disable account, block indicator at perimeter, or segment; choose based on blast radius versus evidence preservation needs.

  • Evidence preservation precedes eradication: capture memory and relevant logs before wiping or reimaging, because eradication destroys forensic artifacts.

  • Severity triage factors: data sensitivity, number of affected hosts, business-critical systems, active versus dormant adversary, and regulatory reporting obligations.

  • Communication plan: define incident commander, stakeholder update cadence, and legal/privacy notification triggers; keep a decision log with timestamps.

  • Eradication verifies root cause removal (malicious accounts, persistence, scheduled tasks, services) rather than only deleting the visible payload.

  • Recovery criteria: systems patched, credentials rotated, monitoring in place for re-infection, and validated functionality before returning to production.

  • Lessons learned: document timeline, root cause, detection gaps, and concrete control improvements with owners and due dates; feed findings back into detection engineering.