Le schede italiane di Majinahanashi: un leak non è un attacco

Il 10 ottobre 2026 sul sito di leak del gruppo ransomware Majinahanashi compaiono, o ricompaiono, due nomi italiani: HYSYTECH S.r.l., società di ingegneria piemontese che progetta impianti per biometano e idrogeno, e Goccia S.p.A., il gruppo di Cocconato, in provincia di Asti, proprietario della catena JOY Gioielli. I tracker automatici rilanciano le due schede italiane con la solita liturgia di nome, data e logo. Ma un leak ransomware non confermato non è la prova di un attacco. Nel caso di Goccia la scheda era già online da due mesi senza che succedesse nulla di nuovo. Nel caso di HYSYTECH il post non mostra alcun elemento verificabile. Per chi lavora in una PMI italiana, capire questa distinzione vale più di qualsiasi feed di sicurezza.

Cosa dicono i feed: due schede italiane, un solo fatto nuovo

La cronologia ricostruita dal tracker ransomware.live dice molto. La scheda di Goccia era già stata indicizzata il 12 agosto 2026 alle 14:47 UTC, con la stessa data di attacco stimata del 3 agosto. In due mesi non è successo niente di nuovo: il copione è stato semplicemente ripubblicato, il 10 ottobre alle 20:43 UTC, con la stessa data di attacco stimata.

La scheda di HYSYTECH è diversa: davvero recente, scoperta da ransomware.live il 10 ottobre alle 20:38 UTC, con attacco stimato al 2 ottobre. Ma secondo RedPacketSecurity il post non mostra screenshot, non indica il tipo né il volume dei dati che sarebbero stati sottratti e non contiene una richiesta di riscatto. Il punto chiave è un altro: il 2 ottobre è la data del post, perché non viene fornita una data di compromissione separata. In altre parole, la «data di attacco stimata» di molti feed è in realtà la data in cui un criminale ha scritto un post. Chi costruisce una timeline di incidente su quel campo sta datando un annuncio, non una compromissione.

Sulle aziende, le fonti ufficiali danno un quadro sobrio. Goccia S.p.A. ha sede legale a Cocconato ed è stata fondata nel 1989 da Giuseppe Conrotto. Il format Joy Gioielli nasce nel 2008 e l’e-commerce nel 2020. Ha 18 punti vendita tra le insegne Joy Gioielli, Pietra Gioielli e Pandora e circa 130 persone secondo il profilo LinkedIn. Le enfasi alla «major Italian jewelry corporation» sono un’aggiunta del tracker. HYSYTECH è una società di ingegneria fondata nel 2003 a Torino, attiva su biometano, bio-GNL e idrogeno con la tecnologia H2GENIO. Nel 2014 ha realizzato con Acea Pinerolese Industriale il primo impianto italiano di upgrading del biogas da frazione organica dei rifiuti urbani. Nel 2020 ha messo in servizio il primo impianto di idrogeno verde da biogas da FORSU.

Chi è Majinahanashi: profilo tecnico e segnali di approssimazione

L’analisi di riferimento è quella di The Raven File, firmata dal ricercatore indipendente RakeshKrish, pubblicata il 14 agosto 2026 e aggiornata il 12 ottobre. Il gruppo viene presentato come l’ennesimo gruppo di estorsione a tema giapponese, dopo Yurei, Sinobi e Tengu: il bollettino di Broadcom/Symantec traduce il nome con «storie di fantasmi». Sul piano infrastrutturale, il sito di leak vive su un dominio Tor non vanity, protetto da un captcha matematico, con nginx e un’applicazione Python/Flask. Il primo leak risale al 27 giugno 2026 e ad agosto le vittime elencate erano 15, sempre secondo The Raven File. Il 2 ottobre il sito è stato rinnovato con il titolo «MAJIN RANSOM» e i file server cambiati.

Il malware descritto dal ricercatore è composto da due campioni in C/C++ da circa 90 KB ciascuno, con data di creazione 2 luglio 2026. Cifra con AES-256, proteggendo le chiavi dei singoli file con RSA, aggiunge l’estensione.MAJIN, usa il mutex Global\majinahanashi_Mutex e installa un servizio chiamato majinSvc. Prima di cifrare cancella le shadow copy, interviene sulle impostazioni di avvio con bcdedit, e svuota i log e il journal USN. Usa la Windows Filtering Platform per silenziare gli agenti EDR. La nota di riscatto è un README.txt con contatti qTOX e Proton, come documentato da PCRisk.

Il giudizio di The Raven File è sobrio: una famiglia di ransomware di fascia media, senza crittografia innovativa né tecniche di anti-analisi sofisticate. E i segnali di approssimazione non mancano: il gruppo avrebbe chiesto 15.000 dollari via email, e per diverse vittime i dati non risultano disponibili. Ha dichiarato che il 70% dei suoi accessi iniziali avviene tramite dispositivi di archiviazione fisici. Sul metodo di infezione dichiarato, commenta il ricercatore, non c’è da fidarsi; il gruppo l’ha contattato per correggere la vittimologia. Su alcune pagine usa formule come «Servers & Hyper-V encrypted» per aumentare l’effetto spavento. Non è la prova che tutto sia finto, ma è il profilo di chi ha interesse a gonfiare.

Rivendicazioni riciclate: un fenomeno noto, non un caso isolato

Le rivendicazioni riciclate o inventate sono ben documentate. Nel report di aprile 2024 sull’impatto di un takedown, Trend Micro ha rilevato che, dei 95 post comparsi dopo l’operazione, oltre due terzi erano ri-caricamenti di attacchi precedenti. Secondo Infosecurity Magazine, quasi l’80% delle voci era illegittimo: il 68% ripubblicazioni e il 10% vittime di altri gruppi come ALPHV e RansomHub.

I casi eclatanti non mancano. Il 23 giugno un gruppo ha rivendicato 33 TB di dati sottratti alla Federal Reserve. I dati pubblicati appartenevano invece a Evolve Bank & Trust, che ha confermato l’incidente. Lo riportano BleepingComputer, The Record e Malwarebytes. Secondo GuidePoint GRIT, un sito di leak è apparso il 27 gennaio con oltre 64 presunte vittime. Di queste, almeno il 90% era già rivendicato da altri gruppi: FunkSec, RansomHub, LockBit e Meow. Halcyon ha concluso che non c’erano prove né di nuove cifrature né di nuove intrusioni. Il principio che GRIT ne ricava è utile: senza nota di riscatto, file cifrati o comunicazioni dirette dell’attaccante, un listing è quasi certamente fabbricato. Lo stesso ricercatore di The Raven File ha documentato un dato relativo al 4 dicembre 2025. Su 23 vittime annunciate da LockBit 5.0, dieci provenivano da un batch precedente risalente ad aprile 2025.

Il caso Majinahanashi presenta gli stessi sintomi. Il 10 ottobre ransomware.live registra come «scoperto» un intero blocco di vittime con attacchi stimati tra il 27 giugno e il 29 agosto. Molte erano già indicizzate ad agosto, e il blocco arriva otto giorni dopo il rebranding del sito del 2 ottobre. L’effetto è misurabile: il ritardo medio tra attacco e pubblicazione è passato da 28,9 a 68,8 giorni tra il profilo di inizio settembre e quello di ottobre. Le statistiche ne risentono: ransomware.live mostra 23 vittime ma include doppioni, Cyberthreatintelligence.net arriva a 42-43 vittime, Breachsense ne contava 12-14 a fine agosto. Tre fonti, tre numeri: chi costruisce un report senza deduplicare sta contando i fantasmi due volte. Sulle pagine di RedPacketSecurity dedicate al gruppo, compresa quella di HYSYTECH, compare un «verification alert»: le schede attribuite a Majinahanashi sono state segnalate come contenenti rivendicazioni non verificate o fabbricate.

Triage operativo: come verificare un leak ransomware non confermato

Davanti a un alert del genere, gli estremi sono entrambi sbagliati: «siamo stati violati, è scritto su internet» e «è tutta fuffa». La procedura di triage indicata dagli analisti si esegue con gli strumenti che un IT manager ha già:

• Catturate l’evidenza: screenshot della scheda, hash, orari, numero di file dichiarato. Una scheda può essere rimossa o modificata, la vostra copia no.
• Confrontate il campione con i vostri dati: percorsi dei file, nomi host, nomi dei dipendenti, date dei documenti. Se i file più recenti sono vecchi di anni, è probabile un riciclo.
• Cercate la stessa vittima altrove: se i dati compaiono su altri siti di leak o in violazioni precedenti, è esattamente il meccanismo che ha smascherato Babuk2.
• Cercate i segnali interni delle tecniche dichiarate: eventi legati a vssadmin, bcdedit, wevtutil e fsutil, il servizio majinSvc, il mutex noto, l’estensione.majin, l’uso di Mimikatz e Advanced IP Scanner. Incrociate con EDR, log del firewall, VPN e autenticazioni.
• Controllate le credenziali esposte da infostealer: ransomware.live, appoggiandosi a Hudson Rock, segnala ad esempio 2 dipendenti compromessi sul dominio di Goccia. È un indizio, non la prova del claim.
• Non contattate il gruppo: se serve parlarci, lo fanno legali e incident response, non l’amministratore di sistema con troppa buona volontà.

Sulla comunicazione, la formula più prudente è un holding statement fattuale: «stiamo verificando una rivendicazione non confermata». Niente smentite assolute, perché il giorno dopo potreste doverle ritirare, e niente conferme premature.

Adempimenti legali: GDPR e NIS2, quando parte l’orologio

Un post su un sito di leak non fa partire da solo nessun termine di legge: il termine decorre dalla conoscenza della violazione o dell’incidente significativo. Un claim credibile impone però un’istruttoria immediata, e se emergono indizi concreti l’orologio corre.

Sul versante GDPR, l’articolo 33 impone al titolare di notificare al Garante senza ingiustificato ritardo. Ove possibile la notifica va fatta entro 72 ore da quando ne è venuto a conoscenza. Non serve se sia improbabile un rischio per gli interessati; oltre le 72 ore va accompagnata dai motivi del ritardo. Dal 1° luglio 2021 la notifica si fa solo con la procedura telematica sul portale del Garante. Il paragrafo 5 impone inoltre di documentare ogni violazione, anche quelle non notificate: documentare l’istruttoria su un claim non confermato è parte dell’obbligo di accountability.

Per la direttiva NIS2, recepita dal D.Lgs. 138/2024, l’articolo 25 prevede per un incidente significativo una pre-notifica al CSIRT Italia entro 24 ore dalla conoscenza. Prevede poi una notifica entro 72 ore e una relazione finale entro un mese. Lo confermano le FAQ dell’Agenzia per la Cybersicurezza Nazionale. Sui tempi, attenzione: secondo la determinazione ACN 127434/2026, per i soggetti inseriti nell’elenco NIS nel 2026 l’obbligo di notifica decorre dal 1° gennaio 2027. Verificate la propria posizione invece di fidarsi del sentito dire.

Difese di base che il caso Majinahanashi porta in primo piano

Indipendentemente dalla veridicità delle due schede, il profilo tecnico descritto da The Raven File è un promemoria delle difese fondamentali. Il gruppo dichiara di cancellare backup e shadow copy: servono quindi backup offline e immutabili, testati con un ripristino vero. Il malware tenta di terminare EDR e agenti di backup: serve un EDR con protezione anti-tampering e la sorveglianza sull’uso anomalo di strumenti come bcdedit e wevtutil.

Gli accessi iniziali via credenziali rubate da infostealer sono un vettore plausibile, come suggeriscono i 2 dipendenti compromessi segnalati sul dominio di Goccia. Serve l’autenticazione a più fattori ovunque, soprattutto su VPN e accessi remoti, e il monitoraggio delle credenziali aziendali esposte. Infine la segmentazione di rete, perché l’attaccante che arriva ovunque cifra tutto, mentre quello che trova porte chiuse si ferma. Resta un punto di onestà intellettuale: al momento non esiste alcuna conferma indipendente di un’intrusione né per HYSYTECH né per Goccia, e «non verificato» significa esattamente questo: non sappiamo.

Fonti:

• guidepointsecurity.com
• Un leak non prova un attacco: cosa sappiamo di Hysytech e Goccia | agendadigitale.eu