CCOA (ISACA) cheat sheet

Full-packet capture (PCAP) retains headers and payload; flow records (NetFlow/IPFIX, Zeek conn.log) retain 5-tuple, byte/packet counts, timestamps, and TCP flags but no payload - payload-based detections require PCAP or proxy/Zeek logs.

TCP flag signatures: SYN-only bursts to many destinations = scan; SYN then RST from target = closed port; RST after data transfer = mid-stream teardown; excessive retransmissions suggest loss, evasion, or a spoofed source.

Beaconing detection: low jitter in connection intervals, consistent byte ratios (outbound/inbound), repeated SNI or URI paths, and periodic DNS lookups at fixed intervals are stronger signals than any single connection.

DNS tunneling indicators: high volume of TXT/NULL/AAAA queries to one domain, long subdomain labels (encoded data), high entropy in query names, and unusually large response sizes relative to query size.

JA3/JA3S and JA4 fingerprints hash TLS ClientHello/ServerHello parameters - a match identifies client tooling even when SNI is randomized or absent; pivot on fingerprint across all flows.

Encrypted traffic triage without decryption: SNI field, certificate subject/issuer, server certificate self-signing, TLS version/cipher anomalies, and flow timing/volume give detection value even when payload is opaque.

HTTP detections: rare or newly registered User-Agent strings, POST bodies to bare IPs or unusual ports, mismatched Host header vs. SNI, and large outbound uploads with 200 responses to a single URI.

Zeek/Suricata rule logic: Suricata signatures match on header (5-tuple, direction) then sticky buffers (http.uri, dns.query, tls.sni); signature hits are alerts, not proof - corroborate with flow context before escalation.

Process lineage is the primary triage artifact: office suite spawning cmd.exe/powershell.exe, wscript.exe spawning mshta.exe, or lsass.exe with a non-system parent are high-fidelity parent-child anomalies.

Windows process integrity levels and user context: a SYSTEM-context process launched from a user-writable directory (AppData, Temp, ProgramData, Public) is a strong persistence or execution indicator.

Command-line telemetry (Event ID 4688 with command-line auditing, or Sysmon Event ID 1) is required to distinguish benign admin tooling from abuse of the same binary - living-off-the-land binaries (certutil, mshta, regsvr32, rundll32, bitsadmin) are judged by arguments.

Sysmon event mapping: 1 process create, 3 network connect, 7 image load, 8 CreateRemoteThread, 10 process access, 11 file create, 12/13/14 registry, 22 DNS query, 23 file delete.

LSASS access detection: Sysmon Event ID 10 with GrantedAccess masks such as 0x1010 or 0x1410 and a calling process outside the OS indicates credential dumping; corroborate with Event ID 4656/4663 and service or driver creation.

Persistence locations to check: Run/RunOnce keys, Services, Scheduled Tasks (Event ID 4698), WMI subscriptions, Winlogon Shell/Userinit, IFEO debugger values, startup folders, and on Linux systemd units, cron, .bashrc, and LD_PRELOAD.

Linux host triage: compare ps output against /proc for hidden processes, check /proc//exe for deleted binaries (memfd or unlinked exec), inspect /etc/ld.so.preload, and review auth.log for sudo/SSH anomalies.

File and memory artifacts: hash files (MD5/SHA-256) for enrichment, check digital signatures and signer, extract strings and PE imports for capability hints, and use memory analysis for injected code not present on disk.

Windows authentication: 4624 success (Logon Type 2 interactive, 3 network, 10 RDP, 5 service), 4625 failure, 4634/4647 logoff, 4648 explicit credentials, 4672 special privileges assigned - 4624 Type 3 followed by 4672 on a server is a lateral-movement pattern.

Account and group changes: 4720 account created, 4722 enabled, 4724 password reset, 4726 deleted, 4732 member added to a security-enabled local group, 4756 universal group - 4720+4732 in sequence indicates privilege escalation.

Kerberos events: 4768 TGT requested, 4769 service ticket requested, 4771 pre-auth failure, 4776 NTLM credential validation; 4769 with RC4 (0x17) encryption for many SPNs is a Kerberoasting signal.

Linux auth logs: sshd 'Accepted publickey' vs 'Failed password' patterns, repeated failures from one source followed by success (brute force to compromise), and new UID 0 accounts or sudoers edits indicate escalation.

Correlation design: build rules on entity (user, host, IP) and time window, not single events; a detection needs a defined threshold, a suppression/allowlist, and a documented false-positive rationale.

Log source health matters: a silent host or a gap in ingestion can be an attacker disabling logging (e.g., auditpol changes, Event ID 1102 log cleared) - monitor for the absence of expected events.

Normalization: map vendor fields to a common schema (ECS or OCSF) for user, host, source IP, destination IP, and action so correlation rules survive log source changes.

Timeline reconstruction: sort all sources by UTC timestamp, note clock skew, and pivot on a single entity (IP, hostname, hash, username) to build the incident narrative.

Indicator types and volatility: file hashes are most stable, then domains, then IPs (most volatile due to shared hosting and CDN reuse); an IP match alone is weak evidence.

Confidence vs. severity: confidence reflects source reliability and corroboration, severity reflects potential impact - a high-severity, low-confidence indicator should trigger collection, not immediate containment.

STIX/TAXII and MISP are standard formats/platforms; indicators carry TLP markings (CLEAR, GREEN, AMBER, RED) that govern sharing scope - respect TLP when producing reports.

Enrichment pivots: hash to file reputation and sandbox behavior, domain to passive DNS and WHOIS/registration age, IP to ASN/geo/scanning history, certificate to JA3S and related infrastructure.

False-positive traps: sinkhole and takedown IPs, security-vendor scanners, CDN and cloud shared IPs, and parking pages produce indicator matches with no malicious activity.

Attribution should be evidence-based and hedged; infrastructure overlap and tooling similarity suggest a cluster, not a definitive actor identity - state the confidence level explicitly.

Indicator lifecycle: indicators expire; set a review date, track first/last seen, and retire indicators that no longer resolve or that now point to benign infrastructure.

Triage order: determine scope (how many hosts/users), impact (data, availability, privilege), and whether the activity is ongoing - containment urgency follows from those three, not from alert severity alone.

Severity matrix inputs: affected asset criticality, data sensitivity, attacker privilege level, persistence presence, and business disruption; a low-severity alert on a domain controller escalates above a high-severity alert on a test VM.

Containment options: network isolation, account disable, credential reset, host shutdown (destroys volatile memory - capture memory first if malware is suspected), and blocking indicators at the perimeter.

Escalation triggers: confirmed unauthorized access, ransomware or destructive activity, regulated data exposure, privilege escalation to domain admin, or evidence of an active external C2 channel.

Chain of custody: record who collected each artifact, when, from where, and its hash; store evidence write-protected and maintain a chain-of-custody form for any item that may reach legal or HR review.

Volatile data capture order (RFC 3227): memory and network state first, then running processes, then disk, then remote logs and backups.

Communication: assign a single incident lead, define an update cadence, and separate technical bridge traffic from executive/business updates to avoid conflicting narratives.

Execution chain: dropper or loader (often script-based) → payload written to disk or injected in memory → persistence → C2 establishment → post-exploitation (credential access, lateral movement, exfiltration).

Common injection APIs: VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, QueueUserAPC, and process hollowing via CreateProcess (suspended) + NtUnmapViewOfSection + SetThreadContext + ResumeThread.

Persistence artifacts: Run keys, services, scheduled tasks, WMI event subscriptions, DLL search-order hijacking, COM hijacking, and on Linux systemd units and cron entries.

Ransomware indicators: shadow copy deletion (vssadmin delete shadows, wbadmin), backup service tampering, mass file rename to a common extension, ransom note files, and high-volume file I/O.

Static analysis: PE headers and sections (packed sections with high entropy, unusual entry point), imports (network, crypto, process injection), strings, and embedded URLs or keys - static analysis can be defeated by packing/obfuscation.

Dynamic analysis: run in an isolated sandbox, capture process tree, file/registry/network events, and memory; detonate with a fake internet or INetSim to observe C2 attempts without live exfiltration.

Artifact hashing and naming: SHA-256 for identification, imphash for import-table similarity, and fuzzy hashes (ssdeep/TLSH) for finding variants - record family name only when corroborated by behavior.

Incident report structure: summary, timeline (UTC), affected assets and accounts, indicators, root cause, actions taken, current status, and recommendations - each claim traceable to an evidence source.

Timeline entries: timestamp (UTC), event description, source (log/artifact), and confidence - do not mix observed facts with inference in the same field.

Indicator appendix: type, value, first seen, last seen, confidence, and TLP marking so downstream teams can act on it without re-analysis.

Metrics to report: detection time (alert to analyst), response time (analyst to containment), dwell time (initial compromise to detection), and scope (hosts/users affected) - defined consistently so trends are comparable.

Language discipline: use 'confirmed', 'likely', and 'unconfirmed' to convey confidence; avoid definitive attribution without corroborating evidence.

Evidence references: cite the specific log source, event ID, or artifact hash behind each finding so reviewers can verify; retain raw evidence alongside the report.

Post-incident review: capture what detection worked or failed, update rules and playbooks, and record lessons learned with owners and due dates.