IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and I have many feelings about Sora, OpenAI's new AI-generated social media platform. Many of which are encapsulated by this video by Casey Neistat. #FreeTheSlop.

— The world's largest platforms have failed to respond to the highest level of global conflict since World War II.

— The semiconductor wars between China and the United States are creating a massive barrier between the world's two largest economies.

— China's DeepSeek performs significantly worse than its US counterparts on a series of benchmark tests.

Let's get started:

digitalpolitics.co/newsletter0…

DLL hijacking is a common technique in which attackers replace a library called by a legitimate process with a malicious one. It is used by both creators of mass-impact malware, like stealers and banking Trojans, and by APT and cybercrime groups behind targeted attacks. In recent years, the number of DLL hijacking attacks has grown significantly.

Trend in the number of DLL hijacking attacks. 2023 data is taken as 100% (download)

We have observed this technique and its variations, like DLL sideloading, in targeted attacks on organizations in Russia, Africa, South Korea, and other countries and regions. Lumma, one of 2025’s most active stealers, uses this method for distribution. Threat actors trying to profit from popular applications, such as DeepSeek, also resort to DLL hijacking.

Detecting a DLL substitution attack is not easy because the library executes within the trusted address space of a legitimate process. So, to a security solution, this activity may look like a trusted process. Directing excessive attention to trusted processes can compromise overall system performance, so you have to strike a delicate balance between a sufficient level of security and sufficient convenience.

Detecting DLL hijacking with a machine-learning model

Artificial intelligence can help where simple detection algorithms fall short. Kaspersky has been using machine learning for 20 years to identify malicious activity at various stages. The AI expertise center researches the capabilities of different models in threat detection, then trains and implements them. Our colleagues at the threat intelligence center approached us with a question of whether machine learning could be used to detect DLL hijacking, and more importantly, whether it would help improve detection accuracy.

Preparation

To determine if we could train a model to distinguish between malicious and legitimate library loads, we first needed to define a set of features highly indicative of DLL hijacking. We identified the following key features:

• Wrong library location. Many standard libraries reside in standard directories, while a malicious DLL is often found in an unusual location, such as the same folder as the executable that calls it.
• Wrong executable location. Attackers often save executables in non-standard paths, like temporary directories or user folders, instead of %Program Files%.
• Renamed executable. To avoid detection, attackers frequently save legitimate applications under arbitrary names.
• Library size has changed, and it is no longer signed.
• Modified library structure.

Training sample and labeling

For the training sample, we used dynamic library load data provided by our internal automatic processing systems, which handle millions of files every day, and anonymized telemetry, such as that voluntarily provided by Kaspersky users through Kaspersky Security Network.

The training sample was labeled in three iterations. Initially, we could not automatically pull event labeling from our analysts that indicated whether an event was a DLL hijacking attack. So, we used data from our databases containing only file reputation, and labeled the rest of the data manually. We labeled as DLL hijacking those library-call events where the process was definitively legitimate but the DLL was definitively malicious. However, this labeling was not enough because some processes, like “svchost”, are designed mainly to load various libraries. As a result, the model we trained on this data had a high rate of false positives and was not practical for real-world use.

In the next iteration, we additionally filtered malicious libraries by family, keeping only those which were known to exhibit DLL-hijacking behavior. The model trained on this refined data showed significantly better accuracy and essentially confirmed our hypothesis that we could use machine learning to detect this type of attacks.

At this stage, our training dataset had tens of millions of objects. This included about 20 million clean files and around 50,000 definitively malicious ones.

We then trained subsequent models on the results of their predecessors, which had been verified and further labeled by analysts. This process significantly increased the efficiency of our training.

Loading DLLs: what does normal look like?

So, we had a labeled sample with a large number of library loading events from various processes. How can we describe a “clean” library? Using a process name + library name combination does not account for renamed processes. Besides, a legitimate user, not just an attacker, can rename a process. If we used the process hash instead of the name, we would solve the renaming problem, but then every version of the same library would be treated as a separate library. We ultimately settled on using a library name + process signature combination. While this approach considers all identically named libraries from a single vendor as one, it generally produces a more or less realistic picture.

To describe safe library loading events, we used a set of counters that included information about the processes (the frequency of a specific process name for a file with a given hash, the frequency of a specific file path for a file with that hash, and so on), information about the libraries (the frequency of a specific path for that library, the percentage of legitimate launches, and so on), and event properties (that is, whether the library is in the same directory as the file that calls it).

The result was a system with multiple aggregates (sets of counters and keys) that could describe an input event. These aggregates can contain a single key (e.g., a DLL’s hash sum) or multiple keys (e.g., a process’s hash sum + process signature). Based on these aggregates, we can derive a set of features that describe the library loading event. The diagram below provides examples of how these features are derived:

Feature extraction from aggregates

Loading DLLs: how to describe hijacking

Certain feature combinations (dependencies) strongly indicate DLL hijacking. These can be simple dependencies. For some processes, the clean library they call always resides in a separate folder, while the malicious one is most often placed in the process folder.

Other dependencies can be more complex and require several conditions to be met. For example, a process renaming itself does not, on its own, indicate DLL hijacking. However, if the new name appears in the data stream for the first time, and the library is located on a non-standard path, it is highly likely to be malicious.

Model evolution

Within this project, we trained several generations of models. The primary goal of the first generation was to show that machine learning could at all be applied to detecting DLL hijacking. When training this model, we used the broadest possible interpretation of the term.

The model’s workflow was as simple as possible:

1. We took a data stream and extracted a frequency description for selected sets of keys.
2. We took the same data stream from a different time period and obtained a set of features.
3. We used type 1 labeling, where events in which a legitimate process loaded a malicious library from a specified set of families were marked as DLL hijacking.
4. We trained the model on the resulting data.

First-generation model diagram

The second-generation model was trained on data that had been processed by the first-generation model and verified by analysts (labeling type 2). Consequently, the labeling was more precise than during the training of the first model. Additionally, we added more features to describe the library structure and slightly complicated the workflow for describing library loads.

Second-generation model diagram

Based on the results from this second-generation model, we were able to identify several common types of false positives. For example, the training sample included potentially unwanted applications. These can, in certain contexts, exhibit behavior similar to DLL hijacking, but they are not malicious and rarely belong to this attack type.

We fixed these errors in the third-generation model. First, with the help of analysts, we flagged the potentially unwanted applications in the training sample so the model would not detect them. Second, in this new version, we used an expanded labeling that included useful detections from both the first and second generations. Additionally, we expanded the feature description through one-hot encoding — a technique for converting categorical features into a binary format — for certain fields. Also, since the volume of events processed by the model increased over time, this version added normalization of all features based on the data flow size.

Third-generation model diagram

Comparison of the models

To evaluate the evolution of our models, we applied them to a test data set none of them had worked with before. The graph below shows the ratio of true positive to false positive verdicts for each model.

Trends in true positives and false positives from the first-, second-, and third-generation models

As the models evolved, the percentage of true positives grew. While the first-generation model achieved a relatively good result (0.6 or higher) only with a very high false positive rate (10^⁻³ or more), the second-generation model reached this at 10^⁻⁵. The third-generation model, at the same low false positive rate, produced 0.8 true positives, which is considered a good result.

Evaluating the models on the data stream at a fixed score shows that the absolute number of new events labeled as DLL Hijacking increased from one generation to the next. That said, evaluating the models by their false verdict rate also helps track progress: the first model has a fairly high error rate, while the second and third generations have significantly lower ones.

False positives rate among model outputs, July 2024 – August 2025 (download)

Practical application of the models

All three model generations are used in our internal systems to detect likely cases of DLL hijacking within telemetry data streams. We receive 6.5 million security events daily, linked to 800,000 unique files. Aggregates are built from this sample at a specified interval, enriched, and then fed into the models. The output data is then ranked by model and by the probability of DLL hijacking assigned to the event, and then sent to our analysts. For instance, if the third-generation model flags an event as DLL hijacking with high confidence, it should be investigated first, whereas a less definitive verdict from the first-generation model can be checked last.

Simultaneously, the models are tested on a separate data stream they have not seen before. This is done to assess their effectiveness over time, as a model’s detection performance can degrade. The graph below shows that the percentage of correct detections varies slightly over time, but on average, the models detect 70–80% of DLL hijacking cases.

DLL hijacking detection trends for all three models, October 2024 – September 2025 (download)

Additionally, we recently deployed a DLL hijacking detection model into the Kaspersky SIEM, but first we tested the model in the Kaspersky MDR service. During the pilot phase, the model helped to detect and prevent a number of DLL hijacking incidents in our clients’ systems. We have written a separate article about how the machine learning model for detecting targeted attacks involving DLL hijacking works in Kaspersky SIEM and the incidents it has identified.

Conclusion

Based on the training and application of the three generations of models, the experiment to detect DLL hijacking using machine learning was a success. We were able to develop a model that distinguishes events resembling DLL hijacking from other events, and refined it to a state suitable for practical use, not only in our internal systems but also in commercial products. Currently, the models operate in the cloud, scanning hundreds of thousands of unique files per month and detecting thousands of files used in DLL hijacking attacks each month. They regularly identify previously unknown variations of these attacks. The results from the models are sent to analysts who verify them and create new detection rules based on their findings.

securelist.com/building-ml-mod…

Introduction

Our colleagues from the AI expertise center recently developed a machine-learning model that detects DLL-hijacking attacks. We then integrated this model into the Kaspersky Unified Monitoring and Analysis Platform SIEM system. In a separate article, our colleagues shared how the model had been created and what success they had achieved in lab environments. Here, we focus on how it operates within Kaspersky SIEM, the preparation steps taken before its release, and some real-world incidents it has already helped us uncover.

How the model works in Kaspersky SIEM

The model’s operation generally boils down to a step-by-step check of all DLL libraries loaded by processes in the system, followed by validation in the Kaspersky Security Network (KSN) cloud. This approach allows local attributes (path, process name, and file hashes) to be combined with a global knowledge base and behavioral indicators, which significantly improves detection quality and reduces the probability of false positives.

The model can run in one of two modes: on a correlator or on a collector. A correlator is a SIEM component that performs event analysis and correlation based on predefined rules or algorithms. If detection is configured on a correlator, the model checks events that have already triggered a rule. This reduces the volume of KSN queries and the model’s response time.

This is how it looks:

A collector is a software or hardware component of a SIEM platform that collects and normalizes events from various sources, and then delivers these events to the platform’s core. If detection is configured on a collector, the model processes all events associated with various processes loading libraries, provided these events meet the following conditions:

• The path to the process file is known.
• The path to the library is known.
• The hashes of the file and the library are available.

This method consumes more resources, and the model’s response takes longer than it does on a correlator. However, it can be useful for retrospective threat hunting because it allows you to check all events logged by Kaspersky SIEM. The model’s workflow on a collector looks like this:

It is important to note that the model is not limited to a binary “malicious/non-malicious” assessment; it ranks its responses by confidence level. This allows it to be used as a flexible tool in SOC practice. Examples of possible verdicts:

• 0: data is being processed.
• 1: maliciousness not confirmed. This means the model currently does not consider the library malicious.
• 2: suspicious library.
• 3: maliciousness confirmed.

A Kaspersky SIEM rule for detecting DLL hijacking would look like this:
N.KL_AI_DLLHijackingCheckResult > 1
Embedding the model into the Kaspersky SIEM correlator automates the process of finding DLL-hijacking attacks, making it possible to detect them at scale without having to manually analyze hundreds or thousands of loaded libraries. Furthermore, when combined with correlation rules and telemetry sources, the model can be used not just as a standalone module but as part of a comprehensive defense against infrastructure attacks.

Incidents detected during the pilot testing of the model in the MDR service

Before being released, the model (as part of the Kaspersky SIEM platform) was tested in the MDR service, where it was trained to identify attacks on large datasets supplied by our telemetry. This step was necessary to ensure that detection works not only in lab settings but also in real client infrastructures.

During the pilot testing, we verified the model’s resilience to false positives and its ability to correctly classify behavior even in non-typical DLL-loading scenarios. As a result, several real-world incidents were successfully detected where attackers used one type of DLL hijacking — the DLL Sideloading technique — to gain persistence and execute their code in the system.

Let us take a closer look at the three most interesting of these.

Incident 1. ToddyCat trying to launch Cobalt Strike disguised as a system library

In one incident, the attackers successfully leveraged the vulnerability CVE-2021-27076 to exploit a SharePoint service that used IIS as a web server. They ran the following command:
c:\windows\system32\inetsrv\w3wp.exe -ap "SharePoint - 80" -v "v4.0" -l "webengine4.dll" -a \\.\pipe\iisipmd32ded38-e45b-423f-804d-34471928538b -h "C:\inetpub\temp\apppools\SharePoint - 80\SharePoint - 80.config" -w "" -m 0
After the exploitation, the IIS process created files that were later used to run malicious code via the DLL sideloading technique (T1574.001 Hijack Execution Flow: DLL):
C:\ProgramData\SystemSettings.exe
C:\ProgramData\SystemSettings.dll
SystemSettings.dll is the name of a library associated with the Windows Settings application (SystemSettings.exe). The original library contains code and data that the Settings application uses to manage and configure various system parameters. However, the library created by the attackers has malicious functionality and is only pretending to be a system library.

Later, to establish persistence in the system and launch a DLL sideloading attack, a scheduled task was created, disguised as a Microsoft Edge browser update. It launches a SystemSettings.exe file, which is located in the same directory as the malicious library:
Schtasks /create /ru "SYSTEM" /tn "\Microsoft\Windows\Edge\Edgeupdates" /sc DAILY /tr "C:\ProgramData\SystemSettings.exe" /F
The task is set to run daily.

When the SystemSettings.exe process is launched, it loads the malicious DLL. As this happened, the process and library data were sent to our model for analysis and detection of a potential attack.

Example of a SystemSettings.dll load event with a DLL Hijacking module verdict in Kaspersky SIEM

The resulting data helped our analysts highlight a suspicious DLL and analyze it in detail. The library was found to be a Cobalt Strike implant. After loading it, the SystemSettings.exe process attempted to connect to the attackers’ command-and-control server.
DNS query: connect-microsoft[.]com
DNS query type: AAAA
DNS response: ::ffff:8.219.1[.]155;
8.219.1[.]155:8443
After establishing a connection, the attackers began host reconnaissance to gather various data to develop their attack.
C:\ProgramData\SystemSettings.exe
whoami /priv
hostname
reg query HKLM\SOFTWARE\Microsoft\Cryptography /v MachineGuid
powershell -c $psversiontable
dotnet --version
systeminfo
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Drivers"
cmdkey /list
REG query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
reg query "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
netsh wlan show profiles
netsh wlan show interfaces
set
net localgroup administrators
net user
net user administrator
ipconfig /all
net config workstation
net view
arp -a
route print
netstat -ano
tasklist
schtasks /query /fo LIST /v
net start
net share
net use
netsh firewall show config
netsh firewall show state
net view /domain
net time /domain
net group "domain admins" /domain
net localgroup administrators /domain
net group "domain controllers" /domain
net accounts /domain
nltest / domain_trusts
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
reg query HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
reg query HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
reg query HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
reg query HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
Based on the attackers’ TTPs, such as loading Cobalt Strike as a DLL, using the DLL sideloading technique (1, 2), and exploiting SharePoint, we can say with a high degree of confidence that the ToddyCat APT group was behind the attack. Thanks to the prompt response of our model, we were able to respond in time and block this activity, preventing the attackers from causing damage to the organization.

Incident 2. Infostealer masquerading as a policy manager

Another example was discovered by the model after a client was connected to MDR monitoring: a legitimate system file located in an application folder attempted to load a suspicious library that was stored next to it.
C:\Program Files\Chiniks\SettingSyncHost.exe
C:\Program Files\Chiniks\policymanager.dll E83F331BD1EC115524EBFF7043795BBE
The SettingSyncHost.exe file is a system host process for synchronizing settings between one user’s different devices. Its 32-bit and 64-bit versions are usually located in C:\Windows\System32\ and C:\Windows\SysWOW64\, respectively. In this incident, the file location differed from the normal one.

Example of a policymanager.dll load event with a DLL Hijacking module verdict in Kaspersky SIEM

Analysis of the library file loaded by this process showed that it was malware designed to steal information from browsers.

Graph of policymanager.dll activity in a sandbox

The file directly accesses browser files that contain user data.
C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Local State
The library file is on the list of files used for DLL hijacking, as published in the HijackLibs project. The project contains a list of common processes and libraries employed in DLL-hijacking attacks, which can be used to detect these attacks.

Incident 3. Malicious loader posing as a security solution

Another incident discovered by our model occurred when a user connected a removable USB drive:

Example of a Kaspersky SIEM event where a wsc.dll library was loaded from a USB drive, with a DLL Hijacking module verdict

The connected drive’s directory contained hidden folders with an identically named shortcut for each of them. The shortcuts had icons typically used for folders. Since file extensions were not shown by default on the drive, the user might have mistaken the shortcut for a folder and launched it. In turn, the shortcut opened the corresponding hidden folder and ran an executable file using the following command:
"%comspec%" /q /c "RECYCLER.BIN\1\CEFHelper.exe [$DIGITS] [$DIGITS]"
CEFHelper.exe is a legitimate Avast Antivirus executable that, through DLL sideloading, loaded the wsc.dll library, which is a malicious loader.

Code snippet from the malicious file

The loader opens a file named AvastAuth.dat, which contains an encrypted backdoor. The library reads the data from the file into memory, decrypts it, and executes it. After this, the backdoor attempts to connect to a remote command-and-control server.

The library file, which contains the malicious loader, is on the list of known libraries used for DLL sideloading, as presented on the HijackLibs project website.

Conclusion

Integrating the model into the product provided the means of early and accurate detection of DLL-hijacking attempts which previously might have gone unnoticed. Even during the pilot testing, the model proved its effectiveness by identifying several incidents using this technique. Going forward, its accuracy will only increase as data accumulates and algorithms are updated in KSN, making this mechanism a reliable element of proactive protection for corporate systems.

IoC

Legitimate files used for DLL hijacking
E0E092D4EFC15F25FD9C0923C52C33D6 loads SystemSettings.dll
09CD396C8F4B4989A83ED7A1F33F5503 loads policymanager.dll
A72036F635CECF0DCB1E9C6F49A8FA5B loads wsc.dll

Malicious files
EA2882B05F8C11A285426F90859F23C6 SystemSettings.dll
E83F331BD1EC115524EBFF7043795BBE policymanager.dll
831252E7FA9BD6FA174715647EBCE516 wsc.dll

Paths
C:\ProgramData\SystemSettings.exe
C:\ProgramData\SystemSettings.dll
C:\Program Files\Chiniks\SettingSyncHost.exe
C:\Program Files\Chiniks\policymanager.dll
D:\RECYCLER.BIN\1\CEFHelper.exe
D:\RECYCLER.BIN\1\wsc.dll

securelist.com/detecting-dll-h…

Airbags are an incredibly important piece of automotive safety gear. They’re also terrifying—given that they’re effectively small pyrotechnic devices that are aimed directly at your face and chest. Myths have pervaded that they “kill more people than they save,” in part due a hilarious episode of The Simpsons. Despite this, they’re credited with saving tens of thousands of lives over the years by cushioning fleshy human bodies from heavy impacts and harsh decelerations.

While an airbag is generally there to help you, it can also hurt you in regular operation. The immense sound pressure generated when an airbag fires is not exactly friendly to your ears. However, engineers at Mercedes-Benz have found a neat workaround to protect your hearing from the explosive report of these safety devices. It’s a nifty hack that takes advantage of an existing feature of the human body. Let’s explore how air bags work, why they’re so darn loud, and how that can be mitigated in the event of a crash.

A Lot Of Hot Air

The first patent for an airbag safety device was filed over 100 years ago, intended for use in aircraft. Credit: US Patent Office
Once an obscure feature only found in luxury vehicles, airbags became common safety equipment in many cars and trucks by the mid-1990s. Indeed, a particular turning point was when they became mandatory in vehicles sold in the US market from late 1998 onwards, which made them near-universal equipment in many other markets worldwide. Despite their relatively recent mainstream acceptance, the concept of the airbag actually dates back a lot farther.

The basic invention of the airbag is typically credited to two English dentists—Harold Round and Arthur Parrott—who submitted a patent for the concept all the way back in 1919. The patent regarded the concept of creating an air cushion to protect occupants in aircraft during serious impacts. Specific attention was given to the fact that the air cushion should “yield readily without developing the power to rebound,” which could cause further injury. This was achieved by giving the device air outlet passages that would vent as a person impacted the device, which would allow the cushion to absorb the hit gently while reducing the chance of injury.

The concept only later became applicable to automobiles when Walter Linderer filed for a German patent in 1951, and John W. Hetrick filed for a US patent in 1952. Both engineers devised airbags that were based on the release of compressed air, triggered either by human intervention or automated mechanical means. These concepts proved ultimately infeasible, as compressed air could not be feasibly be released to inflate an airbag quickly enough to be protective in an automobile crash.

It would only be later in the 1960s that workable versions using explosive or pyrotechnic inflation came to the fore. The concept was simple—use a chemical reaction to generate a great deal of gas near-instantaneously, inflating the airbag fractions of a second before vehicle occupants come into contact with the device. The airbags are fitted with vents that only allow the gas to escape slowly. This means that as a person hits the airbag, they are gently decelerated as their impact pushes the gas out of the restrictive vents. This helps reduce injuries that would typically be incurred if the occupants instead hit interior parts of the car without any protection at all.
In a crash, it’s much nicer to faceplant into an air-filled pillow than a hard, unforgiving dashboard. Credit: DaimlerChrysler AG, CC BY SA 3.0

The Big Bang

The use of pyrotechnic gas generators to inflate airbags was the leap forward that made airbags practical and effective for use in automobiles. However, as you might imagine, releasing a massive burst of gas in under 50 milliseconds does create a rather large pressure wave—which we experience as an incredibly loud sound. If you ever seen airbags detonated outside of a vehicle, you’ve probably noticed they sound rather akin to fireworks or a gun going off. Indeed, the sound of an airbag can exceed 160 decibels (dB)—more than enough to cause instant damage to the ear. Noise generated in a vehicle impact is often incredibly loud, too, or course. Ultimately, this isn’t great for the occupants of the vehicle, particularly their hearing. Ultimately, an airbag deployment is a carefully considered trade-off—the general consensus is that impact protection in a serious crash is preferable, even if your ears are worse for wear afterwards.

However, there is atechnique that can mitigate this problem. In particular, Mercedes-Benz developed a system to protect the hearing of vehicle occupants in the event that the airbags are fired. The trick is in using the body’s own reactions to sound to reduce damage to the ear from excessive sound pressure levels.
In humans, the stapedius muscle can be triggered reflexively to protect the ear from excess sound levels, though the mechanism is slow enough that it can’t respond well to sudden loud impulses. However, pre-emptively triggering it before a loud event can be very useful. Credit: Mercedes Benz
The stapedius reflex (also known as the acoustic reflex) is one of the body’s involuntary, instantaneous movements in response to an external stimulus—in this case, certain sound levels. When a given sound stimulus occurs to either ear, muscles inside both ears contract, most specifically the stapedius muscle in humans. When the muscle contracts, it has a stiffening effect on the ossicular chain—the three tiny bones that connect the ear drum to the cochlea in the inner ear. Under this condition, less vibrational energy is transferred, reducing damage to the cochlea from excessive sound levels.

The threshold at which the reflex is triggered is usually 10 to 20 dB lower than the point at which the individual feels discomfort; typical levels are from around 70 to 100 dB. When triggered by particularly loud sounds of 20 dB above the trigger threshold, the muscle contraction is enough to reduce the sound level at the cochlea by a full 15 dB. Notably, the reflex is also triggered by vocalization—reducing transmission through to the inner ear when one begins to speak.

Mercedes-Benz engineers realized that the stapedius reflex could be pre-emptively triggered ahead of firing the airbags, in order to provide a protective effect for the ears. To this end, the company developed the PRE-SAFE Sound system. When the vehicle’s airbag control unit detects a collision, it triggers the vehicle’s sound system to play a short-duration pink noise signal at a level of 80 dB. This is intended to be loud enough to trigger the stapedius reflex without in itself doing damage to the ears. Typically, it takes higher sound levels closer to 100 dB to reliably trigger the reflex in a wide range of people, but Mercedes-Benz engineers realized that the wide-spread frequency content of pink noise enable the reflex to be switched on at a much lower, and safer, sound level. With the reflex turned on, when the airbags do fire a fraction of a second later, less energy from the intense pressure spike will be transferred to the inner ear, protecting the delicate structures that provide the sense of hearing.

youtube.com/embed/vTmLYY-Z2rc?…

Mercedes-Benz first released the technology in production models almost a decade ago.

The stapedius reflex does have some limitations. It can be triggered with a latency of just 10 milliseconds, however, it can take up to 100 milliseconds for the muscle in the ear to reach full tension, conferring the full protective effect. This limits the ability of the reflex to protect against short, intense noises. However, given the Mercedes-Benz system triggers the sound before airbag inflation where possible, this helps the muscles engage prior to the peak sound level being reached. The protective effect of the stapedius reflex also only lasts for a few seconds, with the muscle contraction unable to be maintained beyond this point. However, in a vehicle impact scenario, the airbags typically all fire very quickly, usually well within a second, negating this issue.

Mercedes-Benz was working on the technology from at least the early 2010s, having run human trials to trigger the stapedius reflex with pink noise in 2011. It deployed the technology on its production vehicles almost a decade ago, first offering PRE-SAFE Sound on E-Class models for the 2017 model year. Despite the simple nature of the technology, few to no other automakers have publicly reported implementing the technique.

Car crashes are, thankfully, rather rare. Few of us are actually in an automobile accident in any given year, even less in ones serious enough to cause an airbag deployment. However, if you are unlucky enough to be in a severe collision, and you’re riding in a modern Mercedes-Benz, your ears will likely thank you for the added protection, just as your body will be grateful for the cushioning of the airbags themselves.

hackaday.com/2025/10/06/how-me…

We’ve covered plenty of interesting human input devices over the years, but how about an instrument? No, not as a MIDI controller, but to interact with what’s going on-on screen. That’s the job of GuitarPie, a guitar-driven pie menu produced by a group at the University of Stuttgart.

The idea is pretty simple: the computer is listening for one specific note, which cues the pie menu on screen. Options on the pie menu can be selected by playing notes on adjacent strings and frets. (Check it out in action in the video embedded below). This is obviously best for guitar players, and has been built into a tablature program they’re calling TabCTRL. For those not in the loop, tablature, also known as tabs, is an instrument-specific notation system for stringed instruments that’s quite popular with guitar players. So TabCTRL is a music-learning program, that shows how to play a given song.

With this pairing, you can rock out to the tablature, the guitarist need never take their hands off the frets. You might be wondering “how isn’t the menu triggered during regular play”? Well, the boffins at Stuttgart thought of that– in TabCTRL, the menu is locked out while play mode is active. (It keeps track of tempo for you, too, highlighting the current musical phrase.) A moment’s silence (say, after you made a mistake and want to restart the song) stops play mode and you can then activate the menu. It’s well a well-thought-out UI. It’s also open source, with all the code going up on GitHub by the end of October.

The neat thing is that this is pure software; it will work with any unmodified guitar and computer. You only need a microphone in front of the amp to pick up the notes. One could, of course, use voice control– we’ve seen no shortage of hacks with that–but that’s decidedly less fun. Purists can comfort themselves that at least this time the computer interface is a real guitar, and not a guitar-shaped MIDI controller.

youtube.com/embed/ItJGNO-IQDw?…

hackaday.com/2025/10/06/guitar…

S/PDIF has been around for a long time; it’s still a really great way to send streams of digital audio from device A to device B. [Nathan Ladwig] has got the ESP32 decoding SPDIF quite effectively, using an onboard peripheral outside its traditional remit.

On the ESP32, the Remote Control Transceiver (RMT) peripheral was intended for use with infrared transceivers—think TV remotes and the like. However, this peripheral is actually quite flexible, and can be used for sending and receiving a range of different signals. [Nathan] was able to get it to work with S/PDIF quite effectively. Notably, it has no defined bitrate, which allows it to work with signals of different sample rates quite easily. Instead, it uses biphase mark code to send data. With one or two transitions for each transmitted bit, it’s possible to capture the timing and determine the correct clock from the signal itself.

[Nathan] achieved this feat as part of his work to create an ESP32-based RTP streaming device. The project allows an ESP32 to work as a USB audio device or take an S/PDIF signal as input, and then transmitting that audio stream over RTP to a receiver which delivers the audio at the other end via USB audio or as an SPDIF output. It’s a nifty project that has applications for anyone that regularly finds themselves needing to get digital audio from once place to another. It can also run a simple visualizer, too, with some attached LEDs.

It’s not the first time we’ve seen S/PDIF decoded on a microcontroller; it’s quite achievable if you know what you’re doing. Meanwhile, if you’re cooking up your own digital audio hacks, we’d love to hear about it. Digitally, of course, because we don’t accept analog phone calls here at Hackaday. Video after the break.

youtube.com/embed/k_nE87P4N88?…

hackaday.com/2025/10/06/esp32-…

Un gruppo che si autodefinisce Scattered LAPSUS$ Hunters è ricomparso dopo mesi di silenzio e l’arresto dei suoi membri. Su un nuovo sito di fuga di notizie, gli aggressori hanno pubblicato un elenco di circa 40 ambienti aziendali Salesforce e hanno chiesto un pagamento di quasi un miliardo di dollari – 989,45 milioni di dollari – in cambio della non divulgazione dei dati, che, secondo gli estorsori, includono circa un miliardo di record di clienti. Hanno fissato un ultimatum per il 10 ottobre: se Salesforce non riuscirà a negoziare, i criminali minacciano di pubblicare tutto ciò che hanno rubato.

Un rappresentante di Salesforce ha dichiarato a The Register che l’azienda era a conoscenza dei tentativi di estorsione e aveva condotto un’indagine in collaborazione con esperti esterni e forze dell’ordine. La nota ufficiale affermava che gli incidenti erano correlati a casi precedentemente noti o non confermati e che non erano stati riscontrati segni di compromissione dell’infrastruttura di Salesforce. L’azienda ha sottolineato che l’attacco non era correlato ad alcuna vulnerabilità nella sua tecnologia e che i clienti interessati stanno ricevendo supporto.

Tuttavia, la situazione affonda le sue radici in eventi accaduti ad agosto. Si è scoperto che gli aggressori avevano utilizzato token OAuth tramite l’integrazione Drift di Salesloft , consentendo loro di accedere a più istanze di Salesforce.

Cloudflare ha segnalato che “centinaia di organizzazioni” sono state colpite, con il furto di informazioni sui clienti in alcuni casi. Il team di Mandiant, incaricato da Salesloft, è stato incaricato di indagare su questi incidenti e il Google Threat Intelligence Group ha successivamente confermato l’entità della violazione. Prima di lanciare l’attuale sito di fuga di notizie, Google e Salesforce hanno inviato avvisi alle aziende potenzialmente interessate.

Nel suo rapporto di agosto sulle intrusioni in Salesforce, Google ha evidenziato il coinvolgimento del gruppo ShinyHuntersnegli incidenti e ha previsto la comparsa di un sito di fuga di notizie. All’epoca, gli analisti dell’azienda hanno anche osservato che la nuova ondata di pubblicazioni mirava probabilmente ad aumentare la pressione sulle vittime associate ai recenti attacchi UNC6040. Lo stesso giorno, è apparso un canale Telegram chiamato Scattered LAPSUS$ Hunters, con Scattered Spider, ShinyHunters e Lapsus$ che dichiaravano la loro collaborazione. Tuttavia, il canale è durato solo pochi giorni ed è stato chiuso all’inizio della settimana successiva.

A metà settembre, i rappresentanti di Scattered Spider e Lapsus$ hanno annunciato pubblicamente il loro ritiro dalle attività, con l’intenzione di “godersi i milioni accumulati”.

Ma poco dopo, due adolescenti del Regno Unito sono stati accusati di attacchi alle infrastrutture di Transport for London e gli investigatori americani e britannici li hanno collegati al gruppo Scattered Spider. Un altro adolescente si è consegnato alla polizia di Las Vegas il 17 settembre: è sospettato di aver partecipato a una serie di attacchi ai casinò nel 2023, attribuiti anch’essi allo stesso gruppo .

In risposta alle richieste dei giornalisti, i rappresentanti del nuovo gruppo SLH/SLSH Press Newsroom hanno rifiutato di fornire dettagli, confermando solo che la decisione di riprendere l’attività era “collegata ai recenti arresti”. Non hanno commentato la struttura del gruppo né l’origine dei dati trapelati.

L'articolo Ritorna il gruppo Scattered LAPSUS$ Hunters e minaccia di divulgare i dati di Salesforce proviene da il blog della sicurezza informatica.

I ricercatori di StrikeReady hanno identificato una serie di attacchi mirati in cui gli aggressori hanno sfruttato una vulnerabilità zero-day in Zimbra Collaboration Suite (ZCS), una popolare piattaforma di posta elettronica open source utilizzata da numerose agenzie governative e aziende in tutto il mondo.

La vulnerabilità, identificata come CVE-2025-27915, è una vulnerabilità XSS causata da un filtraggio insufficiente dei contenuti HTML nei file di calendario .ICS. Di conseguenza, un aggressore potrebbe iniettare codice JavaScript dannoso ed eseguirlo nel contesto della sessione dell’utente.

I file ICS, noti anche come iCalendar, vengono utilizzati per archiviare dati di eventi, riunioni e attività e sono ampiamente utilizzati per condividere pianificazioni tra diverse applicazioni. Questo formato è stato scelto dagli aggressori per implementare il loro exploit: un’e-mail dannosa, camuffata da messaggio ufficiale del Dipartimento di Protocollo della Marina libica, conteneva un file ICS di circa 100 KB, contenente un frammento JavaScript crittografato . Il codice era codificato in Base64 e si attivava all’apertura dell’allegato.

Secondo StrikeReady, l’attacco ha preso di mira un’organizzazione militare in Brasile ed è iniziato all’inizio di gennaio, ben prima del rilascio della patch. Zimbra ha corretto la vulnerabilità solo il 27 gennaio, rilasciando gli aggiornamenti ZCS 9.0.0 P44, 10.0.13 e 10.1.5. Tuttavia, la notifica ufficiale non menzionava alcuno sfruttamento attivo della vulnerabilità, rendendo la scoperta di StrikeReady particolarmente significativa.

Dopo aver decifrato il codice JavaScript, gli esperti hanno stabilito che lo script era stato progettato con cura per rubare dati da Zimbra Webmail: login, password, rubrica, email e cartelle pubbliche. Lo script utilizzava l’esecuzione asincrona e una serie di funzioni IIFE per garantire furtività e multithreading. Tra le azioni identificate c’erano la creazione di campi nascosti per rubare le credenziali, il monitoraggio dell’attività dell’utente seguito da un logout forzato per reintercettare l’accesso, l’accesso all’API SOAP di Zimbra per cercare e recuperare i messaggi, l’inoltro dei contenuti ogni quattro ore e l’aggiunta di un filtro denominato “Correo” che reindirizzava le email all’indirizzo Proton degli aggressori.

Inoltre, il malware raccoglieva artefatti di autenticazione e backup, esportava elenchi di contatti e risorse condivise, mascherava elementi dell’interfaccia per evitare sospetti e implementava un avvio ritardato di 60 secondi prima dell’esecuzione e una limitazione alla riesecuzione a non più di una volta ogni tre giorni. Questa struttura ha permesso all’attività dannosa di rimanere praticamente inosservata per lunghi periodi.

Gli esperti non sono stati in grado di attribuire con certezza l’attacco a un gruppo specifico, ma hanno osservato che questo livello di sviluppo di exploit è tipico di un gruppo molto ristretto di autori dotati delle risorse necessarie per individuare vulnerabilità zero-day. Il rapporto ha inoltre rilevato somiglianze tra i metodi utilizzati e quelli precedentemente utilizzati dal gruppo UNC1151.

StrikeReady ha pubblicato indicatori dettagliati di compromissione e ha decifrato il codice exploit che utilizzava il formato .ICS come canale di distribuzione. L’azienda sottolinea che tali attacchi sono difficili da rilevare utilizzando strumenti standard, poiché gli allegati del calendario sono tradizionalmente considerati sicuri e non destano sospetti nei sistemi di filtraggio. L’incidente ha dimostrato che anche formati apparentemente innocui possono fungere da efficace vettore di distribuzione di codice dannoso se la convalida dei contenuti lato server è inadeguata.

L'articolo Attacchi informatici tramite vulnerabilità zero-day in Zimbra Collaboration Suite proviene da il blog della sicurezza informatica.

I WebSocket offrono comunicazione bidirezionale persistente tra client e server, indispensabile per applicazioni realtime come chat, giochi, dashboard e notifiche. Questa persistenza però introduce superfici d’attacco specifiche: se il canale o le sue regole non sono adeguatamente protetti, possono verificarsi esfiltrazione di dati, hijacking di sessione e vulnerabilità legate a input non filtrati. Questo articolo spiega in modo pratico i rischi più rilevanti e le contromisure essenziali per proteggere questo tipo di connessione.

Ma cosa rende i WebSocket rischiosi?

Le caratteristiche che li rendono utili sono connessioni lunghe, traffico bidirezionale e bassissima latenza, che creano allo stesso tempo opportunità per gli attaccanti. Una connessione persistente significa che una singola breccia può mantenere l’accesso attivo a lungo. La bidirezionalità implica che sia il client che il server possano inviare dati, e per questo entrambi i lati devono considerare i messaggi come non attendibili. Gli endpoint dinamici, se costruiti con dati controllati dall’utente, possono indurre il client a connettersi a server malevoli. Infine, l’assenza di un controllo nativo sugli handshake apre la strada a possibili iniezioni o sfruttamenti provenienti da pagine esterne.

I tipi di attacco più rilevanti includono l’intercettazione e la modifica del traffico, cioè sniffing o man-in-the-middle, quando viene utilizzato il protocollo “ws://” non cifrato. Vi è poi l’iniezione di connessione, paragonabile a un CSRF applicato ai WebSocket, dove pagine malevole inducono il browser a stabilire collegamenti. Non meno importante è l’esfiltrazione di dati tramite reindirizzamento o messaggi inviati a server controllati da un attaccante, e infine le vulnerabilità legate a input non validati, capaci di generare XSS, SQL injection o comandi inattesi.

Linee guida essenziali per la sicurezza delle connessioni WebSocket

I principi di difesa fondamentali sono chiari. La cifratura deve essere sempre obbligatoria e occorre usare il protocollo “wss://”, cioè WebSocket su TLS, per prevenire sniffing e attacchi man-in-the-middle. Gli endpoint devono essere stabili e non controllabili dall’utente, definiti da configurazioni sicure e mai concatenati a input esterni. Gli handshake devono essere autenticati e verificati attraverso meccanismi come token firmati o challenge-response, con il server che controlla lo stato della sessione prima di accettare la connessione. Il controllo dell’origine lato server, tramite verifica dell’header “Origin” rispetto a una whitelist, è un ulteriore requisito.

Tutti i messaggi vanno trattati come non attendibili, con validazione rigorosa tramite schemi, limiti di dimensione e sanitizzazione costante, applicando il principio “deny-by-default”. È buona prassi limitare privilegi e funzionalità, esponendo solo ciò che è strettamente necessario e separando canali e permessi per ridurre l’impatto di una compromissione. Servono inoltre meccanismi di rate limiting, limiti sulla dimensione dei messaggi e timeout di inattività, richiedendo anche riconnessioni periodiche per il rinnovo delle credenziali. Infine, logging e monitoraggio attivo permettono di registrare eventi come handshake rifiutati, token scaduti o anomalie nel traffico, con allarmi su pattern sospetti come spike di connessioni dallo stesso IP.

Best practice e threat detection per proteggere i WebSocket

I pattern difensivi raccomandati si basano su esempi concettuali. L’autenticazione nel handshake richiede un token firmato da verificare server-side prima di stabilire il canale. La whitelist di origine consente di rifiutare richieste non provenienti da domini autorizzati. La validazione dei payload con schemi formali permette di respingere messaggi non conformi. L’escaping dei contenuti da mostrare nella UI è fondamentale per prevenire XSS. La segmentazione dei canali garantisce la separazione tra traffico sensibile e non sensibile, riducendo l’impatto di una compromissione.

Gli indicatori di una possibile compromissione comprendono un aumento anomalo di connessioni da origini non previste, la presenza di messaggi con URL esterni o payload inconsueti, connessioni ripetute e rapide verso endpoint diversi da parte dello stesso client e log che evidenziano la fuoriuscita di dati sensibili al di fuori dei normali flussi applicativi.

In conclusione, i WebSocket permettono esperienze realtime potenti, ma richiedono regole chiare per rimanere sicuri. Con pratiche come cifratura, autenticazione del canale, validazione dei messaggi, controllo delle origini e monitoraggio attivo, è possibile mantenere elevate le performance riducendo drasticamente i rischi di abuso e perdita di dati. L’applicazione sistematica di questi principi trasforma un canale potenzialmente pericoloso in uno strumento più affidabile e sicuro.

L'articolo Proteggere le connessioni WebSocket: rischio, analisi e misure pratiche proviene da il blog della sicurezza informatica.

Se n’è parlato molto poco di questo avvenimento, che personalmente reputo strategicamente molto importante e segno di un forte cambiamento nella gestione delle vulnerabilità non documentate in Italia.

A marzo 2024 scrissi un articolo in cui descrivevo un panorama italiano pressoché desolante: la cultura dei bug non documentati, gli zero-day, era praticamente inesistente, e non c’era alcuna CNA (CVE Numbering Authority) attiva nel nostro paese.

La gestione delle vulnerabilità spesso è lasciata al caso o, peggio, nascosta dietro un velo di segretezza e incapace di creare un dialogo con la comunità dei ricercatori. Quel pezzo, pubblicato su Red Hot Cyber, rimbalzò sui social e suscitò molte reazioni – sinonimo che qualcosa stava cambiando – ma allora pochi potevano immaginare che avrebbe prefigurato un cambiamento reale.

L’approccio italiano e il cambiamento

L’approccio prevalente in Italia tra i produttori di software è spesso caratterizzato dalla mancanza di conoscenza delle pratiche di gestione delle vulnerabilità non documentate, oppure dalla scelta della “security by obscurity“, nella convinzione che nascondere i bug possa garantire sicurezza.

Questo modello, sebbene diffuso, è intrinsecamente fragile: ignora la realtà della cybersicurezza contemporanea, in cui ogni vulnerabilità non gestita rappresenta una porta aperta per attacchi mirati, sofisticati e sempre più frequenti.

Infatti, la cultura dell’oscurità, ha spesso significato di trascuratezza, lentezza nella risposta e, in ultima analisi, rischi concreti per cittadini, istituzioni e clienti fino ad arrivare alla sicurezza nazionale.

Oggi, finalmente, le cose stanno cambiando. Da settembre 2024, due grandi realtà italiane, Almaviva e Leonardo, sono diventate ufficialmente CNA.

Questo significa che possono assegnare identificativi CVE alle vulnerabilità che scoprono o gestiscono tramite la community hacker, entrando così in un circuito internazionale di sicurezza responsabile. Non è un dettaglio tecnico: è la dimostrazione che l’Italia sta iniziando a prendere sul serio le vulnerabilità non documentate e a strutturare processi di sicurezza coerenti con gli standard globali.
Immagine presa da cve.org al 06/10/2025

Coordinated Vulnerability Disclosure: la chiave di volta

La transizione non riguarda solo la scoperta dei bug, ma il modo stesso in cui la sicurezza viene concepita. La CVD (Coordinated Vulnerability Disclosure)diventa lo strumento attraverso cui le aziende collaborano con i ricercatori, condividono informazioni in sicurezza e risolvono le problematiche senza lasciare spazio a sfruttamenti malevoli prima del rilascio delle patch. La CVD è, in pratica, quel ponte tra la scoperta delle vulnerabilità e la gestione responsabile, un principio che fino a poco tempo fa sembrava quasi utopico nel contesto italiano.

Ciò che impressiona è come questo nuovo approccio dimostri che trasparenza, etica e collaborazione non sono ostacoli al business, ma fattori che lo rafforzano.

Gestire i bug in modo aperto riduce drasticamente i rischi di attacco, migliora la reputazione aziendale e crea fiducia nei clienti e nei partner. L’Italia sta imparando che la sicurezza non è un valore accessorio, ma un fattore abilitante che può generare valore tangibile. Questo è il risultato anche di un lento ma significativo cambiamento nella cultura della sicurezza informatica in Italia, sostenuto dagli sforzi dell’Agenzia per la Cybersicurezza Nazionale (ACN), che, con costanza e determinazione, sta tracciando un percorso di maggiore consapevolezza e professionalità nel settore.

L’eredità dell’Open Source e la “destinazione”

Se guardiamo all’esperienza dell’open source, troviamo un modello consolidato: i progetti open prosperano grazie alla collaborazione e alla condivisione delle conoscenze. Bug, patch e miglioramenti diventano patrimonio comune e l’intera comunità beneficia dei risultati. La lezione è chiara: soprattutto nella sicurezza informatica, la cooperazione non è un rischio, ma una risorsa preziosa, capace di trasformare potenziali minacce in opportunità di crescita.

Spesso ho sottolineato un concetto chiave: ‘l’hacking è un percorso, non una destinazione’. Per le aziende italiane, il passaggio dalla mancanza di cultura sugli zero-day, o peggio dalla security by obscurity, a una gestione aperta e responsabile delle vulnerabilità non è solo un atto tecnico: è un vero e proprio percorso di crescita, un cambiamento culturale profondo che richiede visione, consapevolezza e apertura al dialogo con la comunità dei ricercatori.

Significa accettare che la sicurezza non può essere trattata come un segreto commerciale, ma come un impegno condiviso verso la comunità, i clienti e la società nel suo complesso. Richiede coraggio, visione e leadership, ma apre la strada a ecosistemi digitali più resilienti e sostenibili.

Due CNA italiane: un impegno concreto al cambiamento

Almaviva e Leonardo mostrano concretamente la via: non solo riconoscono la responsabilità verso i propri clienti, ma valorizzano il ruolo etico dei ricercatori indipendenti e della comunità hacker e adottando standard e processi che possano consentire una gestione delle vulnerabilità non documentate.

Questo modello dimostra che trasparenza e collaborazione non sono incompatibili con la competitività, ma anzi la rafforzano, trasformando il rischio in un’opportunità di innovazione continua e miglioramento del prodotto.

Il nuovo corso italiano riflette anche un cambiamento di mentalità più ampio: la sicurezza non è solo tecnica, ma sociale, culturale ed etica. La gestione responsabile delle vulnerabilità richiede dialogo, fiducia e cooperazione tra aziende, ricercatori e comunità, principi che costituiscono il fondamento di un ecosistema digitale sano e sostenibile.

Il percorso è ancora lungo, e la strada per diffondere CNA e CVD in tutte le aziende italiane è appena iniziata. Ma il fatto che oggi possiamo contare su due CNA ufficiali rappresenta un cambiamento concreto, la prima traccia di un nuovo paradigma.

E un sogno nel cassetto

Nonostante i passi avanti compiuti, oggi l’Italia e tutta l’Europa continuano a fare affidamento sui processi degli Stati Uniti per la gestione delle vulnerabilità: dal National Vulnerability Database (NVD) alle autorità di numerazione CNA, è il modello statunitense a dettare gli standard globali.

Anche se esiste un progetto europeo, il European Vulnerability Database (EUVD)gestito da ENISA, questo rimane ancora embrionale e lontano dall’avere un modello di classificazione delle vulnerabilità strutturato come quello statunitense sviluppato da MITRE e NIST.

In un’ottica di autonomia strategica europea, sarebbe auspicabile sviluppare un sistema simile a quello statunitense, che integri numerazione, valutazione del rischio e gestione coordinata delle vulnerabilità. Un modello che già esiste in Cina con il CNNVD, il repository nazionale che affianca numerazione e processi di valutazione dei rischi, dimostrando come un approccio nazionale (ed europeo) possa garantire controllo, coerenza e tempestività nella gestione dei bug critici.

Il sogno, quindi, è vedere un sistema europeo maturo e indipendente, in cui ENISA possa gestire un modello europeo della classificazione e gestione dei bug non documentati, con standardchiari, processi di valutazione del rischio condivisi e un repository trasparente accessibile a ricercatori, aziende e istituzioni. Non sarebbe solo un atto tecnico: rappresenterebbe un salto culturale e strategico per tutta la comunità di sicurezza informatica, un segnale che l’Europa vuole costruire autonomia nella cybersicurezza, valorizzare la collaborazione con la comunità hacker e proteggere i cittadini con strumenti propri, moderni e affidabili.

Fino ad allora, ogni passo compiuto dalle aziende italiane, ogni CNA istituita e ogni CVD gestita responsabilmente resta un piccolo ma fondamentale tassello di questo lungo percorso: un percorso che conduce dalla dipendenza dagli altri verso una sicurezza consapevole, etica e autonoma.

L'articolo L’Italia nel mondo degli Zero Day c’è! Le prime CNA Italiane sono Leonardo e Almaviva! proviene da il blog della sicurezza informatica.

I dati sono il sangue dell’intelligenza artificiale. È così che Nello Cristianini parla del motore dell’IA. Per intendere che sono i dati la materia grezza da cui la macchina estrae le proprie predizioni e decisioni. Il professore italiano che insegna intelligenza artificiale all’Università di Bath lo dice in Datacrazia. Politica, cultura, algoritmica e conflitti al tempo dei big data (d editore) un libro del 2018, precedente alla sua famosa trilogia per i tipi de Mulino: La scorciatoia (2023), Machina Sapiens (2024) e Sovrumano (2025), sollevando una questione su cui non sembra avere cambiato idea. O, almeno per quanto riguarda il valore dei dati, che devono essere precisi e affidabili, per consentire alle macchine di «pensare». Pensare come preconizzato da Turing, e cioè nel senso di macchine in grado di simulare un comportamento intelligente, come poi si riveleranno capaci di fare, senza ritenere però che sia lo stesso «pensare» degli esseri umani.

Il libro che è una raccolta collettanea a cura di Daniela Gambetta, e affronta i risvolti socio-politici della gestione dei dati – dalla produzione creativa digitale all’incetta che ne fanno i social network – per arrivare e metterci in guardia dai bias presenti nell’addestramento dell’IA. Timori che hanno già avuto una certa attenzione ma che non sono ancora studiati abbastanza. Ed è per questo che nella parte in cui il libro se ne occupa è possibile affermare che i contributori al libro siano stati capaci di deinire un framework interpretativo critico dell’innovazione che può essere una guida nell’analisi delle tecnologie di rete, indipendentemente dall’attualità delle soluzioni sviluppate proprio nell’IA.

Alla data del libro per esempio, il campione Gary Kasparov era stato già battuto a scacchi da un sistema di machine learning e lo stesso era accaduto a Lee Sedol nel gioco del GO; il chatbot Tay di Facebook era stato già avvelenato nei suoi dati di addestramento dall’esercito di troll su Twitter fino a congratularsi con Hitler, ma ChatGPT era ancora da venire. E, tuttavia le questioni etiche poste dal libro sono ancora irrisolte. Chi decide cosa è bene e cosa è male? La macchina o l’uomo? Viene facile dire l’uomo che la governa, ma cosa accade con i sistemi autonomi che non prevedono l’intervento umano? Ecco, Datacrazia pone quei temi, sociali e filosofici su cui ci interroghiamo ancora oggi: dalla sovranità digitale alle fake news potenziate dall’IA.

dicorinto.it/articoli/recensio…

The Czech Pirate Party won 18 seats in the October 2025 election for Parliament!

Unfortunately, the main winner of the election was the populist billionaire and former prime minister Andrej Babiš and his ANO movement. He has expressed skepticism toward support for Ukraine and has drawn closer to authoritarian leaders such as Viktor Orbán in Hungary. The Czech Pirates run on a diametrically opposed platform. The overall result of 8.7% of the vote makes them the 3rd largest party in the country. While the success is not quite as monumental as when they won 22 seats in 2017. It does represent a vast improvement from just 4 seats that the the Pirates won in 2021. In that year they ran in the Pirates and Mayors (STAN) alliance. That alliance won 37 seats in total. The Pirates ran independently this year after separating from STAN.

The Czech Pirate Party is a member of Pirate Parties International. We appreciate the strong support they provide internationally, and we wish them good luck with their upcoming term!

pp-international.net/2025/10/c…