Salta al contenuto principale

Microsoft acquisisce il 27% di OpenAI per 135 miliardi di dollari


Dopo quasi un anno di trattative con il suo storico sostenitore Microsoft, OpenAI ha concesso a quest’ultima una quota del 27%. Questa mossa elimina una significativa incertezza per entrambe le aziende e apre la strada alla trasformazione dello sviluppatore di ChatGPT in un’impresa a scopo di lucro.

In una dichiarazione rilasciata martedì, entrambe le società hanno affermato che, in base all’accordo rivisto, Microsoft acquisirà circa 135 miliardi di dollari di azioni di OpenAI. Inoltre, Microsoft avrà accesso alla tecnologia della startup di intelligenza artificiale (IA) fino al 2032, compresi i modelli che hanno già raggiunto il benchmark per l’intelligenza artificiale generale (AGI).

OpenAI ha trascorso gran parte di quest’anno spingendo per la ristrutturazione, trasformandosi in un’azienda più tradizionale a scopo di lucro; Microsoft, che ha investito circa 13,75 miliardi di dollari, è stata il più grande ostacolo tra gli investitori di OpenAI.

“OpenAI ha completato una ristrutturazione del capitale e semplificato la sua struttura aziendale”, ha dichiarato il presidente di OpenAI, Bret Taylor, in una nota. “L’organizzazione no-profit controlla ancora l’entità a scopo di lucro, garantendole accesso diretto alle risorse critiche prima dell’arrivo di AGI”.

Nell’ambito della ristrutturazione, l’ente no-profit di OpenAI, la OpenAI Foundation, riceverà anche un capitale di circa 130 miliardi di dollari. La fondazione prevede di concentrarsi inizialmente sul finanziamento di progetti come “l’accelerazione delle innovazioni in campo sanitario”.

OpenAI ha dichiarato che il suo co-fondatore e CEO, Sam Altman, non riceverà alcuna partecipazione azionaria nella società recentemente ristrutturata.

Martedì, le azioni Microsoft sono salite fino al 4,2%, raggiungendo i 553,72 dollari. Molti analisti di Wall Street ritengono che il cambiamento del rapporto con OpenAI abbia rappresentato in passato una fonte importante di incertezza per l’azienda produttrice di software.

L’analista di ricerca di settore Anurag Rana ha affermato che il mantenimento da parte di Microsoft dei diritti di proprietà intellettuale sui prodotti e sui modelli OpenAI fino al 2032 è “il punto più importante” dell’accordo rivisto. “Microsoft sta sviluppando i propri modelli, utilizzando al contempo i modelli OpenAI o Anthropic nel suo prodotto Copilot”.

Un punto cruciale nei negoziati durati mesi tra Microsoft e OpenAI è stato cosa sarebbe successo dopo che OpenAI avesse raggiunto l’AGI (Intelligenza Artificiale Generale), ovvero un’intelligenza artificiale che supera le capacità umane nella maggior parte dei compiti. In base al nuovo accordo, questa soglia deve essere verificata da un “gruppo indipendente di esperti” e, una volta raggiunta, Microsoft non riceverà più alcuna quota dei ricavi di OpenAI.

Azure è stato a lungo il fornitore esclusivo di OpenAI, ma in seguito Microsoft gli ha consentito di acquistare servizi da altri fornitori come Oracle, pur mantenendo il diritto di prelazione di Microsoft . OpenAI investirà altri 250 miliardi di dollari in Azure.

Entrambe le parti hanno dichiarato che i diritti di Microsoft sull’utilizzo della tecnologia OpenAI non includeranno l’hardware consumer. OpenAI avrà anche la possibilità di “sviluppare congiuntamente alcuni prodotti con terze parti”.

L'articolo Microsoft acquisisce il 27% di OpenAI per 135 miliardi di dollari proviene da Red Hot Cyber.


Se ricevi una mail che dice che sei morto… è il nuovo phishing contro LastPass


Gli sviluppatori del gestore di password LastPass hanno avvisato gli utenti di una campagna di phishing su larga scala iniziata a metà ottobre 2025. Gli aggressori stanno inviando e-mail contenenti false richieste di accesso di emergenza al vault delle password, correlate alla morte degli utenti.

Secondo gli esperti, dietro questa campagna c’è il gruppo di hacker CryptoChameleon (noto anche come UNC5356), motivato finanziariamente. Il gruppo è specializzato nel furto di criptovalute e ha già attaccato gli utenti di LastPass nell’aprile 2024.

La nuova campagna si è rivelata estesa e tecnologicamente avanzata: gli aggressori ora sono a caccia non solo delle password principali, ma anche delle passkey.

CryptoChameleon utilizza un kit di phishing specializzato che prende di mira i wallet di criptovalute di Binance, Coinbase, Kraken e Gemini. Nei suoi attacchi, il gruppo sfrutta attivamente pagine di accesso false per Okta, Gmail, iCloud e Outlook.

In una nuova campagna, i truffatori stanno abusando della funzionalità di accesso di emergenza di LastPass. Il gestore di password dispone di un meccanismo di successione che consente ai contatti fidati di richiedere l’accesso al caveau in caso di decesso o incapacità del proprietario dell’account.

Al ricevimento di tale richiesta, il proprietario dell’account viene avvisato e, se non annulla la richiesta entro un periodo di tempo specificato, l’accesso all’account viene concesso automaticamente.

Nelle loro e-mail, i phisher affermano che un familiare avrebbe richiesto l’accesso allo spazio di archiviazione della vittima caricando un certificato di morte. Per rendere il messaggio più convincente, è incluso un falso ID di richiesta. Il destinatario viene invitato ad annullare immediatamente la richiesta, se è ancora in vita, cliccando sul link fornito.

Naturalmente, tali link portano al sito fraudolento lastpassrecovery[.]com, dove alla vittima viene chiesto di inserire la propria password principale. I ricercatori hanno notato che in alcuni casi gli aggressori hanno addirittura chiamato le vittime, fingendosi dipendenti di LastPass, e le hanno convinte a inserire le proprie credenziali su un sito di phishing.

Una caratteristica distintiva di questa campagna è l’enfasi posta sul furto di passkey. A tal fine, gli aggressori utilizzano domini specializzati come mypasskey[.]info e passkeysetup[.]com.

Passkey è un moderno standard di autenticazione senza password basato sui protocolli FIDO2/WebAuthn. Invece delle password tradizionali, la tecnologia utilizza la crittografia asimmetrica. I moderni gestori di password (tra cui LastPass, 1Password, Dashlane e Bitwarden) possono memorizzare e sincronizzare le passkey su tutti i dispositivi. E, come dimostra l’esperienza, gli aggressori si sono rapidamente adattati a questi cambiamenti.

Si consiglia agli utenti di LastPass di rimanere vigili e prestare molta attenzione a qualsiasi email relativa a richieste di accesso di emergenza o di eredità. Gli sviluppatori ricordano agli utenti di controllare sempre gli URL prima di inserire le proprie credenziali e sottolineano inoltre che i rappresentanti di LastPass non chiameranno mai gli utenti chiedendo loro di inserire la password su alcun sito web.

L'articolo Se ricevi una mail che dice che sei morto… è il nuovo phishing contro LastPass proviene da Red Hot Cyber.


All Hail The OC71


Such are the breadth of functions delivered by integrated circuits, it’s now rare to see a simple small-signal transistor project on these pages. But if you delve back into the roots of solid state electronics you’ll find a host of clever ways to get the most from the most basic of active parts.\

Everyone was familiar with their part numbers and characteristics, and if you were an electronics enthusiast in Europe it’s likely there was one part above all others that made its way onto your bench. [ElectronicsNotes] takes a look at the OC71, probably the most common PNP germanium transistor on the side of the Atlantic this is being written on.

When this device was launched in 1953 the transistor itself had only been invented a few years earlier, so while its relatively modest specs look pedestrian by today’s standards they represented a leap ahead in performance at the time. He touches on the thermal runaway which could affect germanium devices, and talks about the use of black silicone filling to reduce light sensitivity.

The OC71 was old hat by the 1970s, but electronics books of the era hadn’t caught up. Thus many engineers born long after the device’s heyday retain a soft spot for it. We recently even featured a teardown of a dead one.

youtube.com/embed/BpxeOxuXjr0?…


hackaday.com/2025/10/29/all-ha…


POS vulnerabili: indagine sulla sicurezza hardware dei dispositivi di pagamento


I terminali di pagamento Worldline, ampiamente utilizzati in Svizzera, si sono dimostrati vulnerabili a un attacco che consente a chiunque di ottenere il controllo completo del dispositivo in un solo minuto. La vulnerabilità riguarda il modello Worldline Yomani XR, installato in supermercati, bar, officine e altri luoghi che accettano carte di credito.

Nonostante il suo aspetto apparentemente sicuro e il sofisticato design antivandalismo, il terminale consente l’accesso root senza password tramite la porta di servizio se un aggressore riesce ad accedervi fisicamente.

L’analisi ha rivelato un connettore per il debugger inutilizzato sul pannello posteriore del terminale, nascosto sotto un piccolo sportello.

Dopo aver collegato un cavo seriale standard e aver avviato il dispositivo, lo specialista ha osservato un avvio Linux standard. Il terminale esegue il kernel versione 3.6, compilato con Buildroot all’inizio del 2023, con utility BusyBox e librerie uClibc.

Al termine del processo di avvio, sulla console seriale appare un prompt di login. Digitando “root” si accede immediatamente alla shell di sistema senza alcuna autenticazione.

Il dispositivo è progettato fisicamente per un elevato livello di sicurezza. Utilizza un processore dual-core basato su architettura Arm, una scheda elettronica compatta e un sofisticato sistema di rilevamento delle manomissioni.

I tentativi di aprire la custodia o di perforare la scheda elettronica attivano meccanismi di sicurezza, tra cui un blocco permanente e una schermata rossa. Una batteria separata mantiene la protezione anche in caso di interruzione dell’alimentazione.

Tuttavia, la vulnerabilità identificata ha aggirato tutte queste misure: l’interfaccia di debug non era protetta. Ciò ha consentito l’accesso a un ambiente Linux non crittografato responsabile della rete e della logica aziendale. Un secondo ambiente, più sicuro, in esecuzione su un processore dedicato, controlla la tastiera, lo schermo e il lettore di schede e viene attivato solo quando vengono soddisfatte le condizioni di sicurezza.

Sebbene non possa essere controllato direttamente tramite la shell Linux, l’accesso al primo ambiente rappresenta comunque un rischio: può essere iniettato codice dannoso, il traffico di rete può essere intercettato o gli aggiornamenti di sistema possono essere interrotti.

Al momento della pubblicazione, non ci sono casi confermati di compromissione dei dati degli utenti a causa di questa vulnerabilità, ma gli esperti sottolineano la gravità del problema. Il fornitore di Worldline è stato informato e, secondo fonti aperte, il problema è già stato risolto nelle versioni successive del firmware.

Tuttavia, la vulnerabilità identificata indica un problema più ampio: difetti simili potrebbero essere riscontrati anche nei terminali di altri produttori. Le interfacce di servizio non protette, lasciate aperte per la diagnostica o la manutenzione, spesso diventano un punto debole anche in dispositivi progettati con cura. Pertanto, quando si progettano e implementano soluzioni di pagamento su larga scala, è importante considerare non solo la robustezza della crittografia e la protezione da atti vandalici, ma anche l’eliminazione di qualsiasi percorso di accesso non autorizzato, comprese le porte di debug e i connettori di test.

L'articolo POS vulnerabili: indagine sulla sicurezza hardware dei dispositivi di pagamento proviene da Red Hot Cyber.


Allarme malware: vulnerabilità critiche in plugin WordPress sfruttate attivamente


Wordfence lancia l’allarme su una campagna malware su larga scala in cui gli aggressori stanno sfruttando vulnerabilità critiche nei popolari plugin di WordPress GutenKit e Hunk Companion. L’azienda ha bloccato 8,7 milioni di tentativi di attacco di questo tipo contro i suoi clienti in soli due giorni.

Gli hacker stanno sfruttando tre vulnerabilità critiche (9,8 sulla scala CVSS): CVE-2024-9234, CVE-2024-9707 e CVE-2024-11972.

Tutte queste vulnerabilità consentono l’esecuzione di codice remoto su siti web vulnerabili.

La vulnerabilità CVE-2024-9234 riguarda il plugin GutenKit, che conta 40.000 installazioni attive. La vulnerabilità è correlata a un endpoint REST non autenticato e consente l’installazione di plugin arbitrari senza autenticazione. Il problema riguarda le versioni 2.1.0 e precedenti di GutenKit.

Le vulnerabilità CVE-2024-9707 e CVE-2024-11972 sono correlate alla mancanza di autorizzazione nell’endpoint REST themehunk-import del plugin Hunk Companion, installato circa 8.000 volte.

Queste vulnerabilità aprono anche la strada all’installazione di plugin arbitrari. La prima vulnerabilità riguarda le versioni 1.8.4 e precedenti del plugin, mentre la seconda riguarda la 1.8.5 e tutte le release precedenti.

Secondo quanto riferito, gli aggressori stanno sfruttando queste vulnerabilità per iniettare un altro plugin vulnerabile nei siti web, che consentirebbe loro di eseguire codice in remoto.

Le patch per tutti e tre i problemi sono disponibili da quasi un anno: GutenKit 2.1.1 è stato rilasciato nell’ottobre 2024 e Hunk Companion è stato aggiornato alla versione 1.9.0 nel dicembre dello stesso anno. Tuttavia, molti siti web utilizzano ancora versioni vulnerabili dei plugin, rendendoli facili bersagli.

Secondo Wordfence, gli aggressori ospitano un plugin dannoso su GitHub in un archivio ZIP denominato “up”. L’archivio contiene script offuscati per caricare, scaricare ed eliminare file, nonché per modificare i permessi di accesso. Uno degli script, protetto da password e camuffato da componente del plugin All in One SEO, effettua automaticamente l’accesso dell’aggressore come amministratore.

Questi strumenti danno agli aggressori il controllo completo: possono mantenere una presenza sul server, rubare o scaricare file, eseguire comandi e intercettare dati privati.

Se il percorso diretto tramite un plugin installato non funziona, gli aggressori spesso iniettano nei siti web un altro plugin vulnerabile, wp-query-console, che consente l’esecuzione del codice senza autenticazione.

Wordfence ha incluso nel suo rapporto un elenco di indirizzi IP che generano grandi volumi di richieste dannose. Inoltre, si consiglia di cercare nei log richieste sospette verso /wp-json/gutenkit/v1/install-active-plugine /wp-json/hc/v1/themehunk-import.

Vale anche la pena controllare le directory /up, /background-image-cropper, /ultra-seo-processor-wpe per individuare file sospetti /oke. /wp-query-console

L'articolo Allarme malware: vulnerabilità critiche in plugin WordPress sfruttate attivamente proviene da Red Hot Cyber.


DK 10x08 - Tre articoli


Le allucinazioni sono un problema intrinseco dei modelli linguistici, adattiamoci! Le allucinazioni possono essere limitate con abbastanza lavoro sui dati di training e sugli algoritmi! E comunque con 250 documenti truccati puoi far fare quello che vuoi a un modello da 13 miliardi di parametri! Ma che meraviglia, l'Intelligenza Artificiale...


spreaker.com/episode/dk-10x08-…


Nikon Small World Competition Announces 2025 Winners


The winning entry, a photo of a fly on a grain of rice.

They say that, sometimes, less is more. That would certainly apply to photomicrography, where you want to take pictures of tiny things. Nikon agrees, and they sponsor the Small World contest every year. The 2025 winners are a big — or not so big, maybe — deal.

This photomicrography competition dates back to 1975, so this is the 51st set of winners. First place went to [Zhang You] for his photograph of a rice weevil (sitophilus oryzae) on a grain of rice.

[You] is an entomologist from the Entomological Society of China. He says, “It pays to dive deep into entomology: understanding insects’ behaviors and mastering lighting, a standout work blends artistry with scientific rigor, capturing the very essence, energy, and spirit of these creatures.” We can’t argue with the results.

If you’re interested in Nikon and photography, you might also be interested in repairing a broken lens or a Nikon D3.


hackaday.com/2025/10/28/nikon-…


Web Development in… Pascal?


If you were asked to make an e-commerce website in 2025, what language would you reach for? Show of hands: JavaScript? Go? Pascal? Well, there was at least one taker for that last one: [jns], and he has an hour-long tutorial video showing you how he made it happen.

The site in question is the web store for his personal business, Photronic Arts, so you cannot say [jns] does not have skin in the game. From the front end, this is HTML and could be anything upto and including Shopify under the hood. It’s not, though: it’s a wholly custom backend [jns] put together in FreePascal, using the Lazarus IDE.

There’s a case to be made for Pascal in the modern day, but when we wrote that we weren’t expecting to get tips about web development. Ironically enough [jns] spends so much time giving the technical details in this video he doesn’t delve that deeply into why he chose FreePascal, especially when it’s clear he’s very familiar with C and C++. In his associated writeup on his Gopher page (link though Floodgap) [jns] simply declares it’s a language he’s quite fond of, which is reason enough of us. The source code is available, though on request, to avoid AI scraping. It’s a sad but understandable response to these modern times.

If you’re not into web development and want to see a deep-dive into how the backend works, this video is worth watching even if you don’t particularly care for Pascal. It’s also worth watching if you do know backend development, and are Pascal-curious. If neither of those things interest you, what about this Pascal Library for Arduino?

Thanks to [jns] for the tip! If you’re doing modern work with questionably-modern tools, we call that a hack and would love to hear from you.


hackaday.com/2025/10/28/web-de…


Testing Cheap DC Breakers and How to Not Start Fires


One characteristic of adding PV solar to homes is a massive increase in high-voltage and high-current DC installations. With this comes a need for suitable breakers, but without the requisite knowledge it can be easy to set up a fire hazard. There is also the issue of online shopping platforms making it easy to get fuses and breakers that may not be quite as capable as they claim, never mind being rated for DC use.

Recently [Will Prowse] had a poke at a range of common purportedly DC-rated breakers from everyone’s favorite US-based seller of tat, to see whether they should be bought or avoided at all cost. Perhaps unsurprisingly the cheap breakers are about as dodgy as you’d imagine. With a hundred plus amps flowing through them they get surprisingly crispy, even if they generally did their job. Minus the few that arrived in a broken condition, of course.

Ultimately [Will] found that the molded case circuit break (MCCB) by one ‘DIHOOL’ performed the best. Compared to the competition, it is much larger and has sizeable terminals that avoid the quaint heat-soaking issues seen with the cheap-and-cheerful rest. At a mere $34 for the 125A-rated version, it’s still a fraction of the cost of a comparable Eaton MCCB, but should upset your insurance company significantly less than the alternatives.

Don’t forget to add in fuses, with [Will] testing a range of cheapo 12V DC fuses, to see which one will prevent fires, and which one cause them. Unsurprisingly, some of them like the Bojack-branded ones ran very hot, making them more of a liability than an asset.

As for what makes DC breakers so different from AC one is that the extinguishing point of a DC arc is much steeper, which means that an AC breaker is likely to fail to extinguish the arc when used for DC applications. This is why a properly rated and ideally certified breaker is essential, and also not really the point where you want to start saving money.

youtube.com/embed/ufj_iJzFIEU?…

youtube.com/embed/7Fbga77ERtY?…


hackaday.com/2025/10/28/testin…


Original E39 Head Unit Modernized


Although most modern cars have moved to using proprietary components nearly everywhere, especially when it comes to infotainment systems, for a brief moment which peaked in the 90s and 00s most cars shipped with radios that fit in a standard size opening called a DIN slot. If you wanted a new Pioneer or Kenwood stereo it was usually a simple matter to slide the factory radio out and put your choice of aftermarket head unit in its place. [Stefan] has an E39 BMW from this era and wanted to upgrade the factory radio but use the original hardware instead of replacing it.

This isn’t just a simple stereo upgrade either. [Stefan] has gone all-out for this build which he started in 2020. Beginning with a Kotlin/Jetpack Compose Linux application to handle control input from the vehicle’s various knobs and buttons he moved on to a map application and an on-screen keyboard. From there he implemented VGA to send video to the OEM screen, and now has a fully functional system based on a Raspberry Pi. It does everything the original unit can do including playing music and showing the feed from the backup camera, plus adds plenty of new, modern features like Bluetooth.

For a certain classic car enthusiast, this build hits a sweet spot of modernizing a true classic like the E39 without removing or permanently modifying any OEM components. The amount of work that went into it is pretty staggering as well, with [Stephan] putting in over 100 hours of work just to get the video signal timing correct. We also like it because it reminds us of the flash-in-the-pan “carputer” trend from the late 00s where people in the pre-smartphone age were shoving all kinds of computing horsepower in their trunks.


hackaday.com/2025/10/28/origin…


2025 Component Abuse Challenge: A Bistable Flip-Flop With A Fuse


The flip-flop, in whichever of its several forms you encounter it, is a staple of logic design. Any time that you need to hold onto something, count, or shift bits, out it comes. We expect a flip-flop to be an integrated circuit if we use one, but most of us could knock one together with a couple of transistors.

You aren’t restricted to transistors of course, a relay will do just as well, but how about a fuse? [b.kainka] has made a functioning set/reset flip-flop using a pair of PTC self-resetting fuses.

The circuit is simplicity itself, a pair of incandescent bulbs in series, each in turn in parallel with a momentary action switch and a PTC fuse. On start-up both fuses are conducting, so one or other of them will do its job as a fuse and go high impedance. At that point its bulb will light and the other fuse will remain low impedance so its bulb will stay dark. Press the switch across the lit bulb for a few seconds however, and the circuit resets itself. The other fuse goes high impedance while the first fuse returns to low impedance, and the other bulb lights.

We’re not sure we can see much in the way of practical application for this circuit, but sometimes merely because you can is reason enough. It’s part of our 2025 Component Abuse Challenge, for which you just about still have time to make an entry yourself if you have one.

2025 Hackaday Component Abuse Challenge


hackaday.com/2025/10/28/2025-c…


Know Audio: Lossy Compression Algorithms And Distortion


In previous episodes of this long-running series looking at the world of high-quality audio, at every point we’ve stayed in the real world of physical audio hardware. From the human ear to the loudspeaker, from the DAC to measuring distortion, this is all stuff that can happen on your bench or in your Hi-Fi rack.

We’re now going for the first time to diverge from the practical world of hardware into the theoretical world of mathematics, as we consider a very contentious topic in the world of audio. We live in a world in which it is now normal for audio to have some form of digital compression applied to it, some of which has an effect on what is played back through our speakers and headphones. When a compression algorithm changes what we hear, it’s distortion in audio terms, but how much is it distorted and how do we even measure that? It’s time to dive in and play with some audio files.

How Good A Copy Does A Copy Have To Be?

A reel-to-reel recorder from the famous Abbey Road studio in London.Abbey Road’s tape recorders would have been about as good as it gets. Josephenus P. Riley, CC BY 2.0.
Were we to record some music with a good quality microphone and analogue tape recorder, we know that what came out of the speakers at playback would be a copy of what was heard by the microphone, subject to distortion from whatever non-linearities it has encountered in the audio path. But despite that distortion, the tape recorder is doing its best to faithfully record an exact copy of what it hears. It’s the same with a compression-free digital recording; record those musicians with a DAT machine or listen to them on a CD, and you’ll get back as good a copy as those media are capable of returning.

The trouble is that uncompressed audio takes up a lot of bandwidth, particularly when streaming over the Internet. Thus just as with any other data format, it makes sense to compress it such that it takes up less space. There are plenty of compression algorithms to choose from, but with analogue sources there are more choices than there are with text, or software. A Linux ISO has to uncompress as a perfect copy of its original otherwise it won’t run, while an image or an audio file simply has to uncompress to something that looks or sounds like the original to our meaty brains.

Those extra compression options for analogue data take advantage of this; they use so-called lossy compression in that what you get out sounds just like what you put in, but isn’t the same. This difference can be viewed as distortion, and if you have ever saved an image containing text as a JPEG file, you’ll probably have seen it as artifacts around sharply defined edges.

So if lossy compression algorithms such as MP3 introduce distortion, how can we measure this? The analogue distortion analyser featured in our last installment is of little use, because the pure sine wave it uses is very easy for the compression algorithm to encode faithfully. Compression based on Fourier analysis is always going to do a good job on a single frequency. Another solution is required, and here the Internet is of little help. It’s time to set out on my own and figure out a way to measure the distortion inherent to an MP3 file.

Math Will Give Us The Right Answer!

A GNU Radio project for my analyserGNU Radio is an extremely convenient way to perform these types of measurement.
At moments like these it’s great to be surrounded by other engineers, because you can mull it over and reach a solution. This distortion can’t be measured through my analogue instrumentation with a sine wave for the reasons discussed above, so it must instead be measured on a real world sample. We came up with a plan: measure the difference between two samples, compute the RMS value for that difference, then calculate the ratio between that and the RMS of the uncompressed sample.

As is so often the case with this type of task, it’s a relatively straightforward task using GNU Radio as a DSP workshop. I created a GNU Radio project to do the job, and fed it an uncompressed and compressed version of the same sample. I used a freely available recording of some bongo drums, and to make my compressed file I encoded it as a 128kbit MP3, then decoded it back to a WAV file. You can find it in my GitHub account, should you wish to play with it yourself.

Math Will Give Us The Wrong Answer!


The result it gives for my two bongo samples varies a little around 0.03, or 3%, depending upon where you are in the sample. What that in effect means is that the MP3 encoded version is around 3% different from the uncompressed one. If that were a figure measured on an analogue circuit using my trusty HP analyser I would say it wasn’t a very good quality circuit at all, and I would definitely be able to hear the distortion when listening to the audio. The fact that I can’t hear it raises a fundamental question as to what distortion really is, and the effect it has upon listeners.

What I would understand as distortion due to non-linearities in the audio path, is in reality harmonic distortion. Harmonics of the input signal are being created; if my audio path is a guitar pedal they are harmonics I want, while if it’s merely a very low quality piece of audio gear they’re unwelcome degradation of the listening experience. This MP3 file has a measurable 3% distortion, yet I am not hearing it as such when I listen. The answer to why that is the case is that this is not harmonic distortion, instead it’s a very similar version of the same sound, which differs by only 3% from the original. People with an acute ear can hear it, but most listeners will not notice the difference.

So In Summary: This Distortion Isn’t Distortion Like The Others


So in very simple terms, I’ve measured distortion, but not distortion in the same sense of the word. I’ve proven that an MP3 encoded audio source has a significant loss of information over its uncompressed ancestor, but noted that it is nowhere near as noticable in the finished product as for example a 3% harmonic distortion would be. It’s thus safe to say that this exercise, while interesting, is a little bit pointless because it produces a misleading figure. I think I have achieved something though, by shining some light on the matter of audio compression and subsequent quality loss. In short: for most of you it won’t matter, while the rest of you are probably using a lossless algorithm such as FLAC anyway.


hackaday.com/2025/10/28/know-a…


Give ATMega88 the Boot With This Retro Front Panel


There's an ATMega88 in that handsome case.

It’s a truism that a computer must boot before it begins to operate. Nowadays that bootstrapping process is automatic, but in the case of the very first home computers, it was very much a hands-on affair. That’s what all those switches and blinkenlights are for on the front panel of the Altair 8800 — laboriously flicking each bit into memory as required to get your program going.

[Linus Åkesson] missed those very early days, and wanted to see what it was like, and clicking virtual switches on an emulator wasn’t going to cut it. He realized that he could set up an ATmega88 for front-panel booting, and proceeded to do just that.

The article linked above goes into good detail; for those of you who prefer video, we’ve embedded his presentation below. They say the book is always better, but to get the full story, you’ll really want both in this case. The video contains a lot more context and build details, but neglects to mention some issues he had with programming that are detailed in the text. In short, the Write Page bit needs to be written to the Command register to use the page buffer. Which does make sense, but tripped [Linus] up at first.

Then again, this use case isn’t exactly detailed in the datasheet. ATmega88 is an old chip, but not Intel 8008 old, so that’s no surprise. Which is exactly what makes this a good hack! The only thing lacking is blinkenlights to allow one to see the contents of the registers. [Linus] discusses the idea of putting them in, but is apparently happy with this more minimalist approach.

We’ve seen the doughty Atmel chip hacked into everything from web-servers to washing machines, and even things that don’t start with “W”. As for the redoubtable [Linus], he’s most famous around these parts for his musical inventions and adventures with the Commodore 64.

youtube.com/embed/S-2adBkW7Xo?…


hackaday.com/2025/10/28/give-a…


Quale sarà l’e-commerce italiano basato su Magento che presto sarà violato?


Un nuovo post sul dark web mette in vendita l’accesso amministrativo a un negozio online italiano basato su Magento. Prezzo: 200 dollari. Clienti e ordini in chiaro, e un rischio enorme per la sicurezza digitale delle aziende italiane.

Un annuncio pubblicato da un utente con nickname “kazu” su un forum underground sta circolando nelle ultime ore. Nel post, l’autore mette in vendita l’accesso al pannello di amministrazione di un e-commerce italiano – completo di dashboard, clienti, ordini e analytics – a soli 200 dollari.
Print Screen del forum underground fornita gentilmente da Paragon Sec a Red Hot Cyber.
Il venditore afferma che il sito compromesso conta 15.145 clienti registrati, 28.500 ordini e oltre 1,6 milioni di euro di vendite complessive. Al momento non conosciamo quale sia l’azienda in questione, ma sappiamo che risulta essenziale per questa azienda analizzare quali possano essere le problematiche della piattaforma Magento e correre subito ai ripari (come ad esempio un patching non effettuato).

Il criminale fornisce i contatti per l’acquisto, i quali vengono forniti su piattaforme anonime e cifrate come Tox, Signal e Telegram, strumenti spesso utilizzati dai criminali per garantire anonimato e riservatezza.

Chi sono i broker di accesso (IaB)


Figure come “kazu” appartengono a una categoria ben definita nell’ecosistema criminale: i broker di accesso (Initial Access Brokers). Si tratta di attori che violano reti aziendali o piattaforme web e rivendono gli accessi a terzi – spesso a gruppi ransomware o operatori di frodi digitali.

Il loro obiettivo non è necessariamente condurre l’attacco finale, ma monetizzare rapidamente le intrusioni ottenute. Sono il primo anello della catena che porta, nei casi più gravi, a data breach, furti di dati sensibili, estorsioni e blocchi operativi.

Un rischio concreto per le aziende italiane


Il fatto che il target sia un e-commerce italiano è significativo. Molte aziende nel nostro Paese, soprattutto le PMI, non dispongono di sistemi di monitoraggio avanzati e non hanno strumenti per sapere se i propri accessi amministrativi siano in vendita nel dark web.

Le conseguenze di un accesso compromesso possono essere devastanti:

  • Furto di dati personali e finanziari dei clienti;
  • Manomissione dei sistemi di pagamento e truffe digitali;
  • Attacchi ransomware con richiesta di riscatto;
  • Violazioni del GDPR e gravi danni reputazionali.


Il ruolo della Cyber Threat Intelligence


È qui che entra in gioco la Cyber Threat Intelligence (CTI): una disciplina fondamentale per individuare e contrastare queste minacce prima che sia troppo tardi. Attraverso l’analisi delle fonti aperte (OSINT), dei forum del dark web, dei canali Telegram e dei marketplace sotterranei, la CTI permette di:

  • Scoprire accessi o dati in vendita relativi alla propria azienda;
  • Rilevare indicatori di compromissione (IoC) legati a determinate campagne o attori;
  • Prevenire attacchi mirati come ransomware o furti di dati;
  • Adattare le difese aziendali alle minacce reali e correnti.

Senza un programma di Cyber Threat Intelligence, molte organizzazioni scoprono di essere state violate solo dopo che l’attacco è avvenuto.

Conclusione: la prevenzione è l’unica difesa


Il caso dell'”Italian Shop Dashboard” è solo uno dei tanti esempi che ogni giorno compaiono nei mercati del dark web. Ogni annuncio rappresenta un’azienda vulnerabile e un’opportunità per gli attaccanti.

Oggi più che mai, la conoscenza è difesa. Implementare una strategia di Cyber Threat Intelligence significa vedere prima ciò che altri non vedono, anticipare le minacce e proteggere la propria infrastruttura digitale prima che finisca nelle mani sbagliate.

L'articolo Quale sarà l’e-commerce italiano basato su Magento che presto sarà violato? proviene da Red Hot Cyber.


L’Europa vs Silicon Valley: “AI First” parte da Torino con von der Leyen


Von der Leyen lancia “AI First” all’Italian Tech Week: tre ostacoli da abbattere e una startup da 2 miliardi persa per strada

Torino, 3 ottobre 2025. Davanti a migliaia di imprenditori e investitori alle OGR, Ursula von der Leyen ha lanciato la sua visione: “AI First”, l’intelligenza artificiale prima di tutto. E per spiegare l’urgenza di questa rivoluzione, la presidente della Commissione europea ha raccontato una storia che brucia ancora: quella della startup italiana Kong, costretta ad attraversare l’Atlantico per trovare chi credesse in lei.

La startup che l’Europa ha lasciato scappare


Tutto ha inizio con due ragazzi milanesi, in uno scantinato, con un’idea vincente. Tre anni a cercare finanziamenti in Italia: nessuno disposto a rischiare. Nel 2010, Kong (gestione dell’infrastruttura digitale cloud) sbarca negli Stati Uniti. In pochi giorni trova i primi investitori. Oggi quella startup vale 2 miliardi di dollari e il suo logo illumina Times Square.

È questa la storia che von der Leyen ha scelto come manifesto del problema europeo: il talento c’è, ma manca un ecosistema, un terreno di coltura dove farlo crescere. Osservando la platea dell’Italian Tech Week, ha dichiarato: “Vedo questo pubblico e penso che il talento non vi manca”, aggiungendo: “Il problema è che il talento da solo non basta: serve un ambiente che sappia riconoscerlo.”
Foto: Carlo Denza

Tre ostacoli da abbattere


Ma dal 2010, qualcosa è cambiato: in Italia gli investimenti in venture capital sono aumentati del 600% nell’ultimo decennio. Ma non basta. Von der Leyen ha identificato tre barriere che l’Europa deve superare per competere nella corsa globale all’AI.

Il capitale che non rischia


Quindi, in Europa il problema non è la scarsità di denaro: il risparmio delle famiglie raggiunge 1.400 miliardi di euro, contro gli 800 miliardi degli Stati Uniti. Ciò che manca è il capitale di rischio. Solo il 24% della ricchezza finanziaria europea è investita in equity, contro il 42% americano.

E la risposta? Un fondo multimiliardario. Si chiama Scaleup Europe, che investirà in intelligenza artificiale, tecnologie quantistiche e clean tech.
Foto: Carlo Denza

Ventisette legislazioni che paralizzano


Come evitare che una startup debba affrontare 27 legislazioni diverse per espandersi in Europa? Von der Leyen ha proposto il “28° regime”: un insieme unico di norme valide per tutta l’Unione.

“Una startup di San Francisco può espandersi facilmente in tutti gli Stati Uniti. In Europa dobbiamo avere la stessa possibilità”, ha sottolineato la presidente.

La lentezza che costa cara


Il punto più doloroso. La lentezza nell’adozione tecnologica, lo stesso errore che trent’anni fa ha fatto perdere all’Europa la rivoluzione digitale. Von der Leyen ha scelto di non ripeterlo.

La strategia si chiama “AI al primo posto“: davanti a ogni problema, la prima domanda dev’essere “come può aiutarci l’intelligenza artificiale?”.

A Torino, città dell’automobile, la presidente ha lanciato l’idea di una rete di città europee per testare veicoli autonomi. Sessanta sindaci italiani hanno già alzato la mano.
Foto: Carlo Denza

L’AI che salva vite


La presidente della Commissione europea, medico di formazione, si dichiara stupita da quello che oggi si può fare in medicina con l’aiuto delle nuove tecnologie. Diagnosi precoci, sviluppo accelerato di farmaci innovativi, assistenza personalizzata.

“L’adozione dell’AI deve essere diffusa e l’Europa vuole contribuire ad accelerarla. Creeremo una rete europea di centri di screening medico avanzati basati sull’AI”, ha annunciato. Un’assistenza di prima classe in ogni parte d’Europa.
Foto: Italian Tech Week

La rivincita dei Supercomputer


Come abbiamo già raccontato su Red Hot Cyber, i supercomputer sono macchine capaci di eseguire miliardi di miliardi di operazioni al secondo. Ma perché sono cruciali per l’intelligenza artificiale?

La risposta è semplice: addestrare un modello AI richiede una potenza di calcolo immensa. Raggiungere capacità di calcolo nell’ordine dei PetaFLOPS, testare milioni di parametri su miliardi di dati. Senza supercomputer, l’AI moderna non esisterebbe.

Dieci anni fa, solo uno dei dieci supercomputer più potenti al mondo era in Europa. Oggi quattro sono tra i primi dieci, e due sono in Italia. “Abbiamo smentito gli scettici”, ha dichiarato von der Leyen con orgoglio.

È la prova che l’Europa può competere quando investe con convinzione. Ma nella corsa all’intelligenza artificiale, avere l’hardware non basta: serve anche un ecosistema che sappia sfruttarlo. Ed è proprio qui che i tre ostacoli identificati dalla presidente diventano determinanti.

La corsa all’intelligenza artificiale è appena iniziata. Resta da vedere se questa volta l’Europa riuscirà davvero a trattenere i suoi Kong prima che attraversino l’oceano.

L'articolo L’Europa vs Silicon Valley: “AI First” parte da Torino con von der Leyen proviene da Red Hot Cyber.


Analog Surround Sound Was Everywhere, But You Probably Didn’t Notice


These days, most of the media we consume is digital. We still watch movies and TV shows, but they’re all packaged in digital files that cram in many millions of pixels and as many audio channels as we could possibly desire.

Back in the day, though, engineering limitations meant that media on film or tape were limited to analog stereo audio at best. And yet, the masterminds at Dolby were able to create a surround sound format that could operate within those very limitations, turning two channels in to four. What started out as a cinematic format would bring surround sound to the home—all the way back in 1982!

From The Silver Screen

Stereo optical sound tracks can be seen on the right of this scan of a 35 mm film print. On the far left is the SDDS digital audio track in blue, with the Dolby Digital audio track visible in between the sprocket holes. Modern film prints often include multiple audio formats like this so a single print can be sent to a wide range of cinemas, whatever their equipment. Credit: CC BY-SA 3.0
Dolby’s surround sound efforts were not initially aimed at the home, but at the cinema. Classically, movies were distributed on 35 mm film with a mono soundtrack encoded optically alongside the image frames themselves, with an upper frequency limit usually topping out at around 12 kHz. By the latter half of the 20th century, this was considered quite poor compared to the much richer stereo sound that filmgoers would otherwise be used to from media such as vinyl records or tape systems. A great deal of research and development was pursued by the industry, with all manner of alternative formats envisaged to make stereo sound viable for movie theatres.

Dolby’s solution was to team up with Kodak, finding a way to squeeze two optical audio tracks into the space where there was only one previously. Dolby’s well-developed noise reduction techniques came in handy in this regard, making the most of the lesser dynamic range available in the compressed space. In 1976, the technology became known as Dolby Stereo, or Dolby SVA, for Stereo Variable Area—the latter referring to the fact that the sound amplitude was encoded by variations in the area of transparency in the film’s audio track.

Dolby had successfully figured out how to distribute full stereo audio with 35 mm film prints. However, the work didn’t stop there. By applying similar techniques to those used in the burgeoning quadrophonic sound market, Dolby was able to create a rudimentary analog surround sound system. This was achieved with the use of a phase-matrix system, which could encode four channels into two stereo channels—left, right, center, and surround, with the latter sitting behind the viewer. A decoder would then split them back out to four channels for playback. This was achieved in a way that allowed the same stereo audio to be played back on regular stereo or mono systems without adding noticeable interference or noise.
A Dolby SDU4 decoder, as typically used in mixing and production of Dolby Surround content. Credit: via eBayNote the two channel inputs – L and R – and outputs for all four channels – L, R, C, and S. Credit: via eBay
In Dolby’s system, when producing the stereo soundtrack for a film print, the encoder would deliver audio for the left speaker directly to the left channel (L), and audio for the right speaker directly to the right channel (R). The center (C) speaker audio would be fed to both left and right channels equally, albeit attenuated by 3 dB. As for the surround (S) speaker audio, this would be attenuated by 3 dB, bandpassed from 100 Hz to 7 kHz, and then routed to the left and right channels, but with a phase shift of +90 degrees and -90 degrees, respectively. This method meant systems with only stereo or mono playback could play the same audio seamlessly as a two-channel or single-channel mix without issue. The surround content would cancel out, and the viewer would just get a regular stereo or mono output.

This method created a stereo recording which could then be decoded back into four channels, albeit not completely discretely—you weren’t getting four distinct channels, so much as two distinct channels with a center and surround channel derived from them with limited separation. In particular, the center channel was often used to deliver dialogue as if it was coming straight out of the screen, while the surround channel was used for more diffuse effects.

Dolby’s cinema audio decoders worked by using some basic logic circuitry to give priority to the channels that had the highest signal level by attenuating the others slightly, which created some additional separation. A time delay of up to 100 ms was also used on the surround channel installed behind the viewer. This ensured that sound leakage from the the left and right channels didn’t confuse the viewer by appearing to come from behind, thanks to the precedence effect—where the human auditory system perceives direction of a sound based on the first arriving waveform.

Bringing It Home

Dolby Surround decoders did not provide a center channel, instead just offering L, R, and S. Credit: author
Dolby’s system was designed for cinema use, but it was by no means limited to such facilities. By 1982, with VHS and Betamax video cassettes started offering Hi-Fi stereo sound, it became entirely possible to deliver the same experience to home viewers in exactly the same way. This actually eased production of home releases for movie studios, which could simply reuse their existing stereo mixdown from the theatrical release. This technology was marketed as Dolby Surround. It came with some simplifications, using only passive decoding and most notably eliminating the center channel. This allowed home decoders to be cheaper, instead just turning the stereo audio into left, right, and a rear surround channel. The latter channel was still limited to 7 kHz, and was recovered by taking the difference of the left and right channels. This only provided separation of as little as 3dB between the surround and other channels.
Dolby Pro Logic decoders performed more like the original cinema decoders, and offered the center channel as well.
Things would improve just a few years later in 1987, with the advent of Dolby Pro Logic decoders. These used so-called “steering logic” that was more similar to the decoders used in original theatre implementations. This involved decoding the stereo tracks into four channels, and monitoring the dominant prevailing direction of the sound. Based on this, the amplifiers for each of the four channels (L,R, C, S) would be varied to create greater separation of up to 30 dB between channels. For example, if the sound was loudest on the left channel, the other channels might have their output lowered to emphasize the effect. This method involved careful control of the amplifiers to ensure total output levels remained relatively constant to avoid audible discontinuities. Dolby would continue to iterate on the system, later developing Pro Logic II decoding in 2000. This was designed to scale Dolby Surround content to suit 5.1 channel systems that were becoming popular with the rise of DVD and more advanced home theatre systems. Pro Logic IIx would follow soon after, doing the same but with 6.1 and 7.1 systems.
Stereo-capable formats like Laserdisc often featured Dolby Surround encoding on releases. Credit: Dillan Payne, CC BY-SA 2.0
Dolby’s engineering trick was intended to make multi-channel surround sound possible in an economically and technically viable way, for both cinemas and home viewers alike. It largely succeeded, particularly because of its all-around compatibility. Movie studios and TV stations were able to sell or broadcast Dolby Surround content perfectly easily without impacting the larger install base of viewers that only had mono or stereo speaker setups. The only requirement was to spend some extra time finessing the mix at the encoding stage, something most were already doing for theatrical releases anyway. Many people never realized that their VHS tapes or Laserdiscs had surround sound capability, because they never invested in a decoder and a multi-speaker setup at home. A huge range of home media came complete with surround content from the 1980s onwards, but a lot of consumers didn’t notice.
If you ever wondered how The Simpsons was broadcast in surround, now you know. Credit: screenshot
Matrix decoding systems like Dolby Surround eventually fell out of style as technology moved on. With the advent of the DVD and other more contemporary digital formats, it became very simple to simply include extra audio channels in the media itself. There was no need to try and mix four down to two channels and then expand them back out—you could just include four, five, or even more audio channels right in the original content. This had the benefit of providing complete channel separation. There was no decoding process that would leave your surround channels with content from other channels in them.

Dolby Surround is one of those fun technologies from yesteryear. It reminds us that a bit of maths and creativity can enable impressive feats amidst even quite restrictive technological limitations. We might not have to work that way anymore, but it’s always instructive to learn these lessons from our recent past.


hackaday.com/2025/10/28/analog…


‘TU VALI, non sei mai troppo giovane per cambiare il mondo’: la visione di Nicola Bellotti


Spesso cerchiamo di spiegare il mondo ibrido, simultaneo e contraddittorio in cui i giovani vivono in connessione perpetua, ma la verità è che come adulti facciamo davvero fatica a capirlo. Ci chiediamo spesso come proteggerli, meno come equipaggiarli.

In poche parole parliamo di empowerment, quel processo di potenziamento che li rende capaci di agire in modo autonomo e responsabile, anche nel mondo digitale non lineare che poi è quello in cui trascorrono la maggior parte della loro vita, tra un ‘io online’ e un ‘io offline’. Si tratta non solo di fornire loro competenze tecnologiche, ma soprattutto far sviluppare consapevolezza critica, capacità di partecipare attivamente e resilienza, per essere in grado di gestire situazioni complesse, prendere decisioni informate e contribuire positivamente alla società.

Poi soffermiamoci un attimo sulla parola ‘complessità’: spesso chi sostiene che alcune cose siano troppo complicate da capire è chi preferisce che tutto rimanga così, senza essere messo in discussione, perché spesso le cose sembrano a volte progettate per non essere capite, in breve un meccanismo di potere, un campo di battaglia informativo nel quale i giovani navigano, un cyberspazio progettato per attirare la loro attenzione. In realtà, i giovani sono assolutamente in grado di imparare a distinguere il segnale dal rumore,.

Così in un mondo costruito sulla disinformazione, i giovani iper-connessi tuttavia soli, pionieri di un territorio inesplorato in continua sperimentazione, non amano la guerra né aspirano a ruoli eroici, si interessano a temi come i cambiamenti climatici, i diritti sociali e la sostenibilità, ma ancora sentono di contare poco, tuttavia sono loro a dominare le nuove tecnologie, con una creatività che è forse la loro più grande innovazione. Poi un giorno arriva Nicola Bellotti e a grandi lettere gli fa sapere che: ‘TU VALI’, la tua voce conta, le tue prospettive valgono, le tue scelte hanno un peso, ti attendono grandi cose. Quindi abbiamo deciso di raccontare questa nuova avventura.

IN BREVE:

  • Intervista a Nicola Bellotti: i giovani? Protagonisti del cambiamento
  • Il cuore del problema: identitá, relazione e rischi
  • Meccanismi e sistemi: dalla tecnologia alla norma
  • Soluzioni e prospettive: educare, preparare e ispirare
  • La visione


Intervista a Nicola Bellotti: i giovani? Protagonisti del cambiamento

Nicola Bellotti intervista Red Hot Cyber
Nicola Bellotti, è un imprenditore con un background multidisciplinare: pioniere nel digital marketing, è uno specialista nel settore digitale, sviluppa strategie di comunicazione per aziende, marchi e personaggi pubblici, concentrandosi sulla costruzione della loro reputazione. Laureatosi in giurisprudenza Nicola già negli anni ‘90 si è dedicato allo sviluppo dei primi siti web informativi fondando poi Blacklemon, una delle prime agenzie italiane specializzate in digital marketing, dove oggi si occupa principalmente di strategie di comunicazione, reputazione del brand e consulenza politica.

Ricopre e ha ricoperto negli anni vari ruoli istituzionali tra cui la partecipazione al Consiglio Generale di Assolombarda e al Comitato Piccola Industria Confindustria, oltre a far parte del gruppo Media, Comunicazione e Entertainment di Assolombarda e del Consiglio di Confesercenti a Piacenza, collaborando anche nel 2002 con il Ministro per l’Innovazione e le Tecnologie, contribuendo alla stesura del “Libro Bianco sull’Accessibilità” e del Decreto Ministeriale “PC per i giovani”. Attivo anche nel campo della sostenibilità nel 2021 ha cofondato NeaGea, una benefit corporation nata con Paolo Mazzoni per supportare le imprese nel perseguimento dell’innovazione strategica, con l’obiettivo di massimizzare il loro impatto positivo sull’ambiente, le persone e le comunità. In precedenza.

La sua attività imprenditoriale non si è limitata al digitale, ma ha toccato vari settori con un modello di “entra, innova e cedi”: nel 2012, ho fondato Melaggiusti, un’azienda specializzata nella riparazione di dispositivi Apple e Samsung, venduta a un fondo di investimento nel 2016, nel 2014 ha fondato Salus Naturalis, un’azienda produttrice di farmaci naturali, poi confluita in Toccasana e ceduta a un gruppo imprenditoriale nel 2018. Ha tenuto inoltre corsi su social media e inbound marketing per diverse istituzioni formative e collaborato con il Master in Comunicazione Internazionale all’Università di Milano (Madec) ed é anche un bravo scrittore: ha pubblicato due romanzi: I Custodi delle Rune (2007) e Mocambo (2024).

Nicola è anche un visionario con una grande fiducia nelle giovani generazioni, come portatrici di nuove idee, innovazione e cambiamento, tesi tra le necessità di migliorare la società e sviluppare competenze cruciali per il mondo del lavoro, in un mondo governato dal NO intrappolato anche da una burocrazia che intrappola le idee invece di liberarle. Qui nasce “la capacità tutta italiana di trasformare l’ostacolo in occasione, il limite in spinta” che lui conosce molto bene. Mentre Stati Uniti e Cina esercitano un grande potere sull’informazione e la disinformazione orchestrata da Russia e Cina si intensifica – tramite anche bot e falsi account sui social – l’Europa è rimasta in una posizione più passiva, quella di osservatore, rischiando oggi di divenire solo un organo regolatore sempre piú isolato geopoliticamente.. Mentre Nicola ha deciso di alzarsi in piedi, investendo nella crescita di una generazione più consapevole delle proprie forze e identità, capace di riconoscere e contrastare disinformazione e manipolazioni digitali. Qui prende forma “Tu Vali”, un’iniziativa del tutto gratuita rivolta ai giovani, che si svolge su un primo ciclo di cinque incontri volto a sostenere e valorizzare i giovani, affinché diventino consapevoli delle proprie forze e capaci di incidere positivamente nel presente e futuro.

  1. Olivia / RHC: Grazie Nicola per aver accettato questa intervista. La tua carriera attraversa l’intera storia di internet, hai visto il digitale trasformarsi da una terra di frontiera per pionieri ad un ecosistema complesso che plasma la vita di tutti, specialmente dei giovani. Da qui nasce l’iniziativa ‘Tu Vali’: puoi raccontarci come si è sviluppata nel tempo e cosa i nativi digitali di oggi possano imparare dai “pionieri” della rete come te?

NICOLA: Non ho mai avuto un mentore nella mia vita professionale, e in molti momenti difficili ho sentito il desiderio profondo di potermi confrontare con qualcuno che avesse già superato certi ostacoli. È da questa mancanza che nasce la mia spinta principale: vorrei essere per i ragazzi un piccolo aiuto, un punto di riferimento, un incoraggiamento sincero.
Anche perché — diciamolo — i giovani sono una categoria bistrattata da millenni. Ti faccio un esempio: “La nostra gioventù ama il lusso, è maleducata, si burla dell’autorità, non ha alcun rispetto degli anziani. I bambini di oggi sono dei tiranni, non si alzano quando un vecchio entra in una stanza, rispondono male ai genitori. In una parola, sono cattivi”. Ti sembra attuale, vero? Eppure lo diceva Socrate, nel 470 a.C. Da sempre i giovani, in quanto incarnazione del futuro e del cambiamento, fanno paura. E la prima reazione del mondo adulto è spesso quella di contenerli, di ridurli al ruolo di semplici spettatori. Io, invece, vorrei aiutarli a scoprire qualcosa in più: sulle grandi opportunità che li attendono, ma soprattutto su loro stessi.

Il cuore del problema: identitá, relazione e rischi


  1. Olivia / RHC: L’identità per molti giovani si trasforma spesso in un semplice like, compromettendo la sicurezza personale e la capacità di riconoscere il proprio potenziale. D’altra parte, la perdita di embodiment rappresenta un problema fisico, mentale e culturale, che richiede un ripensamento nell’uso della tecnologia per aiutare i giovani a riappropriarsi del proprio corpo e del proprio potere. Quali strumenti e leve di empowerment ritieni possano essere efficacemente offerti ai giovani oggi?

NICOLA: Credo che ogni generazione sviluppi i propri anticorpi in risposta alle sfide del tempo in cui vive.

Ho una grande fiducia nel potenziale dei giovani: ciò che a noi adulti può sembrare una minaccia, per loro può diventare un’occasione per inventare qualcosa che ancora non esiste. Quando ero un ragazzino passavo troppo tempo davanti ai videogiochi e ai fumetti. Eppure, dai videogiochi è nata la mia passione per l’informatica applicata alla creatività, e dai fumetti la curiosità per culture lontane dalla mia. In sostanza, da ciò che preoccupava i miei genitori è germogliato il mestiere che oggi svolgo e l’azienda che ho costruito. Il tema della percezione di sé, durante l’adolescenza, è sempre stato cruciale.

Ogni generazione si è confrontata con il bisogno di autodeterminarsi. Quello che oggi trovo particolarmente duro è il peso dei numeri dei social: like, visualizzazioni, follower. Ai miei tempi sapevo di non essere un adone, ma non avevo un contatore quotidiano che me lo ricordasse. Oggi i numeri possono diventare gabbie: offrono false conferme e spingono gli adolescenti — naturalmente in cerca di riconoscimento e appartenenza — a comportamenti di cui rischiano di pentirsi, pur di ottenere qualche like in più e sentirsi visti. Vorrei che gli incontri di “Tu, Vali” fossero una leva di empowerment, una pacca sulla spalla.

  1. Olivia / RHC: Cyberbullismo, hate speech, predatori e crimine online: quali sono gli strumenti che aiutano i genitori nel difficile compito di controllore dei propri figli?

NICOLA: È una domanda davvero complessa. Quando nasce un figlio, nessuno ti consegna un manuale di istruzioni. Cerchi di ispirarti alla tua esperienza di figlio, ti imponi di migliorare ciò che può essere migliorato, ti prepari con mille buone intenzioni e schemi mentali… e poi scopri che ogni figlio è diverso da come l’avevi immaginato. L’adolescenza arriva come un treno in corsa, e tu puoi solo cercare di fare del tuo meglio per restare in piedi. Parlando ogni giorno con tante persone, mi accorgo che quasi nessuno ha davvero chiara la complessità dei social e delle piattaforme digitali che oggi fanno parte della vita quotidiana dei nostri figli.

Esercitare un controllo, senza conoscenza, è difficilissimo: si sbaglia quando si esagera con le restrizioni, ma si sbaglia anche quando si concede troppa libertà. Di fronte a fenomeni come cyberbullismo, hate speech, predatori digitali e criminalità online, serve innanzitutto più cultura. Bisogna conoscere, comprendere, approfondire. È l’unica vera arma che un genitore ha per accorgersi dei segnali che qualcosa non va, e intervenire prima che sia troppo tardi.

  1. Olivia / RHC: Tu affermi: ‘Sembra tutto casuale ma non lo è. Ogni video è scelto da un algoritmo che studia cosa ti piace, come reagisci, quanto resti a guardare … più resti più è difficile capire cosa è vero e cosa non lo è’. Puoi spiegare come funzionano questi algoritmi e quali effetti hanno sulla capacità dei giovani di riconoscere la verità e difendersi dalle manipolazioni digitali?

NICOLA: Partiamo da un dato fondamentale: oggi il controllo della maggior parte delle piattaforme in cui si svolge la comunicazione di massa è concentrato nelle mani di pochissime aziende, quasi tutte americane o cinesi. È estremamente difficile che altri soggetti possano, nel breve periodo, imporsi come alternative reali. All’interno di queste piattaforme (penso a Facebook, Instagram, TikTok, YouTube, LinkedIn) la disponibilità di enormi quantità di dati ha permesso di costruire profili estremamente precisi su ciascuno di noi: abitudini, interessi, paure, inclinazioni. E noi, comodamente, ci siamo lasciati profilare. Così, progressivamente, abbiamo delegato agli algoritmi un numero crescente di decisioni: dal suggerimento del prossimo film su Netflix, fino alla visione passiva di reel che scorrono per ore, sostituendo libri, giornali, perfino le chiacchiere al bar.

Il problema è che questi algoritmi non solo semplificano le nostre scelte, ma rischiano di irrigidire i nostri pregiudizi. Ci mostrano sempre più spesso contenuti che confermano ciò che già pensiamo, dandoci l’illusione che il mondo la pensi come noi. Questo uccide il dialogo, la capacità di sintesi, il confronto politico autentico.

I giovani, diversamente da noi, non hanno conosciuto un mondo “prima dei social”. Non sanno cosa significasse informarsi leggendo un giornale o ascoltando opinioni diverse. Oggi, praticamente nessuno sotto i 65 anni legge regolarmente un quotidiano. È un cambiamento epocale. Se i “boomer” spesso non distinguono una notizia vera da una falsa e la Generazione X si è polarizzata, la maggior parte dei giovani ha perso interesse per le idee. Non solo partecipano meno al dibattito pubblico, ma spesso non votano nemmeno più.

Gli attivisti stessi, pur animati da passione, restano intrappolati nella stessa logica algoritmica: vedono solo ciò che conferma le loro convinzioni. Sono prigionieri di una bolla. Anche qui l’unica arma che hanno le persone contro le manipolazioni digitali è la conoscenza, la curiosità, l’approfondimento. Sono convinto che ogni adolescente, indipendentemente dal suo orientamento politico, debba per sua natura voler cambiare il mondo, mettere in discussione ciò che trova, desiderare il cambiamento con forza. Oggi, invece, vedo una generazione spesso remissiva, ipnotizzata, sfiduciata. Ma, nonostante tutto, continuo ad avere in loro molta più fiducia di quanta ne abbiano loro stessi.

Meccanismi e sistemi: dalla tecnologia alla norma


  1. Olivia / RHC: Mi piace questa tua osservazione: ‘la comunicazione è una cosa seria’… ‘chi capisce come funziona la comunicazione comincia a decidere davvero con la propria testa’. Parliamone.

NICOLA: La comunicazione ha avuto un ruolo decisivo nell’evoluzione dell’umanità rispetto a tutte le altre specie animali. Come ricordava Stephen Hawking, i più grandi traguardi della nostra civiltà sono stati raggiunti parlando. La tecnologia può amplificare questa capacità: può aiutarci a comunicare di più, a comprenderci meglio, a costruire ponti tra persone e culture diverse. Diventa però pericolosa quando si sostituisce al dialogo autentico tra esseri umani.
Studiare i meccanismi della comunicazione (pubblicitaria, politica, sociale o istituzionale) significa imparare a decifrare il mondo in cui viviamo. La comunicazione strategica ti abitua a pensare due o tre mosse avanti, come in una partita di scacchi. Ti allena a leggere una notizia e a ricostruire, a ritroso, le possibili mosse che hanno portato a quel risultato, entro uno scenario preciso e circoscritto.
In questo senso, la comunicazione è una chiave di lettura straordinaria: ti insegna a interpretare la realtà, a comprendere la geopolitica… che, in ultima analisi, è la trama di fondo su cui si muove tutto ciò che accade.

  1. Olivia / RHC: Parliamo di regolamentazione tecnologica: l’Europa cerca di mitigare rischi complessi… Proteggere si, ma bisogna anche permettere lo sviluppo ad esempio quello delle imprese tecnologiche. Ne hai parlato in Trump chiama, Silicon Valley risponde e l’Europa resta a guardare.

NICOLA: Non vorrei essere frainteso, quindi premetto due cose.
La prima: sono un convinto europeista. Credo che l’amicizia costruita tra i popoli europei ci abbia garantito decenni di pace, prosperità e una cultura comune fondata su valori irrinunciabili.
La seconda: sono altrettanto convinto che icambiamenti introdotti dall’Intelligenza Artificiale saranno più profondi e dirompenti di quelli generati dalla rivoluzione industriale tra il Settecento e l’Ottocento. Ci troviamo di fronte a una trasformazione epocale, e l’Europa, purtroppo, non è pronta ad affrontarla.

Nel campo del digitale, i decisori europei si sono dimostrati spesso impreparati, goffi, incapaci di prevedere le conseguenze pratiche delle proprie scelte. Le regole introdotte dall’Unione Europea finiscono troppo spesso per penalizzare chi agisce in modo trasparente (persone, aziende e professionisti) minandone la sostenibilità economica, mentre non riescono minimamente a contrastare chi opera nell’ombra, spesso dall’estero, in modo scorretto o manipolatorio.

Ci sono almeno quattro esempi lampanti:

  • la stretta sulla pubblicità politica online, dove le regole già esistevano ed erano applicate dai professionisti seri del settore;
  • la proposta di regolamento CSAR (Child Sexual Abuse Regulation), che rischia di trasformarsi in una sorta di “Grande Fratello” digitale, autorizzando il controllo di ogni foto che condividiamo su WhatsApp;
  • l’obbligo di verifica dell’età sui siti per adulti, che finirà per far chiudere le aziende più serie e favorire chi non ha mai rispettato le regole;
  • e infine il Digital Services Act, nato con buone intenzioni ma divenuto uno strumento burocratico complesso, più utile a frenare che a innovare.

Mentre Stati Uniti, Cina e India corrono, sperimentano e investono nel futuro, noi europei continuiamo a vietare, bloccare, normare, regolamentare… sacrificando sull’altare delle ideologie – e degli interessi elettorali – il futuro dei nostri giovani. Ed è proprio per questo che dovrebbero essere loro, i giovani, a salire sulle barricate.

  1. Olivia / RHC: Nel contesto normativo (Digital Services Act) vi è anche la proposta di richiesta di documenti per accedere alle piattaforme: per l’underground questo rappresenta un punto debole nel sistema, più pericoloso di altre forme di vulnerabilità, perché un documento digitale è una chiave che può aprire molte porte. Quali sono le tue osservazioni a riguardo?

NICOLA: Come dicevo prima, i decisori di Bruxelles hanno spesso dimostrato di non saper prevedere l’ovvio. Da anni, chiunque lavori nel nostro settore mette in guardia le persone dal condividere con leggerezza i propri dati o documenti online. Eppure, oggi, ci si propone di introdurre sistemi che obbligherebbero gli utenti, anche solo per accedere a un sito per adulti, a fornire il proprio documento d’identità o a sottoporsi a una scansione del volto e della voce per verificare l’età.

Tutto questo accade in un’epoca in cui, con strumenti come HeyGen, anche un ragazzino può creare in pochi minuti un avatar digitale capace di imitare perfettamente voce e sembianze di chiunque. I cosiddetti “deepfake” stanno diventando indistinguibili dal reale, e lo saranno completamente tra pochi mesi. È paradossale: mentre la tecnologia ci mette di fronte a un rischio sempre maggiore di manipolazione e furto d’identità, l’Europa propone soluzioni che aumentano la quantità di dati sensibili in circolazione, anziché proteggerli.

Soluzioni e prospettive: educare, preparare e ispirare


  1. Olivia / RHC: I genitori svolgono sicuramente un ruolo cruciale, devono essere contemporaneamente controllori ed educatorima al contempo bisogna costruire una rete di supporto – educativa, tecnica e normativa – che possa davvero proteggere e responsabilizzare le nuove generazioni. Da dove si parte?

NICOLA: Non sono un esperto di formazione e non pretendo di avere una soluzione. Mi limito a constatare che, purtroppo, la scuola italiana è un sistema obsoleto, autoreferenziale e profondamente infelice. Solo il 26% delle ragazze e il 17% dei ragazzi dichiara di essere contento di andare a scuola, contro una media europea del 56%. È un dato drammatico.

Secondo le ricerche di OMS e OCSE, al 90% delle ragazze e al 92% dei ragazzi di 15 anni la scuola non piace. Può sembrare un fatto scontato — “ai ragazzi non piace studiare” — ma in realtà questo è un problema tipicamente italiano. Gli studenti italiani soffrono di ansia più dei loro coetanei in altri Paesi con stili di vita simili. Il nostro sistema scolastico sembra progettato per i professori e per il personale amministrativo, non per chi dovrebbe esserne il vero protagonista: gli studenti. In altri contesti, di fronte a una crisi di tali proporzioni, si interverrebbe con urgenza. Io partirei da qui: da una riforma seria e profonda della scuola, che metta davvero il futuro dei nostri figli davanti a qualsiasi altra logica. Se riusciamo a trovare fondi per il riarmo, forse potremmo destinarne almeno una parte a un investimento più strategico e civile: quello sull’educazione.

  1. Olivia / RHC: Nicola, la tua esperienza spazia tra innovazione tecnologica, comunicazione e trasformazioni sociali. Quali competenze ritieni fondamentali perché i giovani di oggi possano diventare protagonisti consapevoli e attivi di questo cambiamento? E come possiamo prepararli al meglio per affrontare le sfide future?

NICOLA: La chiave di tutto è la curiosità. Stiamo vivendo un cambiamento radicale nel modo di lavorare: intelligenza artificiale, connettività globale, macchine pensanti e nuovi media sono i motori di una trasformazione che ridisegnerà intere professioni e ne creerà di nuove, oggi ancora impensabili. In questo scenario, chi saprà restare più curioso della media sarà in grado di “surfare” sulla cresta dell’onda.

La curiosità è ciò che spinge a informarsi, conoscere, approfondire, sperimentare e, alla fine, riuscire. Il futuro richiederà la capacità di affrontare problemi complessi, che attraversano discipline diverse, e di coltivare competenze che nessuna macchina potrà facilmente replicare: comprendere il significato profondo di ciò che viene comunicato, cogliere le sfumature emotive, creare connessioni autentiche con gli altri. Più crescerà l’importanza delle macchine, più acquisterà valore il lato umano delle cose: l’empatia, la spiritualità, la capacità di ispirare e interagire in modo autentico. Ma la curiosità da sola non basta. Va accompagnata da apertura mentale, spirito critico, capacità relazionale e, soprattutto, tenacia. Perché alla fine – sempre – la tenacia vince sul talento.

  1. Olivia / RHC: Sei anche uno scrittore. In che modo il narrare storie, nei romanzi come nella comunicazione di brand, influenza la percezione della realtà e può essere uno strumento per aiutare i giovani a costruire un’identità solida e non solo basata sui ‘like’?”

NICOLA: Non riesco a definirmi uno scrittore. Amo leggere, e credo che i veri scrittori siano altri. L’unica cosa che ho scritto di cui vado davvero fiero è Mocambo, perché tra le righe di quei tredici racconti ci sono io, completamente: le esperienze che mi hanno formato, le emozioni che continuo a provare, ma anche le mie fragilità, le mie contraddizioni, le lotte interiori che mi accompagnano da sempre.

Nel mio lavoro, la parte che più mi appassiona è quella legata al branding, all’identità e al posizionamento dei marchi, all’elaborazione di strategie che permettano a persone e aziende di governare la propria reputazione. Sono le sfide più complesse e, al tempo stesso, le più stimolanti.

Ogni progetto è un universo a sé, e per questo è difficile generalizzare o dare consigli validi per tutti i giovani che si affacciano a questo mondo. Quando però i ragazzi mi chiedono un consiglio – capita ogni tanto, alla fine di incontri di formazione – preferisco rispondere facendo ascoltare le parole del monologo finale del film “The Big Kahuna”

Il monologo si chiude dicendo: Sii cauto nell’accettare consigli, ma sii paziente con chi li dispensa. I consigli sono una forma di nostalgia. Dispensarli è un modo di ripescare il passato dal dimenticatoio, ripulirlo, passare la vernice sulle parti più brutte e riciclarlo per più di quel che valga”. Credo che in questa frase ci sia tutta la saggezza e l’umiltà con cui dovremmo guardare all’esperienza, nostra e altrui.

youtube.com/embed/gqQPOYZo6Fs?…

La visione


  1. Olivia / RHC: Puoi elaborare da visionario due scenari futuri del nostro mondo di domani?

NICOLA: Questa è davvero una domanda difficile, Olivia. Sono un divoratore di libri e film di fantascienza, e credo che in quel genere siano già stati immaginati quasi tutti gli scenari possibili. Quello che ho imparato dai fumetti – e che trovo profondamente vero – è che da grandi poteri derivano grandi responsabilità.

Oggi ci troviamo proprio sull’orlo di questo passaggio: stiamo per liberare un potere immenso, capace di cambiare in modo radicale le regole del gioco. Per questo credo che serva una responsabilità nuova, collettiva, che ci porti a rivedere i nostri paradigmi. Dovremmo avere il coraggio di archiviare concetti ormai superati – come le divisioni tra destra e sinistra in politica, per citare un esempio volutamente provocatorio – e imparare a riconoscerci, finalmente, come un unico popolo: quello degli umani, o dei terresti se preferisci tornare alla fantascienza. Un popolo che, molto presto, dovrà imparare a convivere con un’altra forma di intelligenza, diversa dalla nostra ma capace di esistere in modo altrettanto reale e tangibile.

L'articolo ‘TU VALI, non sei mai troppo giovane per cambiare il mondo’: la visione di Nicola Bellotti proviene da Red Hot Cyber.


Mushrooms As Computer Memory


Fungi make up a massive, interconnected part of Earth’s ecosystems, yet they’re vastly underrepresented in research and public consciousness compared to plants and animals. That may change in the future though, as a group of researchers at The Ohio State University have found a way to use fungi as organic memristors — hinting at a possible future where fungal networks help power our computing devices.

A memristor is a passive electronic component whose resistance changes based on the voltage and current that has passed through it, which means it can effectively remember past electrical states even when power is removed. To create these circuit components with fungus, the researchers grew shiitake and button mushroom mycelium for these tests, dehydrated their samples for a number of days, and then attached electrodes to the samples. After misting them briefly to restore conductivity, the samples were exposed to various electrical wave forms at a range of voltages to determine how effective they were at performing the duties of a memristor. At one volt these systems were the most consistent, and they were even programmed to act like RAM where they achieved a frequency of almost 6 kHz and an accuracy of 90%.

In their paper, the research group notes a number of advantages to building fungal-based components like these, namely that they are much more environmentally friendly and don’t require the rare earth metals that typical circuit components do. They’re also easier to grow than other types of neural organoids, require less power, weigh less, and shiitake specifically is notable for its radiation resistance as well. Some work needs to be done to decrease the size required, and with time perhaps we’ll see more fungi-based electrical components like these.


hackaday.com/2025/10/28/mushro…


Gemini 3.0 Pro: scopriamo i primi test di chi lo sta provando


Negli ultimi giorni, alcuni utenti selezionati hanno segnalato di aver avuto accesso al nuovo modello Gemini 3.0 Pro. Le prime impressioni parlano di un’evoluzione significativa rispetto alla generazione precedente, al punto che molti la descrivono come un vero salto di qualità per l’intelligenza artificiale di Google.

Gemini 3.0 Pro sembra in grado di affrontare compiti estremamente complessi: dalla programmazione di videogiochi o siti web completi fino alla generazione di piattaforme e-commerce funzionanti, tutto partendo da un unico prompt. In alcuni test, il modello è riuscito persino a creare grafica vettoriale in formato SVG con risultati molto convincenti.

Si parla inoltre della possibilità che il sistema riesca a costruire ambienti operativi e interfacce complesse, passando con naturalezza dal testo al codice, dai dati alle immagini. Un’evoluzione che conferma come Google stia spingendo verso un’IA sempre più capace di “capire” e non solo di generare.
Un utente su twitter ha generato una completa interfaccia grafica con Gemini 3.0 riportando risultati eccezionali

Un rilascio graduale e un obiettivo ambizioso


Google mantiene ancora il massimo riserbo sull’arrivo ufficiale di Gemini 3.0, ma secondo le informazioni raccolte il debutto potrebbe avvenire entro dicembre (come anticipato nel precedente articolo), in linea con la strategia di rilascio adottata per i modelli precedenti. L’azienda avrebbe optato per un rollout controllato, riservando la fase di test a un numero ristretto di utenti per raccogliere feedback e migliorare le prestazioni.

Uno degli aspetti più interessanti è l’integrazione con l’ecosistema di Google Workspace. Gemini 3.0 Pro sarebbe pensato per operare all’interno di strumenti come Docs, Gmail, Sheets e Slides, permettendo all’intelligenza artificiale di supportare in modo dinamico la produttività e la creazione di contenuti.

L’obiettivo dichiarato è chiaro: competere direttamente con GPT-5 e Claude 4.5, due dei modelli più avanzati attualmente in sviluppo, e superarne le capacità multimodali e di ragionamento complesso.
Un altro utente su twitter si lamenta che non è troppo performante nella programmazione, ma ama scusarsi.

Un salto generazionale verso il multimodale


Gemini 3.0 Pro non rappresenta solo un aggiornamento, ma un vero e proprio cambio di paradigma. È progettato per essere un modello “nativamente multimodale”, capace di passare senza soluzione di continuità dal testo alle immagini, dai dati numerici al codice, e di comprendere i collegamenti logici tra contenuti diversi.

Questa capacità apre la strada a un’IA in grado di partecipare attivamente ai processi creativi e di automazione, trasformando radicalmente il modo in cui si lavora, si scrive o si sviluppano applicazioni. È la visione di Google per un’intelligenza che non assiste soltanto, ma collabora.

Tuttavia, come accade per ogni salto tecnologico, ci sono ancora diversi punti interrogativi. I test pubblici sono limitati, i benchmark ufficiali non sono stati pubblicati e non esiste ancora una valutazione indipendente delle reali prestazioni rispetto alla concorrenza.
Un utente su Twitter riporta invece che si tratti di un modello super performante per la realizzazione delle interfacce grafiche.

Le implicazioni per la cybersecurity e la governance dell’IA


Un modello così potente apre inevitabilmente anche riflessioni nel campo della cybersecurity. Un’intelligenza in grado di generare codice, automatizzare workflow e creare elementi grafici in tempo reale rappresenta una straordinaria opportunità per le imprese, ma anche un rischio se utilizzata in modo improprio.

Potrebbe facilitare la creazione di phishing sofisticati o di codice malevolo, ma al tempo stesso diventare un potente strumento di difesa, capace di identificare vulnerabilità e simulare attacchi per rafforzare la sicurezza.

Dal punto di vista della governance, Gemini 3.0 Pro spinge Google a definire regole chiare sulla trasparenza, la tracciabilità dei contenuti generati e il controllo sugli output. La sfida non è più soltanto tecnica, ma anche etica e regolamentare.

In definitiva, Gemini 3.0 Pro segna l’inizio di una nuova era per l’intelligenza artificiale di Google. Se le promesse verranno mantenute, ci troveremo di fronte non solo a un modello più potente, ma a una piattaforma capace di ridefinire gli standard della produttività e della sicurezza digitale.
Un altro utente di Twitter ha ricreato una completa interfaccia grafica funzionante stile Windows
L'articolo Gemini 3.0 Pro: scopriamo i primi test di chi lo sta provando proviene da Red Hot Cyber.


Cooking Up Plastics in the Kitchen


Two colored plastic films are loosely tied over the entrances to two plastic containers.

The earliest useful plastics were made out of natural materials like cellulose and casein, but since the Bakelite revolution, their use has dwindled away and left them mostly as curiosities and children’s science experiments. Fortunately, though, the raw materials for bioplastics are readily available in most grocery stores, and as [Ben] from NightHawkInLight demonstrates, it’s still possible to find new uses for them.

His first recipe was for a clear gelatine thermoplastic, using honey as a plasticizer, which he formed into the clear packet around some instant noodles: simply throw the whole packet into hot water, and the plastic dissolves away. With some help from the home bioplastics investigator [Giestas], [Ben] next created a starch-based plastic out of starch, vinegar, and glycerine. Starch is a good infrared emitter in the atmospheric window, and researchers have made a starch-plastic aerogel that radiates enough heat to become cooler than its surroundings. Unfortunately, this requires freeze-drying, and while encouraging freezer burn in a normal freezer can have the same effect, it’ll take a few months to get a usable quantity of the material.

The other problem with starch-based plastics is their tendency to absorb water, at least when paired with plasticizers like glycerine or honey. Bioplastics based on alginate, however, are easy to make waterproof. A solution of sodium alginate, derived from seaweed, reacts with calcium ions to make a cross-linked waterproof film. Unfortunately, the film forms so quickly that it separates the solutions of calcium ions from the alginate, and the reaction stops. To get around this, [Ben] mixed a sodium alginate solution with powdered calcium carbonate, which is insoluble and therefore won’t react. To make the plastic set, he added glucono delta lactone, which slowly breaks down in water to release gluconic acid, which dissolves the calcium carbonate and lets the reaction proceed.

The soluble noodle package reminded us of a similar edible package, which included flavoring in the plastic. We’ve also seen alginate used to make conductive string, and rice used to make 3D printer filament. It’s worth some caution, though – not all biologically-derived plastics are healthier than synthetic materials.

youtube.com/embed/J87Qyxzm_fQ?…


hackaday.com/2025/10/28/cookin…


Dal corpo allo schermo: come l’abuso sessuale si è spostato nel mondo digitale


Questo è il secondo di una serie di articoli dedicati all’analisi della violenza di genere nel contesto digitale, in attesa del 25 novembre, Giornata Internazionale per l’Eliminazione della Violenza contro le Donne. Il focus qui è sulla evoluzione della tutela penale di fronte all’aggressione sessuale virtuale.

La nozione di Violenza Sessuale Virtuale (VSV) si riferisce a una serie di condotte aggressive e coercitive a sfondo sessuale che avvengono attraverso strumenti digitali, in assenza di contatto fisico tra l’autore e la vittima. Questo fenomeno, che colpisce in modo sproporzionato donne e ragazze, si articola in forme insidiose come anche la sextortion (estorsione sessuale) e l’abuso sessuale virtuale anche tramite deepfake.

Nonostante l’azione si svolga in uno spazio virtuale, l’intento e l’impatto psicologico della VSV non differiscono sostanzialmente dalla violenza agita nello spazio fisico. Entrambe mirano al dominio, al controllo e alla sopraffazione della vittima. L’ambiente digitale, offrendo anonimato e distanza fisica, può abbassare la percezione del rischio da parte del persecutore, amplificando il senso di impotenza della vittima.

La Sextortion si distingue dal Revenge Porn per la sua finalità strumentale. Consiste nel minacciare la diffusione di immagini intime, reali o manipolate, al fine di estorcere alla vittima ulteriore materiale sessuale, denaro, gift card o servizi. Questa dinamica rientra nel reato di Estorsione (Art. 629 c.p.), dove la prospettazione del danno (la diffusione) ha una chiara efficacia intimidatoria sulla vittima.

Un caso limite è rappresentato dall’abuso sessuale nel Metaverso, ovvero l’aggressione compiuta tramite avatar. Questo atto, pur essendo moralmente riprovevole e causando un impatto psicologico, solleva interrogativi sulla sua riconducibilità alla fattispecie della Violenza Sessuale (Art. 609-bis c.p.), che richiede la condotta materiale.

Il quadro normativo italiano e la giurisprudenza di legittimità


Il Diritto penale italiano, in assenza di una fattispecie autonoma di “Violenza Sessuale Virtuale” (VSV), ha affrontato la questione attraverso l’adattamento e l’interpretazione estensiva dell’Art. 609-bis c.p. e l’introduzione di nuove fattispecie.

Nonostante la formulazione letterale dell’Art. 609-bis c.p. sembri presupporre la materialità del contatto, la giurisprudenza di legittimità ha dato una risposta affermativa alla possibilità di configurare la violenza sessuale attraverso la rete, superando la necessità di una contestualità spaziale o di un contatto corporeo diretto.

La Corte di Cassazione ha consolidato l’orientamento secondo cui il reato può estrinsecarsi anche nel compimento di atti sessuali su se stessi (autoerotismo) effettuati a seguito di costrizione o induzione, come stabilito in diverse sentenze (ad esempio, la Sez. III, sent. n. 37076/12). In questa prospettiva, la Cassazione ha confermato la condanna per violenza sessuale realizzata mediante l’utilizzo di social network e webcam: in un caso specifico, il soggetto aveva compiuto atti di autoerotismo dopo essersi assicurato che alcune minori lo avrebbero guardato attraverso webcam (Sez. III, sent. n. 16616/15). Secondo questa interpretazione, il delitto, quando consiste nel compimento di atti sessuali su se stessi, può essere commesso anche in ambito virtuale, poiché la norma non richiede una contestualità spaziale, ma è essenziale che l’abuso venga effettivamente percepito dalla vittima.

La giurisprudenza ha esteso ulteriormente questo concetto, stabilendo che anche la prestazione sessuale a distanza possa integrare l’elemento oggettivo dell’Art. 609-bis c.p., purché sia accertata la costrizione. Ad esempio, il reato si perfeziona quando la condotta consiste nell’invio di messaggi whatsapp allusivi ed espliciti a una minorenne, costringendola a realizzare selfie intimi da inviare, sotto la minaccia di pubblicazione (sextortion) (Cass., Sez. III, sent. n. 25266/20). In tali contesti, la condotta è considerata violenza sessuale, e non estorsione (Art. 629 c.p.), in quanto l’obiettivo primario del reo è l’ottenimento dell’atto sessuale (l’invio di foto intime o l’autoerotismo coartato) e non solo un vantaggio patrimoniale (Cass., Sez. II, sent. n. 41985/21).

Nonostante questo orientamento giurisprudenziale sia condivisibile in quanto garantisce la tutela della vittima all’interno dell’ordinamento vigente, la stessa Cassazione riconosce una differente invasività nel caso di violenza sessuale virtuale rispetto a quella reale. Inoltre, il limite concettuale di ricondurre la Violenza Sessuale (Art. 609-bis c.p.) esclusivamente all’atto che genera contatto o un’azione su se stessi crea un vuoto normativo per l’abuso sessuale tramite avatar. Poiché l’atto di molestare l’avatar di un soggetto non è in grado di “toccare materialmente” la persona e non rientra nel compimento di atti autoerotici costretti sulla vittima, la sua riconducibilità al 609-bis è esclusa dalla giurisprudenza prevalente.

Contrasto al Deepfake e alla Sextortion


Alcune forme più comuni di VSV sono oggi contrastate efficacemente da due articoli del Codice Penale, introdotti o influenzati dal cosiddetto “Codice Rosso” (L. 69/2019):

Diffusione illecita di immagini o video sessualmente espliciti(Art. 612-ter c.p., Revenge Porn): che punisce la diffusione, senza consenso, di immagini o video sessualmente espliciti;

Illecita diffusione di contenuti generati o alterati con sistemi di intelligenza artificiale (Art. 612-quater c.p.)- Questo nuovo reato, introdotto con la Legge 132/2025, punisce specificamente la diffusione lesiva di contenuti generati o alterati con Intelligenza Artificiale (IA). L’introduzione del 612-quater è stata fondamentale per colmare la lacuna lasciata dal 612-ter, che si applicava solo a immagini realmente realizzate o sottratte, e per contrastare l’abuso sessuale virtuale.

La Sextortion viene ricondotta alla fattispecie di Estorsione(Art.629 c.p.), rientrando nel campo dei reati comuni realizzati mediante strumenti informatici.

La dimensione europea e l’impatto di genere


A livello europeo, la Direttiva (UE) 2024/1385 sulla lotta alla violenza contro le donne impone agli Stati membri l’obbligo di criminalizzare la creazione e diffusione di contenuti intimi tramite IA o photoshop (i cosiddetti deepfakes), rafforzando la tutela. Prevede, inoltre, pene detentive rigorose e l’obbligo di fornire assistenza specialistica, come centri antistupro e centri antiviolenza sessuale, e misure di rimozione del materiale.

Secondo i dati a disposizione circa il 90% delle vittime di diffusione non consensuale di immagini intime sono donne. L’impatto emotivo e psicologico sulla vittima è devastante, causando disturbi d’ansia, depressione e Disturbo Post-Traumatico da Stress (PTSD), configurando un danno biologico risarcibile. Nel contesto di revenge porn e sextortion, il danno è spesso aggravato dalla vittimizzazione secondaria (victim blaming), dove la donna viene colpevolizzata per aver prodotto il contenuto sessuale.

Prova digitale e tutela preventiva


La repressione dei crimini di VSV è strettamente legata alla capacità di acquisire e preservare la prova digitale (immagini, chat, post) in modo ammissibile in giudizio. Semplici screenshot hanno valore probatorio limitato e necessitano di essere supportati da metodologie di acquisizione tecnica forense che garantiscano l’autenticità e l’inalterabilità del contenuto web.

Un elemento cruciale della tutela in Italia è l’intervento preventivo e d’urgenza del Garante per la protezione dei dati personali, previsto dall’Art. 144-bis del Codice Privacy. Chiunque abbia un fondato timore di diffusione non consensuale di materiale sessualmente esplicito può presentare una segnalazione al Garante. Questo interviene entro quarantotto ore e notifica un provvedimento alle piattaforme digitali corredato dell’impronta hash del materiale. Questo codice univoco digitale consente alle piattaforme di identificare e bloccare automaticamente qualsiasi tentativo futuro di ricaricare lo stesso file, offrendo una protezione continua.

Verso una riforma integrata


La violenza sessuale virtuale rappresenta un attacco strutturale alla dignità e all’autodeterminazione. L’ordinamento italiano, pur avendo reagito prontamente con le nuove norme su deepfake e revenge porn, e pur grazie all’interpretazione evolutiva e meritoria della Cassazione che estende il reato di Violenza Sessuale alle condotte costrittive a distanza, evidenzia una rigidità dogmatica di fronte all’abuso sessuale puro nel Metaverso.

L’orientamento giurisprudenziale, che equipara l’atto sessuale coartato a distanza (ad esempio, l’autoerotismo imposto) al reato tradizionale, è fondamentale per la tutela della vittima, ma la Cassazione stessa riconosce una differente invasività rispetto all’atto commesso in presenza. Il limite concettuale, che esclude l’aggressione tramite avatar dal 609-bis c.p., impone una riflessione sull’adeguatezza del concetto di “atto sessuale” nell’era degli ambienti immersivi.

È cruciale che la risposta del legislatore non si limiti alla repressione ex post, ma valuti l’opportunità di introdurre una fattispecie ad hoc, come si è reso necessario per i deepfake, per superare il principio di materialità e tutelare l’integrità sessuale come bene giuridico non solo fisico, garantendo allo stesso tempo un bilanciamento tra la gravità delle condotte digitali e quelle fisiche. Parallelamente, è essenziale valorizzare gli strumenti di prevenzione e di tutela rapida (ex ante), come l’intervento del Garante Privacy, indispensabili per contenere il danno psicologico e sociale subito dalle donne.

L'articolo Dal corpo allo schermo: come l’abuso sessuale si è spostato nel mondo digitale proviene da Red Hot Cyber.


Remembering Better Mono Graphics


No matter what kind of computer or phone you are reading this on, it probably has a graphics system that would have been a powerful computer on its own back in the 1980s. When the IBM PC came out, you had two choices: the CGA card if you wanted color graphics, or the MDA if you wanted text. Today, you might think: no contest, we want color. But the MDA was cheaper and had significantly higher resolution, which was easier to read. But as free markets do, companies see gaps and they fill them. That’s how we got the Hercules card, which supported high-resolution monochrome text but also provided a graphics mode. [The 8-bit Guy] has a look at these old cards and how they were different from their peers.

Actually, the original MDA card could do eight colors, but no one knew because there weren’t any monitors it could work with, and it was a secret. The CGA resolution was a whopping 640×200, while the MDA was slightly better at 720×350. If you did the Hercules card, you got the same 720×350 MDA resolution, but also a 720×348 graphics mode. Besides that, you could keep your monitor (don’t forget that, in those days, monitors typically required a specific input and were costly).

These cards were huge and full of chips, although the 1986 version of the Hercules did have an ASIC, which helped. If you wrote software back in those days, you might remember that the CGA buffer was at address B800:0000, but monochrome cards were at B000:0000. That was inconvenient, but it did allow the wealthy to have two monitors: a color and a monochrome.

[The 8-bit Guy] likes games, and he shows off games that supported Hercules versus running them in color. It turns out, just because a game or other piece of software could run on Hercules graphics didn’t mean it should. Some games did a good job. Others just scaled up their CGA graphics with predictably sketchy results. There was even a software solution, and at the speeds of a PC, you can imagine how that went, too.

[The 8-bit Guy] has talked to us about old graphics before, and points out that if you knew a few tricks, CGA wasn’t as bad as you think. Then things evolved to super CGA, EGA, VGA, and beyond.

youtube.com/embed/hblpFQ2ObCg?…


hackaday.com/2025/10/27/rememb…


Crypto wasted: BlueNoroff’s ghost mirage of funding and jobs



Introduction


Primarily focused on financial gain since its appearance, BlueNoroff (aka. Sapphire Sleet, APT38, Alluring Pisces, Stardust Chollima, and TA444) has adopted new infiltration strategies and malware sets over time, but it still targets blockchain developers, C-level executives, and managers within the Web3/blockchain industry as part of its SnatchCrypto operation. Earlier this year, we conducted research into two malicious campaigns by BlueNoroff under the SnatchCrypto operation, which we dubbed GhostCall and GhostHire.

GhostCall heavily targets the macOS devices of executives at tech companies and in the venture capital sector by directly approaching targets via platforms like Telegram, and inviting potential victims to investment-related meetings linked to Zoom-like phishing websites. The victim would join a fake call with genuine recordings of this threat’s other actual victims rather than deepfakes. The call proceeds smoothly to then encourage the user to update the Zoom client with a script. Eventually, the script downloads ZIP files that result in infection chains deployed on an infected host.

GhostCall campaign attack flow
GhostCall campaign attack flow

In the GhostHire campaign, BlueNoroff approaches Web3 developers and tricks them into downloading and executing a GitHub repository containing malware under the guise of a skill assessment during a recruitment process. After initial contact and a brief screening, the user is added to a Telegram bot by the recruiter. The bot sends either a ZIP file or a GitHub link, accompanied by a 30-minute time limit to complete the task, while putting pressure on the victim to quickly run the malicious project. Once executed, the project downloads a malicious payload onto the user’s system. The payload is specifically chosen according to the user agent, which identifies the operating system being used by the victim.

GhostHire campaign attack flow
GhostHire campaign attack flow

We observed the actor utilizing AI in various aspects of their attacks, which enabled them to enhance productivity and meticulously refine their attacks. The infection scheme observed in GhostHire shares structural similarities of infection chains with the GhostCall campaign, and identical malware was detected in both.

We have been tracking these two campaigns since April 2025, particularly observing the continuous emergence of the GhostCall campaign’s victims on platforms like X. We hope our research will help prevent further damage, and we extend our gratitude to everyone who willingly shared relevant information.

The relevant information about GhostCall has already been disclosed by Microsoft, Huntability, Huntress, Field Effect, and SentinelOne. However, we cover newly discovered malware chains and provide deeper insights.

The GhostCall campaign


The GhostCall campaign is a sophisticated attack that uses fake online calls with the threat actors posing as fake entrepreneurs or investors to convince targets. GhostCall has been active at least since mid-2023, potentially following the RustBucket campaign, which marked BlueNoroff’s full-scale shift to attacking macOS systems. Windows was the initial focus of the campaign; it soon shifted to macOS to better align with the targets’ predominantly macOS environment, leveraging deceptive video calls to maximize impact.

The GhostCall campaign employs sophisticated fake meeting templates and fake Zoom updaters to deceive targets. Historically, the actor often used excuses related to IP access control, but shifted to audio problems to persuade the target to download the malicious AppleScript code to fix it. Most recently, we observed the actor attempting to transition the target platform from Zoom to Microsoft Teams.

During this investigation, we identified seven distinct multi-component infection chains, a stealer suite, and a keylogger. The modular stealer suite gathers extensive secret files from the host machine, including information about cryptocurrency wallets, Keychain data, package managers, and infrastructure setups. It also captures details related to cloud platforms and DevOps, along with notes, an API key for OpenAI, collaboration application data, and credentials stored within browsers, messengers, and the Telegram messaging app.

Initial access


The actor reaches out to targets on Telegram by impersonating venture capitalists and, in some cases, using compromised accounts of real entrepreneurs and startup founders. In their initial messages, the attackers promote investment or partnership opportunities. Once contact is established with the target, they use Calendly to schedule a meeting and then share a meeting link through domains that mimic Zoom. Sometimes, they may send the fake meeting link directly via messages on Telegram. The actor also occasionally uses Telegram’s hyperlink feature to hide phishing URLs and disguise them as legitimate URLs.

Overall behavior of the phishing site
Overall behavior of the phishing site

Upon accessing the fake site, the target is presented with a page carefully designed to mirror the appearance of Zoom in a browser. The page uses standard browser features to prompt the user to enable their camera and enter their name. Once activated, the JavaScript logic begins recording and sends a video chunk to the /upload endpoint of the actor’s fake Zoom domain every second using the POST method.

Initial page mimicking Zoom call joining behavior
Initial page mimicking Zoom call joining behavior

Once the target joins, a screen resembling an actual Zoom meeting appears, showing the video feeds of three participants as if they were part of a real session. Based on OSINT we were monitoring, many victims initially believed the videos they encountered were generated by deepfake or AI technology. However, our research revealed that these videos were, in fact, real recordings secretly taken from other victims who had been targeted by the same actor using the same method. Their webcam footage had been unknowingly recorded, then uploaded to attacker-controlled infrastructure, and reused to deceive other victims, making them believe they were participating in a genuine live call. When the video replay ended, the page smoothly transitioned to showing that user’s profile image, maintaining the illusion of a live call.

Fake Zoom meeting
Fake Zoom meeting

Approximately three to five seconds later, an error message appears below the participants’ feeds, stating that the system is not functioning properly and prompting them to download a Zoom SDK update file through a link labeled “Update Now”. However, rather than providing an update, the link downloads a malicious AppleScript file onto macOS and triggers a popup for troubleshooting on Windows.

Clicking the link on macOS (left) and on Windows (right)
Clicking the link on macOS (left) and on Windows (right)

On macOS, clicking the link directly downloads an AppleScript file named Zoom SDK Update.scpt from the actor’s domain. A small “Downloads” coach mark is also displayed, subtly encouraging the user to execute the script by imitating genuine Apple feedback. On Windows, the attack uses the ClickFix technique, where a modal window appears with a seemingly harmless code snippet from a legitimate domain. However, any attempt to copy the code—via the Copy button, right-click and Copy, or Ctrl+C—results in a malicious one-liner being placed in the clipboard instead.

Malicious code upon ClickFix
Malicious code upon ClickFix

We observed that the actor implemented beaconing activity within the malicious web page to track victim interactions. The page reports back to their backend infrastructure—likely to assess the success or failure of the targeting. This is accomplished through a series of automatically triggered HTTP GET requests when the victim performs specific actions, as outlined below.

EndpointTriggerPurpose
/join/{id}/{token}User clicks Join on the pre-join screenTrack whether the victim entered the meeting
/action/{id}/{token}Update / Troubleshooting SDK modal is shownTrack whether the victim clicked on the update prompt
/action1/{id}/{token}User uses any copy-and-paste method to copy modal window contentsConfirm the clipboard swap likely succeeded
/action2/{id}/{token}User closes modalTrack whether the victim closed the modal

In September 2025, we discovered that the group is shifting from cloning the Zoom UI in their attacks to Microsoft Teams. The method of delivering malware remains unchanged. Upon entering the meeting room, a prompt specific to the target’s operating system appears almost immediately after the background video starts—unlike before. While this is largely similar to Zoom, macOS users also see a separate prompt asking them to download the SDK file.

General fake prompt to update the SDK file (left) and Windows-specific (right)
General fake prompt to update the SDK file (left) and Windows-specific (right)

We were able to obtain the AppleScript (Zoom SDK Update.scpt) the actor claimed was necessary to resolve the issue, which was already widely known through numerous research studies as the entry point for the attack. The script is disguised as an update for the Zoom Meeting SDK and contains nearly 10,000 blank lines that obscure its malicious content. Upon execution, it fetches another AppleScript, which acts as a downloader, from a different fake link using a curl command. There are numerous variants of this “troubleshooting” AppleScript, differing in filename, user agent, and contents.

Snippets of the AppleScript disguised as a Zoom SDK update
Snippets of the AppleScript disguised as a Zoom SDK update

If the targeted macOS version is 11 (Monterey) or later, the downloader AppleScript installs a fake application disguised as Zoom or Microsoft Teams into the /private/tmp directory. The application attempts to mimic a legitimate update for Zoom or Teams by displaying a password input popup. Additionally, it downloads a next-stage AppleScript, which we named “DownTroy”. This script is expected to check stored passwords and use them to install additional malware with root privileges. We cautiously assess that this would be an evolved version of the older one, disclosed by Huntress.

Moreover, the downloader script includes a harvesting function that searches for files associated with password management applications (such as Bitwarden, LastPass, 1Password, and Dashlane), the default Notes app (group.com.apple.notes), note-taking apps like Evernote, and the Telegram application installed on the device.

Another notable feature of the downloader script is a bypass of TCC (Transparency, Consent, and Control), a macOS system designed to manage user consent for accessing sensitive resources such as the camera, microphone, AppleEvents/automation, and protected folders like Documents, Downloads, and Desktop. The script works by renaming the user’s com.apple.TCC directory and then performing offline edits to the TCC.db database. Specifically, it removes any existing entries in the access table related to a client path to be registered in the TCC database and executes INSERT OR REPLACE statements. This process enables the script to grant AppleEvents permissions for automation and file access to a client path controlled by the actor. The script inserts rows for service identifiers used by TCC, including kTCCServiceAppleEvents, kTCCServiceSystemPolicyDocumentsFolder, kTCCServiceSystemPolicyDownloadsFolder, and kTCCServiceSystemPolicyDesktopFolder, and places a hex-encoded code-signature blob (in the csreq style) in the database to meet the requirement for access to be granted. This binary blob must be bound to the target app’s code signature and evaluated at runtime. Finally, the script attempts to rename the TCC directory back to its original name and calls tccutil reset DeveloperTool.

In the sample we analyzed, the client path is ~/Library/Google/Chrome Update —the location the actor uses for their implant. In short, this allows the implant to control other applications, access data from the user’s Documents, Downloads, and Desktop folders, and execute AppleScripts—all without prompting for user consent.

Initial infection flow
Initial infection flow

Multi-stage execution chains


According to our telemetry and investigation into the actor’s infrastructure, DownTroy would download ZIP files that contain various individual infection chains from the actor’s centralized file hosting server. Although we haven’t observed how the SysPhon and the SneakMain chain were installed, we suspect they would’ve been downloaded in the same manner. We have identified not only at least seven multi-stage execution chains retrieved from the server, but also various malware families installed on the infected hosts, including keyloggers and stealers downloaded by CosmicDoor and RooTroy chains.

NumExecution chain/MalwareComponentsSource
1ZoomClutch(standalone)File hosting server
2DownTroy v1 chainLauncher, Dropper, DownTroy.macOSFile hosting server
3CosmicDoor chainInjector, CosmicDoor.macOS in NimFile hosting server
4RooTroy chainInstaller, Loader, Injector, RooTroy.macOSFile hosting server
5RealTimeTroy chainInjector, RealTimeTroy.macOS in GoUnknown, obtained from multiscanning service
6SneakMain chainInstaller, Loader, SneakMain.macOSUnknown, obtained from infected hosts
7DownTroy v2 chainInstaller, Loader, Dropper, DownTroy.macOSFile hosting server
8SysPhon chainInstaller, SysPhone backdoorUnknown, obtained from infected hosts

The actor has been introducing new malware chains by adapting new programming languages and developing new components since 2023. Before that, they employed standalone malware families, but later evolved into a modular structure consisting of launchers, injectors, installers, loaders, and droppers. This modular approach enables the malicious behavior to be divided into smaller components, making it easier to bypass security products and evade detection. Most of the final payloads in these chains have the capability to download additional AppleScript files or execute commands to retrieve subsequent-stage payloads.

Interestingly, the actor initially favored Rust for writing malware but ultimately switched to the Nim language. Meanwhile, other programming languages like C++, Python, Go, and Swift have also been utilized. The C++ language was employed to develop the injector malware as well as the base application within the injector, but the application was later rewritten in Swift. Go was also used to develop certain components of the malware chain, such as the installer and dropper, but these were later switched to Nim as well.

ZoomClutch/TeamsClutch: the fake Zoom/Teams application


During our research of a macOS intrusion on a victim’s machine, we found a suspicious application resembling a Zoom client executing from an atypical, writable path — /tmp/zoom.app/Contents/MacOS — rather than the standard /Applications directory. Analysis showed that the binary was not an official Zoom build but a custom implant compiled on macOS 14.5 (24F74) with Xcode 16 beta 2 (16C5032a) against the macOS 15.2 SDK. The app is ad‑hoc signed, and its bundle identifier is hard‑coded to us.zoom.com to mimic the legitimate client.

The implant is written in Swift and functions as a macOS credentials harvester, disguised as the Zoom videoconferencing application. It features a well-developed user interface using Swift’s modern UI frameworks that closely mimics the Zoom application icon, Apple password prompts, and other authentic elements.

ZoomClutch prompting the victim to enter their password
ZoomClutch prompting the victim to enter their password

ZoomClutch steals macOS passwords by displaying a fake Zoom dialog, then sends the captured credentials to the C2 server. However, before exfiltrating the data, ZoomClutch first validates the credentials locally using Apple’s Open Directory (OD) to filter out typos and incorrect entries, mirroring macOS’s own authentication flow. OD manages accounts and authentication processes for both local and external directories. Local user data sits at /var/db/dslocal/nodes/Default/users/ as plists with PBKDF2‑SHA512 hashes. The malware creates an ODSession, then opens a local ODNode via kODNodeTypeLocalNodes (0x2200/8704) to scope operations to /Local/Default.

It subsequently calls verifyPassword:error: to check the password, which re-hashes the input password using the stored salt and iterations, returning true if there is a match. If verification fails, ZoomClutch re-prompts the user and shortly displays a “wrong password” popup with a shake animation. On success, it hides the dialog, displays a “Zoom Meeting SDK has been updated successfully” message, and the validated credentials are covertly sent to the C2 server.

ZoomClutch success window displayed after password validation
ZoomClutch success window displayed after password validation

All passwords entered in the prompt are logged to ~/Library/Logs/keybagd_events.log. The malware then creates a file at ~/Library/Logs/<username>_auth.log to store the verified password in plain text. This file is subsequently uploaded to a C2 URL using curl.

With medium-high confidence, we assess that the malware was part of BlueNoroff’s workflow needed to initiate the execution flow outlined in the subsequent infection chains.

The TeamsClutch malware that mimics a legitimate Microsoft Teams functions similarly to ZoomClutch, but with its logo and some text elements replaced.

TeamsClutch authentication and success windows
TeamsClutch authentication and success windows

DownTroy v1 chain


The DownTroy v1 chain consists of a launcher and a dropper, which ultimately loads the DownTroy.macOS malware written in AppleScript.

  • Dropper: a dropper file named "trustd", written in Go
  • Launcher: a launcher file named "watchdog", written in Go
  • Final payload: DownTroy.macOS written in AppleScript

The dropper operates in two distinct modes: initialization and operational. When the binary is executed with a machine ID (mid) as the sole argument, it enters initialization mode and updates the configuration file located at ~/Library/Assistant/CustomVocabulary/com.applet.safari/local_log using the provided mid and encrypts it with RC4. It then runs itself without any arguments to transition into operational mode. In case the binary is launched without any arguments, it enters operational mode directly. In this mode, it retrieves the previously saved configuration and uses the RC4 key NvZGluZz0iVVRGLTgiPz4KPCF to decrypt it. It is important to note that the mid value must first be included in the configuration during initialization mode, as it is essential for subsequent actions.

It then decodes a hard-coded, base64-encoded string associated with DownTroy.macOS. This AppleScript contains a placeholder value, %mail_id%, which is replaced with the initialized mid value from the configuration. The modified script is saved to a temporary file named local.lock within the <BasePath> directory from the configuration, with 0644 permissions applied, meaning that only the script owner can modify it. The malware then uses osascript to execute DownTroy.macOS and sets Setpgid=1 to isolate the process group. DownTroy.macOS is responsible for downloading additional scripts from its C2 server until the system is rebooted.

The dropper implements a signal handling procedure to monitor for termination attempts. Initially, it reads the entire trustd (itself) and watchdog binary files into memory, storing them in a buffer before deleting the original files. Upon receiving a SIGINT or SIGTERM signal indicating that the process should terminate, the recovery mechanism activates to maintain persistence. While SIGINT is a signal used to interrupt a running process by the user from the terminal using the keyboard shortcut Ctrl + C, SIGTERM is a signal that requests a process to terminate gracefully.

The recovery mechanism begins by recreating the <BasePath> directory with intentionally insecure 0777 permissions (meaning that all users have the read, write, and execute permissions). Next, it writes both binaries back to disk from memory, assigning them executable permissions (0755), and also creates a plist file to ensure the automatic restart of this process chain.

  • trustd: trustd in the <BasePath> directory
  • watchdog: ~/Library/Assistant/SafariUpdate and watchdog in the <BasePath> directory
  • plist: ~/Library/LaunchAgents/com.applet.safari.plist

The contents of the plist file are hard-coded into the dropper in base64-encoded form. When decoded, the template represents a standard macOS LaunchAgent plist containing the placeholder tokens #path and #label. The malware replaces these tokens to customize the template. The final plist configuration ensures the launcher automatic execution by setting RunAtLoad to true (starts at login), KeepAlive to true (restarts if terminated), and LaunchOnlyOnce to true.

  • #path is replaced with the path to the copied watchdog
  • #label is replaced with com.applet.safari to masquerade as a legitimate Safari-related component

The main feature of the discovered launcher is its ability to load the same configuration file located at ~/Library/Assistant/CustomVocabulary/com.applet.safari/local_log. It reads the file and uses the RC4 algorithm to decrypt its contents with the same hard-coded 25-byte key: NvZGluZz0iVVRGLTgiPz4KPCF. After decryption, the loader extracts the <BasePath> value from the JSON object, which specifies the location of the next payload. It then executes a file named trustd from this path, disguising it as a legitimate macOS system process.

We identified another version of the loader, distinguished by the configuration path that contains the <BasePath> — this time, the configuration file was located at /Library/Graphics/com.applet.safari/local_log. The second version is used when the actor has gained root-level permissions, likely achieved through ZoomClutch during the initial infection.

CosmicDoor chain


The CosmicDoor chain begins with an injector malware that we have named “GillyInjector” written in C++, which was also described by Huntress and SentinelOne. This malware includes an encrypted baseApp and an encrypted malicious payload.

  • Injector: GillyInjector written in C++
  • BaseApp: a benign application written in C++ or Swift
  • Final payload: CosmicDoor.macOS written in Nim

The syscon.zip file downloaded from the file hosting server contains the “a” binary that has been identified as GillyInjector designed to run a benign Mach-O app and inject a malicious payload into it at runtime. Both the injector and the benign application are ad-hoc signed, similar to ZoomClutch. GillyInjector employs a technique known as Task Injection, a rare and sophisticated method observed on macOS systems.

The injector operates in two modes: wiper mode and injector mode. When executed with the --d flag, GillyInjector activates its destructive capabilities. It begins by enumerating all files in the current directory and securely deleting each one. Once all files in the directory are unrecoverably wiped, GillyInjector proceeds to remove the directory itself. When executed with a filename and password, GillyInjector operates as a process injector. It creates a benign application with the given filename in the current directory and uses the provided password to derive an AES decryption key.

The benign Mach-O application and its embedded payload are encrypted with a customized AES-256 algorithm in ECB mode (although similar to the structure of the OFB mode) and then base64-encoded. To decrypt, the first 16 bytes of the encoded string are extracted as the salt for a PBKDF2 key derivation process. This process uses 10,000 iterations, and a user-provided password to generate a SHA-256-based key. The derived key is then used to decrypt the base64-decoded ciphertext that follows.

Base application and payload decryption
Base application and payload decryption

The ultimately injected payload is identified as CosmicDoor.macOS, written in Nim. The main feature of CosmicDoor is that it communicates with the C2 server using the WSS protocol, and it provides remote control functionality such as receiving and executing commands.

Our telemetry indicates that at least three versions of CosmicDoor.macOS have been detected so far, each written in different cross-platform programming languages, including Rust, Python, and Nim. We also discovered that the Windows variant of CosmicDoor was developed in Go, demonstrating that the threat actor has actively used this malware across both Windows and macOS environments since 2023. Based on our investigation, the development of CosmicDoor likely followed this order: CosmicDoor.Windows in Go → CosmicDoor.macOS in Rust → CosmicDoor in Python → CosmicDoor.macOS in Nim. The Nim version, the most recently identified, stands out from the others primarily due to its updated execution chain, including the use of GillyInjector.

Except for the appearance of the injector, the differences between the Windows version and other versions are not significant. On Windows, the fourth to sixth characters of all RC4 key values are initialized to 123. In addition, the CosmicDoor.macOS version, written in Nim, has an updated value for COMMAND_KEY.

CosmicDoor.macOS in NimCosmicDoor in Python, CosmicDoor.macOS in RustCosmicDoor.Windows in Go
SESSION_KEY3LZu5H$yF^FSwPu3SqbL*sK3LZu5H$yF^FSwPu3SqbL*sK3LZ123$yF^FSwPu3SqbL*sK
COMMAND_KEYlZjJ7iuK2qcmMW6hacZOw62jubk$sb3xzCJ%ydILi@W8FHjub123b3xzCJ%ydILi@W8FH
AUTH_KEYEj7bx@YRG2uUhya#50Yt*aoEj7bx@YRG2uUhya#50Yt*aoEj7123YRG2uUhya#50Yt*ao

The same command scheme is still in use, but other versions implement only a few of the commands available on Windows. Notably, commands such as 345, 90, and 45 are listed in the Python implementation of CosmicDoor, but their actual code has not been implemented.

CommandDescriptionCosmicDoor.macOS in Rust and NimCosmicDoor in PythonCosmicDoor.Windows in Go
234Get device informationOOO
333No operationO
44Update configurationO
78Get current work directoryOOO
1Get interval timeO
12Execute commandsOOO
34Set current work directoryOOO
345(DownExec)O (but, not implemented)
90(Download)O (but, not implemented)
45(Upload)O (but, not implemented)
SilentSiphon: a stealer suite for harvesting


During our investigation, we discovered that CosmicDoor downloads a stealer suite composed of various bash scripts, which we dubbed “SilentSiphon”. In most observed infections, multiple bash shell scripts were created on infected hosts shortly after the installation of CosmicDoor. These scripts were used to collect and exfiltrate data to the actor’s C2 servers.

The file named upl.sh functions as an orchestration launcher, which aggregates multiple standalone data-extraction modules identified on the victim’s system.
upl.sh
├── cpl.sh
├── ubd.sh
├── secrets.sh
├── uad.sh
├── utd.sh
The launcher first uses the command who | tail -n1 | awk '{print $1}' to identify the username of the currently logged-in macOS user, thus ensuring that all subsequent file paths are resolved within the ongoing active session—regardless of whether the script is executed by another account or via Launch Agents. However, both the hard-coded C2 server and the username can be modified with the -h and -u flags, a feature consistent with other modules analyzed in this research. The orchestrator executes five embedded modules located in the same directory, removing each immediately after it completes exfiltration.

The stealer suite harvests data from the compromised host as follows:

  1. upl.sh is the orchestrator and Apple Notes stealer.
    It targets Apple Notes at /private/var/tmp/group.com.apple.notes.
    It stores the data at /private/var/tmp/notes_<username>.
  2. cpl.sh is the browser extension stealer module.
    It targets:
  • Local storage for extensions: the entire “Local Extension Settings” directory of Chromium-based web browsers, such as Chrome, Brave, Arc, Edge, and Ecosia
  • Browser’s built-in database: directories corresponding to Exodus Web3 Wallet, Coinbase Wallet extension, Crypto.com Onchain Extension, Manta Wallet, 1Password, and Sui wallet in the “IndexedDB” directory
  • Extension list: the list of installed extensions in the “Extensions” directory
    Stores the data at /private/var/tmp/cpl_<username>/<browser>/*
ubd.sh is the browser credentials and macOS Keychains stealer module.
It targets:
  • Credentials stored in the browsers: Local State, History, Cookies, Sessions, Web Data, Bookmarks, Login Data, Session Storage, Local Storage, and IndexedDB directories of Chromium-based web browsers, such as Chrome, Brave, Arc, Edge, and Ecosia
  • Credentials in the Keychain: /Library/Keychains/System.keychain and ~/Library/Keychains/login.keychain-db
    It stores the data at /private/var/tmp/ubd_<username>/*
secrets.sh is the secrets stealer module.
It targets:
  • Version Control: GitHub (.config/gh), GitLab (.config/glab-cli), and Bitbucket (.bit/config)
  • Package manager: npm (.npmrc), Yarn (.yarnrc.yml), Python pip (.pypirc), RubyGems (.gem/credentials), Rust cargo (.cargo/credentials), and .NET Nuget (.nuget/NuGet.Config)
  • Cloud/Infrastructure: AWS (.aws), Google Cloud (.config/gcloud), Azure (.azure), Oracle Cloud (.oci), Akamai Linode (.config/linode-cli), and DigitalOcean API (.config/doctl/config.yaml)
  • Cloud Application Platform: Vercel (.vercel), Cloudflare (.wrangler/config), Netlify (.netfily), Stripe (.config/stripe/config.toml), Firebase (.config/configstore/firebase-tools.json), Twilio (.twilio-cli)
  • DevOps/IaC: CircleCI (.circleci/cli.yml), Pulumi (.pulumi/credentials.json), and HashiCorp (.vault-token)
  • Security/Authentication: SSH (.ssh) and FTP/cURL/Wget (.netrc)
  • Blockchain Related: Sui Blockchain (.sui), Solana (.config/solana), NEAR Blockchain (.near-credentials), Aptos Blockchain (.aptos), and Algorand (.algorand)
  • Container Related: Docker (.docker) and Kubernetes (.kube)
  • AI: OpenAI (.openai)
    It stores the data at /private/var/tmp/secrets_backup_<current time>/<username>/*
uad.sh is the password‑vault stealer module
It targets:
  • Password manager: 1Password 8, 1Password 7, Bitwarden, LastPass, and Dashlane
  • Note-taking: Evernote and Notion
  • Collaboration suites: Slack
  • Messenger: Skype (inactive), WeChat (inactive), and WhatsApp (inactive)
  • Cryptocurrency: Ledger Live, Hiro StacksWallet, Tonkeeper, MyTonWallet, and MetaMask (inactive)
  • Remote Monitoring and Management: AnyDesk
    It stores the data at /private/var/tmp/<username>_<target application>_<current time>/*
utd.sh is the Telegram stealer module
It targets:
  • On macOS version 14 and later:
    • Telegram’s cached resources, such as chat history and media files
    • Encrypted geolocation cache
    • AES session keys used for account takeover
    • Legacy sandbox cache


  • On macOS versions earlier than 14:
    • List of configured Telegram accounts
    • Export-key vault
    • Full chat DB, messages, contacts, files, and cached media
      It stores the data at /private/var/tmp/Telegrams_<username>/*


These extremely extensive targets allow the actor to expand beyond simple credentials to encompass their victims’ entire infrastructure. This includes Telegram accounts exploitable for further attacks, supply chain configuration details, and collaboration tools revealing personal notes and business interactions with other users. Notably, the attackers even target the .openai folder to secretly use ChatGPT with the user’s account.

The collected information is immediately archived with the ditto -ck command and uploaded to the initialized C2 server via curl command, using the same approach as in ZoomClutch.


RooTroy chain


We identified a ZIP archive downloaded from the file hosting server that contains a three-component toolset. The final payload, RooTroy.macOS, was also documented in the Huntress’s blog, but we were able to obtain its full chain. The archive includes the following:

  • Installer: the primary installer file named "rtv4inst", written in Go
  • Loader: an auxiliary loader file named "st" and identified as the Nimcore loader, written in Nim
  • Injector: an injector file named "wt", which is identified as GillyInjector, written in C++
  • Final payload: RooTroy.macOS, written in Go

Upon the execution of the installer, it immediately checks for the presence of other components and terminates if any are missing. Additionally, it verifies that it has accepted at least two command-line arguments to function properly, as follows.
rvt4inst <MID> <C2> [<Additional C2 domains…>]


  • MID (Machine ID): unique identifier for victim tracking
  • C2: primary command‑and‑control domain
  • Additional C2 values can be supplied

On the first launch, the installer creates several directories and files that imitate legitimate macOS components. Note that these paths are abused only for camouflage; none are genuine system locations.

NumPathRole
1/Library/Google/Cache/.cfgConfiguration
2/Library/Application Support/Logitechs/versionsNot identified
3/Library/Application Support/Logitechs/bin/Update CheckFinal location of the Nimcore loader (st)
4/Library/Storage/DiskbaseApp’s potential location 1
5/Library/Storage/MemorybaseApp’s potential location 2
6/Library/Storage/CPU/cpumonsFinal location of GillyInjector (wt)
7/Library/LaunchDaemons/<bundle ID>.plist.plist path for launching st
8/private/var/tmp/.lesshstContains the .plist path

The installer uses the hard‑coded key 3DD226D0B700F33974F409142DEFB62A8CD172AE5F2EB9BEB7F5750EB1702E2A to serialize its runtime parameters into an RC4‑encrypted blob. The resulting encrypted value is written as .cfg inside /Library/Google/Cache/.

The installer then implements a naming mechanism for the plist name through dynamic bundle ID generation, where it scans legitimate applications in /Applications to create convincing identifiers. It enumerates .app bundles, extracts their names, and combines them with service-oriented terms like “agent”, “webhelper”, “update”, “updater”, “startup”, “service”, “cloudd”, “daemon”, “keystone.agent”, “update.agent”, or “installer” to construct bundle IDs, such as “com.safari.update” or “com.chrome.service”. If the bundle ID generation process fails for any reason, the malware defaults to “com.apple.updatecheck” as a hard-coded fallback identifier.

The installer then deploys the auxiliary binaries from the ZIP extraction directory to their final system locations. The Nimcore loader (st) is copied to /Library/Application Support/Logitechs/bin/Update Check. The GillyInjector binary is renamed to cpumons in the /Library/Storage/CPU path. Both files receive 0755 permissions to ensure executability.

Later, a persistence mechanism is implemented through macOS Launch Daemon plists. The plist template contains four placeholder fields that are filled in during generation:

  • The Label field receives the dynamically generated bundle ID.
  • The SERVER_AUTH_KEY environment variable is populated with the GillyInjector’s path /Library/Storage/CPU/cpumons that is RC4-encrypted using the hard-coded key "yniERNUgGUHuAhgCzMAi" and then base64-encoded.
  • The CLIENT_AUTH_KEY environment variable receives the hard-coded value "..".
  • The Program field points to the installed Nimcore loader’s path.

The installer completes the persistence setup by using legitimate launchctl commands to activate the persistence mechanism, ensuring the Nimcore loader is executed. It first runs “launchctl unload <bundle ID>.plist” on any existing plist with the same name to remove previous instances, then executes “launchctl load <bundle ID>.plist” to activate the new persistence configuration through /bin/zsh -c.

The second stage in this execution chain is the Nimcore loader, which is deployed by the installer and specified in the Program field of the plist file. This loader reads the SERVER_AUTH_KEY environment variable with getenv(), base64-decodes the value, and decrypts it with the same RC4 key used by the installer. The loader is able to retrieve the necessary value because both SERVER_AUTH_KEY and CLIENT_AUTH_KEY are provided in the plist file and filled in by the installer. After decryption, it invokes posix_spawn() to launch GillyInjector.

GillyInjector is the third component in the RooTroy chain and follows the same behavior as described in the CosmicDoor chain. In this instance, however, the password used for generation is hard-coded as xy@bomb# within the component. The baseApp is primarily responsible for displaying only a simple message and acts as a carrier to keep the injected final payload in memory during runtime.

The final payload is identified as RooTroy.macOS, written in Go. Upon initialization, RooTroy.macOS reads its configuration from /Library/Google/Cache/.cfg, a file created by the primary installer, and uses the RC4 algorithm with the same 3DD226D0B700F33974F409142DEFB62A8CD172AE5F2EB9BEB7F5750EB1702E2A key to decrypt it. If it fails to read the config file, it removes all files at /Library/Google/Cache and exits.

As the payload is executed at every boot time via a plist setup, it prevents duplicate execution by checking the .pid file in the same directory. If a process ID is found in the file, it terminates the corresponding process and writes the current process ID into the file. Additionally, it writes the string {"rt": "4.0.0."} into the .version file, also located in the same directory, to indicate the current version. This string is encrypted using RC4 with the key C4DB903322D17C8CBF1D1DB55124854C0B070D6ECE54162B6A4D06DF24C572DF.

This backdoor executes commands from the /Library/Google/Cache/.startup file line by line. Each line is executed via /bin/zsh -c "[command]" in a separate process. It also monitors the user’s login status and re-executes the commands when the user logs back in after being logged out.

Next, RooTroy collects and lists all mounted volumes and running processes. It then enters an infinite loop, repeatedly re-enumerating the volumes to detect any changes—such as newly connected USB drives, network shares, or unmounted devices—and uses a different function to identify changes in the list of processes since the last iteration. It sends the collected information to the C2 server via a POST request to /update endpoint with Content-Type: application/json.

The data field in the response from the C2 server is executed directly via AppleScript with osascript -e. When both the url and auth fields are present, RooTroy connects to the URL with GET method and the Authorization header to retrieve additional files. Then it sleeps for five seconds and repeats the process.

Additional files are loaded as outlined below:

  1. Generate a random 10-character file name in the temp directory: /private/tmp/[random-chars]{10}.zip.
  2. Save the downloaded data to that file path.
  3. Extract the ZIP file using ditto -xk /private/tmp/[random-chars]{10}.zip /private/tmp/[random-chars]{10}.
  4. Make the file executable using chmod +x /private/tmp/[random-chars]{10}/install.
  5. Likely install additional components by executing /bin/zsh /private/tmp/[random-chars]{10}/install /private/tmp/[random-chars]{10} /private/tmp/[random-chars]{10}/.result.
  6. Check the .result file for the string “success”.
  7. Send result to /report endpoint.
  8. Increment the cid field and save the configuration.
  9. Clean up all temp files.

We also observed the RooTroy backdoor deploying files named keyboardd to the /Library/keyboard directory and airmond to the /Library/airplay path, which were confirmed to be a keylogger and an infostealer.

RealTimeTroy chain


We recently discovered GillyInjector containing an encrypted RealTimeTroy.macOS payload from the public multiscanning service.

  • Injector: GillyInjector written in C++
  • baseApp: the file named “ChromeUpdates” in the same ZIP file (not secured)
  • Final payload: RealTimeTroy.macOS, written in Go

RealTimeTroy is a straightforward backdoor written in the Go programming language that communicates with a C2 server using the WSS protocol. We have secured both versions of this malware. In the second version, the baseApp named “ChromeUpdates” should be bundled along with the injector into a ZIP file. While the baseApp data is included in the same manner as in other GillyInjector instances, it is not actually used. Instead, the ChromeUpdates file is copied to the path specified as the first parameter and executed as the base application for the injection.

This will be explained in more detail in the GhostHire campaign section as the payload RealTimeTroy.macOS performs actions identical to the Windows version, with some differences in the commands. Like the Windows version, it injects the payload upon receiving command 16. However, it uses functionality similar to GillyInjector to inject the payload received from the C2. The password for AES decryption and the hardcoded baseApp within RealTimeTroy have been identified as being identical to the ones contained within the existing GillyInjector (MD5 76ACE3A6892C25512B17ED42AC2EBD05).

Additionally, two new commands have been added compared to the Windows version, specifically for handling commands via the pseudo-terminal. Commands 20 and 21 are used to respectively spawn and exit the terminal, which is used for executing commands received from command 8.

We found the vcs.time metadata within the second version of RealTimeTroy.macOS, which implies the commit time of this malware, and this value was set to 2025-05-29T12:22:09Z.

SneakMain chain


During our investigation into various incidents, we were able to identify another infection chain involving the macOS version of SneakMain in the victims’ infrastructures. Although we were not able to secure the installer malware, it would operate similar to the RooTroy chain, considering the behavior of its loader.

  • Installer: the primary installer (not secured)
  • Loader: Identified as Nimcore loader, written in Nim
  • Final payload: SneakMain.macOS, written in Nim

The Nimcore loader reads the SERVER_AUTH_KEY and CLIENT_AUTH_KEY environment variables upon execution. Given the flow of the RooTroy chain, we can assume that these values are provided through the plist file installed by an installer component. Next, the values are base64-decoded and then decrypted using the RC4 algorithm with the hard-coded key vnoknknklfewRFRewfjkdlIJDKJDF, which is consistently used throughout the SneakMain chain. The decrypted SERVER_AUTH_KEY value should represent the path to the next payload to be executed by the loader, while the decrypted CLIENT_AUTH_KEY value is saved to the configuration file located at /private/var/tmp/cfg.

We have observed that this loader was installed under the largest number of various names among malware as follows:

  • /Library/Application Support/frameworks/CloudSigner
  • /Library/Application Support/frameworks/Microsoft Excel
  • /Library/Application Support/frameworks/Hancom Office HWP
  • /Library/Application Support/frameworks/zoom.us
  • /Library/Application Support/loginitems/onedrive/com.onedrive.updater

The payload loaded by the Nimcore loader has been identified as SneakMain.macOS, written in the Nim programming language. Upon execution, it reads its configuration from /private/var/tmp/cfg, which is likely created by the installer. The configuration’s original contents are recovered through RC4 decryption with the same key and base64 decoding. In the configuration, a C2 URL and machine ID (mid) are concatenated with the pipe character (“|”). Then SneakMain.macOS constructs a JSON object containing this information, along with additional fields such as the malware’s version, current time, and process list, which is then serialized and sent to the C2 server. The request includes the header Content-Type: application/json.

As a response, the malware receives additional AppleScript commands and uses the osascript -e command to execute them. If it fails to fetch the response, it tries to connect to a default C2 server every minute. There are two URLs hard-coded into the malware: hxxps://file-server[.]store/update and hxxps://cloud-server[.]store/update.

One interesting external component of this chain is the configuration updater. This updater verifies the presence of the configuration file and updates the C2 server address to hxxps://flashserve[.]store/update with the same encryption method, while preserving the existing mid value. Upon a successful update, it outputs the updated configuration to standard output.

Beside the Nim-based chain, we also identified a previous version of the SneakMain.macOS binary, written in Rust. This version only consists of a launcher and the Rust-based SneakMain. It is expected to create a corresponding plist for regular execution, but this has not yet been discovered. The Rust version supports two execution modes:

  • With arguments: the malware uses the C2 server and mid as parameters
  • Without arguments: the malware loads an encrypted configuration file located at /Library/Scripts/Folder Actions/Check.plist

This version collects a process list only at a specific time during execution, without checking newly created or terminated processes. The collected list is then sent to the C2 server via a POST request to hxxps://chkactive[.]online/update, along with the current time (uid) and machine ID (mid), using the Content-Type: application/json header. Similarly, it uses the osascript -e command to execute commands received from the C2 server.

DownTroy v2 chain


The DownTroy.macOS v2 infection chain is the latest variant, composed of four components, with the payload being an AppleScript and the rest written in Nim. It was already covered by SentinelOne under the name of “NimDoor”. The Nimcore loader in this chain masquerades as Google LLC, using an intentional typo by replacing the “l” (lowercase “L”) in “Google LLC” with an “I” (uppercase “i”).

  • Installer: the primary installer file named "installer", written in Nim
  • Dropper: a dropper file named "CoreKitAgent", written in Nim
  • Loader: an auxiliary loader file named "GoogIe LLC" and identified as Nimcore loader, written in Nim
  • Final payload: DownTroy.macOS, written in AppleScript

The installer, which is likely downloaded and initiated by a prior malicious script, serves as the entry point for this process. The dropper receives an interrupt (SIGINT) or termination signal (SIGTERM) like in the DownTroy v1 chain, recreating the components on disk to recover them. Notably, while the previously described RooTroy and SneakMain chains do not have this recovery functionality, we have observed that they configure plist files to automatically execute the Nimcore loader after one hour if the process terminates, and they retain other components. This demonstrates how the actor strategically leverages DownTroy chains to operate more discreetly, highlighting some of the key differences between each chain.

The installer should be provided with one parameter and will exit if executed without it. It then copies ./CoreKitAgent and ./GoogIe LLC from the current location to ~/Library/CoreKit/CoreKitAgent and ~/Library/Application Support/Google LLC/GoogIe LLC, respectively. Inside of the installer, com.google.update.plist (the name of the plist) is hard-coded to establish persistence, which is later referenced by the dropper and loader. The installer then concatenates this value, the given parameter, and the dropper’s filename into a single string, separated by a pipe (“|”).

This string is encrypted using the AES algorithm with a hard-coded key and IV, and the resulting encrypted data is then saved to the configuration file.

  • Key: 5B77F83ECEFA0E32BA922F61C9EFFF7F755BA51A010DB844CA7E8AD3DB28650A
  • IV: 2B499EB3865A7EF17264D15252B7F73E
  • Configuration file path: /private/tmp/.config

It fulfills its function by ultimately executing the copied dropper located at ~/Library/CoreKit/CoreKitAgent.

The dropper in the DownTroy v2 chain uses macOS’s kqueue alongside Nim’s async runtime to manage asynchronous control flow, similar to CosmicDoor, the Nimcore loader in the RooTroy chain, and the Nim version of SneakMain.macOS. The dropper monitors events via kqueue, and when an event is triggered, it resumes the corresponding async tasks through a state machine managed by Nim. The primary functionality is implemented in state 1 of the async state machine.

The dropper then reads the encrypted configuration from /private/tmp/.config and decrypts it using the AES algorithm with the hard-coded key and IV, which are identical to those used in the installer. By splitting the decrypted data with a “|”, it extracts the loader path, the plist path, and the parameter provided to the installer. Next, it reads all the contents of itself and the loader, and deletes them along with the plist file in order to erase any trace of their existence. When the dropper is terminated, a handler function is triggered that utilizes the previously read contents to recreate itself and the loader file. In addition, a hard-coded hex string is interpreted as ASCII text, and the decoded content is written to the plist file path obtained from the configuration.

In the contents above, variables enclosed in %’s are replaced with different strings based on hard-coded values and configurations. Both authentication key variables are stored as encrypted strings with the same AES algorithm as used for the configuration.

  • %label% -> com.google.update
  • %server_auth_key% -> AES-encrypted selfpath (~/Library/CoreKit/CoreKitAgent)
  • %client_auth_key% -> AES-encrypted configuration
  • %program% -> loader path (~/Library/Application Support/Google LLC/GoogIe LLC)

The core functionality of this loader is to generate an AppleScript file using a hard-coded hex string and save it as .ses in the same directory. The script, identified as DownTroy.macOS, is designed to download an additional malicious script from a C2 server. It is nearly identical to the one used in the DownTroy v1 chain, with the only differences being the updated C2 servers and the curl command option.

We have observed three variants of this chain, all of which ultimately deploy the DownTroy.macOS malware but communicate with different C2 servers. Variant 1 communicates with the same C2 server as the one configured in the DownTroy v1 chain, though it appears in a hex-encoded form.

Config pathC2 serverCurl command
Variant 1/private/var/tmp/cfghxxps://bots[.]autoupdate[.]online:8080/testcurl –no-buffer -X POST -H
Variant 2/private/tmp/.confighxxps://writeup[.]live/test,
hxxps://safeup[.]store/test
curl –connect-timeout 30 –max-time 60 –no-buffer -X POST -H
Variant 3/private/tmp/.confighxxps://api[.]clearit[.]sbs/test,
hxxps://api[.]flashstore[.]sbs/test
curl –connect-timeout 30 –max-time 60 –no-buffer -X POST -H

The configuration file path used by variant 1 is the same as that of SneakMain. This indicates that the actor transitioned from the SneakMain chain to the DownTroy chain while enhancing their tools, and this variant’s dropper is identified as an earlier version that reads the plist file directly.

SysPhon chain


Unlike other infection chains, the SysPhon chain incorporates an older set of malware: the lightweight version of RustBucket and the known SugarLoader. According to a blog post by Field Effect, the actor deployed the lightweight version of RustBucket, which we dubbed “SysPhon”, alongside suspected SugarLoader malware and its loader, disguised as a legitimate Wi-Fi updater. Although we were unable to obtain the suspected SugarLoader malware sample or the final payloads, we believe with medium-low confidence that this chain is part of the same campaign by BlueNoroff. This assessment is based on the use of icloud_helper (a tool used for stealing user passwords) and the same initial infection vector as before: a fake Zoom link. It’s not surprising, as both malicious tools have already been attributed to BlueNoroff, indicating that the tools were adapted for the campaign.

Considering the parameters and behavior outlined in the blog post above, an AppleScript script deployed icloud_helper to collect the user’s password and simultaneously installed the SysPhon malware. The malware then downloaded SugarLoader, which connected to the C2 server and port pair specified as a parameter. This ultimately resulted in the download of a launcher to establish persistence. Given this execution flow and SugarLoader’s historical role in retrieving the KANDYKORN malware, it is likely that the final payload in the chain would be KANDYKORN or another fully-featured backdoor.

SysPhon is a downloader written in C++ that functions similarly to the third component of the RustBucket malware, which was initially developed in Rust and later rewritten in Swift. In March 2024, an ELF version of the third component compatible with Linux was uploaded to a multi-scanner service. In November 2024, SentinelOne reported on SysPhon, noting that it is typically distributed via a parent downloader that opens a legitimate PDF related to cryptocurrency topics. Shortly after the report, a Go version of SysPhon was also uploaded to the same scanner service.

SysPhon requires a C2 server specified as a parameter to operate. When executed, it generates a 16-byte random ID and retrieves the host name. It then enters a loop to conduct system reconnaissance by executing a series of commands:

Information to collectCommand
macOS versionsw_vers –ProductVersion
Current timezonedate +%Z
macOS installation log (Update, package, etc)grep “Install Succeeded” /var/log/install.log awk ‘{print $1, $2}’
Hardware informationsysctl -n hw.model
Process listps aux
System boot timesysctl kern.boottime

The results of these commands are then sent to the specified C2 server inside a POST request with the following User-Agent header: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0). This User-Agent is the same as the one used in the Swift implementation of the RustBucket variant.
ci[random ID][hostname][macOS version][timezone][install log][boot time][hw model][current time][process list]
After sending the system reconnaissance data to the C2 server, SysPhon waits for commands. It determines its next action by examining the first character of the response it receives. If the response begins with 0, SysPhon executes the binary payload; if it’s 1, the downloader exits.

AI-powered attack strategy


While the video feeds for fake calls were recorded via the fabricated Zoom phishing pages the actor created, the profile images of meeting participants appear to have been sourced from job platforms or social media platforms such as LinkedIn, Crunchbase, or X. Interestingly, some of these images were enhanced with GPT-4o. Since OpenAI implemented the C2PA standard specification metadata to identify the generated images as artificial, the images created via ChatGPT include metadata that indicates their synthetic origin, which is embedded in file formats such as PNGs.

EXIF metadata of images generated by GPT-4o
EXIF metadata of images generated by GPT-4o

Among these were images whose filenames were set to the target’s name. This indicates the actor likely used the target’s publicly available profile image to generate a suitable profile for use alongside the recorded video. Furthermore, the inclusion of Zoom’s legitimate favicon image leads us to assess with medium-high confidence that the actor is leveraging AI for image enhancement.

Victim's profile image enhanced using GPT-4o
Victim’s profile image enhanced using GPT-4o

In addition, the secrets stealer module of SilentSiphon, secrets.sh, includes several comment lines. One of them uses a checkmark emoticon to indicate archiving success, although the comment was related to the backup being completed. Since threat actors rarely use comments, especially emoticons, in malware intended for real attacks, we suggest that BlueNoroff uses generative AI to write malicious scripts similar to this module. We assume they likely requested a backup script rather than an exfiltration script.

Comments that appear to be AI-generated in the secrets stealer module
Comments that appear to be AI-generated in the secrets stealer module

The GhostHire campaign


The GhostHire campaign was less visible than GhostCall, but it also began as early as mid-2023, with its latest wave observed recently. It overlaps with the GhostCall campaign in terms of infrastructure and tools, but instead of using video calls, the threat actors pose as fake recruiters to target developers and engineers. The campaign is disguised as skill assessment to deliver malicious projects, exploiting Telegram bots and GitHub as delivery vehicles. Based on historical attack cases of this campaign, we assess with medium confidence that this attack flow involving Telegram and GitHub represents the latest phase, which started no later than April this year.

Initial access


The actor initiates communication with the target directly on Telegram. Victims receive a message with a job offer along with a link to a LinkedIn profile that impersonates a senior recruiter at a financial services company based in the United States.

Fake LinkedIn profile
Fake LinkedIn profile

We observed that the actor uses a Telegram Premium account to enhance their credibility by employing a custom emoji sticker featuring the company’s logo. They attempt to make the other party believe they are in contact with a legitimate representative.

Fake Telegram account
Fake Telegram account

During the investigation, we noticed suspicious changes made to the Telegram account, such as a shift from the earlier recruiter persona to impersonating individuals associated with a Web3 multi-gaming application. The actor even changed their Telegram handle to remove the previous connection.

The same Telegram account changed to impersonate a Web3 company founder
The same Telegram account changed to impersonate a Web3 company founder

During the early stages of our research and ongoing monitoring of publicly available malicious repositories, we observed a blog post published by a publicly cited target. In this post, the author shares their firsthand experience with a scam attempt involving the same malicious repositories we already identified. It provided us with valuable insight into how the group initiates contact with a target and progresses through a fake interview process.

Following up on initial communication, the actor adds the target to a user list for a Telegram bot, which displays the impersonated company’s logo and falsely claims to streamline technical assessments for candidates. The bot then sends the victim an archive file (ZIP) containing a coding assessment project, along with a strict deadline (often around 30 minutes) to pressure the target into quickly completing the task. This urgency increases the likelihood of the target executing the malicious content, leading to initial system compromise.

The project delivered through the ZIP file appears to be a legitimate DeFi-related project written in Go, aiming at routing cryptocurrency transactions across various protocols. The main project code relies on an external malicious dependency specified in the go.mod file, rather than embedding malicious code directly into the project’s own files. The external project is named uniroute. It was published in the official Go packages repository on April 9, 2025.

We had observed this same repository earlier in our investigation, prior to identifying the victim’s blog post, which later validated our findings. In addition to the Golang repository, we discovered a TypeScript-based repository uploaded to GitHub that has the same download function.

Uniroute malicious package is referenced via go.mod in the DeFi-related project
Uniroute malicious package is referenced via go.mod in the DeFi-related project

Upon execution of the project, the malicious package is imported, and the GetUniRoute() function is called during the initialization of the unirouter at the following path: contracts/UniswapUniversalRouter.go. This function call acts as the entry point for the malicious code.

Entry point of malicious function
Entry point of malicious function

The malicious package consists of several files:
uniroute
├── README.md
├── dar.go
├── go.mod
├── go.sum
├── lin.go
├── uniroute.go
└── win.go
The main malicious logic is implemented in the following files:

  1. uniroute.go: the main entry point
  2. win.go: Windows-specific malicious code
  3. lin.go: Linux-specific malicious code
  4. dar.go: macOS (Darwin)-specific malicious code

The main entry point of the package includes a basic base64-encoded blob that is decoded to a URL hosting the second-stage payload: hxxps://download.datatabletemplate[.]xyz/account/register/id=8118555902061899&secret=QwLoOZSDakFh.

Base64-encoded C2 URL in the malicious package
Base64-encoded C2 URL in the malicious package

When the User-Agent of the running platform is detected, the corresponding payload is retrieved and executed. The package utilizes Go build tags to execute different code depending on the operating system.

  • Windows (win.go). Downloads its payload to %TEMP%\init.ps1 and performs anti-antivirus checks by looking for the presence of the 360 Security process. If the 360 antivirus is not detected, the malware generates an additional VBScript wrapper at %TEMP%\init.vbs. The PowerShell script is then covertly executed with a bypassed execution policy, without displaying any windows to the user.
  • Linux (lin.go). Downloads its payload to /tmp/init and runs it as a bash script with nohup, ensuring the process continues running even after the parent process terminates.
  • macOS (dar.go). Similarly to Linux, downloads its payload to /tmp/init and uses osascript with nohup to execute it.

We used our open source package monitoring tool to discover that the actor had published several malicious Go packages with behavior similar to uniroute. These packages are imported into repositories and executed within a specific section of the code.

PackageVersionPublished dateRole
sorttemplatev1.1.1 ~ v1.1.5Jun 11, 2024 ~ Apr 17, 2025Malicious dependency
sortv1.1.2 ~ v1.1.7Nov 10, 2024 ~ Apr 17, 2025Refers to the malicious sorttemplate
sorttemplatev1.1.1Jan 10, 2025Malicious dependency
uniroutev1.1.1 ~ v2.1.5Apr 2, 2025 ~ Apr 9, 2025Malicious dependency
BaseRouterApr 5, 2025 ~ Apr 7, 2025Malicious dependency
Malicious TypeScript project


Not only did we observe attacks involving malicious Golang packages, but we also identified a malicious Next.js project written in TypeScript and uploaded to GitHub. This project includes TypeScript source code for an NFT-related frontend task. The project acts in a similar fashion to the Golang ones, except that there is no dependency. Instead, a malicious TypeScript file within the project downloads the second-stage payload from a hardcoded URL.

Malicious TypeScript-based project
Malicious TypeScript-based project

The malicious behavior is implemented in pages/api/hello.ts, and the hello API is fetched by NavBar.tsx with fetch('/api/hello').
wallet-portfolio
├── README.md
├── components
│ ├── navBar
│ │ ├── NavBar.tsx ##### caller
...
├── data
├── next.config.js
├── package-lock.json
├── package.json
├── pages
│ ├── 404.tsx
│ ├── _app.tsx
│ ├── _document.tsx
│ ├── api
│ │ ├── 404.ts
│ │ ├── app.ts
│ │ ├── hello.ts ##### malicious
...
│ ├── create-nft.tsx
│ ├── explore-nfts.tsx
...
We have to point out that this tactic isn’t unique to BlueNoroff. The Lazarus group was the first to adopt it, and the Contagious Interview campaign also uses it. However, the GhostHire campaign stands apart because it uses a completely different set of malware chains.

DownTroy: multi-platform downloader


Upon accessing the URL with the correct User-Agent, corresponding scripts are downloaded for each OS: PowerShell for Windows, bash script for Linux, and AppleScript for macOS, which all turned out to be the DownTroy malware. It is the same as the final payload in the DownTroy chains from the GhostCall campaign and has been expanded to include versions for both Windows and Linux. In the GhostHire campaign, this script serves as the initial downloader, fetching various malware chains from a file hosting server.

DownTroy delivery process
DownTroy delivery process

Over the course of tracking this campaign, we have observed multiple gradual updates to these DownTroy scripts. The final version shows that the PowerShell code is XOR-encrypted, and the AppleScript has strings split by individual characters. Additionally, all three DownTroy strains collect comprehensive system information including OS details, domain name, host name, username, proxy settings, and VM detection alongside process lists.

Full infection chain on Windows


In January 2025, we identified a victim who had executed a malicious TypeScript project located at <company name>-wallet-portfolio, which followed the recruiter persona from the financial company scenario described earlier. The subsequent execution of the malicious script created the files init.vbs and init.ps1 in the %temp% directory.

The DownTroy script (init.ps1) was running to download additional malware from an external server every 30 seconds. During the attack, two additional script files, chsplitobf.ps1 and sinst.bat, were downloaded and executed on the infected host. Though we weren’t able to obtain the files, based on our detection, we assess the PowerShell script harvests credentials stored in a browser, similar to SilentSiphon on macOS.

In addition, in the course of the attack, several other payloads written in Go and Rust rather than scripts, were retrieved from the file hosting server dataupload[.]store and executed.

Overall Windows infection chain
Overall Windows infection chain

New method for payload delivery


In contrast to GhostCall, DownTroy.Windows would retrieve a base64-encoded binary blob from the file hosting server and inject it into the cmd.exe process after decoding. This blob typically consists of metadata, a payload, and the loader code responsible for loading the payload. The first five bytes of the blob represent a CALL instruction that invokes the loader code, followed by 0x48 bytes of metadata. The loader, which is 0xD6B bytes in size, utilizes the metadata to load the payload into memory. The payload is written to newly allocated space, then relocated, and its import address table (IAT) is rebuilt from the same metadata. Finally, the payload is executed with the CreateThread function.

Binary blob structure
Binary blob structure

The metadata contains some of the fields from PE file format, such as an entry point of the payload, imagebase, number of sections, etc, needed to dynamically load the payload. The payload is invoked by the loader by referencing the metadata stored separately, so it has a corrupted COFF header when loaded. Generally, payloads in PE file format should have a legitimate header with the corresponding fields, but in this case, the top 0x188 bytes of the PE header of the payload are all filled with dummy values, making it difficult to analyze and detect.

UAC bypass


We observed that the first thing the actor deployed after DownTroy was installed was the User Account Control (UAC) bypass tool. The first binary blob fetched by DownTroy contained the payload bypassing UAC that used a technique disclosed in 2019 by the Google Project Zero team. This RPC-based UAC bypass leveraging the 201ef99a-7fa0-444c-9399-19ba84f12a1a interface was also observed in the KONNI malware execution chain in 2021. However, the process that obtains the privilege had been changed from Taskmgr.exe to Computerdefaults.exe.

The commands executed through this technique are shown below. In this case, this.exe is replaced by the legitimate explorer.exe due to parent PID spoofing.

In other words, the actor was able to run DownTroy with elevated privileges, which is the starting point for all further actions. It also executed init.vbs, the launcher that runs DownTroy, with elevated privileges.

RooTroy.Windows in Go


RooTroy.Windows is the first non-scripted malware installed on an infected host. It is a simple downloader written in Go, same to the malware used in the GhostCall campaign. Based on our analysis of RooTroy’s behavior and execution flow, it was loaded and executed by a Windows service named NetCheckSvc.

Although we did not obtain the command or installer used to register the NetCheckSvc service, we observed that the installer had been downloaded from dataupload[.]store via DownTroy and injected into the legitimate cmd.exe process with the parameter -m yuqqm2ced6zb9zfzvu3quxtrz885cdoh. The installer then probably created the file netchksvc.dll at C:\Windows\system32 and configured it to run as a service named NetCheckSvc. Once netchksvc.dll was executed, it loaded RooTroy into memory, which allowed it to operate in the memory of the legitimate svchost.exe process used to run services in Windows.

RooTroy.Windows initially retrieves configuration information from the file C:\Windows\system32\smss.dat. The contents of this file are decrypted using RC4 with a hardcoded key: B3CC15C1033DE79024F9CF3CD6A6A7A9B7E54A1A57D3156036F5C05F541694B7. This key is different from the one used in the macOS variant of this malware, but the same C2 URLs were used in the GhostCall campaign: readysafe[.]xyz and safefor[.]xyz.

Then RooTroy.Windows creates a string object {"rt": "5.0.0"}, which is intended to represent the malware’s version. This string is encrypted using RC4 with another hardcoded string, C4DB903322D17C8CBF1D1DB55124854C0B070D6ECE54162B6A4D06DF24C572DF. It is the same as the key used in RooTroy.macOS, and it is stored at C:\ProgramData\Google\Chrome\version.dat.

Next, the malware collects device information, including lists of current, new and terminated processes, OS information, boot time, and more, which are all structured in a JSON object. It then sends the collected data to the C2 server using the POST method with the Content-Type: application/json header.

The response is parsed into a JSON object to extract additional information required for executing the actual command. The commands are executed based on the value of the type field in the response, with each command processing its corresponding parameters in the required object.

Value of typeDescription
0Send current configuration to C2
1Update received configuration with the configuration file (smss.dat)
2Payload injection
3Self-update

If the received value of type is 2 or 3, the responses include a common source field within the parsed data, indicating where the additional payload originates. Depending on the value of source, the data field in the parsed data contains either the file path where the payload is stored on the disk, the C2 server address from which it should be downloaded, or the payload itself encoded in base64. Additionally, if the cipher field is set to true, the key field is used as the RC4 decryption key.

Value of sourceDescriptionValue of data
0Read payload from a specific fileFile path
1Fetch payload from another serverC2 address
2Delivered by the current JSON objectbase64-encoded payload

If the value of type is set to 2, the injection mode, referred to as peshooter in the code, is activated to execute an additional payload into memory. This mode checks whether the payload sourced from the data field is encrypted by examining the cipher value as a flag in the parsed data. If it is, the payload is decrypted with the RC4 algorithm. If no key is provided in the key value, a hardcoded string, A6C1A7CE43B029A1EF4AE69B26F745440ECCE8368C89F11AC999D4ED04A31572, is used as the default key.

If the pid value is not specified (e.g., set to -1), the process with the name provided in the process field is executed in suspended mode, with the optional argument value as its input. Additionally, if a sid value is provided at runtime, a process with the corresponding session ID is created. If a pid value is explicitly given, the injection is performed into that specific process.

Before performing the injection, the malware enables the SeDebugPrivilege privilege for process injection and unhooks the loaded ntdll.dll for the purpose of bypassing detection. This is a DLL unhooking technique that dynamically loads and patches the .text section of ntdll.dll to bypass the hooking of key functions by security software to detect malicious behavior.

Once all the above preparations are completed, the malware finally injects the payload into the targeted process.

If the value of type is set to 3, self-update mode is activated. Similar to injection mode, it first checks whether the payload sourced from the data is encrypted and, if so, decrypts it using RC4 with a hardcoded key: B494A0AE421AFE170F6CB9DE2C1193A78FBE16F627F85139676AFC5D9BFE93A2. A random 32-byte string is then generated, and the payload is encrypted using RC4 with this string as the key. The encrypted payload is stored in the file located at C:\Windows\system32\boot.sdl, while the generated random key is saved unencrypted in C:\Windows\system32\wizard.sep. This means the loader will read the wizard.sep file to retrieve the RC4 key, use it to decrypt the payload from boot.sdl, and then load it.

After successfully completing the update operation, the following commands are created under the filename update-[random].bat in the %temp% directory:
@echo off
set SERVICE_NAME=NetCheckSvc
sc stop %SERVICE_NAME% >nul 2>&1
sc start %SERVICE_NAME% >nul 2>&1
start "" cmd /c del "%~f0" >nul 2>&1
This batch script restarts a service called NetCheckSvc and self-deletes, which causes the loader netchksvc.dll to be reloaded. In other words, the self-update mode updates RooTroy itself by modifying two files mentioned above.

According to our telemetry, we observed that the payload called RealTimeTroy was fetched by RooTroy and injected into cmd.exe process with the injected wss://signsafe[.]xyz/update parameter.

RealTimeTroy in Go


The backdoor requires at least two arguments: a simple string and a C2 server address. Before connecting to the given C2 server, the first argument is encrypted using the RC4 algorithm with the key 9939065709AD8489E589D52003D707CBD33AC81DC78BC742AA6E3E811BA344C and then base64 encoded. In the observed instance, this encoded value is passed to the “p” (payload) field in the request packet.

The entire request packet is additionally encrypted using RC4 algorithm with the key 4451EE8BC53EA7C148D8348BC7B82ACA9977BDD31C0156DFE25C4A879A1D2190. RealTimeTroy then sends this encrypted message to the C2 server to continue communication and receive commands from the C2.

Then the malware receives a response from the C2. The value of “e” (event) within the response should be 5, and the value of “p” is decoded using base64 and then decrypted using RC4 with the key 71B743C529F0B27735F7774A0903CB908EDC93423B60FE9BE49A3729982D0E8D, which is deserialized in JSON. The command is extracted from the “c” (command) field in the JSON object, and the malware performs specific actions according to the command.

CommandDescriptionParameter from C2
1Get list of subfilesDirectory path
2Wipe fileFile path
3Read fileFile path
4Read directoryDirectory path
5Get directory informationDirectory path
6Get process information
7Terminate processProcess ID
8Execute commandCommand line
10Write fileFile path, content
11Change work directoryDirectory path
12Get device information
13Get local drives
14Delete fileFile path
15Cancel command
16File downloadData for file download
19Process injectionData for process injection

Upon receiving the file download command (16), the d (data) field in the response contains a JSON object. If the u (url) field is initialized, a connection is established to the specified URL using the m (method) and h (headers) fields provided in the same JSON object. If the connection returns a 200 status code (success), the response body is written to the file path indicated by the r (rpath) value in the response.

While the u value is not initialized, the malware writes the value of the b (buffer) field from the response to the path provided through the r field. It continues writing b until the e (eof) flag is set and then sends the xxHash of the total downloaded contents to the C2 server. This allows for the downloading of the larger file contents from the C2 server.

When receiving the process injection command (19), the d in the response includes another JSON object. If the l (local) flag within this object is set to true, a t (total) amount of data is read from b starting at the f (from) position specified in the object. The xxHash value of b is then validated to ensure it matches the provided h (hash) value. If the l flag is false, b is instead read from the file path specified as fp (file path). The payload is then injected into cmd.exe with the same method as the peshooter used in RooTroy.

The result is then serialized and secured with a combination of RC4 encryption and base64 encoding before being sent to the C2 server. The key used for encryption, 71B743C529F0B27735F7774A0903CB908EDC93423B60FE9BE49A3729982D0E8D, is the same key used to decrypt the response object.

CosmicDoor.Windows written in Go


CosmicDoor.Windows is the Windows version of CosmicDoor written in Go and has the same features as macOS versions. The C2 server address wss://second.systemupdate[.]cloud/client is hardcoded in the malware. It processes a total of seven commands, passed from the C2.

CommandDescriptionParameter from C2
234Get device information
333No operationUnknown
44Update configurationInterval time, UID, C2 server address
78Get current work directory
1Get interval time
12Execute commands OR code injectionCommand line
34Set current work directoryDirectory path

The command 234 is for collecting device information such as user name, computer name, OS, architecture, Windows version, and boot time.

The command 12 serves two primary functions. The first is to execute a command line passed as a parameter using cmd.exe /c, while the second is to perform code injection. This injection capability is nearly identical to the peshooter functionality found in RooTroy, but it is considered an enhanced version.

Within CosmicDoor, the peshooter feature can accept up to six parameters using the shoot or shoote command to configure code injection options. If a file path is provided in the PATH parameter, the next payload is read from that file on the system. Conversely, if a string beginning with http is specified, the next payload is retrieved through HTTP communication instead.

NumParameterDescription
1shoot or shooteThe next payload is either plain or base64-encoded
2SIDSession ID to be used when executing notepad.exe
3PIDProcess ID of the targeted process to be injected
4REASONIf set to -1, ARGS is passed to the injected payload
5PATHRead payload from local file or fetch it from external server
6ARGSParameters to be passed
7FUNCExport function name to execute

Then it checks the SID, PID, and REASON parameters. If PID is not passed, CosmicDoor defaults to creating notepad.exe in suspended mode and assigns it a target for injection, and the SID determines the session ID that runs notepad.exe. If no SID is passed, it defaults to the token of the current process. REASON means to pass ARGS to the payload by default if no value greater than 0 is passed.

Finally, CosmicDoor allocates space inside of the targeted process’s memory space for the payload, the hardcoded shellcode for the loader, and ARGS to write the data, and then invokes the loader code to execute the final payload from memory. If FUNC is set at this point, it calls the corresponding export function of the loaded payload. This usage is also well displayed inside CosmicDoor.
"ERROR: Invalid syntax.\n"
"Examples:\n"
"\tshoot [SID] [PID] [REASON] [PATH] [ARGS] [FUNC]\n"
"Parameter List:\n"
"\t[SID] Session ID.\n"
"\t[PID] Process ID.\n"
"\t[REASON] reason.\n"
"\t[PATH] the path of PE file.\n"
"\t[ARGS] the arguments of PE file.\n"
"\t[FUNC] Export function of PE file.\n";

Bof loader written in Rust


Bof loader is assumed to be one of the payloads downloaded from dataupload[.]store by DownTroy. It is a loader protected by Themida and written in Rust. The malware was created with the name nlsport.dll, and unlike other malware, it is registered with security support providers and loaded with SYSTEM privileges by the LSASS process at Windows boot time. In this instance, the malicious behavior is implemented in the SpLsaModeInitialize export function inside the DLL file and it contains the string that indicates its work path C:\Users\Molly.

The loader employs the NTDLL unhooking technique, a method also used by other malware families. After unhooking, the loader reads two files. The first one contains an RC4 key, while the second holds a payload encrypted with that key.

  • RC4 key: C:\Windows\system32\wand.bin
  • Encrypted payload: C:\Windows\system32\front.sdl.

The loader then decrypts the payload, allocates memory in the current process, and executes the decrypted shellcode via the NtCreateThreadEx function. This is very similar to the injection feature implemented within RooTroy, written in Golang.

During our focused monitoring of the threat actor’s infrastructure, we discovered that one of the instances was signed with a valid certificate from a legitimate Indian company.

Victims


Our telemetry detected infection events from various countries affected by both campaigns. We have observed several infected macOS hosts located in Japan, Italy, France, Singapore, Turkey, Spain, Sweden, India and Hong Kong infected by the GhostCall campaign since 2023. The victims of the GhostHire campaign, which resumed its activities starting this year, have been identified as individuals in Japan and Australia.

We observed that many stolen videos and profile images have been uploaded to the actor’s public storage server. These were utilized to convince victims in the course of the GhostCall campaign. We closely examined the uploaded data and found that most victims were executives at tech companies and venture capital funds in the Web3/blockchain industry located in the APAC region, particularly in Singapore and Hong Kong.

Attribution


In 2022, we already uncovered the PowerShell script that BlueNoroff heavily relied on to collect base system information and execute commands from its C2 server. This script is considered to be an earlier version of DownTroy. Moreover, leveraging trusted resources attributed to venture capital funds to attack the cryptocurrency-related industry was a primary attack method of the SnatchCrypto campaign. Additionally, the tendency to create phishing domains using the names of venture capital firms and the use of Hostwinds hosting to build these phishing sites also overlaps with past cases of BlueNoroff observed in our previous research.

In late-2023, we provided an insight into the early stage of the BlueNoroff’s GhostCall campaign to our customers. The actor utilized JavaScript and AppleScript to raise an issue regarding IP access control on Windows and macOS respectively. In this instance, the JavaScript ultimately downloaded a VBScript file, which has been identified as a VBScript version of DownTroy. This version shares a C2 server with CosmicDoor.Windows. The AppleScript was used against a victim in August 2023, and fetched from a fake domain support.video-meeting[.]online, which shared its resolved IP address (104.168.214[.]151) with the ObjCShellZ malware’s C2 server swissborg[.]blog.

We assess with medium-high confidence that BlueNoroff is behind both campaigns when comprehensively considering the infrastructure, malware, attack methods, final targets, and motives behind the attacks used in both campaigns.

Conclusion


Our research indicates a sustained effort by the actor to develop malware targeting both Windows and macOS systems, orchestrated through a unified command-and-control infrastructure. The use of generative AI has significantly accelerated this process, enabling more efficient malware development with reduced operational overhead. Notably, AI will make it easier to introduce new programming languages and add new features, thereby complicating detection and analysis tasks. Furthermore, AI supports the actor’s ability to maintain and expand their infrastructure, enhancing their overall productivity.

Beyond technical capabilities, the actor leverages AI to refine sophisticated social engineering tactics. The AI-powered, tailored approach enables the attackers to convincingly disguise themselves, operating with detailed information, allowing for more meticulous targeted attacks. By combining compromised data with AI’s analytical and productive capabilities, the actor’s attack success rate has demonstrably increased.

The actor’s targeting strategy has evolved beyond simple cryptocurrency and browser credential theft. Upon gaining access, they conduct comprehensive data acquisition across a range of assets, including infrastructure, collaboration tools, note-taking applications, development environments, and communication platforms (messengers). This harvested data is exploited not only against the initial target but also to facilitate subsequent attacks, enabling the actor to execute supply chain attacks and leverage established trust relationships to impact a broader range of users.

Kaspersky products detect the exploits and malware used in this attack with the following verdicts:

HEUR:Trojan.VBS.Agent.genUDS:Trojan.PowerShell.SBadur.genHEUR:Trojan.VBS.Cobalt.gen
Trojan.VBS.RunnerTrojan-Downloader.PowerShell.PowedonTrojan.Win64.Kryptik
Backdoor.PowerShell.AgentHEUR:Backdoor.OSX.OSAHEUR:Backdoor.OSX.Agent
Backdor.Shell.AgentTrojan.Win32.BlueNoroff.lHEUR:Trojan-Spy.OSX.ZoomClutch.a
HEUR:Trojan.OSX.Nimcore.aHEUR:Backdoor.OSX.RooTroy.aHEUR:Trojan-Downloader.OSX.Bluenoroff.a
HEUR:Backdoor.OSX.CosmicDoor.aHEUR:Trojan-Dropper.OSX.GillyInjector.aHEUR:Trojan.OSX.Nukesped.*
HEUR:Trojan-Downloader.OSX.Bluenoroff.bHEUR:Backdoor.Python.Agent.brHEUR:Trojan.HTML.Bluenoroff.a
HEUR:Trojan.OSX.BlueNoroff.genTrojan.Python.BlueNoroff.aTrojan.Shell.Agent.gn

Indicators of compromise


More IoCs are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

AppleScript
e33f942cf1479ca8530a916868bad954 zoom_sdk_support.scpt
963f473f1734d8b3fbb8c9a227c06d07 test1
60bfe4f378e9f5a84183ac505a032228 MSTeamsUpdate.scpt

ZoomClutch
7f94ed2d5f566c12de5ebe4b5e3d8aa3 zoom

TeamsClutch
389447013870120775556bb4519dba97 Microsoft Teams

DownTroy v1 chain
50f341b24cb75f37d042d1e5f9e3e5aa trustd
a26f2b97ca4e2b4b5d58933900f02131 watchdog, SafariUpdate
6422795a6df10c45c1006f92d686ee7e 633835385.txt

CosmicDoor in Rust
931cec3c80c78d233e3602a042a2e71b dnschk
c42c7a2ea1c2f00dddb0cc4c8bfb5bcf dnschk

CosmicDoor in Python
9551b4af789b2db563f9452eaf46b6aa netchk

CosmicDoor chain
76ace3a6892c25512b17ed42ac2ebd05 a
19a7e16332a6860b65e6944f1f3c5001 a

SilentSiphon
c446682f33641cff21083ac2ce477dbe upl
e8680d17fba6425e4a9bb552fb8db2b1 upl.sh
10cd1ef394bc2a2d8d8f2558b73ac7b8 upl.sh
a070b77c5028d7a5d2895f1c9d35016f cpl.sh
38c8d80dd32d00e9c9440a498f7dd739 secrets.sh
7168ce5c6e5545a5b389db09c90038da uad.sh
261a409946b6b4d9ce706242a76134e3 ubd.sh
31b88dd319af8e4b8a96fc9732ebc708 utd.sh

RooTroy chain
1ee10fa01587cec51f455ceec779a160 rtv4inst
3bbe4dfe3134c8a7928d10c948e20bee st, Update Check
7581854ff6c890684823f3aed03c210f wt
01d3ed1c228f09d8e56bfbc5f5622a6c remoted

RealTimeTroy chain
5cb4f0084f3c25e640952753ed5b25d0 Chrome Update

SneakMain in Rust
1243968876262c3ad4250e1371447b23 helper, wt
5ad40a5fd18a1b57b69c44bc2963dc6b 633835387.txt
6348b49f3499d760797247b94385fda3 ChromeUpdate

SneakMain chain
17baae144d383e4dc32f1bf69700e587 mdworker
8f8942cd14f646f59729f83cbd4c357b com.password.startup
0af11f610da1f691e43173d44643283f CloudSigner, Microsoft Excel, Hancom Office HWP, zoom.us, com.onedrive.updater
7e50c3f301dd045eb189ba1644ded155 mig

TripleWatch stealer
0ca37675d75af0e7def0025cd564d6c5 keyboardd

DownTroy v2 chain
d63805e89053716b6ab93ce6decf8450 CoreKitAgent
e9fdd703e60b31eb803b1b59985cabec GoogIe LLC
f1d2af27b13cd3424556b18dfd3cf83f installer
b567bfdaac131a2d8a23ad8fd450a31d CoreKitAgent
00dd47af3db45548d2722fe8a4489508 GoogIe LLC
6aa93664b4852cb5bad84ba1a187f645 installer
d8529855fab4b4aa6c2b34449cb3b9fb CoreKitAgent
eda0525c078f5a216a977bc64e86160a GoogIe LLC
ab1e8693931f8c694247d96cf5a85197 installer

SysPhon chain
1653d75d579872fadec1f22cf7fee3c0 com.apple.sysd
529fe6eff1cf452680976087e2250c02 growth
a0eb7e480752d494709c63aa35ccf36c com.apple.secd
73d26eb56e5a3426884733c104c3f625 Wi-Fi Updater

VBScript
358c2969041c8be74ce478edb2ffcd19 init.vbs
2c42253ebf9a743814b9b16a89522bef init.vbs

DownTroy.Windows
f1bad0efbd3bd5a4202fe740756f977a init.ps1
a6ce961f487b4cbdfe68d0a249647c48 init.ps1
8006efb8dd703073197e5a27682b35bf init.ps1
c6f0c8d41b9ad4f079161548d2435d80 init.ps1
f8bb2528bf35f8c11fbc4369e68c4038 init.ps1

Bof loader
b2e9a6412fd7c068a5d7c38d0afd946f nlsport.dll
de93e85199240de761a8ba0a56f0088d

File hosting server
system.updatecheck[.]store
dataupload[.]store
safeupload[.]online
filedrive[.]online

AppleScript C2
hxxp://web071zoom[.]us/fix/audio/4542828056
hxxp://web071zoom[.]us/fix/audio-fv/7217417464
hxxp://web071zoom[.]us/fix/audio-tr/7217417464
hxxps://support.ms-live[.]us/301631/check
hxxps://support.ms-live[.]us/register/22989524464UcX2b5w52
hxxps://support.ms-live[.]us/update/02583235891M49FYUN57

ZoomClutch/TeamsClutch C2
hxxps://safeupload[.]online/uploadfiles
hxxps://api.clearit[.]sbs/uploadfiles
hxxps://api.flashstore[.]sbs/uploadfiles
hxxps://filedrive[.]online/uploadfiles

DownTroy C2
hxxps://bots.autoupdate[.]online:8080/test
hxxps://writeup[.]live/test
hxxps://safeup[.]store/test
hxxps://api[.]clearit[.]sbs/test
hxxps://api[.]flashstore[.]sbs/test

CosmicDoor C2
ws://web.commoncome[.]online:8080/client
ws://first.longlastfor[.]online:8080/client
wss://firstfromsep[.]online/client
second.systemupdate[.]cloud
second.awaitingfor[.]online

RooTroy C2
safefor[.]xyz
readysafe[.]xyz

RealTimeTroy C2
instant-update[.]online
signsafe[.]xyz

TripleWatch stealer C2
hxxps://metamask.awaitingfor[.]site/update

SilentSiphon C2
hxxps://urgent-update[.]cloud/uploadfiles
hxxps://dataupload[.]store/uploadfiles
hxxps://filedrive[.]online/uploadfiles

SneakMain.macOS C2
hxxps://chkactive[.]online/update
hxxps://file-server[.]store/update
hxxps://cloud-server[.]store/update
hxxps://flashserve[.]store/update

Additional C2 servers
download.datatabletemplate[.]xyz
check.datatabletemplate[.]shop
download.face-online[.]world
root.security-update[.]xyz
real-update[.]xyz
root.chkstate[.]online
secondshop[.]online
signsafe[.]site
secondshop[.]store
botsc.autoupdate[.]xyz
first.system-update[.]xyz
image-support[.]xyz
pre.alwayswait[.]site


securelist.com/bluenoroff-apt-…


Making a Virtual Machine Look like Real Hardware to Malware


Running suspicious software in a virtual machine seems like a basic precaution to figure out whether said software contains naughty code. Unfortunately it’s generally rather easy to detect whether or not one’s software runs inside a VM, with [bRootForce] going through a list of ways that a VirtualBox VM can be detected from inside the guest OS. While there are a range of obvious naming issues, such as the occurrence of the word ‘VirtualBox’ everywhere, there many more subtle ways too.

Demonstrated is the PoC ‘malware’ application called Al-Khaser, which can be used to verify one’s anti-malware systems, such as when trying to unleash a debugger on a piece of malware, run it inside a VM, along with many more uses. Among its anti-virtualization features are specific registry key names and values, file system artefacts, directory names, MAC addresses, virtual devices, etc.

In order to squeeze by those checks, [bRootForce] created the vbox_stealth shell script for Bash-blessed systems in order to use the VirtualBox Manager for the renaming of hardware identifier, along with the VBoxCloak project’s PowerShell script that’s used inside a Windows VirtualBox guest instance to rename registry keys, kill VirtualBox-specific processes, and delete VirtualBox-specific files.

Theoretically this should make it much harder for any malware to detect that it’s not running inside Windows on real hardware, but as always there are more subtle ways that are even harder to disguise.

youtube.com/embed/-On6bWFXuM8?…


hackaday.com/2025/10/27/making…


Building a Hydraulic Gear Pump Isn’t So Easy



The gear pump prototype in action. (Credit: Artisan Makes, YouTube)The gear pump prototype in action. (Credit: Artisan Makes, YouTube)
Hydraulic gear pumps are deceptively simple: just two gears rotating together, forcing the hydraulic oil from one side to the other where the teeth don’t meet, and thus providing the ability to pressurize said oil to make hydraulic cylinders, final drives, etc. do their thing. As with most machining projects like this, the devil is absolutely in the details, particularly in the tolerances. This is the crash course that the [Artisan Makes] channel on YouTube is currently going through.

In this part one of a series on a DIY gear pump, scrap aluminium is used for the housing, along with 1045 medium carbon steel for the gears and W1A high carbon steel for bearings and other wear surfaces. Since at least one of the gears needs to be driven, a lip seal rated for 10 bar is used to provide a path for the shaft. As noted in the video, this is supposed to be a learning experience, ergo it’s a simplified design that merely targets being functional as a gear pump.

With the basic design figured out, the parts were created on the lathe and mill, followed by assembly. Most of the controversy is about the tolerances within the housing, as any leakage will reduce the efficiency. This means the spacing between the gears and housing, space between the gears and bearings, as well as that provided by the gasket that seals the housing base and top. This is where the comment section somewhat explodes with criticism and advice.

As can be seen in the demonstration with a better gasket, there is absolutely flow when driven at 1200 RPM, but also clearly severe leakage as evidenced by said flow not moving quite as fast as it should. We’re looking forward to the next part, in which addressing these tolerances is tackled, with hopefully a much more performant gear pump resulting.

youtube.com/embed/SIeOhI7Qng8?…


hackaday.com/2025/10/27/buildi…


The Supercon 2025 Badge is Built to be Customized


For anyone who’s joined us for previous years, you’ll know that badge hacking and modification are core to the Hackaday Supercon experience. While you’re of course free to leave the badge completely stock, we encourage attendees to tear it apart, learn how it works, and (hopefully) rebuild it into something unique. There are even prizes for the best hacks.

As such, every decision about the badge’s hardware and software is made with hackability in mind. It’s why we always try to add an expansion port to the badge and, in recent years, have leaned into MicroPython to make it easier for attendees to modify the code.

But one thing that’s been largely missing in previous badges is aesthetic customization. Sure, you could strip out the firmware and write something entirely new, or hang some oddball peripheral off the side of the thing, but ultimately it still looked like the badge we gave you at the door. That’s because, at the end of the day, the badges are just PCBs. Short of designing your own enclosure (which has certainly been done), every badge looks the same. That is, until now.

This year’s badge is unique among Supercon badges because it isn’t just a PCB. It’s actually a stack-up of two PCBs! That might not sound like much of a distinction, but in this case, the front board has no electrical function — its only purpose is to hold the keyboard membrane against the dome switches on the rear PCB. The only reason we made it out of a PCB in the first place is that it was convenient and cheap at the scale we needed. But if those weren’t concerns, it could just as easily have been 3D-printed or cut out with a laser or a CNC router.

While the necessities of running two hacker cons on opposite sides of the planet within a couple of months of each other meant we needed to think at scale, attendees are free to do whatever they want between now and when they get their badges on Friday. Want to carve a front panel out of aluminum on your CNC? Awesome. Perhaps laser-cut some thin plywood and give it a nice stain for that old-school look? We love it. Want to see what that fancy multi-material 3D printer you’ve got is capable of? So do we.
Hailing frequencies open, Captain.

Some Assembly Required


Want to make the 2025 Hackaday Supercon badge your own? Just head over to the “hardware/mechanicals_and_models” directory in the badge’s GitHub repository and you’ll find STEP, DXF, and SVG versions of the front panel. We’re eager to see some wild and wonderful front panels, but there are a few things to keep in mind:

  • Spacing between the rear and front boards should be approximately 2 mm.
  • The area around the keyboard should be roughly PCB thickness (~1.7 mm) for optimal typing.
  • You’ll need to provide hardware (M3 nuts/bolts work well) to attach the front panel to the badge.

If you’ve got other questions or need some assistance, leave a comment below or check in on the #badge-hacking channel in the Hackaday Discord server. See you at Supercon!


hackaday.com/2025/10/27/the-su…


A 3D Printed 16mm Movie Camera


The basic principles of a motion picture film camera should be well understood by most readers — after all, it’s been well over a hundred years since the Lumière brothers wowed 19th century Paris with their first films. But making one yourself is another matter entirely, as they are surprisingly complex and high-precision devices. This hasn’t stopped [Henry Kidman] from giving it a go though, and what makes his camera more remarkable is that it’s 3D printed.

The problem facing a 16mm movie camera designer lies in precisely advancing the film by one frame at the correct rate while filming, something done in the past with a small metal claw that grabs each successive sprocket. His design eschews that for a sprocket driven by a stepper motor from an Arduino. His rotary shutter is driven by another stepper motor, and he has the basis of a good camera.

The tests show promise, but he encounters a stability problem, because as it turns out, it’s difficult to print a 16mm sprocket in plastic without it warping. He solves this by aligning frames in post-processing. After fixing a range of small problems though, he has a camera that delivers a very good picture quality, and that makes us envious.

Sadly, those of us who ply our film-hacking craft in 8mm don’t have the luxury of enough space for a sprocket to replace the claw.

youtube.com/embed/ZAtYJYfV2nA?…


hackaday.com/2025/10/27/a-3d-p…


Exploding The Mystical Craftsman Myth


As a Hackaday writer, I see a lot of web pages, social media posts, videos, and other tips as part of my feed. The best ones I try to bring you here, assuming of course that one of my ever-vigilant colleagues hasn’t beaten me to it. Along the way I see the tropes of changing content creator fashion; those ridiculous pea-sized hand held microphones, or how all of a sudden everything has to be found in the woods. Some of them make me laugh, but there’s one I see a lot which has made me increasingly annoyed over the years. I’m talking of course about the craftsman myth.

No. The Last True Nuts And Bolts Are Not Being Made In Japan


If you don’t recognise the craftsman myth immediately, I’m sure you’ll be familiar with it even if you don’t realise it yet. It goes something like this: somewhere in Japan (or somewhere else perceived as old-timey in online audience terms like Appalachia, but it’s usually Japan), there’s a bloke in a tin shed who makes nuts and bolts.

But he’s not just any bloke in a tin shed who makes nuts and bolts, he’s a special master craftsman who makes nuts and bolts like no other. He’s about 120 years old and the last of a long line of nut and bolt makers entrusted with the secrets of nut and bolt making, father to son, since the 8th century. His tools are also mystical, passed down through the generations since they were forged by other mystical craftsmen centuries ago, and his forge is like no other, its hand-cranked bellows bring to life a fire using only the finest cedar driftwood charcoal. The charcoal is also made by a 120 year old master charcoal maker Japanese bloke whose line stretches back to the n’th century, yadda yadda. And when Takahashi-san finally shuffles off this mortal coil, that’s it for nuts and bolts, because the other nuts and bolts simply can’t compare to these special ones.
An Indian craftsman hand-shaping a cricket bat.Something that’s genuinely in decline where this is being written, this craftsman is making a cricket bat in India. Amit.kapil, CC BY-SA 4.0.
Purple prose aside, this type of media annoys me, because while Takahashi-san and his brother craftsmen in Appalachia and anywhere else in the world possess amazing skills and should without question be celebrated, the videos are not about that. Instead they’re using them as a cipher for pushing the line that The World Ain’t What It Used To Be, and along the way they spread the myth that either there are no blokes in tin sheds left wherever you live, or if there are, their skills are of no significance. Perhaps the saddest part of the whole thing is that there are truly disappearing crafts which should be highlighted, but they probably don’t generate half the YouTube clicks so we don’t see much of them.

Celebrate your Local Craftsmen


My dad was a craftsman in a tin shed, just like the ones in the videos but in central southern England. Partly as a result of this I have known and dealt with a lot of blokes in tin sheds throughout my lifetime, and I am certain I would feel right at home standing in that Japanese one.

Part of coming to terms with the disturbed legacy of my own dysfunctional family has come in evaluating what from them I recognise as part of me and what I don’t, and it’s in my dad’s workshop that I realise what made me. Like all of us, he instinctively made things, usually with great success but let’s face it, like all of us too, sometimes where just buying the damn thing would have made more sense. He had truly elite skills in his craft that I will never equal, just as in my line I have mastered construction techniques which weren’t even conceived when he took his apprenticeship.

But here’s the point, my dad was not unique, and all the other blokes in tin sheds were not necessarily the same age as he was. Indeed one of the loose community of blacksmiths around where I grew up was someone who was in another year at the same school as me when I was a teenager. Even the crafts weren’t all of the mystical tools variety, I am immediately thinking of the tin shed full of CNC machine tools, or the bloke running an injection moulding operation. Believe me, both of those last two are invaluable craftsmen to know when you need their services, but they don’t fit the myth, do they? They’re not exotic.

So by all means watch those YouTube videos showing faraway folks in tin sheds and their craft, you’ll see some amazing work. But please don’t buy the mystique, or the premise that they automatically represent a disappearing world. Your part of the world will have blokes in tin sheds doing things just as impressive and useful, whether they be hand-forging steel on the anvil or working it using cutting-edge technology, and we should be seeking them out rather than lamenting a probably made-up tale from the other side of the world.

Early 20th century Japanese craftsman: Elstner Hilton, CC BY 2.0 .


hackaday.com/2025/10/27/explod…


Connector-Free Zone: PCB Edge as USB-C Interfaces


PCB Edge USB-C

Sometimes when you’re making a PCB that you plan on programming over USB, but you only plan on plugging in a couple of times, it would be nice to make that connection without another BOM item. Over on GitHub [AnasMalas] has released a PCB edge USB-C connection symbol/footprint to do just that!

This isn’t the first PCB edge USB-C connector we’ve seen, but this one has some nice features. It’s available in both KiCad and EasyEDA formats, allowing you to easily add it into your preferred ECAD software. As well as supporting multiple software packages, there are two versions included: a 10-pin and 14-pin version. The 10-pin version has, on each side, 2 USB voltage pins, 2 ground pins, and a CC1 or CC2 pin on its respective side; this version is ideal if you’re looking to just supply power via the connector. The 14-pin version has all the pins of the 10-pin version with the addition of four data-positive and data-negative pins needed to relay information to the board, ideal if you’re planning on programming a microcontroller with this connection.

One important note is that, while most PCBs default to 1.6 mm thickness, if you use this connector you’ll need to drop that down to ~0.8 mm to properly interface with a common USB cable. [AnasMalas] also suggests using ENIG board finish to preserve the connectors on your USB cable.

For such a small and common connector, USB-C holds a ton of potential. Be sure to check out our series all about USB-C for more details.

Thanks to [Ben] for the tip.


hackaday.com/2025/10/27/connec…


The Channel Crossing Bridge That Never Was



Full marks for clarity of message. Credit: Euro Route materials
When the Channel Tunnel opened in 1994, the undersea rail link saw Britain grew closer to the European mainland than ever before. However, had things gone a little differently, history might have taken a very different turn. Among the competing proposals for a fixed Channel crossing was a massive bridge. It was a scheme so audacious that fate would never allow it to come to fruition.

Forget the double handling involved in putting cars on trains and doing everything by rail. Instead, the aptly-named Euro Route proposed that motorists simply drive across the Channel, perhaps stopping for duty-free shopping in the middle of the sea along the way.

Long-Held Dreams


The concept of a permanent tunnel or transit link between Britain and France dates back a long way. The earliest recorded example is from 1802, when French engineer Albert Mathieu-Favier proposed a tunnel design for horse-drawn stagecoaches to travel between the Isles and the mainland. Ultimately, though, the feasibility of engineering such a project was beyond the limits of the time. The idea would never quite go away, though, with the British and French governments eventually coming to explore it in earnest starting in the late 1950s. The Channel Tunnel Study Group was established as an Anglo-French task force to explore the possibilities of building a crossing between the two nations. This led to an early effort to construct a cross-Channel tunnel beginning in 1973, only for the project to be scrapped two years later by British Prime Minister Harold Wilson on the basis of cost and the strains of the worldwide oil crisis.
The split bridge-tunnel-bridge concept was chosen due to concerns around comfort and air quality in a full-length Channel-crossing tunnel. Credit: Euro Route materials
It would be over a decade before the concept returned to the fore. The French and British governments reconvened in 1984 to establish baseline parameters for the project, before opening up the project to proposals in 1985. That process saw the Channel Tunnel Group win the day with a plan for a 51.5-kilometer dual-track rail-only tunnel, with trains carrying passengers and hauling cars between the two countries. The Treaty of Canterbury was signed in 1986, and construction began soon after, eventually leading to the infrastructure that exists today.
The tall cable-stayed bridges would avoid any issues with sea traffic passing through the area. Credit: Euro Route materials
The Channel Tunnel might have been the winning project, but it wasn’t the only proposal on the table. The Euro Route project was an altogether bolder scheme. Their plan called for a three-stage crossing combining both road and rail. Cars would travel via a spectacular road link featuring bridges springing from each coast, leading into an immersed tunnel running through the deepest section of the Channel. Meanwhile, there would also be a twin-track rail tunnel not dissimilar from the Channel Tunnel itself.

The Euro Route project was marketed based on its key offering—users would be able to drive all the way with a minimum of fuss. “From your home you will drive straight to France,” read the marketing materials. There would be no fussy loading and unloading of automobiles on to train cars. Meanwhile, those that wished to travel by rail could equally do so via the separate rail tunnel, with freight trains using the passage as well.

The project would not be cheap. Estimates were that it would cost some £6 billion to build (1985 prices). At the time, this figure came in at two to three times what the Channel Tunnel proposal was expected to cost—no surprise given it also involved an entire road crossing in addition to a rail tunnel. However, the project was backed by a consortium of heavyweight British institutions—including British Steel, Barclays Bank, and GEC—which had together secured over seven billion pounds in funding for the project. The intention was that it would be paid for in time by charging tolls to access the crossing.

The road crossing was designed for drama and practicality in equal measure. Motorists would leave the M20 near Dover, before passing through toll booths to pay for the journey. From there, they would make their way onto a bridge standing some fifty meters above the waves. This cable-stayed bridge would stretch for 8.5 km to an artificial island, where the motorway would spiral down beneath sea level to the undersea tunnel below. This tunnel consisted of a 21 km immersed tube tunnel carrying parallel dual carriageways safely beneath the shipping lanes, emerging at a second artificial island before another bridge carried traffic the final 7.5 km to France. A third artificial island would also sit in between the other two, serving as a ventilation shaft for the road tunnel and acting as a marker to enforce lane discipline for shipping in the Channel.
Euro Route’s prime point of difference was that it avoided the tedious loading and unloading of vehicles on to train cars versus the eventual Channel Tunnel concept that was chosen. Credit: Euro Route materials
All in all, traveling the Euro Route was expected to take just 30 minutes over the road. Customs formalities were to be “speeded up by computer” to ease the journey, pushing the total time to approximately 45 minutes. This was to be a key advantage over concepts like the all-rail Channel Tunnel. “NOTE: A shuttle service would require additional time for waiting, and loading and unloading; Euro Route does not,” noted the marketing materials. . Those behind the EuroRoute believed people wanted to drive across the Channel themselves, rather than sitting in their cars on a train for a longer period of time.

The combined bridge-tunnel-bridge concept was, at first blush, more complicated than simply building a single long road tunnel from coast to coast. However, such a tunnel would have likely measured well over 30 km in length. This was considered somewhat undesirable both for the length of time spent underground and the build-up of traffic emissions. The open-air bridges were used to help break up the journey so less time would be spent in a tube beneath the waves. This design also created opportunity, for the artificial islands weren’t seen as just entry and exit points to the tunnel below. EuroRoute envisioned them as destinations in their own right, with refuelling, refreshment, and parking facilities, as well as other niceties like hotels and duty-free shopping complexes.
As built, traversing the Channel Tunnel via automobile requires a lengthy loading and unloading process, since the cars are hauled by train. Credit: Ministère des Affaires Étrangères Français
The rail component proposed by EuroRoute was remarkably similar to what was eventually built as part of the Channel Tunnel project. It concerned a tunnel running between Cheriton and Sangatte, though EuroRoute planned to use immersed tube construction for the majority of its length, rather than boring through the entire length as with the Channel Tunnel. Overall, though, it similarly featured two tubes for bidirectional travel, with a central shaft for maintenance access.

The Euro Route proposal noted that public sentiment was on its side. Contemporary research suggested that fifty-two percent of people preferred driving across, with many actively disliking the car shuttle concept. Yet when decision time came, the governments chose the Channel Tunnel—ultimately the simpler, cheaper rail-only proposal. The fact that the Channel Tunnel project would end up with massive budget overruns and significant delays perhaps casts that decision in a different light. At the same time, we might never know how well—or how badly—construction of the Euro Route might have gone.

EuroRoute’s bridges and islands seem destined to remain forever on the drawing board, another grand infrastructure dream that fell victim to caution and economics. But those architectural drawings still capture something important—the ambition of an era when it seemed anything could be built, even a bridge linking two former bitter enemies over the busiest shipping lanes in the world.


hackaday.com/2025/10/27/the-ch…


A digital age of majority


A digital age of majority
IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and you find me in New York this week. More on that to be published on Oct 29. For those of you in the Big Apple, please reach out here (even if it's to recommend your favorite coffee joints.)

— Countries are converging on the idea of setting a "digital age of majority" for when children can access online services.

— Artificial intelligence-powered deepfakes have yet to up-end democratic elections. But the technology is not far from becoming identical to real videos/photos.

— A select few companies are starting to take a commanding lead in the different layers that make up the global market for generative AI.

Let's get started:



digitalpolitics.co/newsletter0…


Satellite Snooping Reveals Sensitive Unencrypted Data


In an era where running a website without HTTPS is shunned, and everyone wants you to encrypt your DNS queries, you’d expect that the telecommunications back-ends are secured tightly as well. Especially the wireless bits between terra firma and geosynchronous communication satellites.

But as recently discovered by US researchers, the opposite is actually true. The paper by [Wenyi Morty Zhang] et al. (PDF) goes into great detail on how they discovered these unencrypted IP traffic flows and what they found in these captures.

With an off-the-shelf consumer satellite dish mounted to the roof of a university building in San Diego, they performed a scan of IP traffic on 39 geosynchronous satellites. To their surprise, they found unencrypted data that belonged to companies like T-Mobile for their cellular backhaul, Internet traffic targeting airliners, and VoIP communication — all in the clear.

Even more worrying was what looked like military traffic and corporate VPN data containing unencrypted login details, corporate emails and much more. While T-Mobile immediately enabled encryption after this discovery, it remains to be seen whether anyone else will. It’s probably best to assume that any communication can be intercepted and to use e.g. PGP-encrypted emails for anything sensitive.

The researchers have made the IP encapsulation parser (in Python) for DVB-S2(X) captures available for anyone who wants to give this experiment a whirl themselves.


hackaday.com/2025/10/27/satell…


Il segreto dietro la velocità di Space Invaders? Un limite tecnico dell’hardware


Nel 1978 Space Invaders della Taito conquistò il pubblico con un gameplay apparentemente geniale: più alieni venivano abbattuti, più rapidamente si muovevano quelli rimasti. Un crescendo di tensione che ha segnato la storia dei videogiochi arcade.

Ma, come rivelato dall’esperto di programmazione C/C++ Zuhaitz, quel ritmo incalzante non fu frutto di un’intuizione creativa, bensì di un limite tecnico del processore su cui il gioco era basato.

Secondo un’analisi pubblicata il 27 ottobre, il comportamento che rese Space Invaders così iconico è in realtà il risultato di un collo di bottiglia del processore Intel 8080, introdotto nel 1974.

Questo chip, dotato di circa 5.000 transistor e funzionante a una frequenza di 2 MHz, gestiva tutte le operazioni del gioco: dal calcolo delle posizioni al ridisegno sullo schermo, fino al rilevamento delle collisioni tra proiettili e alieni.

All’inizio di ogni partita, la CPU doveva elaborare simultaneamente i movimenti e le azioni di 55 alieni. Il carico di lavoro era quindi elevato e rallentava il rendering dei fotogrammi. Tuttavia, ogni volta che un alieno veniva distrutto, diminuiva la quantità di calcoli richiesti e il processore riusciva a eseguire le istruzioni più rapidamente. Il risultato fu un’accelerazione naturale del gameplay: meno alieni, maggiore velocità di gioco.

Curiosamente, nel codice sorgente originale non è presente alcuna istruzione progettata per aumentare intenzionalmente la velocità del gioco. L’effetto che i giocatori percepivano come un crescendo di difficoltà era dunque una conseguenza non programmata, ma estremamente efficace nel generare tensione e coinvolgimento.

Nelle versioni successive e negli emulatori moderni, i programmatori hanno dovuto introdurre manualmente limiti di velocità per replicare fedelmente la sensazione originale. Con l’hardware attuale, infatti, Space Invaders risulterebbe eccessivamente rapido senza una regolazione artificiale.

Tomohiro Nishikado 西角友宏, autore di Space Invaders, scoprì che il processore del videogioco era in grado di rendere ogni fotogramma della grafica di animazione dell’alieno più veloce quando c’erano meno alieni sullo schermo.

Poiché le posizioni degli alieni venivano aggiornate dopo ogni fotogramma, questo faceva sì che gli alieni si muovessero sullo schermo a una velocità crescente man mano che ne venivano distrutti sempre di più.

Piuttosto che progettare una compensazione per l’aumento di velocità, decise che si trattava di una caratteristica e non di un bug e lo mantenne come un meccanismo di gioco.

L'articolo Il segreto dietro la velocità di Space Invaders? Un limite tecnico dell’hardware proviene da Red Hot Cyber.


Magazine Transistor Tester Lives Again


One of the lost pleasures of our modern world is the experience of going shopping at a grocery store, a mall, or a drugstore, and finding this month’s electronics magazine festooned with projects that you might like to build. Sure, you can find anything on the Internet, but there’s something to be said about the element of surprise. Can any of those old projects still be of interest?

[Bettina Neumryr] thinks so. She has a hobby of finding old magazine projects and building them. Her most recent installment is a transistor tester from the June 1983 issue of Everyday Electronics.

The tester was quite a neat job for 1983, with a neat case and a PC board. It measures beta and leakage. There’s an analog meter that can measure the collector current for a fixed base current (beta or hfe). Leakage is how much current flows between emitter and collector with the base turned off.

In 1983, we’d have loved to have a laser printer to do toner transfer for the PC board, but of course, that was unheard of in hobby circles of the day. The tester seemed to work right off the bat, although there was a small adjustment necessary to calibrate the device. All that was left was to put it in a period-appropriate box with some printed labels.

We loved the old electronics and computer magazines. Usually, when we see someone working on an old magazine project, it is probably not quite a literal copy of it. But either way is cool.

youtube.com/embed/R4AF_30SUbA?…


hackaday.com/2025/10/27/magazi…


Arriva CoPhish! Microsoft Copilot Studio usato per rubare account


Gli aggressori utilizzano una tecnica di phishing avanzata, nota come CoPhish, che si avvale di Microsoft Copilot Studio per convincere gli utenti a concedere l’accesso non autorizzato ai propri account Microsoft Entra ID.

Un recente rapporto, descrive l’attacco nei dettagli e sottolinea come malgrado gli sforzi di Microsoft volti a rafforzare le politiche di consenso, permangano evidenti vulnerabilità negli strumenti di intelligenza artificiale offerti in cloud.

L’adozione crescente di strumenti come Copilot da parte delle organizzazioni evidenzia la necessità di un’attenta supervisione delle piattaforme low-code. In questo ambito, funzionalità configurabili dall’utente, progettate per favorire la produttività, possono inavvertitamente agevolare il phishing.
Un aggressore può utilizzare un agente Copilot Studio dannoso per indurre un bersaglio a cadere vittima di un attacco di phishing OAuth. L’aggressore o l’agente può quindi compiere azioni per conto dell’utente (Fonte Datadog Security Labs).
Questo attacco scoperto dai ricercatori di Datadog Security Labs, utilizza agenti di intelligenza artificiale personalizzabili ospitati su domini Microsoft legittimi per mascherare i tradizionali attacchi di consenso OAuth, facendoli apparire affidabili e aggirando i sospetti degli utenti.

Gli aggressori sono in grado di progettare e creare chatbot dall’aspetto innocuo, al fine di ottenere dagli utenti le credenziali di accesso e, successivamente, tokens OAuth utilizzabili per compiere azioni dannose, ad esempio, l’accesso ai calendari o la lettura delle email.

Gli attacchi di consenso OAuth, classificati nella tecnica MITRE ATT&CK T1528, consistono nell’indurre gli utenti ad approvare registrazioni di app dannose che richiedono ampie autorizzazioni per l’accesso a dati sensibili.

Gli attacchi condotti all’interno degli ambienti Entra ID prevedono la creazione di registri di applicazioni da parte degli aggressori al fine di ottenere l’accesso alle risorse messe a disposizione da Microsoft Graph, quali ad esempio la posta elettronica o OneNote. Ciò avviene mediante l’utilizzo di collegamenti di phishing che inducono le vittime a concedere il consenso. Una volta ottenuto l’approvazione, il token che ne deriva conferisce all’aggressore la possibilità di impersonificare l’utente, consentendo così l’estrazione dei dati o ulteriori azioni di compromissione.

Negli anni, Microsoft ha implementato misure di difesa più solide, come ad esempio le limitazioni relative alle applicazioni non verificate. Inoltre, un aggiornamento del luglio 2025 ha stabilito come impostazione predefinita “microsoft-user-default-recommended”, andando così a bloccare automaticamente l’accesso a autorizzazioni considerate ad alto rischio, quali Sites.Read.All e Files.Read.All, qualora non venga concessa l’approvazione da parte dell’amministratore.

Tuttavia, permangono delle lacune: gli utenti senza privilegi possono comunque approvare app interne per autorizzazioni come Mail.ReadWrite o Calendars.ReadWrite, mentre gli amministratori con ruoli come Amministratore applicazioni possono acconsentire a qualsiasi autorizzazione su qualsiasi app.

L'articolo Arriva CoPhish! Microsoft Copilot Studio usato per rubare account proviene da Red Hot Cyber.


Anatomia di un furto di dati: Analisi tecnica dell’Infostealer “Formbook”


Nel panorama delle minacce informatiche, pochi malware sono tanto persistenti e diffusi quanto Formbook. Nato come un semplice keylogger e form-grabber, si è evoluto in un potente infostealer venduto secondo il modello Malware-as-a-Service (MaaS), rendendolo accessibile a un’ampia platea di criminali informatici. La sua capacità di esfiltrare credenziali dai browser, client email e altri software lo rende uno strumento prediletto per ottenere un accesso iniziale alle reti aziendali.

In questo articolo, analizzeremo il sample di un dropper multi-stadio progettato per distribuire l’infostealer Formbook, e, a partire dalle evidenze raccolte, illustreremo le contromisure proposte da ELMI per prevenire, rilevare e rispondere a questa tipologia di minacce.

ELMIopera nel settore IT come System Integrator da quarant’anni, offrendo consulenza professionale e supportando aziende private e pubbliche nello sviluppo di progetti innovativi.
Attualmente, l’azienda è fortemente focalizzata sui temi della Digital Transformation, con particolare riferimento alle aree tecnologiche inerenti la Digitalizzazione dei processi, la Cyber Security, l’Asset Management, l’Intelligenza Artificiale generativa e la Blockchain.

Infostealer in azione: analisi tecnica di Formbook

Come osservato in diverse campagne recenti documentate anche dall’Agenzia per la Cybersicurezza Nazionale (ACN), la distribuzione di Formbook avviene principalmente tramite malspam (Malware Spam o Malicious Spam): email malevole confezionate per sembrare legittime (finte fatture, documenti di spedizione, preventivi o comunicazioni aziendali). Il messaggio contiene tipicamente un allegato (archivi compressi .zip/.rar o file Office con macro disabilitate) o un link che, una volta cliccato, porta al download di un file JavaScript offuscato. È proprio questo file, nel campione analizzato, a costituire il dropper iniziale che dà avvio alla catena di infezione.

L’obiettivo della fase iniziale è indurre l’utente a eseguire manualmente l’allegato — affidandosi quindi alla componente di ingegneria sociale più che a vulnerabilità software. Questo approccio, combinato con tecniche di offuscamento del codice e l’uso di servizi cloud legittimi per ospitare i payload successivi, rende la campagna particolarmente insidiosa e difficile da bloccare con i soli controlli perimetrali.

L’analisi è quindi partita da un campione JavaScript, rivelando una catena di infezione complessa che impiega PowerShell come stadio intermedio e culmina con l’esecuzione “fileless” del payload finale. L’attore della minaccia ha implementato molteplici tecniche di offuscamento ed evasione, e ha sfruttato un servizio legittimo (Google Drive) per ospitare il payload, rendendo il rilevamento basato sulla rete più difficile.

Questa analisi documenta in dettaglio ogni fase, mappando le Tattiche, Tecniche e Procedure (TTPs) osservate sul framework MITRE ATT&CK e fornendo gli Indicatori di Compromissione (IoCs) necessari per il rilevamento e la mitigazione.

L’obiettivo non è solo sezionare il malware, ma capire come un singolo file si inserisca nell’enorme ecosistema del cybercrime, alimentando il mercato nero dei dati e come possa impattare significativamente l’operatività e la riservatezza dei sistemi.

Nome File 8f7b48c9b0cb0702de08f98e8e4fb2cd47103b219beff7815dc8e742039c12cb.js

Tipo File .js

SHA256 8f7b48c9b0cb0702de08f98e8e4fb2cd47103b219beff7815dc8e742039c12cb

Dimensione 300 KB

Entropia 4976

VT https://www.virustotal.com

Dettaglio PEStudio


Catena d’infezione di Formbook: dal phishing all’esecuzione fileless
L’attacco si sviluppa attraverso una catena di eventi ben definita, progettata per aumentare la furtività e la probabilità di successo dell’infezione.

  1. Malspam: mail con link o allegato malevolo.
  2. Dropper: Viene eseguito il file .js iniziale. Lo script de-offusca e assembla in memoria un secondo payload, uno script PowerShell.
  3. Loader: Lo script JS scrive il payload PowerShell su disco in %APPDATA%Plaidtry.ps1 e tenta di eseguirlo.
  4. Evasione: Lo script PowerShell esegue controlli anti-analisi e anti-antivirus. Se l’ambiente è considerato sicuro, procede.
  5. Download: Lo script PowerShell contatta un URL su Google Drive per scaricare un terzo payload, un file contenente dati codificati in Base64 (Pidg.chl).
  6. Esecuzione Fileless: Il file scaricato viene letto, il suo contenuto Base64 viene decodificato in memoria, rivelando un iniettore di PE (Portable Executable).
  7. Iniezione: L’iniettore alloca memoria nel processo powershell.exe stesso, vi scrive il payload finale di Formbook e ne avvia l’esecuzione, il tutto senza che l’eseguibile di Formbook venga mai salvato su disco.


Analisi del dropper Iniziale (File JavaScript)


Il campione iniziale viene veicolato tramite campagne malspam , una delle tecniche di distribuzione più comuni per Formbook, come documentato anche dall’ACN. L’efficacia di questa prima fase non si basa su vulnerabilità software, ma interamente sull’ingegneria sociale, studiata per ingannare e indurre l’utente a compiere un’azione decisiva.

Individuati 23 temi, sfruttati per diffondere campagne malevole in Italia, nella settimana del 20-26 Settembre

L’attore della minaccia confeziona un’e-mail che appare come una comunicazione legittima e urgente, ad esempio una finta fattura, un documento di spedizione o un preventivo. Il corpo del messaggio è solitamente breve e spinge la vittima a scaricare un allegato o visualizzare un documento esterno tramite un link.

Le campagne individuate relative al malware Formbook, distribuiscono quest’ultimo mediante email con allegati compressi come ZIP,TAR,7z.

Una volta scaricato ed estratto l’archivio, ci troviamo davanti ad un file di testo con estensione .js. Analizzando l’hash del file tramite i principali motori di TI notiamo che esso risulta segnalato come Trojan.

Il codice sorgente è fortemente offuscato: dopo un primo passaggio di formattazione la struttura sintattica risulta leggibile, ma le funzioni operative restano deliberatamente nascoste da nomi di variabili non significativi e dalla frammentazione del codice. L’analisi si è pertanto concentrata sull’identificazione di funzionalità che consentono l’interazione con il sistema operativo. La scoperta chiave è stata l’uso intensivo di ActiveXObject per istanziare oggetti COM di sistema:

  • WScript.Shell: Per l’esecuzione di comandi.



  • Scripting.FileSystemObject: Per la manipolazione di file.



  • WbemScripting.SWbemLocator: Per l’interazione con WMI.



La logica principale dello script è un ciclo di assemblaggio: decodifica e concatena centinaia di piccole stringhe per costruire in memoria il payload della fase successiva, uno script PowerShell, che verrà salvato nella cartella %APPDATA% con il nome di “Plaidtry”.

Analisi del loader intermedio (script PowerShell)


Lo script Plaidtry.ps1 è a sua volta offuscato, ma con una logica interna. Contiene una funzione (Kuglepenne) di de-offuscamento che ricostruisce i comandi reali campionando caratteri da stringhe offuscate. Eseguendo questa funzione in un ambiente sicuro (PowerShell ISE), abbiamo potuto decodificare i comandi passo dopo passo.


Esempio de-offuscamento

Il cuore dello script è la logica di download. Imposta uno User-Agent di Firefox per mascherare la richiesta, quindi utilizza il metodo Net.WebClient.DownloadFile per scaricare un payload dall’URL di Google Drive precedentemente decodificato. Il file viene salvato come %APPDATA%Pidg.chl

Script PS de-offuscato

Dettaglio PROCMON

Dettaglio Folder

Il file Pidg.chl non è un eseguibile. È un file di testo contenente un’unica, lunga stringa codificata in Base64. Utilizzando PowerShell per decodificare questa stringa, abbiamo svelato l’ultimo e più pericoloso stadio dell’attacco: un iniettore di PE

Questo script, anch’esso altamente offuscato, è progettato per eseguire un file .exe senza mai scriverlo su disco. Le sue componenti chiave sono:

  • PE Incorporato: Una variabile contenente una stringa Base64 di centinaia di kilobyte. Questa è la rappresentazione testuale del file Formbook.exe.
  • API di Windows tramite P/Invoke: Lo script definisce un blocco di codice per creare un “ponte” verso le funzioni critiche di kernel32.dll, tra cui VirtualAlloc (per allocare memoria), WriteProcessMemory (per scrivere in memoria) e CreateThread (per eseguire codice in un nuovo thread).



La logica dello script è la seguente: decodifica la grande stringa Base64 per ricostruire in memoria i byte dell’eseguibile di Formbook. Successivamente, alloca una nuova regione di memoria all’interno del processo powershell.exe in cui è in esecuzione, vi copia i byte di Formbook e infine avvia un nuovo thread in quel punto.

Il risultato è che Formbook inizia la sua esecuzione come un thread all’interno di un processo PowerShell legittimo. A questo punto, l’infostealer inizierebbe la sua attività malevola: registrare i tasti premuti, rubare le credenziali salvate nei browser, catturare i dati dai form web e inviarli a un’altra infrastruttura C2 controllata dall’attaccante.

Indicazioni di mitigazione e contenimento contro gli infostealer


Dopo aver ricostruito la catena di infezione e le tecniche utilizzate da Formbook, è possibile delineare le principali azioni di mitigazione e contenimento. Lo scopo è ridurre la superficie d’attacco, bloccare la diffusione e preservare le evidenze per la triage/IR.

Mitigazione

  • Isolare l’host sospetto: rimuovere la macchina dalla rete aziendale (network segmentation/isolation) preservando la macchina accesa per acquisizione forense; evitare reboot non pianificati che potrebbero cancellare evidenze volatili.
  • Preservare le evidenze: acquisire immagine della memoria e snapshot del filesystem, raccogliere i log di processi, le chiavi di registro e i file sospetti (hash). Archiviare gli artefatti in area sicura con controllo degli accessi.
  • Bloccare IoC a livello di rete ed endpoint: importare gli hash, i domini e gli URL conosciuti nei sistemi di prevenzione (SIEM,NGFW,XDR) e applicare regole temporanee per limitare il traffico verso host sospetti.

Eradicazione

  • Indagine forense completa: correlare gli eventi (mail, download, esecuzione di script, attività di PowerShell) per stabilire il perimetro di compromissione e individuare eventuali movimenti laterali.
  • Rimozione controllata: con piani di ripristino, rimuovere le componenti malevole e ripristinare gli host compromessi da backup affidabili;
  • Rotazione credenziali: considerare la rotazione di credenziali e di eventuali segreti potenzialmente esfiltrati.

Prevenzione

  • Limitare l’esecuzione di scripting non autorizzato: applicare policy di gruppo (GPO) per disabilitare o restringere l’uso di Windows Script Host (WSH) e l’esecuzione di script in cartelle temporanee dove non necessario.
  • PowerShell: impostare policy di esecuzione restrittive, abilitare la protezione di runtime (AMSI/ConstrainedLanguage) e monitorare i moduli e le chiamate sospette.
  • Application Execution Control: adottare controlli di application whitelisting (AppLocker/WDAC) per impedire l’esecuzione di binari e script non autorizzati.
  • Monitoraggio comportamentale (XDR/EDR): attivare raccolta estesa di telemetria (process creation, parent/child chain, network connections, API di memoria) e regole di alerting su pattern sospetti (es. PowerShell con payload base64 molto lungo, uso di WScript.Shell, download da servizi di file hosting con agent/UA sospetto).
  • Segmentazione e least privilege: segmentare reti critiche e applicare principi di least privilege agli account e ai servizi.
  • Formazione e awareness: intensificare attività di phishing simulation e formazione degli utenti per ridurre il rischio d’apertura di allegati/JS malevoli.

Comunicazione e disclosure

  • Coordinare la notifica: segnalare gli IoC e i dettagli tecnici alle autorità competenti (CSIRT aziendale o nazionale) e, se del caso, ai provider di hosting (es. Google per file Drive abusivi) seguendo le procedure di disclosure responsabile.
  • Aggiornamento delle difese: condividere gli IoC con team Threat Intelligence e aggiornare regole SIEM/EDR per permettere threat hunting e prevenzione su larga scala.


Conclusioni sull’analisi di Formbook


L’analisi di questo campione dimostra una chiara tendenza verso catene di infezione complesse e “fileless”. L’attore della minaccia ha investito notevoli sforzi per eludere il rilevamento a ogni livello: l’offuscamento degli script iniziali, l’uso di servizi cloud legittimi per l’hosting dei payload e, infine, l’iniezione in memoria del malware vero e proprio.

Questa metodologia stratificata rappresenta una sfida significativa per le soluzioni di sicurezza tradizionali basate su firme e analisi di file. Sottolinea la necessità di un monitoraggio comportamentale avanzato (XDR) e costante in grado di rilevare attività anomale da parte di processi altrimenti legittimi come PowerShell. L’analisi, infine, ci ha permesso di ricostruire l’intera catena di attacco e di estrarre IoC e TTPs preziosi per rafforzare le posture difensive contro minacce simili.

Mapping MITRE ATT&CK per Formbook


Le TTPs osservate durante l’analisi sono state mappate sul framework MITRE ATT&CK.

TatticaID TecnicaNome TecnicaDescrizione
EsecuzioneT1059.007JavaScriptL’infezione iniziale parte da uno script JavaScript.
EsecuzioneT1059.001PowerShellPowerShell è usato come stadio intermedio per l’evasione e il download.
Evasione DifeseT1027Obfuscated Files or InformationSia lo script JS che quello PS sono pesantemente offuscati per impedire l’analisi.
Evasione DifeseT1562.001Disable or Modify ToolsLo script tenta di disabilitare servizi e controlla lo stato di Windows Defender.
Evasione DifeseT1055Process InjectionIl payload finale di FormBook viene iniettato in un processo legittimo in memoria.
EsecuzioneT1047Windows Management Instrumentation (WMI)Il dropper JS utilizza WMI per tentare di eseguire lo script PowerShell in modo furtivo.
Comando e ControlloT1105Ingress Tool TransferIl loader scarica il payload finale da una risorsa web esterna (Google Drive).
Comando e ControlloT1573.002Encrypted Channel: Asymmetric CryptographyViene utilizzata una connessione HTTPS (TLS) per scaricare il payload, crittografando il traffico.

Indicatori di Compromissione (IoCs)


  • SHA256 (JS):

8f7b48c9b0cb0702de08f98e8e4fb2cd47103b219beff7815dc8e742039c12cb

  • SHA256 (Pidg.chl):

C28CF95D3330128C056E6CA3CA23931DC8BBCB4385A1CE37037AF2E45B1734DC

  • SHA256 (Plaidtry.ps1):

14345A45F4D51C63DFCDD1A5DC1EDD42BB169109A8903E33C4657C92AF6DF2830

  • URL:

drive.google.com/uc?export=dow…

Fonti:ACN.GOV.IT ,CERT-AGID

Il supporto di ELMI nelle strategie di prevenzione e detection

ELMI propone un percorso integrato di prevenzione, rilevazione e risposta alle minaccestudiato specificamente per contrastare campagne di infostealer basate su phishing e fileless execution. La proposta combina soluzioni integrate, affiancando alla tecnologia un approccio consulenziale e formativo.

Soluzioni integrate per una sicurezza a 360°


Le misure tecniche rappresentano il primo baluardo nella protezione contro infostealer, richiedendo un’architettura di sicurezza multilivello che integra strumenti e processi dedicati. All’interno del suoSecurity Competence Center, ELMI mette a disposizione un set di soluzioni integrate che coprono l’intero ciclo di difesa.

  • Servizio SOC H24: Control Room dedicata al monitoraggio, triage e gestione degli eventi di sicurezza H24/7 che possono impattare l’infrastruttura aziendale.
  • ExtendedDetection & Response (XDR): soluzione di cybersecurity che integra e correla dati provenienti da endpoint, rete, email, server e cloud per offrire una visione unificata della sicurezza. Consente una rilevazione più rapida delle minacce e una risposta più efficace grazie all’analisi avanzata e all’automazione dei processi.
  • Domain Threat Intelligence: servizio avanzato che monitora e analizza i domini aziendali per individuare vulnerabilità, minacce emergenti e account compromessi. Attraverso strumenti di analisi e intelligenza artificiale, supporta la mitigazione dei rischi e la protezione dell’integrità dei domini.
  • Early Warning: bollettini informativi su minacce emergenti.
  • Vulnerability Assessment & Threat Hunting: individuazione preventiva delle vulnerabilità e ricerca proattiva di minacce avanzate non ancora rilevate dai sistemi automatici.
  • Cybersecurity Awareness: attività di formazione dedicate, per mantenere alta la consapevolezza del rischio e rafforzare la resilienza aziendale.

Il Security Competence Center integra, inoltre, servizi di Network Operation Center(NOC), dedicati alla gestione e al monitoraggio continuo della rete, e Managed Services, che consentono la gestione remota dell’infrastruttura IT, permettendo di configurare e controllare a distanza tutti i componenti aziendali.

I punti di forza del Security Competence Center di ELMI risiedono nell’approccio integrato agli incidenti informatici, nella disponibilità operativa H24 su tutto il territorio e nella capacità di offrire servizi personalizzati a 360°, garantendo così una protezione coerente e completa.

L’obiettivo non è solo quello di fornire singoli strumenti, ma costruire insieme al cliente una difesa coordinata, capace di anticipare le minacce, accelerare il rilevamento e garantire una risposta immediata.

Un approccio consulenziale e progressivo alla cybersecurity


A garantire l’efficacia dell’intero processo è la competenza di un team multidisciplinare, composto da figure specializzate come network engineer, system administrator e security analyst, con un solido background operativo e una visione end-to-end dell’infrastruttura IT.

Affrontare efficacemente il rischio cyber richiede un approccio strutturato, personalizzato e progressivo.Il supporto di ELMI si articola in tre momenti chiave:

  • Audit preliminare,per fotografare lo stato di sicurezza e individuare le aree più critiche;
  • Assessment tecnico e organizzativo, che misura la maturità delle difese esistenti rispetto a standard e framework internazionali;
  • Roadmap personalizzata, con un piano d’azione su misura che unisce rafforzamento tecnologico, attivazione dei servizi SOC, formazione e definizione di policy.

Grazie a un approccio consulenziale e operativo integrato, ELMI accompagna i clienti lungo tutto il percorso di rafforzamento della postura di sicurezza, assicurando una progressiva riduzione del rischio e una maggiore resilienza rispetto a minacce complesse e in continua evoluzione.

L'articolo Anatomia di un furto di dati: Analisi tecnica dell’Infostealer “Formbook” proviene da Red Hot Cyber.


Record-Breaking Robots at Guinness World Records


If you ever wanted to win a bar bet about a world record, you probably know about the Guinness book for World Records. Did you know, though, that there are some robots in that book? Guinness pointed some out in a recent post.

Ever wonder about the longest table-tennis rally with a robot or the fastest robotic cube solver? No need to wonder anymore.

Our favorite was the fastest robot to solve a puzzle cube. This robot solved the Rubik’s Cube in 103 milliseconds! Don’t blink or you’ll miss it in the video embedded. Of course, the real kudos go to the team that created the robot: [Matthew Patrohay], [Junpei Ota], [Aden Hurd], and [Alex Berta].

Another favorite was the smallest humanoid robot. In order to win this record, the robot must be able to move its shoulders, elbows, knees, and hips just like a human. It also has to be able to walk on two feet. This tiny little guy meets the requirements and stands only 57.6 mm (2.26 in) tall! Created by [Tatsuhiko Mitsuya] in April 2024, this robot can be controlled via Bluetooth.

We’ve seen entries in this category before — check them out in Almost Breaking The World Record For The Tiniest Humanoid Robot, But Not Quite.

youtube.com/embed/Ogchiuuhxnc?…


hackaday.com/2025/10/26/record…


Mem3nt0 mori – The Hacking Team is back!


In March 2025, Kaspersky detected a wave of infections that occurred when users clicked on personalized phishing links sent via email. No further action was required to initiate the infection; simply visiting the malicious website using Google Chrome or another Chromium-based web browser was enough.

The malicious links were personalized and extremely short-lived to avoid detection. However, Kaspersky’s technologies successfully identified a sophisticated zero-day exploit that was used to escape Google Chrome’s sandbox. After conducting a quick analysis, we reported the vulnerability to the Google security team, who fixed it as CVE-2025-2783.

Acknowledgement for finding CVE-2025-2783 (excerpt from the security fixes included into Chrome 134.0.6998.177/.178)
Acknowledgement for finding CVE-2025-2783 (excerpt from the security fixes included into Chrome 134.0.6998.177/.178)

We dubbed this campaign Operation ForumTroll because the attackers sent personalized phishing emails inviting recipients to the Primakov Readings forum. The lures targeted media outlets, universities, research centers, government organizations, financial institutions, and other organizations in Russia. The functionality of the malware suggests that the operation’s primary purpose was espionage.

We traced the malware used in this attack back to 2022 and discovered more attacks by this threat actor on organizations and individuals in Russia and Belarus. While analyzing the malware used in these attacks, we discovered an unknown piece of malware that we identified as commercial spyware called “Dante” and developed by the Italian company Memento Labs (formerly Hacking Team).

Similarities in the code suggest that the Operation ForumTroll campaign was also carried out using tools developed by Memento Labs.

In this blog post, we’ll take a detailed look at the Operation ForumTroll attack chain and reveal how we discovered and identified the Dante spyware, which remained hidden for years after the Hacking Team rebrand.

Attack chain


Operation ForumTroll attack chain
Operation ForumTroll attack chain

In all known cases, infection occurred after the victim clicked a link in a spear phishing email that directed them to a malicious website. The website verified the victim and executed the exploit.

When we first discovered and began analyzing this campaign, the malicious website no longer contained the code responsible for carrying out the infection; it simply redirected visitors to the official Primakov Readings website.

Therefore, we could only work with the attack artifacts discovered during the first wave of infections. Fortunately, Kaspersky technologies detected nearly all of the main stages of the attack, enabling us to reconstruct and analyze the Operation ForumTroll attack chain.

Phishing email


Example of a malicious email used in this campaign (translated from Russian)
Example of a malicious email used in this campaign (translated from Russian)

The malicious emails sent by the attackers were disguised as invitations from the organizers of the Primakov Readings scientific and expert forum. These emails contained personalized links to track infections. The emails appeared authentic, contained no language errors, and were written in the style one would expect for an invitation to such an event. Proficiency in Russian and familiarity with local peculiarities are distinctive features of the ForumTroll APT group, traits that we have also observed in its other campaigns. However, mistakes in some of those other cases suggest that the attackers were not native Russian speakers.

Validator


The validator is a relatively small script executed by the browser. It validates the victim and securely downloads and executes the next stage of the attack.

The first action the validator performs is to calculate the SHA-256 of the random data received from the server using the WebGPU API. It then verifies the resulting hash. This is done using the open-source code of Marco Ciaramella’s sha256-gpu project. The main purpose of this check is likely to verify that the site is being visited by a real user with a real web browser, and not by a mail server that might follow a link, emulate a script, and download an exploit. Another possible reason for this check could be that the exploit triggers a vulnerability in the WebGPU API or relies on it for exploitation.

The validator sends the infection identifier, the result of the WebGPU API check and the newly generated public key to the C2 server for key exchange using the Elliptic-curve Diffie–Hellman (ECDH) algorithm. If the check is passed, the server responds with an AES-GCM key. This key is used to decrypt the next stage, which is hidden in requests to bootstrap.bundle.min.js and .woff2 font files. Following the timeline of events and the infection logic, this next stage should have been a remote code execution (RCE) exploit for Google Chrome, but it was not obtained during the attack.

Sandbox escape exploit


List of in-the-wild 0-days caught and reported by Kaspersky
List of in-the-wild 0-days caught and reported by Kaspersky

Over the years, we have discovered and reported on dozens of zero-day exploits that were actively used in attacks. However, CVE-2025-2783 is one of the most intriguing sandbox escape exploits we’ve encountered. This exploit genuinely puzzled us because it allowed attackers to bypass Google Chrome’s sandbox protection without performing any obviously malicious or prohibited actions. This was due to a powerful logical vulnerability caused by an obscure quirk in the Windows OS.

To protect against bugs and crashes, and enable sandboxing, Chrome uses a multi-process architecture. The main process, known as the browser process, handles the user interface and manages and supervises other processes. Sandboxed renderer processes handle web content and have limited access to system resources. Chrome uses Mojo and the underlying ipcz library, introduced to replace legacy IPC mechanisms, for interprocess communication between the browser and renderer processes.

The exploit we discovered came with its own Mojo and ipcz libraries that were statically compiled from official sources. This enabled attackers to communicate with the IPC broker within the browser process without having to manually craft and parse ipcz messages. However, this created a problem for us because, to analyze the exploit, we had to identify all the Chrome library functions it used. This involved a fair amount of work, but once completed, we knew all the actions performed by the exploit.

In short, the exploit does the following:

  • Resolves the addresses of the necessary functions and code gadgets from dll using a pattern search.
  • Hooks the v8_inspector::V8Console::Debug function. This allows attackers to escape the sandbox and execute the desired payload via a JavaScript call.
  • Starts executing a sandbox escape when attackers call console.debug(0x42, shellcode); from their script.
  • Hooks the ipcz::NodeLink::OnAcceptRelayedMessage function.
  • Creates and sends an ipcz message of the type RelayMessage. This message type is used to pass Windows OS handles between two processes that do not have the necessary permissions (e.g., renderer processes). The exploit retrieves the handle returned by the GetCurrentThread API function and uses this ipcz message to relay it to itself. The broker transfers handles between processes using the DuplicateHandle API function.
  • Receives the relayed message back using the ipcz::NodeLink::OnAcceptRelayedMessage function hook, but instead of the handle that was previously returned by the GetCurrentThread API function, it now contains a handle to the thread in the browser process!
  • Uses this handle to execute a series of code gadgets in the target process by suspending the thread, setting register values using SetThreadContext, and resuming the thread. This results in shellcode execution in the browser process and subsequent installation of a malware loader.

So, what went wrong, and how was this possible? The answer can be found in the descriptions of the GetCurrentThread and GetCurrentProcess API functions. When these functions are called, they don’t return actual handles; rather, they return pseudo handles, special constants that are interpreted by the kernel as a handle to the current thread or process. For the current process, this constant is -1 (also equal to INVALID_HANDLE_VALUE, which brings its own set of quirks), and the constant for the current thread is -2. Chrome’s IPC code already checked for handles equal to -1, but there were no checks for -2 or other undocumented pseudo handles. This oversight led to the vulnerability. As a result, when the broker passed the -2 pseudo handle received from the renderer to the DuplicateHandle API function while processing the RelayMessage, it converted -2 into a real handle to its own thread and passed it to the renderer.

Shortly after the patch was released, it became clear that Chrome was not the only browser affected by the issue. Firefox developers quickly identified a similar pattern in their IPC code and released an update under CVE-2025-2857.

When pseudo handles were first introduced, they simplified development and helped squeeze out extra performance – something that was crucial on older PCs. Now, decades later, that outdated optimization has come back to bite us.

Could we see more bugs like this? Absolutely. In fact, this represents a whole class of vulnerabilities worth hunting for – similar issues may still be lurking in other applications and Windows system services.

To learn about the hardening introduced in Google Chrome following the discovery of CVE-2025-2783, we recommend checking out Alex Gough’s upcoming presentation, “Responding to an ITW Chrome Sandbox Escape (Twice!),” at Kawaiicon.

Persistent loader


Persistence is achieved using the Component Object Model (COM) hijacking technique. This method exploits a system’s search order for COM objects. In Windows, each COM class has a registry entry that associates the CLSID (128-bit GUID) of the COM with the location of its DLL or EXE file. These entries are stored in the system registry hive HKEY_LOCAL_MACHINE (HKLM), but can be overridden by entries in the user registry hive HKEY_CURRENT_USER (HKCU). This enables attackers to override the CLSID entry and run malware when the system attempts to locate and run the correct COM component.

COM hijacking in a nutshell
COM hijacking in a nutshell

The attackers used this technique to override the CLSID of twinapi.dll {AA509086-5Ca9-4C25-8F95-589D3C07B48A} and cause the system processes and web browsers to load the malicious DLL.

This malicious DLL is a loader that decrypts and executes the main malware. The payload responsible for loading the malware is encoded using a simple binary encoder similar to those found in the Metasploit framework. It is also obfuscated with OLLVM. Since the hijacked COM object can be loaded into many processes, the payload checks the name of the current process and only loads the malware when it is executed by certain processes (e.g., rdpclip.exe). The main malware is decrypted using a modified ChaCha20 algorithm. The loader also has the functionality to re-encrypt the malware using the BIOS UUID to bind it to the infected machine. The decrypted data contains the main malware and a shellcode generated by Donut that launches it.

LeetAgent


LeetAgent is the spyware used in the Operation ForumTroll campaign. We named it LeetAgent because all of its commands are written in leetspeak. You might not believe it, but this is rare in APT malware. The malware connects to one of its C2 servers specified in the configuration and uses HTTPS to receive and execute commands identified by unique numeric values:

  • 0xC033A4D (COMMAND) – Run command with cmd.exe
  • 0xECEC (EXEC) – Execute process
  • 0x6E17A585 (GETTASKS) – Get list of tasks that agent is currently executing
  • 0x6177 (KILL) – Stop task
  • 0xF17E09 (FILE \x09) – Write file
  • 0xF17ED0 (FILE \xD0) – Read file
  • 0x1213C7 (INJECT) – Inject shellcode
  • 0xC04F (CONF) – Set communication parameters
  • 0xD1E (DIE) – Quit
  • 0xCD (CD) – Change current directory
  • 0x108 (JOB) – Set parameters for keylogger or file stealer

In addition to executing commands received from its C2, it runs keylogging and file-stealing tasks in the background. By default, the file-stealer task searches for documents with the following extensions: *.doc, *.xls, *.ppt, *.rtf, *.pdf, *.docx, *.xlsx, *.pptx.

The configuration data is encoded using the TLV (tag-length-value) scheme and encrypted with a simple single-byte XOR cipher. The data contains settings for communicating with the C2, including many settings for traffic obfuscation.

In most of the observed cases, the attackers used the Fastly.net cloud infrastructure to host their C2. Attackers frequently use it to download and run additional tools such as 7z, Rclone, SharpChrome, etc., as well as additional malware (more on that below).

The number of traffic obfuscation settings may indicate that LeetAgent is a commercial tool, though we have only seen ForumTroll APT use it.

Finding Dante


In our opinion, attributing unknown malware is the most challenging aspect of security research. Why? Because it’s not just about analyzing the malware or exploits used in a single attack; it’s also about finding and analyzing all the malware and exploits used in past attacks that might be related to the one you’re currently investigating. This involves searching for and investigating similar attacks using indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs), as well as identifying overlaps in infrastructure, code, etc. In short, it’s about finding and piecing together every scrap of evidence until a picture of the attacker starts to emerge.

We traced the first use of LeetAgent back to 2022 and discovered more ForumTroll APT attacks on organizations and individuals in Russia and Belarus. In many cases, the infection began with a phishing email containing malicious attachments with the following names:

  • Baltic_Vector_2023.iso (translated from Russian)
  • DRIVE.GOOGLE.COM (executable file)
  • Invitation_Russia-Belarus_strong_partnership_2024.lnk (translated from Russian)
  • Various other file names mentioning individuals and companies

In addition, we discovered another cluster of similar attacks that used more sophisticated spyware instead of LeetAgent. We were also able to track the first use of this spyware back to 2022. In this cluster, the infections began with phishing emails containing malicious attachments with the following names:

  • SCAN_XXXX_<DATE>.pdf.lnk
  • <DATE>_winscan_to_pdf.pdf.lnk
  • Rostelecom.pdf.lnk (translated from Russian)
  • Various others

The attackers behind this activity used similar file system paths and the same persistence method as the LeetAgent cluster. This led us to suspect that the two clusters might be related, and we confirmed a direct link when we discovered attacks in which this much more sophisticated spyware was launched by LeetAgent.

Connection between LeetAgent and commercial spyware called Dante
Connection between LeetAgent and commercial spyware called Dante

After analyzing this previously unknown, sophisticated spyware, we were able to identify it as commercial spyware called Dante, developed by the Italian company Memento Labs.

The Atlantic Council’s Cyber Statecraft Initiative recently published an interesting report titled “Mythical Beasts and where to find them: Mapping the global spyware market and its threats to national security and human rights.” We think that comparing commercial spyware to mythical beasts is a fitting analogy. While everyone in the industry knows that spyware vendors exist, their “products” are rarely discovered or identified. Meanwhile, the list of companies developing commercial spyware is huge. Some of the most famous are NSO Group, Intellexa, Paragon Solutions, Saito Tech (formerly Candiru), Vilicius Holding (formerly FinFisher), Quadream, Memento Labs (formerly Hacking Team), negg Group, and RCS Labs. Some are always in the headlines, some we have reported on before, and a few have almost completely faded from view. One company in the latter category is Memento Labs, formerly known as Hacking Team.

Hacking Team (also stylized as HackingTeam) is one of the oldest and most famous spyware vendors. Founded in 2003, Hacking Team became known for its Remote Control Systems (RCS) spyware, used by government clients worldwide, and for the many controversies surrounding it. The company’s trajectory changed dramatically in 2015 when more than 400 GB of internal data was leaked online following a hack. In 2019, the company was acquired by InTheCyber Group and renamed Memento Labs. “We want to change absolutely everything,” the Memento Labs owner told Motherboard in 2019. “We’re starting from scratch.” Four years later, at the ISS World MEA 2023 conference for law enforcement and government intelligence agencies, Memento Labs revealed the name of its new surveillance tool – DANTE. Until now, little was known about this malware’s capabilities, and its use in attacks had not been discovered.

Excerpt from the agenda of the ISS World MEA 2023 conference (the typo was introduced on the conference website)
Excerpt from the agenda of the ISS World MEA 2023 conference (the typo was introduced on the conference website)

The problem with detecting and attributing commercial spyware is that vendors typically don’t include their copyright information or product names in their exploits and malware. In the case of the Dante spyware, however, attribution was simple once we got rid of VMProtect’s obfuscation and found the malware name in the code.

Dante spyware name in the code
Dante spyware name in the code

Dante


Of course, our attribution isn’t based solely on the string “Dante” found in the code, but it was an important clue that pointed us in the right direction. After some additional analysis, we found a reference to a “2.0” version of the malware, which matches the title of the aforementioned conference talk. We then searched for and identified the most recent samples of Hacking Team’s Remote Control Systems (RCS) spyware. Memento Labs kept improving its codebase until 2022, when it was replaced by Dante. Even with the introduction of the new malware, however, not everything was built from scratch; the later RCS samples share quite a few similarities with Dante. All these findings make us very confident in our attribution.

Why did the authors name it Dante? This may be a nod to tradition, as RCS spyware was also known as “Da Vinci”. But it could also be a reference to Dante’s poem Divine Comedy, alluding to the many “circles of hell” that malware analysts must pass through when detecting and analyzing the spyware given its numerous anti-analysis techniques.

First of all, the spyware is packed with VMProtect. It obfuscates control flow, hides imported functions, and adds anti-debugging checks. On top of that, almost every string is encrypted.

VMProtect anti-debugging technique
VMProtect anti-debugging technique

To protect against dynamic analysis, Dante uses the following anti-hooking technique: when code needs to execute an API function, its address is resolved using a hash, its body is parsed to extract the system call number, and then a new system call stub is created and used.

Dante anti-hooking technique (simplified)
Dante anti-hooking technique (simplified)

In addition to VMProtect’s anti-debugging techniques, Dante uses some common methods to detect debuggers. Specifically, it checks the debug registers (Dr0–Dr7) using NtGetContextThread, inspects the KdDebuggerEnabled field in the KUSER_SHARED_DATA structure, and uses NtQueryInformationProcess to detect debugging by querying the ProcessDebugFlags, ProcessDebugPort, ProcessDebugObjectHandle, and ProcessTlsInformation classes.

To protect itself from being discovered, Dante employs an interesting method of checking the environment to determine if it is safe to continue working. It queries the Windows Event Log for events that may indicate the use of malware analysis tools or virtual machines (as a guest or host).

The strings Dante searches for in the event logs
The strings Dante searches for in the event logs

It also performs several anti-sandbox checks. It searches for “bad” libraries, measures the execution times of the sleep() function and the cpuid instruction, and checks the file system.

Some of these anti-analysis techniques may be a bit annoying, but none of them really work or can stop a professional malware analyst. We deal with these techniques on an almost daily basis.

After performing all the checks, Dante does the following: decrypts the configuration and the orchestrator, finds the string “DANTEMARKER” in the orchestrator, overwrites it with the configuration, and then loads the orchestrator.

The configuration is decrypted from the data section of the malware using a simple XOR cipher. The orchestrator is decrypted from the resource section and poses as a font file. Dante can also load and decrypt the orchestrator from the file system if a newer, updated version is available.

The orchestrator displays the code quality of a commercial product, but isn’t particularly interesting. It is responsible for communication with C2 via HTTPs protocol, handling modules and configuration, self-protection, and self-removal.

Modules can be saved and loaded from the file system or loaded from memory. The infection identifier (GUID) is encoded in Base64. Parts of the resulting string are used to derive the path to a folder containing modules and the path to additional settings stored in the registry.

An example of Dante's paths derivation
An example of Dante’s paths derivation

The folder containing modules includes a binary file that stores information about all downloaded modules, including their versions and filenames. This metadata file is encrypted with a simple XOR cipher, while the modules are encrypted with AES-256-CBC, using the first 0x10 bytes of the module file as the IV and the key bound to the machine. The key is equal to the SHA-256 hash of a buffer containing the CPU identifier and the Windows Product ID.

To protect itself, the orchestrator uses many of the same anti-analysis techniques, along with additional checks for specific process names and drivers.

If Dante doesn’t receive commands within the number of days specified in the configuration, it deletes itself and all traces of its activity.

At the time of writing this report, we were unable to analyze additional modules because there are currently no active Dante infections among our users. However, we would gladly analyze them if they become available. Now that information about this spyware has been made public and its developer has been identified, we hope it won’t be long before additional modules are discovered and examined. To support this effort, we are sharing a method that can be used to identify active Dante spyware infections (see the Indicators of compromise section).

Although we didn’t see the ForumTroll APT group using Dante in the Operation ForumTroll campaign, we have observed its use in other attacks linked to this group. Notably, we saw several minor similarities between this attack and others involving Dante, such as similar file system paths, the same persistence mechanism, data hidden in font files, and other minor details. Most importantly, we found similar code shared by the exploit, loader, and Dante. Taken together, these findings allow us to conclude that the Operation ForumTroll campaign was also carried out using the same toolset that comes with the Dante spyware.

Conclusion


This time, we have not one, but three conclusions.

1) DuplicateHandle is a dangerous API function. If the process is privileged and the user can provide a handle to it, the code should return an error when a pseudo-handle is supplied.

2) Attribution is the most challenging part of malware analysis and threat intelligence, but also the most rewarding when all the pieces of the puzzle fit together perfectly. If you ever dreamed of being a detective as a child and solving mysteries like Sherlock Holmes, Miss Marple, Columbo, or Scooby-Doo and the Mystery Inc. gang, then threat intelligence might be the right job for you!

3) Back in 2019, Hacking Team’s new owner stated in an interview that they wanted to change everything and start from scratch. It took some time, but by 2022, almost everything from Hacking Team had been redone. Now that Dante has been discovered, perhaps it’s time to start over again.

Full details of this research, as well as future updates on ForumTroll APT and Dante, are available to customers of the APT reporting service through our Threat Intelligence Portal.

Contact: intelreports@kaspersky.com

Indicators of compromise


Kaspersky detections
Exploit.Win32.Generic
Exploit.Win64.Agent
Trojan.Win64.Agent
Trojan.Win64.Convagent.gen
HEUR:Trojan.Script.Generic
PDM:Exploit.Win32.Generic
PDM:Trojan.Win32.Generic
UDS:DangerousObject.Multi.Generic

Folder with modules
The folder containing the modules is located in %LocalAppData%, and is named with an eight-byte Base64 string. It contains files without extensions whose names are also Base64 strings that are eight bytes long. One of the files has the same name as the folder. This information can be used to identify an active infection.

Loader
7d3a30dbf4fd3edaf4dde35ccb5cf926
3650c1ac97bd5674e1e3bfa9b26008644edacfed
2e39800df1cafbebfa22b437744d80f1b38111b471fa3eb42f2214a5ac7e1f13

LeetAgent
33bb0678af6011481845d7ce9643cedc
8390e2ebdd0db5d1a950b2c9984a5f429805d48c
388a8af43039f5f16a0673a6e342fa6ae2402e63ba7569d20d9ba4894dc0ba59

Dante
35869e8760928407d2789c7f115b7f83
c25275228c6da54cf578fa72c9f49697e5309694
07d272b607f082305ce7b1987bfa17dc967ab45c8cd89699bcdced34ea94e126


securelist.com/forumtroll-apt-…


VFETs are (Almost) Solid State Tubes


We always enjoy videos from [w2aew]. His recent entry looks at vertical or VFETs, which are, as he puts it, a JFET that thinks it is a triode. He clearly explains how the transistor works as a conductor unless you bias the gate to form a depletion zone.

The transistors have a short channel, which means they conduct quite well. The low gate resistance and capacitance mean the devices can also switch very quickly. These devices were once in vogue for audio applications. However, they’d fallen out of favor until recently. The reason is that they work quite well in switching power supplies.

How good is the on resistance? So good that his meter reported the probes were shorted instead of measuring the resistance. Pretty good. We’ve seen these VFET transistors used as switches to drive magnetic field coils many years ago and they replaced much more complex circuitry.

The curve tracer in the video is a beautiful instrument of its own. The digital displays give it a high tech yet retro look. A curve tracer, if you haven’t used one, plots stepped voltages against current flowing, and is very useful for examining semiconductor devices. While not as fancy, it is possible to make one to connect to a scope quite easily.

We are pretty sure that it is a Tektronix 576. We watched a repair of a similar unit, the 577, if you’d like to see some (probably) similar insides.

youtube.com/embed/93ke5wM0gZ0?…


hackaday.com/2025/10/26/vfets-…


Hackaday Links: October 26, 2025


Hackaday Links Column Banner

There was a bit of a kerfuffle this week with the news that an airliner had been hit by space junk. The plane, a United Airlines 737, was operating at 36,000 feet on a flight between Denver and Los Angeles when the right windscreen was completely shattered by the impact, peppering the arm of one pilot with bits of glass. Luckily, the heavily reinforced laminated glass stayed intact, but the flight immediately diverted to Salt Lake City and landed safely with no further injuries. The “space junk” report apparently got started by the captain, who reported that they saw what hit them and that “it looked like space debris.”

We were a little skeptical of this initial assessment, mainly because the pilots and everyone aboard the flight were still alive, which we’d assume would be spectacularly untrue had the plane been hit by anything beyond the smallest bit of space junk. As it turns out, our suspicions were justified when Silicon Valley startup WindBorne Systems admitted that one of its high-altitude balloons hit the flight. The company, which uses HABs to gather weather data for paying customers, seems to have complied with all the pertinent regulations, like filing a NOTAM, so why the collision happened is a bit of a mystery.

Their blog post about the incident contains a clue, though, since they have made an immediate change to “minimize time spent between 30,000 and 40,000 feet,” which is the sweet spot for commercial aviation. They also state that future changes will allow them to monitor flight tracking data and autonomously avoid planes. From this, we gather that the balloons can at least control their altitude, which perhaps means this one somehow got stuck at 36,000 feet. We’d love to know more about these HABs; we wonder if there’s any way to track and recover these things like there is for radiosondes?

In other initially fake news, there was a bit of a stir in amateur radio circles with a report that Hytera ham radios were being banned from sale in the U.S. The report came in a video from Matt Covers Tech, and suggested that Hytera’s handy talkie radios had somehow fallen afoul of regulators. We did some checking around but couldn’t come up with anything to back up this claim until the indispensable Josh (KI6NAZ) over at Ham Radio Crash Course got ahold of the story and did his usual bang-up analysis. TL;DW — no, Hytera handy talkies are not being banned from sale in the U.S., but yes, the company does seem to be in a heap of trouble with the FCC and the federal government over some of their other shenanigans, to the point of felony indictments.

youtube.com/embed/RsX3JztCcLU?…

Back in the day, pranks were pretty simple and, with the possible exception of a burning poop-filled paper bag catching the bushes next to your front step on fire, mostly harmless. But pranks seem to scale with time and with technology, to the point where it’s now possible to stuff a dead-end street with 50 Waymos robotaxis. The stunt, which prankster Riley Walz describes in high-tech terms as “the world’s first Waymo DDoS” attack — we seriously doubt that — was carried out in a decidedly low-tech manner by enlisting 50 co-conspirators to simultaneously order a ride to San Francisco’s longest dead-end street. The Jaguar robotaxis dutifully reported to the address, packing the narrow street with waiting cars. Nobody got into the cars, resulting in a $5 missed-ride charge, but even if the riders did show up, we assume the autonomous cars would have had the robot equivalent of a stroke trying to figure out how to get out of each other’s way. Like most pranks, it was pretty cool as long as you weren’t the one on the receiving end. It’s not clear whether there were any repercussions for Riley — again, we doubt it — but we can imagine there would have been had anyone on that street needed fire or EMS while the attack was in progress.

If you’ve been worried about AI, you’re not alone. And while there’s plenty to be concerned about, according to Andy Masley, water use by AI data centers shouldn’t be one of them. In his excellent analysis, he looks at all the details of AI water use and comes to the convincing conclusion that, all things considered, U.S. data centers really don’t use that much water — about 0.2% of the 132 billion gallons consumed nationwide every day. Even then, that fraction of a percent includes the water needed to generate the electricity for those data centers; take that out, and the number drops to about 50 million gallons a day. And those figures are for all data centers; limited to just AI data centers, that number drops to about 0.008% of the freshwater consumed daily nationwide. We haven’t checked Andy’s math, of course, nor have we vetted his bona fides or checked to see if he has an axe to grind in this area. But it’s an eye-opening article nonetheless.

And finally, if you just can’t get enough of the surveillance state while you’re out in the world, you can now extend pervasive monitoring tech into the very heart of your home with the world’s first toilet wearable. The aptly named Throne One clips to the rim of your toilet and uses an array of sensors to monitor your gut health. The company doesn’t specify what sensors are used, but since the main data points seem to be where your poop falls on the Bristol Stool Scale and measuring hydration by urine color, there’s got to be a camera in there somewhere. There’s also allowance for multiple users, and while we suppose the polar opposite of facial recognition could be used to distinguish one butt from another, we’d imagine it would be simpler to determine who’s using the toilet via Bluetooth. There’s also a microphone, to listen in on “urinary dynamics” for those who pee standing up. Honestly, while we’d never actually use this thing, we’d love to do a teardown and see what’s inside. New in box only, of course.


hackaday.com/2025/10/26/hackad…