Gli attacchi di credential stuffing hanno avuto un impatto enorme nel 2024, alimentati da un circolo vizioso di infezioni da infostealer e violazioni dei dati. Ma le cose potrebbero peggiorare ulteriormente con Computer-Using Agents, un nuovo tipo di agente AI che consente l'automazione a basso costo e con poco sforzo di comuni attività web, comprese quelle eseguite frequentemente dagli aggressori.
Credenziali rubate: l'arma preferita dai criminali informatici nel 2024.
Le credenziali rubate sono state l'azione degli aggressori numero 1 nel 2023/24 e il vettore di violazione per l'80% degli attacchi alle app Web. Non sorprende se si considera il fatto che miliardi di credenziali trapelate sono in circolazione online e gli aggressori possono accaparrarsi l'ultima goccia per soli $ 10 sui forum criminali.
Il mercato criminale delle credenziali rubate sta beneficiando della pubblicità di violazioni di alto profilo nel 2024, come gli attacchi ai clienti di Snowflake che hanno utilizzato credenziali trovate in dump di violazioni di dati e feed di credenziali compromessi da campagne di infostealer e phishing di massa, che hanno portato alla compromissione di 165 tenant di clienti e a centinaia di milioni di record violati.
Tuttavia, nonostante il 2024 sia un anno senza precedenti in termini di impatto degli attacchi basati sull'identità, c'è ancora molto potenziale inesplorato che gli aggressori devono sfruttare.
Automazione degli attacchi alle credenziali: cosa è cambiato con il passaggio al SaaS?
Brute forcing e credential stuffing non sono una novità, e sono stati una componente chiave del toolkit degli aggressori informatici per decenni. Ma non è più così facile distribuire automaticamente le credenziali sui sistemi come un tempo. Non esiste più una soluzione unica per tutti.
Invece di un'unica rete centralizzata con app e dati contenuti all'interno di un perimetro infrastrutturale, l'IT aziendale è ora costituito da centinaia di app e piattaforme basate sul Web, che creano migliaia di identità per organizzazione.
Ciò significa che anche le identità sono ora decentralizzate e distribuite su Internet, anziché essere archiviate esclusivamente in sistemi di identità come Active Directory e implementate utilizzando protocolli e meccanismi comuni.
Mentre HTTP(S) è standard, le app web moderne sono complesse e altamente personalizzate, con un'interfaccia basata sulla grafica che è diversa ogni volta. E per peggiorare le cose, le app web moderne sono specificamente progettate per prevenire l'automazione dannosa tramite protezioni bot come CAPTCHA.
Quindi, anziché ricorrere a protocolli standard ed essere in grado di scrivere un singolo set di strumenti da utilizzare in qualsiasi organizzazione/ambiente (ad esempio, scrivere uno scanner DNS una volta, utilizzare un singolo scanner di porte come Nmap per l'intera Internet, scrivere un singolo script per servizio (ad esempio FTP, SSH, Telnet, ecc.) per il tuo password sprayer), è invece necessario sviluppare uno strumento personalizzato per ogni app a cui si desidera mirare.
Trovare l'ago nel pagliaio
Non solo ci sono più ambienti che gli aggressori possono includere nell'ambito dei loro attacchi, ma ci sono anche più credenziali con cui lavorare.
Ci sono circa 15 miliardi di credenziali compromesse disponibili su Internet pubblico, senza contare quelle trovate solo nei canali/feed privati. Questa lista è in continua crescita, come 244 milioni di password mai viste prima e 493 milioni di coppie di siti web e indirizzi email unici aggiunti a Have I Been Pwned dai log di infostealer solo il mese scorso.
Sembra spaventoso, ma è difficile per gli aggressori sfruttare questi dati. La stragrande maggioranza di queste credenziali sono vecchie e non valide. Una recente revisione dei dati TI da parte dei ricercatori di Push Security ha scoperto che meno dell'1% delle credenziali rubate incluse nei feed di threat intelligence da un set di dati multi-vendor era utilizzabile, in altre parole, il 99% delle credenziali compromesse erano falsi positivi.
Ma non tutti sono inutili, come hanno dimostrato gli attacchi Snowflake, che hanno sfruttato con successo credenziali risalenti al 2020. Quindi ci sono chiaramente tesori che aspettano di essere scoperti dagli aggressori.
Gli aggressori sono costretti a dare priorità
La natura distribuita delle app e delle identità e la scarsa affidabilità dei dati delle credenziali compromessi fanno sì che gli aggressori siano costretti a stabilire delle priorità, nonostante un ambiente ricco di obiettivi composto da centinaia di app aziendali, che creano migliaia di identità diffuse per organizzazione, perché:Scrivere ed eseguire script python personalizzati per ogni singola app (ci sono più di 40.000 app SaaS su Internet) non è realistico. Anche se si facessero le prime 100 o 1000, sarebbe un compito significativo e richiederebbe una manutenzione costante, mentre si scalferebbe appena la superficie dell'opportunità totale.
Anche quando completamente programmati e utilizzando una botnet per distribuire l'attacco ed evitare il blocco IP, controlli come la limitazione della velocità, CAPTCHA e blocchi degli account possono ostacolare il credential stuffing di massa contro una singola app. E un attacco concentrato su un singolo sito genererà livelli significativi di traffico se si desidera superare 15 miliardi di password in un lasso di tempo ragionevole, quindi è molto probabile che faccia scattare l'allarme.
Quindi gli aggressori tendono a prendere di mira un numero inferiore di app e cercano solo una corrispondenza diretta in termini di credenziali tentate (ad esempio, la credenziale rubata deve appartenere direttamente a un account sull'app di destinazione). Quando vanno a caccia di qualcosa di nuovo, tendono a concentrarsi su un'app/piattaforma specifica (ad esempio, Snowflake) o a cercare un sottoinsieme più ristretto di credenziali (ad esempio, credenziali chiaramente associate a dispositivi edge, per ambienti di rete più tradizionali).
Un'occasione persa?
Come abbiamo stabilito, la situazione relativa agli attacchi di credential stuffing è già piuttosto brutta nonostante queste limitazioni. Ma le cose potrebbero essere significativamente peggiori.
Il riutilizzo della password significa che un singolo account compromesso potrebbe trasformarsi in molti.
Se gli aggressori fossero in grado di aumentare la portata dei loro attacchi per colpire un numero più ampio di app (piuttosto che concentrarsi su una rosa ristretta di app di alto valore), potrebbero trarre vantaggio dal fin troppo comune riutilizzo delle password. Secondo una recente indagine sui dati di identità, in media:1 dipendente su 3 riutilizza le password
Il 9% delle identità ha una password riutilizzata e nessun MFA. Il 10% degli account IdP (utilizzati per SSO) ha una password non univoca
Cosa significa? Se una credenziale rubata è valida, ci sono buone probabilità che possa essere utilizzata per accedere a più di un account, su più di un'app (almeno).
Immagina lo scenario: una recente perdita di credenziali compromesse da infezioni da infostealer o campagne di phishing delle credenziali mostra che una particolare combinazione di nome utente e password è valida su un'app specifica, ad esempio Microsoft 365. Ora, questo account è piuttosto bloccato: non solo ha MFA, ma sono presenti policy di accesso condizionale che limitano l'IP/la posizione da cui è possibile accedervi.
Di solito, è qui che l'attacco finirebbe e tu volgeresti la tua attenzione a qualcos'altro. Ma cosa succederebbe se potessi distribuire queste credenziali su ogni altra app aziendale su cui l'utente ha un account?
Scalabilità degli attacchi alle credenziali con agenti che utilizzano computer
Finora, l'impatto dell'intelligenza artificiale sugli attacchi all'identità è stato limitato all'uso di LLM per la creazione di e-mail di phishing, nello sviluppo di malware assistito dall'intelligenza artificiale e per i bot dei social media: senza dubbio significativo, ma non esattamente trasformativo e che richiede una supervisione e un contributo umani costanti.
Ma con il lancio di OpenAI Operator, un nuovo tipo di "agente che utilizza il computer", le cose potrebbero cambiare.
L'operatore viene formato su un set di dati specialistico e implementato nel suo browser sandbox, il che significa che è in grado di eseguire comuni attività web come un essere umano, visualizzando e interagendo con le pagine come farebbe un essere umano.
A differenza di altre soluzioni automatizzate, Operator non richiede alcuna implementazione o codifica personalizzata per poter interagire con nuovi siti, il che lo rende un'opzione molto più scalabile per gli aggressori che mirano a colpire un'ampia gamma di siti/app.
Demo: utilizzo dell'operatore per condurre attacchi di credential stuffing su larga scala
I ricercatori di Push Security hanno messo alla prova i casi d'uso dannosi di Operator, utilizzandolo per:Identifica quali aziende hanno un tenant esistente in un elenco di app
Tentativo di accesso a vari tenant dell'app con un nome utente e una password forniti
Riepilogo dell'impatto
I risultati sono stati piuttosto sorprendenti. L'operatore ha chiaramente dimostrato la capacità di indirizzare un elenco di app con credenziali compromesse ed eseguire azioni in-app. Ora pensa a questo x10, x100, x10.000... Non si tratta di attività complesse. Ma il valore di CUAs Operator non sta nell'affrontare la complessità, ma nella scala. Immagina un mondo in cui puoi orchestrare le finestre dell'operatore tramite API e fargli eseguire queste azioni simultaneamente (funzionalità che esiste già per ChatGPT).
Ma questo è più grande di Operator: riguarda la direzione della tecnologia. OpenAI potrebbe implementare delle restrizioni: migliori guardrail in-app, limiti di velocità sul numero di attività simultanee e utilizzo totale, ecc. Ma puoi star certo che non sarà l'unica CUA: è solo questione di tempo prima che emergano prodotti simili (forse anche intrinsecamente dannosi) che sfruttano la stessa tecnologia.
Considerazioni finali
È ancora presto per la tecnologia CUA, ma c'è una chiara indicazione che una sfida alla sicurezza già grave potrebbe essere aggravata da questa particolare forma di automazione basata sull'intelligenza artificiale. Mentre la capacità di prendere di mira un ampio set di app è stata in precedenza al di là della portata dell'automazione tradizionale, sta per diventare molto più accessibile anche agli aggressori poco qualificati (pensate: script kiddie di nuova generazione?).
Un altro modo di pensarci è che in effetti fornisce a un aggressore umano una flotta di stagisti di basso livello che non sanno esattamente cosa stanno facendo, ma possono essere istruiti a svolgere compiti specifici e dettagliati su larga scala con solo un controllo occasionale, mentre lavori su altri compiti più complessi. Quindi, un po' come un responsabile di un team rosso di bot AI.
Operator significa che gli aggressori possono sfruttare le credenziali compromesse su larga scala, trarre vantaggio dal vasto numero di identità vulnerabili e non configurate correttamente e convertirle in violazioni sistemiche molto più facilmente. In un certo senso, potrebbe rendere il credential stuffing un po' più simile a quello che era prima del passaggio alle app cloud, dove potevi distribuire migliaia di credenziali sui tuoi obiettivi senza dover ogni volta sviluppare qualcosa di personalizzato.
Fortunatamente, non sono necessarie nuove funzionalità anti-IA, ma è più importante che mai che le organizzazioni cerchino di difendere la propria superficie di attacco all'identità e di individuare e correggere le vulnerabilità dell'identità prima che gli aggressori possano trarne vantaggio.
Nessun commento:
Posta un commento