China’s Top Cybersecurity Firms Hit by Mounting Military Procurement Bans

China’s military procurement system has suspended or permanently barred more than a dozen of the country’s leading cybersecurity vendors since 2024, according to new research from threat intelligence group Natto Thoughts. 

The findings, based on public notices from the military procurement network cross-referenced with corporate disclosures and Chinese media reports, identify at least 21 enforcement actions between 2021 and 2026 tied to contract bidding misconduct rather than product or technical failures.

The penalties fall under a three-tier system used by the People’s Liberation Army (PLA): a private warning list for early-stage concerns, a suspension list for confirmed but limited violations, and a public blacklist reserved for serious offenses that can carry lifetime bans extending to affiliated companies and executives.

[ Read: China, India-Linked Hackers Both Targeted Same Pakistani Police Force ]

One example is Beijing TopSec Network Security, an indirect subsidiary of TopSec Technologies Group. In 2024, the company was suspended from specific services for three years after it was accused of collusive bidding on an Army contract, but investigators later expanded the suspension to cover all military branches. In January 2026, following a two-year probe, authorities imposed a lifetime ban on all military procurement, the maximum penalty available.

Venustech Group followed a similar trajectory, but the impact on the company was less severe. Its subsidiary, Beijing Venustech Information Security Technology, was suspended from a regional military command in August 2024 and from all military bidding in February 2025. In April 2026, the sanctions escalated to include the parent company itself. However, the action remains a suspension rather than a permanent ban.

Advertisement. Scroll to continue reading.

Other firms named in the research include Qi An Xin’s Legendsec subsidiary, digital certificate provider BJCA, Kylinsec, Westone (CETC Cyber Security), and Huaru Technologies. Several of these companies are publicly traded or holders of classified systems and defense-related qualifications.

These firms occupy a dual role in China’s security ecosystem, according to Eugenio Benincasa, a China-focused cybersecurity researcher at ETH Zurich, who co-authored the report [subscription required] with Natto Thoughts co-founder Mei Danowski.

On the defensive side, Benincasa told SecurityWeek, companies like TopSec and Venustech pioneered China’s firewall market, while Qi An Xin has built a strong position in threat intelligence. 

None of the firms have been publicly linked to directly operating offensive hacking groups, Benincasa said, but they have long-standing ties to the PLA and China’s security services, supporting military cyber operations through training and service provision, and, in Qi An Xin’s case, through investments in companies tied to known Chinese APT activity.

The Natto team ties the increase in enforcement to a broader shift in PLA procurement oversight, including 2024 regulations on competitive bidding for military equipment and the growing enforcement role of China’s newly formed Cyberspace Force, which the report credits with six of the reviewed violation cases.

The researchers also point to commercial pressure as a contributing factor. For instance, Venustech’s early-2025 outlook cited softening security budgets and a market pivot toward AI- and data-driven demand, a shift that TopSec appears to be navigating as well.

Despite the penalties, the report concludes that the Chinese military still depends heavily on these firms for modernization, framing the crackdown as an effort to professionalize defense acquisition rather than evidence that China’s cybersecurity capabilities are weakening.

Related: Chinese Cybersecurity Firm’s AI Hacking Claims Draw Comparisons to Claude Mythos

Related: China Revives Tianfu Cup Hacking Contest Under Increased Secrecy

Related: Cybersecurity Firms React to China’s Reported Software Ban

https://www.securityweek.com/chinas-top-cybersecurity-firms-hit-by-mounting-military-procurement-bans/




Albiriox, il RAT bancario che si finge UniCredit su Telegram

Una finta promozione, la promessa di 100 dollari e un bot Telegram: è la trappola con cui, in una campagna a tema italiano documentata dalla società italiana D3Lab, viene distribuito Albiriox, un banking trojan Android costruito per la frode on-device. Il marchio abusato è quello di UniCredit, ma conviene chiarirlo subito per non generare equivoci: la banca e i suoi clienti sono le vittime dell’operazione, non la fonte di una compromissione. La catena descritta non coinvolge alcun sistema dell’istituto; ad essere sfruttata è la sua identità, usata come esca.

La catena di infezione

Secondo l’analisi di D3Lab, l’allarme è partito da un servizio di brand monitoring che ha intercettato un dominio appena registrato, unicredit-tme[.]shop
, creato l’8 luglio 2026. La pagina promette una ricompensa e invita a scaricare un’app, ma invece di rimandare a uno store ufficiale porta a un bot Telegram (
@UniCreditit_bot
) che guida la vittima nell’installazione. L’incentivo è esplicito: 100 dollari per chi installa l’applicazione e altri 50 per chi invita un amico, un meccanismo referral che trasforma il raggiro in un moltiplicatore di diffusione.

La campagna non risulta appoggiarsi a Google Play né ad altri store ufficiali: l’utente viene convinto a installare l’APK manualmente, presumibilmente dopo aver abilitato le sorgenti sconosciute. Il dettaglio tecnico più rilevante è che il file scaricato è un dropper autocontenuto: il payload di secondo stadio non viene prelevato dalla rete a runtime, ma è già incorporato nell’APK, spezzato in più asset con estensioni fuorvianti, ricomposto in locale, decifrato in AES-CBC e decompresso con GZIP. Così la catena di consegna deve solo convincere la vittima a installare il primo file: il resto avviene sul dispositivo, senza un secondo download che potrebbe fallire o essere intercettato dai controlli di rete.

Che cosa fa Albiriox una volta a bordo

Il secondo stadio si registra come servizio di Accessibility e da lì controlla il telefono. Le capacità osservate sono quelle di un banking trojan moderno: overlay per catturare credenziali (con schermate configurabili per PIN, pattern, coppie utente/password), intercettazione degli SMS e degli OTP, controllo remoto in stile VNC con manipolazione dello schermo, fino alla modalità black screen che nasconde all’utente ciò che l’operatore sta facendo.

L’operatore non si limita a rubare le password: agisce direttamente dentro le sessioni bancarie legittime, aggirando i passaggi di autenticazione. La comunicazione con il server avviene su un protocollo TCP grezzo con messaggi JSON, verso 179[.]43[.]159[.]210
sulle porte 5555
e 5552
; nel codice compare persino un marcatore di campagna con il paese bersaglio scritto in cirillico, Италия
, indizio dell’ecosistema in cui il builder è stato configurato.

L’attribuzione ad Albiriox, spiega D3Lab, poggia sul confronto manuale con un campione noto, sulle somiglianze di protocollo e sul materiale Telegram del progetto: il sample italiano appare una build personalizzata e offuscata. Vale la cautela d’obbligo sui nomi: si tratta di una build riconducibile alla famiglia, le cui funzionalità D3Lab allinea alla versione 1.5 annunciata dagli sviluppatori a gennaio 2026.

Perché conta per il mercato italiano

Albiriox non nasce oggi. La ricerca di Cleafy, che per prima ne ha descritto la famiglia, lo inquadra come offerta Malware-as-a-Service commercializzata su forum di lingua russa, con una fase beta a settembre 2025 e la commercializzazione dall’ottobre successivo, a canoni mensili nell’ordine delle centinaia di dollari; la lista hardcoded dei bersagli superava le 400 applicazioni bancarie, di pagamento e crypto, come riportato dalla stampa specializzata. La novità della campagna italiana non è quindi il malware in sé, ma la sua localizzazione: un pacchetto pronto all’uso viene calato su un marchio bancario nazionale e distribuito con un funnel social semplice ed economico.

Il segnale non è isolato: nella sintesi settimanale del 4-10 luglio il CERT-AGID ha rilevato campagne italiane a tema banking veicolate via SMS con link al download di APK malevoli, tra cui Albiriox insieme a RedWing e RedHook. Vettori diversi, stessa famiglia: nella stessa settimana Albiriox arriva agli utenti italiani per almeno due strade distinte.

Per il settore finanziario italiano contano soprattutto due elementi. La superficie di attacco resta il fattore umano unito al sideloading, mentre il brand monitoring si conferma un segnale di early warning: un dominio appena registrato che imita una banca è spesso il primo anello di una catena malevola, non solo phishing. Il mobile banking trojan a tema Italia è del resto un filone già noto al mercato, come mostra il caso del trojan Xenomorph.

La difesa passa per il presidio dei domini simili al proprio marchio, il blocco dei bot Telegram usati come vettore, la comunicazione ai clienti che nessuna banca distribuisce APK fuori dagli store, e il monitoraggio dei dispositivi che installano app con permessi di Accessibility e connessioni TCP verso porte anomale. Sul versante utente, la logica è la stessa che vale contro ogni account takeover: diffidare di premi che chiedono un’installazione, e trattare ogni APK ricevuto via messaggistica come ostile.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/albiriox-rat-bancario-italia/




Old UEFI Shims Expose Systems to Secure Boot Bypass

Nearly a dozen Unified Extensible Firmware Interface (UEFI) shim bootloaders signed by Microsoft allow attackers to bypass Secure Boot protections, ESET warns.

Small, trusted pieces of software bridge a computer motherboard’s UEFI firmware and the operating system, typically a Linux distribution, enabling the machine to boot with Secure Boot enabled.

By using Microsoft-signed UEFI shim bootloaders, Linux distributions can establish a trust model without requiring individual keys to be built into the motherboard’s NVRAM. The shims allow bootloaders, kernels, and other components to run during Secure Boot.

While various vulnerabilities have been addressed in the open source shim project over time, not all vendors updated their bootloaders, and these older shims remained signed and trusted within the Secure Boot chain, exposing systems to potential attacks.

According to ESET, 11 such old, forgotten UEFI shims, primarily from version 0.9 and earlier, lingered around until revoked by Microsoft on June 2026 Patch Tuesday. Two CVEs were assigned, namely CVE-2026-8863 and CVE-2026-10797.

The vulnerable shims, ESET says, could be exploited to “bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate authority (CA) certificate, regardless of the installed operating system (OS).”

Advertisement. Scroll to continue reading.

Coming from various tools and packages, these shims extend the attack surface through their trusted second-stage bootloaders. Additionally, attackers could bring their own vulnerable shims to systems that have enrolled the Microsoft third-party UEFI certificate.

“Signing and compilation timestamps of the applications trusted by the shims we reported span from 2013 to 2025 – enough to confirm that a significant portion of these binaries were old and likely affected by numerous publicly known vulnerabilities, [such as] BootHole in the case of GRUB2,” ESET notes.

Continuous trust in these old, vulnerable shims allows attackers to execute untrusted code during the boot process and deploy bootkits even if Secure Boot is enabled.

ESET reported the findings to CERT/CC in February 2026. In June, Microsoft revoked all vulnerable applications and added them to the UEFI DBX (Forbidden Signature Database). According to CERT/CC, system admins should update the signature database (DB) before applying DBX revocations.

“In practice, this means updating trusted boot applications and certificates first, followed by deployment of the revocation list. Failure to follow this order may cause systems to reject newly updated boot components. Enterprises, virtualization providers, and cloud operators managing large-scale deployments should prioritize validation and deployment of these updates to prevent the execution of vulnerable or unsigned binaries during physical or virtual machine startup,” CERT/CC notes.

Since 2017, shims have been signed and documented after a vetting process, but those approved before then are not documented, and many old, still-trusted shims may remain, potentially exposing systems to attacks.

Related: New Exploit Bypasses Apple’s Boot Defenses, Affects Millions of iPhones

Related: Nightmare Eclipse Drops ‘LegacyHive’ Windows Zero-Day

Related: Trend Micro, Tanium, ESET and Tenable Patch Severe Product Vulnerabilities

Related: Unpatched Cursor Vulnerability Exposes Users to Code Execution

https://www.securityweek.com/old-uefi-shims-expose-systems-to-secure-boot-bypass/




You Can’t Secure a Ship Like a Laptop

Modern cargo vessels are becoming floating distributed data centers. A single ship spends weeks at sea exchanging data with cloud platforms, fleet management systems, cargo-monitoring applications, and shore-based operations centers. Thousands of connected devices run at once across the vessel and its cargo.

That connectivity improves visibility and control, but it also creates a security problem most organizations underestimate. Many shipping companies still secure a vessel as if it were a remote branch office. It is something else: an unattended edge environment where systems run autonomously across shifting networks and jurisdictions, with no one aboard to troubleshoot, verify device integrity, or step in when something breaks.

Security Without a Human Backstop

Most enterprise security architectures rest on one assumption: when something goes wrong, someone can respond. An administrator investigates an alert. A technician replaces hardware or applies a patch. At sea, that assumption fails, and several common security controls fail with it.

Take secure boot. It verifies that a device starts from a trusted, signed image. It does not verify that the image is still the version the operator would want running months or years later. A device can keep booting a known-vulnerable image indefinitely and still pass every secure-boot check.

Remote patching solves part of this, but only if the process itself is reliable, automated, and doesn’t open new attack surfaces in the act of closing old vulnerabilities. A patch that requires physical intervention or fails silently on one vessel in a hundred-vessel fleet isn’t a security control. It’s a liability.

Physical security also presents challenges. Operators rarely control everyone with physical access to a vessel, especially in chartered or leased environments. If hardware is removed, tampered with, or replaced, a response may be impossible until the next port.

Scale compounds the problem. Large fleets carry thousands of devices across hundreds of vessels. At that scale, manual verification, patching, and inventory management break down. When a device drops off the network, no one can easily tell whether it was compromised, stolen, or simply disconnected.

The pattern is the same: traditional controls assume a human backstop is always available. In unattended environments, security must continuously verify system integrity rather than waiting for someone to restore trust after a failure.

When Compliance and Security Diverge

It’s tempting to treat certification as the finish line: pass the audit, earn the designation, and declare the system secure. But compliance and security are not the same, especially in environments that run for months or years between physical inspections.

Log4Shell made this concrete. Overnight, organizations running software certified under recognized security standards had a critical, widely exploited flaw on their hands. They faced an uncomfortable choice: patch immediately and risk falling out of compliance, or stay compliant and keep running vulnerable software. They could be compliant and exposed at the same time.

That tension is sharpening at sea. Regulators and industry bodies now demand stronger cybersecurity governance, software integrity, and centralized management of shipboard systems. Those developments are valuable and long overdue, but a certification is only a snapshot, and a vessel stays in service for years.

The operators best positioned for this reality will treat compliance as a baseline rather than an endpoint. The more important question is whether they can continuously verify system integrity, respond to new vulnerabilities, and securely update systems long after the audit is over.

Building Security for Unattended Systems

If traditional models fail because they assume a human is in the loop, more monitoring won’t fix the problem. You should design systems that establish and maintain trust on their own, starting with continuous verification. Instead of validating software only when a device starts, modern architectures can measure and attest to the integrity of firmware, operating systems, and workloads across the device’s whole lifecycle. Trust becomes an ongoing process, not a one-time event.

Second, trust has to stay tied to the hardware itself. You can bind cryptographic keys and sensitive workloads to a device’s trusted hardware and software state, which makes stolen equipment or extracted storage far less useful to an attacker. Where physical access can’t be tightly controlled, that matters.

Consistency matters just as much. Security gets harder as systems drift from their intended configuration. Immutable operating environments and centrally managed software deployments reduce that drift, so teams know exactly what is running across a distributed fleet.

AI-powered code analysis tools are surfacing vulnerabilities faster than ever, but patching systems on vessels daily or weekly isn’t realistic. That’s where defense-in-depth earns its value. Layer security controls so that any single unpatched flaw doesn’t hand attackers a path through the system. Most discovered vulnerabilities should have no exploitable foothold by the time they are found.

Finally, unattended environments need centralized orchestration. Security teams can’t send technicians to log into individual systems scattered across hundreds of vessels. Policies, updates, and verification have to be managed remotely and applied consistently at fleet scale.

Together, these approaches shift security from a model that relies on human intervention to one that continuously establishes trust through the platform itself. This is fast becoming the operating model for large-scale edge environments, whether in data centers, industrial facilities, or vessels at sea.

The Architecture Is Already Here

Some major shipping operators are already building this model. Maersk, for example, is deploying a next-generation IoT platform across hundreds of owned and chartered vessels, supporting thousands of connected devices managed remotely from shore. The headline benefits are operational — greater visibility into cargo, equipment, and fleet performance — but the underlying architecture reflects the realities of unattended environments. You can deploy, monitor, update, and secure systems without relying on staff aboard every vessel.

That distinction matters because operational resilience and security increasingly depend on the same foundation. Organizations that design for unattended operation gain both.

Why Ships Are the Real Test of Edge Security

As organizations push more connected infrastructure to the edge, blocking unauthorized access is the easy part, and the harder problem becomes trusting systems that run for long stretches without anyone there to watch them.

Few edge environments are more remote or more operationally critical than a vessel at sea. Maritime environments break a hidden assumption in traditional security models: that someone is always on hand to investigate alerts, approve actions, or restore trust after a failure.

That is why ships matter beyond shipping. They are the clearest test of whether a security architecture was built for the edge. A model that can continuously verify, update, and protect systems in the middle of the ocean will work anywhere.

https://www.securitymagazine.com/articles/102406-you-cant-secure-a-ship-like-a-laptop




Nightmare Eclipse Drops ‘LegacyHive’ Windows Zero-Day 

Nightmare Eclipse, the disgruntled security researcher who has been dropping zero-day exploits targeting Microsoft products, released another unpatched Windows vulnerability this week, right on the July 2026 Patch Tuesday.

The fresh exploit, named LegacyHive, is a local privilege escalation bug in the Windows User Profile Service that allows an attacker to load other users’ hives, including those of administrators.

Also known as Chaotic Eclipse, Nightmare Eclipse released proof-of-concept (PoC) exploit code that works on systems running Microsoft’s July 2026 patches.

“The PoC requires another standard user credentials and a third username (which can be an administrator account), if the PoC is successful, it will end up mounting the target user hive in current user classes root,” the researcher explains.

Unlike previously dropped zero-day exploits from Nightmare Eclipse, LegacyHive was released with a stripped PoC to prevent the security defect’s in-the-wild exploitation.

According to the researcher, the exploit originally did not require user credentials and allowed any hive to be loaded, not just the usrclass.dat hive. That is still possible, the researcher says, but would require some work.

Advertisement. Scroll to continue reading.

To date, Nightmare Eclipse released over half a dozen zero-days in Microsoft products, including BlueHammer, RedSun, and UnDefend, which have been exploited in attacks, along with GreenPlasma, RoguePlanet, YellowKey, and GreatXML.

Microsoft has yet to acknowledge the LegacyHive exploit. SecurityWeek has emailed the company for a statement and will update this article if it responds.

Related: Unpatched Cursor Vulnerability Exposes Users to Code Execution

Related: CISA Urges Immediate Patching of Exploited SharePoint Vulnerabilities

Related: Windows Bind Link Attacks Can Hide Malware From EDR Tools

Related: Progress Confirms Zero-Day Vulnerability Behind ShareFile Disruption

https://www.securityweek.com/nightmare-eclipse-drops-legacyhive-windows-zero-day/




Comunicazione di crisi: il lato dell’incidente che non si risolve in sala server

La comunicazione di crisi è l’insieme delle decisioni con cui un’organizzazione, mentre un incidente è in corso, sceglie cosa dire, a chi e in quale momento. È la metà meno tecnica e più sottovalutata della risposta a un attacco informatico, eppure è quella su cui, a distanza di mesi, si misura quasi sempre il danno vero. Un attacco si contiene nel giro di ore o giorni; la fiducia di clienti, autorità e mercato si perde o si difende in base a poche frasi pronunciate nelle prime ore, quando le informazioni sono incomplete e la tentazione di tacere o minimizzare è più forte.

Il paradosso è che la parte tecnica di un incidente segue procedure note, mentre la comunicazione viene quasi sempre improvvisata. Le organizzazioni investono in strumenti di rilevamento e in piani di ripristino, ma raramente hanno pronto, prima che serva, chi parla a nome dell’azienda, con quali messaggi e dentro quali vincoli di legge. Il risultato è che la prima dichiarazione, quella che resterà agli atti e nei titoli, viene spesso scritta sotto pressione da chi non avrebbe dovuto scriverla.

Perché la comunicazione è parte della risposta, non un’appendice

Trattare la comunicazione come un’attività separata, da affidare all’ufficio stampa a emergenza conclusa, è l’errore concettuale di fondo. Gli standard di settore la collocano invece dentro la gestione dell’incidente. La guida del NIST sulla risposta agli incidenti prevede il coordinamento e la condivisione delle informazioni tra le funzioni come parte integrante del processo, e lo standard internazionale dedicato alla gestione delle crisi, la ISO 22361 pubblicata nel 2022, dedica alla comunicazione di crisi una sezione specifica, costruita attorno a pochi principi: informazioni accurate, credibili e tempestive, coerenza del messaggio tra i diversi canali, consapevolezza delle barriere che ostacolano la comprensione e gestione attenta dei social media, descritti insieme come opportunità e minaccia.

Lo stesso standard chiarisce un punto che ha conseguenze pratiche: la strategia di comunicazione deve essere definita e approvata dai vertici prima della crisi, non costruita durante. È la stessa logica che governa la gestione degli incidenti sul piano tecnico, dove la qualità della risposta si decide nella preparazione. Per la comunicazione vale identicamente: chi non ha stabilito in anticipo chi è il portavoce, quali sono i canali e quali i messaggi di base per gli scenari più probabili, si troverà a deciderlo nel momento peggiore.

Le tre domande della comunicazione di crisi: cosa, a chi e quando

Ogni comunicazione di crisi si regge su tre decisioni che vanno prese quasi simultaneamente. La prima riguarda i destinatari, che non sono un pubblico indistinto. I dipendenti vanno informati prima che leggano la notizia altrove, perché diventano inevitabilmente i primi testimoni verso l’esterno. I clienti hanno bisogno di sapere se i loro dati sono coinvolti e cosa devono fare. Le autorità competenti vanno notificate entro termini di legge precisi. I partner della catena di fornitura devono poter valutare la propria esposizione. Stampa e opinione pubblica arrivano per ultimi nell’ordine di priorità, ma sono i più rapidi a colmare con ipotesi il vuoto lasciato dal silenzio.

La seconda decisione è il contenuto, e qui il principio guida è la coerenza. Messaggi diversi a interlocutori diversi sono fisiologici, ma non devono contraddirsi, perché una contraddizione tra ciò che si dice ai clienti e ciò che si dichiara alla stampa diventa essa stessa la notizia. Il contenuto deve dire ciò che è confermato, ammettere ciò che non si sa ancora e indicare cosa l’organizzazione sta facendo, senza promettere ciò che non si è certi di poter mantenere. Una rassicurazione smentita il giorno dopo costa più del problema che voleva nascondere.

La terza decisione è il tempo. Comunicare troppo presto, con informazioni sbagliate, è pericoloso; comunicare troppo tardi cede il racconto ad altri. La via praticabile è la comunicazione progressiva: un primo messaggio che riconosce la situazione e dice che si sta indagando, seguito da aggiornamenti man mano che il quadro si chiarisce. Il silenzio totale, nella convinzione di parlare solo a indagini concluse, è quasi sempre la scelta peggiore, perché trasmette l’idea che l’organizzazione non controlli ciò che sta accadendo.

Gli obblighi di legge che scandiscono i tempi

La comunicazione di crisi, nel caso di un attacco informatico, non è solo una scelta strategica: è in parte un obbligo giuridico con scadenze cronometrate. Il Regolamento generale sulla protezione dei dati impone, ai suoi articoli 33 e 34, di notificare una violazione di dati personali all’autorità di controllo entro settantadue ore dal momento in cui se ne è venuti a conoscenza, salvo che sia improbabile un rischio per i diritti delle persone, e di comunicarla anche agli interessati, senza ingiustificato ritardo, quando il rischio per loro è elevato. La direttiva NIS2, per i soggetti che vi rientrano, aggiunge una scansione ancora più stretta: un pre-allarme entro ventiquattro ore dalla consapevolezza di un incidente significativo, una notifica più completa entro settantadue ore e una relazione finale entro un mese. Per le organizzazioni incluse nel Perimetro di Sicurezza Nazionale Cibernetica i termini si comprimono ulteriormente, fino a sei ore o addirittura un’ora a seconda della gravità dell’incidente, una finestra in cui non c’è alcuno spazio per l’improvvisazione.

Questi termini cambiano la natura della comunicazione, perché la trasformano in un processo con una sveglia che corre dal primo istante. Significa che la decisione di chi notifica, con quali contenuti e tenendo il conto di quali scadenze, va presa quando tutti sono concentrati sul contenimento tecnico. Per questo gli adempimenti NIS2 in materia di notifica non sono un capitolo a parte rispetto alla gestione dell’incidente, ma una sua componente che va provata in anticipo, perché nessuno improvvisa una notifica giuridicamente corretta in ventiquattro ore mentre i sistemi sono fermi.

Gli errori che trasformano una crisi gestibile in un disastro reputazionale

Le crisi che degenerano raramente lo fanno per il danno tecnico in sé. Degenerano per come vengono raccontate. Il primo errore è il silenzio prolungato, l’idea di non dire nulla finché non si sa tutto: lascia spazio a ricostruzioni esterne che poi è difficilissimo correggere. Il secondo è la minimizzazione, il dichiarare che è tutto sotto controllo quando non lo è, perché ogni sviluppo successivo smentirà la rassicurazione e ogni smentita eroderà la credibilità di quella dopo. Il terzo è la pluralità di voci non coordinate, con persone diverse che rilasciano versioni incoerenti, situazione che lo standard ISO indica esplicitamente tra le barriere a una comunicazione efficace.

C’è poi un errore più sottile, quello di considerare la comunicazione un problema solo esterno. Una crisi mal comunicata all’interno, con dipendenti tenuti all’oscuro, produce ansia, voci incontrollate e fughe di informazioni verso l’esterno che vanificano qualsiasi strategia mediatica. La comunicazione interna e quella esterna sono lo stesso problema visto da due lati, e vanno gestite con la stessa cura. Lo strumento che previene gran parte di questi errori non è il talento del portavoce, ma la preparazione: messaggi di base già abbozzati per gli scenari ricorrenti, un portavoce designato e addestrato, e prove regolari che mettano alla prova non solo la reazione tecnica ma anche quella comunicativa, come avviene nelle esercitazioni di crisi che simulano l’intera catena decisionale.

La comunicazione di crisi, in fondo, non è l’arte di dire la cosa giusta sotto pressione, ma il risultato di un lavoro fatto quando la pressione non c’è. Le organizzazioni che escono meglio da un incidente non sono quelle che hanno trovato le parole perfette nel momento dell’emergenza, ma quelle che avevano già deciso, a freddo, chi parla, a chi, entro quali termini di legge e con quale messaggio di fondo. È in questo spostamento, dalla reazione improvvisata alla capacità preparata, che una crisi smette di essere una minaccia esistenziale per la reputazione e torna a essere ciò che dovrebbe restare: un problema tecnico grave, ma gestito.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/cyber-security/comunicazione-di-crisi-incidente-cyber/




Unpatched Cursor Vulnerability Exposes Users to Code Execution

An unpatched vulnerability in Cursor on Windows can be triggered for code execution when a developer opens a repository in the application, Mindgard reports.

Cursor is one of the most popular AI-assisted development environments, with more than 7 million active users.

The security defect, Mindgard says, is straightforward: when opening a repository, Cursor would automatically execute a malicious git.exe binary in the project’s root without warning the user or asking for approval.

“The vulnerability is not theoretical and does not depend on a complex chain of exploitation, prompt injection, model manipulation, jailbreaks, memory corruption, or sophisticated attacker tradecraft. Exploitation simply requires a developer to open a project containing a git.exe binary in the repository at the root,” Mindgard says.

According to Mindgard, the issue exists because, when loading a project, Cursor looks for Git binaries in multiple locations, including the workspace itself.

“If an attacker planted a malicious git.exe in the repository root, Cursor will execute it automatically as part of its path resolution logic without warning, approval, or even an indication that executable content from the repository is about to run,” Mindgard explains.

Advertisement. Scroll to continue reading.

Mindgard has disclosed the vulnerability publicly after reporting it to Cursor on December 15, 2025, and receiving no response regarding a potential patch for seven months.

The company says Cursor’s CISO invited Mindgard to its bug bounty program on HackerOne in January, where the security defect was resubmitted and confirmed as reproducible, but it has not received a response from Cursor.

“But coordinated disclosure only works when there is coordination. Seven months after initial disclosure, we have no indication that users are being protected, that remediation is underway, or that affected organizations have been informed. And at this point, withholding information no longer serves users; it serves silence,” Mindgard notes.

SecurityWeek has emailed Cursor for a statement on the matter and will update this article if the company responds.

Related: Windows Bind Link Attacks Can Hide Malware From EDR Tools

Related: Vulnerabilities Patched by Fortinet, Ivanti, ServiceNow

Related: Progress Confirms Zero-Day Vulnerability Behind ShareFile Disruption

Related: NIST Opens Updated IoT Security Guidance to Public Review

https://www.securityweek.com/unpatched-cursor-vulnerability-exposes-users-to-code-execution/




CISA Urges Immediate Patching of Exploited SharePoint Vulnerabilities

The US Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday urged immediate hardening of Microsoft SharePoint servers in light of recently disclosed zero-day vulnerabilities.

The freshest of the exploited flaws is CVE-2026-56164, a privilege escalation issue that can be exploited remotely without authentication, and which was resolved with Microsoft’s July 2026 Patch Tuesday updates.

On Tuesday, CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog, urging federal agencies to patch it within three days, in line with BOD 26-04 recommendations.

Microsoft’s latest round of security updates also resolved CVE-2026-55040 and CVE-2026-58644, critical-severity SharePoint bugs that could be exploited remotely to bypass a security feature and to execute arbitrary code.

Although not flagged as exploited, these vulnerabilities pose a risk to organizations if they are not patched in due time, CISA warns.

The cybersecurity agency also draws attention to CVE-2026-32201, a spoofing issue in SharePoint patched in April after being exploited in attacks as a zero-day.

Advertisement. Scroll to continue reading.

Another exploited SharePoint flaw is CVE-2026-45659, a code execution issue patched in May via an out-of-band security update, which was added to CISA’s KEV list in early July.

“These vulnerabilities affect all supported on-premises SharePoint Server versions (Subscription Edition, 2019, and 2016) and involve establishing remote code execution (RCE) and post-exploitation activities, such as stealing Internet Information Services (IIS) machine keys and performing deserialization techniques, to gain persistence and deploy malware,” CISA warns.

The agency recommends that organizations monitor their SharePoint servers to identify any signs of unusual activity, which could point to active exploitation.

In addition to applying Microsoft’s patches, organizations are advised to ensure that their security products cover all SharePoint web applications, hunt for intrusions, rotate IIS machine keys, enable tailored logging, ensure that SharePoint servers are not directly exposed to the internet, and restrict access to the administration interfaces.

Related: White House Launches AI-Driven ‘Gold Eagle’ Vulnerability Coordination Initiative

Related: CISA Urges Immediate Patching of Exploited ColdFusion, Langflow, Joomla Flaws

Related: SonicWall Issues Urgent SMA Patch Warning for Two Zero-Day Exploits

Related: US, Allies Warn of Russian Cyberattacks Targeting Critical Infrastructure Routers

https://www.securityweek.com/cisa-urges-immediate-patching-of-exploited-sharepoint-vulnerabilities/




The Agentic Insider: Why AI Tech Stacks Are the Ultimate Insider Threat

For decades, an insider threat was a human problem. It was the disgruntled employee, the compromised contractor, or the careless team member. Security leaders managed this risk through a combination of trust and verification: background checks, restricting access to files required only for daily role (known as least-privilege access), and behavioural monitoring to spot someone entering an office or accessing a database at 2 AM.

But as organizations move beyond Large Language Models (LLMs) and toward agentic AI, the very definition of insider threat is expanding. We no longer deal only with systems that generate answers. We are deploying systems that can pursue objectives, use credentials, access data, interact with applications and trigger actions inside and sometimes outside of our organizations.

That is a materially different scale of risk. An LLM is closer to a digital library: useful, powerful, but largely dependent on the user. An AI agent is closer to an enhanced human operator. It can act at machine speed, across connected systems, using the permissions it has been granted. Yet, many organizations are still treating these agents as ordinary applications, when they should be governing them more like high-risk users with privileged access.

The Rapid Rise of Agentic AI 

Across the globe, organizations are under immense pressure to increase speed and reduce costs by automating complex processes through agentic AI — and are rushing to capture these efficiencies at an unprecedented pace. According to recent Gartner projections, 40% of enterprise applications will feature integrated, task-specific AI agents by the end of 2026 — a massive jump from less than 5% in 2025. Companies are adopting or experimenting with these agents to autonomously execute complex processes like invoice processing, supplier payments, and even the management of operational technology in manufacturing plants and hospitals.

To function, these agents require deep access to internal systems and permission to complete actions. A supply chain agent, for example, is not just reading reports. It may be approving orders, changing suppliers, rerouting shipments, initiating payments or interacting with systems that affect warehouses, factories and transport networks. In some cases, these agents operate with limited human supervision and, at times, no supervision at all. They have effectively become insiders that never sleep, operate at unprecedented speed and can chain actions across multiple parts of the organization.

The Fast-Emerging Blind Spots

This creates several immediate blind spots. The first is trust without context. Many organizations are giving AI agents access to internal systems before they understand how they are configured, what they can do, or what normal behavior looks like. It is the digital equivalent of hiring someone into a sensitive role without a background check or job description. The risk is even greater when agents are bought from third-party vendors, where the organization may have limited visibility over how the system was built, tested, governed or updated.

Insider risk has always involved ambiguity. An employee entering a factory at night might be responding to an emergency, or they might be acting outside policy. AI agents create the same problem, but at machine speed. An agent may access systems, move data or trigger workflows in ways that look legitimate because they sit within its permissions. Yet if the agent is optimizing for speed or efficiency, it may also take shortcuts that bypass controls or create risks no one anticipated. Without a behavioral baseline, security teams may not know whether the agent is performing normally, drifting from its intended role, or becoming a source of harm.

We are also seeing the emergence of what could be called Russian Doll risks, or more technically a nested delegation risk: one layer of delegation hidden inside another. A human tasks an agent, the agent tasks another agent, and that second agent may interact with a supplier’s own agent. Each step moves human oversight further away from the action. It also makes it harder to know who, or what, made a decision, and whether the right controls were applied.

Finally, agentic AI risk cannot sit in an organizational silo. When companies treat AI agents purely as an IT or cybersecurity issue, they miss the fact that these systems may be given access to financial, operational and physical environments. If IT provisions an agent without input from Legal, HR, Physical Security and the relevant business owner, the organization loses sight of the full risk picture. That creates gaps in accountability, where an agent can operate across departments without anyone clearly owning what it is allowed to do, how it is monitored, or when it should be stopped.

Mapping a Path Forward: Actionable Steps for the C-Suite

Agentic AI tech stacks are fast becoming one of the most consequential insider risks facing organizations. The issue is no longer limited to data theft or misuse of information. As agents gain access to financial, operational and physical systems, a failure of governance could disrupt a critical pipeline, interfere with logistics or affect the delivery of care in a hospital.

Boards and security leaders therefore need to move from passive implementation to active agentic governance. That means rewriting their security playbook around three core priorities: 

  1. Implement agentic AI background checks: Treat the procurement of any autonomous AI agent with the same scrutiny you would apply to a high-risk human hire. Security leaders must vet third-party vendors, investigate how the models are built, and verify exactly what internal networks they are permitted to touch.
  2. Establish behavioral baselines: You cannot spot a rogue agent if you do not know what normal behavior looks like. Organizations must continuously monitor and define baseline activity for every deployed agent to immediately catch and stop unauthorized shortcuts.
  3. Dissolve departmental silos: Pull AI risk out of the IT basement. Bring the Chief Information Security Officer, Chief Security Officer, and Chief People Officer into a unified risk group. Just as HR and security align to manage human insider threats, they must align to manage digital ones.

The pace of AI development means organizations are having to move faster than ever, but at the same time, things will never be this slow again. We have a narrow window to build the frameworks that will govern the machines we have invited into our inner circles. The question for every C-suite is simple: Do you know what your agents are doing right now, and have you given them permission to do it?

https://www.securitymagazine.com/articles/102405-the-agentic-insider-why-ai-tech-stacks-are-the-ultimate-insider-threat




Risposta agli incidenti: il nuovo approccio del NIST SP 800-61

La risposta agli incidenti è l’insieme delle attività con cui un’organizzazione si prepara a un attacco informatico, lo individua, lo contiene e ne esce ripristinando ciò che è stato colpito. Per quasi due decenni, dalla prima edizione del 2004, il riferimento di tutto il settore è stato un ciclo a quattro fasi codificato dal NIST, una sequenza ordinata che ha insegnato a generazioni di professionisti come muoversi durante un incidente. Nel 2025, però, il NIST ha cambiato impostazione in modo netto, e capire perché aiuta a vedere come è maturata l’intera disciplina.

Il punto non è che il vecchio schema fosse sbagliato, ma che il modo in cui veniva usato si era irrigidito. Trattato come una lista di controllo lineare, da percorrere dall’inizio alla fine quando l’allarme era già scattato, finiva per relegare la risposta agli incidenti a un’attività isolata, di competenza quasi esclusiva del reparto tecnico, scollegata dal resto della gestione del rischio. La revisione del 2025 nasce proprio per correggere questa deriva.

Dal ciclo a quattro fasi alla revisione 3

Il modello classico, contenuto nella seconda revisione della guida del NIST, descriveva la risposta agli incidenti in quattro fasi: preparazione; rilevamento e analisi; contenimento, eradicazione e ripristino; attività post-incidente. Era uno schema solido e didatticamente efficace, e in realtà già concepito come ciclo, con le attività post-incidente che rialimentavano la preparazione. Il limite non stava nella sua forma, ma nel modo in cui veniva spesso applicato: come una lista lineare da percorrere quando l’allarme era già scattato, dando l’impressione che la risposta cominciasse con il rilevamento e si esaurisse con il ripristino, quasi fosse un episodio a sé.

La terza revisione, il NIST SP 800-61 Rev. 3 pubblicata nell’aprile 2025, supera quel modello e ne propone uno sensibilmente diverso. Non descrive più un ciclo separato, ma inserisce la risposta agli incidenti dentro la più ampia gestione del rischio, mappandola sulle sei funzioni del CSF 2.0, il quadro di riferimento del NIST per la cybersicurezza. La risposta agli incidenti, in altre parole, smette di essere una procedura accanto alle altre e diventa una capacità che attraversa l’intero modo in cui un’organizzazione governa la propria sicurezza.

Le sei funzioni applicate alla risposta agli incidenti

Le sei funzioni del CSF 2.0 sono Govern (governare), Identify (identificare), Protect (proteggere), Detect (rilevare), Respond (rispondere) e Recover (ripristinare). La revisione 3 le usa come ossatura, distribuendo tra esse ciò che prima era confinato nelle quattro fasi. La novità più significativa è la presenza di Govern, la funzione introdotta dal CSF 2.0, che porta la responsabilità di definire strategia, ruoli e politiche della risposta al livello di governo dell’organizzazione, legando la gestione dell’incidente alle scelte di chi la guida.

Il documento raggruppa le funzioni in modo istruttivo. La preparazione non è più una singola fase iniziale, ma il prodotto continuo di Govern, Identify e Protect, cioè di tutto ciò che si fa prima e indipendentemente da un attacco: conoscere i propri rischi, proteggere gli asset, stabilire chi decide cosa. La gestione vera e propria dell’incidente vive invece nelle funzioni Detect, Respond e Recover. E il miglioramento continuo, le lezioni apprese da ogni evento, non è un’appendice finale ma un filo che rientra costantemente nella funzione Identify, alimentando la preparazione del giro successivo.

Un esempio concreto aiuta a vedere la differenza. Di fronte a un attacco ransomware, nel vecchio schema si sarebbe partiti dal rilevamento; nella nuova impostazione, gran parte del lavoro è già avvenuto prima. La funzione Govern ha stabilito chi ha l’autorità di dichiarare la crisi e quali sono le priorità dell’organizzazione; Identify ha mappato quali sistemi sono critici e quali dati sono in gioco; Protect ha predisposto i backup e le segmentazioni che limiteranno il danno. Solo a quel punto entrano in scena Detect, che riconosce la cifratura in corso, Respond, che isola i sistemi e attiva le comunicazioni previste, e Recover, che ripristina a partire dai backup. La qualità della risposta, in questo quadro, si decide molto prima dell’attacco.

Perché il cambiamento conta

Il valore di questa riorganizzazione sta nel messaggio di fondo: la risposta agli incidenti non è qualcosa che il SOC fa da solo quando suona l’allarme, ma una capacità che si costruisce ogni giorno e che parte dall’alto. Collocando Govern tra le funzioni, il NIST mette nero su bianco che la preparazione a un incidente è una responsabilità di governo, non una faccenda puramente operativa. È un’impostazione che si salda perfettamente con la direzione presa dalle normative recenti, che hanno reso i vertici aziendali responsabili in prima persona della gestione del rischio cyber.

Ne discende anche una conseguenza pratica sulla preparazione, che cessa di essere un adempimento da spuntare una volta per diventare una postura permanente. Mantenere viva quella postura significa esercitarsi con regolarità, ad esempio in ambienti come un cyber range, e curare con continuità le attività che riducono la superficie d’attacco, come una solida gestione delle vulnerabilità. Sono attività che nel vecchio schema rischiavano di apparire esterne alla risposta, e che nel nuovo ne sono invece parte integrante.

Cosa significa in pratica

Adottare l’impostazione della revisione 3 non vuol dire buttare via il lavoro fatto con il modello a quattro fasi. Le cose che accadono durante un incidente, rilevare, contenere, eradicare, ripristinare, restano quelle: cambia la cornice che le tiene insieme e il modo di pensarle. In concreto, significa allineare il proprio piano di risposta alle funzioni del CSF, coinvolgere il livello di governo nella definizione di ruoli e priorità, e trattare le lezioni apprese come un meccanismo di miglioramento continuo anziché come un verbale archiviato dopo l’emergenza.

Conviene anche evitare un equivoco: passare al nuovo modello non rende obsoleti i piani e le procedure costruiti negli anni. Un buon piano di risposta resta utile, va semplicemente riletto attraverso le funzioni del CSF, verificando che ciascuna sia presidiata e che le lezioni apprese da ogni esercitazione e da ogni incidente reale rientrino davvero nel ciclo, invece di fermarsi a un verbale. È proprio questo aggancio sistematico al miglioramento continuo, più che la riorganizzazione formale delle fasi, a fare la differenza tra un’organizzazione che impara dai propri incidenti e una che li ripete.

Per le organizzazioni italiane, questo approccio ha il vantaggio di parlare la stessa lingua degli obblighi che già le riguardano, dove la sicurezza è concepita come gestione del rischio governata dai vertici e non come un insieme di misure tecniche slegate. La risposta agli incidenti, vista così, non è il piano che si tira fuori dal cassetto quando ormai è troppo tardi, ma la misura di quanto un’organizzazione abbia saputo prepararsi, governare e migliorare prima che l’incidente arrivasse. È in questo spostamento, dal procedimento isolato alla capacità diffusa, che sta il senso della nuova impostazione del NIST.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/cyber-security/risposta-agli-incidenti-nist-800-61/