The pattern that fired.
The fix that didn’t.
The agent ran an eight-pattern identity sweep three times across eight days. The first run was a clean baseline. The second caught a service account logging in via Chrome from a real employee’s laptop. The third, eight days later, found that the recommendation hadn’t been actioned, the misuse had continued daily, and a DLP event tied the same laptop to a Private-classified file access. No detection rule ever fired.
svc-backup@ authenticated via Chrome from laptop LAP-890, breaking its automated server-only baseline. Cross-correlation identified tina.b***@ as the regular operator of that laptop.The agent did not wait for an alert. It tested eight MITRE identity techniques on a cadence across two IdPs. The most consequential finding came on the eighth pattern, in the second run. No alert ever fired.
Run 3 did not start over. It read Run 2’s report, checked the recommendation status, and added what was new. The agent is not a goldfish. It tracks whether recommendations were actioned and flags the ones that weren’t.
The agent checked whether prior recommendations were actioned and escalated when they weren’t. Run 3’s value came from memory, not rediscovery.
Eight MITRE techniques. Two identity providers. No alert needed.
Most identity threats don’t trigger alerts. They look like normal logins, until someone steps back and asks whether the right user from the wrong device, the wrong IP, or the wrong hour actually fits the baseline. That’s the question an ITDR assessment is built to answer.
The agent’s instructions on March 17 were to sweep the [tenant] mesh for eight
identity-attack patterns across both connected IdPs (Okta and Microsoft Entra ID) and surface
what no existing detection rule covered. Seven days of authentication data, thirty days of
privilege-change data, ~200 accounts.
The same eight-pattern sweep would be re-run on March 18 and again on March 26. The first run was a baseline. The second and third are why this case is here.
The first sweep was healthy. Mostly.
Run 1 produced an overall risk verdict of HEALTHY with documented caveats. Of the eight patterns, two surfaced low-confidence suspicious signal (shared public IPs across users, impossible-travel candidates) that the agent attributed to a test-bed environment with simulated data. Three patterns were clean. Three were blocked on data gaps.
The agent also documented an architectural insight that single-IdP tools hide from buyers:
Okta was recording internal proxy IPs in src_endpoint.ip; Entra was recording
public client IPs in device.ip. Until that field-path asymmetry was
reconciled, cross-IdP IP correlation would produce false matches. The finding was logged.
A query template update was queued.
The agent signed off. A clean-with-caveats baseline. The next run would be scheduled for the following day.
Same sweep. One pattern caught.
Run 2 swept the same eight patterns against fresh data. Seven came back clean or data-gap, just like the day before. Pattern 8, Service Account Abuse, moved from CLEAN to SUSPICIOUS, high confidence.
At 2026-03-18 09:22:50 UTC, the service account
svc-backup@[tenant].onmicrosoft.com authenticated to Okta. The login itself
was successful. Nothing about it, in isolation, would trigger an alert. The agent’s hit came from
comparing the login’s shape to the account’s baseline.
The account had a consistent baseline: four automated logins per hour at fifteen-minute intervals from
server 10.100.10.5, user-agent ServiceAgent/1.0 (BackupAutomation).
The fifth record didn’t match. It was an interactive login from a different IP,
using Chrome.
- Baseline (4 of 5 records):
10.100.10.5,ServiceAgent/1.0 (BackupAutomation), 15-min intervals. - Anomalous (1 of 5 records):
172.16.82.127,Chrome/120.0.0.0, single timestamp.
A laptop. A user. A four-minute window.
The IP 172.16.82.127 was internal RFC1918; it couldn’t be enriched with external threat
intel. The agent took a different pivot: which device holds this IP, and who else has
authenticated from it today?
A DHCP lookup mapped 172.16.82.127 to host LAP-890, a laptop, not a server.
A second authentication query against that same IP across the prior 24 hours returned fourteen records.
Thirteen of them belonged to one person.
tina.b***@, regular operator
svc-backup@, anomalous login
tina.b***@‘s active session
window on her own laptop. The likeliest person behind the service-account credentials
is the person who uses the device every day. The agent did not conclude an attack. It recommended
an interview, a credential rotation, and an IP restriction, with a disposition of SUSPICIOUS.
The recommendation went to the security team. The run was archived. A new run was queued for the following week.
Eight days later. Same finding. Worse.
Run 3 swept the same eight patterns against fresh data. Pattern 8 surfaced again: same service account, same laptop, now with seven consecutive days of daily logins. The agent did not re-discover the finding from scratch. It read its own prior assessment, confirmed the recommendation had not been actioned, and added the new evidence that had accumulated since.
svc-backup@ browser login from LAP-890. Cross-correlation identified tina.b***. Interview + rotate + restrict recommended.svc-backup@. DLP event on same laptop: tina.b*** attempted to access a Private-classified file.The Run 3 report’s first line is the kind of sentence security teams need agents to write: “The primary finding from the prior assessment was not remediated.” The agent had not forgotten. It had checked.
- Pattern persistence: svc-backup@ continues to authenticate to Okta via Chrome from LAP-890 (172.16.82.127) every day at ~09:22 UTC. Mar 20 through Mar 26, inclusive, seven consecutive days.
- New evidence: the service account is now making HTTP requests after the browser login, where the original baseline showed authentication-only activity.
- DLP correlation: a DLP event on the same laptop in the intervening week shows
tina.b***@attempting to access a Private-classified file. The agent did not declare this causal; it surfaced it for analyst review. - Recommendation status: credential rotation, IP restriction, and conditional-access policy from Run 2 were not actioned. Escalation re-issued.
The most useful identity findings are not alerts.
No detection rule fired across the three runs. A periodic eight-pattern sweep with cross-source pivots caught what an alert-driven SOC would have missed entirely. ITDR assessments belong on a cadence, not an event trigger.
One pivot can replace ten enrichment queries.
The pivot from IP-of-the-anomalous-login to who else authenticated from that IP identified the user in one query. Threat intel has nothing to say about an RFC1918 address, and the agent did not waste budget asking. Pivot beats enrichment when the IP is internal.
Cross-run memory is a feature, not a luxury.
Run 3’s value came from comparing today against a previous report. Without memory, Run 3 would have surfaced “service account interactive login, investigate” as a fresh finding. With memory, it surfaced “the recommendation from Run 2 was not actioned, and here is what’s new since.” That’s the difference between a repeat alert and an escalation.
Data gaps are recommendations, not blockers.
MFA challenge logging absent. Privilege change events absent. Each run produced an explicit, prioritized remediation list for every gap it found. The gaps weren’t worked around. They were named, ranked, and handed to the platform team.
Key queries across the three runs
R2·Q7 Pattern 8 baseline: svc-backup@ authentication history (7d) HIT
R2·Q9 Cross-pivot: who else authenticated from 172.16.82.127 today? PIVOT
R2·Q10 DHCP map: which device holds 172.16.82.127? ENRICH
R3·Q3 Pattern 8 re-test (8 days later), same account, same query PERSISTS
R3·Q7 Post-login activity: is svc-backup@ doing anything new? NEW EVIDENCE
R3·Q9 DLP activity on LAP-890, same laptop, intervening week CROSS-DOMAIN
Showing 6 of 81 queries across the 3 runs. Full per-run query trails in queries.md for each assessment.
Sources queried · with status
| Source | Status | Notes |
|---|---|---|
| identity.okta (Signin Backup) | HIT | Primary authentication record; svc-backup@ baseline + anomaly |
| identity.azuread (Entra Signin Backup) | HIT | Cross-IdP comparison; public client IPs via device.ip |
| network.dhcp | HIT | IP → device pivot (172.16.82.127 → LAP-890) |
| http_activity (proxy) | PARTIAL | Behavioral drift confirmed in Run 3; full URL classification limited |
| dlp_activity | HIT | Cross-domain correlation in Run 3, same laptop, same week |
| identity.entra (audit logs) | GAP | No entity_management events. Pattern 7 not testable |
| identity.okta (mfa_challenges) | GAP | MFA fields empty on both connectors. Pattern 4 not testable |
Gaps explicitly catalogued
- MFA challenge logging not populated on either IdP. T1621 detection is blind. Remediation: enable Okta System Log MFA events + Entra sign-in logs with MFA detail.
- Privilege escalation events not present. T1098 detection is blind. Remediation: onboard
entity_managementoraccount_changeevents from both IdPs. - Okta source IPs are all internal proxy. Geo-based impossible-travel detection on Okta side is degraded. Entra provides public client IPs via
device.ipas compensating control. - Auth0 + JumpCloud auth connectors produce zero events. If these IdPs are in active use, identity events are being lost.
MITRE ATT&CK coverage
| Technique | Pattern | Result across 3 runs |
|---|---|---|
| T1110.003 | Password Spraying | CLEAN × 3 |
| T1110.004 | Credential Stuffing | CLEAN × 3 |
| T1078 | Impossible Travel | LOW-CONF × 1, CLEAN × 2 (architectural shared-IP resolution) |
| T1621 | MFA Fatigue | DATA GAP × 3. Recommendation: enable logging |
| T1078 | Dormant Account | INCOMPLETE × 3. Recommendation: user inventory normalization |
| T1078 | Cross-IdP Anomaly | CLEAN × 3. Architectural IP-field asymmetry documented |
| T1098 | Privilege Escalation | DATA GAP × 3. Recommendation: onboard entity_management |
| T1078.001 | Service Account Abuse | CLEAN → SUSPICIOUS → ESCALATED |
See how Workers remember across runs.
Bring the assessment you want to run on a cadence.