AML.T0139 Compromise Accounts: Stopping Stolen AI Capacity and Account Resale

A compromised AI account is not just a breach, it is free capacity the attacker spends on your bill and sells to others. MITRE ATLAS AML.T0139 Compromise Accounts covers adversaries taking over existing accounts with services that support targeting or later operations, because those accounts bring established identities, trusted relationships, access to resources or funded wallets for AI services. ATLAS added it in release 2026.10 (28 October 2026) under Resource Development (AML.TA0003), rates it Realized across the Predictive, Generative, Agentic AI and Enterprise platforms, and links it to ATT&CK T1586 Compromise Accounts. This page covers the AI-specific part: account takeover to harvest model capacity, credits and quotas, and the pooling of stolen accounts behind proxies. It is written for teams that own AI accounts and for teams that run AI services. For the general technique see the MITRE ATT&CK T1586 Compromise Accounts Guide; for hardening the credentials themselves see AML.T0012 Valid Accounts.

Source note: ATLAS IDs, names, tactics and case studies on this page were checked against MITRE ATLAS data release 2026.10 (mitre-atlas/atlas-data on GitHub). The technique is new, so confirm against the current ATLAS text before relying on it.

Key takeaways

• The prize is billable capacity. ATLAS lists prepaid balances, service wallets, promotional credits, subscription allowances and usage charged to an existing payment method or enterprise billing account.
• T0139 and T0012 are two views of one event. Compromise Accounts is the attacker acquiring the account as a resource; Valid Accounts is using it to get in. Defend the credential once and you address both.
• Stolen accounts feed proxies. ATLAS notes compromised accounts can supply capacity for AI service proxies that aggregate and resell access while hiding the underlying credentials.
• Distillation campaigns use them too. ATLAS case study AML.CS0075 records actors compromising user credentials for Google AI services and rotating queries across thousands of accounts.
• Spend is a security signal. Sysdig advises reviewing unexpected spikes in LLM usage, inference calls or cloud spend with both security and finance teams.

What ATLAS says, and what is AI-specific

ATLAS names four ways credentials are obtained: AML.T0052 Phishing, password guessing or reuse, theft of access tokens, and purchase from third parties. The AI-specific content is about what the account is then used for:

• LLMjacking: consuming model access at the account holder's expense, for the attacker's own inference, code generation or tool development, while exhausting credits and quotas or generating extra charges.
• Proxy supply: compromised accounts provide capacity for AI service proxies (ATLAS sub-technique AML.T0008.005), letting operators pool and resell access.
• Cover for coordinated collection: Google reported distillation campaigns that rotated requests across compromised credentials and fraudulent accounts through proxy infrastructure.
• Gray-market pooling: account merchants and registration intermediaries supply access alongside discounted capacity, unused quotas and shared subscriptions.

Cases in ATLAS

LLMjacking (AML.CS0030). Sysdig Threat Research found attackers using stolen cloud credentials to reach cloud-hosted models, checking which models were enabled and setting up a reverse proxy to sell model access to other criminals. Its tooling covered AI21 Labs, Anthropic, AWS Bedrock, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter and GCP Vertex AI. ATLAS records Sysdig's estimate of up to $46,000 a day in worst-case harm for unauthorised use of a single Claude 2.x model, and maps the step to AML.T0139: the stolen credentials supplied accounts that gave LLM capacity at the holders' expense and supported proxy-mediated access. In February 2026 Sysdig described the market maturing, with stolen compute and API access resold through a marketplace on Telegram and Discord. See LLMjacking 2024 to 2026.

Distillation against Google AI services (AML.CS0075). Google Threat Intelligence Group and Google DeepMind reported unknown actors compromising user credentials for Google AI services and spreading queries across thousands of compromised and fraudulent accounts in different product channels. ATLAS records Google reporting, by September 2026, coordinated distillation campaigns of more than 100 million prompts. See the Model Extraction and Distillation Defence Guide.

Resale of AI access (related incident). Microsoft reported that the Storm-2139 network used exposed customer credentials scraped from public sources to access generative AI services, changed what the services could do and sold access to others. The customer-side lesson is that published credentials are found and monetised. See Microsoft Azure OpenAI Abuse 2025.

Preventing account compromise and limiting the payout

For organisations that own AI accounts

• Remove long-lived keys: prefer workload identity and short-lived tokens; where keys remain, scope one key per application and environment. Sysdig recommends shorter lifetimes and tighter IAM scope.
• Phishing-resistant MFA on consoles: AI console administrators can create keys, raise limits and change logging, so treat them as privileged. See the LLMjacking Guide.
• Cap the wallet: set provider spend limits, cloud budgets and alerts per project, and avoid auto-recharge on prepaid balances without approval.
• Restrict models: allow only the models each project needs, so a stolen credential cannot switch on expensive ones.
• Turn on invocation logging: Amazon Bedrock model invocation logging is disabled by default; once enabled through PutModelInvocationLoggingConfiguration it records request, response and metadata, including identity.arn and token counts, to CloudWatch Logs or S3.
• Scan for exposure: search code, images, notebooks and agent configuration for AI keys. See AML.T0055 Unsecured Credentials.

For AI service providers

• Detect takeover signals: new device, location or ASN for a long-standing account, followed by a change in usage profile.
• Correlate accounts: look for many accounts sharing infrastructure, request patterns or prompt suites, a sign of pooling behind a proxy (see AML.T0021 Establish Accounts for the fraudulent-registration side).
• Notify and reset: alert the legitimate holder, revoke sessions and keys, and refund or credit where policy allows.

Detection

For a step-by-step response, use the LLMjacking Response Playbook: revoke and rotate the credential, disable unused models, check for new keys or users created by the attacker, review invocation logs for data exposure and contact the provider about charges.

Metrics

• Share of AI workloads using short-lived or federated identity instead of static keys.
• Share of AI projects with a spend limit and an alert owned by a named person.
• Share of AI accounts and regions with invocation logging enabled.
• Median time from spend anomaly to credential revocation.
• Exposed AI keys found by scanning per month, and time to rotate.

Framework mapping

ATLAS release 2026.10 maps no mitigation directly to AML.T0139. The MITRE ATLAS Mitigations Guide covers the controls mapped to the related techniques.

Common failure patterns

• Billing alerts nobody owns. Spend notifications go to a finance mailbox and the security team learns of the compromise from the invoice.
• Every model enabled everywhere. A stolen key can call the most expensive models in every region.
• One shared key for many applications. Rotation breaks production, so it is delayed while the attacker keeps spending.
• Logging off to save cost. Without invocation logs there is no way to tell what the attacker generated or whether data was queried.
• Rotating the key but not checking for persistence. Attackers with console access may have created extra keys or users.

Practitioner checklist

• Inventory every AI account, project, key and subscription with an owner.
• Replace static AI keys with federated or short-lived credentials where supported.
• Require phishing-resistant MFA for AI console administrators.
• Set spend limits and budget alerts on every AI project and route them to security as well as finance.
• Allow only required models and regions.
• Enable invocation logging and alert on changes to it.
• Scan repositories, images and agent configs for AI keys continuously.
• Rehearse the LLMjacking response, including checks for attacker-created keys.

Standards and references

• MITRE ATLAS: Compromise Accounts (AML.T0139)
• MITRE ATLAS: LLMjacking case study (AML.CS0030)
• MITRE ATT&CK: Compromise Accounts (T1586)
• AWS: Monitor model invocation using CloudWatch Logs and Amazon S3
• Sysdig: What is LLMjacking?
• Sysdig: LLMjacking, from emerging threat to black market reality
• Microsoft On the Issues: Disrupting a global cybercrime network abusing generative AI

Related NHI Mgmt Group resources: AML.T0140 Centralized AI Service Request Routing · AML.T0135 Outputs from AI Models · MITRE ATT&CK T1586 Compromise Accounts Guide · LLMjacking Guide · AI API key abuse · MITRE ATLAS Guide