120 alerts. One overnight pass.
Five confirmed threats.
120+ NEW Defender alerts overnight across 50+ workstations and one EC2 instance. By morning, the agent had triaged the lot: five end-to-end confirmed threats across Initial Access → Execution → Persistence → Discovery → Defense Evasion, cross-environment spread from corporate to cloud, and ~45 single-category alerts closed with rationale.
investigation_state: "UnsupportedAlertType". Defender could not auto-investigate.One overnight pass reduced 120 alerts to 5 confirmed threats and ~45 single-category triages. The morning briefing was the report, not the queue.
The cross-environment finding, corporate workstations + EC2, required the same threat-chain query to operate across endpoint and cloud telemetry simultaneously. Single-domain tools can’t tell this story.
The agent’s final move was to defer to the human on red-team-vs-real. The recommendation is conditional and explicit about what it cannot rule out on its own evidence.
Volume that defeats triage by hand.
A 24-hour pull on NEW HIGH/CRITICAL Defender alerts returned ~120 records. The shape was familiar:
10 Unfamiliar sign-in properties, dozens of suspicious cmd.exe executions, persistence
mechanisms (AppCertDLLs, IFEO, WMI subscriptions, file association changes), system discovery,
masqueraded services. A 7-day lookback expanded the population to ~50 workstations on the
172.16.16.x subnet plus a single EC2 instance on 10.100.6.x.
Every alert carried investigation_state: "UnsupportedAlertType". Defender’s
auto-investigator does not handle these alert types, so they accumulate as NEW indefinitely. The
analyst arriving at 08:00 UTC would see a wall of unprocessed alerts and an explicit message from
the platform: we cannot auto-triage these for you.
Most autonomous SOC tools stop here. They summarize the alert volume and route to a human. The agent’s instructions were to take the next step: assemble per-user threat chains and separate the structural signal from the noise.
From 120 alerts to 5 confirmed threats.
The agent’s move was to correlate per host and per user across alert types. A user with one “Unfamiliar sign-in” alert and one “cmd.exe execution” alert is two records in the queue. The same user with sign-in PLUS execution PLUS persistence PLUS discovery PLUS evasion over the same seven days is a confirmed threat, and a verdict the analyst can act on.
Five users met the threshold:
| User | Host | Alerts (7d) | Threat stages observed |
|---|---|---|---|
| raymond.c*** | NY-1229 (172.16.16.98) | 17 | Initial AccessExecutionPersistenceDiscovery |
| laura.s*** | BD-1375 (172.16.16.65) | 8 | Initial Access ×2PersistenceExecutionDefense Evasion |
| aaron.d*** | SE-1640 (172.16.16.112) | 7 | Initial AccessPersistence ×2Execution |
| peter.s*** | SE-3348 (172.16.16.122) | 5 | Initial AccessExecutionPersistence (WMI)Defense Evasion |
| brenda.m*** | DC-873 (172.16.16.83) | 12 | Initial AccessExecutionDiscovery ×2Defense Evasion |
| ec2-user | i-0bff****7bbb (10.100.6.12) | 8 | ExecutionPersistence ×4 (WMI, IFEO, File-Assoc)Defense Evasion |
laura.s*** had two “Unfamiliar sign-in” alerts six days apart with persistence activity between them. The repeat pattern is what separates a transient sign-in anomaly from a sustained foothold.
The EC2 instance is the cross-environment tell. A different /24, no AAD-tracked identity, but the same multi-stage pattern as corporate hosts. ec2-user shows four distinct persistence mechanisms (WMI subscription, IFEO debugger, file association, masqueraded service) — consistent with an attacker who established corporate access first and pivoted to cloud, or with coordinated red-team activity spanning both environments.
Eleven techniques. Five tactics. One narrative.
The agent mapped every confirmed host activity to MITRE ATT&CK. The breadth across five distinct tactics is structural evidence no single vendor label can produce.
Four distinct persistence mechanisms across 15+ hosts. Three discovery techniques across 10 hosts. A single attacker can use one of these. Multiple, in parallel, across different hosts, indicates either an automated playbook or a coordinated team, but in either case, this is not random noise.
Critical Threat, conditional on confirmation.
The agent’s final disposition was RECOMMEND ESCALATION at Critical severity, but the report’s first action item is not “isolate the hosts.” It’s:
The pattern is consistent with either a sustained adversary or an authorized red team. Without access to the change-management calendar or red-team scheduling, the agent cannot disambiguate. It does not pretend it can. Confidence is set to MEDIUM with the structural evidence, cross-host, cross-environment confirmed threats across 11 techniques, explicitly cited as the reason it was not set lower.
- Severity: 3.65 composite (DEEP-tier route)
- Confidence: MEDIUM. Cross-host/cross-environment structural correlation, not single-source vendor labels.
- Incident criteria met: 5 of 6 (active compromise, multi-stage progression, persistence established, cross-environment spread, credential-compromise indicators)
- Open question: lateral movement. Different subnets affected, but no L3/L4 flow data to confirm path.
Pattern beats label.
Every alert in this case carried “UnsupportedAlertType,” the platform’s signal that it couldn’t classify the alert itself. The verdict came not from any single label but from cross-host, cross-tactic threat-chain correlation. When labels are unreliable, the agent’s job is to surface the structure.
Workers stop at the policy boundary.
The agent could not distinguish a real compromise from an authorized red-team exercise without access to the change-management calendar. Rather than guess, it explicitly conditioned the disposition: “if not authorized, begin IR.” The human gets a load-bearing claim and the evidence; the human makes the call.
Cross-environment spread is the structural tell.
The same persistence patterns on corporate Windows hosts and an AWS EC2 instance is information no single-domain tool can produce. The mesh-level view is what made “is this real?” answerable on the basis of more than alert volume.
Volume is not severity. Structure is.
The 120-alert queue would have been alarming on its own. The 5-confirmed-threat finding is what the IR team needs. Workers’ triage that reduces 120 to 5, with the threat-chain detail and the evidence for each, is the value, not the alert count.
Key queries: intake + correlation + verification
Q124h NEW HIGH/CRITICAL intake: overnight queueINTAKE
investigation_state: "UnsupportedAlertType".Q15Per-user 7d cross-alert-type correlation (threat chain detector)CORE QUERY
Q18Cross-subnet sweep: anything on 10.100.6.x with persistence?CLOUD HIT
Q20UnsupportedAlertType base-rate check (suppress false signal)VALIDATE
Showing 4 of 20 queries. Full audit trail in queries.md.
Sources queried · with status
| Source | Status | Notes |
|---|---|---|
| detection.alerts (msdefender) | HIT | 120+ NEW alerts; UnsupportedAlertType across the board |
| edr.crowdstrike (process_activity) | GAP | No cmd.exe command-line detail. Cannot see what was executed. |
| identity.azuread (auth events) | GAP | “Unfamiliar sign-in” criteria opaque without raw auth telemetry |
| cloud.cloudtrail | PARTIAL | EC2 instance metadata available; IAM activity for ec2-user not yet queried |
| changemgmt.tickets (red-team calendar) | GAP | Not ingested. Cannot rule out authorized testing without this source. |
Gaps explicitly catalogued
- No authentication telemetry. What made sign-ins “unfamiliar” cannot be verified (geo, device, MFA status).
- No process_activity / command-line detail. Cannot see what cmd.exe was actually doing on each threat-chain host.
- OCSF device fields empty. Host identification required raw_data parsing for every alert type.
- No %username observable matches. Cross-event-type user correlation required manual cross-reference.
- Change-management calendar not ingested. Agent cannot distinguish compromise from authorized red team without this source.
Run Workers against your overnight queue.
Bring the alerts that piled up since yesterday’s shift.