Read Time:3 Minute, 33 Second

A prompt sent to a public-facing artificial-intelligence agent could once have become a route into other Amazon Bedrock AgentCore resources in the same AWS account and region, according to research from Zenity Labs. The attack chain, called AgentCorruption, illustrates how ordinary agent capabilities can combine into a serious cloud-security failure even when the chat interface itself contains no traditional software vulnerability.

The researchers said the chain exposed private conversations, source code, persistent memory, API keys, OAuth tokens, and values stored in AWS Secrets Manager. AWS has since changed relevant defaults and removed broad permissions identified during disclosure. The episode nevertheless offers an important design lesson: an AI agent is both an application that interprets untrusted language and a cloud workload that may hold powerful credentials.

From an untrusted prompt to workload credentialsAgentCore provides managed infrastructure for creating and operating AI agents. Zenity found that an agent equipped with a web-request or shell tool could be instructed to contact the link-local metadata address at 169.254.169.254. Because the request originated inside the agent’s Firecracker microVM, the metadata service returned temporary credentials associated with the runtime’s execution role.

This amounted to a prompt-driven server-side request forgery path. The model followed an instruction using a capability developers had intentionally provided; the danger came from the destination it could reach and the authority attached to the resulting credentials. Untrusted input, unrestricted network access, and an overpowered role turned a useful tool into a cloud-control channel.

Zenity reported the metadata behavior in December 2025 and raised the wider role-permission issue in January 2026. AWS moved new deployments to the more defensive IMDSv2 flow in February and subsequently required it. By late September, the researchers confirmed that AWS had removed permissions enabling broad agent invocation, conversation access, and Secrets Manager access.

Shared permissions widened the blast radiusThe stolen role was especially consequential because, according to the researchers, its default permissions were not confined to a single agent. They used log-discovery capabilities to identify agent IDs, retrieved container images from Amazon Elastic Container Registry, invoked internal agents, and inspected session events.

Permissions related to AgentCore runtimes and events could expose chats or allow fabricated memories to be inserted. Persistent memory creates a particularly subtle risk: malicious instructions stored today may influence an agent during later conversations, after the original prompt and attacker are no longer visible. Access to resource API keys and Secrets Manager could also turn one compromised agent into a bridge toward connected business services.

AWS disputed describing the behavior as a vulnerability. The company noted that software running within a microVM can access the execution role credentials by design and that cross-account access still requires permissions on both the role and the target. That distinction matters, but it does not remove the customer-side risk created by excessive privilege or by tools that let untrusted prompts reach sensitive network locations.

Controls for production AI agentsCreate a custom IAM role for every production agent and restrict actions to named resources instead of using wildcards.

Block unnecessary outbound destinations, especially metadata and internal management endpoints.

Separate internet-facing agents from internal agents that can reach sensitive data or actions.

Validate tool inputs and route access through controlled gateways that callers cannot bypass.

Monitor CloudTrail and CloudWatch for unusual runtime invocations, secret retrieval, event creation, and image access.

Prompt filtering alone is not a sufficient boundary because models can be manipulated in ways that are difficult to predict exhaustively. The stronger approach assumes that an agent will eventually receive a hostile instruction and limits what its identity, tools, and network position can do when that happens.

Treat agents as privileged workloadsOrganizations should inventory each agent’s tools, credentials, data stores, network routes, and persistent memory. Reviews should occur before deployment and whenever a tool or integration is added, because a seemingly modest capability may compose with existing permissions in unexpected ways.

AgentCorruption demonstrates a recurring pattern in AI security: the model need not “break out” through a novel exploit if developers already gave it access to the pieces needed for an attack chain. Least privilege, isolation, observable tool use, and explicit trust boundaries remain the most dependable defenses.

Un prompt, tutti gli agenti di una regioneL’8 ottobre 2026, in concomitanza con una presentazione al SecTor 2026 di Toronto, i ricercatori di Zenity Labs hanno divulgato pubblicamente AgentCorruption: una catena di vulnerabilità in Amazon Bedrock AgentCore, il servizio gestito con cui #AWS permette di distribuire ed eseguire agenti AI in produzione. Il risultato dimostrato dai ricercatori è di quelli che dovrebbero far riflettere chiunque stia costruendo (o valutando di costruire) agenti autonomi su infrastrutture #cloud: partendo da un singolo prompt dannoso inviato a un agente esposto pubblicamente — ad esempio un chatbot di supporto clienti — è stato possibile ottenere il controllo di tutti gli altri agenti AgentCore dello stesso account e della stessa regione AWS, inclusi quelli interni e più sensibili.

Il problema è stato segnalato ad AWS in modo responsabile il 25 dicembre 2025 e corretto prima della divulgazione pubblica; non risultano exploit osservati “in the wild”. Ma il meccanismo #dell’attacco merita di essere capito in dettaglio, perché illustra un rischio strutturale che va ben oltre il singolo bug e riguarda qualsiasi piattaforma di agenti gestita.

La catena d’attacco, passo per passo1. Dal prompt injection all’Instance Metadata ServiceIl punto di ingresso è una tecnica ormai familiare: un agente pubblico, dotato di un normale strumento per effettuare richieste HTTP in uscita (ad esempio per consultare una base di conoscenza esterna), viene istruito via prompt a effettuare una richiesta verso l’endpoint dell’Instance Metadata Service (IMDS) della macchina sottostante — lo stesso endpoint, raggiungibile tipicamente su 169.254.169.254, che su EC2 restituisce credenziali temporanee legate al ruolo IAM dell’istanza:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/Secondo Zenity, l’agente gira all’interno di una microVM basata su Firecracker priva del necessario isolamento di rete verso questo endpoint: qualsiasi agente in grado di effettuare richieste HTTP in uscita può quindi raggiungere IMDS e farsi restituire le credenziali temporanee del ruolo di esecuzione sottostante, senza bisogno di altre vulnerabilità applicative.

2. “One Role to Rule Them All”: il ruolo IAM condivisoIl vero amplificatore del danno non è l’accesso a IMDS in sé, ma cosa quelle credenziali permettevano di fare. Il ruolo IAM predefinito usato dagli agenti AgentCore non era circoscritto al singolo agente, ma copriva le risorse AgentCore dell’intera regione AWS: con quelle credenziali i ricercatori hanno potuto enumerare ed invocare altri agenti nello stesso account, leggere le loro sessioni attive e accedere a segreti archiviati in AWS Secrets Manager e nelle variabili d’ambiente di altri agenti — comprese chiavi API e token OAuth usati per integrazioni con servizi aziendali e di terze parti.

È lo stesso antipattern che si incontra fin troppo spesso nelle configurazioni IAM “provvisorie”: un ruolo ampio creato per far funzionare rapidamente un servizio, mai più ristretto in un secondo momento. Qui l’impatto è amplificato dal fatto che il ruolo non apparteneva a un singolo workload, ma era condiviso implicitamente da ogni agente della regione.

3. Movimento laterale e furto del codice sorgenteDa lì la catena si allarga ulteriormente: i ricercatori hanno potuto scaricare e leggere le immagini #container degli altri agenti, recuperandone di fatto il codice sorgente, e muoversi lateralmente tra agenti interni e pubblici fino a raggiungere, in teoria, credenziali con privilegi più ampi all’interno dell’organizzazione.

4. Memory poisoning: la persistenza silenziosaL’aspetto forse più insidioso della ricerca è la dimostrazione di un attacco di memory poisoning: modificando la memoria a lungo termine di un agente, i ricercatori hanno inserito istruzioni persistenti che continuavano a inoltrare le conversazioni future a una destinazione controllata dall’attaccante, anche dopo che l’accesso iniziale sarebbe stato chiuso. È un promemoria del fatto che, per gli agenti AI, la “memoria” è una superficie di attacco a sé, separata dal runtime e dalle credenziali, e va trattata con lo stesso rigore di un database che contiene dati utente.

La risposta di AWSSecondo le verifiche di Zenity Labs, AWS ha corretto i problemi principali prima della divulgazione pubblica:

i nuovi deployment di AgentCore usano ora IMDSv2 come impostazione predefinita, che richiede un token di sessione ottenuto con una richiesta PUT autenticata e rende quindi molto più difficile lo sfruttamento da semplice SSRF/prompt injection;

il ruolo di esecuzione predefinito è stato ridotto, rimuovendo la capacità di invocare altri agenti, leggere le conversazioni private di altri agenti e accedere indiscriminatamente a Secrets Manager.

Non è stato pubblicato (almeno nelle fonti disponibili al momento della scrittura) un identificativo #CVE specifico per questa catena, a differenza di altri problemi correlati su AgentCore — come le falle nel SDK Starter Toolkit legate a code injection e SSRF, che hanno invece ricevuto CVE distinti — e come il caso, segnalato separatamente da BeyondTrust, di un bypass #DNS nella modalità “sandbox isolata” del Code Interpreter di AgentCore (CVSS 7.5), che dimostra come la famiglia di problemi legati all’isolamento di rete degli agenti non sia un caso isolato.

Cosa portare a casa, anche se non usi AgentCoreLe lezioni di AgentCorruption si applicano a qualsiasi piattaforma agentica, gestita o self-hosted:

Imposta sempre IMDSv2 su ogni istanza EC2 o ambiente di esecuzione che possa ospitare codice non completamente attendibile (agenti, plugin, codice generato da LLM). Verificalo esplicitamente, non assumerlo:
aws ec2 describe-instances --query
"Reservations[].Instances[].MetadataOptions"

Un ruolo IAM per agente, non un ruolo per servizio. Ogni agente dovrebbe avere un ruolo di esecuzione limitato esclusivamente alle risorse che gli servono, senza possibilità di enumerare o invocare altri agenti dello stesso account. In pratica: niente wildcard su bedrock-agentcore:* a livello di account o regione.

Non esporre agenti privilegiati direttamente al pubblico senza un livello di validazione dell’input e senza aver ridotto al minimo ciò che quell’agente specifico può raggiungere a valle, anche in caso di compromissione totale.

Tratta la memoria dell’agente come dato non attendibile. Se un agente scrive nella propria memoria a lungo termine informazioni derivate da input esterni (utenti, documenti, risposte di altri tool), quella memoria può essere avvelenata esattamente come un database esposto a input utente non sanificato.

Instrumenta per il rilevamento, non solo per la prevenzione. Credenziali “canary” nel ruolo IAM, percorsi S3 esca e DNS sinkhole sono tecniche di deception che permettono di scoprire rapidamente se un agente è stato compromesso, anche quando la prevenzione fallisce.

ConclusioneAgentCorruption non è una falla esotica: è la combinazione, fin troppo comune, di una configurazione IAM troppo permissiva e di un confine di rete meno isolato di quanto documentato. La differenza, con gli agenti AI, è che il punto di ingresso non richiede più un exploit tecnico: basta un prompt. Per chi progetta sistemi agentici, il principio del minimo privilegio applicato per-agente, non per-servizio, passa da “buona pratica” a requisito di sicurezza di base.

Fonti: Dark Reading – “AgentCorruption Puts AWS Environments At Risk With One Prompt”, Zenity Labs e CSO Online.

Read Time:4 Minute, 22 Second

Security researchers at LevelBlue have pulled back the curtain on a credential-harvesting toolkit, internally named TIKTOUK, that turns an everyday WordPress mistake — leaving a site backup or configuration file sitting in a publicly reachable location — into a pipeline for stealing cloud and email credentials at scale. A leaked control panel used to run the operation revealed roughly 50,000 real, server-side credentials gathered from about 37,000 domains, including hundreds of AWS access keys that the researchers confirmed were still active.

Rather than relying on one single exploit, TIKTOUK bundles several different collection techniques together: scanning sites for exposed sensitive files, recovering stored passwords from plugin configurations, and scraping secrets out of JavaScript served to ordinary site visitors. LevelBlue says the operation was already running at meaningful scale by the time it was identified through a combination of source code review, reverse engineering, and controlled lab testing.

Inside the Toolkit’s ArchitectureTIKTOUK is built from two Python components plus a Linux-based crawler written in Go, all of which check in with a central HTTP service to receive tasks and report back findings. The coordination layer distributes targets and collects results, though LevelBlue’s testing didn’t find evidence of a fully automatic handoff between the different components — suggesting a human operator may still be steering parts of the operation.

The probing component handles initial reconnaissance: it pulls a list of targets, confirms which ones are running WordPress, and then sends specially crafted REST API batch requests that combine a malformed URL with delete and content-rendering operations. When a request formatted as JSON gets rejected, the tool automatically retries using multipart encoding instead — and that retry frequently succeeds. That specific fallback pattern, LevelBlue notes, gives defenders a distinctive signature to hunt for in their own web server logs.

Turning a Backup File Into a Credential DumpA separate collection module goes after exposed WordPress configuration backups directly, pulling database credentials and WordPress security keys out of them. It doesn’t stop there — the same component also probes for exposed environment files, repository configuration, raw database backups, and debug logs, essentially sweeping up anything left accessible through a plain web request that shouldn’t be.

Some of its database queries are notably methodical: nested batch requests first retrieve the name WordPress uses for its options table, then feed that name into follow-up queries designed to pull the option values themselves. The tool decodes hexadecimal-encoded responses back into readable text and assembles structured records containing database settings, stored email credentials, AWS key pairs, and recognizable API key patterns.

From Website Compromise to Cloud TakeoverThe blast radius extends well past the compromised website itself. The leaked operator panel contained AWS keys with the potential to be abused for sending email, spinning up compute resources, or accessing AI services tied to the victim’s cloud account. TIKTOUK’s collector can specifically decrypt stored settings from popular SMTP plugins — WP Mail SMTP, Easy WP SMTP, and FluentSMTP — recovering plaintext email credentials using encryption keys or configuration material the tool already has access to. LevelBlue is careful to note this isn’t a cryptographic breakthrough; the toolkit simply gets its hands on what it needs to unlock settings that were never meant to be exposed in the first place. In one particularly efficient step, it can even derive an Amazon SES email password directly from a stolen AWS secret key.

A third piece, the JavaScript crawler, fetches site pages and any scripts they load, scanning the contents for credential patterns tied to services like SendGrid, Anthropic, AWS Bedrock, and AWS more broadly — all secrets that were likely embedded in client-side code by mistake and shipped straight to every visitor’s browser.

Exploitation Links and What’s Still UnconfirmedLevelBlue connected TIKTOUK’s request patterns to two specific vulnerabilities, CVE-2026-60137 and CVE-2026-63030, which affect a batch-route mechanism in WordPress versions 6.9.x prior to 6.9.5 and 7.0.x prior to 7.0.2. Importantly, the firm’s lab testing didn’t go as far as demonstrating a full working exploit — controlled test targets returned pre-prepared responses without actually executing attacker-supplied SQL. That said, separate incident telemetry did confirm the toolkit successfully retrieved payloads and communicated with its controller infrastructure in the wild, and investigators separately identified a related Go-based botnet capable of remote command execution.

In short: the lab results establish exactly how the components behave, not that a specific live production site has been fully breached end-to-end using this chain. Site operators shouldn’t read that distinction as reassuring, though, given the scale of credentials already found in the leaked panel.

What WordPress Site Owners Should CheckConfirm backup files, configuration exports, and debug logs are never stored inside a publicly web-accessible directory.

Update WordPress past the affected 6.9.x and 7.0.x ranges identified in the advisory.

Rotate SMTP plugin credentials and any AWS keys that may have been referenced in configuration files or client-side JavaScript.

Watch server logs for the JSON-then-multipart retry pattern on REST batch endpoints as a potential sign of probing activity.

Audit JavaScript served to visitors for hard-coded API keys or secrets that should never have been placed there.

RE: https://mastodon.uno/@antoniopavolini/117214788502406189

Ricordiamolo: mettere i dati su "AWS European Sovereign Cloud" non li rende magicamente europei. Anche se i server sono in Europa, il CLOUD Act statunitense può imporre a società soggette alla giurisdizione USA di fornire dati alle autorità americane.

Il governo USA e i Big Tech stanno evidentemente cercando di indebolire e marginalizzare ervizi europei sia sul piano politico che su quello economico.

Messaggio rilanciato nel gruppo Sicurezza: @sicurezza@diggita.com

#Amazon #AWS #cloud #cloudact #BigTech

Truffle Security ha passato al setaccio oltre 430.000 fonti pubbliche — repository Git, dataset di training, immagini #Docker, log di CI — e ne ha estratto 64.024 coppie di chiavi #AWS uniche, distribuite su oltre 50.000 account. Il dato che dovrebbe far drizzare le antenne a qualsiasi sistemista non è tanto il numero in sé, quanto quello che è successo quando i ricercatori hanno riverificato un campione di 10.616 chiavi ad agosto 2026: l’88% era ancora valido. Non credenziali di test dimenticate in un branch morto: chiavi vive, utilizzabili, spesso con privilegi amministrativi completi su account aziendali.

È un caso di studio quasi perfetto su come l’igiene delle credenziali #cloud si degradi silenziosamente nel tempo, e su cosa si può fare concretamente — oggi, con gli strumenti che AWS mette già a disposizione — per non finire nella prossima ricerca di questo tipo.

I numeri che contano davveroLa metodologia merita una menzione: i ricercatori non hanno letto policy IAM né toccato dati applicativi, ma hanno usato esclusivamente chiamate di sola lettura come sts:GetCallerIdentity, iam:ListAccessKeys e budgets:DescribeBudgets per confermare che una chiave fosse autentica e capire a cosa desse accesso. Un approccio pulito, che rende i numeri difficili da liquidare come esagerazioni.

Il quadro che emerge sul campione riverificato:

768 chiavi aziendali con controllo amministrativo totale sull’account che le ospitava.

526 di queste erano chiavi di root, cioè l’identità con poteri illimitati che AWS stessa raccomanda di non usare mai in produzione.

130 chiavi root appartenevano addirittura all’account di gestione dell’intera organizzazione AWS, con potenziale impatto su tutti gli account figli collegati via AWS Organizations.

242 utenti IAM avevano la policy AdministratorAccess allegata direttamente o tramite un gruppo.

Su un sottoinsieme di 1.157 utenti IAM di cui è stato possibile enumerare le policy, il 976, cioè l’84%, risultava amministratore.

Ma il dato più interessante per chi fa capacity planning della propria postura di sicurezza è un altro: l’età mediana delle chiavi ancora attive era di circa 5 anni, con punte fino a 17,4 anni. E solo il 13,7% aveva accanto una chiave più recente, segno che il resto — l’86% — non era mai stato ruotato dal giorno della creazione. Le chiavi AWS non scadono da sole: se nessuno le ruota o le revoca attivamente, restano valide per sempre, anche dopo che la persona che le ha create ha lasciato l’azienda o dimenticato il progetto in cui erano incluse.

Da dove escono le chiaviLa fonte principale identificata non è #GitHub, come ci si aspetterebbe, ma Hugging Face: 8.482 chiavi uniche trovate in 3.394 dataset pubblici, con la percentuale più alta di chiavi root fra tutte le sorgenti analizzate (17,9%). Il meccanismo è subdolo: uno sviluppatore include per errore un file di configurazione o un notebook con credenziali hardcoded in un dataset poi scaricato, clonato e reimpacchettato migliaia di volte per l’addestramento di modelli. A quel punto cancellare il file originale non serve a nulla, perché la credenziale è ormai disseminata in decine di copie derivate. Le altre fonti classiche — cronologia Git, immagini Docker, registri dei package manager, log di CI esposti — restano comunque significative.

Perché l’impatto economico è il segnale più sottovalutatoUn altro dato da isolare: sui soli account con spesa mensile leggibile, il totale ammontava a oltre 420.000 dollari al mese, con nove account sopra i 10.000 dollari/mese. La parte più scomoda: solo il 9,5% degli account leggibili aveva un budget alert configurato, anche minimo. La maggior parte delle organizzazioni coinvolte non avrebbe quindi ricevuto alcun segnale automatico in caso di abuso delle credenziali per cryptomining o exfiltration, se non la fattura di fine mese — e un budget alert a 10 dollari costa letteralmente nulla da configurare. È probabilmente il controllo con il miglior rapporto sforzo/beneficio dell’intero articolo, eppure resta il più trascurato.

Il piano d’azione per chi gestisce account AWS in produzione1. Eliminare le chiavi di root, senza eccezioniCome ricordano gli stessi ricercatori, nel 2026 non esiste più alcuna ragione legittima per avere una chiave di accesso root attiva. Ogni operazione che un tempo richiedeva le credenziali root può oggi essere delegata a un utente o ruolo IAM con permessi granulari. Il primo passo è un inventario:

aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'Se il valore restituito è diverso da zero, esiste ancora una chiave di accesso root da eliminare dalla console IAM (sezione «Credenziali di sicurezza» dell’account root). Questo controllo va ripetuto su ogni account collegato via AWS Organizations, inclusi quelli storici creati anni fa e magari dimenticati.

2. Fare l’inventario e la rotazione delle chiavi IAMPer ogni utente IAM, un comando come questo restituisce l’età di ciascuna chiave attiva:

aws iam list-access-keys --user-name nome-utente
--query 'AccessKeyMetadata[].{Id:AccessKeyId,Status:Status,Created:CreateDate}'Per farlo su scala, conviene generare il credential report integrato di IAM, che include per ogni utente la data dell’ultima rotazione e dell’ultimo utilizzo:

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > credential-report.csvDa qui è possibile costruire una policy interna semplice ma efficace: nessuna chiave IAM viva più di 90 giorni senza rotazione, e nessuna chiave inutilizzata da oltre 45 giorni resta attiva. Questi controlli si possono automatizzare con AWS Config, usando le regole gestite access-keys-rotated e iam-user-unused-credentials-check, che segnalano automaticamente le credenziali fuori policy.

3. Sostituire le chiavi statiche con credenziali temporanee dove possibileLa causa profonda del problema non è solo la disattenzione nel pubblicare codice: è l’uso stesso di chiavi statiche a lunga durata dove non servirebbero. Per workload su EC2, ECS o Lambda, i ruoli IAM associati all’istanza o alla funzione eliminano la necessità di distribuire chiavi: le credenziali vengono generate automaticamente, durano poche ore e non finiscono mai su disco. Per l’accesso umano da riga di comando, IAM Identity Center (ex AWS SSO) con aws sso login ottiene lo stesso risultato: credenziali temporanee via autenticazione federata, mai una coppia access key/secret key permanente da custodire.

4. Restringere il raggio d’azione con permission boundary e Access AnalyzerDove le chiavi IAM restano necessarie, i permission boundary impongono un tetto massimo ai privilegi che una policy può concedere a un utente, indipendentemente da eventuali policy troppo permissive aggiunte in futuro per errore. AWS IAM Access Analyzer va usato in modo proattivo per capire chi, all’esterno dell’account, può potenzialmente raggiungere le risorse tramite trust policy troppo larghe:

aws accessanalyzer list-findings
--analyzer-arn arn:aws:access-analyzer:eu-west-1:123456789012:analyzer/nome-analyzer
--filter '{"status":{"eq":["ACTIVE"]}}'5. Impedire che le chiavi finiscano nel commit, non solo dopoTrattare ogni commit come una potenziale fuga di dati è l’unico approccio realistico: il 43% delle chiavi individuate nella ricerca era presente in più posizioni contemporaneamente, segno che, una volta trapelata, una credenziale si propaga rapidamente in fork, mirror e archivi di terze parti. Strumenti come gitleaks o TruffleHog vanno integrati come pre-commit hook, così da bloccare il problema prima che raggiunga il repository remoto:

installazione di un pre-commit hook con gitleaks

gitleaks protect --staged -vGitHub, #GitLab e Gitea offrono inoltre scanning nativo dei secret sui push, con notifica automatica ad AWS quando viene rilevata una chiave valida: è da qui che nasce la policy AWSCompromisedKeyQuarantine, applicata automaticamente da AWS quando una chiave viene rilevata esposta pubblicamente. Nella ricerca, il 12% delle chiavi la portava già — un segnale che, se ignorato, lascia comunque la chiave tecnicamente valida per operazioni di sola lettura in molti casi, e va trattato come un incidente da chiudere subito, non come un avviso a bassa priorità.

ConclusioneIl dato più utile di questa ricerca non è il numero assoluto di chiavi esposte, ma la fotografia di cosa succede quando la rotazione delle credenziali non è un processo automatizzato ma una buona intenzione: dopo cinque anni, in media, nessuno se ne ricorda più. Per chi amministra infrastrutture AWS, il valore pratico sta tutto nella lista di controlli sopra — nessuno dei quali richiede strumenti terzi costosi o una rewrite dell’architettura. Un inventario delle chiavi, un budget alert, un permission boundary e un pre-commit hook sono interventi che si implementano in un pomeriggio e che, secondo questi numeri, la maggior parte delle organizzazioni non ha ancora messo in pratica.

Fonte: Truffle Security — «768 Leaked Corporate AWS Keys Held Full Admin Rights», ripreso da Petri.com.