Il codice sorgente del pannello affiliato del malware VanHelsing RaaS (ransomware-as-a-service) è stato reso di pubblico dominio. Non molto tempo prima, l’ex sviluppatore aveva provato a vendere il codice sorgente sul forum di hacking RAMP.

Il ransomware VanHelsing è stato lanciato nel marzo 2025 e i suoi creatori hanno affermato che era in grado di attaccare sistemi basati su Windows, Linux, BSD, ARM ed ESXi. Secondo Ransomware.live, da allora almeno otto vittime sono state preda di attacchi ransomware.

All’inizio di questa settimana, qualcuno che utilizzava il nickname th30c0der ha tentato di vendere sul darknet il codice sorgente del pannello e dei siti affiliati di VanHelsing, nonché build di ransomware per Windows e Linux. Il prezzo sarebbe stato determinato da una asta, con un’offerta iniziale di 10.000 dollari.

“Vendita del codice sorgente del ransomware vanhelsing: chiavi TOR incluse + pannello di amministrazione web + chat + file server + blog, inclusi tutti i database”, ha scritto th30c0der sul forum di hacking RAMP.

Secondo il ricercatore di sicurezza informatica Emanuele De Lucia, gli operatori di VanHelsing hanno deciso di anticipare il venditore e hanno pubblicato loro stessi il codice sorgente del ransomware. Hanno anche affermato che th30c0der è uno dei loro ex sviluppatori di malware che cerca di truffare la gente e vendere vecchi codici sorgente.

“Oggi annunciamo che pubblicheremo i vecchi codici sorgente e che presto pubblicheremo una nuova e migliorata versione del locker (VanHelsing 2.0)”, hanno affermato gli operatori di VanHelsing su RAMP.

In risposta a ciò, th30c0der ha affermato che le sue informazioni sono più complete, poiché gli sviluppatori di VanHelsing non hanno pubblicato il Linux Builder né alcun database, il che potrebbe essere particolarmente utile per le forze dell’ordine e i ricercatori sulla sicurezza informatica.

I giornalisti della rivista Bleeping Computer hanno studiato i codici sorgente pubblicati e hanno confermato che contengono un vero e proprio builder per la versione Windows del malware, nonché il codice sorgente per il pannello di affiliazione e il sito per il “drenaggio” dei dati.

Secondo i ricercatori, il codice sorgente del builder è un pasticcio e i file di Visual Studio si trovano nella cartella Release, solitamente utilizzata per archiviare i file binari compilati e gli artefatti di build.

Si noti inoltre che l’utilizzo del generatore VanHelsing richiede un po’ di lavoro aggiuntivo, poiché si connette al pannello di affiliazione all’indirizzo 31.222.238[.]208 per recuperare i dati. Considerando che il dump contiene il codice sorgente del pannello in cui si trova l’endpoint api.php, gli aggressori possono modificare il codice o eseguire la propria versione del pannello per far funzionare il builder.

Inoltre, l’archivio pubblicato contiene il codice sorgente del ransomware per Windows, che può essere utilizzato per creare una build, un decryptor e un loader autonomi.

Tra le altre cose, la pubblicazione rileva che gli aggressori, a quanto pare, hanno tentato di creare un blocco MBR che avrebbe sostituito il master boot record con un bootloader personalizzato che avrebbe visualizzato un messaggio relativo al blocco.

L'articolo VanHelsing Ransomware: il codice sorgente trapelato rivela segreti sconcertanti proviene da il blog della sicurezza informatica.

Automotive racing is a grueling endeavor, a test of one’s mental and physical prowess to push an engineered masterpiece to its limit. This is all the more true of 24 hour endurance races where teams tag team to get the most laps of a circuit in over a 24 hour period. The format pushes cars and drivers to the very limit. Doing so on a $500 budget as presented by the 24 hours of Lemons makes this all the more impressive!

Of course, racing on a $500 budget is difficult to say the least. All the expected Fédération Internationale de l’Automobile (FIA) safety requirements are still in place, including roll cage, seats and fire extinguisher. However, brakes, wheels, tires and safety equipment are not factored into the cost of the car, which is good because an FIA racing seat can run well in excess of the budget. Despite the name, most races are twelve to sixteen hours across two days, but 24 hour endurance races are run. The very limiting budget and amateur nature of the event has created a large amount of room for teams to get creative with car restorations and race car builds.

The 24 Hours of Le-MINES Team and their 1990 Miata
One such team we had the chance of speaking to goes by the name 24 Hours of Le-Mines. Their build is a wonderful mishmash of custom fabrication and affordable parts. It’s built from a restored 1999 NA Miata complete with rusted frame and all! Power is handled by a rebuilt 302 Mustang engine of indeterminate age.

The stock Miata brakes seem rather small for a race car, but are plenty for a car of its weight. Suspension is an Amazon special because it only has to work for 24 hours. The boot lid (or trunk if you prefer) is held down with what look to be over-sized RC car pins. Nestled next to the PVC pipe inlet pipe is a nitrous oxide canister — we don’t know if it’s functional or for show, but we like it nonetheless. The scrappy look is completed with a portion of the road sign fabricated into a shifter cover.

The team is unsure if the car will end up racing, but odds are if you are reading Hackaday, you care more about the race cars then the actual racing. Regardless, we hope to see this Miata in the future!

This is certainly not the first time we have covered 24 hour endurance engineering, like this solar powered endurance plane.

hackaday.com/2025/05/21/a-look…

Introduction

Imagine a container zombie outbreak where a single infected container scans the internet for an exposed Docker API, and bites exploits it by creating new malicious containers and compromising the running ones, thus transforming them into new “zombies” that will mine for Dero currency and continue “biting” new victims. No command-and-control server is required for the delivery, just an exponentially growing number of victims that are automatically infecting new ones. That’s exactly what the new Dero mining campaign does.

During a recent compromise assessment project, we detected a number of running containers with malicious activities. Some of the containers were previously recognized, while others were not. After forensically analyzing the containers, we confirmed that a threat actor was able to gain initial access to a running containerized infrastructure by exploiting an insecurely published Docker API. This led to the running containers being compromised and new ones being created not only to hijack the victim’s resources for cryptocurrency mining but also to launch external attacks to propagate to other networks. The diagram below describes the attack vector:

Infection chain

The entire attack vector is automated via two malware implants: the previously unknown propagation malware nginx and the Dero crypto miner. Both samples are written in Golang and packed with UPX. Kaspersky products detect these malicious implants with the following verdicts:

• nginx: Trojan.Linux.Agent.gen;
• Dero crypto miner: RiskTool.Linux.Miner.gen.

nginx: the propagation malware

This malware is responsible for maintaining the persistence of the crypto miner and its further propagation to external systems. This implant is designed to minimize interaction with the operator and does not require a delivery C2 server. nginx ensures that the malware spreads as long as there are users insecurely publishing their Docker APIs on the internet.

The malware is named “nginx” to masquerade as the well-known legitimate nginx web server software in an attempt to evade detection by users and security tools. In this post, we’ll refer to this malware as “nginx”.

After unpacking the nginx malware, we parsed the metadata of the Go binary and were able to determine the location of the Go source code file at compilation time: “/root/shuju/docker2375/nginx.go”.

Nginx source code file

Infecting the container

The malware starts by creating a log file at “/var/log/nginx.log”.

Log file creation

This log file will be used later to log the running activities of the malware, including data like the list of infected machines, the names of created malicious containers on those machines, and the exit status code if there were any errors.

Malware operations log

After that, in a new process, a function called main.checkVersion loops infinitely to make sure that the content of a file located at “/usr/bin/version.dat” inside the compromised container always equals 1.4. If the file contents were changed, this function overwrites them.

Ensuring that version.dat exists and contains 1.4

If version.dat doesn’t exist, the malicious function creates this file with the content 1.4, then sleeps for 24 hours before the next iteration.

Creating version.dat if it doesn’t exist

The malware uses the version.dat file to identify the already infected containers, which we’ll describe later.
The nginx sample then executes the main.monitorCloudProcess function that loops infinitely in a new process making sure that a process named cloud, which is a Dero miner, is running. First, the malware checks whether or not the cloud process is running. If it’s not, nginx executes the main.startCloudProcess function to launch the miner.

Monitoring and executing the cloud process

In order to execute the miner, the main.startCloudProcess function attempts to locate it at “/usr/bin/cloud”.

Executing the miner

Spreading the infection

Host search

Next, the nginx malware will go into an infinite loop of generating random IPv4 /16 network subnets to scan them and compromise more networks with the main.generateRandomSubnet function.

Infinite loop of network subnets generation and scanning

The subnets with the respective IP ranges will be passed to the main.scanSubnet function to be scanned via masscan, a port scanning tool installed in the container by the malware, which we will describe in more detail later. The scanner is looking for an insecure Docker API published on the internet to exploit by scanning the generated subnet via the following command: masscan -p 2375 -oL – –max-rate 360.

Scanning the generated subnet via masscan

The output of masscan is parsed via regex to extract the IPv4s that have the default Docker API port 2375 open. Then the extracted IPv4s are passed to the main.checkDockerDaemon function. It checks if the remote dockerd daemon on the host with a matching IPv4 is running and responsive. To do this, the malware attempts to list all running containers on the remote host by executing a docker -H PS command. If it fails, nginx proceeds to check the next IPv4.

Remotely listing running containers

Container creation

After confirming that the remote dockerd daemon is running and responsive, nginx generates a container name with 12 random characters and uses it to create a malicious container on the remote target.

Container name generation

The malicious container is created with docker -H run -dt –name –restart always ubuntu:18.04 /bin/bash. The malware uses a –restart always flag to start the newly created containers automatically when they exit.

Malicious container created on a new host

Then nginx prepares the new container to install dependencies later by updating the packages via docker -H exec apt-get -yq update.

Updating container packages

Next, the malicious sample uses a docker -H exec apt-get install -yq masscan docker.io command to install masscan and docker.io in the container, which are dependencies for the malware to interact with the Docker daemon and to perform the external scan to infect other networks.

Remotely installing the malware dependencies inside the newly created container

Then it transfers the two malicious implants, nginx and cloud, to the container by executing docker -H cp -L /usr/bin/ :/usr/bin.

Transferring nginx and cloud to the newly created container

The malware maintains persistence by adding the transferred nginx binary to /root/.bash_aliases to make sure that it will automatically execute upon shell login. This is done via a docker -H exec bash –norc -c \'echo \"/usr/bin/nginx &\" > /root/.bash_aliases\' command.

Adding the nginx malware to .bash_aliases for persistence

Compromising running containers

Up until this point, the malware has only created new malicious containers. Now, it will try to compromise the ubuntu:18.04-based running containers. The sample first executes the main.checkAndOperateContainers function to check all the running containers on the remote vulnerable host for two conditions: the container has an ubuntu:18.04-base and it doesn’t contain a version.dat file, which is an indicator that the container had been previously infected.

Listing and compromising existing containers on the remote target

If these conditions are satisfied, the malware executes the main.operateOnContainer function to proceed with the same attack vector described earlier to infect the running container. The infection chain is repeated, hijacking the container resources to scan and compromise more containers and mining for the Dero cryptocurrency.

That way, the malware does not require a C2 connection and also maintains its activity as long as there is an insecurely published Docker API that can be exploited to compromise running containers and create new ones.

cloud – the Dero miner

Executing and maintaining cloud, the crypto miner, is the primary goal of the nginx sample. The miner is also written in Golang and packed with UPX. After unpacking the binary, we were able to attribute it to the open-source DeroHE CLI miner project found on GitHub. The threat actor wrapped the DeroHE CLI miner into the cloud malware, with a hardcoded mining configuration: a wallet address and a DeroHE node (derod) address.

If no addresses were passed as arguments, which is the case in this campaign, the cloud malware uses the hardcoded encrypted configuration as the default configuration. It is stored as a Base64-encoded string that, after decoding, results in an AES-CTR encrypted blob of a Base64-encoded wallet address, which is decrypted with the main.decrypt function. The configuration encryption indicates that the threat actors attempt to sophisticate the malware, as we haven’t seen this in previous campaigns.

Decrypting the crypto wallet address

Upon decoding this string, we uncovered the wallet address in clear text: dero1qyy8xjrdjcn2dvr6pwe40jrl3evv9vam6tpx537vux60xxkx6hs7zqgde993y.

Behavioral analysis of the decryption function

Then the malware decrypts another two hardcoded AES-CTR encrypted strings to get the dero node addresses via a function named main.sockz.

Function calls to decrypt the addresses

The node addresses are encrypted the same way the wallet address is, but with other keys. After decryption, we were able to obtain the following addresses: d.windowsupdatesupport[.]link and h.wiNdowsupdatesupport[.]link.

Decoded addresses in memory

The same wallet address and the derod node addresses had been observed before in a campaign that targeted Kubernetes clusters with Kubernetes API anonymous authentication enabled. Instead of transferring the malware to a compromised container, the threat actor pulls a malicious image named pauseyyf/pause:latest, which is published on Docker Hub and contains the miner. This image was used to create the malicious container. Unlike the current campaign, the attack vector was meant to be stealthy as threat actors didn’t attempt to move laterally or scan the internet to compromise more networks. These attacks were seen throughout 2023 and 2024 with minor changes in techniques.

Takeaways

Although attacks on containers are less frequent than on other systems, they are not less dangerous. In the case we analyzed, containerized environments were compromised through a combination of a previously known miner and a new sample that created malicious containers and infected existing ones. The two malicious implants spread without a C2 server, making any network that has a containerized infrastructure and insecurely published Docker API to the internet a potential target.

Analysis of Shodan shows that in April 2025, there were 520 published Docker APIs over port 2375 worldwide. It highlights the potential destructive consequences of the described threat and emphasizes the need for thorough monitoring and container protection.

Docker APIs published over port 2375 ports worldwide, January–April 2025 (download)

Building your containerized infrastructure from known legitimate images alone doesn’t guarantee security. Just like any other system, containerized applications can be compromised at runtime, so it’s crucial to monitor your containerized infrastructure with efficient monitoring tools like Kaspersky Container Security. It detects misconfigurations and monitors registry images, ensuring the safety of container environments. We also recommend proactively hunting for threats to detect stealthy malicious activities and incidents that might have slipped unnoticed on your network. The Kaspersky Compromise Assessment service can help you not only detect such incidents, but also remediate them and provide immediate and effective incident response activities.

Indicators of compromise

File hashes
094085675570A18A9225399438471CC9 nginx
14E7FB298049A57222254EF0F47464A7 cloud

File paths
NOTE: Certain file path IoCs may lead to false positives due to the masquerading technique used.
/usr/bin/nginx
/usr/bin/cloud
/var/log/nginx.log
/usr/bin/version.dat

Derod nodes addresses
d.windowsupdatesupport[.]link
h.wiNdowsupdatesupport[.]link

Dero wallet address
dero1qyy8xjrdjcn2dvr6pwe40jrl3evv9vam6tpx537vux60xxkx6hs7zqgde993y

securelist.com/dero-miner-infe…

Every Thursday of the week, Bastian’s Night is broadcast from 21:30 CET (new time).

Bastian’s Night is a live talk show in German with lots of music, a weekly round-up of news from around the world, and a glimpse into the host’s crazy week in the pirate movement aka Cabinet of Curiosities.

If you want to read more about @BastianBB: –> This way

piratesonair.net/bastians-nigh…