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
$userat ~$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.
Actor archetypes - objective drives behavior
| Archetype | What they want | Tempo / dwell | What they actually do | What 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 minutes | Buy 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 weekends | You'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 data | Mass exploitation in days; SaaS theft in hours | Zero-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-exporting | No 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 foothold | Get in, verify access, leave persistence, go quiet | VPN/RDP creds from infostealer logs, edge-device exploits, webshells; validate privilege level, then list the access on a criminal forum | The 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 data | Months to years; deliberately low and slow | Exploit 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 in | Assume 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 fast | LOTL only, SOHO-router botnets for ingress, credential harvesting on domain controllers, mapping OT/ICS networks; wipers when activated | Absence 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 workers | Weeks of targeted social engineering; heists execute fast | Fake 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 tools | Often 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 fraud | Redirect a payment | Days of silent mailbox reading, then one well-timed email | AiTM phish or password reuse → inbox rules that hide replies → read invoice threads → spoof or hijack the thread → change bank details | The 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 insider | Revenge, profit, or taking data to a competitor | Usually around resignation or termination | Legitimate access, no exploit: bulk downloads, personal cloud uploads, USB copies, forwarding to personal email, mass-deleting things on the way out | Different 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 messaging | Bursty, timed to news events | DDoS, defacement, hack-and-leak, often exaggerated claims recycled from old breaches | Job 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 question | Where evidence lands |
|---|---|---|---|
| Initial access | Valid 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 phishing | How 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 |
| Execution | PowerShell, mshta, rundll32, msiexec from a URL, Python / Node on dev boxes; in SaaS, "execution" is API calls and OAuth app actions | What ran first, and under which identity? | EDR process trees, Prefetch / Amcache, 4688 / Sysmon 1, PowerShell 4104, SaaS audit API events |
| Persistence | Several 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 key | If 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 escalation | Not usually exploits: credentials found in scripts, shares and vaults; Kerberoasting; AD CS misconfigurations (ESC1-8); help-desk / IdP admin roles; over-permissioned cloud roles | What's the highest privilege they reached, and how? | 4769 (RC4 TGS), AD CS issuance logs, role-grant events in IdP / cloud, LSASS access |
| Defense evasion | Kill 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 hypervisor | Which 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 access | LSASS / NTDS / DCSync; browser cookie and token theft; reading password managers and cloud CLI credential files; harvesting session tokens from HAR files and CI/CD secrets | Which credentials must I treat as burned? | Sysmon 10 on lsass, 4662 replication, file access on cookie / credential stores, secret-scanner hits |
| Discovery | AdFind / SharpHound / BloodHound, net commands, network scanners; in cloud and SaaS, list / describe / enumerate API calls and global address list pulls | What 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 movement | RDP, SMB / PsExec, WinRM, WMI, SSH with harvested keys; identity-plane movement - SSO from the IdP into AWS, Snowflake, Salesforce with no host hop at all | What'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 |
| Collection | Archive with 7-Zip / WinRAR into staging folders; mailbox reads; SharePoint / Drive bulk access; SQL queries over crown-jewel tables | What did they gather - this shows their objective? | Archive files and their MFT entries, MailItemsAccessed, FileDownloaded bursts, ACCESS_HISTORY / query logs |
| Command & control | Legit RMM and tunnels (ngrok, Cloudflare Tunnel, Tailscale) more than custom implants; Cobalt Strike / Sliver / Havoc / Brute Ratel where implants are used; C2 over SaaS APIs | How are they talking to the environment, and will blocking it tip them off? | DNS, proxy / firewall, EDR network events, RMM vendor portals |
| Exfiltration | rclone to MEGA / S3 / attacker cloud, built-in sync clients, SaaS bulk export, cross-account EBS snapshot sharing, Snowflake COPY INTO an external stage | What 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 |
| Impact | Encrypt ESXi / file servers, delete backups, wipe, extortion emails to the client's customers, DDoS as added pressure, fraudulent payments | What'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.