5 min
Amazon Web Services si trova al centro di una sofisticata campagna di cryptomining che dal 2 novembre 2025 sta colpendo gli account AWS attraverso credenziali IAM compromesse. L'operazione, rilevata dai sistemi automatizzati di GuardDuty, rappresenta un'evoluzione significativa nelle tattiche di persistenza utilizzate dai threat actor nel settore crypto, con tecniche progettate specificamente per ostacolare la risposta agli incidenti e massimizzare la durata delle operazioni di mining. La campagna sfrutta sia Amazon Elastic Container Service che Amazon Elastic Compute Cloud per distribuire miner di criptovalute su larga scala, con i primi sistemi operativi già entro 10 minuti dall'accesso iniziale.
Gli ingegneri di sicurezza di AWS hanno individuato pattern di attacco simili distribuiti su molteplici account cliente, confermando una campagna coordinata che utilizza credenziali IAM legittime ma compromesse. È fondamentale sottolineare che non si tratta di una vulnerabilità nei servizi AWS, ma dell'utilizzo non autorizzato di credenziali valide, collocando la responsabilità nel dominio del cliente secondo il modello di responsabilità condivisa del cloud.
L'elemento più innovativo dell'attacco riguarda l'implementazione di tecniche di persistenza avanzate. I threat actor hanno utilizzato l'API ModifyInstanceAttribute su tutte le istanze EC2 lanciate, impostando la protezione dalla terminazione API su true. Questa manovra costringe le vittime a riabilitare manualmente la terminazione prima di poter eliminare le risorse compromesse, creando un ostacolo significativo per i team di incident response e potenzialmente neutralizzando i controlli di remediation automatizzati.
Dal punto di vista operativo, l'attaccante ha dimostrato una preparazione meticolosa. Durante la fase di discovery, ha sistematicamente verificato le quote di servizio EC2 attraverso chiamate GetServiceQuota, per poi testare i permessi IAM utilizzando l'API RunInstances con il flag DryRun abilitato. Questa tecnica di ricognizione deliberata ha permesso di validare le capacità di deployment senza effettivamente lanciare istanze, minimizzando costi e riducendo l'esposizione al rilevamento.
Sulla componente Amazon ECS, la campagna ha distribuito decine di cluster ECS per singolo attacco, superando in alcuni casi i 50 cluster. L'attore ha registrato task definition che utilizzavano l'immagine Docker malevola yenik65958/secret:user, creata il 29 ottobre 2025. L'immagine conteneva un binario SBRMiner-MULTI configurato per eseguire automaticamente uno script run.sh che avvia l'algoritmo di mining randomvirel, collegandosi ai pool: asia.rplant.xyz, eu.rplant.xyz e na.rplant.xyz sulla porta 17155, sfruttando tutti i core processore disponibili.
Per quanto riguarda Amazon EC2, la strategia si è rivelata particolarmente aggressiva. I threat actor hanno creato 2 launch template e 14 auto scaling group configurati con parametri estremi: dimensione massima di 999 istanze e capacità desiderata di 20. La campagna ha differenziato tra Spot Instance, targetizzando istanze GPU e ML ad alte prestazioni come g4dn, g5, p3, p4d e inf1, e istanze On-Demand che puntavano a risorse compute, memory e general-purpose come c5, c6i, r5, m5a e m5n.
L'aspetto più preoccupante riguarda la fase di persistenza. Oltre alla protezione dalla terminazione, l'attaccante ha creato una funzione Lambda con configurazione che bypassa l'autenticazione IAM, generando un endpoint Lambda pubblico. Successivamente ha creato un nuovo utente IAM denominato user-x1x2x3x4, allegando la policy AmazonSESFullAccess e generando access key e login profile, presumibilmente per future attività di phishing attraverso Amazon Simple Email Service.
Le capacità di detection multilivello di GuardDuty hanno identificato con successo tutte le fasi della catena di attacco. La funzionalità Extended Threat Detection, lanciata al re:Invent 2025, ha correlato i segnali attraverso il finding AttackSequence:EC2/CompromisedInstanceGroup. Il sistema ha generato alert attraverso threat intelligence su domini/IP EC2, anomaly detection e sequenze di attacco EC2, dimostrando l'efficacia di un approccio stratificato alla sicurezza.
Dal punto di vista tecnico, i security team dovrebbero monitorare specifici indicatori di compromissione. Oltre ai domini crypto già menzionati, pattern di user agent Boto3 indicano l'utilizzo di script Python per l'automazione dell'intera catena di attacco. Le convenzioni di naming dell'infrastruttura seguono schemi specifici: SPOT-us-east-1-G*-* per le spot instance e OD-us-east-1-G*-* per quelle on-demand.
Le raccomandazioni di AWS per mitigare questi rischi enfatizzano controlli IAM rigorosi: implementare credenziali temporanee invece di access key a lungo termine, imporre autenticazione multi-fattore per tutti gli utenti e applicare il principio del privilegio minimo. L'abilitazione di GuardDuty Runtime Monitoring risulta essenziale per estendere la copertura di detection agli eventi a livello di sistema su EC2, ECS e EKS, fornendo visibility sulle attività sospette a livello host.
Per le organizzazioni che operano nel contesto europeo, questa campagna evidenzia l'importanza di implementare policy preventive attraverso service control policy che neghino la creazione di Lambda URL con AuthType impostato su "NONE". L'integrazione di GuardDuty con AWS Security Hub e Amazon EventBridge, o tooling di terze parti, abilita workflow di risposta automatizzati e remediation rapida dei finding ad alta severità.
Gli account potenzialmente compromessi dovrebbero seguire le procedure di remediation documentate da AWS, includendo controlli specifici per immagini container, policy di scansione e monitoraggio di richieste inusuali di allocazione CPU nelle task definition ECS. La rapidità di deployment dimostrata da questa campagna – con miner operativi in meno di 10 minuti – sottolinea la necessità di detection proattiva e capacità di risposta automatizzata per proteggere efficacemente le infrastrutture cloud da operazioni di cryptomining non autorizzate.