Kimsuky costruisce stack AI offline per automatizzare phishing e…

Il gruppo APT nordcoreano Kimsuky ha sviluppato una pipeline AI completamente offline sui propri server C2. I ricercatori di Genians hanno documentato lo stack

Il 10 agosto 2026 i ricercatori della sudcoreana Genians hanno reso pubblico un dossier che traccia mesi di attività su infrastruttura C2 controllata dal gruppo APT nordcoreano Kimsuky. La scoperta non è un altro caso di uso casuale di chatbot pubblici: gli operatori hanno installato, configurato e tenuto in esecuzione uno stack di intelligenza artificiale completamente offline, con modelli locali, database di recupero documenti, librerie di orchestrazione e strumenti di speech-to-text. Il passaggio modifica le regole del rilevamento: scompare il rumore dei servizi cloud tracciabili, e con lui i tradizionali indicatori di qualità scadente che spesso tradivano il phishing a mano.

Punti chiave

Kimsuky ha installato e configurato tre strumenti di esecuzione LLM locale — Ollama, GPT4All, Msty — lasciando tracce di esecuzione effettiva, non solo download
Gli analisti hanno trovato un database RAG attivo (localdocs_v3.db) per interrogare documenti privati, e librerie .NET che coprono l'intero arco "esecuzione locale → retrieval → agenti automatizzati → integrazione AI esterna"
I metadata di documenti esca mostrano timestamp identici a distanza di due settimane, indicatore di generazione automatizzata via script
Genians colloca lo stack in una fase di "ricerca e acquisizione di conoscenza", non di training proprio modello: nessun dataset di fine-tuning è stato recuperato

Come funziona lo stack AI trovato sui server C2

La prova più solida riguarda Ollama, framework per eseguire modelli LLM in locale. I ricercatori di Genians hanno recuperato file di chiavi SSH di autenticazione generati automaticamente al primo avvio del programma: la creazione di questi file avviene solo in esecuzione, non a seguito di semplice download. GPT4All, secondo strumento identificato, presentava il file localdocs_v3.db, che il software crea esclusivamente quando l'utente attiva la funzione LocalDocs per indicizzare documenti privati e interrogare il modello con retrieval-augmented generation. Msty, piattaforma di orchestrazione multi-modello, mostrava tracce di installazione con integrazione per Ollama, ChatGPT, Claude, Gemini e supporto MCP.

La raccolta di componenti di sviluppo spazia su directory nascosta con nome "Pictureszzznupkg". TechTimes, riproducendo il report Genians, ha dettagliato librerie .NET che coprono l'intero pipeline: LLaMaSharp per binding modelli locali in C#, Microsoft.SemanticKernel e Microsoft.Agents.AI per orchestrazione agenti, Microsoft.Extensions.AI e OpenAI/Azure.AI.OpenAI per integrazione servizi esterni, LangChain per chaining, backend CUDA 11 e 12 per accelerazione GPU. La densità e la coerenza funzionale dei componenti, come notano i ricercatori, "suggerisce che non sono stati raccolti per semplice curiosità, ma per lo sviluppo diretto di uno strumento AI finalizzato a uno scopo specifico".

Speech-to-text e documenti esca: le tracce di automazione

Lo stack include capacità di elaborazione audio. Sono stati trovati OpenAI Whisper e faster-whisper, accompagnati da guida in coreano intitolata "Let's extract text from audio files". L'installazione suggerisce che i documenti audio intercettati o rubati possano essere convertiti in testo analizzabile automaticamente, senza passare per servizi cloud registrati.

La prova più netta di automazione industriale, però, risiede nei metadata di documenti esca in formato PDF. TechTimes ha riportato l'analisi forense: Author impostato a "python-docx", Creator a "WPS Office", con timestamp identici 5:00:04 e 5:00:44 su file creati a distanza di due settimane — il 2026-03-11 e il 2026-03-24. La distanza di quaranta secondi a quattordici giorni di intervallo costituisce pattern classico di script schedulato, non di composizione manuale. Il dato è coerente con la valutazione di Genians: "questo cambiamento va oltre uno spostamento nel modo di creare documenti esca e dimostra che l'AI può abilitare l'automazione e la produzione su larga scala di attacchi di ingegneria sociale".

"The fact that all three tools left installation traces is an important indicator that the threat actor did not merely test a single tool by chance, but broadly compared and evaluated multiple approaches to running AI models locally" — Genians, via TechTimes

La campagna Operation GitPower e il contesto C2

Lo stack AI è stato identificato su infrastruttura collegata a Operation GitPower, campagna denominata da Genians che abusa GitHub come canale C2 con payload AsyncRAT cifrati. Fortinet aveva già documentato pattern analoghi di utilizzo GitHub-C2 nel aprile 2026 contro utenti sudcoreani, fornendo corroborazione indipendente sulla metodologia di comando e controllo, se non sullo specifico stack AI.

Sui server è stata inoltre recuperata una richiesta testuale dell'operatore: "The more detailed the analysis, the better. Please do not do it haphazardly". Il messaggio, accompagnato da riferimento a dataset contenenti wallet, credenziali Gmail e cronologie di registrazione siti, è compatibile con preparazione di input per sistema di analisi automatizzato, benché Genians non confermi che la richiesta sia stata effettivamente sottoposta a un servizio AI.

Tracce attive dell'editor Cursor, strumento AI-powered per coding, completano il quadro di un ambiente di sviluppo integrato dove l'intelligenza artificiale assiste la produzione di codice malevolo senza esporre snippet a piattaforme esterne registrate.

Perché la fase offline altera la rilevabilità

Il passaggio da strumenti cloud a stack locale elimina due categorie tradizionali di segnale difensivo: le connessioni verso API pubbliche rilevabili a livello rete, e gli artefatti di qualità che spesso tradivano contenuto generato a mano o con modelli non controllati. Errori di traduzione, formattazione incoerente, ortografia difettosa — tutti indicatori comportamentali utili agli analisti — perdono rilevanza quando il modello è locale, il prompt è curato e l'output è inserito in template automatizzato.

La transizione è qualitativa, non solo quantitativa. Genians posiziona esplicitamente lo stack in "fase di ricerca e acquisizione di conoscenza": nessun dataset di training o output di fine-tuning è stato trovato, quindi l'attore non sta addestrando un modello proprio. Ma la raccolta sistematica di componenti che coprono esecuzione locale, retrieval, agenti e integrazione esterna descrive un'architettura in costruzione, non un esperimento isolato. L'obiettivo appare l'automazione dell'intero ciclo: indicizzare documenti rubati, generare esche su misura, analizzare intercettazioni audio, produrre codice — il tutto su server controllati, senza telemetria verso fornitori.

La catena di custodia dei dati e i limiti del dossier

Diversi elementi restano non verificati nel reporting disponibile. Genians non conferma che i documenti indicizzati nel database RAG siano di provenienza illecita: il report indica solo "in its possession", senza prova di furto. Non è confermato che i documenti esca con metadata automatizzati siano stati distribuiti a vittime reali, né che lo stack sia stato osservato in esecuzione attiva contro un target durante il monitoraggio. La richiesta operatore di analizzare dataset non è verificata come input effettivo a un sistema AI. Reuters, citato nel reporting di The Hacker News, ha dichiarato esplicitamente che i nuovi finding non sono verificabili indipendentemente.

Il numero di vittime di Operation GitPower non è divulgato, e il modello LLM specifico usato per la generazione documenti esca non è identificato: i ricercatori hanno solo i pattern metadata, non il motore. La timeline completa di sviluppo dello stack AI — data di inizio, grado di avanzamento, eventuale deployment operativo — non è ricostruibile dal materiale pubblico.

Questi limiti non sminuiscono il valore del finding, ma ne circoscrivono la natura: è un'istantanea di infrastruttura in preparazione, non la documentazione di un attacco concluso. La distinzione è rilevante per chi alloca risorse difensive: il segnale è precoce, non posteriore.

Cosa fare adesso

Allineare il rilevamento di phishing sulla valutazione del comportamento post-intrusione e su indicatori di compromissione della catena di delivery, piuttosto che sulla sola qualità linguistica del contenuto: la generazione AI locale rende la qualità del testo un segnale inaffidabile
Monitorare l'installazione e l'esecuzione di framework LLM locale — Ollama, GPT4All, Msty, Whisper — su endpoint e server aziendali, che in ambiente normale non dovrebbero essere presenti
Esaminare i metadata dei documenti in entrata: timestamp identici, Author "python-docx" o Creator "WPS Office" in pattern ripetuti sono indicatori di generazione automatizzata da valutare nel contesto della catena di provenienza
Rivedere le policy di rilevamento su GitHub come canale C2, metodologia documentata da Fortinet nel aprile 2026 e ora integrata nella campagna Operation GitPower con payload cifrati

Domande frequenti

Kimsuky sta addestrando un proprio modello AI?

No. Genians ha esplicitamente escluso questa evidenza: non sono stati trovati dataset di training né output di fine-tuning. Lo stack è in fase di "ricerca e acquisizione di conoscenza", con modelli pre-addestrati eseguiti in locale.

I documenti generati automaticamente sono già stati usati in attacchi reali?

Non è confermato. I metadata dei PDF indicano generazione automatizzata, ma il reporting non documenta che questi documenti siano stati effettivamente distribuiti a vittime. Potrebbero essere in fase di test.

Perché lo stack offline è più pericoloso dei chatbot pubblici?

Perché elimina la telemetria verso servizi cloud tracciabili e rimuove gli artefatti di qualità che spesso permettevano di identificare contenuto generato senza supervisione. L'attacco diventa più omogeneo e meno rumoroso.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti