LLMjacking: quando invasores rodam LLMs na sua fatura da AWS

Uma conta sandbox que normalmente custa US$ 120 por dia fatura US$ 85.000 em quatorze horas. Uma conta-membro inativa, sem movimentação há onze meses, acumula US$ 75.000 antes que alguém abra a fatura. A conta de um varejista europeu salta de algumas centenas de dólares por mês para US$ 522.000 em menos de dois dias.

Nenhum desses invasores roubou dados ou implantou ransomware. Eles obtiveram credenciais de nuvem, usaram-nas para chamar os modelos de linguagem mais caros do Amazon Bedrock e deixaram a fatura para a vítima. Isso é LLMjacking. Em 2026, ele se tornou um dos incidentes de segurança mais comuns — e mais caros — que chegam à equipe de suporte da DoiT.

Este post explica como o ataque funciona e o que vimos nos incidentes deste ano. Depois, percorre os controles da AWS que o previnem. Por fim, mostra como configurar o DoiT Cloud Intelligence™ (DCI) para que você descubra por um alerta, e não pela fatura.

Parte 1: controles da AWS que previnem o LLMjacking

Elimine as credenciais que valem a pena roubar

• Pare de emitir chaves de usuário IAM de longa duração. Use o IAM Identity Center para pessoas. Dê aos workloads roles do IAM com credenciais temporárias: OIDC para GitHub Actions, IRSA ou EKS Pod Identity e perfis de instância. As melhores práticas de IAM da AWS são explícitas quanto a isso.
• Audite as chaves que você já tem. Exclua chaves sem uso há 90 dias; não pare na desativação. A AWS vai pedir a exclusão depois de um incidente de qualquer forma. Nunca coloque chaves compartilhadas em variáveis de CI, values do Helm ou arquivos de credenciais de agentes/MCP.
• Trate as chaves de API do Bedrock como segredos. Prefira chaves de curta duração, que valem por até 12 horas, e inventarie e restrinja o escopo das de longa duração (AWS).
• Ative a varredura de segredos e a push protection no seu controle de versão (GitHub). Se a AWS anexar a política AWSCompromisedKeyQuarantineV3 a um dos seus usuários, inicie a resposta a incidentes. A política limita o que a chave pode fazer, mas não remove o invasor (AWS).

Proteja o root

Use MFA por hardware, nenhuma chave de acesso root e um endereço de e-mail root em um domínio que você controla e monitora ativamente. Configure os contatos alternativos SECURITY e OPERATIONS em todas as contas, incluindo as inativas, para que os avisos da AWS cheguem a alguém que os leia.

Coloque guardrails no nível da Organização

O princípio de menor privilégio no IAM deve limitar cada workload aos modelos e regiões específicos de que ele precisa (exemplos de política da AWS). As service control policies adicionam então uma barreira que um principal comprometido não consegue remover. Aqui está um ponto de partida, a ser testado primeiro em uma OU de não produção:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMarketplaceSubscribeExceptPlatformRole",
      "Effect": "Deny",
      "Action": "aws-marketplace:Subscribe",
      "Resource": "*",
      "Condition": {
        "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/ai-platform-admin" }
      }
    },
    {
      "Sid": "DenyBedrockOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] }
      }
    },
    {
      "Sid": "DenyFederationTokenConsoleBypass",
      "Effect": "Deny",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    }
  ]
}

Algumas ressalvas. Os perfis de inferência entre regiões roteiam requisições para outras regiões, então valide a condição de região em relação aos perfis que você realmente usa (AWS). Algumas contas nunca deveriam usar IA generativa: sandboxes, contas inativas e a maioria das contas de produção fora da sua plataforma de IA. Para essas, um deny simples em bedrock:* é mais fácil e mais seguro.

Limite a velocidade com que o dinheiro pode sair

• Reduza as cotas de tokens por minuto do Bedrock ao que cada workload precisa e exija aprovação para aumentos (AWS). Uma cota limita a taxa, não o total, mas faz você ganhar tempo.
• Mantenha a experimentação em contas delimitadas com orçamentos próprios.

Registre e detecte

• Uma trilha de CloudTrail da organização multirregião entregue a uma conta de arquivo de logs com acesso restrito.
• Registro de invocação de modelos do Bedrock para workloads aprovados (AWS).
• Amazon GuardDuty em todas as contas e em todas as regiões, com as proteções relacionadas a IA habilitadas. Depois de um incidente, a AWS verificou a presença de serviços de segurança na conta-membro afetada, não apenas na conta de gerenciamento.
• Alertas sobre os sinais que apareceram cedo em incidentes reais:
  • novos acordos no Marketplace
  • chamadas a GetFederationToken
  • CreateAccessKey chamado por uma role assumida
  • logins do root ou mudanças de MFA
  • saltos repentinos no volume de envio do SES

Parte 2: como configurar o DoiT Cloud Intelligence como seu alarme antecipado

A DCI não vai substituir o GuardDuty nem o CloudTrail. Seu valor aqui é ser um plano de controle de custos fora das suas contas AWS. Um invasor com suas chaves AWS pode ler e editar o AWS Budgets, e já vimos um fazer exatamente isso. Mas ele não consegue tocar nos alertas e orçamentos que você configurou na DCI.

Alertas, orçamentos e detecção de anomalias vigiam o gasto. Composer e Security Insights fecham as brechas que os invasores usam para entrar. O CloudFlow transforma qualquer um deles em uma notificação, um ticket ou uma etapa de contenção aprovada.

1. Alertas de limite que não precisam de linha de base

Os alertas disparam com base em uma regra fixa, então funcionam desde o primeiro dia, em um modelo que você nunca usou. É o controle da DCI mais confiável contra LLMjacking.

• Crie uma alocação que agrupe todo o gasto com modelos de IA: Amazon Bedrock e os produtos do Marketplace "(Amazon Bedrock Edition)". Novos modelos passam a entrar nela automaticamente, e seus alertas não deixam passar em silêncio o lançamento de modelo do mês que vem.
• Alerta de gasto diário por conta: restrinja o escopo a essa alocação, com Metric em Cost e Interval em Daily. Defina a condição como is > $X, em que X é duas a três vezes um dia normal. Ative Evaluate for each: Account para que uma única regra cubra todas as contas.
• Alerta de "deveria ser zero": para sandboxes, contas inativas e qualquer coisa que não rode workloads de IA, alerte em > $10 por dia.
• Salto de um dia para o outro: percentage change is > 100%.
• Alerta de previsão: mensal, is forecasted to be > seu gasto planejado com IA.

Encaminhe os alertas para e-mail e para um canal do Slack que alguém realmente acompanhe (entrega de alertas no Slack).

2. Orçamentos em todas as contas, especialmente nas silenciosas

Coloque um orçamento mensal recorrente em cada conta AWS, com limites em 50%, 85% e 100%. As sugestões de orçamento podem dimensioná-los para você. Adicione um orçamento diário na alocação de IA como um segundo alarme fácil de acompanhar. Contas inativas e de sandbox são os alvos favoritos dos invasores justamente porque ninguém cria orçamento para elas. Uma conta de US$ 0 com um orçamento de US$ 50 é um alarme excelente.

Os orçamentos não vão impedir o gasto, mas vão avisar você de fora da conta comprometida.

3. Ajuste a detecção de anomalias para que ela realmente chegue até você

A detecção de anomalias de custo continua merecendo seu lugar, especialmente para o lado de EC2, GPU e SageMaker de um ataque. Três configurações importam:

• Amplie o filtro de severidade. As notificações por e-mail vêm por padrão apenas com Critical. Configure-as para "Warning and above" ou "All severity levels" (configurações de notificação).
• Ative a renotificação, para que uma anomalia ativa que continua crescendo avise você de novo.
• Garanta que haja um destinatário configurado. Em mais de um incidente, a DCI detectou a anomalia, mas ninguém ficou sabendo. Nenhum destino de notificação estava configurado.

Nos planos Enhanced e Enterprise, habilite a detecção de anomalias em tempo real para AWS. Ela trabalha a partir do CloudTrail e reporta em cerca de uma hora. Hoje ela cobre EC2 e RDS, não o Bedrock. Ainda assim, pega a metade do ataque de GPU e instâncias, que costuma rodar em paralelo ao abuso dos modelos. Você também pode habilitar a detecção de anomalias na própria alocação de IA (monitoramento de alocações).

Se você instrumenta workloads de IA com o Attribute, a DoiT também oferece anomalias de uso no nível de token em acesso antecipado. Elas podem sinalizar um workload descontrolado mais rápido do que os dados de billing. Elas só enxergam o tráfego dos seus próprios hosts instrumentados, então não vão pegar uma chave roubada usada a partir da máquina de um invasor.

4. Automatize a primeira resposta com o CloudFlow

O CloudFlow pode ser acionado por alertas da DCI, limites de orçamento e anomalias de custo, o que transforma uma notificação em uma ação:

• Alerta → Slack → aprovação → contenção. Quando o alerta do Bedrock disparar, publique a conta e o valor no seu canal de incidentes. Depois, com a aprovação de uma pessoa, execute uma ação na AWS: desative a chave de acesso suspeita ou anexe um deny explícito em bedrock:InvokeModel* e bedrock:Converse*. As etapas de aprovação impedem que um falso positivo derrube a produção.
• Detecção de primeiro uso de serviço. Um template de fluxo agendado sinaliza o primeiro gasto em qualquer serviço ou SKU da AWS. Isso cobre a lacuna dos modelos novos descrita antes.
• Revogue chaves de API de provedores de IA. Um template acionado por webhook, com aprovação embutida, exclui credenciais de longa duração do Bedrock (e chaves da OpenAI, Anthropic ou Gemini). Você pode chamá-lo a partir do EventBridge, do seu SIEM ou de um finding do GuardDuty (tutorial).

Qualquer ação de contenção exige que a role do CloudFlow na conta de destino tenha as permissões IAM correspondentes. Decida essas permissões antes de um incidente.

5. Feche as brechas antes que um invasor as encontre

O Security Insights traz findings do AWS Security Hub e do Trusted Advisor. Eles incluem chaves de acesso que não foram rotacionadas, contas root sem MFA e contas sem GuardDuty ou CloudTrail. Quase todos os incidentes descritos acima começaram com um desses problemas.

Esses findings usam as regras genéricas da AWS. O Composer permite que você escreva as suas próprias, nos planos Enhanced e Enterprise. É o mecanismo de políticas da DCI. Ele varre os recursos de cada conta conectada e os compara com receitas, que são regras que você monta sem código. Você pode duplicar uma receita da DoiT e editá-la, ou descrever a verificação para o assistente de IA. As correspondências aparecem como Security insights.

Veja como as brechas por trás dos incidentes deste ano se traduzem em receitas que você pode criar hoje:

A última linha é o mais perto que o Composer chega de identificar abuso. Uma chave em uma conta sandbox cujo último uso foi para o Bedrock merece uma olhada, mesmo que o gasto ainda não tenha mudado.

Para agir sobre os findings, agende um CloudFlow que leia os Security findings abertos pelo nó Composer Insights. Publique-os no Slack ou abra um ticket toda manhã. Para chaves obsoletas, adicione uma etapa de aprovação que desative a chave assim que o dono confirmar que ela não é usada.

O Composer executa varreduras periódicas, então é um controle de higiene, não um alarme de ataque. Ele não verifica o status do GuardDuty ou do Security Hub, o registro de invocações do Bedrock, as chaves de API do Bedrock nem o conteúdo das SCPs. O Security Insights e o AWS Config cobrem isso. Use o Composer para fechar as portas pelas quais os invasores entraram neste ano e mantenha os alertas de limite acima para o gasto em si.

Se acontecer mesmo assim

Comece a contenção assim que suspeitar de um comprometimento. Não espere por um alerta de anomalia nem pelos números finais de billing.

1. Contenha primeiro. Desative e, em seguida, exclua as chaves de acesso comprometidas. Revogue as sessões de role ativas com uma política de deny condicionada a aws:TokenIssueTime e desabilite qualquer chave de API do Bedrock suspeita. Se precisar de um instrumento mais drástico, uma SCP de emergência que negue bedrock:* na conta afetada estanca a sangria (e também interrompe o uso legítimo do Bedrock). Espere que as chamadas continuem chegando por alguns minutos depois que uma chave for desabilitada.
2. Cace mecanismos de persistência. Procure novos usuários IAM, chaves de acesso, roles e mudanças de política de confiança, acordos do Marketplace, identidades do SES, Capacity Blocks e instâncias em todas as regiões. Rotacione todas as chaves que podem ter sido expostas, não só a que a AWS sinalizou. Já vimos uma segunda onda chegar seis dias depois do início de um incidente aberto, por uma chave que ninguém rotacionou.
3. Preserve as evidências. Exporte o CloudTrail (o Event History só guarda 90 dias), os logs de invocação, um inventário de recursos e uma exportação de custos por serviço.
4. Responda à AWS antes do prazo. Os avisos de segurança da AWS normalmente dão cinco dias antes de os serviços serem suspensos. As restrições podem chegar dias depois do incidente e podem afetar serviços de produção como Lambda, ECS e EC2.
5. Peça o ajuste de billing explicitamente. Nos casos que vimos, a AWS espera pelo menos dois controles de monitoramento de custos, como AWS Budgets e Cost Anomaly Detection. Ela também espera MFA no root, GuardDuty ou Security Hub. Eles verificam isso na conta afetada. Os acordos do Marketplace criados pelo invasor precisam ser cancelados. Os desfechos variaram de créditos integrais a créditos parciais e recusas. O processo levou de duas a doze semanas. Uma linha do tempo clara, contenção rápida e evidências completas fazem a diferença. A AWS também disse que pode não analisar faturas futuras se os controles não estiverem em vigor.

Se sua conta AWS é revendida pela DoiT, abra um ticket de suporte da DoiT assim que suspeitar de comprometimento. Nossa equipe coordena com a AWS o caso de segurança e o pedido de ajuste de billing, e ajuda você a reunir as evidências que a AWS solicita.

Seu checklist contra LLMjacking

Na AWS

• Nenhuma chave de usuário IAM de longa duração para pessoas ou workloads. Chaves antigas auditadas e excluídas.
• Root: MFA por hardware, sem chaves de acesso e um endereço de e-mail monitorado em um domínio que você possui.
• Contatos alternativos SECURITY e OPERATIONS configurados em todas as contas.
• SCPs que negam o Bedrock onde ele não é necessário, restringem assinaturas do Marketplace e bloqueiam GetFederationToken.
• Cotas de tokens por minuto do Bedrock dimensionadas conforme a necessidade.
• CloudTrail da organização, registro de invocações do Bedrock e GuardDuty em todas as contas e regiões.

No DoiT Cloud Intelligence

• Uma alocação cobrindo o Bedrock mais o gasto do Marketplace "(Amazon Bedrock Edition)".
• Alertas diários de limite por conta nessa alocação, incluindo as contas que "deveriam ser zero".
• Um orçamento em cada conta AWS, incluindo as inativas.
• Notificações de anomalia configuradas para Warning ou acima, com renotificação e um destinatário de verdade.
• Detecção de anomalias em tempo real na AWS (planos Enhanced e Enterprise).
• Receitas do Composer para chaves obsoletas e de admin, postura do root, contatos de segurança, cobertura de trilhas e uso de chaves do Bedrock fora das suas contas de IA.
• CloudFlow: fluxo de contenção com aprovação a partir de alertas e detecção de primeiro uso de serviço.

Invasores ganham dinheiro com LLMjacking, então vão continuar procurando contas que ninguém vigia. Detecção perfeita não é realista. Ainda assim, você pode tornar sua conta um alvo caro, barulhento e de vida curta. E, se algo passar, você pode ficar sabendo em horas, e não pela fatura.

Quer ajuda para revisar seus guardrails na AWS ou para configurar alertas, orçamentos e CloudFlow da DCI para workloads de IA? Fale com a DoiT.