Marcus Chen, YuSMP Group
Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Progetta e mette in sicurezza piattaforme backend e cloud per team di prodotto negli Stati Uniti e nell'UE
Un corridoio di server con pannelli simili a casseforti attraversato da uno sciame di piccole sonde luminose, immagine degli attacchi automatizzati che scandagliano i sistemi esposti

Gli attacchi in breve

Tra il 1° e il 5 ottobre 2026 sette istituti finanziari sudcoreani hanno confermato violazioni di dati che, secondo il Korea Herald, riguardano circa 66.000 persone e 2.200 record aziendali. Shinhan Bank è stata la prima a comunicarlo, il 1° ottobre; entro il 5 ottobre l'hanno seguita KB Kookmin, Hana, BNK Busan, Yegaram Savings, Welcome Savings e Hyundai Capital. La polizia nazionale coreana ha assegnato al caso 28 investigatori, divisi in quattro squadre della sua unità contro il cyberterrorismo.

A rendere insolita questa ondata è lo strumento sospettato. Il 2 ottobre Bloomberg, citando Yonhap, ha riferito che nell'intrusione a Shinhan si sospetta l'uso di strumenti di IA, e alcuni ricercatori hanno trovato sull'infrastruttura collegata un titolo di pagina in cinese traducibile come «console di penetration test autonomo con IA». Il presidente Lee Jae Myung ha dichiarato che sono emersi segnali di uso dell'IA e ha ordinato un'indagine approfondita.

I punti di ingresso, invece, erano ordinari: applicazioni periferiche esposte su Internet con autenticazione debole. È esattamente la superficie che un penetration test e security audit deve individuare prima che lo faccia un attaccante automatizzato.

Quali istituti sono stati colpiti e cosa è trapelato?

Shinhan Bank ha comunicato il primo incidente il 1° ottobre, con circa 25.700 clienti coinvolti. Nei giorni successivi hanno segnalato incidenti KB Kookmin Bank, Hana Bank e BNK Busan Bank, poi le banche di risparmio Yegaram e Welcome e la società di credito Hyundai Capital. Anche Woori Bank e NH NongHyup Bank sarebbero state prese di mira, senza fughe di dati confermate.

I campi esposti sono quelli che interessano ai truffatori: nomi e numeri di telefono abbinati a reddito, massimali di credito e, in alcuni casi, numeri di registrazione dei residenti. I numeri variano molto da un istituto all'altro — alcune comunicazioni riguardavano solo poche decine di persone — e la stampa locale riporta cifre diverse per singola banca; citiamo quindi il totale pubblicato dal Korea Herald il 6 ottobre.

La Financial Services Commission ha convocato una riunione d'emergenza e ha chiesto a tutti gli operatori finanziari di ispezionare i sistemi accessibili dall'esterno, ridurre l'esposizione superflua dei dati, verificare i controlli di autenticazione e condividere informazioni sulle minacce. Il Financial Supervisory Service ha individuato 28 indirizzi IP legati ai tentativi e fissato una scadenza ravvicinata per le verifiche interne.

Che ruolo ha avuto l'IA?

La pista dell'IA si basa su indizi forensi, non su un'attribuzione confermata. Un server ritenuto parte dell'intrusione a Shinhan riportava un titolo HTML in cinese che descrive una console di penetration test autonomo con IA. I ricercatori lo hanno collegato ad ARTEX, un framework open source che usa agenti LLM per automatizzare ricognizione, ricerca di vulnerabilità, pianificazione dei percorsi d'attacco, esecuzione degli strumenti e verifica degli exploit. BleepingComputer ha sottolineato il 5 ottobre che le autorità non hanno confermato l'uso dello strumento, e gli esperti locali descrivono un operatore umano che lo guida.

La sfumatura è importante. Lo scenario più probabile non è un hacker IA del tutto autonomo, ma un piccolo team che usa strumenti agentici per scansionare molti obiettivi, concatenare le scoperte e provare i percorsi di login a un ritmo che un tempo richiedeva molte più persone. La stessa categoria di strumenti è venduta e pubblicata open source per attività legittime di red teaming. Il suo arrivo sul fronte offensivo accorcia il tempo tra «esiste un endpoint debole» e «viene sfruttato».

Come sono entrati gli attaccanti?

Secondo il Korea Times, i punti di ingresso segnalati erano ai margini delle banche, non nei sistemi core:

  • Shinhan: un bypass dell'autenticazione su un servizio di verifica dello stato delle pratiche per gli agenti di credito — una pagina di consultazione per i partner.
  • KB Kookmin: accessi esterni anomali a un sistema mobile per i dipendenti.
  • Hana: accesso non autorizzato a un sistema di supporto commerciale.

La stampa locale parla anche di credential stuffing — login automatizzati con password trapelate. Niente di tutto ciò richiede exploit inediti. Basta trovare applicazioni accessorie che restituiscono dati dei clienti, si fidano del client o non hanno rate limiting — un lavoro che un agente IA svolge senza sosta.

Cosa cambia per i team software negli Stati Uniti e nell'UE

La vostra applicazione più debole definisce la vostra violazione. Le banche blindano le piattaforme core e l'home banking. Portali per agenti, strumenti di consultazione per broker, back-end mobili per i dipendenti e tool commerciali sono spesso sviluppati in fretta, da fornitori diversi, e verificati meno. Per le aziende FinTech e i loro fornitori sono ormai superficie d'attacco di primo livello.

I penetration test annuali non tengono più il passo degli attaccanti. Se un avversario può lanciare un agente su centinaia di host e iterare durante la notte, una verifica all'anno lascia mesi di esposizione. Aspettatevi che autorità di vigilanza e grandi clienti chiedano test continui o legati ai rilasci, monitoraggio della superficie d'attacco e prove che le vulnerabilità sono state corrette.

Le scadenze normative sono strette. Nell'UE le entità finanziarie soggette a DORA devono classificare e segnalare i gravi incidenti ICT con tempistiche serrate, e la normativa newyorkese NYDFS Part 500 impone di notificare gli eventi di cybersicurezza entro 72 ore. Una violazione passata da un portale sviluppato da un fornitore resta un incidente dell'istituto: i contratti con i fornitori di software devono quindi prevedere per iscritto obblighi di test di sicurezza e di comunicazione.

La minimizzazione dei dati è un controllo di sicurezza. Una pagina di stato che doveva mostrare solo «approvata / in lavorazione» ma restituiva reddito e massimali di credito ha trasformato un bug di autenticazione in una violazione da notificare. Progettare API che restituiscono solo i campi indispensabili limita i danni del prossimo bypass.

Cosa significa per il mercato italiano?

In Italia banche, assicurazioni, istituti di pagamento e di moneta elettronica applicano DORA dal 17 gennaio 2025, sotto la vigilanza di Banca d'Italia, IVASS e Consob per i rispettivi ambiti. Il regolamento impone in particolare la gestione del rischio legato ai fornitori terzi di servizi ICT — cioè proprio le software house e le società di consulenza che sviluppano portali per agenti e mediatori creditizi, tool commerciali e app per i dipendenti. Gli istituti più rilevanti devono inoltre svolgere periodicamente test di penetrazione basati sulle minacce (TLPT), in Italia secondo il quadro TIBER-IT della Banca d'Italia; scenari di ricognizione assistita dall'IA vanno ormai inclusi in questi esercizi.

Accanto a DORA, il D.Lgs. 138/2024 che recepisce la direttiva NIS2 estende gli obblighi di gestione del rischio e di notifica verso l'Agenzia per la Cybersicurezza Nazionale (ACN) a molti più soggetti, e in caso di fuga di dati personali resta la notifica al Garante privacy entro 72 ore prevista dall'art. 33 del GDPR. Per una fintech o una software house che lavora con banche italiane, test regolari delle proprie applicazioni, evidenze delle correzioni e un processo di segnalazione chiaro diventano requisiti nelle gare e nei contratti di fornitura.

Checklist di hardening per le applicazioni finanziarie esposte su Internet

  1. Censire tutto ciò che è raggiungibile. Compresi portali per partner e agenti, API mobili per i dipendenti, tool di marketing e vendita e ambienti di staging dimenticati.
  2. Imporre l'autenticazione lato server su ogni route. Nessun controllo lato client, nessun endpoint «nascosto», autorizzazione a livello di oggetto su ogni consultazione di record.
  3. Fermare il credential stuffing. MFA resistente al phishing per i dipendenti, rate limiting e rilevamento dei bot al login, controllo delle password compromesse.
  4. Restituire il minimo. Ridurre le risposte delle API a ciò che serve a ogni schermata; mascherare di default identificativi e campi finanziari.
  5. Testare in modo continuo. Scansioni automatiche nella CI e pianificate, più penetration test manuali sui nuovi servizi esposti prima del go-live.
  6. Sorvegliare i pattern agentici. Alert su sondaggi sistematici e massivi di molti endpoint e su enumerazioni insolite di ID.

Domande frequenti

Cosa è successo alle banche sudcoreane?

Tra il 1° e il 5 ottobre 2026 sette istituti finanziari sudcoreani hanno confermato violazioni di dati: Shinhan Bank, KB Kookmin Bank, Hana Bank, BNK Busan Bank, Yegaram Savings Bank, Welcome Savings Bank e Hyundai Capital. Secondo il Korea Herald sono stati esposti dati di circa 66.000 persone e 2.200 record aziendali, tra cui nomi, numeri di telefono, numeri di registrazione dei residenti, reddito annuo e massimali di credito. La sola Shinhan ha segnalato circa 25.700 clienti coinvolti.

Negli attacchi è stata davvero usata l'IA?

È un sospetto, non una conferma. Il 2 ottobre Bloomberg, citando Yonhap, ha riferito che nell'attacco a Shinhan si sospetta l'uso di strumenti di IA, e alcuni ricercatori hanno trovato su un server collegato all'intrusione un titolo di pagina in cinese traducibile come «console di penetration test autonomo con IA». La stringa è stata associata ad ARTEX, un framework open source di penetration test basato su LLM. Il presidente Lee Jae Myung ha parlato di segnali di uso dell'IA, ma le autorità non hanno confermato ufficialmente lo strumento.

Come sono entrati gli attaccanti?

I punti di ingresso segnalati erano sistemi periferici esposti su Internet, non il core bancario: un bypass dell'autenticazione sul servizio di verifica dello stato delle pratiche per gli agenti di credito di Shinhan, accessi esterni anomali a un sistema mobile per i dipendenti di KB Kookmin e un tentativo di accesso non autorizzato al sistema di supporto commerciale di Hana Bank. La stampa locale parla anche di credential stuffing, cioè login automatizzati con password rubate.

Cosa dovrebbero fare ora i team fintech negli Stati Uniti e nell'UE?

Censire ogni applicazione raggiungibile dall'esterno, compresi portali partner, pagine di stato per gli agenti e back-end mobili per i dipendenti; imporre autenticazione e autorizzazione lato server su ogni endpoint; introdurre rate limiting e difese contro il credential stuffing; ridurre al minimo i dati personali restituiti da questi sistemi; e testare in modo continuo, perché gli attaccanti assistiti dall'IA esplorano un'ampia superficie d'attacco molto più in fretta di un ciclo annuale di penetration test.

Fonti

Bloomberg — AI Tools Suspected in Korea’s Shinhan Bank Hack, Yonhap Says (2 ottobre 2026)
The Korea Herald — Police launch major probe as suspected AI hacks sweep through banks (6 ottobre 2026)
The Korea Times — Shinhan, Kookmin, Hana data breaches fuel concerns over AI-powered cyberattacks (2 ottobre 2026)
BleepingComputer — South Korea probes bank breaches amid suspected AI-powered attacks (5 ottobre 2026)