Introduction

Cyberthreats are constantly evolving, and email phishing is no exception. Threat actors keep coming up with new methods to bypass security filters and circumvent user vigilance. At the same time, established – and even long-forgotten – tactics have not gone anywhere; in fact, some are getting a second life. This post details some of the unusual techniques malicious actors are employing in 2025.

Using PDF files: from QR codes to passwords

Emails with PDF attachments are becoming increasingly common in both mass and targeted phishing campaigns. Whereas in the past, most PDF files contained phishing links, the main trend in these attacks today is the use of QR codes.

Email with a PDF attachment that contains a phishing QR code

This represents a logical progression from the trend of using QR codes directly in the email body. This approach simplifies the process of disguising the phishing link while motivating users to open the link on their mobile phone, which may lack the security safeguards of a work computer.

Email campaigns that include phishing links embedded in PDF attachments continue to pose a significant threat, but attackers are increasingly employing additional techniques to evade detection. For example, some PDF files are encrypted and protected with a password.

Phishing email with a password-protected PDF attachment

The password may be included in the email that contains the PDF, or it may be sent in a separate message. From the cybersecurity standpoint, this approach complicates quick file scanning, while for the recipients it lends an air of legitimacy to attackers’ efforts and can be perceived as adherence to high security standards. Consequently, these emails tend to inspire more user trust.

PDF file after the user enters the password

Phishing and calendar alerts

The use of calendar events as a spam technique, which was popular in the late 2010s but gradually faded away after 2019, is a relatively old tactic. The concept is straightforward: attackers send an email that contains a calendar appointment. The body of the email may be empty, but a phishing link is concealed in the event description.

Blank email with a phishing link in the calendar appointment

When the recipient opens the email, the event is added to their calendar – along with the link. If the user accepts the meeting without thoroughly reviewing it, they will later receive a reminder about it from the calendar application. As a result, they risk landing on the phishing website, even if they chose not to open the link directly in the original message.

In 2025, phishers revived this old tactic. However, unlike the late 2010s, when these campaigns were primarily mass mailshots designed with Google Calendar in mind, they are now being used in B2B phishing and specifically target office workers.

Phishing sign-in form for a Microsoft account from a calendar phishing attack

Verifying existing accounts

Attackers are not just updating the methods they use to deliver phishing content, but also the phishing websites. Often, even the most primitive-looking email campaigns distribute links to pages that utilize new techniques.

Voice message phishing

For example, we observed a minimalistic email campaign crafted to look like an alert about a voice message left for the user. The body of the email contained only a couple of sentences, often with a space in the word “voice”, and a link. The link led to a simple landing page that invited the recipient to listen to the message.

Landing page that opens when clicking the link in the phishing email

However, if the user clicks the button, the path does not lead to a single page but rather a chain of verification pages that employ CAPTCHA. The purpose is likely to evade detection by security bots.

The CAPTCHA verification chain

After repeatedly proving they are not a bot, the user finally lands on a website designed to mimic a Google sign-in form.

The phishing sign-in form

This page is notable for validating the Gmail address the user enters and displaying an error if it is not a registered email.

Error message

If the victim enters a valid address, then, regardless whether the password is correct or not, the phishing site will display another similar page, with a message indicating that the password is invalid. In both scenarios, clicking “Reset Session” opens the email input form again. If a distracted user attempts to log in by trying different accounts and passwords, all of these end up in the hands of the attackers.

MFA evasion

Because many users protect their accounts with multi-factor authentication, scammers try to come up with ways to steal not just passwords but also one-time codes and other verification data. Email phishing campaigns that redirect users to sites designed to bypass MFA can vary significantly in sophistication. Some campaigns employ primitive tactics, while others use well-crafted messages that are initially difficult to distinguish from legitimate ones. Let’s look at an email that falls in the latter category.

Phishing email that mimics a pCloud notification

Unlike most phishing emails that try to immediately scare the user or otherwise grab their attention, the subject here is quite neutral: a support ticket update from the secure cloud storage provider pCloud that asks the user to evaluate the quality of the service. No threats or urgent calls to action. If the user attempts to follow the link, they are taken to a phishing sign-in form visually identical to the original, but with one key difference: instead of pcloud.com, the attackers use a different top-level domain, p-cloud.online.

The phishing sign-in form

At every step of the user’s interaction with the form on the malicious site, the site communicates with the real pCloud service via an API. Therefore, if a user enters an address that is not registered with the service, they will see an error, as if they were signing in to pcloud.com. If a real address is entered, a one-time password (OTP) input form opens, which pCloud also requests when a user tries to sign in.

OTP input form

Since the phishing site relays all entered data to the real service, an attempt to trick the verification process will fail: if a random combination is entered, the site will respond with an error.

Attempting to bypass verification

The real OTP is sent by the pCloud service to the email address the user provided on the phishing site.

OTP email

Once the user has “verified” the account, they land on the password input form; this is also requested by the real service. After this step, the phishing page opens a copy of the pCloud website, and the attacker gains access to the victim’s account. We have to give credit to the scammers: this is a high-quality copy. It even includes a default folder with a default image identical to the original, which may delay the user’s realization that they have been tricked.

Password input form

Conclusion

Threat actors are increasingly employing diverse evasion techniques in their phishing campaigns and websites. In email, these techniques include PDF documents containing QR codes, which are not as easily detected as standard hyperlinks. Another measure is password protection of attachments. In some instances, the password arrives in a separate email, adding another layer of difficulty to automated analysis. Attackers are protecting their web pages with CAPTCHAs, and they may even use more than one verification page. Concurrently, the credential-harvesting schemes themselves are becoming more sophisticated and convincing.

To avoid falling victim to phishers, users must stay sharp:

• Treat unusual attachments, such as password-protected PDFs or documents using a QR code instead of a link to a corporate website, with suspicion.
• Before entering credentials on any web page, verify that the URL matches the address of the legitimate online service.

Organizations are advised to conduct regular security training for employees to keep them up-to-date on the latest techniques being used by threat actors. We also recommend implementing a reliable solution for email server security. For example, Kaspersky Security for Mail Server detects and blocks all the attack methods described in this article.

securelist.com/email-phishing-…

Introduction

Back in 2024, we gave a brief description of a complex cyberespionage campaign that we dubbed “PassiveNeuron”. This campaign involved compromising the servers of government organizations with previously unknown APT implants, named “Neursite” and “NeuralExecutor”. However, since its discovery, the PassiveNeuron campaign has been shrouded in mystery. For instance, it remained unclear how the implants in question were deployed or what actor was behind them.

After we detected this campaign and prevented its spreading back in June 2024, we did not see any further malware deployments linked to PassiveNeuron for quite a long time, about six months. However, since December 2024, we have observed a new wave of infections related to PassiveNeuron, with the latest ones dating back to August 2025. These infections targeted government, financial and industrial organizations located in Asia, Africa, and Latin America. Since identifying these infections, we have been able to shed light on many previously unknown aspects of this campaign. Thus, we managed to discover details about the initial infection and gather clues on attribution.

SQL servers under attack

While investigating PassiveNeuron infections both in 2024 and 2025, we found that a vast majority of targeted machines were running Windows Server. Specifically, in one particular infection case, we observed attackers gain initial remote command execution capabilities on the compromised server through the Microsoft SQL software. While we do not have clear visibility into how attackers were able to abuse the SQL software, it is worth noting that SQL servers typically get compromised through:

• Exploitation of vulnerabilities in the server software itself
• Exploitation of SQL injection vulnerabilities present in the applications running on the server
• Getting access to the database administration account (e.g. by brute-forcing the password) and using it to execute malicious SQL queries

After obtaining the code execution capabilities with the help of the SQL software, attackers deployed an ASPX web shell for basic malicious command execution on the compromised machine. However, at this stage, things did not go as planned for the adversary. The Kaspersky solution installed on the machine was preventing the web shell deployment efforts, and the process of installing the web shell ended up being quite noisy.

In attempts to evade detection of the web shell, attackers performed its installation in the following manner:

1. They dropped a file containing the Base64-encoded web shell on the system.
2. They dropped a PowerShell script responsible for Base64-decoding the web shell file.
3. They launched the PowerShell script in an attempt to write the decoded web shell payload to the filesystem.

As Kaspersky solutions were preventing the web shell installation, we observed attackers to repeat the steps above several times with minor adjustments, such as:

• Using hexadecimal encoding of the web shell instead of Base64
• Using a VBS script instead of a PowerShell script to perform decoding
• Writing the script contents in a line-by-line manner

Having failed to deploy the web shell, attackers decided to use more advanced malicious implants to continue the compromise process.

Malicious implants

Over the last two years, we have observed three implants used over the course of PassiveNeuron infections, which are:

• Neursite, a custom C++ modular backdoor used for cyberespionage activities
• NeuralExecutor, a custom .NET implant used for running additional .NET payloads
• the Cobalt Strike framework, a commercial tool for red teaming

While we saw different combinations of these implants deployed on targeted machines, we observed that in the vast majority of cases, they were loaded through a chain of DLL loaders. The first-stage loader in the chain is a DLL file placed in the system directory. Some of these DLL file paths are:

• C:\Windows\System32\wlbsctrl.dll
• C:\Windows\System32\TSMSISrv.dll
• C:\Windows\System32\oci.dll

Storing DLLs under these paths has been beneficial to attackers, as placing libraries with these names inside the System32 folder makes it possible to automatically ensure persistence. If present on the file system, these DLLs get automatically loaded on startup (the first two DLLs are loaded into the svchost.exe process, while the latter is loaded into msdtc.exe) due to the employed Phantom DLL Hijacking technique.

It also should be noted that these DLLs are more than 100 MB in size — their size is artificially inflated by attackers by adding junk overlay bytes. Usually, this is done to make malicious implants more difficult to detect by security solutions.

On startup, the first-stage DLLs iterate through a list of installed network adapters, calculating a 32-bit hash of each adapter’s MAC address. If neither of the MAC addresses is equal to the value specified in the loader configuration, the loader exits. This MAC address check is designed to ensure that the DLLs get solely launched on the intended victim machine, in order to hinder execution in a sandbox environment. Such detailed narrowing down of victims implies the adversary’s interest towards specific organizations and once again underscores the targeted nature of this threat.

Having checked that it is operating on a target machine, the loader continues execution by loading a second-stage loader DLL that is stored on disk. The paths where the second-stage DLLs were stored as well as their names (examples include elscorewmyc.dll and wellgwlserejzuai.dll) differed between machines. We observed the second-stage DLLs to also have an artificially inflated file size (in excess of 60 MB), and the malicious goal was to open a text file containing a Base64-encoded and AES-encrypted third-stage loader, and subsequently launch it.

Snippet of the payload file contents

This payload is a DLL as well, responsible for launching a fourth-stage shellcode loader inside another process (e.g. WmiPrvSE.exe or msiexec.exe) which is created in suspended mode. In turn, this shellcode loads the final payload: a PE file converted to a custom executable format.

In summary, the process of loading the final payload can be represented with the following graph:

Final payload loading

It is also notable that attackers attempted to use slightly different variants of the loading scheme for some of the target organizations. For example, we have seen cases without payload injection into another process, or with DLL obfuscation on disk with VMProtect.

The Neursite backdoor

Among the three final payload implants that we mentioned above, the Neursite backdoor is the most potent one. We dubbed it so because we observed the following source code path inside the discovered samples: E:\pro\code\Neursite\client_server\nonspec\mbedtls\library\ssl_srv.c. The configuration of this implant contains the following parameters:

• List of C2 servers and their ports
• List of HTTP proxies that can be used to connect to C2 servers
• List of HTTP headers used while connecting to HTTP-based C2 servers
• A relative URL used while communicating with HTTP-based C2 servers
• A range of wait time between two consecutive C2 server connections
• A byte array of hours and days of the week when the backdoor is operable
• An optional port that should be opened for listening to incoming connections

The Neursite implant can use the TCP, SSL, HTTP and HTTPS protocols for C2 communications. As follows from the configuration, Neursite can connect to the C2 server directly or wait for another machine to start communicating through a specified port. In cases we observed, Neursite samples were configured to use either external servers or compromised internal infrastructure for C2 communications.

The default range of commands implemented inside this backdoor allows attackers to:

• Retrieve system information.
• Manage running processes.
• Proxy traffic through other machines infected with the Neursite implant, in order to facilitate lateral movement.

Additionally, this implant is equipped with a component that allows loading supplementary plugins. We observed attackers deploy plugins with the following capabilities:

• Shell command execution
• File system management
• TCP socket operations

The NeuralExecutor loader

NeuralExecutor is another custom implant deployed over the course of the PassiveNeuron campaign. This implant is .NET based, and we found that it employed the open-source ConfuserEx obfuscator for protection against analysis. It implements multiple methods of network communication, namely TCP, HTTP/HTTPS, named pipes, and WebSockets. Upon establishing a communication channel with the C2 server, the backdoor can receive commands allowing it to load .NET assemblies. As such, the main capability of this backdoor is to receive additional .NET payloads from the network and execute them.

Tricky attribution

Both Neursite and NeuralExecutor, the two custom implants we found to be used in the PassiveNeuron campaign, have never been observed in any previous cyberattacks. We had to look for clues that could hint at the threat actor behind PassiveNeuron.

Back when we started investigating PassiveNeuron back in 2024, we spotted one such blatantly obvious clue:

Function names found inside NeuralExecutor

In the code of the NeuralExecutor samples we observed in 2024, the names of all functions had been replaced with strings prefixed with “Супер обфускатор”, the Russian for “Super obfuscator”. It is important to note, however, that this string was deliberately introduced by the attackers while using the ConfuserEx obfuscator. When it comes to strings that are inserted into malware on purpose, they should be assessed carefully during attribution. That is because threat actors may insert strings in languages they do not speak, in order to create false flags intended to confuse researchers and incident responders and prompt them to make an error of judgement when trying to attribute the threat. For that reason, we attached little evidential weight to the presence of the “Супер обфускатор” string back in 2024.

After examining the NeuralExecutor samples used in 2025, we found that the Russian-language string had disappeared. However, this year we noticed another peculiar clue related to this implant. While the 2024 samples were designed to retrieve the C2 server addresses straight from the configuration, the 2025 ones did so by using the Dead Drop Resolver technique. Specifically, the new NeuralExecutor samples that we found were designed to retrieve the contents of a file stored in a GitHub repository, and extract a string from it:

Contents of the configuration file stored on GitHub

The malware locates this string by searching for two delimiters, wtyyvZQY and stU7BU0R, that mark the start and the end of the configuration data. The bytes of this string are then Base64-decoded and decrypted with AES to obtain the C2 server address.

Snippet of the implant configuration

It is notable that this exact method of obtaining C2 server addresses from GitHub, using a string containing delimiter sequences, is quite popular among Chinese-speaking threat actors. For instance, we frequently observed it being used in the EastWind campaign, which we previously connected to the APT31 and APT27 Chinese-speaking threat actors.

Furthermore, during our investigation, we learned one more interesting fact that could be useful in attribution. We observed numerous attempts to deploy the PassiveNeuron loader in one particular organization. After discovering yet another failed deployment, we have detected a malicious DLL named imjp14k.dll. An analysis of this DLL revealed that it had the PDB path G:\Bee\Tree(pmrc)\Src\Dll_3F_imjp14k\Release\Dll.pdb. This PDB string was referenced in a report by Cisco Talos on activities likely associated with the threat actor APT41. Moreover, we identified that the discovered DLL exhibits the same malicious behavior as described in the Cisco Talos report. However, it remains unclear why this DLL was uploaded to the target machine. Possible explanations could be that the attackers deployed it as a replacement for the PassiveNeuron-related implants, or that it was used by another actor who compromised the organization simultaneously with the attackers behind PassiveNeuron.

When dealing with attribution of cyberattacks that are known to involve false flags, it is difficult to understand which attribution indicators to trust, or whether to trust any at all. However, the overall TTPs of the PassiveNeuron campaign most resemble the ones commonly employed by Chinese-speaking threat actors. Since TTPs are usually harder to fake than indicators like strings, we are, as of now, attributing the PassiveNeuron campaign to a Chinese-speaking threat actor, albeit with a low level of confidence.

Conclusion

The PassiveNeuron campaign has been distinctive in the way that it primarily targets server machines. These servers, especially the ones exposed to the internet, are usually lucrative targets for APTs, as they can serve as entry points into target organizations. It is thus crucial to pay close attention to the protection of server machines. Wherever possible, the attack surface associated with these servers should be reduced to a minimum, and all server applications should be monitored to prevent emerging infections in a timely manner. Specific attention should be paid to protecting applications against SQL injections, which are commonly exploited by threat actors to obtain initial access. Another thing to focus on is protection against web shells, which are deployed to facilitate compromise of servers.

Indicators of compromise

PassiveNeuron-related loader files
12ec42446db8039e2a2d8c22d7fd2946
406db41215f7d333db2f2c9d60c3958b
44a64331ec1c937a8385dfeeee6678fd
8dcf258f66fa0cec1e4a800fa1f6c2a2
d587724ade76218aa58c78523f6fa14e
f806083c919e49aca3f301d082815b30

Malicious imjp14k.dll DLL
751f47a688ae075bba11cf0235f4f6ee

securelist.com/passiveneuron-c…

If you think about it, STL files are like PDF files. You usually create them using some other program, export them, and then expect them to print. But you rarely do serious editing on a PDF or an STL. But what if you don’t have anything but the STL? [The Savvy Engineer] has a method to help you if you need to reverse engineer an STL file in FreeCAD. Check it out in the video below.

The problem is, of course, that STLs are made up of numerous little triangles. The trick is to switch workbenches and create a shape from mesh. That gets you part of the way.

Once you have a shape, you can convert it to a solid. At that point, you can create a refined copy. This gives you a proper CAD file that you can export to a STEP file. From there, you can use it in FreeCAD or nearly any other CAD package you like to use.

Once you have a proper object, you can easily use it like any other solid body in your CAD program. This is one of those things you won’t need every day, but when you do need it, it’ll come in handy.

Want to up your FreeCAD game? We can help. There are other ways to hack up STL files. You can even import them into TinkerCAD to do simple things, but they still aren’t proper objects.

youtube.com/embed/TddS7qhcDng?…

hackaday.com/2025/10/21/revers…

One downside of working with the old Inmos Transputer devices is the rarity and cost of the original silicon. Obviously, you can’t sidestep the acquisition of the processor—unless you emulate—but what about replacing the IMS C011/C012 link chip? You need this (expensive) part to interface the transputer to the programming host, but as [Erturk Kocalar] discovered, it’s perfectly possible to coax a Teensy to do that job for you just as well.
The unusual two-bit start sequence differentiates a data packet from an ACK. It’s simple to emulate if you use the LSB of a 9-bit word as a dummy start bit!
Transputers work by utilizing an array of bit serial interfaces to connect a network of devices, allowing for cooperative computation on tasks too large to fit on a single device. This protocol is, at its link level, a simple asynchronous bit serial affair, with 11-bit data messages, and a raw two-bit frame for the acknowledge. The C011 device at its heart is just a specialized UART—it takes 8-bit parallel data from the host, dealing with handshaking, and pushes it out to the first transputer in the chain at 5, 10 or 20 Mbps, but inverted and with two start bits and a single stop bit. In parallel, it performs the same task in the reverse direction.

[Erturk] realized that the Teensy UART has an inverted mode and, crucially, a 9-bit data mode. This allows the second start bit to be generated as bit 0 of the word, with the remaining eight bits forming the payload. Simple stuff. Additionally, the Teensy UART is capable of the maximum transputer bitrate of 20 Mbps, without breaking a sweat.

There is a slight issue, however, in that there is no way to send or receive the two-cycle acknowledgement frame directly. Since the protocol stop bit is a low, it is possible to implement this by simply sending a dummy data word with all 9 data bits low (since the acknowledge is a ‘1’, ‘0’ pattern). In one specific corner case, that of a direct memory PEEK operation, the command is clocked into the transputer, which sends back a two-cycle ACK—almost immediately followed by the 11-cycle data packet with the result. But, since the Teensy UART is still busy ‘fake decoding’ the full 11-bit dummy ACK message, it will miss the data packet entirely.

It turns out that the easiest way to get around this is to speed up the link and run at the maximum 20 Mbps rate. That way, the Teensy will have fully received the overly-long ACK long before the transputer has completed the PEEK command and started to send over the result. Why you would voluntarily run the link slower escapes us, once you’d got the design dialled in and reliability was a given, anyway.

We like transputers, a cool technology that died too soon. Here’s a quick guide to these innovative devices. Some people are really into transputer hardware, like this person. Finally, with the genuine hardware finicky to work with, expensive and hard to find, you could play along with your trusty web browser, and tick it off your nerdy bucket list.

hackaday.com/2025/10/20/puttin…

Il 20 ottobre 2025, la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha pubblicato un’allerta urgente riguardante una vulnerabilità critica, CVE-2025-33073, presente nel client SMB di Windows di Microsoft. Questa falla, caratterizzata da un controllo degli accessi inadeguato, potrebbe comportare un aumento significativo dei privilegi per gli aggressori. La vulnerabilità rappresenta un rischio elevato per gli attacchi informatici in tutto il mondo, motivo per cui è stata segnalata con urgenza.

Il CISA sollecita nel suo bollettino un’azione immediata: applicare le ultime patch di Microsoft come indicato nei loro avvisi di sicurezza o seguire la Direttiva operativa vincolante (BOD) 22-01 per i servizi cloud federali.

Secondo il catalogo delle vulnerabilità note sfruttate (KEV) della CISA, i malintenzionati possono creare uno script che ingannano il computer della vittima, inducendolo ad avviare una connessione SMB con il sistema dell’aggressore.

La falla, associata a CWE-284 (Improper Access Control), mette in evidenza le preoccupazioni di vecchia data sui meccanismi di autenticazione del protocollo SMB, che sono stati a lungo un obiettivo privilegiato dei criminali informatici, a partire dall’epidemia di WannaCry nel 2017 e il successivo BlueKeep.

Con l’intensificarsi delle minacce informatiche e l’aumento degli incidenti ransomware, le aziende si stanno affrettando ad applicare le patch ai propri sistemi prima della scadenza del 10 novembre.

La vulnerabilità sfrutta il protocollo Server Message Block (SMB), un elemento fondamentale della condivisione file e delle comunicazioni di rete di Windows.

Questo bug di sicurezza, una volta sfruttato, lascia la porta aperta ad accessi non autorizzati, potenzialmente permettendo agli aggressori di assumere il pieno controllo del dispositivo violato. Questa vulnerabilità può essere sfruttata mediante tecniche di ingegneria sociale o attraverso download drive-by, sfruttando l’errore degli utenti che inconsapevolmente eseguono il payload dannoso.

Una volta attivato, il client SMB si autentica sul server dell’aggressore, aggirando le normali misure di sicurezza e consentendo il movimento laterale all’interno delle reti. Sebbene la CISA sottolinei che non è noto se questa specifica falla alimenti le campagne ransomware, la tecnica rispecchia le tattiche utilizzate da gruppi come LockBit e Conti, che sfruttano abitualmente i protocolli Windows per l’accesso iniziale.

L’avviso giunge in un momento di tensione per gli amministratori IT, in seguito a un’ondata di exploit correlati alle PMI nel 2025, compresi quelli che hanno preso di mira ambienti Azure non aggiornati. Gli esperti avvertono che i sistemi non protetti potrebbero essere soggetti a esfiltrazione di dati o distribuzione di malware, soprattutto in settori come la finanza e l’assistenza sanitaria.

Se le misure di mitigazione non sono praticabili, interrompere l’utilizzo dei prodotti interessati. Strumenti come Windows Defender e il rilevamento degli endpoint di terze parti possono aiutare a monitorare le anomalie del traffico SMB.

L'articolo Vulnerabilità critica nel client SMB di Windows: CISA lancia l’allarme proviene da Red Hot Cyber.

In un’epoca in cui la produzione e la condivisione di dati personali avviene in maniera massiva e quotidiana, il concetto di anonimizzazione assume un ruolo centrale nel dibattito sulla tutela della privacy e sul riutilizzo etico dei dati. Con l’avvento del General Data Protection Regulation (GDPR), il quadro normativo europeo ha introdotto definizioni precise e obblighi stringenti per il trattamento dei dati personali, distinguendo in maniera netta tra dati identificabili, pseudonimizzati e completamente anonimizzati.

Secondo il GDPR, un dato può essere considerato anonimo solo quando è reso tale in modo irreversibile, ovvero quando non è più possibile identificare, direttamente o indirettamente, l’interessato, anche attraverso l’uso di informazioni supplementari o tecniche di inferenza. Tuttavia, raggiungere un livello di anonimizzazione assoluto è tutt’altro che banale: i dataset possono contenere identificatori diretti (come nomi o numeri di documento) e quasi-identificatori (informazioni come localizzazione, età o preferenze), che, se combinati, possono consentire la ri-identificazione degli individui.

L’interesse verso l’anonimizzazione è cresciuto in parallelo con l’aumento esponenziale della quantità di dati disponibili online. Oggi, oltre la metà della popolazione mondiale è connessa a Internet, e molte organizzazioni – grandi e piccole – analizzano i dati per individuare pattern, comportamenti e profili, sia a fini interni che per finalità commerciali. Spesso, questi dati vengono condivisi con terze parti o resi pubblici per scopi di ricerca, aumentando il rischio di esposizione di informazioni personali.

Negli anni si sono verificati numerosi casi in cui processi di anonimizzazione inadeguati hanno portato alla ri-identificazione degli utenti, con gravi conseguenze per la loro privacy. Eclatante il caso del 2006, in cui una piattaforma di streaming pubblicò un dataset contenente milioni di valutazioni di film dichiarate “anonime”, che furono però facilmente associate ai rispettivi utenti tramite dati incrociati. Similmente, nel 2013, il Dipartimento dei trasporti di New York rese pubblici i dati dei taxi cittadini, ma un’errata anonimizzazione consentì di risalire alle licenze originali e persino all’identità di alcuni conducenti.

Questi esempi dimostrano come l’anonimizzazione non sia solo una questione tecnica, ma anche normativa, etica e metodologica. Le domande che emergono sono molteplici:

• Quando un dato può dirsi davvero anonimo?
• Le tecniche di anonimizzazione sono sempre irreversibili?
• Come si misura l’efficacia dell’anonimizzazione rispetto alla perdita di utilità dei dati?

L’obiettivo di questo articolo è fare chiarezza su questi interrogativi, offrendo una panoramica delle principali tecniche di anonimizzazione oggi in uso, analizzando i rischi connessi alla ri-identificazione e illustrando come strumenti e metodologie possano supportare una pubblicazione sicura dei dati, conforme ai principi della privacy-by-design e della data protection. In particolare, si approfondiranno le differenze tra l’anonimizzazione dei dati relazionali e quella dei dati strutturati in forma di grafo, sempre più diffusi nell’ambito dei social network e delle analisi comportamentali.

Tecniche di Protezione dei Dati: confronto tra Pseudonimizzazione e Anonimizzazione

Il Regolamento Generale sulla Protezione dei Dati (GDPR) introduce una distinzione fondamentale tra dati personali, dati pseudonimizzati e dati anonimizzati, concetti che vengono spesso confusi, ma che hanno implicazioni molto diverse sul piano normativo, tecnico e operativo.

L’articolo 4 del GDPR fornisce le seguenti definizioni:

• Dati personali: qualsiasi informazione riguardante una persona fisica identificata o identificabile (data subject), direttamente o indirettamente.
• Pseudonimizzazione: trattamento dei dati personali in modo tale che non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, che devono essere conservate separatamente e protette da misure tecniche e organizzative adeguate.
• Anonimizzazione: processo attraverso il quale i dati personali vengono modificati in modo irreversibile, rendendo impossibile l’identificazione, diretta o indiretta, dell’individuo a cui si riferiscono.

Questa distinzione è tutt’altro che formale. Secondo il Considerando 26 del GDPR:

“I principi della protezione dei dati non dovrebbero applicarsi a informazioni anonime, ossia a informazioni che non si riferiscono a una persona fisica identificata o identificabile, o a dati personali resi anonimi in modo tale che l’interessato non sia più identificabile.”

In altre parole, una volta che i dati sono stati anonimizzati correttamente, non rientrano più nell’ambito di applicazione del GDPR. Ciò li rende estremamente preziosi per l’elaborazione, l’analisi e la condivisione, soprattutto in settori come la sanità, la statistica, il marketing e la ricerca scientifica.

Una delle convinzioni più diffuse – e pericolose – è ritenere che pseudonimizzazione e anonimizzazione siano equivalenti. In realtà, il GDPR è molto chiaro nel distinguere i due concetti.

• La pseudonimizzazione riduce il rischio di esposizione dei dati personali, ma non elimina il legame con l’identità dell’individuo. Chi è in possesso delle informazioni aggiuntive (es. tabelle di corrispondenza, chiavi di decodifica) può facilmente ripristinare l’identità.
• L’anonimizzazione, invece, comporta l’eliminazione definitiva di ogni possibilità di re-identificazione. I dati anonimizzati non permettono alcun collegamento con l’individuo e, pertanto, cessano di essere considerati dati personali.

Quindi, se esiste una possibilità – anche remota – di risalire all’identità di una persona, i dati non possono essere considerati anonimi, ma semplicemente pseudonimizzati.

Tecniche di Anonimizzazione dei Dati

La scelta della tecnica di anonimizzazione più adatta dipende strettamente dallo scopo per cui i dati devono essere anonimizzati. Ogni metodo comporta compromessi tra livello di privacy garantita e utilità residua del dato: più i dati sono protetti, minore sarà, in genere, la loro granularità e quindi il loro valore analitico.

Le principali modalità attraverso cui i dati possono essere trasformati a fini di anonimizzazione sono tre:

• Sostituzione di un valore o di un attributo,
• Modifica (generalizzazione o randomizzazione),
• Rimozione (soppressione) di attributi o interi record.

L’obiettivo, in ogni caso, è quello di garantire la privacy dei soggetti coinvolti senza compromettere l’utilizzabilità dei dati, soprattutto quando si tratta di analisi statistiche, ricerca o studi di mercato.

In questa sezione verranno presentate alcune delle principali tecniche di anonimizzazione, con indicazioni sul loro corretto utilizzo in base al contesto.

Soppressione di Attributi o Record

La soppressione è una delle tecniche più semplici e dirette: consiste nella rimozione di uno o più attributi da un dataset. È particolarmente utile quando:

• Un attributo non è rilevante ai fini dell’analisi,
• L’attributo contiene informazioni identificative dirette e non è possibile anonimizzarlo in altro modo,
• L’intero record rappresenta un rischio e deve essere rimosso.

Esempio pratico

Immaginiamo di voler analizzare le prestazioni di un gruppo di studenti in un test di valutazione. Il dataset a nostra disposizione contiene tre attributi per ciascun partecipante:

• Nome dello studente
• Nome del docente
• Voto ottenuto

Poiché l’obiettivo dell’analisi è di tipo statistico e non richiede l’identificazione dei singoli studenti, il nome dello studente risulta essere un’informazione non necessaria e altamente identificativa. Per garantire la privacy degli interessati, applichiamo la tecnica della soppressione, eliminando completamente la colonna contenente i nomi.

Dopo questa operazione, il dataset mantiene la propria utilità analitica, in quanto consente ancora di osservare e confrontare i risultati dei test in relazione ai diversi docenti o a gruppi di studenti, ma senza esporre informazioni personali.

In alcuni casi, la soppressione può riguardare anche interi record. Questo avviene, ad esempio, quando la combinazione di più attributi (come età, localizzazione geografica, e materia del test) rende un soggetto potenzialmente riconoscibile, soprattutto in campioni di piccole dimensioni. Se non è possibile anonimizzare efficacemente quei record con altre tecniche, la rimozione totale rappresenta la misura più sicura per tutelare la privacy.

La soppressione è una tecnica semplice ed efficace, in quanto elimina completamente le informazioni sensibili, rendendole irrecuperabili e garantendo così un elevato livello di protezione della privacy. Tuttavia, questa efficacia ha un costo: la rimozione di attributi o record può compromettere la qualità e l’utilità del dataset, soprattutto se le informazioni eliminate sono rilevanti per l’analisi. Inoltre, un uso non bilanciato della soppressione può introdurre distorsioni (bias) nei risultati, riducendo l’affidabilità delle conclusioni ottenute.

Sostituzione di Caratteri (Character Replacement)

La sostituzione di caratteri è una tecnica di anonimizzazione che consiste nel mascherare parzialmente il contenuto di un attributo, sostituendo alcuni caratteri con simboli predefiniti, come ad esempioX o*. Si tratta di un approccio utile quando si desidera nascondere parte dell’informazione, mantenendo però una certa struttura del dato, utile a fini analitici o di verifica. Questa tecnica non elimina l’attributo, ma oscura solo i dati più sensibili, rendendoli meno identificabili. La sostituzione può essere applicata, ad esempio, ai codici postali, ai numeri di telefono, agli indirizzi email o a qualsiasi campo testuale potenzialmente riconducibile a una persona.

Esempio pratico

Supponiamo di voler analizzare la distribuzione geografica degli utenti di un servizio, utilizzando il codice postale. Se il codice completo può rendere identificabile l’individuo, è possibile mascherarne le ultime cifre.

Prima della sostituzione:

• 20156
• 00189
• 70125

Dopo la sostituzione:

• 201XX
• 001XX
• 701XX

In questo modo, è ancora possibile condurre un’analisi per area geografica generale (es. quartieri o zone urbane), ma si elimina la precisione che potrebbe portare alla localizzazione esatta e quindi all’identificazione indiretta del soggetto.

La sostituzione di caratteri è facile da implementare e consente di mantenere una buona utilità del dato, ma è meno sicura rispetto ad altre tecniche più radicali, come la soppressione. Infatti, se il contesto circostante è troppo ricco di informazioni, o se vengono incrociati più attributi, può comunque emergere un rischio di re-identificazione.

Per questo motivo, questa tecnica è indicata soprattutto in dataset di grandi dimensioni, dove l’attributo mascherato non è sufficiente, da solo, a identificare una persona, ma può contribuire ad aumentare la protezione complessiva se combinato con altre tecniche.

Rimescolamento dei Dati (Shuffling)

La tecnica del rimescolamento, oshuffling, consiste nel riorganizzare in modo casuale i valori di un determinato attributo all’interno del dataset, mantenendo inalterata la lista dei valori ma disassociandoli dai relativi record originali. Questa tecnica è utile quando si vuole preservare la distribuzione statistica di un attributo, ma non è necessario mantenere la relazione tra quell’attributo e gli altri presenti nel dataset. In sostanza, i valori non vengono alterati, ma permessi tra i diversi record, rendendo più difficile il collegamento diretto tra un’informazione sensibile e un individuo specifico.

Esempio pratico

Immaginiamo di avere un dataset che contiene:

• ID cliente
• Regione geografica
• Importo speso

Se l’obiettivo è analizzare la distribuzione degli importi spesi per area geografica, ma senza voler collegare l’importo specifico al singolo cliente, possiamo applicare lo shuffling all’attributo “importo speso”, rimescolandone i valori tra i diversi record.

Prima dello shuffling:

Dopo lo shuffling dell’importo:

In questo modo, si preservano i dati regionali e la distribuzione aggregata degli importi, ma si interrompe la correlazione diretta tra individuo e valore economico, riducendo il rischio di identificazione.

Sebbene semplice da applicare, lo shuffling non garantisce da solo un’adeguata anonimizzazione. In alcuni casi, soprattutto quando i dataset sono piccoli o gli attributi fortemente correlati, potrebbe essere possibile ricostruire le associazioni originali attraverso tecniche di inferenza.

Per questo motivo, il rimescolamento viene spesso utilizzato in combinazione con altre tecniche, come la soppressione o la generalizzazione, per rafforzare la protezione dei dati.

Aggiunta di Rumore (Noise Addition)

L’aggiunta di rumore è una tecnica di anonimizzazione molto diffusa e consiste nel modificare leggermente i valori dei dati, introducendo delle variazioni artificiali che nascondono i valori reali, pur mantenendo l’informazione statisticamente utile. L’obiettivo è ridurre la precisione del dato per renderlo meno identificabile, ma senza compromettere l’utilità complessiva, soprattutto quando viene analizzato in aggregato.

Esempio pratico

Supponiamo di avere un dataset con le date di nascita dei pazienti in un’analisi epidemiologica. Per ridurre il rischio di identificazione, possiamo aggiungere o sottrarre casualmente alcuni giorni o mesi a ciascuna data.

Data originale:

• 12/06/1985
• 03/11/1990
• 28/04/1978

Dopo l’aggiunta di rumore (± qualche giorno):

• 10/06/1985
• 07/11/1990
• 30/04/1978

Queste variazioni non alterano in modo significativo l’analisi, ad esempio per fasce di età o tendenze temporali, ma rendono molto più difficile collegare con certezza una data a un individuo specifico.

Un elemento critico di questa tecnica è determinare quanto rumore aggiungere: troppo poco può non essere sufficiente a proteggere la privacy, mentre troppo può distorcere i risultati dell’analisi. Per questo motivo, è essenziale valutare attentamente il contesto di utilizzo e, quando possibile, applicare tecniche di aggiunta di rumore controllata, come nel caso della Differential Privacy, che vedremo più avanti.

Generalizzazione

La generalizzazione è un’altra tecnica di anonimizzazione in cui i dati vengono semplificati o aggregati in modo da ridurre il livello di dettaglio, e quindi la possibilità di identificazione. In pratica, si sostituisce un valore specifico con uno più generico, modificando la scala o il livello di precisione dell’attributo.

Esempio pratico

Nel caso delle date, invece di riportare giorno, mese e anno, possiamo decidere di conservare solo l’anno.

Data originale:

• 12/06/1985 → 1985
• 03/11/1990 → 1990
• 28/04/1978 → 1978

Un altro esempio classico riguarda l’età: anziché indicare “33 anni”, possiamo scrivere “30-35” o “30+”, riducendo la precisione ma mantenendo l’informazione utile per analisi demografiche.

La generalizzazione è particolarmente utile quando si vuole preservare l’analisi su gruppi (cluster), ma è meno efficace per studi che richiedono una precisione individuale. Inoltre, non sempre garantisce un livello sufficiente di anonimizzazione, soprattutto se i dati generalizzati possono essere incrociati con altre fonti.

È per questo motivo che la generalizzazione è spesso combinata con altre tecniche, o applicata attraverso modelli più evoluti come il k-anonimato e l-diversità, che vedremo nelle prossime sezioni.

K-Anonimity

L’idea alla base è quella di garantire che ogni record in un dataset non sia distinguibile da almeno altri k - 1 record, rispetto a un insieme di attributi considerati potenzialmente identificativi (dettiquasi-identificatori).

In altre parole, un dataset soddisfa il criterio di k-anonimato se, per ogni combinazione di attributi sensibili, esistono almeno k record identici, rendendo molto difficile risalire all’identità di una singola persona.

Esempio pratico

Supponiamo di avere un dataset con le seguenti colonne:

• Età
• CAP
• Patologia diagnosticata

Se questi attributi vengono considerati quasi-identificatori, e applichiamo il k-anonimato con k = 3, allora ogni combinazione di età e CAP dovrà comparire in almeno tre record.

Prima dell’anonimizzazione:

Dopo l’anonimizzazione con K = 3:

In questo esempio, l’età è stata generalizzata e il CAP parzialmente mascherato, in modo da creare un gruppo indistinguibile di almeno tre record. Di conseguenza, la probabilità di identificare un individuo specifico in quel gruppo è al massimo 1 su 3.

Le principali caratteristiche del k-anonimato sono:

• Maggiore è il valore di k, minore è il rischio di identificazione.
• La tecnica può essere applicata a diversi tipi di dati, ma richiede l’individuazione attenta dei quasi-identificatori.
• L’efficacia dipende fortemente dalla qualità e varietà del dataset: se troppo eterogeneo, la perdita di dettaglio può essere significativa.

Il k-anonimato non protegge dai cosiddetti attacchi di background knowledge: se un avversario conosce informazioni aggiuntive (es. una persona vive in un certo CAP e ha una certa età), potrebbe comunque risalire alla sua patologia, anche se presente in un gruppo di k elementi. Per mitigare questo rischio, si ricorre ad approcci più sofisticati, come l-diversità e t-closeness, che introducono ulteriori vincoli sulla distribuzione dei dati sensibili all’interno dei gruppi.

L-Diversity

La l-diversità è una tecnica che estende e rafforza il concetto di k-anonimato, con l’obiettivo di evitare che all’interno dei gruppi di equivalenza (ossia i gruppi di record resi indistinguibili tra loro) ci sia scarsa varietà nei dati sensibili.

Infatti, anche se un dataset è k-anonimo, può comunque essere vulnerabile: se in un gruppo di 3 record tutti i soggetti condividono lo stesso valore per un attributo sensibile (es. una malattia), un attaccante potrebbe facilmente dedurre quell’informazione, pur non sapendo esattamente a chi appartiene. Con l-diversità, si impone una regola aggiuntiva: ogni gruppo di equivalenza deve contenere almeno L valori distinti per l’attributo sensibile. Questo aumenta il livello di incertezza per chi tenta di effettuare una re-identificazione.

Esempio pratico

Riprendiamo l’esempio di un dataset sanitario con i seguenti attributi:

• Età
• CAP
• Diagnosi

Supponiamo di aver ottenuto gruppi indistinguibili tramite k-anonimato, ma che tutti i soggetti abbiano la stessa diagnosi:

Esempio di gruppo con scarsa diversità:

Un gruppo come questo rispetta il k-anonimato (k=3), ma è altamente vulnerabile, perché un attaccante sa che chiunque in quel gruppo ha il diabete.

Applicando L-Diversità (L=3):

Ora, anche se il gruppo è indistinguibile rispetto ai quasi-identificatori, l’attributo sensibile “diagnosi” ha almeno tre valori diversi, il che limita la possibilità di dedurre informazioni certe.

La l-diversità è efficace nel:

• Aumentare l’incertezza per gli attaccanti, anche in presenza di conoscenze pregresse.
• Evitare la perdita di riservatezza in caso di gruppi omogenei.

Tuttavia, non è infallibile: in situazioni in cui la distribuzione dei dati sensibili è fortemente sbilanciata (es. 9 diagnosi comuni e 1 rara), anche con l-diversità può verificarsi un attacco per inferenza probabilistica, dove l’informazione meno frequente può comunque essere dedotta con alta probabilità.

Rischi di Re-identificazione

Anche dopo l’anonimizzazione, esiste sempre un rischio residuo che un individuo possa essere identificato, ad esempio incrociando i dati con informazioni esterne o tramite inferenze. Per questo motivo, è fondamentale valutare attentamente il rischio prima di condividere o pubblicare un dataset.

I rischi si suddividono in tre categorie:

• Prosecutor Risk: l’attaccante sa che un individuo è nel dataset e cerca di trovarlo.
• Journalist Risk: l’attaccante non sa se l’individuo è presente, ma prova comunque a identificarlo.
• Marketer Risk: l’obiettivo è identificare quanti più record possibile, non singole persone.

Questi rischi sono gerarchici: se un dataset è protetto contro il rischio più elevato (prosecutor), è considerato sicuro anche rispetto agli altri.

Ogni organizzazione dovrebbe definire il livello di rischio accettabile, in base alle finalità e al contesto del trattamento dei dati.

Conclusioni

L’anonimizzazione dei dati rappresenta oggi una sfida cruciale nel bilanciare due esigenze spesso contrapposte: da un lato la protezione della privacy degli individui, dall’altro la valorizzazione del dato come risorsa per l’analisi, la ricerca e l’innovazione.

È fondamentale comprendere che nessuna tecnica, da sola, garantisce la protezione assoluta: l’efficacia dell’anonimizzazione dipende dalla struttura del dataset, dal contesto d’uso e dalla presenza di dati esterni che potrebbero essere incrociati per effettuare attacchi di re-identificazione.

In un’epoca dominata dai big data e dall’intelligenza artificiale, la corretta gestione dei dati personali è un dovere etico oltre che legale. L’anonimizzazione, se ben progettata e valutata, può essere uno strumento potente per abilitare l’innovazione nel rispetto dei diritti fondamentali.

L'articolo Anonimizzazione dei Dati: Proteggere la Privacy senza Perdere Utilità proviene da Red Hot Cyber.

Il ricercatore di sicurezza Alessandro Sgreccia, membro del team HackerHood di Red Hot Cyber, ha segnalato a Zyxel due nuove vulnerabilità che interessano diversi dispositivi della famiglia ZLD (ATP / USG).

Alessandro Sgreccia (Ethical hacker di HackerHood conosciuto per l’emissione di varie CVE, come la RCE nvd.nist.gov/vuln/detail/CVE-2…CVE-2022-0342 da 9.8 su Zyxel), ha attivato una segnalazione responsabile a Zyxel che prontamente ha risposto risolvendo il problema.

Zyxel ha prontamente analizzato i report forniti e ha pubblicato un avviso ufficiale in cui conferma le falle e indica le versioni del firmware interessate e le release con le correzioni disponibili nel suo bollettino di sicurezza.

CVE-2025-9133 – Missing Authorization

Questa vulnerabilità, con un punteggio CVSS v3.1 di 8.1 (High), riguarda un problema di autorizzazione mancante nella gestione di alcune richieste inviate all’interfaccia web dei firewall Zyxel.

In determinate circostanze, un attaccante autenticato con privilegi limitati potrebbe riuscire ad accedere a informazioni sensibili o a funzioni non previste per il proprio livello di accesso.
Il problema è stato classificato anche come CWE-184 (Incomplete List of Disallowed Inputs), in quanto associato a una validazione parziale dei comandi accettati dal sistema.

CVE-2025-8078 – Improper Neutralization of Special Elements used in an OS Command

La seconda vulnerabilità, con punteggio CVSS v3.1 di 7.2 (High), riguarda una command injection individuata in un componente del firmware ZLD.

Un utente autenticato con privilegi elevati potrebbe, in condizioni specifiche, eseguire comandi arbitrari sul dispositivo compromettendo la sicurezza del sistema. Il bug è stato classificato come CWE-78, ossia una neutralizzazione impropria degli elementi speciali utilizzati nei comandi di sistema.

L’advisory ufficiale di Zyxel elenca i modelli e le release interessate e raccomanda l’aggiornamento alle versioni con patch (le informazioni sulle singole release e sulle build corrette sono contenute nell’avviso). Gli amministratori sono invitati a seguire le istruzioni fornite dal vendor. Zyxel

L’apertura di Zyxel alla community hacker

Negli ultimi anni, la cooperazione tra HackerHood e Zyxel è diventata una tappa fondamentale del programma di sicurezza del gruppo. Le segnalazioni effettuate da HackerHood – in particolare tramite il lavoro del ricercatore Alessandro Sgreccia – hanno portato all’attribuzione di 17 CVE nell’arco degli ultimi tre anni sugli apparati Zyxel. Questo risultato testimonia non solo la capacità tecnica del team, ma anche un rapporto di fiducia crescente con il vendor e l’apertura nei suoi confronti alla community hacker che di fatto diventa per i vendor un forte alleato.

Zyxel, da parte sua, ha riconosciuto pubblicamente il contributo di HackerHood e di Sgreccia anche nella propria Hall of Fame dedicata ai segnalatori (inclusa la CVE-2025-1731 / CVE-2025-1732). In sintesi: quella tra Zyxel e HackerHood non è una semplice segnalazione occasionale, ma una dinamica di collaborazione strutturata, che negli ultimi tre anni ha contribuito a rendere i dispositivi Zyxel più robusti contro le minacce.

Raccomandazioni operative

1. Applicare le patch indicate da Zyxel appena possibile.
2. Limitare l’accesso alle interfacce di management (IP ACL, VPN di gestione, accesso da rete di management isolata).
3. Monitorare i log di management e le chiamate all’interfaccia web/CGI per attività anomale.
4. Ruotare credenziali e chiavi qualora si sospetti che un dispositivo possa essere stato esposto.
5. Contattare il vendor o il proprio fornitore di servizi per supporto nelle operazioni di aggiornamento e verifica.

Il ruolo di HackerHood nella scoperta

HackerHood, con circa 20 CVE emesse in tre anni di attività, è il collettivo di ethical hacker di Red Hot Cyber che si impegna nella ricerca di vulnerabilità non documentate per garantire una sicurezza informatica più robusta. Il gruppo si basa su un manifesto che promuove la condivisione della conoscenza e il miglioramento della sicurezza collettiva, identificando e segnalando vulnerabilità critiche per proteggere utenti e aziende.

Secondo quanto riportato nel manifesto di HackerHood, il collettivo valorizza l’etica nella sicurezza informatica e incentiva la collaborazione tra i professionisti del settore. Questo caso dimostra l’importanza della loro missione: mettere al servizio della comunità globale le competenze di hacker etici per individuare minacce ancora sconosciute.

Unisciti a HackerHood

Se sei un bug hunter o un ricercatore di sicurezza e vuoi contribuire a iniziative di questo tipo, HackerHood è sempre aperto a nuovi talenti. Il collettivo accoglie esperti motivati a lavorare su progetti concreti per migliorare la sicurezza informatica globale. Invia un’email con le tue esperienze e competenze a redazione@redhotcyber.com per unirti a questa squadra di professionisti.

La scoperta di queste due nuove CVE sono un ulteriore esempio del contributo di HackerHood al panorama della sicurezza informatica internazionale. È essenziale che aziende e utenti finali prestino attenzione a tali scoperte, adottando le misure necessarie per prevenire eventuali exploit. La collaborazione tra ethical hacker, aziende e comunità resta una pietra miliare nella lotta contro le minacce cibernetiche.

L'articolo HackerHood di RHC Rivela due nuovi 0day sui prodotti Zyxel proviene da Red Hot Cyber.

La direttiva europea NIS2 rappresenta un punto di svolta per la cybersecurity in Italia e in Europa, imponendo a organizzazioni pubbliche e private nuove responsabilità nella gestione dei rischi informatici. Per supportare il percorso di adeguamento in tutte le sue fasi, l’Agenzia per la Cybersicurezza Nazionale (ACN) ha recentemente pubblicato la guida alla lettura delle “Linee guida NIS – Specifiche di base”, un documento che chiarisce gli obblighi per i soggetti NIS essenziali e importanti coinvolti e definisce tempi e modalità di adozione delle misure minime di sicurezza e di notifica degli incidenti.

Il documento rappresenta un valido aiuto per aziende ed enti pubblici per capire come affrontare gli obblighi previsti dal decreto legislativo 138/2024, che ha recepito in Italia la direttiva europea NIS2.

In questo articolo analizzeremo nel dettaglio i due capitoli centrali delle linee guida ACN: da un lato le “Misure di sicurezza di base”, che vanno individuate con un approccio basato sul rischio e dunque calibrate sul contesto di ogni organizzazione; vengono poi passate in rassegna le tipologie di requisiti e le evidenze documentali richieste. Altro aspetto fondamentale riguarda gli “Incidenti significativi di base”, con particolare attenzione sulle tipologie individuate, sui criteri di evidenza e sui rischi legati all’abuso dei privilegi. Al tempo stesso, capiremo il valore di affidarsi a un partner esperto comeELMI per gestire rischi e adempimenti NIS2 in modo efficace e integrato.

Le linee guida NIS2 dell’ACN: misure di sicurezza di base

La prima parte del documento linee guida ACN riguarda le Misure di sicurezza di base, con un focus su:

• struttura delle misure di sicurezza
• approccio basato sul rischio secondo il quale sono state sviluppate le misure
• tipologie di requisiti delle misure
• principali evidenze documentali richieste.

I soggetti NIS devono adottare le misure di sicurezza entro 18 mesi (ottobre 2026) dalla data di ricezione della comunicazione di iscrizione nell’elenco nazionale NIS. Le misure di sicurezza si applicano ai sistemi informativi e di rete che i soggetti utilizzano nelle loro attività o nella fornitura dei loro servizi.

Queste misure, sviluppate in coerenza con il Framework Nazionale per la Cybersecurity, sono organizzate in funzioni, categorie e sottocategorie, ciascuna accompagnata da requisiti specifici. In termini pratici, ogni misura indica cosa deve essere implementato e quali evidenze documentali devono essere fornite a dimostrazione della conformità.

In totale, le linee guida ACN definiscono:

• 37 misure di sicurezza e 87 requisiti per i soggetti importanti;
• 43 misure di sicurezza e 116 requisiti per i soggetti essenziali.

La differenza riflette la maggiore esposizione al rischio e il ruolo critico dei soggetti essenziali;questi, infatti, devono rispettare un numero maggiore di misure e requisiti rispetto ai soggetti importanti, poiché la normativa tiene conto della loro maggiore esposizione ai rischi e del possibile impatto, sociale ed economico, di un possibile incidente.

In questo contesto, il supporto di un partner specializzato come ELMI consente alle organizzazioni di interpretare correttamente i requisiti ACN, tradurli in piani operativi concreti e predisporre la documentazione necessaria, riducendo i rischi di non conformità.

Misure di sicurezza di base: approccio basato sul rischio

Nella definizione delle misure di sicurezza, l’ACN ha applicato quanto previsto dall’articolo 31 della Decreto NIS2: gli obblighi non sono uguali per tutti, ma devono essere calibrati sul grado di esposizione al rischio dei sistemi informativi e di rete.

I requisiti più complessi sono modulati attraverso alcune clausole che ne guidano l’applicazione:

• possono riguardare almeno i sistemi e le reti più rilevanti per l’organizzazione;
• devono essere definiti sulla base della valutazione del rischio (misura ID.RA-05);
• ammettono eccezioni solo in presenza di ragioni normative o tecniche documentate;
• si applicano anche alle forniture che possono avere impatti diretti sulla sicurezza dei sistemi.

Tipologie di requisiti

Per tradurre le misure di sicurezza in azioni concrete, l’ACN definisce i requisiti specifici che i soggetti NIS devono rispettare per essere conformi. Questi requisiti si dividono in due principali categorie:

• Organizzativi: riguardano principalmente la gestione, l’organizzazione, la documentazione e il controllo di processi e attività, come ad esempio l’adozione e l’approvazione di politiche o procedure, la definizione di processi interni e la redazione di documentazione ufficiale. Gran parte dei requisiti delle misure di sicurezza di base rientra in questa categoria, come ad esempio la misura GV.RR-02, che definisce l’organizzazione della sicurezza informatica e i relativi ruoli e responsabilità, o la misura GV.PO-01, relativa all’adozione e documentazione delle politiche di sicurezza.
• Tecnologici: implicano l’adozione di strumenti e soluzioni tecnologiche per garantire la protezione dei sistemi informativi. Tra gli esempi vi sono la cifratura dei dati, l’aggiornamento dei software o l’uso di sistemi di autenticazione multifattore. Alcuni requisiti di tipo tecnologico sono legati, ad esempio, alla misura DE.CM-01, che richiede sistemi di rilevamento delle intrusioni e strumenti per l’analisi e il filtraggio del traffico in ingresso.

Questa distinzione permette di combinare controlli organizzativi e tecnologici, assicurando che le misure di sicurezza non siano solo formalmente adottate, ma realmente efficaci nel prevenire e mitigare i rischi informatici.

Documentazione a supporto delle misure di sicurezza

Per dimostrare l’effettiva implementazione delle misure di sicurezza, i soggetti NIS devono predisporre una serie di documenti chiave, strutturati in base alla propria organizzazione e al contesto operativo. Tra i principali troviamo:

• Elenchi: personale dell’organizzazione di sicurezza informatica, configurazioni di riferimento e sistemi accessibili da remoto.
• Inventari: apparati fisici, servizi, sistemi e applicazioni software, flussi di rete, servizi dei fornitori e relativi fornitori.
• Piani: gestione dei rischi, business continuity e disaster recovery, trattamento dei rischi, gestione delle vulnerabilità, adeguamento e valutazione dell’efficacia delle misure, formazione in materia di sicurezza informatica, risposta agli incidenti.
• Politiche di sicurezza informatica: definite in base ai requisiti previsti negli allegati 1 e 2 della determina 164179/2025, rispettivamente per soggetti importanti ed essenziali.
• Procedure: sviluppate in relazione ai requisiti specifici per cui sono richieste.
• Registri: esiti del riesame delle politiche, attività di formazione del personale, manutenzioni effettuate.

L’organizzazione può decidere come strutturare la documentazione, ad esempio concentrando più contenuti in un unico documento o distribuendoli su più file, purché i documenti siano facilmente accessibili e consultabili da chi ha necessità di verificarli.

ELMI supporta le organizzazioni con unapiattaforma documentale che consente di mappare i requisiti normativi, centralizzare e proteggere la documentazione, tracciare accessi e responsabilità e automatizzare processi approvativi. Inoltre, favorisce la gestione controllata di policy, piani e analisi dei rischi, garantendo aggiornamenti continui e supportando la formazione del personale.

Così, le aziende non solo rispettano gli obblighi della NIS2, ma trasformano la compliance in un processo semplice, sicuro e facilmente auditabile.

Gli Incidenti significativi di base

Le linee guida ACN definiscono anche le tipologie di incidenti significativi di base, ossia quegli eventi che possono avere un impatto rilevante sulla sicurezza dei dati o sulla continuità dei servizi dei soggetti NIS. Gli incidenti sono differenziati in base alla tipologia di soggetto: per i soggetti importanti sono stati identificati tre principali incidenti, mentre per i soggetti essenziali ve ne sono quattro, con l’aggiunta di un evento specifico legato all’abuso dei privilegi concessi.

In dettaglio, le principali tipologie di incidenti significativi di base sono:

• IS-1: perdita di riservatezza di dati digitali di proprietà del soggetto o sotto il suo controllo;
• IS-2: perdita di integrità dei dati, con impatto verso l’esterno;
• IS-3: violazione dei livelli di servizio attesi dei servizi o delle attività del soggetto;
• IS-4 (solo soggetti essenziali): accesso non autorizzato o abuso dei privilegi concessi su dati digitali, anche parziale.Si parla di abuso dei privilegi quando l’accesso è effettuato in violazione delle politiche interne dell’organizzazione o per finalità estranee alle necessità funzionali.

L’evidenza dell’incidente è il punto di partenza per l’adempimento degli obblighi di notifica: si considera incidente significativo solo quando il soggetto dispone di elementi oggettivi che confermano che l’evento si è effettivamente verificato. È proprio dal momento in cui l’evidenza viene acquisita che decorrono i termini per la pre-notifica (24 ore) e la notifica ufficiale (72 ore) al CSIRT Italia.

L’evidenza può essere raccolta attraverso diverse fonti, tra cui:

• Segnalazioni esterne, ad esempio comunicazioni ricevute dal CSIRT Italia;
• Segnalazioni interne, come richieste di supporto o malfunzionamenti riportati dagli utenti all’help desk;
• Eventi rilevati dai sistemi di monitoraggio, quali log di sicurezza, alert o sistemi di rilevamento intrusioni.

In pratica, avere evidenza significa poter dimostrare con dati concreti che l’incidente si è verificato, rendendo possibile una risposta tempestiva e la corretta gestione degli adempimenti normativi.

Per molte organizzazioni, l’elemento critico non è solo individuazione dell’incidente, ma disporre di un presidio costante capace di monitorare e bloccare le minacce informatiche in real-time. In quest’ottica, ilSecurity Competence Center di ELMI fornisce un monitoraggio H24 e grazie a strumenti avanzati di Threat Hunting e Incident Response, permette di ridurre drasticamente il tempo necessario per confermare un evento e avviare la notifica secondo le linee guida NIS2.

Direttiva NIS2: obblighi e scadenze per le aziende

Chi rientra nell’elenco dei soggetti NIS deve rispettare precise deadline, senza margini di rinvio. I soggetti NIS devono organizzare gli adempimenti in modo proattivo e tempestivo per garantire la conformità alla NIS2 e ridurre i rischi informatici.

Il percorso normativo prevede una serie di tappe fondamentali:

• entro gennaio 2026 i soggetti dovranno adempiere agli obblighi di base in materia di notifica di incidente;
• entro aprile 2026 sarà l’ACN a definire e adottare il modello di categorizzazione delle attività e dei servizi, nonché a predisporre gli obblighi a lungo termine;
• entro settembre 2026, è richiesto ai soggetti l’implementazione delle misure di sicurezza di base e la categorizzazione delle proprie attività e servizi;
• dopo ottobre 2026, scatterà l’obbligo per i soggetti di dare piena attuazione agli adempimenti a lungo termine.

Parallelamente a questo calendario, le principali attività da pianificare includono:

• Implementazione delle misure di sicurezza di base, calibrate sul rischio specifico dei sistemi e delle reti;
• Predisposizione della documentazione chiave, come elenchi, inventari, piani, politiche, procedure e registri;
• Monitoraggio e gestione degli incidenti significativi, con particolare attenzione all’acquisizione dell’evidenza e alle notifiche.

Per affrontare con efficacia queste scadenze, è consigliabile definire piani operativi chiari, assegnare responsabilità specifiche, attivare sistemi di monitoraggio continuo e integrare la compliance con la formazione del personale. In questo modo, le organizzazioni non solo rispettano la normativa, ma rafforzano la resilienza digitale e riducono l’impatto di eventuali incidenti.

ELMI accompagna i soggetti NIS in questa fase cruciale, supportandoli nella pianificazione degli adempimenti e nella predisposizione della documentazione richiesta. Attraverso assessment mirati e roadmap di compliance, l’azienda consente di rispettare le scadenze fissate dalla direttiva NIS2 senza frammentare i processi interni, garantendo al contempo continuità operativa e robustezza delle difese.

Come ELMI supporta le organizzazioni nella compliance NIS2

Affidarsi a un partner altamente qualificato come ELMI significa percorrere un percorso strutturato versol’adeguamento alla Direttiva NIS2, con soluzioni personalizzate, integrate e scalabili, progettate per ogni fase del processo di compliance. Grazie a una consolidata expertise in cybersecurity e consulenza, ELMI supporta le organizzazioni nell’implementazione delle misure di sicurezza, nella gestione degli incidenti e nella documentazione richiesta dalla normativa.

Assessment e analisi del perimetro NIS2

ELMI accompagna le aziende con un assessment strutturato, volto a valutare l’ambito di applicazione della direttiva: analisi dei servizi erogati, delle infrastrutture IT e dei vincoli normativi, identificazione dei ruoli e delle responsabilità in ambito cybersecurity, e valutazione del livello di sicurezza attuale.

Successivamente, viene condotta una Gap Analysis per identificare le aree di non conformità e le opportunità di miglioramento, valutando rischi, vulnerabilità e impatto operativo di eventuali incidenti. Su questa base viene definito un piano di intervento, che include contromisure tecniche e procedurali per rafforzare la sicurezza e garantire la conformità agli obblighi normativi.

Gestione proattiva degli eventi

IlSecurity Competence Center è il centro operativo di ELMI progettato per affrontare le sfide di cyber sicurezza con un approccio integrato e proattivo. Il Security Operation Center (SOC) e il Network Operation Center (NOC), garantiscono la protezione delle informazioni critiche, la conformità normativa, il monitoraggio continuo e la resilienza delle infrastrutture informatiche. In particolare:

• Il Security Operation Center (SOC), è il centro operativo dotato di una control room dedicata al monitoraggio continuo, al triage e alla gestione degli eventi di sicurezza H24/7 che possono impattare l’infrastruttura aziendale.
• Il Network Operation Center (NOC), è focalizzato sulla gestione e sul monitoraggio delle reti, per garantirne efficienza, disponibilità e resilienza.

Insieme, SOC e NOC rappresentano il cuore operativo per la protezione degli asset critici e la gestione degli incidenti.

Attraverso un servizio H24 e strumenti avanzati di threat intelligence e sistemi di allerta precoce, ELMI assicura una gestione completa degli incidenti, riducendo il time to detect e il time to respond, garantendo un controllo costante su reti, sistemi e applicazioni critiche, in linea con le prescrizioni della Direttiva NIS2.

Formazione e supporto normativo continuo

La compliance NIS2 non si esaurisce con l’implementazione tecnica e procedurale. ELMI affianca le organizzazioni con percorsi formativi mirati, orientati alla gestione degli incidenti, alla governance della sicurezza e alla diffusione della cultura cybersecurity a tutti i livelli aziendali.

Parallelamente, ELMI offre supporto normativo costante, con aggiornamenti su nuove disposizioni e linee guida, revisione periodica di policy e procedure e assistenza nell’interpretazione tecnica dei requisiti, assicurando un approccio sostenibile e integrato alla conformità NIS2.

La Direttiva europea NIS2 e le linee guida ACN stabiliscono uno standard chiaro per la gestione dei rischi informatici, dalle misure di sicurezza di base alla corretta gestione degli incidenti significativi. Per le organizzazioni, rispettare questi requisiti significa adottare un approccio risk-based, con controlli organizzativi e tecnologici integrati, monitoraggio costante e procedure documentate.

Affidarsi a un partner come ELMI e al suo team di specialisti certificati consente di trasformare la compliance NIS2 in un vero vantaggio competitivo. Grazie a servizi su misura di cybersecurity e programmi di formazione e supporto normativo, le aziende possono garantire robustezza dei sistemi informativi, tracciabilità degli eventi, riduzione del time to detect e del time to respond, e piena conformità agli obblighi di notifica.

L'articolo NIS2 e nuove linee guida ACN: cosa cambia per le aziende e come prepararsi proviene da Red Hot Cyber.

Un team di ricercatori di Hong Kong ha reso pubblico un sistema denominato Lancelot, che rappresenta la prima realizzazione pratica di apprendimento federato, risultando al contempo protetto da attacchi di manomissione dei dati e da violazioni della riservatezza.

L’apprendimento federato consente a più partecipanti (client) di addestrare congiuntamente un modello senza rivelare i dati di origine. Questo approccio è particolarmente importante in medicina e finanza, dove le informazioni personali sono strettamente regolamentate.

Tuttavia, questi sistemi sono vulnerabili al data poisoning : un aggressore può caricare aggiornamenti falsi e distorcere i risultati. I metodi di apprendimento federato hanno parzialmente risolto questo problema scartando gli aggiornamenti sospetti, ma non hanno protetto dal possibile recupero di dati crittografati dalla memoria della rete neurale.

Il team ha deciso di combinare sicurezza crittografica e resistenza agli attacchi. Lancelot utilizza la crittografia completamente omomorfica per garantire che tutti gli aggiornamenti del modello locale rimangano crittografati end-to-end.

Il sistema seleziona inoltre gli aggiornamenti client attendibili senza rivelare chi è attendibile. Ciò è possibile grazie a uno speciale meccanismo di “ordinamento mascherato”: un centro chiavi attendibile riceve i dati crittografati, ordina i client in base al livello di attendibilità e restituisce al server solo un elenco crittografato, oscurando i partecipanti alla formazione. In questo modo, il server aggrega solo i dati verificati senza rivelarne l’origine.

Per velocizzare i calcoli, gli sviluppatori hanno implementato due tecniche di ottimizzazione. La “rilinearizzazione lazy” posticipa i costosi passaggi crittografici alla fase finale, riducendo il carico sulla CPU. Il metodo “Dynamic hoisting” raggruppa le operazioni ripetitive e le esegue in parallelo, anche sulle GPU, riducendo significativamente i tempi di addestramento complessivi.

Il risultato è una soluzione che affronta due vulnerabilità dell’apprendimento federato: è resiliente agli attacchi di malintenzionati e al contempo garantisce la completa riservatezza dei dati. I test hanno dimostrato che Lancelot non solo previene fughe di dati e sabotaggi, ma riduce anche significativamente i tempi di addestramento dei modelli ottimizzando le operazioni crittografiche e sfruttando le GPU.

I ricercatori intendono espandere l’architettura Lancelot, rendendola adatta a scenari su larga scala. Le potenziali applicazioni includono l’addestramento di sistemi di intelligenza artificiale in ospedali, banche e altre organizzazioni che gestiscono dati sensibili. Il team sta attualmente testando nuove versioni con supporto per chiavi distribuite (CKKS a soglia e multi-chiave), integrazione di metodi di privacy differenziale e aggregazione asincrona, che consentiranno al sistema di funzionare in modo affidabile anche con connessioni di rete instabili e un’ampia varietà di dispositivi client.

L'articolo Lancelot: il sistema di apprendimento AI federato e sicuro proviene da Red Hot Cyber.