ARTEX negli attacchi in Giappone: 20 aziende nel mirino e sei server AI

🛡️ Executive Summary

• GMO Cybersecurity conferma l’impiego di ARTEX in un’infrastruttura usata per prendere di mira circa 20 aziende giapponesi, nove dello stesso settore.
• I ricercatori individuano altre sei infrastrutture d’attacco basate sull’AI: non dimostrano che tutte utilizzassero ARTEX. Otto società prese di mira hanno comunicato fughe di dati.
• Il caso evidenzia campagne selettive per paese e settore e mostra i limiti di una difesa fondata soltanto su CVE, scansioni esterne e regole WAF statiche.

L’impiego di ARTEX negli attacchi contro aziende giapponesi non è più soltanto un’ipotesi ricavata dai log. GMO Cybersecurity by Ierae ha individuato lo strumento di penetration testing agentico in un’infrastruttura offensiva che aveva preso di mira circa 20 società in Giappone, nove delle quali appartenenti allo stesso comparto. L’indagine, pubblicata il 19 ottobre 2026, ha inoltre individuato altre sei infrastrutture che utilizzavano l’intelligenza artificiale per attacchi orientati soprattutto al mercato giapponese. Tra le aziende identificate come bersagli, otto avevano già comunicato episodi di fuga di dati nel periodo settembre-ottobre. I numeri descrivono un fenomeno concreto, ma non autorizzano ad attribuire ad ARTEX ogni violazione.

GMO trova ARTEX nei server da cui partivano gli attacchi

Il salto investigativo riguarda la qualità dell’evidenza. In una prima analisi GMO aveva considerato altamente probabile l’impiego di AI sulla base dei registri forensi; nel nuovo rapporto del suo centro di contrasto al cybercrime dichiara di avere identificato ARTEX nell’infrastruttura utilizzata dagli attaccanti. Lo strumento è concepito per automatizzare attività di penetration testing tramite agenti e modelli linguistici, ma può essere impiegato fuori da un contesto autorizzato per esplorare applicazioni, individuare superfici vulnerabili e concatenare verifiche offensive.

Per quell’infrastruttura la società descrive un targeting quasi esclusivamente giapponese, almeno nel perimetro osservato: circa venti imprese, di cui nove nello stesso settore. Non significa che venti organizzazioni siano state compromesse, né che sia possibile misurare da questo solo dato il tasso di successo degli attacchi. Rispetto ai test di exploit condotti con agenti AI su Chrome e sistemi di autenticazione, qui la differenza è il contesto: non una valutazione autorizzata, ma tracce dell’utilizzo dello strumento su un’infrastruttura associata a intrusioni reali.

Leggi anche: ARTEX e Claude contro le banche: l’AI entra nel workflow dell’hacker

Sei altre infrastrutture AI e otto società che hanno denunciato fughe di dati

Allargando l’analisi con il supporto di organizzazioni esterne, GMO ha individuato sei ulteriori infrastrutture offensive basate sull’AI, orientate principalmente a imprese giapponesi. Gli obiettivi non sono distribuiti casualmente: un’infrastruttura interessa gift card digitali e distribuzione, un’altra istruzione, regali e stampa; le altre prendono di mira programmi a punti e marketing, assicurazioni e finanza, commercio elettronico, media e logistica. Il criterio che emerge è la specializzazione per settore, accompagnata dall’uso di host distinti per le diverse campagne. Fra le società che GMO ha identificato come bersagli, otto hanno pubblicato comunicazioni relative a fughe di informazioni tra settembre e ottobre 2026. L’azienda ritiene che più incidenti siano riconducibili allo stesso gruppo offensivo e ha condiviso le evidenze con le forze dell’ordine, ma non rende pubblici tutti i dettagli tecnici necessari per verificare indipendentemente questa attribuzione. Soprattutto, il rilevamento di ARTEX riguarda esplicitamente la prima infrastruttura: il rapporto non sostiene che tutte le altre sei eseguano lo stesso tool e non prova che gli otto episodi di data breach siano stati causati individualmente da ARTEX. La distinzione ricorda il caso CyberXero, in cui un’infrastruttura di agenti AI è stata collegata a bersagli energetici ucraini: capacità offensiva osservata, vittime segnalate e responsabilità dei singoli incidenti richiedono prove differenti.

Dalla Corea del Sud al Giappone, senza una regia comune dimostrata

Il collegamento asiatico più rilevante precede la nuova scoperta. Il 7 ottobre CrowdStrike aveva analizzato una campagna contro organizzazioni finanziarie sudcoreane trovando, in directory esposte dell’attaccante, configurazioni ARTEX, cronologie Claude Code e file di memoria. La ricerca tecnica originale di CrowdStrike descriveva un’infrastruttura a due server, con DeepSeek v4.1-flash come backend principale e altri modelli impiegati nelle sessioni di lavoro; la vicenda era emersa anche attraverso le compromissioni di banche sudcoreane. GMO considera compatibile con quella dinamica la selezione di bersagli giapponesi per paese e comparto. Somiglianza del metodo non equivale però a identità degli operatori, e nessuna delle due analisi dimostra una direzione statale cinese. CrowdStrike giudicava l’attore del caso coreano probabilmente sinofono e motivato economicamente, con fiducia moderata; non è una prova sufficiente per attribuirgli automaticamente anche le operazioni in Giappone. La novità non sta quindi in un nuovo nome da associare a un gruppo APT, ma nella ripetibilità del modello di attacco agentico attraverso mercati e settori differenti.

CVE incomplete, inventari imperfetti e WAF elusi: dove l’AI accelera gli attaccanti

Le contromisure non si ricavano dal solo nome del tool. In una precedente analisi tecnica di GMO sulle intrusioni recenti, pubblicata il 15 ottobre, i ricercatori individuavano tre criticità operative. La prima riguarda la dipendenza esclusiva dagli elenchi CVE: versioni non più supportate o varianti vulnerabili possono restare fuori dai controlli basati sulle corrispondenze ufficiali. La seconda è il limite dell’Attack Surface Management eseguito dall’esterno, che spesso non permette di identificare con certezza la versione di un’applicazione e non può effettuare verifiche distruttive; l’attaccante, invece, può tentare direttamente lo sfruttamento. La terza riguarda l’elusione delle regole WAF: GMO riferisce attacchi distribuiti attraverso centinaia di indirizzi IP, sostituiti prima di superare le soglie di blocco. Il rapporto descrive tecniche osservate nelle indagini recenti, non prova che ciascuna sia stata utilizzata da ARTEX in tutti i casi giapponesi. Il problema operativo converge con gli incidenti analizzati da CERT-In, dove gli agenti accelerano la compromissione di sistemi reali: vulnerabilità e configurazioni errate rimangono tradizionali, ma l’automazione comprime i tempi a disposizione dei difensori.

Continua con:

Agenti AI attaccano retailer per 25 dollari e rubano oltre 600.000 carte

Agenti AI, la nuova kill chain: 157 skill malevole e tool poisoning sfuggono ai SOC

Per le aziende italiane cambia la velocità della difesa, non la geografia delle vittime

L’indagine GMO non documenta aziende italiane compromesse da questa campagna e non consente di estenderne automaticamente il perimetro all’Europa. È tuttavia rilevante per imprese italiane con portali di commercio elettronico, servizi finanziari, programmi fedeltà e applicazioni pubblicamente raggiungibili: sono categorie di attività presenti anche negli obiettivi giapponesi. La risposta pratica consiste nel confrontare la visibilità esterna con un inventario interno delle versioni, mantenere aggiornati i componenti supportati e sostituire o isolare quelli fuori supporto, cercare tentativi coordinati attraverso IP diversi e verificare gli eventi applicativi successivi alle prime richieste sospette. Un WAF può attenuare alcuni vettori, ma non sostituisce la correzione dei difetti né l’analisi dei log che collega scansioni, autenticazioni anomale ed eventuale esfiltrazione. Le campagne agentiche contro siti governativi statunitensi e canadesi avevano già mostrato il rischio di delegare sequenze offensive a strumenti autonomi; il caso giapponese aggiunge un elemento concreto, l’organizzazione di infrastrutture e bersagli per comparto economico. La difesa dovrà misurare non soltanto quali asset sono vulnerabili, ma quanto rapidamente riesce a riconoscere una campagna prima che il primo accesso diventi una fuga di dati.