LLMjacking: quando gli aggressori eseguono LLM a carico della sua fattura AWS

Un account sandbox che normalmente costa 120 $ al giorno fattura 85.000 $ in quattordici ore. Un account membro dormiente, fermo da undici mesi, accumula 75.000 $ prima che qualcuno apra la fattura. L'account di un retailer europeo passa da poche centinaia di dollari al mese a 522.000 $ in meno di due giorni.

Nessuno di questi aggressori ha rubato dati o distribuito ransomware. Hanno sottratto credenziali cloud e le hanno usate per invocare i modelli linguistici di grandi dimensioni più costosi su Amazon Bedrock, lasciando il conto alla vittima. Questo è l'LLMjacking. Nel 2026 è diventato uno degli incidenti di sicurezza più comuni, e più costosi, che arrivano al team di supporto di DoiT.

Questo articolo spiega come funziona l'attacco e cosa abbiamo osservato negli incidenti di quest'anno. Illustra poi i controlli AWS che lo prevengono. Infine, mostra come configurare DoiT Cloud Intelligence™ (DCI) per scoprire l'attacco da un avviso anziché dalla fattura.

Parte 1: i controlli AWS che prevengono l'LLMjacking

Eliminare le credenziali che vale la pena rubare

• Smettere di emettere chiavi utente IAM di lunga durata. Usare IAM Identity Center per le persone. Assegnare ai workloads ruoli IAM con credenziali temporanee: OIDC per GitHub Actions, IRSA o EKS Pod Identity e instance profile. Le best practice IAM di AWS sono esplicite al riguardo.
• Verificare le chiavi già esistenti. Eliminare le chiavi inutilizzate da 90 giorni; non limitarsi a disattivarle. Dopo un incidente AWS ne chiederà comunque l'eliminazione. Non inserire mai chiavi condivise in variabili CI, valori Helm o file di credenziali di agenti/MCP.
• Trattare le chiavi API di Bedrock come segreti. Preferire le chiavi a breve termine, che durano fino a 12 ore, e inventariare e limitare l'ambito di quelle a lungo termine (AWS).
• Attivare il secret scanning e la push protection nel source control (GitHub). Se AWS applica la policy AWSCompromisedKeyQuarantineV3 a uno degli utenti, avviare la risposta all'incidente. La policy limita ciò che la chiave può fare, ma non rimuove l'aggressore (AWS).

Proteggere il root

Usare MFA hardware, nessuna chiave di accesso root e un indirizzo email root su un dominio sotto il proprio controllo e monitorato attivamente. Impostare i contatti alternativi SECURITY e OPERATIONS su ogni account, compresi quelli dormienti, così che gli avvisi di AWS raggiungano qualcuno che li legge davvero.

Mettere guardrail a livello di Organization

Il privilegio minimo in IAM dovrebbe limitare ogni workload ai modelli e alle region specifici di cui ha bisogno (esempi di policy AWS). Le service control policy aggiungono poi una rete di sicurezza che un principal compromesso non può rimuovere. Ecco un punto di partenza, da testare prima in una OU non di produzione:

{
  "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": "*"
    }
  ]
}

Qualche avvertenza. I profili di inferenza cross-region instradano le richieste verso altre region, quindi occorre validare la condizione sulla region rispetto ai profili effettivamente utilizzati (AWS). Alcuni account non dovrebbero mai usare l'AI generativa: sandbox, account dormienti e la maggior parte degli account di produzione al di fuori della piattaforma AI. Per questi, un semplice deny su bedrock:* è più semplice e più sicuro.

Limitare la velocità con cui il denaro può uscire

• Abbassare le quote di token al minuto di Bedrock al necessario per ciascun workload e richiedere un'approvazione per gli aumenti (AWS). Una quota limita il ritmo, non il totale, ma fa guadagnare tempo.
• Mantenere la sperimentazione in account circoscritti con budget propri.

Registrare e rilevare

• Un trail CloudTrail a livello di organizzazione multi-region consegnato a un account di archiviazione log blindato.
• Il logging delle invocazioni dei modelli Bedrock per i workloads approvati (AWS).
• Amazon GuardDuty in ogni account e in ogni region, con le protezioni legate all'AI abilitate. Dopo un incidente, AWS ha verificato la presenza di servizi di sicurezza nell'account membro interessato, non solo in quello di gestione.
• Avvisi sui segnali comparsi presto negli incidenti reali:
  • nuovi accordi Marketplace
  • chiamate GetFederationToken
  • CreateAccessKey chiamata da un ruolo assunto
  • accessi root o modifiche alla MFA
  • aumenti improvvisi del volume di invio SES

Parte 2: configurare DoiT Cloud Intelligence come campanello d'allarme

DCI non sostituirà GuardDuty o CloudTrail. Il suo valore, in questo scenario, sta nell'essere un control plane dei costi esterno agli account AWS. Un aggressore in possesso delle chiavi AWS può leggere e modificare AWS Budgets, e ne abbiamo visto uno fare esattamente questo. Non può però toccare gli avvisi e i budget configurati in DCI.

Avvisi, budget e rilevamento delle anomalie sorvegliano la spesa. Composer e Security Insights chiudono le falle usate dagli aggressori per entrare. CloudFlow trasforma ciascuno di questi elementi in una notifica, un ticket o un'azione di contenimento approvata.

1. Avvisi a soglia che non richiedono una baseline

Gli avvisi scattano su una regola fissa, quindi funzionano dal primo giorno, anche su un modello mai usato prima. È il controllo DCI più affidabile contro l'LLMjacking.

• Creare un'allocation che raggruppi tutta la spesa per modelli AI: Amazon Bedrock e i prodotti Marketplace "(Amazon Bedrock Edition)". I nuovi modelli vi confluiranno automaticamente e gli avvisi non ignoreranno in silenzio il modello che verrà lanciato il mese prossimo.
• Avviso di spesa giornaliera per account: circoscritto a quell'allocation, con Metric impostata su Cost e Interval su Daily. Impostare la condizione su is > $X, dove X è due o tre volte una giornata normale. Attivare Evaluate for each: Account, così una sola regola copre ogni account.
• Avviso "dovrebbe essere zero": per sandbox, account dormienti e tutto ciò che non esegue workloads di AI, impostare l'avviso a > $10 al giorno.
• Impennata da un giorno all'altro: percentage change is > 100%.
• Avviso di forecast: mensile, is forecasted to be > la spesa AI pianificata.

Instradare gli avvisi via email e su un canale Slack che qualcuno guarda davvero (consegna degli avvisi su Slack).

2. Budget su ogni account, soprattutto quelli silenziosi

Impostare un budget mensile ricorrente su ogni account AWS, con soglie al 50%, 85% e 100%. I suggerimenti di budget possono dimensionarli automaticamente. Aggiungere un budget giornaliero sull'allocation AI come secondo campanello d'allarme di facile lettura. Gli account dormienti e sandbox sono i bersagli preferiti degli aggressori proprio perché nessuno vi assegna un budget. Un account da 0 $ con un budget di 50 $ è un ottimo allarme.

I budget non fermeranno la spesa, ma la segnaleranno dall'esterno dell'account compromesso.

3. Tarare il rilevamento delle anomalie perché le notifiche la raggiungano davvero

Il rilevamento delle anomalie di costo resta comunque prezioso, soprattutto per il versante EC2, GPU e SageMaker di un attacco. Tre impostazioni fanno la differenza:

• Ampliare il filtro di gravità. Le notifiche email sono impostate di default solo su Critical. Impostarle su "Warning and above" o "All severity levels" (impostazioni di notifica).
• Attivare la rinotifica, così un'anomalia attiva che continua a crescere torna a farsi sentire.
• Verificare che sia configurato un destinatario. In più di un incidente, DCI ha rilevato l'anomalia ma nessuno ne ha avuto notizia: non era impostato alcun destinatario delle notifiche.

Sui piani Enhanced ed Enterprise, abilitare il rilevamento anomalie in tempo reale per AWS. Si basa su CloudTrail e segnala entro circa un'ora. Oggi copre EC2 e RDS, non Bedrock. Intercetta comunque la metà dell'attacco fatta di GPU e istanze, che spesso corre in parallelo all'abuso dei modelli. È anche possibile abilitare il rilevamento anomalie sull'allocation AI stessa (monitoraggio delle allocation).

Se i workloads di AI sono strumentati con Attribute, DoiT offre anche anomalie di utilizzo a livello di token in early access. Possono segnalare un workload fuori controllo più velocemente dei dati di fatturazione. Vedono però solo il traffico proveniente dagli host strumentati, quindi non intercetteranno una chiave rubata usata dalla macchina di un aggressore.

4. Automatizzare la prima risposta con CloudFlow

CloudFlow può attivarsi su avvisi DCI, soglie di budget e anomalie di costo, trasformando una notifica in un'azione:

• Avviso → Slack → approvazione → contenimento. Quando scatta l'avviso Bedrock, pubblicare account e importo nel canale degli incidenti. Poi, dopo l'approvazione di una persona, eseguire un'azione AWS: disattivare la chiave di accesso sospetta o applicare un deny esplicito su bedrock:InvokeModel* e bedrock:Converse*. I passaggi di approvazione evitano che un falso positivo metta fuori uso la produzione.
• Rilevamento del primo utilizzo di un servizio. Un template di flow pianificato segnala la prima spesa su qualsiasi servizio o SKU AWS. Copre la lacuna dei nuovi modelli descritta sopra.
• Revocare le chiavi API dei provider AI. Un template attivato via webhook, con approvazione integrata, elimina le credenziali Bedrock a lungo termine (e le chiavi OpenAI, Anthropic o Gemini). Può essere richiamato da EventBridge, dal SIEM o da un finding di GuardDuty (tutorial).

Qualsiasi azione di contenimento richiede che il ruolo CloudFlow nell'account di destinazione abbia le autorizzazioni IAM corrispondenti. Queste autorizzazioni vanno definite prima di un incidente.

5. Chiudere le falle prima che un aggressore le trovi

Security Insights importa i finding di AWS Security Hub e Trusted Advisor: chiavi di accesso non ruotate, account root senza MFA e account senza GuardDuty o CloudTrail. Quasi tutti gli incidenti descritti sopra sono iniziati da uno di questi problemi.

Questi finding usano le regole generiche di AWS. Composer permette di scriverne di proprie, sui piani Enhanced ed Enterprise. È il motore di policy di DCI: scansiona le risorse di ogni account connesso e le confronta con le recipe, regole che si costruiscono senza codice. È possibile duplicare una recipe di DoiT e modificarla, oppure descrivere il controllo all'assistente AI. Le corrispondenze compaiono come Security insights.

Ecco come le falle alla base degli incidenti di quest'anno si traducono in recipe realizzabili già oggi:

L'ultima riga è il punto in cui Composer si avvicina di più al rilevamento di un abuso. Una chiave in un account sandbox il cui ultimo utilizzo è stato per Bedrock merita un'occhiata, anche se la spesa non si è ancora mossa.

Per agire sui finding, pianificare un CloudFlow che legga i Security finding aperti tramite il nodo Composer Insights. Pubblicarli su Slack o aprire un ticket ogni mattina. Per le chiavi obsolete, aggiungere un passaggio di approvazione che disattivi la chiave una volta che il proprietario conferma che è inutilizzata.

Composer esegue scansioni periodiche, quindi è un controllo di igiene, non un allarme anti-attacco. Non verifica lo stato di GuardDuty o Security Hub, il logging delle invocazioni Bedrock, le chiavi API Bedrock o il contenuto delle SCP. Per quelli ci sono Security Insights e AWS Config. Usare Composer per chiudere le porte da cui gli aggressori sono entrati quest'anno, e mantenere gli avvisi a soglia descritti sopra per la spesa vera e propria.

Se succede comunque

Avviare il contenimento non appena si sospetta una compromissione. Non aspettare un avviso di anomalia o le cifre definitive di fatturazione.

1. Prima di tutto, contenere. Disattivare, e poi eliminare, le chiavi di accesso compromesse. Revocare le sessioni di ruolo attive con una policy di deny condizionata su aws:TokenIssueTime e disabilitare le eventuali chiavi API Bedrock sospette. Se serve uno strumento drastico, una SCP di emergenza che nega bedrock:* sull'account interessato ferma l'emorragia (ferma anche l'uso legittimo di Bedrock). Aspettarsi che le chiamate continuino ad arrivare per qualche minuto dopo la disattivazione di una chiave.
2. Cercare la persistenza. Controllare nuovi utenti IAM, chiavi di accesso, ruoli e modifiche alle trust policy, accordi Marketplace, identità SES, Capacity Block e istanze in ogni region. Ruotare ogni chiave potenzialmente esposta, non solo quella segnalata da AWS. Abbiamo visto una seconda ondata arrivare sei giorni dopo l'apertura di un incidente, attraverso una chiave che nessuno aveva ruotato.
3. Preservare le prove. Esportare CloudTrail (la Event History conserva solo 90 giorni), i log di invocazione, un inventario delle risorse e un'esportazione dei costi per servizio.
4. Rispondere ad AWS prima della scadenza. Le notifiche di sicurezza di AWS in genere concedono cinque giorni prima della sospensione dei servizi. Le restrizioni possono arrivare giorni dopo l'incidente e colpire servizi di produzione come Lambda, ECS ed EC2.
5. Chiedere esplicitamente la rettifica della fattura. Nei casi che abbiamo visto, AWS si aspetta almeno due controlli di monitoraggio dei costi, come AWS Budgets e Cost Anomaly Detection. Si aspetta anche MFA sul root, GuardDuty o Security Hub. Queste verifiche vengono fatte nell'account interessato. Gli accordi Marketplace creati dall'aggressore vanno annullati. Gli esiti sono andati da crediti totali a crediti parziali fino a dinieghi. Il processo ha richiesto da due a dodici settimane. Una cronologia chiara, un contenimento rapido e prove complete fanno la differenza. AWS ha anche dichiarato che potrebbe non esaminare fatture future se i controlli non sono in atto.

Se il suo account AWS è rivenduto da DoiT, aprire un ticket di supporto DoiT non appena si sospetta una compromissione. Il nostro team si coordina con AWS sul caso di sicurezza e sulla richiesta di rettifica della fattura, e aiuta a raccogliere le prove richieste da AWS.

La checklist anti-LLMjacking

In AWS

• Nessuna chiave utente IAM di lunga durata per persone o workloads. Chiavi vecchie verificate ed eliminate.
• Root: MFA hardware, nessuna chiave di accesso e un indirizzo email monitorato su un dominio di proprietà.
• Contatti alternativi SECURITY e OPERATIONS impostati su ogni account.
• SCP che negano Bedrock dove non serve, limitano le sottoscrizioni Marketplace e bloccano GetFederationToken.
• Quote di token al minuto di Bedrock dimensionate sul fabbisogno.
• CloudTrail a livello di organizzazione, logging delle invocazioni Bedrock e GuardDuty in ogni account e region.

In DoiT Cloud Intelligence

• Un'allocation che copre Bedrock più la spesa Marketplace "(Amazon Bedrock Edition)".
• Avvisi a soglia giornalieri per account su quell'allocation, inclusi gli account "dovrebbe essere zero".
• Un budget su ogni account AWS, dormienti inclusi.
• Notifiche di anomalia impostate su Warning o superiore, con rinotifica e un destinatario reale.
• Rilevamento anomalie in tempo reale su AWS (piani Enhanced ed Enterprise).
• Recipe di Composer per chiavi obsolete e di admin, postura del root, contatti di sicurezza, copertura dei trail e uso di chiavi Bedrock fuori dagli account AI.
• CloudFlow: contenimento da avviso ad approvazione e rilevamento del primo utilizzo di un servizio.

Gli aggressori guadagnano con l'LLMjacking, quindi continueranno a cercare account che nessuno sorveglia. Un rilevamento perfetto non è realistico. Si può però rendere il proprio account un bersaglio costoso, rumoroso e di breve durata. E se qualcosa passa comunque, lo si può scoprire nel giro di ore anziché dalla fattura.

Desidera un supporto per rivedere i guardrail AWS o configurare avvisi DCI, budget e CloudFlow per i workloads di AI? Parli con DoiT.