AI agents (ARTEX) and Key Eater campaign abuse leaked GitHub secrets and Entra ID app credentials, hitting 27 organizations via MSPs
Matéria consolidada. Reúne 6 matérias que o Tifon tinha publicado separadamente sobre a mesma história. A IA reescreveu o relatório com o que as 2 fontes trouxeram em 07/11/2026 12:02; os links antigos trazem para cá.
Microsoft Threat Intelligence reported on 5 November 2026 that threat actors are using the agentic offensive security framework ARTEX, and similar AI tooling, to mass-query public GitHub repositories for exposed credentials, OAuth application secrets and AI inference API keys. The stolen secrets are then abused automatically against the victim's cloud tenant with little human input (cybersecuritydive.com, gbhackers.com). The activity began in August 2026, when high-volume GitHub searches combined a target organization's name with keywords for secrets, cloud services or AI providers. In one intrusion, an AI agent went from scanning GitHub for secrets to exfiltrating Azure Key Vault data in about five minutes (gbhackers.com, cybersecuritydive.com). Stolen Entra ID application credentials were used to sign into Microsoft 365 and Azure environments, including at managed service providers (MSPs). In at least one case a vendor-owned multitenant application was compromised at the source and reused across downstream tenants (cybersecuritydive.com).
The Todyl MXDR team has since named related activity Key Eater, active since 1 November 2026 according to Todyl (gbhackers.com). It uses stolen Entra ID application credentials against MSPs and their downstream clients, with 27 organizations reported impacted across government, energy, agriculture, transportation, engineering, legal, education and nonprofit sectors; 81 files were downloaded and about 2,279 mailbox items accessed (gbhackers.com). No Microsoft vulnerability is exploited: the attacker authenticates as legitimate applications with valid secrets, which makes signature-based detection harder (gbhackers.com, cybersecuritydive.com). Todyl reports the same operator IP 199.19.77[.]84 seen in the Microsoft-reported activity. Attribution for the GitHub scanning and for Key Eater is not established, and the initial credential-theft mechanism for Key Eater remains unresolved; more victims may exist outside monitored environments (gbhackers.com). ARTEX was previously tied to a China-nexus actor, tracked as Storm-0940, that abused ConnectWise Cloud Backup. Todyl found no evidence of persistence or of compromise of the vendor platform itself (gbhackers.com).
Detalhes técnicos
- Earliest observed successful service principal sign-ins in the Microsoft-reported activity came from 199.19.77[.]84 on 28 October 2026, across multiple application IDs and impacted customers. They were used for cloud resource discovery, credential and data exfiltration from Azure Key Vaults and Storage Accounts, and abuse of Azure AI services (cybersecuritydive.com, gbhackers.com).
- Other infrastructure: sign-ins from 199.19.77[.]18, a Tor exit node; reconnaissance against victim Azure AI workloads from 157.22.126[.]128; and operations from 65.87.223[.]26 that included shell commands embedded in a user agent and attempts to obtain App Service authentication tokens (cybersecuritydive.com).
- GitHub queries targeted OAuth application secrets and inference API keys (gbhackers.com).
- After sign-in, the agents enumerated subscriptions, resource groups, permissions, AI deployments and service configurations (gbhackers.com).
- They targeted operations returning storage account keys, App Service settings, connection strings, publishing credentials, AI/ML connections and datastores, and AKS user credentials (both sources).
- They accessed SharePoint and OneDrive content, downloaded files, read mailbox items and used Microsoft Graph search requests to find valuable content (both sources).
- They obtained tokens for single-tenant OAuth applications, searched Azure DevOps for further secrets, and used Azure VM Run Command to execute scripts on virtual machines (cybersecuritydive.com, gbhackers.com).
- Adaptive error correction: failed HTTP 400 responses in ARM telemetry were followed within tens of seconds by retries that returned 200 (cybersecuritydive.com). A failed Key Vault metadata request mixed data-plane API versions with ARM endpoints and succeeded about 28 seconds later with ARM API version 2023-07-01. Similar fixes followed failed Azure SQL firewall enumeration (about 60 seconds) and Application Insights queries (about 80 seconds) (gbhackers.com).
- Key Eater scope (Todyl): about 45 app registrations were targeted across 18 organizations, with successful authentication into more than 33 (gbhackers.com).
- Key Eater technique: the attacker abuses Azure DevOps federated workload identity and replays session tokens (gbhackers.com).
- Token pattern: for nearly every stolen credential, the operator requests an Azure Resource Manager token, then a Key Vault token, and often Microsoft Graph, Storage and Cognitive Services tokens within seconds. Previously unused applications begin authenticating within minutes, suggesting harvested secrets enable further access (gbhackers.com).
- Data collection: 29 single-wildcard Microsoft Graph searches ran across about 25 tenants. SharePoint files were downloaded at roughly one per second, including password lists, private keys, VPN profiles, MFA and remote monitoring API keys, backup credentials, firewall configurations and service-account maps. One multi-tenant MSP application swept 15 customer tenants in loops of about 10 seconds (gbhackers.com).
- Tooling: scripted clients made up 95% of sign-ins. A single operator is believed to control the tooling from a VPS; AI assistance is a low-confidence possibility (gbhackers.com).
- Evasion: after detections on 3 November, the attacker spoofed browser user agents to replace curl/Python signatures and replayed several users' refresh tokens. Conditional Access blocked all observed replays (gbhackers.com).
- Possible LLMjacking: four AI-service tokens were issued across two MSPs, but resource consumption was not confirmed (gbhackers.com).
- Key Eater IOCs: operator IP 199.19.77[.]84; user agents task177-f2267/1.0 and sait-tenant-deep/37346 (gbhackers.com).
Remediação
- Scan GitHub code for secrets, remove them and immediately rotate any exposed keys or credentials (cybersecuritydive.com). Deleting repository content does not invalidate a secret (gbhackers.com).
- Rotate every secret reachable through compromised vaults, not only the credential that was first exposed (gbhackers.com).
- Investigate service principal sign-ins, Key Vault reads, storage downloads, Graph activity and application credential changes, and hunt for the IP addresses and user agents above (gbhackers.com).
- Investigate both successful and failed service-principal sign-ins, and preserve audit logs (gbhackers.com).
- Disable compromised applications and rotate exposed application and downstream credentials (gbhackers.com).
- User-focused Conditional Access alone does not protect against app-only authentication abuse (gbhackers.com).
- Enable GitHub secret scanning, which covers repository history, and monitor public repositories for enterprise members leaking secrets. Use Azure DevOps secret scanning and push protection (gbhackers.com).
- Move to managed identities or workload identity federation, and apply least privilege (gbhackers.com).
- The cybersecuritydive.com remediation text was truncated in the input, so further guidance from it is not captured here.
Relatos divergentes
- Attribution: cybersecuritydive.com says attribution for the GitHub scanning is not established and notes only that ARTEX was previously linked to Storm-0940. gbhackers.com goes further and warns that the earlier ARTEX attribution to Storm-0940 (ConnectWise compromise) should not be applied automatically to this activity. Both agree there is no confirmed actor, and gbhackers.com says the same for Key Eater.
- Todyl's findings: cybersecuritydive.com describes Todyl's report as a similar campaign involving the same IP addresses. gbhackers.com adds that Todyl assessed AI involvement with low confidence and named no framework. gbhackers.com is more specific on this point.
- Start of activity: the Microsoft-reported activity shows successful sign-ins from 199.19.77[.]84 on 28 October 2026 (cybersecuritydive.com, gbhackers.com), while Todyl dates Key Eater to 1 November 2026 (gbhackers.com). The earlier date is the more complete view if both describe the same operator; Todyl's date may reflect only its own telemetry.
- Scope of Key Eater: cybersecuritydive.com says details on the actor, the initial access method and the number of affected organizations remain limited, and describes only multi-sector access via an MSP's clients. gbhackers.com, citing Todyl telemetry, gives the specific figures (27 organizations impacted) and is the more detailed and more authoritative source. Its counts of 18 organizations with targeted app registrations and 27 impacted organizations are not reconciled in the report, so the exact scope remains unconfirmed.
- Vendor compromise: cybersecuritydive.com reports a vendor-owned multitenant application compromised at the source and reused downstream, while gbhackers.com (Todyl) says there is no evidence of compromise of the vendor platform itself. The two may describe different cases.
- Sourcing: gbhackers.com states its summary comes from the article alone and that no Microsoft primary source was opened. cybersecuritydive.com attributes its details to Microsoft's reporting. The Microsoft-attributed details are therefore second-hand in both cases.
Linha do tempo
-
Threat actors use ARTEX agentic AI framework to harvest secrets from public GitHub repos and pivot into Entra ID tenants
ler a análise desta fonte ocultar
Microsoft Threat Intelligence reported on 5 November 2026 that threat actors are using the agentic offensive security framework ARTEX and similar AI tooling to mass-query public GitHub repositories for exposed credentials, OAuth application secrets and AI inference API keys, then automatically abuse them against the victim's cloud tenant. The activity began in August 2026, with the AI framework submitting large volumes of GitHub queries combining a target organization's name with keywords for secrets, cloud services or AI providers (microsoft.com). Stolen Entra ID application credentials were then used to sign into Microsoft 365 and Azure environments, including at managed service providers, with at least one case of a vendor-owned multitenant application compromised at the source and reused across downstream tenants (microsoft.com). Microsoft observed an AI agent progress from scanning GitHub for secrets to exfiltrating data from Azure Key Vault in just five minutes (microsoft.com). The article notes attribution for the GitHub scanning is not established, while ARTEX was previously tied to a China-nexus actor abusing ConnectWise Cloud Backup; Microsoft's earlier reporting names that activity Storm-0940 (microsoft.com).
Technical Details
As early as 28 October 2026, Microsoft observed successful service principal sign-ins from 199.19.77[.]84 involving multiple application IDs across impacted customers, used for cloud resource discovery and credential and data exfiltration from Azure Key Vaults and Storage Accounts, plus abuse of Azure AI services (microsoft.com). Sign-ins also came from 199.19.77[.]18, a Tor exit node; reconnaissance against victim Azure AI workloads came from 157.22.126[.]128, and operations from 65.87.223[.]26 included shell commands embedded in a user agent and attempts to obtain App Service authentication tokens (microsoft.com). The actor targeted operations returning storage account keys, App Service settings, connection strings and publishing credentials, AI/ML connections and datastores and AKS user credentials, then accessed SharePoint and OneDrive content, downloaded files, read mailbox items and issued Microsoft Graph search requests (microsoft.com). ARM telemetry showed adaptive behaviour: failed HTTP 400 responses were followed within tens of seconds by retries with corrected API versions or HTTP methods returning 200 (microsoft.com). Agents also obtained tokens for single-tenant OAuth applications, searched Azure DevOps for further secrets and used Run Command to execute scripts on Azure VMs (microsoft.com). Todyl reported a similar campaign involving the same IP addresses (microsoft.com).
Remediation
Organizations should scan their GitHub code for secrets, remove them and immediately rotate any exposed keys or credentials, treating any secret found in a public repository and its associated application as compromised; removing the original commit alone does not remediate the exposure (microsoft.com). Microsoft recommends enabling GitHub secret scanning and public monitoring, push protection, GitHub Advanced Security / Secret Protection for Azure DevOps, enforcing least privilege on workload identities, enabling Defender for Cloud protections and migrating OAuth applications from client secrets to managed identities (microsoft.com). Defenders should hunt for service principal sign-ins from the listed IP addresses and for unexpected Key Vault, Storage, Graph and Run Command activity by application identities.
-
ARTEX agentic AI framework used to steal Azure Key Vault secrets within 5 minutes of finding leaked GitHub credentials
ler a análise desta fonte ocultar
Microsoft reports that attackers are using the ARTEX agentic AI framework to find exposed credentials on GitHub and compromise Azure environments with little human input. In one intrusion, an AI agent went from searching GitHub for application secrets to exfiltrating Azure Key Vault data in about five minutes. Microsoft saw high-volume GitHub searches from August 2026. It saw follow-on successful Microsoft Entra service principal sign-ins from 199.19.77[.]84 as early as October 28. Todyl reported related abuse from the same address but assessed AI involvement with low confidence and named no framework. The earlier ARTEX attribution to Storm-0940 (ConnectWise compromise) should not be applied automatically to this activity.
Technical Details
- GitHub queries combined organization names with keywords for credentials, cloud services and AI providers. They targeted OAuth application secrets and inference API keys.
- Stolen service principal credentials sometimes belonged to vendor-operated multitenant applications, which extended exposure to downstream customers.
- After sign-in, the agents enumerated subscriptions, resource groups, permissions, AI deployments and service configurations.
- They targeted storage account keys, App Service settings, connection strings, publishing credentials, machine learning connections and AKS user credentials.
- They accessed SharePoint, OneDrive and mailbox items, using Microsoft Graph searches to find valuable content.
- They abused Azure VM Run Command to execute scripts on virtual machines.
- Microsoft saw adaptive error correction. A failed Key Vault metadata request mixed data-plane API versions with ARM endpoints and was retried successfully about 28 seconds later with ARM API version 2023-07-01. Similar fixes followed failed Azure SQL firewall enumeration (about 60 seconds) and Application Insights queries (about 80 seconds).
Remediation
- Revoke or rotate exposed credentials. Deleting repository content does not invalidate them.
- Rotate every secret reachable through compromised vaults, not only the credential that was first exposed.
- Investigate service principal sign-ins, Key Vault reads, storage downloads, Graph activity and application credential changes.
- Enable GitHub secret scanning, which covers repository history. Monitor public repositories for enterprise members leaking secrets. Use Azure DevOps secret scanning and push protection.
- Move to managed identities or workload identity federation, and apply least privilege.
This summary comes from the article alone. No Microsoft primary source was opened.
-
Threat Actor Abuses Microsoft Entra ID to Compromise MSP Clients via Valid Credentials
ler a análise desta fonte ocultar
An attacker has been observed abusing Microsoft Entra ID to target downstream clients of a managed service provider (MSP), using valid credentials to gain unauthorized access to organizations across multiple sectors. The campaign leverages legitimate identity infrastructure rather than exploiting a software vulnerability, making detection harder for defenders relying on signature-based tools. Details on the specific threat actor, initial access method for credential theft, and scope of affected organizations remain limited in current reporting. The incident highlights ongoing risk from supply-chain-style attacks against MSPs that provide identity and access management services to multiple downstream customers.
-
'Key Eater' Campaign Abuses Stolen Microsoft Entra ID App Credentials to Breach 27 Organizations via MSPs
ler a análise desta fonte ocultar
Todyl's MXDR team identified an ongoing campaign dubbed Key Eater, active since November 1, 2026, in which attackers use stolen Microsoft Entra ID application credentials to breach Microsoft 365 and Azure environments through managed service providers (MSPs) and their downstream clients. The campaign has impacted 27 organizations, targeting roughly 45 app registrations across 18 organizations and successfully authenticating into more than 33. No Microsoft vulnerabilities were exploited; instead, the attacker authenticates as legitimate applications using valid secrets, abusing Azure DevOps federated workload identity and replaying session tokens. Victims span government, energy, agriculture, transportation, engineering, legal, education, and nonprofit sectors, with 81 files downloaded and ~2,279 mailbox items accessed.
Technical Details
For nearly every stolen credential, the operator requests an Azure Resource Manager token followed by a Key Vault token, then often Microsoft Graph, Storage, and Cognitive Services tokens within seconds. Previously unused applications begin authenticating within minutes, suggesting harvested secrets enable further access. The attacker executed 29 single-wildcard Microsoft Graph searches across ~25 tenants and downloaded SharePoint files at roughly one per second, collecting password lists, private keys, VPN profiles, MFA and remote monitoring API keys, backup credentials, firewall configurations, and service-account maps. One multi-tenant MSP application swept 15 customer tenants in ~10-second loops. Scripted clients accounted for 95% of sign-ins, with a single operator believed to control scripted tooling from a VPS; AI assistance is a low-confidence possibility. After detections on November 3, the attacker spoofed browser user agents to replace curl/Python signatures and replayed multiple users' refresh tokens, though Conditional Access blocked all observed replays. Four AI-service tokens were issued across two MSPs, possibly indicating LLMjacking, though resource consumption was not confirmed. The confirmed operator IP is 199.19.77.84, with user agents task177-f2267/1.0 and sait-tenant-deep/37346.
Remediation
Administrators should investigate both successful and failed service-principal sign-ins, preserve audit logs, disable compromised applications, and rotate exposed application and downstream credentials. User-focused Conditional Access alone does not protect against app-only authentication abuse. There is no evidence of persistence or compromise of the vendor platform itself, and attribution plus the initial credential theft mechanism remain unresolved, with potential additional victims outside monitored environments.