Facts checked Nov 6, 2026
Microsoft said Nov. 5 that attackers use an AI framework to search GitHub for secrets. We would search Entra app sign-in logs today for every client secret, on GitHub or not, because a valid secret signs in with no MFA prompt until revoked.
What Microsoft saw
Microsoft has seen the agentic framework send large volumes of GitHub queries since August, often including organization names, secret keywords or cloud keywords. Searching public code is "well-documented"; Microsoft says agents also analyze results and conduct follow-on attacks. It cites ARTEX as an example tool, names no actor and no victim count.
"In at least one case," Microsoft says, an AI agent went from scanning GitHub to exfiltrating data from Azure Key Vault in five minutes. Microsoft published no timestamps, tenant or baseline.
"In multiple cases" agents then obtained a token for a single-tenant OAuth app and enumerated resources. "In some cases" they exfiltrated Key Vault secrets; they also searched Azure DevOps for secrets and used VM Run Command. Separately, Microsoft says that in one attack from as early as Oct. 28, an agentic framework used "valid leaked or stolen application credentials" and signed in to "dozens of associated applications across multiple tenants." The actor targeted credential-returning operations; the apps then accessed SharePoint, OneDrive and mailbox items.
In logs, Microsoft describes failed API calls retried with a changed method or API version about 28, 60 and 80 seconds later, each returning HTTP 200 (three examples, one attack).
Who is affected
Entra tenants with client-secret apps, vendor multitenant apps and MSPs. Neither source counts US victims.
Where Microsoft's and Todyl's accounts differ
Todyl, an MXDR vendor, reported similar activity Nov. 3; it says credentials for its own integration apps in two MSP tenants were among those abused. The accounts differ on these points, and none is settled. The last column says what to do under either.
Point | Microsoft (Nov. 5) | Todyl (Nov. 3) | What to do either way |
|---|---|---|---|
AI direction | "The agent" signed in | Its telemetry "does not show an AI model directing it," a possibility it holds at low confidence | Run the same hunt |
Credential source | "leaked or stolen" | "still unknown" | Hunt every client secret, not only those found on GitHub |
Vendor | Cases where a vendor-owned multitenant app credential was "compromised at the source"; it names no vendor and does not tie these cases to Todyl | "no sign any vendor platform was compromised" | Include vendor apps in the hunt and the inventory |
Start | "As early as" Oct. 28 | Nov. 1, with no activity in its data on 199.19.77[.]0/24 from Oct. 6 | Do not stop the search at either date |
Scale | "dozens" of apps | A floor: about 45 app registrations targeted at roughly 18 organizations | Do not add the two; read neither as a total |
199.19.77[.]18 | A sign-in source | 199.19.77[.]84 made all confirmed app sign-ins; .18 was a password spray in which every attempt failed | Hunt both; block only .84 |
Where Conditional Access and sign-in logs fall short
Todyl wrote app sign-ins carry "no MFA prompt" and user-scoped Conditional Access "doesn't apply." Microsoft says exposed credentials "remain usable until revoked or rotated," even after removal from the repo, and "Tokens already issued remain valid until expiry." Conditional Access for workload identities needs Workload ID Premium licensing and covers only single-tenant apps, not multitenant apps, third-party SaaS or managed identities. Entra's retention table lists sign-in logs at 7 days on Free and 30 on P1/P2, with no separate service-principal line; upgrades do not recover expired logs. As of Nov. 6 that reaches back to about Oct. 30 on Free and Oct. 7 on P1/P2, so unless logs were archived, Free already misses Oct. 28. Key Vault reads are logged only if a diagnostic setting already existed; Azure Activity logs last 90 days; Graph activity logs need storage or analytics integration.
What to do now
- SOC, today: search Entra service principal and non-interactive sign-ins, failures included, for the patterns and IPs below, as far back as retention allows.
- Identity team, on a hit you confirm: remove all secrets, certificates and federated credentials, disable the service principal if needed, and rotate everything in vaults it could read and credentials in documents it accessed.
- Identity team, this week: list every app credential, owner and permission, vendor apps included; cut roles to least privilege.
- AppSec, this week: search public code and history for your secrets; revoke what you find.
- Platform, next quarter: move to managed identity for Azure workloads and federation elsewhere, though Todyl saw a federated identity used.
MSPs: review Partner Center access, GDAP (granular delegated admin privileges) relationships and customer tenants; notify affected customers per agreements.
Not known: who is behind it, how many companies, how credentials were obtained, whether AI directed the Oct. 28 activity.
How to read what you find
What you find | What it means | First action |
|---|---|---|
AADSTS7000215 or 7000222 on an app | Someone may hold its secret, or your own app has a stale one | Check source IP; failure then success is urgent |
One IP on 3+ service principals, mixed success | Possibly one operator | Hunt that IP everywhere |
One app requests ARM, Key Vault, Storage and Graph tokens in a short window | Possible enumeration | Review Key Vault and activity logs |
Secret in public repo, no sign-in hits | Exposed; no use seen in the logs you still have. Microsoft says to assume it is compromised | Revoke; check history |
Retries against a rotated app | Someone may still hold the old secret | Keep alerting |
Indicators to hunt
Defanged. Microsoft itself lists the .84 block.
Indicator | Source view | Use |
|---|---|---|
199.19.77[.]84 | Microsoft: sign-ins as early as Oct. 28. Todyl: high confidence; first seen Nov. 1 08:45 UTC, last seen Nov. 3 21:31 UTC | Block exact /32, hunt |
199.19.77[.]18 | Microsoft: sign-ins; Tor exit, may be unrelated. Todyl: low to moderate | Hunt only |
65.87.223[.]26 | Microsoft: "potentially associated." Todyl: low to moderate | Hunt only |
157.22.126[.]128 | Microsoft only: "potentially associated"; recon of AI workloads | Hunt only |
task177-f2267/1.0, sait-tenant-deep/37346 (user agents) | Todyl only: "Unique to the actor"; it says the actor later switched to spoofed browser signatures | Hunt only |
Do not block these: 20.20.34[.]96, 20.20.34[.]160 and 20.231.130[.]224. Todyl says they are Microsoft service addresses where the actor's searches and mail reads get logged, not actor infrastructure.
Block the exact IP, not the ASN. Per Microsoft, put the .84 block in a named location in a Conditional Access policy targeting workload identities, assigned directly to service principals (it has the license limit above), and in a user-scoped block policy to cover replayed sessions. Firewall rules never see app sign-in traffic, Todyl says. Microsoft also says actors change IPs and user agents, and that blocking traffic by tool traits such as default user agents will not stop an agent, which will quickly change them. Microsoft's published queries do not cover .18 or 157.22, so hunt the full list.
