The agent built an APT28 attribution.
Then it caught itself.
Nine “unfamiliar sign-in” alerts triggered a 30-day lookback. The investigator concluded a sustained nation-state campaign with high confidence. The senior reviewer then found that the lookback had dropped a single filter, and every “APT detection” feeding the conclusion had already been resolved as benign by the source platform.
The first-pass agent published a confident, high-severity APT attribution. The senior reviewer caught the methodology error and reversed the verdict. The analyst sees both passes and the evidence that moved the call.
The reviewer did not synthesize. It interrogated. It re-ran the load-bearing queries with corrected predicates. Severity moved down here. It moved up on the ContentServer C2 case. Both directions are part of the contract.
The reviewer didn’t just re-evaluate the conclusion. It re-ran the queries with corrected predicates. The error was in the query, not the reasoning.
Nine users. Three offices. Twenty-four hours.
At 18:16 UTC on 2026-03-10, Azure AD Identity Protection raised “Unfamiliar sign-in properties”
against katherine.p*** on host DC-1659. Inside twenty-four hours,
eight more identical alerts followed:
nicole.m***, brian.c***, emma.s***,
anna.b***, ronald.b***, kenneth.b***,
matthew.s***, and steven.n***, spanning hosts in
Bangalore (BD), Washington (DC), and New York (NY).
Nine distinct users. Three offices. All inside the same /24 subnet. All within a single working day. The cluster pattern is what an investigator notices first, and what the agent flagged for DEEP-tier investigation.
A 30-day lookback built an APT28 case.
The investigator escalated to DEEP tier on multi-signal pattern and ran a 30-day historical lookback against the four most recent hosts. The lookback surfaced Dukozy-labeled malware. Seadask-labeled malware. YTTRIUM actor activity. Bladabindi backdoor. Persistence mechanisms: AppCertDlls, IFEO, WMI, scheduled tasks, masqueraded services. Internal port-scanning from a host outside the affected subnet. PowerShell policy bypasses.
The story wrote itself: a sustained, multi-week intrusion by a nation-state actor. Approximately 600 detection records across four hosts. ~53 specifically labeled with APT28 / YTTRIUM family signatures. The agent published a Critical Threat verdict with HIGH confidence and recommended immediate incident response: network isolation, credential reset, forensic imaging.
This is where most autonomous investigators stop: confident answer, polished narrative, ready to ship.
Four working theories, all consistent with APT.
The investigator tested each hypothesis against the 30-day record set. All four corroborated the APT28 attribution. None was disconfirmed.
Four hypotheses tested, all corroborated. The investigator finalized the report and handed it to the senior reviewer for sign-off.
One missing filter. The verdict collapses.
The senior reviewer’s first move was not to read the conclusion. It was to read the queries. Specifically Q5 through Q8: the 30-day per-host lookbacks that surfaced Dukozy, Seadask, YTTRIUM, Bladabindi, persistence mechanisms, and ~600 detection records.
The reviewer noticed that the Gate 1 intake query filtered correctly on status_id = NEW.
The Gate 2 enrichment queries did not.
Q5 as executed, 30-day lookback (BD-2578)
Q5 corrected, what should have run
status_id of RESOLVED with status_detail = "Benign",
meaning Microsoft Defender had already investigated and dispositioned each one as a false positive.
The investigator built an APT28 narrative on top of vendor-resolved benign alerts. The reviewer
spotted the filter omission, re-ran the four enrichment queries with the correct predicate,
and the corroborating evidence dissolved.
The 30-day lookback queries in Gate 2 did not filter by status_id. The initial 24h query
correctly used status_id = NEW. The enrichment queries dropped this filter. This caused
the investigation to treat already-resolved, benign-classified alerts as active threats.
Every single APT/malware detection across all four investigated hosts has been resolved by the source platform. The source platforms (Microsoft Defender / Azure Security Center via SecLake) investigated these detections and classified them as benign, likely false positives or signature-matched benign files.
Recommendation: withdraw APT28 attribution. Re-disposition as Standard. Focus on
the 9 “Unfamiliar sign-in” alerts and behavioral persistence alerts that remain genuinely
status_id = NEW.
Severity moved down. The evidence moved with it.
When Q5 through Q8 were re-run with status_id = NEW, the corroborating evidence
for APT28 attribution disappeared. The table below shows what the agent counted as confirmation:
| Detection family | Status (verified) | Vendor disposition | Count (4 hosts) |
|---|---|---|---|
| Dukozy high-severity malware | RESOLVED | Benign | ~8 |
| Seadask high-severity malware | RESOLVED | Benign | ~7 |
| YTTRIUM Actor activity detected | RESOLVED | Benign | ~12 |
| YTTRIUM malicious file detected | RESOLVED | Benign | ~18 |
| Bladabindi backdoor detected | RESOLVED | Benign | ~8 |
| Total APT/malware alerts | ALL RESOLVED | ALL BENIGN | ~53 |
Three categories of alerts remained status_id = NEW and genuinely actionable after the
corrected query set:
- The 9 “Unfamiliar sign-in properties” alerts. The original trigger pattern. Still requires investigation, but at standard, not APT, severity.
- Behavioral / persistence detections (~30 per host) with
status_detail = "UnsupportedAlertType". The SecLake integration cannot auto-resolve these alert types; they remain NEW by default. They need triage, but the NEW status is not evidence of malicious intent. - CrowdStrike operational alerts with
status_id = null. Mostly operational noise (PrinterInstaller, browser activity, msiexec).
Standard investigation. Not a nation-state campaign.
The corrected investigation withdraws all APT28 / YTTRIUM attribution claims. The reviewer blocked the original report from distribution and published a revised disposition with the following recommended actions:
- Contact the 9 affected users to verify whether sign-in activity was legitimate.
- Check for recent IT changes (MFA rollout, VPN reconfiguration, device refresh) that could explain unfamiliar sign-in properties across multiple users at once.
- Deploy Azure AD authentication log connector to enable proper sign-in investigation. Current data lacks source IP, geolocation, and MFA status.
- Triage a sample of “UnsupportedAlertType” persistence alerts to determine whether
status_id = NEWis meaningful here or simply a gap in the SecLake integration’s status handling. - If any user confirms they did NOT sign in, escalate that specific account for credential-compromise investigation.
Estimated cost avoided by the reviewer’s catch: 40–80 person-hours of incident response mobilization, plus the operational disruption of credential resets and forensic imaging across 9 hosts.
Always check status_id on enrichment queries.
The Gate 1 intake query correctly filtered by status_id = NEW. The filter was dropped for the 30-day lookbacks. That single omission caused the entire investigation to reach the wrong conclusion. The fix is structural: shared FSQL rules now enforce status_id filtering on any detection-record query whose result feeds a verdict.
Vendor detection labels are not confirmed threats.
“Dukozy malware detected” means the vendor matched a signature. It does not mean Dukozy is confirmed present, especially when the same vendor later resolved it as benign. Disposition state is part of the evidence, not metadata to be ignored.
Volume is not evidence.
~600 alerts sounds alarming but is meaningless without signal-to-noise separation and status verification. The investigator weighted record count toward confidence; the reviewer reduced 600 to ~14 actionable records by adding one predicate.
Absence of enrichment data is itself a finding.
No file hashes, no Azure AD authentication logs, no on-prem network flow data. These are not blockers to be worked around. They are evidence-quality limits that must be stated explicitly rather than filled with assumptions.
All 14 FSQL queries executed
Q1 Pull new HIGH/CRITICAL/FATAL detection findings (24h) CORRECT FILTER
Q3 Extract user/IP from all 9 sign-in alerts CORRECT FILTER
Q5 30-day history for BD-2578 (ronald.b***), 172.16.16.60 MISSING FILTER
Q6 30-day history for BD-2773 (steven.n***), 172.16.16.44 MISSING FILTER
Q7–Q8 30-day history for BD-2395 and BD-991, same pattern MISSING FILTER
Q10 Inventory check on 10.100.21.239 (suspected pivot) EMPTY RESULT
Q11–Q14 Threat-intel enrichment attempts (file hashes, malware family lookups) DATA GAP
Showing 7 of 14 queries above. Full query trail with results in queries.md.
Sources queried · with status
| Source | Status | Notes |
|---|---|---|
| detection.alerts (SecLake) | HIT | Primary intake; 600+ records over 30d |
| edr.crowdstrike | PARTIAL | Detections present; FDR Auth ingestion empty; connector verification needed |
| identity.azuread | GAP | No authentication logs ingested; cannot verify sign-in source IP, geo, MFA status |
| identity.gws (Google Workspace Directory) | HIT | User-host correlation; 10.100.21.239 not found |
| inventory.cmdb | HIT | Host registration check |
| network.flow (on-prem) | GAP | No flow data for 172.16.16.x or 10.100.21.x; cannot trace lateral movement |
| osint (threat-intel connectors) | GAP | Cannot enrich without IOC-grade evidence (hashes, IPs, domains absent from records) |
Gaps explicitly catalogued
- Azure AD authentication logs not ingested. Root-cause investigation of the 9 sign-in alerts cannot proceed without source IP, geo, and MFA detail.
- CrowdStrike FDR Auth empty. Cannot correlate endpoint logon events with the identity alerts. Connector ingestion to verify.
- No on-premises network flow data for 172.16.16.x or 10.100.21.x. Lateral movement paths cannot be traced.
- File hashes absent from detection findings. Threat-intel enrichment not possible against the source records as ingested.
- 5 of 9 hosts not deep-dived. NY-2752, BD-1310, DC-2097, DC-1659, BD-2578 covered at 24h trigger only. Recommend extending if any user confirms unauthorized sign-in.
MITRE ATT&CK · what was attributed vs. what holds
| Technique | Tactic | Status after review |
|---|---|---|
| T1078 | Initial Access · Valid Accounts | Possible, pending sign-in verification with affected users |
| T1059 | Execution · Command and Scripting | Resolved/Benign, vendor disposition |
| T1546 / T1543 / T1053 / T1037 | Persistence · multiple | NEW status, but “UnsupportedAlertType”; needs triage to determine if integration artifact or real |
| T1036 | Defense Evasion · Masquerading | NEW status with same caveat as above |
| T1082 / T1016 / T1018 / T1046 | Discovery · multiple | NEW status with same caveat as above |
See how Workers stress-tests its own conclusions.
Bring your alerts. Deep investigations and critical findings get a senior review automatically.