What Industry Leaders Can Do to Support Women in Security

@import url(‘https://fonts.googleapis.com/css2?family=Nunito+Sans:ital,opsz,wght@0,6..12,400;0,6..12,500;0,6..12,600;0,6..12,700;1,6..12,400;1,6..12,500;1,6..12,600;1,6..12,700&family=Nunito:ital,wght@0,400;0,500;0,600;0,700;1,400;1,500;1,600;1,700&display=swap’); h3 { font-weight: bold; font-size: 18px; color: #C72026; } figure { padding: 4px; margin: auto; } figcaption { color: #404144; Nunito Sans’, Arial, sans-serif; font-size: 14px; padding: 10px; text-align: left; }

Can the industry do more for women in security? 

That was a question I asked earlier this year, just before International Women’s Day. The insights I received from female leaders in the industry were eye-opening. While many shared that security and cybersecurity spaces have become more welcoming to women, they also acknowledged that there is still a long journey ahead for not just acceptance, but support and empowerment. 

In the most recent episode of Lock It Down with Security Magazine, I spoke with Melissa Mack, Director on the Professional Certification Board for ASIS and Managing Director at Pinkerton, about her experiences in rising to a leadership position in a traditionally male-dominated field. Mack expressed that for a majority of her career, she “was often the only woman in the room.” 

“I learned very quickly how to work and adapt in a male-dominated environment,” Mack states. 

But why is the expectation that women must the ones to adapt? Thinking back to the earlier question — can the industry do more for women in security — I think the answer is “yes.”

To learn how security leaders and organizations like can take actionable steps to support women seeking leadership roles in the industry, listen to our conversation below: 

Lock it Down Podcast logo

What Industry Leaders Can Do to Support Women in Security

Melissa Mack, Managing Director at Pinkerton, discusses the state of the security industry for women.

Or check it out on our Apple Podcasts. Don’t forget to like, follow, and rate and review our podcasts!

https://www.securitymagazine.com/articles/102314-what-industry-leaders-can-do-to-support-women-in-security




Windows Users Targeted in New Phishing Campaign

Research from FortiGuard Labs reveals a new phishing campaign leveraging emails posing as purchase orders, prompting targets to open malicious attachments.  

The research states, “This campaign demonstrates a sophisticated multi-stage attack chain that begins with a phishing email delivering a malicious JavaScript file. The JavaScript decrypts and executes a PowerShell script that uses process hollowing to inject a .NET downloader module into a trusted Windows process (MsBuild.exe). The downloader module communicates with a remote C2 server to fetch and execute additional plugin modules, allowing the attacker to adapt the malware’s post-compromise behavior.”

Windows users are the primary target of this phishing threat. 

This campaign is evasive and challenging for conventional signature-based security measures to identify, largely due to the use of: 

  • Several encryption layers
  • Fileless execution
  • Process hollowing tactics 

Below, security leaders discuss this campaign. 

Security Leaders Weigh In

Kern Smith, Senior Vice President of Global Solutions Engineering at Zimperium:

While this campaign ultimately executes on Windows, the broader lesson extends well beyond the endpoint. Attackers increasingly rely on social engineering and multi-stage attack chains that begin wherever users are most active, and increasingly, that starts on mobile devices through email, messaging platforms, and collaboration tools.

What makes these attacks effective is not just the malware itself, but the ability to move users from initial engagement to compromise while avoiding detection across devices and environments. Organizations should think beyond traditional endpoint visibility and ensure they can identify suspicious activity early, correlate signals across mobile devices, applications, and endpoints, and rapidly determine whether an alert represents a real incident. As attack paths become more distributed and AI accelerates attacker execution, security teams need AI-empowered security capabilities that reduce investigation time and provide clearer paths from signal to response.

Jason Soroko, Senior Fellow at Sectigo:

FortiGuard Labs recently discovered JavaScript-driven phishing campaign, deploying a PureLogs variant, underscores the shift toward fileless, evasive execution chains. Attackers hide the payload in an archive disguised as a purchase order, exploiting routine business workflows. The obfuscated JavaScript serves as an entry point that bypasses perimeter defenses, then decrypts and launches a PowerShell script. Threat actors continue refining methods that blend malicious activity with legitimate administrative tools.

The campaign relies on process hollowing to inject a .NET downloader into the trusted Windows MsBuild executable, masking it within a heavily used framework component and complicating detection. Once embedded, the downloader contacts a remote command server to retrieve modular plugins, giving the attacker dynamic post-compromise control. Layered encryption combined with legitimate system processes shows a sophisticated approach to data theft that demands equally adaptive, behavior-focused defenses.

Maxime Cartier, Vice President of Human Risk at Hoxhunt:

Historically, risky behavior and the human element have been linked to up to 90% of breaches, mainly via social engineering and phishing. However, when you look meticulously at recent research, many of the risks and barriers are behavioral, not technical.

Developers, admins, IT operations teams — they respond to the same drivers we think about in Human Risk Management every day: motivation, prioritization, clarity, communication, and friction. If security teams want outcomes to improve, they need to communicate risk in ways that help people act, not just escalate pressure.

This creates a significant opportunity for security awareness and Human Risk Management teams to collaborate more closely with vulnerability management teams. We spend a lot of time thinking about how to influence secure behavior at scale. Those same principles apply directly to improving remediation outcomes across the organization.

https://www.securitymagazine.com/articles/102322-windows-users-targeted-in-new-phishing-campaign




SEO poisoning e chatbot AI dirottati per un malware miner


Le campagne di SEO poisoning non sono certo una novità nel panorama cybercriminale. Da decenni gli attaccanti manipolano i motori di ricerca per spingere siti malevoli tra i primi risultati, inducendo gli utenti a scaricare malware credendo di visitare pagine legittime. Ma una nuova campagna analizzata da Microsoft Security Blog mostra un’evoluzione particolarmente interessante del fenomeno: gli attori malevoli stanno iniziando a sfruttare anche i chatbot AI per distribuire malware destinato al cryptomining GPU.

Secondo i ricercatori, gli attaccanti stanno prendendo di mira utenti molto specifici: appassionati hardware, gamer e power user che dispongono di GPU ad alte prestazioni, sistemi ideali per attività di cryptojacking ad alta redditività.

Dalla SEO poisoning ai chatbot AI

La campagna sfrutta una combinazione di tecniche di social engineering e manipolazione algoritmica. Gli utenti cercano online utility popolari come CrystalDiskInfo, HWMonitor, Display Driver Uninstaller o FurMark e vengono indirizzati verso domini controllati dagli attaccanti che imitano i siti ufficiali. La parte più interessante della ricerca riguarda però l’utilizzo dei Large Language Model. Microsoft spiega di aver osservato casi in cui utenti che chiedevano consigli di download a chatbot AI ricevevano link verso domini malevoli inseriti direttamente nelle risposte generate dal modello.

Non si tratta ancora di un attacco strutturato contro gli LLM stessi, ma piuttosto di una forma di “AI search poisoning”, cioè un’estensione della classica SEO poisoning all’interno degli ecosistemi conversazionali basati su AI. Il concetto è semplice ma estremamente efficace: se gli utenti iniziano a sostituire Google con chatbot AI per trovare software e utility, gli attaccanti seguiranno inevitabilmente lo stesso flusso.

Come funziona la catena di infezione

La campagna descritta da Microsoft non punta alla massima diffusione possibile. L’obiettivo sembra essere invece la selezione accurata delle vittime più redditizie. I software impersonati dagli attaccanti sono infatti tutti associati a utenti enthusiast, overclocker o gamer avanzati. Questo consente agli operatori della campagna di aumentare la probabilità di compromettere sistemi dotati di GPU discrete di fascia alta, molto più profittevoli per il mining rispetto ai normali PC consumer.

Secondo l’analisi tecnica, gli utenti vengono indirizzati verso siti clone costruiti per sembrare identici alle pagine ufficiali delle utility più note. Una volta scaricato il software, il payload avvia una catena di infezione che include componenti di persistenza e accesso remoto. Tra gli elementi più preoccupanti figura l’abuso di ScreenConnect, utilizzato per mantenere accesso persistente ai sistemi compromessi. Questo dettaglio è particolarmente rilevante perché suggerisce che la campagna non sia limitata al solo cryptomining. Microsoft sottolinea infatti che gli accessi ottenuti potrebbero essere successivamente sfruttati anche per furto dati, movimenti laterali e distribuzione ransomware. La presenza di strumenti di remote management rende quindi l’infezione potenzialmente molto più pericolosa di un semplice miner GPU.

Il ruolo crescente della SEO poisoning nell’ecosistema malware

La SEO poisoning sta diventando una delle tecniche preferite dai cybercriminali per ottenere accesso iniziale. Secondo ReliaQuest, le rilevazioni di malware collegate a campagne SEO poisoning sono cresciute del 60% in sei mesi tra il 2023 e il 2024. Anche Zscaler aveva già osservato campagne analoghe basate su keyword AI, utilizzate per distribuire malware come Vidar, Lumma e Legion Loader attraverso siti ottimizzati con tecniche Black Hat SEO. La novità è che ora il fenomeno sembra estendersi oltre i motori di ricerca tradizionali, entrando nei flussi conversazionali generati dai chatbot AI: non viene compromessa l’AI in sé, ma il contesto informativo che l’AI utilizza per rispondere agli utenti.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/05/27/seo-poisoning-e-chatbot-ai-dirottati-per-un-malware-miner/?utm_source=rss&utm_medium=rss&utm_campaign=seo-poisoning-e-chatbot-ai-dirottati-per-un-malware-miner




Texas Tech University Constructing Critical Infrastructure Security Site

Texas Tech University recently broke ground to establish a critical infrastructure security site, expanding on the institute it established in 2024. The institute was established in order to assess and develop clarification and mediation methods for vulnerabilities to United States critical infrastructure. The current expansion will broaden the institute’s support of innovation, research and collaboration in regards to national security and critical infrastructure defense. 

“This groundbreaking reflects Texas Tech’s growing role in securing the nation’s critical infrastructure,” remarked Stephen Bayne, Vice President for National Security and Executive Director of the university’s Critical Infrastructure Security Institute (CISI). “This research site strengthens our ability to protect the systems our nation, state and community depend on every day and delivers solutions that address evolving threats to infrastructure security.”

This expansion will enable CISI operate as a hub for innovation, testing cyber-physical protections, critical power infrastructure, and more. In addition, the institute will be able to offer certification and training for the next generation of engineers and scientists. 

The institute will continue to collaborate with educational, federal, and industry partners in order to: 

  • Update networks for greater critical infrastructure security
  • Develop new technologies, standards and best practices to decrease vulnerabilities

The new construction will be at the university’s Reese National Security Complex.

https://www.securitymagazine.com/articles/102319-texas-tech-university-constructing-critical-infrastructure-security-site




600,000 Lithuanian National Register Entries Leaked

On Friday, the Lithuanian general prosecutor’s office announced a data leak of national register entries, predominantly registers of legal and real estate entities. This leak impacted more than 600,000 entries.

Upon discovery of this incident, authorities enacted further cybersecurity measures (such as restricting access and blocking the accounts of suspected malicious actors). 

At this time, Lithuanian officials believe this was the result of foreign activity, though no official statement has been made to indicate which country is suspected. However, some suspect a Russian intelligence operation, as Lithuania is considered a target of Russia’s hybrid war, which involves: 

  • Arson
  • Vandalism
  • Sabotage 
  • Influence operations

Following this data leak, the head of the State Enterprise Centre of Registers Adrijus Jusas resigned. 

https://www.securitymagazine.com/articles/102318-600-000-lithuanian-national-register-entries-leaked




Kaspersky: la GenAI mette alla prova il riconoscimento facciale


Un volto reale può essere modificato dall’intelligenza artificiale invecchiandolo, ringiovanendolo o alterandolo talmente tanto da perdere la somiglianza con l’originale. A un osservatore umano sembrerà quello di un’altra persona ma, per alcuni sistemi di riconoscimento facciale, quel volto può continuare a corrispondere alla stessa identità.

È il risultato mostrato da Kaspersky durante HORIZONS, la principale conferenza europea dell’azienda, in una dimostrazione condotta dal Global Research and Analysis Team, il GReAT.

I ricercatori hanno elaborato fotografie di volti reali con strumenti di intelligenza artificiale generativa, simulando scenari di invecchiamento e ringiovanimento. In molti casi le immagini prodotte sono apparse ai giornalisti presenti come ritratti di persone diverse, ma il sistema di riconoscimento facciale ha continuato ad associarle alle identità originali in dieci casi di test indipendenti.

Il punto, per Kaspersky, è duplice. Da una parte l’esperimento conferma che alcuni sistemi biometrici non si basano sulla semplice somiglianza visiva, ma su caratteristiche geometriche e strutturali del volto.

Dall’altra, proprio queste caratteristiche possono essere conservate anche in immagini sintetiche generate a partire da fotografie reali, creando un rischio per i sistemi automatici di verifica dell’identità.

Maher Yamout è Lead Security Researcher del Global Research and Analysis Team di Kaspersky.

Maher Yamout, Lead Security Researcher del Global Research and Analysis Team di Kaspersky, lo ha definito “una prova di fattibilità di un potenziale attacco basato sull’intelligenza artificiale”, precisando che l’esperimento non costituisce uno studio su larga scala.

La conseguenza pratica, ha spiegato, è che “le trasformazioni facciali generate dall’IA possono preservare l’identità biometrica anche quando la percezione umana interpreta le immagini come individui completamente diversi”.

Perché la macchina non vede quello che vediamo noi

Per capire il problema bisogna distinguere due passaggi che spesso vengono confusi. Il primo è il rilevamento facciale: il sistema analizza un’immagine e stabilisce se al suo interno è presente un volto.

Il secondo è la verifica facciale: una volta individuato il volto, il sistema lo confronta con un’immagine di riferimento e valuta se appartiene alla stessa persona.

Nel suo intervento, Yamout ha spiegato che la macchina non “capisce” un volto nel modo in cui lo fa un essere umano. Non interpreta la pelle, l’espressione, l’impressione complessiva o la somiglianza visiva.

Il sistema individua l’area del volto, ne estrae caratteristiche e le converte in matrici matematiche. A quel punto confronta numeri, distanze e soglie di similarità.

Questo spiega perché un’immagine modificata dall’IA può apparire molto diversa a una persona, ma risultare ancora abbastanza vicina all’originale per un modello di riconoscimento.

L’intelligenza artificiale può cambiare l’età apparente, la texture della pelle, gli occhiali, alcuni dettagli estetici o lo stile dell’immagine, ma conservare elementi geometrici e strutturali sufficienti per superare il confronto biometrico.

Nella nostra intervista, avvenuta successivamente alla presentazione, Yamout ha riassunto il punto in modo molto diretto: “Le macchine non capiscono la pelle, non capiscono le fotografie”.

Secondo Yamout, sette modelli su otto hanno si sono fatti ingannare da immagini rifatte in stile Studio Ghibli. Che questa immagine sia sufficiente per fingersi Sam Altman?

I modelli, ha spiegato, cercano elementi come occhi, naso e bocca, individuano l’area del volto e la trasformano in numeri. “Quello che siamo riusciti a fare è stato cambiare l’aspetto visibile del volto ma mantenere intatta la struttura sottostante”.

Uno degli esempi più efficaci mostrati durante la presentazione riguardava un’immagine trasformata in uno stile illustrato simile a quello dello Studio Ghibli. A un osservatore umano non verrebbe naturale accettarla come prova di identità in un sistema di sicurezza.

Eppure, secondo Yamout, sette modelli su otto l’hanno comunque riconosciuta come riferibile alla stessa persona.

È un dettaglio aneddotico, che però rende bene la distanza tra la percezione umana e il calcolo biometrico.

KYC, onboarding e verifica dell’identità

Il tema diventa particolarmente rilevante nei processi di verifica dell’identità. Tra questi rientra il KYC, acronimo di “Know Your Customer”, cioè l’insieme delle procedure con cui banche, fintech, piattaforme finanziarie e altri soggetti verificano l’identità di un cliente prima di attivare un servizio o autorizzare determinate operazioni.

In molti casi l’utente carica un documento, scatta una foto o registra un breve video; il sistema confronta poi quei dati con un’immagine di riferimento.

Yamout ha indicato le università e le istituzioni finanziarie tra gli ambiti in cui possono essere ancora usate forme di verifica facciale bidimensionale.

È difficile misurarne la diffusione precisa, ha osservato, perché si tratta di una tecnologia comune, integrata in molti ambienti con motori, modelli e configurazioni differenti.

Il rischio più concreto riguarda gli scenari in cui un attaccante non genera un volto casuale ma parte da una fotografia reale.

Nella conferenza stampa Yamout ha parlato di immagini “seeded”: il modello riceve un’immagine iniziale e produce una variante sintetica, modificata secondo le istruzioni dell’operatore.

Questo rende l’attacco più mirato, perché l’immagine artificiale conserva una relazione matematica con il volto originale.

Yamout ha indicato le università e le istituzioni finanziarie tra i contesti in cui possono essere ancora usate forme di verifica facciale bidimensionale.

La conseguenza è che la verifica umana e quella algoritmica possono differire. Un operatore potrebbe considerare sospetta o non corrispondente un’immagine che il sistema giudica invece compatibile.

Oppure, in uno scenario automatizzato, una piattaforma potrebbe accettare un’immagine sintetica perché la distanza matematica rispetto al volto di riferimento rimane entro la soglia prevista dal modello.

Secondo Yamout, gli attaccanti partono sempre dallo studio dell’ambiente che vogliono colpire. Cercano di capire quali sistemi vengono usati, quali utenti sono coinvolti, quali software sono presenti e quali abitudini operative esistono all’interno dell’organizzazione.

Se scoprono che una procedura di verifica facciale usa un modello vulnerabile a immagini sintetiche o deepfake, quella procedura può diventare un punto d’ingresso.

La biometria resta utile, ma non basta da sola

Il messaggio di Yamout, però, non è che il riconoscimento facciale debba essere abbandonato.

Nell’intervista ha usato un paragone molto chiaro: le password continuano a essere usate anche se possono essere violate; i token di autenticazione a due fattori continuano a essere usati anche se possono essere sottratti con tecniche di phishing; gli antivirus continuano a essere distribuiti anche se esistono malware capaci di aggirarli.

La logica è la stessa per il riconoscimento facciale. Il riconoscimento facciale può ancora servire ma da solo non basta più a confermare un’identità. Deve essere affiancato da altri controlli, soprattutto nei processi più sensibili.

“Dobbiamo smettere di usarlo? No. È una buona misura di sicurezza”, ha spiegato Yamout. Il punto è affiancarla ad altri controlli compensativi: password, token, codici, verifica del dispositivo, analisi del comportamento, controlli documentali e procedure di escalation quando emergono anomalie.

Il riconoscimento facciale può ancora servire ma da solo non basta più a confermare un’identità. Deve essere affiancato da altri controlli, soprattutto nei processi più sensibili.

Questa logica vale soprattutto per i sistemi 2D. Yamout ha distinto questi scenari dal riconoscimento facciale usato ad esempio dagli smartphone, che si basa su scansioni 3D e quindi su una tecnologia più difficile da aggirare.

Anche in quel caso, ha ricordato, sono stati discussi tentativi di attacco tramite modelli tridimensionali del volto, ma il costo operativo è molto più alto. E nella sicurezza informatica, l’aumento del costo dell’attacco è già una forma di protezione.

È qui che torna il concetto di difesa in profondità. Se un sistema richiede password, token e verifica facciale, diventa più difficile aggirare tutto insieme. L’attaccante può riuscire a compromettere un fattore ma deve investire più tempo e più risorse per superarli tutti.

E spesso, ha detto Yamout, si sposta su un bersaglio più facile: “Gli attaccanti, alla fine, sono pigri”.

Le vecchie serrature vanno aggiornate

L’esperimento di Kaspersky non dice che ogni sistema di riconoscimento facciale sia facilmente aggirabile, né che la biometria abbia perso utilità.

Mostra però che immagini, audio e video generati dall’intelligenza artificiale stanno cambiando le regole della verifica dell’identità, costringendo aziende, sviluppatori e responsabili della sicurezza a ripensare molti processi oggi dati per affidabili.

Per anni il volto è stato trattato come un elemento forte dell’identità, perché difficile da replicare e immediato da verificare.

L’IA ha cambiato i termini del problema: può produrre immagini che confondono l’essere umano, preservano elementi biometrici rilevanti per la macchina e aprono nuovi scenari per frodi, identità sintetiche e manipolazioni nei processi di onboarding.

La risposta più solida passa da sistemi capaci di combinare più segnali. La verifica facciale deve essere accompagnata da controlli sulla provenienza dell’immagine, analisi del rischio, verifica del dispositivo, controlli antifrode e procedure manuali nei casi dubbi.

Dove la posta in gioco è alta, affidarsi a un singolo fattore espone a un rischio crescente.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/05/25/kaspersky-la-genai-mette-alla-prova-il-riconoscimento-facciale/?utm_source=rss&utm_medium=rss&utm_campaign=kaspersky-la-genai-mette-alla-prova-il-riconoscimento-facciale




Kaspersky: gli agenti IA cambiano la fiducia aziendale


Gli agenti di intelligenza artificiale sono ormai entrati nel radar dei criminali informatici. Dall’inizio dell’anno, infatti, Kaspersky ha rilevato a livello mondiale oltre 92.000 attacchi malware camuffati da servizi e agenti IA.

Il dato è stato presentato a Roma durante Kaspersky HORIZONS, e racconta bene quanto rapidamente l’hype sull’intelligenza artificiale sia stato metabolizzato anche dal cybercrime. Tant’è che le false applicazioni di ChatGPT rappresentano il 49% degli attacchi rilevati, mentre Claude e Gemini incidono ciascuno per il 18%.

Accanto ai nomi più noti, i ricercatori hanno individuato oltre 15.000 file malevoli distinti mascherati da software di IA autonoma, comprese versioni contraffatte di strumenti emergenti come OpenClaw.

Il punto, però, non è soltanto che i criminali usino l’IA come nuova esca. Nel suo intervento, Dmitry Galov, Head of Kaspersky’s Global Research & Analysis Team per Russia e CIS, ha spiegato che dietro molti di questi falsi strumenti si nascondono malware già noti.Ci riferiamo a banking trojan, spyware, infostealer, exploit e downloader in grado di installare ulteriori payload dannosi.

La novità sta nella confezione: gli attaccanti sfruttano la fiducia nei brand dell’IA e la curiosità verso strumenti percepiti come indispensabili per restare al passo.

cover Galov Kaspersky

Dmitry Galov, Head of Kaspersky’s Global Research & Analysis Team per Russia e CIS.

La supply chain dell’IA diventa un bersaglio

Un’altra area di rischio riguarda la supply chain del software. Galov ha citato il caso di LiteLLM, una libreria Python ampiamente usata per accedere a modelli di intelligenza artificiale, con circa 97 milioni di download mensili.

La compromissione della libreria ha permesso di inserire codice dannoso capace di sottrarre credenziali di database, file di wallet di criptovalute e altre informazioni sensibili. È un esempio concreto di come un singolo componente esterno, se compromesso, possa trasformarsi in un punto d’ingresso verso molte organizzazioni contemporaneamente.

Galov ha chiarito nell’intervista che il problema non riguarda solo l’IA. Qualsiasi software moderno può dipendere da librerie, pacchetti open source o componenti di terze parti. Nel caso dell’intelligenza artificiale, però, l’ecosistema si sta sviluppando a grande velocità, in modo aperto e collaborativo, e questo rende più appetibili le dipendenze esterne.

Per ridurre il rischio, secondo Galov, serve integrare la sicurezza in tutto il ciclo di sviluppo del software: ogni pacchetto esterno introdotto in un prodotto o in un’infrastruttura deve essere controllato da motori di rilevamento e gestito con policy chiare.

Per gli aggiornamenti non legati alla sicurezza, ha suggerito anche una finestra di “cool down”, evitando di adottare automaticamente l’ultima versione appena pubblicata. Molti attacchi alla supply chain, ha spiegato, restano attivi per finestre molto brevi, da pochi minuti a qualche giorno, prima di essere individuati dalla comunità open source o dai vendor di sicurezza.

Compromettendo LiteLLM (95 milioni di download mensili), il gruppo TeamPCP ha aperto una breccia in migliaia di applicazioni contemporaneamente, sottraendo credenziali cloud e chiavi di accesso ai modelli.

ClickFix e la vecchia debolezza umana

La corsa agli strumenti di IA ha riattivato anche tecniche di ingegneria sociale più classiche. Galov ha citato il caso degli attacchi ClickFix, in cui falsi tutorial o documentazioni apparentemente legittime convincono l’utente a copiare e incollare un comando nel terminale.

L’utente pensa di installare un componente, configurare un ambiente o migliorare le prestazioni di uno strumento, in realtà esegue una stringa malevola. Il meccanismo è particolarmente efficace perché colpisce sviluppatori, tecnici e persone che stanno cercando guide pratiche per entrare nel mondo degli agenti IA.

Nella nostra intervista, successiva alla presentazione, Galov ha ricondotto questi attacchi a una dinamica nota: le esche cambiano ma la natura umana resta la stessa. Gli utenti tendono a fidarsi di ciò che percepiscono come utile, urgente o di valore.

Sul primo gesto, cioè copiare, incollare e premere Invio, la tecnologia può fare ben poco. La difesa può però intervenire negli stadi successivi, con soluzioni di rilevamento e risposta sugli endpoint (EDR) e altri livelli di protezione capaci di bloccare l’esecuzione o riconoscere comportamenti malevoli prima che l’attacco raggiunga il suo obiettivo finale.

Negli attacchi alla supply chain, il bersaglio non è mai quello finale. Un’azienda su tre ne è rimasta vittima nell’ultimo anno.

Skill, plugin e falsi strumenti legittimi

Il rischio non si esaurisce nei malware travestiti da app IA. Kaspersky segnala anche la crescita delle “malicious skills”, cioè funzionalità dannose nascoste all’interno dei flussi di lavoro basati sull’intelligenza artificiale.

Possono presentarsi come plugin, prompt o estensioni apparentemente innocue, in realtà sono progettate per esfiltrare dati, fare ricognizione o manipolare risultati.

È un passaggio importante perché sposta il tema dalla protezione del singolo endpoint alla sicurezza dell’intero ecosistema agentico. OpenClaw, citato sia nel comunicato sia durante l’intervento, diventa in questo senso un esempio del nuovo perimetro da controllare.

Gli agenti IA possono essere estesi con skill e plugin, e queste estensioni possono a loro volta scaricare dipendenze, interagire con strumenti locali o collegarsi a servizi esterni.

La domanda di sicurezza non riguarda quindi solo il modello ma tutto ciò che gli viene connesso: codice, permessi, API, dipendenze e automazioni.

L’IA in ottica cybersecurity: stessi strumenti, intenzioni opposte. Quello che per le aziende è efficienza, per gli attaccanti diventa scala.

Gli agenti aumentano l’efficienza, ma anche l’esposizione

Nel corso della nostra intervista, Galov non ha proposto una lettura allarmistica. Anzi, ha definito gli agenti IA un grande vantaggio per l’efficienza, anche nella cybersecurity e nei SOC, soprattutto quando aiutano ad automatizzare attività ripetitive. Il problema nasce quando vengono adottati senza una postura di sicurezza adeguata.

La sua analogia è semplice: passare da carta e penna a un laptop aumenta senz’altro l’efficienza, ma anche il rischio di vulnerabilità. La scelta non è tra innovazione e sicurezza, ma tra automazione governata e automazione lasciata senza controllo.

Una posizione, questa, che troviamo anche nei comunicati di Kasperky: “L’introduzione di agenti di intelligenza artificiale negli ambienti aziendali cambia la natura stessa della fiducia. Ogni azione automatizzata diventa parte di una catena più ampia di sistemi e scambi di dati”.

Il gruppo Silver Fox ha usato versioni false di Claude Code. Un caso che mostra come la diffusione degli strumenti IA apra nuove superfici d’attacco basate sull’ingegneria sociale.

Il nuovo controllo passa da dati, decisioni e log

Non corso dell’intervista, non ci è  restato che chiedere a Galov delle possibili contromisure. Per Galov le aziende devono concentrarsi su due piani: data management e decision management.

Il primo riguarda i dati a cui l’agente può accedere: bisogna verificare che siano davvero necessari per il compito assegnato e che non venga concesso più di quanto serva.

Il secondo riguarda le azioni che l’agente può compiere: per le decisioni più sensibili deve restare una validazione umana, una sorta di secondo fattore in cui il controllo finale torna a una persona.

A questo si aggiunge la visibilità sull’infrastruttura intorno agli agenti, che comunicano con modelli esterni, tool di terze parti e API.

Per questo, secondo Galov, le aziende devono raccogliere log ed eventi, integrarli in sistemi SIEM e metterli a disposizione dei SOC analyst. Il rischio peggiore è che qualcosa accada senza sapere chi lo ha fatto, quale componente lo ha eseguito e quali dati o sistemi siano stati coinvolti.

È lo stesso principio che Kaspersky riassume nelle sue raccomandazioni: standardizzare interfacce e protocolli, applicare il principio del minimo scambio necessario di dati, identificare chiaramente utenti, agenti e servizi IA, mantenere la supervisione umana nei processi critici e procedere con implementazioni graduali, includendo eventuali rollback.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/05/22/kaspersky-agenti-ia-cambiano-fiducia-aziendale/?utm_source=rss&utm_medium=rss&utm_campaign=kaspersky-agenti-ia-cambiano-fiducia-aziendale




HackerOne taglia drasticamente le ricompense dei bug bounty


L’epoca d’oro dei bug bounty potrebbe stare entrando in una nuova fase molto più complessa. HackerOne, una delle piattaforme più importanti al mondo per la segnalazione responsabile di vulnerabilità, ha drasticamente ridotto le ricompense economiche del proprio programma Internet Bug Bounty (IBB), provocando forti reazioni nella comunità dei ricercatori di sicurezza.

Secondo quanto riportato da The Register, i compensi per le vulnerabilità critiche sono stati ridotti di oltre il 75%. Un bug critico che in precedenza poteva valere circa 9.250 dollari viene ora premiato con appena 2.257 dollari. Anche le altre categorie hanno subito ridimensionamenti drastici: le vulnerabilità high severity passano da circa 4.429 a 1.009 dollari, mentre le medium severity scendono da 1.843 a 297 dollari.

Il taglio rappresenta uno dei segnali più evidenti della crisi che sta attraversando il settore del vulnerability research crowdsourced, sempre più travolto da una crescita esplosiva di report generati con l’AI, falsi positivi e attività automatizzate a basso valore.

La rivoluzione AI sta travolgendo i bug bounty

Negli ultimi mesi il mondo dei bug bounty è stato investito da un’ondata senza precedenti di segnalazioni generate o assistite da AI. Secondo diversi operatori del settore, i moderni LLM consentono ormai anche a utenti con competenze offensive limitate di produrre grandi quantità di report apparentemente plausibili, saturando i team di triage e aumentando enormemente il rumore operativo.

Il problema non riguarda solo HackerOne. Secondo Financial Times, alcune piattaforme hanno registrato un aumento quadruplo delle submission nel giro di poche settimane, mentre la percentuale di report realmente validi sarebbe crollata in molti casi sotto il 5%.

Il problema è talmente grave che persino Linus Torvalds ha recentemente definito la mailing list sicurezza del kernel Linux “quasi completamente ingestibile” a causa dell’aumento di report AI-generated.

HackerOne cerca di ridurre il rumore operativo

Il drastico ridimensionamento delle ricompense sembra quindi essere parte di una strategia più ampia. Già ad aprile 2026 HackerOne aveva annunciato la sospensione temporanea delle nuove submission per il programma Internet Bug Bounty, spiegando che il rapporto tra velocità di discovery e capacità di remediation era diventato insostenibile.

Secondo la piattaforma, l’intelligenza artificiale ha “industrializzato” la scoperta delle vulnerabilità molto più rapidamente rispetto alla capacità dei maintainer open source di validare, correggere e distribuire patch. In pratica, l’intero ecosistema dei bug bounty starebbe soffrendo un problema strutturale: trovare vulnerabilità sta diventando sempre più facile, ma gestirle continua a richiedere tempo umano altamente specializzato.

Questo crea un paradosso operativo. Da un lato le piattaforme ricevono volumi enormi di report; dall’altro il valore medio reale delle submission tende a diminuire.

Il rischio di una crisi economica per i ricercatori indipendenti

La riduzione dei payout rischia però di avere conseguenze importanti anche sulla sostenibilità economica del bug hunting indipendente. Negli ultimi dieci anni piattaforme come HackerOne e Bugcrowd hanno contribuito a trasformare il vulnerability research in una vera professione, creando un mercato globale basato sulla disclosure responsabile.

Molti ricercatori hanno costruito carriere interamente basate sui bug bounty, mentre alcune aziende hanno iniziato a utilizzare il crowdsourced testing come alternativa o complemento ai penetration test tradizionali. Secondo vari report di settore, i payout per vulnerabilità critiche nei programmi enterprise possono ancora raggiungere cifre a sei zeri, soprattutto in ambito cloud, crypto e infrastrutture strategiche. Tuttavia il drastico taglio del programma IBB mostra che il modello economico tradizionale potrebbe non essere più sostenibile per alcuni ecosistemi open source.

Il rischio, secondo diversi esperti, è che i ricercatori più qualificati inizino progressivamente ad abbandonare i bounty pubblici meno remunerativi, spostandosi verso altri ambiti.

L’effetto collaterale: meno vulnerabilità divulgate?

Storicamente i bug bounty sono stati considerati uno strumento fondamentale per incentivare la disclosure responsabile. L’idea alla base del modello è relativamente semplice: pagare i ricercatori affinché segnalino vulnerabilità ai vendor invece di venderle a broker, spyware company o gruppi criminali.

Ma il mercato delle vulnerabilità è cambiato enormemente negli ultimi anni. Diversi studi mostrano che il valore economico dei mercati grigi e dei broker zero-day può essere enormemente superiore rispetto ai payout tradizionali dei bug bounty. In alcuni casi vulnerabilità particolarmente critiche possono raggiungere cifre superiori al milione di dollari sui mercati offensivi.

Se i payout pubblici diminuiscono troppo, il rischio teorico è che una parte dei ricercatori inizi a considerare meno conveniente la disclosure responsabile tradizionale. Naturalmente il panorama resta molto più complesso di così. Per molti ricercatori contano anche reputazione, visibilità, riconoscimento professionale e opportunità lavorative future. Tuttavia il fattore economico continua a rappresentare uno dei principali motori dell’intero ecosistema.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/05/21/hackerone-taglia-drasticamente-le-ricompense-dei-bug-bounty/?utm_source=rss&utm_medium=rss&utm_campaign=hackerone-taglia-drasticamente-le-ricompense-dei-bug-bounty




Attacco ai router Huawei dietro blackout telecom del Lussemburgo


Un attacco informatico basato su una vulnerabilità sconosciuta nei router enterprise di Huawei avrebbe causato nel 2025 uno dei più gravi incidenti infrastrutturali europei degli ultimi anni, provocando il collasso temporaneo dell’intera rete telecom del Lussemburgo.

Secondo quanto riportato da Recorded Future News, l’incidente avrebbe coinvolto un comportamento non documentato del sistema operativo di rete Huawei VRP, sfruttato tramite traffico malevolo appositamente costruito per mandare in crash i router dell’operatore nazionale POST Luxembourg.

L’attacco, avvenuto il 23 luglio 2025, ha causato un’interruzione completa delle comunicazioni mobili 4G e 5G, della telefonia fissa e persino di parte dei servizi di emergenza nazionali per oltre tre ore.

La vicenda solleva interrogativi particolarmente delicati non solo sul piano tecnico, ma anche su quello della trasparenza nella disclosure delle vulnerabilità critiche che coinvolgono infrastrutture telecom strategiche.

Un blackout nazionale causato da traffico di rete malevolo

Secondo le informazioni emerse, l’attacco avrebbe sfruttato un’anomalia mai documentata pubblicamente nel software di routing Huawei. Paul Rausch, responsabile comunicazione di POST Luxembourg, ha confermato che l’incidente è stato causato da un attacco denial-of-service basato su un “comportamento non pubblico e non documentato” per il quale non esisteva alcuna patch disponibile al momento dell’incidente. Il traffico malevolo avrebbe innescato un ciclo continuo di reboot dei router enterprise Huawei, causando il collasso progressivo di parti critiche dell’infrastruttura telecom nazionale.

L’aspetto più interessante è che gli investigatori lussemburghesi non ritengono che l’attacco fosse necessariamente diretto contro il Lussemburgo come bersaglio specifico. Secondo le autorità, il traffico malevolo potrebbe semplicemente essere transitato attraverso l’infrastruttura di POST Luxembourg, provocando accidentalmente il crash dei dispositivi Huawei invece della normale elaborazione e inoltro dei pacchetti. In pratica, i router avrebbero reagito al traffico anomalo entrando in una condizione di failure non prevista che li costringeva a riavviarsi ripetutamente.

Il caso riapre il dibattito sugli zero-day nelle infrastrutture critiche

Diversi elementi emersi nelle indagini portano a classificare l’incidente come un possibile zero-day, cioè una vulnerabilità sconosciuta pubblicamente e priva di patch disponibili. Secondo le fonti citate da Recorded Future News, Huawei avrebbe dichiarato di non aver mai osservato un comportamento simile presso altri clienti e di non aver avuto a disposizione in quel momento una soluzione pronta per mitigare il problema.

Il punto più controverso riguarda però l’assenza totale di disclosure pubblica.

A quasi dieci mesi dall’incidente, non risulta infatti assegnato alcun identificativo CVE pubblico relativo alla vulnerabilità sfruttata nell’attacco. Non esistono advisory aperti alla comunità di sicurezza, né dettagli tecnici che consentano agli operatori telecom di verificare eventuali esposizioni analoghe.

E questo è un problema. I CVE rappresentano infatti uno dei principali strumenti globali per tracciare vulnerabilità, coordinare attività di remediation e permettere ai team SOC e CERT di identificare rapidamente i sistemi vulnerabili.

L’assenza di disclosure pubblica crea quindi un problema potenzialmente sistemico: altri operatori che utilizzano gli stessi apparati Huawei potrebbero non sapere di essere esposti allo stesso comportamento anomalo.

Huawei e il problema della trasparenza nelle vulnerabilità enterprise

La vicenda evidenzia anche un cambiamento nel modo in cui Huawei gestisce la disclosure delle vulnerabilità enterprise. Sempre secondo Recorded Future News, mentre il vendor continua a pubblicare CVE per prodotti consumer, le disclosure pubbliche relative ai prodotti enterprise networking sono diventate sempre più rare negli ultimi anni. Huawei pubblica anche advisory di sicurezza enterprise, ma spesso attraverso portali clienti riservati invece che tramite comunicazioni pubbliche aperte alla comunità globale di sicurezza.

La situazione rischia inevitabilmente di alimentare ulteriori tensioni geopolitiche attorno alle infrastrutture telecom cinesi, tema già al centro di anni di dibattiti internazionali su supply chain security, rischio cyber e sovranità digitale.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/05/20/attacco-ai-router-huawei-dietro-blackout-telecom-del-lussemburgo/?utm_source=rss&utm_medium=rss&utm_campaign=attacco-ai-router-huawei-dietro-blackout-telecom-del-lussemburgo




MSHTA, lo “zombie” di IE che alimenta attacchi su Windows


Nonostante Internet Explorer sia ormai ufficialmente morto da tempo, uno dei suoi componenti storici continua a rappresentare un serio problema di sicurezza per gli ambienti Windows moderni. Si tratta di MSHTA.exe, il Microsoft HTML Application Host, una utility legacy ancora inclusa di default nel sistema operativo e oggi sempre più sfruttata dai cybercriminali per distribuire malware, loader e infostealer.

Secondo una nuova ricerca pubblicata da Bitdefender Labs, negli ultimi mesi si è registrato un forte aumento delle catene di attacco che utilizzano mshta.exe come componente centrale delle operazioni malevole. Il fenomeno riguarda sia campagne cybercriminali opportunistiche sia minacce più sofisticate basate su tecniche LOLBIN, cioè “Living-off-the-Land Binary”.

Il problema è particolarmente delicato perché MSHTA è un binario firmato da Microsoft e considerato legittimo dal sistema operativo. Questo consente agli attaccanti di utilizzare uno strumento trusted di Windows per eseguire codice malevolo riducendo la probabilità di essere intercettati dalle difese tradizionali.

Cos’è MSHTA e perché esiste ancora in Windows

MSHTA nasce alla fine degli anni ’90 insieme a Internet Explorer 5 come componente dedicato all’esecuzione delle cosiddette HTML Application (HTA), applicazioni sviluppate con HTML, VBScript e JavaScript. L’obiettivo originario era permettere la creazione di piccoli strumenti amministrativi o applicazioni desktop leggere basate su tecnologie web. Nonostante la progressiva scomparsa di Internet Explorer, Microsoft ha continuato a mantenere MSHTA in Windows per ragioni di backward compatibility, soprattutto nei contesti enterprise dove alcuni ambienti legacy continuano ancora a dipendere da script e applicazioni HTA.

Secondo Bitdefender, una parte limitata dell’utilizzo di MSHTA è ancora legittima. Alcuni amministratori lo impiegano per script di login, notifiche di aggiornamento o piccoli tool interni. Tuttavia, la componente malevola sta crescendo molto più rapidamente rispetto agli utilizzi leciti. Ma c’è un problema: MSHTA consente di eseguire script direttamente in memoria, scaricare contenuti remoti ed eludere diversi controlli di sicurezza sfruttando un processo firmato Microsoft.

Come gli attaccanti usano MSHTA nelle campagne malware

Secondo i ricercatori di Bitdefender, MSHTA viene oggi utilizzato soprattutto come stadio intermedio nelle moderne catene di infezione. Gli attaccanti convincono la vittima ad aprire file HTA o eseguire comandi apparentemente innocui tramite phishing, siti fake, campagne ClickFix o falsi aggiornamenti software. Una volta avviato, mshta.exe può recuperare script remoti e lanciare codice PowerShell o VBScript direttamente in memoria senza scrivere necessariamente payload evidenti sul disco.

Questo approccio permette di distribuire malware come Lumma Stealer, Amatera e altri infostealer moderni mantenendo un profilo operativo relativamente basso. Bitdefender segnala inoltre che molti dei domini contattati dalle campagne osservate utilizzano tecniche di typosquatting, simulando URL apparentemente legittimi per aumentare la credibilità dell’infrastruttura malevola. Il vantaggio per gli attaccanti è duplice. Da un lato utilizzano un binario di sistema trusted; dall’altro eseguono gran parte dell’attività malevola direttamente in memoria, riducendo la visibilità per antivirus e strumenti EDR meno evoluti.

Il ritorno dei LOLBIN e la crisi delle difese tradizionali

Il caso MSHTA conferma un trend ormai consolidato nel panorama della cybersecurity: il ritorno massiccio delle tecniche LOLBIN. Invece di introdurre malware custom facilmente identificabili, molti gruppi criminali preferiscono sfruttare componenti già presenti nel sistema operativo per mascherare le proprie attività. Windows offre numerosi strumenti di questo tipo — PowerShell, rundll32, regsvr32, certutil, wmic — e MSHTA continua a essere uno dei più efficaci.

Questo approccio complica enormemente il lavoro dei team SOC perché il comportamento osservato appare inizialmente legittimo. Bloccare completamente mshta.exe può inoltre creare problemi operativi in alcune aziende che utilizzano ancora applicazioni legacy. Secondo diversi analisti, il problema deriva anche dall’enorme eredità storica di Windows. La necessità di mantenere compatibilità con software sviluppati decenni fa continua infatti a lasciare disponibili componenti che oggi rappresentano superfici di attacco estremamente appetibili.

Perché MSHTA è ancora così efficace contro le aziende

Uno degli aspetti più interessanti evidenziati dal report riguarda la persistenza operativa di questo strumento nonostante le tecnologie moderne di sicurezza. Molte organizzazioni si concentrano infatti sulla rilevazione del malware finale, ma monitorano molto meno attentamente i processi trusted del sistema operativo.

MSHTA permette inoltre di concatenare facilmente più tecnologie offensive. Un semplice file HTA può scaricare script PowerShell, avviare payload in memoria, contattare server remoti e stabilire persistenza senza utilizzare eseguibili tradizionali. In diversi scenari, gli attaccanti utilizzano MSHTA anche come componente iniziale per campagne ransomware o compromissioni enterprise più ampie.

Il problema è aggravato dal fatto che molte campagne moderne sfruttano social engineering avanzato. Le vittime vengono indotte a eseguire manualmente comandi o aprire file apparentemente innocui tramite falsi CAPTCHA, notifiche browser, finte procedure di supporto tecnico o documenti Office malevoli.

La sfida futura: eliminare il legacy senza rompere Windows

La vicenda riapre inevitabilmente il dibattito sulla gestione delle componenti legacy all’interno di Windows. Microsoft sta progressivamente dismettendo diverse tecnologie storiche, ma molti strumenti rimangono presenti per garantire compatibilità con ambienti enterprise complessi. Nel frattempo, però, i cybercriminali continuano a sfruttare proprio queste aree grigie dell’ecosistema Windows.

Secondo Bitdefender, il numero di catene malevole che coinvolgono mshta.exe è aumentato sensibilmente negli ultimi mesi, segnale che gli attaccanti considerano ancora questo strumento estremamente efficace. Per i team di sicurezza questo significa che la semplice presenza di processi firmati Microsoft non può più essere considerata automaticamente affidabile. Servono capacità avanzate di behavioral analysis, monitoraggio delle child process, controllo delle connessioni outbound e visibilità sulle esecuzioni in memoria.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/05/19/mshta-lo-zombie-di-internet-explorer-che-alimenta-attacchi-su-windows/?utm_source=rss&utm_medium=rss&utm_campaign=mshta-lo-zombie-di-internet-explorer-che-alimenta-attacchi-su-windows