How to think about an investigation #

The rest of this guide is what to look at. This section is how to reason while you do it: forming hypotheses, choosing which evidence to pull first, and deciding when scoping is done. Use it at the start of an engagement and whenever an investigation stalls.

The universal cognition model

  • Start with a hypothesis, not a toolkit. "I believe the attacker got in via a phished OAuth consent on $user at ~$time." If you can't state one, you're fishing. Hypotheses are cheap - write 2-3 competing ones and let evidence kill them.
  • Make it falsifiable. For each hypothesis, name the single artifact that would disprove it. Looking for refuting evidence is faster than piling up confirming evidence, and it protects you from confirmation bias.
  • Three parallel streams. Attribution ("what happened"), containment ("stop the bleeding"), and recovery ("safe to resume") run concurrently with different clients, different reviewers, different urgency. Don't let one stall the other two.
  • Time-box every thread. If a pivot hasn't produced a lead in 30 minutes, note it and switch. Diminishing returns on any single artifact is real; width of coverage beats depth on one source.
  • Negative evidence counts. "No sign-in log entry from that IP for user X" is as important as a positive hit, but only if you confirmed the log would have captured it. State retention and ingestion lag before you call silence meaningful.
  • Pivot on identities and time, not hostnames. Attackers rotate hosts; identities and when they acted are the durable pivots across endpoint, cloud, and SaaS.
  • "How would I be wrong?" Ask it out loud every 20 minutes. Also: "What's the simplest explanation that fits - insider mistake, misconfig, legitimate automation?" Rule those out before escalating.

Per-platform thinking

Each block below is the shape of the reasoning, not the artifact checklist. Pair with the deep-dives further down.

Windows endpoint

  • Open with: "What ran, who ran it, when, and from where did it get there?"
  • Reason: execution evidence → where the binary came from → how it persisted → what it talked to. If execution is unclear, drop to filesystem metadata and work forward in time.
  • Watch for: timestomped files (metadata lying), ShimCache being treated as execution evidence, "clean" systems where the attacker just lived in LOLBAS.
  • Done when: you can draw the chain from entry → execution → persistence → lateral in one sentence per step.

Linux endpoint

  • Open with: "Did a human or a service account do this, and did they escalate?"
  • Reason: account → shell/session → process tree → persistence. Linux often lacks rich execution logging, so lean on auth history and shell history; corroborate with filesystem mtimes.
  • Watch for: shells that disable history, mount options that erase atime, legitimate admins who look exactly like attackers, hidden LKMs or preload hooks that make tooling lie.
  • Done when: you can account for every privileged shell in the window and distinguish admin baseline from intruder.

macOS endpoint

  • Open with: "Did user intent exist, and did a signed/notarized trust path get subverted?"
  • Reason: code signing / notarization status → persistence surface (launchd, BTM, login items) → user-activity signal → network. macOS is less about volume of artifacts and more about trust posture.
  • Watch for: no wall-clock on FSEvents, Mach-time ordering in the Unified Log, over-trusting TCC prompts as "legitimate consent," ignoring XProtect/MRT silently blocking something upstream.
  • Done when: you can state whether privilege was granted (TCC/consent), how persistence survives reboot, and what the first non-signed thing executed was.

Memory / volatile

  • Open with: "What is in memory that disk cannot or will not tell me?"
  • Reason: running processes, injected code, in-flight connections, loaded modules, cached credentials. Memory is a temporary veto over disk - if disk and memory disagree, memory often wins for live activity.
  • Watch for: acquiring memory on an EDR-contained host (safe) vs. a live attacker-controlled one (noisy); kernel versions mismatched to Volatility symbols; power-off before capture.
  • Done when: you've anchored suspect processes to parent, cmdline, and network peer, or confirmed memory is clean.

AWS

  • Open with: "Which identity acted, from where, assuming what role, with what permissions?"
  • Reason: identity → session → API calls → resource changes. Treat every AssumeRole as a hop in a lateral chain. Correlate the IP's AS/geo against the identity's baseline before accepting it as the actor.
  • Watch for: IMDS SSRF chains (role creds used off-instance), defense evasion of the audit backbone, long-lived access keys, service-linked roles that look system-like but got abused.
  • Done when: you can draw an identity-and-permission graph for the window and name every resource mutated.

M365 / Entra ID

  • Open with: "Was this a stolen session or a stolen secret, and what did it read or send?"
  • Reason: sign-in method → MFA posture → session artifact (cookie, PRT, refresh token) → mailbox / Teams / Drive actions. BEC is nearly always session theft now, not password spray.
  • Watch for: AiTM cookie reuse across geos, OAuth app consent abuse (persistence without passwords), Compliance/eDiscovery role abuse to purge mail, UAL ingestion lag masquerading as "no activity."
  • Done when: you can state which mailboxes were read, which rules/forwarding were set, and whether any OAuth app still has lingering consent.

Okta

  • Open with: "Did someone bypass MFA, and did they change the identity surface itself?"
  • Reason: auth event → factor used → device/network context → downstream app session. Then look up: were factors, policies, admin roles, or group memberships changed?
  • Watch for: helpdesk-reset MFA (SCATTERED SPIDER pattern), app-level session reuse after the Okta session dies, support/impersonation sessions, drift in Conditional-Access-equivalent policies.
  • Done when: you can prove whether the identity provider itself was tampered with, versus only an individual session being hijacked.

Salesforce

  • Open with: "Which records left the tenant, and via what mechanism - UI, API, or report export?"
  • Reason: login → session → object access pattern → export surface (reports, Data Loader, API, Connected Apps). Volume and object type matter more than any single query.
  • Watch for: legitimate integrations that look like exfil, hourly log delivery lag biting your timeline, Connected Apps granted broad scopes long before the incident, LoginAs / support impersonation.
  • Done when: you can state the row count and object families touched, and whether any Connected App or report subscription persists.

Google Workspace

  • Open with: "Was Drive the target, and were sharing or forwarding rules used to externalize data?"
  • Reason: login → device → Drive access + sharing changes → Gmail filters/forwarding → OAuth-scope grants. Drive is where damage lives; Gmail is often how exfil persists.
  • Watch for: Drive log hours of lag, "anyone with the link" share changes, third-party add-ons with Drive scope, legacy Takeout exports, admin role elevation to self-service.
  • Done when: you can enumerate externally-shared files created in-window and every active forwarding or filter rule post-incident.

Slack / Teams

  • Open with: "Was this used for recon, lateral social engineering, or data staging?"
  • Reason: session origin → channel/DM access pattern → file uploads/downloads → integrations / webhooks / bots. Chat is often where the attacker learns the org before pivoting.
  • Watch for: private DMs that aren't in the default export, bot tokens used off-hours, webhook URLs leaked in code, legacy SSO tokens, user-created apps with over-broad scopes.
  • Done when: you can list the channels/DMs read, files exchanged, and every live integration token the actor could still use.

GitHub / SCM

  • Open with: "Was code read, modified, or exfiltrated, and does any persistence remain (keys, tokens, apps)?"
  • Reason: auth method → repo access pattern → clone/push events → secrets/keys/app grants added. Git commit metadata lies; trust the server-side audit log.
  • Watch for: PAT abuse that still shows the owner as actor, OAuth app installations, deploy keys and GitHub Actions secrets added, forks created as exfil stashes, workflow files modified to leak secrets at build time.
  • Done when: you can enumerate every repo cloned/forked in-window and every active token, app, deploy key, and workflow secret.

Snowflake / data warehouse

  • Open with: "Which rows and columns were read, and were they staged out?"
  • Reason: login → session → queries run → objects/columns accessed → external stages or COPY INTO targets. If MFA wasn't enforced, assume credential reuse until proven otherwise.
  • Watch for: ACCOUNT_USAGE latency hiding recent activity, benign BI tools that look exactly like exfil, UDFs / external functions used as covert egress, roles granted to new users during the window.
  • Done when: you can state the data classes exposed and whether any external stage, pipe, or share still carries the actor's reach.

Other SaaS (Atlassian, Zoom, Box, ServiceNow…)

  • Open with: "What is this app's blast radius for the business, and what's the minimum log that would prove read vs. write?"
  • Reason: determine audit coverage first - many SaaS tools log less than you expect. Then: auth → session → object access → integrations.
  • Watch for: tier-based logging gates (features behind E5-equivalent plans), API tokens that outlive user sessions, long default retention gaps, apps you forgot are federated through the IdP.
  • Done when: you've answered the "would we even see it?" question honestly, and documented the gap for the final report.

Think like the operator - what intrusions actually look like #

The per-platform cards above tell you where to look. This part covers who is on the other side and what they do from first access to payout. Every intrusion is somebody's job with an objective, a budget and a deadline. Work out the objective early, because it predicts the next move, tells you which evidence matters most, and tells you when you're done.

Speed is the 2025-26 reality (CrowdStrike 2026 Global Threat Report, covering 2025): average eCrime breakout time, initial access to first lateral movement, fell to 29 minutes (48 min the year before); the fastest observed was 27 seconds. In one intrusion, exfiltration began 4 minutes after initial access. 82% of detections were malware-free: valid credentials, identity flows, approved SaaS integrations and admin tools, not dropped binaries. Practical implication: 1-10-60 is a real target, not a slogan - containment decisions are measured in minutes, and "no malware found" is not "no intrusion."

Actor archetypes - objective drives behavior

ArchetypeWhat they wantTempo / dwellWhat they actually doWhat it means for your investigation
Ransomware affiliate (RaaS - Akira, Qilin, Play, DragonForce…; SPIDER family)Payment via encryption and leak threat (double extortion)Hours to a few days; breakout in minutesBuy or phish access → AD recon (AdFind, SharpHound, network scanners) → dump creds → disable EDR (BYOVD, uninstall via stolen console creds) → delete backups / shadow copies → exfil with rclone / MEGA / cloud sync → encrypt ESXi hypervisors and file servers, often off-hours / holiday weekendsYou're racing the encryption clock. Protect backups, hypervisors and the EDR console first. The exfil determination (what left, how much, whose data) drives legal notification and is usually what the client pays you to answer.
Data-theft extortion (no encryption - Cl0p / GRACEFUL SPIDER, ShinyHunters / UNC6040, UNC5537)Payment for not publishing stolen dataMass exploitation in days; SaaS theft in hoursZero-days in managed file-transfer apps (MOVEit 2023, Cleo 2024) hitting hundreds of orgs at once; vishing staff into authorizing a malicious OAuth app (Salesforce Data Loader); logging into SaaS / Snowflake with infostealer creds and bulk-exportingNo host malware, often no EDR signal. The whole engagement is data-access scoping from app/SaaS logs, and log retention is your enemy. Preserve first, then answer "which records, for which people."
Initial access broker (IAB)Sell the footholdGet in, verify access, leave persistence, go quietVPN/RDP creds from infostealer logs, edge-device exploits, webshells; validate privilege level, then list the access on a criminal forumThe actor you find may not be the one who comes back. Look for multiple, unrelated persistence sets and for a quiet gap between first access and hands-on-keyboard activity.
Nation-state espionage (PANDA / BEAR / KITTEN families)Long-term intelligence - email, IP, negotiating positions, government / defense dataMonths to years; deliberately low and slowExploit edge devices with no EDR (Ivanti, Fortinet, Citrix, Palo Alto, Cisco); LOTL with built-in tools; target specific mailboxes and file shares; tunnel through ORB networks of hacked routers; clean logs; keep several independent ways back inAssume incomplete scope. Edge appliances need their own forensics (integrity checks, vendor tools, memory). Work out the collection intent (whose mail, which projects) - that defines the damage, and it's what the client's leadership will ask.
Pre-positioning / destructive (VOLT TYPHOON / VANGUARD PANDA; Sandworm / VOODOO BEAR)Ability to disrupt or destroy later (critical infrastructure, OT)Years of quiet presence; destructive phase is fastLOTL only, SOHO-router botnets for ingress, credential harvesting on domain controllers, mapping OT/ICS networks; wipers when activatedAbsence of malware is the signature. Hunt for admin-tool use that doesn't match the admins. Involve government partners (CISA / FBI) - counsel decides, but raise it.
DPRK revenue operations (CHOLLIMA family)Money for the regime: crypto theft; salaries from fake IT workersWeeks of targeted social engineering; heists execute fastFake recruiters and "coding test" malware aimed at developers; supply-chain compromise (3CX, JumpCloud); FAMOUS CHOLLIMA IT workers hired under false identities using US "laptop farms" and remote-access toolsOften insider-shaped: the "attacker" is an employee with legitimate access. Pull HR / onboarding records, remote-access tool usage, VPN geolocation and payroll routing. Crypto tracing and law-enforcement coordination start early.
BEC / payment fraudRedirect a paymentDays of silent mailbox reading, then one well-timed emailAiTM phish or password reuse → inbox rules that hide replies → read invoice threads → spoof or hijack the thread → change bank detailsThe clock is the money: get the client to their bank and the FBI IC3 / Financial Fraud Kill Chain within 72 h of the wire. Then scope mailbox access (MailItemsAccessed) and whether partners were phished from the client's account.
Malicious insiderRevenge, profit, or taking data to a competitorUsually around resignation or terminationLegitimate access, no exploit: bulk downloads, personal cloud uploads, USB copies, forwarding to personal email, mass-deleting things on the way outDifferent rules: HR and counsel lead, interviews need Upjohn warnings, and the evidence must survive employment litigation. Compare against the person's own activity baseline, not "attacker TTPs."
Hacktivist (JACKAL family)Attention, political messagingBursty, timed to news eventsDDoS, defacement, hack-and-leak, often exaggerated claims recycled from old breachesJob one is verifying the claim: is the posted data actually yours, and is it new? Many "breaches" turn out to be old third-party leaks.

The intrusion lifecycle - what operators do at each stage

Each row is one stage of an intrusion: what attackers do there today, the question that should be in your head, and where the evidence lands. Use it as a scoping checklist: for each stage, answer the question from the evidence column, or record why you can't (log gap, retention, no coverage).

Stage (ATT&CK)What operators actually do (2024-26)Your questionWhere evidence lands
Initial accessValid creds from infostealer logs; edge-device exploits; vishing the help desk for MFA resets; ClickFix fake-CAPTCHA "paste this into Run"; Teams / call-back phishing posing as IT (Black Basta); SEO-poisoned tool downloads; compromised MSP / RMM; AiTM phishingHow did they get in, and is that door still open for anyone else?IdP sign-ins, VPN / edge logs, help-desk tickets, email gateway, browser history, RunMRU (ClickFix), EDR first-seen process
ExecutionPowerShell, mshta, rundll32, msiexec from a URL, Python / Node on dev boxes; in SaaS, "execution" is API calls and OAuth app actionsWhat ran first, and under which identity?EDR process trees, Prefetch / Amcache, 4688 / Sysmon 1, PowerShell 4104, SaaS audit API events
PersistenceSeveral layers on purpose: legit RMM (AnyDesk, ScreenConnect), extra MFA device registered, OAuth app / service-principal secret, new local or cloud admin, scheduled task / service, webshell on an edge device, IAM access keyIf I reset every password tonight, how do they get back in tomorrow?ASEP sweeps, IdP factor / device changes, app-consent logs, IAM key creation, RMM install events, edge-device file integrity
Privilege escalationNot usually exploits: credentials found in scripts, shares and vaults; Kerberoasting; AD CS misconfigurations (ESC1-8); help-desk / IdP admin roles; over-permissioned cloud rolesWhat's the highest privilege they reached, and how?4769 (RC4 TGS), AD CS issuance logs, role-grant events in IdP / cloud, LSASS access
Defense evasionKill or blind EDR (BYOVD drivers, uninstall with stolen console creds, work on hosts without EDR); clear logs; disable CloudTrail / audit; timestomp; operate from unmanaged VMs they create on your hypervisorWhich of my evidence sources has been tampered with, and where am I blind?Sensor heartbeat gaps, 1102 / 104, StopLogging, driver loads, new VMs in vCenter, coverage maps
Credential accessLSASS / NTDS / DCSync; browser cookie and token theft; reading password managers and cloud CLI credential files; harvesting session tokens from HAR files and CI/CD secretsWhich credentials must I treat as burned?Sysmon 10 on lsass, 4662 replication, file access on cookie / credential stores, secret-scanner hits
DiscoveryAdFind / SharpHound / BloodHound, net commands, network scanners; in cloud and SaaS, list / describe / enumerate API calls and global address list pullsWhat did they learn about the environment, and therefore what were they looking for?EDR command lines, LDAP query telemetry, CloudTrail List* / Describe* / Get* bursts, SaaS directory reads
Lateral movementRDP, SMB / PsExec, WinRM, WMI, SSH with harvested keys; identity-plane movement - SSO from the IdP into AWS, Snowflake, Salesforce with no host hop at allWhat's the full set of systems and identities they touched?4624 type 3 / 10 pairs on both ends, RDP and SSH logs, IdP SSO events per app
CollectionArchive with 7-Zip / WinRAR into staging folders; mailbox reads; SharePoint / Drive bulk access; SQL queries over crown-jewel tablesWhat did they gather - this shows their objective?Archive files and their MFT entries, MailItemsAccessed, FileDownloaded bursts, ACCESS_HISTORY / query logs
Command & controlLegit RMM and tunnels (ngrok, Cloudflare Tunnel, Tailscale) more than custom implants; Cobalt Strike / Sliver / Havoc / Brute Ratel where implants are used; C2 over SaaS APIsHow are they talking to the environment, and will blocking it tip them off?DNS, proxy / firewall, EDR network events, RMM vendor portals
Exfiltrationrclone to MEGA / S3 / attacker cloud, built-in sync clients, SaaS bulk export, cross-account EBS snapshot sharing, Snowflake COPY INTO an external stageWhat left, how much, to where - can I prove it either way?Flow logs / firewall byte counts, SRUM network bytes, cloud data events, SaaS export events
ImpactEncrypt ESXi / file servers, delete backups, wipe, extortion emails to the client's customers, DDoS as added pressure, fraudulent paymentsWhat's the business damage, and what's the fastest safe recovery path?Ransom notes, backup-console audit logs, hypervisor logs, payment systems

Per-attack-type thinking

Same structure as the platform cards: the question to open with, the reasoning path, the pitfalls, and when you're done.

Ransomware (pre- or post-encryption)

  • Open with: "Is encryption still spreading, are the backups intact, and did data leave before the encryption?"
  • Reason: stop the spread (isolate segments, cut admin paths, revoke tier-0) → protect backups and hypervisors → work backward from the encryptor's launch: how it was deployed (GPO, PsExec, ESXi SSH) → which privileged account deployed it → how that account was compromised → initial access. Run the exfil question in parallel, because it decides notification.
  • Watch for: the encryptor is the last 1% of the intrusion; ESXi encryption leaves almost no Windows evidence; the leak-site post may come before the client knows; paying doesn't remove the attacker's persistence.
  • Done when: you can name the initial access, the deployment mechanism and account, every persistence item, and give a defensible exfiltration finding (confirmed, likely, or no evidence, with the log coverage stated).

Data-theft extortion (no encryption)

  • Open with: "Is the attacker's claim real, and which records did they actually access?"
  • Reason: validate any sample they sent (is it yours, and how recent?) → identify the access path (file-transfer zero-day, SaaS creds, OAuth app) → pull and preserve every relevant log before it rolls → reconstruct the query, export or download set → map it to data subjects.
  • Watch for: short SaaS log retention; actors claiming more than they took (or less); one access path hiding a second one; third-party (vendor) breaches presented as yours.
  • Done when: you can give counsel a record-level or best-bounded estimate of affected data, and the access path is closed for everyone, not just this actor.

Edge-device / zero-day exploitation

  • Open with: "Is the appliance itself compromised, and what did they reach from it?"
  • Reason: vendor advisory and integrity-check tool → collect appliance logs, config and (where possible) memory before patching or rebooting → look for webshells, modified binaries, new local accounts → pivot on the appliance's internal IPs and service accounts → hunt downstream for LOTL activity from those sources.
  • Watch for: patching or factory-resetting erases the evidence; attackers that tamper with the vendor's own integrity checker; appliances that log to local disk only; the same exploit used by several unrelated actors.
  • Done when: the device is rebuilt from known-good, every credential it stored or saw is rotated, and the downstream hunt is complete for the exposure window, not just since detection.

Identity / SaaS-only intrusion (no endpoint)

  • Open with: "Which identity was taken, how was MFA bypassed, and which apps did that identity reach through SSO?"
  • Reason: IdP sign-ins and factor changes → session / token reuse → map every downstream app reached via SSO → in each app, data access and persistence (OAuth apps, API tokens, new admins, forwarding rules).
  • Watch for: EDR says "clean" because nothing touched a host; per-app logs have different time lags and retention; tokens that outlive password resets; attacker-registered MFA devices.
  • Done when: every session and token is revoked, the attacker's factors and devices are removed, all app grants are reviewed, and the help-desk or verification process they abused is fixed.

Supply-chain / trusted-third-party compromise

  • Open with: "Which trusted component or vendor delivered the attacker, and where else does that trust reach?"
  • Reason: identify the trusted vehicle (signed update, package dependency, CI/CD action, MSP's RMM, vendor's support access) → find every system that received it in the window → split "received" from "activated," because second-stage payloads are often selective → hunt for the actor's follow-on activity on activated hosts.
  • Watch for: signed and "legitimate" binaries; build-time secret theft in CI/CD; MSP tools that give the attacker every customer at once; vendors that are slow to share indicators.
  • Done when: you have a list of exposed versus activated systems, the trust relationship is cut or re-verified, and secrets the pipeline or vendor could see are rotated.

Insider / fake-employee (incl. DPRK IT workers)

  • Open with: "Is this person's activity out of pattern for their own role, and are they even who they claim to be?"
  • Reason: engage HR and counsel first → preserve quietly (don't tip them off) → baseline the person's normal activity → find deviations (bulk data movement, personal cloud, remote-access tools, impossible geolocation, the same laptop shared across identities) → tie actions to the person, not just the account.
  • Watch for: legal limits on monitoring; shared or delegated accounts; for fake workers, KVM-over-IP devices and laptops shipped to a "farm" address; sanctions exposure in payroll.
  • Done when: findings are defensible in employment litigation or for law enforcement, access is removed at the right moment, and the hiring or identity-verification gap is documented.

Business email compromise

  • Open with: "Has money moved, and can it still be recalled?"
  • Reason: bank and FBI IC3 first if a wire went out → find the mailbox compromise path (AiTM, password reuse, OAuth app) → inbox rules and forwarding → what the attacker read (MailItemsAccessed) → who they emailed as the victim → whether partners or customers were also hit.
  • Watch for: the compromised mailbox may belong to the vendor, not the client; rules that move replies to RSS Feeds or Archive; password resets that leave sessions alive; notification duties if the mailbox held personal data.
  • Done when: the money question is answered, sessions and rules are removed, mail-access scope is defined for counsel, and affected counterparties have been warned.

Cloud control-plane / infrastructure takeover

  • Open with: "Do they have, or did they have, administrative control of the account or org, and what did they create that outlives their credentials?"
  • Reason: scope the compromised principals → every role assumption and cross-account trust → resources created (users, keys, roles, Lambda functions, instances for crypto-mining, snapshots shared out) → data-plane access → logging and guardrail changes.
  • Watch for: deleting the leaked key before you've scoped it; persistence in another region or account; crypto-mining as a noisy distraction from quieter theft; ransom by deleting data or locking KMS keys.
  • Done when: every attacker-created resource is identified and removed, logging is restored and protected by guardrails (SCPs), and the identity graph is clean.

Reading the operator - tells that change your hypothesis

  • Speed and noise. Fast, loud, playbook-driven (AdFind → SharpHound → rclone → encryptor) points to an eCrime affiliate. Slow, quiet, selective, with log cleanup, points to espionage. Moving fast through cloud consoles with lots of failed API calls points to someone unfamiliar with the environment, like an IAB or a junior affiliate.
  • Toolkit. Commercial RMM, rclone, MEGA, Cobalt Strike, AnyDesk and network scanners are a ransomware precursor kit. A webshell on a VPN appliance with no endpoint malware at all points to a state actor or a mass-exploitation campaign. API-only activity from residential proxies points to identity theft at scale.
  • What they looked at. Finance shares and cyber-insurance policies (to size the ransom) point to extortion. Specific executives' mailboxes, R&D or negotiation files point to espionage. Payroll, HR and vendor master data point to fraud.
  • Working hours. Activity clustered in a consistent time zone is a weak but useful attribution hint. Activity timed for the victim's night, weekend or holiday is deliberate eCrime tradecraft.
  • Reaction to containment. Re-entry attempts within hours, new persistence appearing, or attackers taunting staff on Teams or by phone means an active operator who is watching you. Plan containment as one coordinated action.
  • More than one actor. An IAB followed by a ransomware crew, or an unrelated cryptominer alongside a state actor. Don't merge timelines just because they overlap. Separate them by tooling, infrastructure and objective.
  • Claims versus evidence. Ransom notes and leak-site posts are marketing. Verify every claim (data volume, systems, "we still have access") against your own evidence before it reaches the client's decision-makers.
Trap: "we found the malware, so we found the attacker." With 82% of detections malware-free, the binary is often the least important artifact. Scope by identity, access and objective, then use malware findings to support it. A clean malware sweep with an unexplained admin login at 03:00 is still an open intrusion.
Eradication principle: operators keep more than one way back in on purpose. Inventory every persistence item, credential and trust relationship first. Then remove them all in one coordinated window: credential resets, token revocation, persistence removal and blocks together. Piecemeal cleanup tells the attacker which footholds you've found and pushes them toward the ones you haven't.
Practitioner tip: analysts who start with "I'll pull KAPE / Velociraptor and parse $MFT" tend to collect far more than they can analyze. Analysts who start with "What does the client think happened? Let me build 2-3 hypotheses before touching any artifact" reach answers faster. Lead with the thinking; artifacts land as evidence for hypotheses, not as a scavenger hunt.