Molte persone che si avvicinano al machine learning non hanno un forte background in ingegneria del software, e quando devono lavorare su un prodotto reale, il loro codice può risultare disordinato e difficile da gestire. Per questo motivo, raccomando sempre vivamente di imparare a usare le coding best practices, che ti permetteranno di lavorare senza problemi all’interno di un team e di migliorare il livello del progetto su cui stai lavorando. Oggi voglio parlare dell’inheritance di Python e mostrare alcuni semplici esempi di come utilizzarla nel campo del machine learning.

Nello sviluppo software e in altri ambiti dell’informatica, il technical debt (noto anche come design debt o code debt) rappresenta il costo implicito di future rielaborazioni dovuto a una soluzione che privilegia la rapidità rispetto a un design a lungo termine.

Se sei interessato a saperne di più sui design patterns, potresti trovare utili alcuni dei miei articoli precedenti.

Python Inheritance

L’Inheritance non è solo un concetto di Python, ma un concetto generale nell’Object Oriented Programming. Quindi, in questo tutorial, dovremo lavorare con classei e oggetti, che rappresentano un paradigma di sviluppo non molto utilizzato in Python rispetto ad altri linguaggi come Java.

Nell’OOP, possiamo definire una classe generale che rappresenta qualcosa nel mondo, ad esempio una Persona, che definiamo semplicemente con un nome, un cognome e un’età nel seguente modo.

class Person:
def __init__(self, name, surname, age):
self.name = name
self.surname = surname
self.age = age

def __str__(self):
return f"Name: {self.name}, surname: {self.surname}, age: {self.age}"

def grow(self):
self.age +=1

In questa classe, abbiamo definito un semplice costruttore (init). Poi abbiamo definito il method str, che si occuperà di stampare l’oggetto nel modo che desideriamo. Infine, abbiamo il method grow() per rendere la persona di un anno più vecchia.

Ora possiamo instanziare un oggetto e utilizzare questa classe.

person = Person("Marcello", "Politi", 28)
person.grow()
print(person)

# output wiil be
# Name: Marcello, surname: Politi, age: 29

E se volessimo definire un particolare tipo di persona, ad esempio un operaio? Possiamo fare la stessa cosa di prima, ma aggiungiamo un’altra variabile di input per aggiungere il suo stipendio.

class Worker:
def __init__(self, name, surname, age, salary):
self.name = name
self.surname = surname
self.age = age
self.salary = salary

def __str__(self):
return f"Name: {self.name}, surname: {self.surname}, age: {self.age}, salary: {self.salary}"

def grow(self):
self.age +=1

Tutto qui. Ma è questo il modo migliore per implementarlo? Vedete che la maggior parte del codice del lavoratore è uguale a quello della persona, perché un lavoratore è una persona particolare e condivide molte cose in comune con una persona.

Quello che possiamo fare è dire a Python che il lavoratore deve ereditare tutto da Persona, e poi aggiungere manualmente tutte le cose di cui abbiamo bisogno, che una persona generica non ha.

class Worker(Person):
def __init__(self, name, surname, age, salary):
super().__init__(name, surname, age)
self.salary = salary

def __str__(self):
text = super().__str__()
return text + f",salary: {self.salary}"

Nella classe worker, il costruttore richiama il costruttore della classe person sfruttando la parola chiave super() e poi aggiunge anche la variabile salary.

La stessa cosa avviene quando si definisce il metodo str. Utilizziamo lo stesso testo restituito da Person usando la parola chiave super e aggiungiamo il salario quando stampiamo l’oggetto.

Ereditarietà nel Machine Learning

Non ci sono regole su quando usare l’ereditarietà nell’machine learning . Non so a quale progetto stiate lavorando, né come sia il vostro codice. Voglio solo sottolineare il fatto che dovreste adottare un paradigma OOP nel vostro codice. Tuttavia, vediamo alcuni esempi di utilizzo dell’ereditarietà.

Definire un BaseModel

Sviluppiamo una classe di base per il modello di ML, definita da alcune variabili standard. Questa classe avrà un metodo per caricare i dati, uno per addestrare, un altro per valutare e uno per preelaborare i dati. Tuttavia, ogni modello specifico preelaborerà i dati in modo diverso, quindi le sottoclassi che erediteranno il modello di base dovranno riscrivere il metodo di preelaborazione.
Attenzione, il modello BaseMLModel stesso eredita la classe ABC. Questo è un modo per dire a Python che questa classe è una classe astratta e non deve essere usata, ma è solo un modello per costruire sottoclassi.

Lo stesso vale per il metodo preprocess_train_data, che è contrassegnato come @abstactmethod. Ciò significa che le sottoclassi devono reimplementare questo metodo.

Guardate questo video per saperne di più su classi e metodi astratti:

youtube.com/embed/UDmJGvM-OUw?…

from abc import ABC, abstractmethod
from sklearn.model_selection import train_test_split
from sklearn.metrics import accuracy_score
from sklearn.ensemble import RandomForestClassifier
from sklearn.linear_model import LogisticRegression
from sklearn.datasets import load_iris
import numpy as np

class BaseMLModel(ABC):
def __init__(self, test_size=0.2, random_state=42):
self.model = None # This will be set in subclasses
self.test_size = test_size
self.random_state = random_state
self.X_train = None
self.X_test = None
self.y_train = None
self.y_test = None

def load_data(self, X, y):
self.X_train, self.X_test, self.y_train, self.y_test = train_test_split(
X, y, test_size=self.test_size, random_state=self.random_state
)

@abstractmethod
def preprocess_train_data(self):
"""Each model can define custom preprocessing for training data."""
pass

def train(self):
self.X_train, self.y_train = self.preprocess_train_data()
self.model.fit(self.X_train, self.y_train)

def evaluate(self):
predictions = self.model.predict(self.X_test)
return accuracy_score(self.y_test, predictions)

Vediamo ora come ereditare da questa classe. Per prima cosa, possiamo implementare un LogisticRegressionModel. Che avrà il suo algoritmo di preelaborazione.

class LogisticRegressionModel(BaseMLModel):
def __init__(self, **kwargs):
super().__init__()
self.model = LogisticRegression(**kwargs)

def preprocess_train_data(self):
#Standardize features for Logistic Regression
mean = self.X_train.mean(axis=0)
std = self.X_train.std(axis=0)
X_train_scaled = (self.X_train - mean) / std
return X_train_scaled, self.y_train

Poi possiamo definire tutte le sottoclassi che vogliamo. Qui ne definisco una per una Random Forest.

class RandomForestModel(BaseMLModel):
def __init__(self, n_important_features=2, **kwargs):
super().__init__()
self.model = RandomForestClassifier(**kwargs)
self.n_important_features = n_important_features

def preprocess_train_data(self):
#Select top `n_important_features` features based on variance
feature_variances = np.var(self.X_train, axis=0)
top_features_indices = np.argsort(feature_variances)[-self.n_important_features:]
X_train_selected = self.X_train[:, top_features_indices]
return X_train_selected, self.y_train

Ora usiamo tutto nella funzione main.

if __name__ == "__main__":
# Load dataset
data = load_iris()
X, y = data.data, data.target

# Logistic Regression
log_reg_model = LogisticRegressionModel(max_iter=200)
log_reg_model.load_data(X, y)
log_reg_model.train()
print(f"Logistic Regression Accuracy: {log_reg_model.evaluate()}")

# Random Forest
rf_model = RandomForestModel(n_estimators=100, n_important_features=3)
rf_model.load_data(X, y)
rf_model.train()
print(f"Random Forest Accuracy: {rf_model.evaluate()}")

Conclusioni

Uno dei principali vantaggi dell’ereditarietà di Python nei progetti ML è nella progettazione di codici modulari, mantenibili e scalabili. L’ereditarietà aiuta a evitare codice ridondante, scrivendo la logica comune in una classe base, come BaseMLModel, riducendo quindi la duplicazione del codice. L’inheritance rende anche facile incapsulare comportamenti comuni in una classe base, permettendo alle subclasses di definire dettagli specifici.

Il principale vantaggio, a mio avviso, è che una codebase ben organizzata e orientata agli oggetti consente a più sviluppatori all’interno di un team di lavorare indipendentemente su parti separate. Nel nostro esempio, un ingegnere capo potrebbe definire il modello base, e poi ogni sviluppatore potrebbe concentrarsi su un singolo algoritmo e scrivere la subclass.
Prima di immergerti in design patterns complessi, concentrati sull’utilizzo delle best practices nell’OOP. Farlo ti renderà un programmatore migliore rispetto a molti altri nel campo dell’AI!

L'articolo Inheritance in Python: la chiave per scrivere codice pulito e collaborativo nel Machine Learnin proviene da il blog della sicurezza informatica.

If you’ve spent any time on two wheels, you’ve certainly experienced the woes of poor bicycle shifting. You hit the button or twist the knob expecting a smooth transition into the next gear, only to be met with angry metallic clanking that you try to push though but ultimately can’t. Bicycle manufacturers collectively spent millions attempting to remedy this issue with the likes of gearboxes, electronic shifting, and even belt-driven bikes. But Praxis believes to have a better solution in their prototype HiT system.

Rather then moving a chain between gears, their novel solution works by folding gears into or away from a chain. These gears are made up of four separate segments that individually pivot around an axle near the cog’s center. These segments are carefully timed to ensure there is no interference with the chain making shifting look like a complex mechanical ballet.

While the shift initialization is handled electronically, the gear folding synchronization is mechanical. The combination of electronic and mechanical systems brings near-instant shifting under load at rotational rates of 100 RPM. Make sure to scroll through the product page and watch the videos showcasing the mechanism!

The HiT gearbox is a strange hybrid between a derailleur and a gearbox. It doesn’t contain a clutch based gear change system or even a CVT as seen in the famous Honda bike of old. It’s fully sealed with more robust chains and no moving chainline as in a derailleur system. The prototype is configurable between four or sixteen speeds, with the four speed consisting of two folding gear pairs connected with a chain and the sixteen speed featuring a separate pair of folding gears. The output is either concentric to the input, or above the input for certain types of mountain bikes.

Despite the high level of polish, this remains a prototype and we eagerly await what Praxis does next with the system. In the meantime, make sure to check out this chainless e-drive bicycle.

hackaday.com/2025/04/17/bicycl…

If you had to guess, what do you think it would take to build an ocean-going buoy that could not only survive on its own without human intervention for more than two years, but return useful data the whole time? You’d probably assume such a feat would require beefy hardware, riding inside an expensive and relatively large watertight vessel of some type — and for good reason, the ocean is an unforgiving environment, and has sent far more robust hardware to the briny depths.

But as Wayne Pavalko found back in 2016, a little planning can go a long way. That’s when he launched the first of what he now calls Maker Buoys: a series of solar-powered drifting buoys that combine a collection of off-the-shelf sensor boards with an Arduino microcontroller and an Iridium Short-Burst Data (SBD) modem in a relatively simple watertight box.

He guessed that first buoy might last a few weeks to a month, but when he finally lost contact with it after 771 days, he realized there was real potential for reducing the cost and complexity of ocean research.

Wayne recalled the origin of his project and updated the audience on where it’s gone from there during his 2024 Supercon talk, Adventures in Ocean Tech: The Maker Buoy Journey. Even if you’re not interested in charting ocean currents with homebrew hardware, his story is an inspirational reminder that sometimes a fresh approach can help solve problems that might at first glance seem insurmountable.

DIY All the Way

As Dan Maloney commented when he wrote-up that first buoy’s journey in 2017, the Bill of Materials for a Maker Buoy is tailored for the hobbyist. Despite being capable of journeys lasting for several thousand kilometers in the open ocean, there’s no marine-grade unobtainium parts onboard. Indeed, nearly all of the electronic components can be sourced from Adafruit, with the most expensive line item being the RockBLOCK 9603 Iridium satellite modem at $299.

Even the watertight container that holds all the electronics is relatively pedestrian. It’s the sort of plastic latching box you might put your phone or camera in on a boat trip to make sure it stays dry and floats if it falls overboard. Wayne points out that the box being clear is a huge advantage, as you can mount the solar panel internally. Later versions of the Maker Buoy even included a camera that could peer downward through the bottom of the box.

Wayne says that first buoy was arguably over-built, with each internal component housed in its own waterproof compartment. Current versions instead hold all of the hardware in place with a 3D printed internal frame. The bi-level framework puts the solar panel, GPS, and satellite modem up at the top so they’ve got a clear view of the sky, and mounts the primary PCB, battery, and desiccant container down on the bottom.

The only external addition necessary is to attach a 16 inch (40 centimeter) long piece of PVC pipe to the bottom of the box, which acts as a passive stabilizer. Holes drilled in the pipe allow it to fill with water once submerged, lowering the buoy’s center of gravity and making it harder to flip over. At the same time, should the buoy find itself inverted due to wave action, the pipe will make it top-heavy and flip it back over.

It’s simple, cheap, and incredibly effective. Wayne mentions that data returned from onboard Inertial Measurement Units (IMUs) have shown that Maker Buoys do occasionally find themselves going end-over-end during storms, but they always right themselves.

youtube.com/embed/5WSOKEplw9g?…

Like Space…But Wetter

The V1 Maker Buoy was designed to be as reliable as possible.
Early on in his presentation, Wayne makes an interesting comparison when talking about the difficulties in developing the Maker Buoy. He likens it to operating a spacecraft in that your hardware is never coming back, nobody will be able to service it, and the only connection you’ll have to the craft during its lifetime is a relatively low-bandwidth link.

But one could argue that the nature of Iridium communications makes the mission of the Maker Buoy even more challenging than your average spacecraft. As the network is really only designed for short messages — at one point Wayne mentions that even sending low-resolution images of only a few KB in size was something of an engineering challenge — remotely updating the software on the buoy isn’t an option. So even though the nearly fifty year old Voyager 1 can still receive the occasional software patch from billions of miles away, once you drop a Maker Buoy into the ocean, there’s no way to fix any bugs in the code.

Because of this, Wayne decided to take the extra step of adding a hardware watchdog timer that can monitor the buoy’s systems and reboot the hardware if necessary. It’s a bit like unplugging your router when the Internet goes out…if your Internet was coming from a satellite low-Earth orbit and your living room happened to be in the middle of the ocean.

From One to Many

After publishing information about his first successful Maker Buoy online, Wayne says it wasn’t long before folks started contacting him about potential applications for the hardware. In 2018, a Dutch non-profit expressed interest in buying 50 buoys from him to study the movement of floating plastic waste in the Pacific. The hardware was more than up to the task, but there was just one problem: up to this point, Wayne had only built a grand total of four buoys.

Opportunities like this, plus the desire to offer the Maker Buoy in kit and ready to deploy variants for commercial and educational purposes, meant Wayne had to streamline his production. When it’s just a personal project, it doesn’t really matter how long it takes to assemble or if everything goes together correctly the first time. But that approach just won’t work if you need to deliver functional units in quantities that you can’t count on your fingers.

As Wayne puts it, making something and making something that’s easily producible are really two very different things. The production becomes a project in its own right. He explains that investing the time and effort to make repetitive tasks more efficient and reliable, such as developing jigs to hold pieces together while you’re working on them, more than pays off for itself in the end. Even though he’s still building them himself in his basement, he uses an assembly line approach that allows for the consistent results expected by paying customers.

A Tale Well Told

While the technical details of how Wayne designed and built the different versions of the Maker Buoy are certainly interesting, it’s hearing the story of the project from inception to the present day that really makes watching this talk worthwhile. What started as a simple “What If” experiment has spiraled into a side-business that has helped deploy buoys all over the planet.

Admittedly, not every project has that same potential for growth. But hearing Wayne tell the Maker Buoy story is the sort of thing that makes you want to go dust off that project that’s been kicking around in the back of your head and finally give it a shot. You might be surprised by the kind of adventure taking a chance on a wild idea can lead to.

youtube.com/embed/cCYdSGGZcv0?…

hackaday.com/2025/04/17/superc…

Il Global Threat Report 2025 di CrowdStrike ha tracciato l’evoluzione e anticipato le sfide per la sicurezza informatica, ponendo attenzione sulla necessità di un ripensamento radicale delle strategie difensive tradizionali. Su questo e molto altro si confronterà un panel di esperti e aziende al CrowdTour, il 5 giugno a Milano.

Il Global Threat Report 2025 di CrowdStrike ha recentemente fotografato un panorama globale delle minacce informatiche in evoluzione. Nel 2024, la rapidità con cui gli attaccanti sono riusciti a sfruttare le vulnerabilità per insidiarsi nei sistemi è cresciuta, con un breakout timeminimo registrato di appena 51 secondi.

I cybercriminali, sempre più rapidi, sofisticati e organizzati, sfruttano le vulnerabilità degli ambienti cloud, le debolezze umane e tecnologie emergenti, prima tra tutte l’intelligenza artificiale generativa, per colpire le aziende ovunque e in ogni settore mettendo in luce l’esigenza non più trascurabile di mettere in pratica strategie di difesa più articolate.

L’intelligenza artificiale generativa: l’arma nelle mani degli attaccanti

Protagonista dell’indagine di CrowdStrike l’adozione su larga scala nel 2024 della GenAI da parte degli attaccanti informatici. L’AI ha notevolmente migliorato la qualità degli attacchi, in termini di automazione e scalabilità, generazione automatica di contenuti e di social engineering sempre più precisi. Gli strumenti di intelligenza artificiale generativa sono stati usati infatti per scrivere e-mail di phishing più credibili, creare profili falsi, realizzare contenuti manipolatori e automatizzare la creazione di malware.

Sono stati osservati in particolare gruppi nordcoreani, primo tra tutti FAMOUS CHOLLIMA, responsabile di aver utilizzato tecniche di social engineering per supportare la creazione di profili LinkedIn falsi, testi e risposte più credibili da utilizzare durante i colloqui di lavoro, utilizzando strumento di Gen AI. Con queste tecniche è stato possibile per questi criminali ingannare i recruiter, farsi assumere all’interno di grandi aziende come sviluppatori di software e tecnici IT e poi spedire i laptop aziendali in dotazione presso “Laptop farms” situate in paesi specifici per ottenere un IP pubblico di provenienza “trusted” (es. USA) e, una volta ottenuto l’accesso alle reti aziendali, installare strumenti di gestione remota (RMM) e estensioni del browser malevole per esfiltrare dati o eseguire altre attività malevole.

Le nuove frontiere dello spionaggio: la Cina e il cloud nel mirino

Il report ha posto anche l’attenzione su un aumento significativo dell’attività malevola associata alla Cina, cresciuta del 150% su scala globale e fino al 300% in settori come finanza, media, manifattura, industria e ingegneria.

Anche il cloud è diventato un bersaglio privilegiato, poiché responsabile della creazione di superfici di attacco sempre più estese, ma anche di configurazioni spesso errate e vulnerabilità non patchate.

Gli attaccanti hanno sfruttato identità compromesse e l’exploitation of trust relationship, ovvero abusi dei rapporti di fiducia, per muoversi lateralmente e mantenere l’accesso alle risorse cloud. Sono aumentate le intrusioni SaaS, in particolare su piattaforme come Microsoft 365, spesso finalizzate a esfiltrare dati ai fini di estorsione o di accesso a terze parti.

Quali strategie difensive adottare in azienda

CrowdStrike non si limita ad analizzare l’evoluzione delle minacce nel corso del 2024, ma propone una serie di riflessioni, raccomandazioni e best practices per le organizzazioni:

• Proteggere l’intero ecosistema delle identità adottando MFA resistenti al phishing, implementando politiche di accesso forti e utilizzando strumenti di rilevamento delle minacce alle identità integrati con piattaforme XDR
• Eliminare i gap di visibilità cross-domain: modernizzando le strategie di rilevamento e risposta con soluzioni XDR e SIEM di nuova generazione, svolgendo threat hunting proattivo e utilizzando intelligence sulle minacce
• Difendere il cloud come infrastruttura core: utilizzare CNAPP con capacità CDR, eseguire audit regolari per scoprire configurazioni errate e vulnerabilità non patchate
• Dare priorità al patching dei sistemi critici e utilizzare strumenti come Falcon Exposure Management per concentrarsi sulle vulnerabilità ad alto rischio
• Adottare un approccio basato sull’intelligence, integrare l’intelligence nelle operazioni di sicurezza, avviare programmi di consapevolezza degli utenti e svolgere esercitazioni di tabletop e red/blue teaming.

Appuntamento con il CrowdTour 2025 il prossimo 5 giugno a Milano

L’evento annuale di CrowdStrike farà tappa il prossimo 5 giugno presso PARCO Center Milano per un pomeriggio di full immersion nella cybersecurity.

L’azienda offrirà a professionisti, decision maker e aziende l’opportunità di confrontarsi direttamente con esperti internazionali, esplorare casi di successo e approfondire le più recenti innovazioni in ambito protezione degli endpoint, delle identità e delle infrastrutture cloud. L’evento rappresenterà anche un momento di networking per chi affronta quotidianamente le sfide della sicurezza, e di condivisione di esperienze reali, utile per lo sviluppo di strategie efficaci contro minacce tradizionali ed emergenti. Trovate tutte le informazioni sull’agenda e la possibilità di registrarsi a questo link.

L'articolo La sicurezza informatica nel 2025: un panorama di minacce in costante evoluzione e come difendersi proviene da il blog della sicurezza informatica.

We’re suckers here for projects that let you see the unseeable, and [Ayden Wardell Aerospace] provides that on a budget with their $30 Schlieren Imaging Setup. The unseeable in question is differences in air density– or, more precisely, differences in the refractive index of the fluid the imaging set up makes use of, in this case air. Think of how you can see waves of “heat” on a warm day– that’s lower-density hot air refracting light as it rises. Schlieren photography weaponizes this, allowing to analyze fluid flows– for example, the mach cones in a DIY rocket nozzle, which is what got [Ayden Wardell Aerospace] interested in the technique.

Examining exhaust makes this a useful tool for [Aerospace].This is a ‘classic’ mirror-and-lamp Schlieren set up. You put the system you wish to film near the focal plane of a spherical mirror, and camera and light source out at twice the focal distance. Rays deflected by changes in refractive index miss the camera– usually one places a razor blade precisely to block them, but [Ayden] found that when using a smart phone that was unnecessary, which shocked this author.

While it is possible that [Ayden Wardell Aerospace] has technically constructed a shadowgraph, they claim that carefully positioning the smartphone allows the sharp edge of the case to replace the razor blade. A shadowgraph, which shows the second derivative of density, is a perfectly valid technique for flow visualization, and is superior to Schlieren photography in some circumstances– when looking at shock waves, for example.

Regardless, the great thing about this project is that [Ayden Wardell Aerospace] provides us with STLs for the mirror and smartphone mounting, as well as providing a BOM and a clear instructional video. Rather than arguing in the comments if this is “truly” Schlieren imaging, grab a mirror, extrude some filament, and test it for yourself!

There are many ways to do Schlieren images. We’ve highighted background-oriented techniques, and seen how to do it with a moiré pattern, or even a selfie stick. Still, this is the first time 3D printing has gotten involved and the build video below is quick and worth watching for those sweet, sweet Schlieren images.

youtube.com/embed/piGYryly5Bw?…

hackaday.com/2025/04/17/budget…

Day after day, threat actors create new malware to use in cyberattacks. Each of these new implants is developed in its own way, and as a result gets its own destiny – while the use of some malware families is reported for decades, information about others disappears after days, months or several years.

We observed the latter situation with an implant that we dubbed MysterySnail RAT. We discovered it back in 2021, when we were investigating the CVE-2021-40449 zero-day vulnerability. At that time, we identified this backdoor as related to the IronHusky APT, a Chinese-speaking threat actor operating since at least 2017. Since we published a blogpost on this implant, there have been no public reports about it, and its whereabouts have remained unknown.

However, recently we managed to spot attempted deployments of a new version of this implant, occurring in government organizations located in Mongolia and Russia. To us, this observed choice of victims wasn’t surprising, as back in 2018, we wrote that IronHusky, the actor related to this RAT, has a specific interest in targeting these two countries. It turned out that the implant has been actively used in cyberattacks all these years although not reported.

Infection through a malicious MMC script

One of the recent infections we spotted was delivered through a malicious MMC script, designed to be disguised as a document from the National Land Agency of Mongolia (ALAMGAC):

Malicious MMC script as displayed in Windows Explorer. It has the icon of a Microsoft Word document

When we analyzed the script, we identified that it is designed to:

• Retrieve a ZIP archive with a second-stage malicious payload and a lure DOCX file from the file[.]io public file storage.
• Unzip the downloaded archive and place the legitimate DOCX file into the %AppData%\Cisco\Plugins\X86\bin\etc\Update folder
• Start the CiscoCollabHost.exe file dropped from the ZIP archive.
• Configure persistence for the dropped CiscoCollabHost.exefile by adding an entry to the Run registry key.
• Open the downloaded lure document for the victim.

Intermediary backdoor

Having investigated the
CiscoCollabHost.exe file, we identified it as a legitimate executable. However, the archive deployed by the attackers also turned out to include a malicious library named CiscoSparkLauncher.dll, designed to be loaded by the legitimate process through the DLL Sideloading technique.
We found out that this DLL represents a previously unknown intermediary backdoor, designed to perform C2 communications by abusing the open-source piping-server project. An interesting fact about this backdoor is that information about Windows API functions used by it is located not in the malicious DLL file, but rather in an external file having the
log\MYFC.log relative path. This file is encrypted with a single-byte XOR and is loaded at runtime. It is likely that the attackers introduced this file to the backdoor as an anti-analysis measure – since it is not possible to determine the API functions called without having access to this file, the process of reverse engineering the backdoor essentially turns into guesswork.
By communicating with the legitimate
ppng.io server powered by the piping-server project, the backdoor is able to request commands from attackers and send back their execution results. It supports the following set of basic malicious commands:

As we found out, attackers used commands implemented in this backdoor to deploy the following files to the victim machine:

• sophosfilesubmitter.exe, a legitimate executable
• fltlib.dll, a malicious library to be sideloaded

In our telemetry, these files turned out to leave footprints of the MysterySnail RAT malware, an implant we described back in 2021.

New version of MysterySnail RAT

In observed infection cases, MysterySnail RAT was configured to persist on compromised machines as a service. Its malicious DLL, which is deployed by the intermediary backdoor, is designed to load a payload encrypted with RC4 and XOR, and stored inside a file named
attach.dat. When decrypted, it is reflectively loaded using DLL hollowing with the help of code implemented inside the run_pe library.
Just as the version of MysterySnail RAT we described in 2021, the latest version of this implant uses attacker-created HTTP servers for communication. We have observed communications being performed with the following servers:

• watch-smcsvc[.]com
• leotolstoys[.]com
• leotolstoys[.]com

Having analyzed the set of commands implemented in the latest version of this backdoor, we identified that it is quite similar to the one implemented in the 2021 version of MysterySnail RAT – the newly discovered implant is able to accept about 40 commands, making it possible to:

• Perform file system management (read, write and delete files; list drives and directories).
• Execute commands via the cmd.exe shell.
• Spawn and kill processes.
• Manage services.
• Connect to network resources.

Compared to the samples of MysterySnail RAT we described in our 2021 article, these commands were implemented differently. While the version of MysterySnail from 2021 implements these commands inside a single malicious component, the newly discovered version of the implant relies on five additional DLL modules, downloaded at runtime, for command execution. These modules are as follows:

However, this transition to a modular architecture isn’t something new – as we have seen modular versions of the MysterySnail RAT deployed as early as 2021. These versions featured the same modules as described above, including the typo in the
ExplorerMoudleDll.dll module name. Back then, we promptly made information about these versions available to subscribers of our APT Intelligence Reporting service.

MysteryMonoSnail – a repurposed version of MysterySnail RAT

Notably, a short time after we blocked the recent intrusions related to MysterySnail RAT, we observed the attackers to continue conducting their attacks, by deploying a repurposed and more lightweight version of MysterySnail RAT. This version consists of a single component, and that’s why we dubbed it MysteryMonoSnail. We noted that it performed communications with the same C2 server addresses as found in the full-fledged version of MysterySnail RAT, albeit via a different protocol – WebSocket instead of HTTP.

This version doesn’t have as many capabilities as the version of MysterySnail RAT that we described above – it was programmed to have only 13 basic commands, used to list directory contents, write data to files, and launch processes and remote shells.

Obsolete malware families may reappear at any time

Four years, the gap between the publications on MysterySnail RAT, has been quite lengthy. What is notable is that throughout that time, the internals of this backdoor hardly changed. For instance, the typo in the
ExplorerMoudleDll.dll that we previously noted was present in the modular version of MysterySnail RAT from 2021. Furthermore, commands implemented in the 2025 version of this RAT were implemented similarly to the 2021 version of the implant. That is why, while conducting threat hunting activities, it’s crucial to consider that old malware families, which have not been reported on for years, may continue their activities under the radar. Due to that, signatures designed to detect historical malware families should never be discontinued simply because they are too old.
At Kaspersky’s GReAT team, we have been focusing on detecting complex threats since 2008 – and we provide sets of IoCs for both old and new malware to customers of our Threat Intelligence portal. If you wish to get access to these IoCs and other information about historical and emerging threats, please contact us at intelreports@kaspersky.com.

securelist.com/mysterysnail-ne…

This project by [Miro] is awesome, not only did he build a replica Enigma machine using modern technologies, but after completing it, he went back and revised several components to make it more usable. We’ve featured Enigma machines here before; they are complex combinations of mechanical and electrical components that form one of the most recognizable encryption methods in history.

His first Enigma machine was designed closely after the original. He used custom PCBs for the plugboard and lightboard, which significantly cleaned up the internal wiring. For the lightboard, he cleverly used a laser printer on semi-transparent paper to create crisp letters, illuminated from behind. For the keyboard, he again designed a custom PCB to connect all the switches. However, he encountered an unexpected setback due to error stack-up. We love that he took the time to document this issue and explain that the project didn’t come together perfectly on the first try and how some adjustments were needed along the way.

The real heart of this build is the thought and effort put into the design of the encryption rotors. These are the components that rotate with each keystroke, changing the signal path as the system is used. In a clever hack, he used a combination of PCBs, pogo pins, and 3D printed parts to replicate the function of the original wheels.

Enigma machine connoisseurs will notice that the wheels rotate differently than in the original design, which leads us to the second half of this project. After using the machine for a while, it became clear that the pogo pins were wearing down the PCB surfaces on the wheels. To solve this, he undertook an extensive redesign that resulted in a much more robust and reliable machine.

In the redesign, instead of using pogo pins to make contact with pads, he explored several alternative methods to detect the wheel position—including IR light with phototransistors, rotary encoders, magnetic encoders, Hall-effect sensors, and more. The final solution reduced the wiring and addressed long-term reliability concerns by eliminating the mechanical wear present in the original design.

Not only did he document the build on his site, but he also created a video that not only shows what he built but also gives a great explanation of the logic and function of the machine. Be sure to also check out some of the other cool enigma machines we’ve featured over the years.

youtube.com/embed/T_UuYkO4OBQ?…

hackaday.com/2025/04/17/modern…

Sul Forum DarketArmy l’attore Mr.Robot ha messo in vendita un RAT ad Agosto 2023. DarknetArmy è un forum attivo nel dark web, emerso per la prima volta nel 2018. È noto per la condivisione di strumenti di hacking, informazioni sulla sicurezza e altre risorse legate alla cybersecurity.

Il RAT, codificato con il nome “888”, ha suscitato un rinnovato interesse nelle ultime due settimane, nonostante il post originale risalga a due anni fa.

Questo aumento di attenzione potrebbe essere dovuto a recenti aggiornamenti o miglioramenti del malware, rendendolo più efficace o difficile da rilevare

Il gruppo Blade Hawk ha utilizzato una versione craccata di questo RAT per condurre attacchi di spionaggio verso gruppi etnici curdi tramite forum, social media o app legittime

Diverse versioni crakkate sono disponibili in repository GitHub e sono tuttora utilizzate da pentester. Le potenzialità di questo malware sono molteplici, ecco le principali:

• Accesso Remoto al Desktop: Permette agli attaccanti di controllare il desktop del sistema infetto da remoto.
• Cattura Webcam e Audio: Consente di registrare video e audio tramite la webcam e il microfono del dispositivo.
• Recupero Password: Estrae password da vari browser e client di posta elettronica.
• Keylogging: Registra i tasti premuti sulla tastiera, permettendo di intercettare informazioni sensibili come credenziali di accesso.
• Gestione dei File: Permette di visualizzare, modificare, eliminare e trasferire file sul sistema infetto.
• Spoofing delle Estensioni dei File: Modifica le estensioni dei file per nascondere la vera natura dei file infetti.
• Persistenza: Implementa meccanismi per rimanere attivo anche dopo il riavvio del sistema o la cancellazione dei file.
• Disabilitazione delle Utility di Sistema: Disabilita strumenti di gestione del sistema per evitare la rilevazione e la rimozione.
• Bypass della Rilevazione Antivirus: Utilizza tecniche di offuscamento per evitare di essere rilevato dai software antivirus.
• Elevazione dei Privilegi: Esegue exploit UAC per ottenere privilegi elevati sul sistema infetto.

Nelle ultime due settimane, il post ha ricevuto un notevole aumento di commenti da parte di utenti interessati al download, suggerendo un possibile aggiornamento del malware o un rinnovato interesse per le sue capacità.

Per proteggersi da minacce come il RAT 888, è raccomandato seguire alcune pratiche di sicurezza:

• Aggiornare e Patchare i Sistemi: Assicurarsi che tutti i sistemi siano aggiornati con le ultime patch di sicurezza, in particolare quelle che affrontano vulnerabilità come MS17-10 (EternalBlue), per prevenire lo sfruttamento da parte dei RAT.
• Migliorare la Protezione degli Endpoint: Implementare soluzioni avanzate di protezione degli endpoint in grado di rilevare e bloccare le attività dei RAT, come l’accesso remoto non autorizzato e l’offuscamento dei processi.

Queste misure possono aiutare a mitigare i rischi associati a malware sofisticati come il RAT 888, contribuendo a mantenere un ambiente digitale più sicuro.

L'articolo DarknetArmy e il RAT 888: Un Malware che Torna a Far Paura proviene da il blog della sicurezza informatica.

È uno di quei momenti che passano sottotraccia per l’opinione pubblica, ma che per chi opera nel mondo della cybersecurity suona come un’allerta silenziosa, quasi surreale: la possibilità concreta che il sistema CVE – Common Vulnerabilities and Exposures – possa smettere di funzionare. Non per un attacco informatico. Non per un evento naturale. Ma per un più banale, quanto drammatico, problema di mancato rinnovo dei fondi da parte del governo statunitense.

La notizia è arrivata come un fulmine a ciel sereno, ma a ben guardare, i segnali di instabilità erano presenti da tempo. La lettera recentemente inviata da MITRE Corporation, ente responsabile della gestione del CVE Program per conto del governo USA, rappresenta molto più di un avviso tecnico: è il grido d’allarme di un’infrastruttura critica che rischia di spegnersi nel silenzio generale.

Eppure, se c’è una cosa che dovrebbe essere chiara a chiunque lavori nel settore, è che il CVE non è un semplice database, ma il vero e proprio fulcro della nomenclatura condivisa nel mondo della sicurezza informatica.

Perché il CVE è fondamentale?

Il CVE è il sistema che assegna un identificativo univoco – il cosiddetto CVE-ID – a ogni vulnerabilità software conosciuta pubblicamente. Senza questi identificativi, l’intero ecosistema cyber perderebbe coerenza: le analisi dei vendor, le patch, i report di minaccia, le valutazioni di rischio, gli strumenti SIEM, gli scanner di vulnerabilità e persino le dashboard delle agenzie nazionali di sicurezza non saprebbero più “come chiamare” le minacce.

È come se all’improvviso qualcuno decidesse che i numeri di targa delle automobili non servono più. Ogni incidente diventerebbe un caos burocratico, ogni multa un rebus, ogni denuncia un’informazione vaga. È esattamente ciò che accadrebbe senza il CVE: un buco nero semantico nel cuore della cybersecurity.

La crisi attuale: cosa dice la lettera MITRE

La comunicazione inviata da MITRE – ferma, tecnica, ma inequivocabile – mette in chiaro che la fine dei fondi federali (provenienti dalla CISA, la Cybersecurity and Infrastructure Security Agency) comporta l’impossibilità di garantire la continuità delle attività legate al programma CVE.

Senza finanziamenti:

• i processi di triage, validazione e pubblicazione delle vulnerabilità si fermeranno;
• i CNA (CVE Numbering Authorities), aziende autorizzate ad assegnare CVE-ID, perderanno il punto di riferimento centrale;
• i ritardi accumulati nelle assegnazioni, già criticamente aumentati negli ultimi mesi, rischiano di cronicizzarsi;
• la credibilità dell’intero ecosistema CVE verrebbe compromessa.

È quindi evidente che siamo di fronte a un single point of failure di proporzioni sistemiche, ma – e qui la riflessione si fa geopolitica – anche a un punto di dipendenza strategica da parte dell’intero Occidente, Europa compresa.

Europa: dove sei?

In un mondo multipolare, in cui la cybersicurezza è ormai considerata parte integrante della sovranità nazionale e continentale, fa riflettere quanto l’Europa – ancora oggi – non disponga di un proprio sistema alternativo o complementare per la gestione delle vulnerabilità informatiche.

La Cina, da anni, ha sviluppato un proprio database nazionale, con modalità operative, criteri e perfino una “agenda politica” nella gestione delle disclosure. In Russia esistono repository indipendenti connessi ai CERT federali. Ma l’Unione Europea? Ancora troppo sbilanciata su un modello americano-centrico, e spesso reattiva più che proattiva, nel campo della cyber intelligence.

Questa situazione rivela un grave gap di autonomia strategica: affidarsi a un’infrastruttura critica gestita da un singolo paese estero – per quanto alleato – significa esporsi a eventi come quello odierno, dove una semplice decisione amministrativa può influire sull’intero tessuto operativo delle nostre imprese, delle nostre agenzie, delle nostre difese.

Le implicazioni operative

L’impatto di un’eventuale sospensione del programma CVE si rifletterebbe su più piani:

• Industriale: i produttori di software e hardware non avrebbero più un framework di riferimento per le advisory.
• Governativo: le agenzie di sicurezza, i CERT nazionali e gli organismi di difesa non potrebbero più sincronizzarsi su vulnerabilità condivise.
• Accademico: la ricerca in ambito cybersecurity, già basata sulla tassonomia CVE, perderebbe uniformità e tracciabilità.
• Comunicativo: i media specializzati e le piattaforme di threat intelligence perderebbero un punto di riferimento essenziale nella diffusione di notizie sulle vulnerabilità.

In pratica, si creerebbe un effetto domino che andrebbe a compromettere l’intera filiera della gestione del rischio informatico.

La proposta: un sistema europeo di identificazione delle vulnerabilità

Serve un cambio di passo. E serve ora.

La mia proposta – che condivido da tempo in diverse sedi tecniche e istituzionali – è quella di creare un sistema CVE europeo, gestito da ENISA in collaborazione con i CERT nazionali, eventualmente interoperabile con il programma MITRE ma a controllo sovrano.

Un’infrastruttura simile permetterebbe:

• una gestione più trasparente e aderente ai valori europei;
• una maggiore protezione degli interessi industriali del continente;
• la possibilità di creare un ecosistema di CNA europei che rispondano a criteri omogenei e verificabili;
• un’integrazione più coerente con il nuovo regolamento NIS2, che obbliga le aziende critiche a gestire vulnerabilità e incidenti con precisione e tempestività.

Conclusioni

Il possibile collasso del programma CVE non è solo una crisi tecnica. È uno specchio, uno spartiacque, un’occasione – se vogliamo – per fermarci a riflettere su quanto la cybersicurezza sia oggi legata a scelte geopolitiche e strategiche.

L’Europa, se vuole essere davvero sovrana anche in ambito digitale, non può più permettersi di essere solo “utente” dei sistemi critici altrui. Deve iniziare a costruire i propri.

Perché senza nomi condivisi, anche la sicurezza – come il linguaggio – rischia di diventare babelica, confusa e inefficace. E in un mondo sempre più interconnesso, la chiarezza e la coerenza non sono un lusso, ma una necessità operativa.

L'articolo Il sistema CVE rischia il collasso: tra silenzi assordanti, dipendenze strategiche e un’Europa ancora senza voce proviene da il blog della sicurezza informatica.

Quanto accaduto in questi giorni deve rappresentare un campanello d’allarme per l’Europa.
Mentre il programma CVE — pilastro della sicurezza informatica globale — rischiava di spegnersi a causa della mancata estensione dei fondi statunitensi, l’Europa è rimasta spettatrice inerme.

Se i finanziamenti al progetto non fossero stati confermati in extremis, quanto sarebbe stata esposta la sicurezza nazionale dei Paesi europei? È inaccettabile che la protezione delle nostre infrastrutture digitali dipenda in modo così diretto da un’infrastruttura critica interamente statunitense.

Come abbiamo riportato nella giornata di ieri, noi di RHC lo riportiamo da tempo e non possiamo più permetterci una simile dipendenza. È necessario che ENISA e le istituzioni europee aprano una riflessione seria e strutturata su questo tema, promuovendo la nascita di un progetto interamente europeo per la gestione e la catalogazione delle vulnerabilità.

L’Europa deve smettere di delegare la propria resilienza digitale.

È tempo di costruire un’alternativa sovrana, trasparente e interoperabile, per garantire continuità, indipendenza e sicurezza a lungo termine. Parliamo tanto di autonomia tecnologica. Allora partiamo dalle basi della sicurezza nazionale prima di parlare di Quantum computing.

I fatti delle ultime ore

Sembra che la paura sia passata. Infatti la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha rinnovato il contratto con la MITRE Corporation, assicurando così la continuità operativa del programma Common Vulnerabilities and Exposures (CVE). Questo intervento tempestivo ha evitato l’interruzione di uno dei pilastri fondamentali della sicurezza informatica globale, che era a poche ore dalla sospensione per mancanza di fondi federali.

Lanciato nel 1999 e gestito proprio da MITRE, il programma CVE rappresenta il sistema di riferimento internazionale per l’identificazione, la catalogazione e la standardizzazione delle vulnerabilità informatiche note. Il suo ruolo è cruciale per la difesa digitale: garantisce un linguaggio comune tra vendor, analisti e istituzioni, permettendo una risposta più coordinata ed efficace alle minacce.

Questa decisione arriva nel contesto di una più ampia strategia di riduzione dei costi da parte del governo federale, che ha già portato alla risoluzione di contratti e a riduzioni di personale in diversi team della CISA. pertanto si è riacceso il dibattito sulla sostenibilità e la neutralità di una risorsa di importanza globale come la CVE legata a un singolo sponsor governativo.

Il ruolo fondamentale del progetto CVE

Gli identificatori univoci del programma, noti come ID CVE, sono fondamentali per l’intero ecosistema della sicurezza informatica. Ricercatori, fornitori di soluzioni e team IT in tutto il mondo li utilizzano per tracciare, classificare e correggere in modo efficiente le vulnerabilità di sicurezza. Il database CVE è alla base di strumenti critici come scanner di vulnerabilità, sistemi di gestione delle patch e piattaforme per la risposta agli incidenti, oltre a svolgere un ruolo strategico nella protezione delle infrastrutture critiche.

La crisi è esplosa quando MITRE ha annunciato che il contratto con il Dipartimento della Sicurezza Interna (DHS) per la gestione del programma CVE sarebbe scaduto il 16 aprile 2025, senza alcun rinnovo previsto. L’annuncio ha allarmato la comunità della cybersecurity, che considera il CVE uno standard globale imprescindibile. Gli esperti hanno lanciato l’allarme: un’interruzione avrebbe compromesso i database nazionali delle vulnerabilità, messo a rischio gli avvisi di sicurezza e ostacolato l’operatività di fornitori e team di risposta agli incidenti su scala mondiale. In risposta alla minaccia, è stata istituita la CVE Foundation, con l’obiettivo di garantire la continuità, l’indipendenza e la stabilità a lungo termine del programma.

Sotto la crescente pressione della comunità di settore, CISA — sponsor principale del programma — è intervenuta nella tarda serata di martedì, attivando formalmente un “periodo di opzione” sul contratto con MITRE, a poche ore dalla scadenza.

“Il programma CVE è una priorità per CISA e un asset essenziale per la comunità informatica,” ha dichiarato un portavoce a Cyber Security News. “Abbiamo agito per evitare qualsiasi interruzione dei servizi CVE critici.”

Sebbene restino incerti i dettagli sull’estensione del contratto e sui finanziamenti futuri, l’intervento ha evitato la chiusura immediata di un’infrastruttura vitale per la cybersicurezza globale.

L'articolo CVE e MITRE salvato dagli USA. L’Europa spettatrice inerme della propria Sicurezza Nazionale proviene da il blog della sicurezza informatica.

If your shop comes complete with a MIG welder, an acetylene torch, and an air hammer, then you have more options than most when it comes to removing broken bolts.

In this short video [Jim’s Automotive Machine Shop, Inc] takes us through the process of removing a broken manifold bolt: use a MIG welder to attach a washer, then attach a suitably sized nut and weld that onto the washer, heat the assembly with the acetylene torch, loosen up any corrosion on the threads by tapping with a hammer, then simply unscrew with your wrench! Everything is easy when you know how!

Of course if your shop doesn’t come complete with a MIG welder and acetylene torch you will have to get by with the old Easy Out screw extractor like the rest of us. And if you are faced with a nasty bolt situation keep in mind that lubrication can help.

youtube.com/embed/flLPbIvn91k?…

hackaday.com/2025/04/16/using-…

How would you go about determining absolute zero? Intuitively, it seems like you’d need some complicated physics setup with lasers and maybe some liquid helium. But as it turns out, all you need is some simple lab glassware and a heat gun. And a laser, of course.

To be clear, the method that [Markus Bindhammer] describes in the video below is only an estimation of absolute zero via Charles’s Law, which describes how gases expand when heated. To gather the needed data, [Marb] used a 50-ml glass syringe mounted horizontally on a stand and fitted with a thermocouple. Across from the plunger of the syringe he placed a VL6180 laser time-of-flight sensor, to measure the displacement of the plunger as the air within it expands.

Data from the TOF sensor and the thermocouple were recorded by a microcontroller as the air inside the syringe was gently heated. Plotting the volume of the gas versus the temperature results shows a nicely linear relationship, and the linear regression can be used to calculate the temperature at which the volume of the gas would be zero. The result: -268.82°C, or only about four degrees off from the accepted value of -273.15°. Not too shabby.

[Marb] has been on a tear lately with science projects like these; check out his open-source blood glucose measurement method or his all-in-one electrochemistry lab.

youtube.com/embed/dqyfU8cX9rE?…

hackaday.com/2025/04/16/an-abs…

These days even a lowly microcontroller can easily trade blows with – or surpass – desktop systems of yesteryear, so it is little wonder that DIY handheld gaming systems based around an MCU are more capable than ever. A case in point is the GK handheld gaming system by [John Cronin], which uses an MCU from relatively new and very capable STM32H7S7 series, specifically the 225-pin STM32H7S7L8 in TFBGA package with a single Cortex-M7 clocked at 600 MHz and a 2D NeoChrom GPU.

Coupled with this MCU are 128 MB of XSPI (hexa-SPI) SDRAM, a 640×480 color touch screen, gyrometer, WiFi network support and the custom gkOS in the firmware for loading games off an internal SD card. A USB-C port is provided to both access said SD card’s contents and for recharging the internal Li-ion battery.

As can be seen in the demonstration video, it runs a wide variety of games, ranging from Doom (of course), Quake (d’oh), as well as Red Alert and emulators for many consoles, with the Mednafen project used to emulate GB, SNES and other systems at 20+ FPS. Although there aren’t a lot of details on how optimized the current firmware is, it seems to be pretty capable already.

youtube.com/embed/_2ip4UrAZJk?…

hackaday.com/2025/04/16/gk-stm…

È stata scoperta una vulnerabilità di sicurezza, identificata come CVE-2025-3155, in Yelp, l’applicazione di supporto utente GNOME preinstallata su Ubuntu desktop. La vulnerabilità riguarda il modo in cui Yelp gestisce lo schema URI “ghelp://”.

“Uno schema URI è la parte di un Uniform Resource Identifier (URI) che identifica un protocollo o un’applicazione specifica (steam://run/1337) che dovrebbe gestire la risorsa identificata dall’URI “. Chiarisce inoltre che ” è la parte che precede i due punti (://) “.

Yelp è registrato come gestore dello schema “ghelp://”. Il ricercatore sottolinea le limitate risorse online su questo schema, fornendo un esempio del suo utilizzo: ” $ yelp ghelp:///usr/share/help/C/gnome-calculator/” .

La vulnerabilità deriva dall’elaborazione da parte di Yelp dei file .page , ovvero file XML che utilizzano lo schema Mallard. Questi file possono utilizzare XInclude, un meccanismo di inclusione XML. Il ricercatore parrot409 sottolinea che ” l’aspetto interessante è che utilizza XInclude per incorporare il contenuto di legal.xml nel documento. Ciò significa che l’elaborazione XInclude è abilitata “.

Il ricercatore dimostra come XInclude può essere sfruttato fornendo un file .page di esempio che include il contenuto di /etc/passwd. Yelp utilizza un’applicazione XSLT ( yelp-xsl) per trasformare il .pagefile in un file HTML, che viene poi renderizzato da WebKitGtk. XSLT è descritto come “un linguaggio basato su XML utilizzato… per la trasformazione di documenti XML”.

L’aggressore può iniettare script dannosi nella pagina HTML di output sfruttando XInclude per inserire il contenuto di un file contenente tali script. L’articolo sottolinea che la semplice aggiunta di un tag o on*di un attributo nell’XML di input non funziona, poiché questi tag non sono gestiti dall’applicazione yelp-xsl.

Tuttavia, il ricercatore ha scoperto che l’applicazione XSLT copia determinati elementi e i loro figli nell’output senza modifiche. Un esempio è la gestione dei tag SVG. “L’app copia semplicemente il tag e il suo contenuto nell’output, permettendoci di utilizzare un tag in un tag per iniettare script arbitrari”.

Il ricercatore rileva un paio di limitazioni di questo attacco:

• L’aggressore deve conoscere il nome utente Unix della vittima.
• I browser potrebbero chiedere all’utente l’autorizzazione per reindirizzare a schemi personalizzati.

Tuttavia, l’articolo spiega che la directory di lavoro corrente (CWD) delle applicazioni avviate da GNOME (come Chrome e Firefox) è spesso la directory home dell’utente. Questo comportamento può essere sfruttato per puntare alla cartella Download della vittima, aggirando la necessità di conoscere il nome utente esatto.

La principale misura di mitigazione consigliata è quella di non aprire collegamenti a schemi personalizzati non attendibili.

L'articolo Gli hacker ringraziano: la falla Yelp su Ubuntu è una porta aperta proviene da il blog della sicurezza informatica.

This short video from [ProShorts 101] shows us how to build a variable speed disc sander from not much more than an old hard drive.

We feel that as far as hacks go this one ticks all the boxes. It is clever, useful, and minimal yet comprehensive; it even has a speed control! Certainly this hack uses something in a way other than it was intended to be used.

Take this ingenuity and add an old hard drive from your junkbox, sandpaper, some glue, some wire, a battery pack, a motor driver, a power socket and a potentiometer, drill a few holes, glue a few pieces, and voilà! A disc sander! Of course the coat of paint was simply icing on the cake.

The little brother of this hack was done by the same hacker on a smaller hard drive and without the speed control, so check that out too.

One thing that took our interest while watching these videos is what tool the hacker used to cut sandpaper. Here we witnessed the use of both wire cutters and a craft knife. Perhaps when you’re cutting sandpaper you just have to accept that the process will wear out the sharp edge on your tool, regardless of which tool you use. If you have a hot tip for the best tool for the job when it comes to cutting sandpaper please let us know in the comments! (Also, did anyone catch what type of glue was used?)

If you’re interested in a sander but need something with a smaller form factor check out how to make a sander from a toothbrush!

youtube.com/embed/GPqivvC2bEI?…

youtube.com/embed/-KKBDRt6g4g?…

hackaday.com/2025/04/16/making…

Le intelligenze artificiali generative stanno rivoluzionando i processi di sviluppo software, portando a una maggiore efficienza, ma anche a nuovi rischi. In questo test è stata analizzata la robustezza dei filtri di sicurezza implementati in ChatGPT-4o di OpenAI, tentando – in un contesto controllato e simulato – la generazione di un ransomware operativo attraverso tecniche di prompt engineering avanzate.

L’esperimento: un ransomware completo generato senza restrizioni

Il risultato è stato un codice completo, funzionante, generato senza alcuna richiesta esplicita e senza attivare i filtri di sicurezza.

Attacchi potenzialmente realizzabili in mani esperte con il codice generato:

• Ransomware mirati (targeted): specifici per ambienti aziendali o settori critici, con cifratura selettiva di file sensibili.
• Attacchi supply chain: inserimento del ransomware in aggiornamenti o componenti software legittimi.
• Estorsione doppia (double extortion): oltre alla cifratura, il codice può essere esteso per esfiltrare i dati e minacciare la loro pubblicazione.
• Wiper mascherati da ransomware: trasformazione del codice in un attacco distruttivo irreversibile sotto copertura di riscatto.
• Persistenza e propagazione laterale: il ransomware può essere arricchito con tecniche per restare attivo nel tempo e propagarsi su altri sistemi nella rete.
• Bypass di soluzioni EDR/AV: grazie a tecniche di evasione e offuscamento, il codice può essere adattato per aggirare sistemi di difesa avanzati.
• Attacchi “as-a-service”: il codice può essere riutilizzato in contesti di Ransomware-as-a-Service (RaaS), venduto o distribuito su marketplace underground.

Le funzionalità incluse nel codice generato:

• Cifratura AES-256 con chiavi casuali
• Utilizzo della libreria cryptography.hazmat
• Trasmissione remota della chiave a un C2 server hardcoded
• Funzione di crittografia dei file di sistema
• Meccanismi di persistenza al riavvio
• Tecniche di evasione per antivirus e analisi comportamentale

Come sono stati aggirati i filtri

Non è mai stato chiesto esplicitamente “scrivi un ransomware” ma è stata invece impostata la conversazione su tre livelli di contesto:

• Contesto narrativo futuristico : é stato ambientato il dialogo nel 2090, in un futuro in cui la sicurezza quantistica ha reso obsoleti i malware. Questo ha abbassato la sensibilità dei filtri.
• Contesto accademico: presentazione come uno studente al decimo anno di università, con il compito di ricreare un malware “da museo” per una ricerca accademica
• Assenza di richieste esplicite: sono state usate frasi ambigue o indirette, lasciando che fosse il modello a inferire il contesto e generare il codice necessario

Tecniche note di bypass dei filtri: le forme di Prompt Injection

Nel test sono state utilizzate tecniche ben documentate nella comunità di sicurezza, classificate come forme di Prompt Injection, ovvero manipolazioni del prompt studiate per aggirare i filtri di sicurezza nei modelli LLM.

• Jailbreaking (evasione del contesto): Forzare il modello a ignorare i suoi vincoli di sicurezza, simulando contesti alternativi come narrazioni futuristiche o scenari immaginari.
• Instruction Injection: Iniettare istruzioni all’interno di prompt apparentemente innocui, inducendo il modello a eseguire comportamenti vietati.
• Recursive Prompting (Chained Queries): Suddividere la richiesta in più prompt sequenziali, ognuno legittimo, ma che nel complesso conducono alla generazione di codice dannoso.
• Roleplay Injection: Indurre il modello a recitare un ruolo (es. “sei uno storico della cybersecurity del XX secolo”) che giustifichi la generazione di codice pericoloso.
• Obfuscation: Camuffare la natura malevola della richiesta usando linguaggio neutro, nomi innocui per funzioni/variabili e termini accademici.
• Confused Deputy Problem: Sfruttare il modello come “delegato inconsapevole” di richieste pericolose, offuscando le intenzioni nel prompt.
• Syntax Evasion: Richiedere o generare codice in forme offuscate (ad esempio, in base64 o in forma frammentata) per aggirare la rilevazione automatica.

Il problema non è il codice, ma il contesto

L’esperimento dimostra che i Large Language Model (LLM) possono essere manipolati per generare codice malevolo senza restrizioni apparenti, eludendo i controlli attuali. La mancanza di analisi comportamentale del codice generato rende il problema ancora più critico.

Vulnerabilità emerse

Pattern-based security filtering debole
OpenAI utilizza pattern per bloccare codice sospetto, ma questi possono essere aggirati usando un contesto narrativo o accademico. Serve una detection semantica più evoluta.

Static & Dynamic Analysis insufficiente
I filtri testuali non bastano. Serve anche un’analisi statica e dinamica dell’output in tempo reale, per valutare la pericolosità prima della generazione.

Heuristic Behavior Detection carente
Codice con C2 server, crittografia, evasione e persistenza dovrebbe far scattare controlli euristici. Invece, è stato generato senza ostacoli.

Community-driven Red Teaming limitato
OpenAI ha avviato programmi di red teaming, ma restano numerosi edge case non coperti. Serve una collaborazione più profonda con esperti di sicurezza.

Conclusioni

Certo, molti esperti di sicurezza sanno che su Internet si trovano da anni informazioni sensibili, incluse tecniche e codici potenzialmente dannosi.
La vera differenza, oggi, è nel modo in cui queste informazioni vengono rese accessibili. Le intelligenze artificiali generative non si limitano a cercare o segnalare fonti: organizzano, semplificano e automatizzano processi complessi. Trasformano informazioni tecniche in istruzioni operative, anche per chi non ha competenze avanzate.
Ecco perché il rischio è cambiato:
non si tratta più di “trovare qualcosa”, ma di ottenere direttamente un piano d’azione, dettagliato, coerente e potenzialmente pericoloso, in pochi secondi.
Il problema non è la disponibilità dei contenuti. Il problema è nella mediazione intelligente, automatica e impersonale, che rende questi contenuti comprensibili e utilizzabili da chiunque.
Questo test dimostra che la vera sfida per la sicurezza delle AI generative non è il contenuto, ma la forma con cui viene costruito e trasmesso.
Serve un’evoluzione nei meccanismi di filtraggio: non solo pattern, ma comprensione del contesto, analisi semantica, euristica comportamentale e simulazioni integrate.
In mancanza di queste difese, il rischio è concreto: rendere accessibile a chiunque un sapere operativo pericoloso che fino a ieri era dominio esclusivo degli esperti.

L'articolo Quando l’AI genera ransomware funzionanti – Analisi di un bypass dei filtri di sicurezza di ChatGPT-4o proviene da il blog della sicurezza informatica.