In early 2025, security researchers uncovered a new malware family named Webrat. Initially, the Trojan targeted regular users by disguising itself as cheats for popular games like Rust, Counter-Strike, and Roblox, or as cracked software. In September, the attackers decided to widen their net: alongside gamers and users of pirated software, they are now targeting inexperienced professionals and students in the information security field.

Distribution and the malicious sample

In October, we uncovered a campaign that had been distributing Webrat via GitHub repositories since at least September. To lure in victims, the attackers leveraged vulnerabilities frequently mentioned in security advisories and industry news. Specifically, they disguised their malware as exploits for the following vulnerabilities with high CVSSv3 scores:

This is not the first time threat actors have tried to lure security researchers with exploits. Last year, they similarly took advantage of the high-profile RegreSSHion vulnerability, which lacked a working PoC at the time.

In the Webrat campaign, the attackers bait their traps with both vulnerabilities lacking a working exploit and those which already have one. To build trust, they carefully prepared the repositories, incorporating detailed vulnerability information into the descriptions. The information is presented in the form of structured sections, which include:

• Overview with general information about the vulnerability and its potential consequences
• Specifications of systems susceptible to the exploit
• Guide for downloading and installing the exploit
• Guide for using the exploit
• Steps to mitigate the risks associated with the vulnerability

Contents of the repository

In all the repositories we investigated, the descriptions share a similar structure, characteristic of AI-generated vulnerability reports, and offer nearly identical risk mitigation advice, with only minor variations in wording. This strongly suggests that the text was machine-generated.

The Download Exploit ZIP link in the Download & Install section leads to a password-protected archive hosted in the same repository. The password is hidden within the name of a file inside the archive.

The archive downloaded from the repository includes four files:

1. pass – 8511: an empty file, whose name contains the password for the archive.
2. payload.dll: a decoy, which is a corrupted PE file. It contains no useful information and performs no actions, serving only to divert attention from the primary malicious file.
3. rasmanesc.exe (note: file names may vary): the primary malicious file (MD5 61b1fc6ab327e6d3ff5fd3e82b430315), which performs the following actions:
   
   • Escalate its privileges to the administrator level (T1134.002).
   • Disable Windows Defender (T1562.001) to avoid detection.
   • Fetch from a hardcoded URL (ezc5510min.temp[.]swtest[.]ru in our example) a sample of the Webrat family and execute it (T1608.001).

   
   

4. start_exp.bat: a file containing a single command: start rasmanesc.exe, which further increases the likelihood of the user executing the primary malicious file.

The execution flow and capabilities of rasmanesc.exe

Webrat is a backdoor that allows the attackers to control the infected system. Furthermore, it can steal data from cryptocurrency wallets, Telegram, Discord and Steam accounts, while also performing spyware functions such as screen recording, surveillance via a webcam and microphone, and keylogging. The version of Webrat discovered in this campaign is no different from those documented previously.

Campaign objectives

Previously, Webrat spread alongside game cheats, software cracks, and patches for legitimate applications. In this campaign, however, the Trojan disguises itself as exploits and PoCs. This suggests that the threat actor is attempting to infect information security specialists and other users interested in this topic. It bears mentioning that any competent security professional analyzes exploits and other malware within a controlled, isolated environment, which has no access to sensitive data, physical webcams, or microphones. Furthermore, an experienced researcher would easily recognize Webrat, as it’s well-documented and the current version is no different from previous ones. Therefore, we believe the bait is aimed at students and inexperienced security professionals.

Conclusion

The threat actor behind Webrat is now disguising the backdoor not only as game cheats and cracked software, but also as exploits and PoCs. This indicates they are targeting researchers who frequently rely on open sources to find and analyze code related to new vulnerabilities.

However, Webrat itself has not changed significantly from past campaigns. These attacks clearly target users who would run the “exploit” directly on their machines — bypassing basic safety protocols. This serves as a reminder that cybersecurity professionals, especially inexperienced researchers and students, must remain vigilant when handling exploits and any potentially malicious files. To prevent potential damage to work and personal devices containing sensitive information, we recommend analyzing these exploits and files within isolated environments like virtual machines or sandboxes.

We also recommend exercising general caution when working with code from open sources, always using reliable security solutions, and never adding software to exclusions without a justified reason.

Kaspersky solutions effectively detect this threat with the following verdicts:

• HEUR:Trojan.Python.Agent.gen
• HEUR:Trojan-PSW.Win64.Agent.gen
• HEUR:Trojan-Banker.Win32.Agent.gen
• HEUR:Trojan-PSW.Win32.Coins.gen
• HEUR:Trojan-Downloader.Win32.Agent.gen
• PDM:Trojan.Win32.Generic

Indicators of compromise

Malicious GitHub repositories
https://github[.]com/RedFoxNxploits/CVE-2025-10294-Poc
https://github[.]com/FixingPhantom/CVE-2025-10294
https://github[.]com/h4xnz/CVE-2025-10294-POC
https://github[.]com/usjnx72726w/CVE-2025-59295/tree/main
https://github[.]com/stalker110119/CVE-2025-59230/tree/main
https://github[.]com/moegameka/CVE-2025-59230
https://github[.]com/DebugFrag/CVE-2025-12596-Exploit
https://github[.]com/themaxlpalfaboy/CVE-2025-54897-LAB
https://github[.]com/DExplo1ted/CVE-2025-54106-POC
https://github[.]com/h4xnz/CVE-2025-55234-POC
https://github[.]com/Hazelooks/CVE-2025-11499-Exploit
https://github[.]com/usjnx72726w/CVE-2025-11499-LAB
https://github[.]com/modhopmarrow1973/CVE-2025-11833-LAB
https://github[.]com/rootreapers/CVE-2025-11499
https://github[.]com/lagerhaker539/CVE-2025-12595-POC

Webrat C2
http://ezc5510min[.]temp[.]swtest[.]ru
http://shopsleta[.]ru

MD5
28a741e9fcd57bd607255d3a4690c82f
a13c3d863e8e2bd7596bac5d41581f6a
61b1fc6ab327e6d3ff5fd3e82b430315

securelist.com/webrat-distribu…

[Alireza Alavi] wanted to use an e-ink tablet as a Linux monitor. Why? We don’t need to ask. You can see the result of connecting an Onyx BOOX Air 2 to an Arch Linux box in the video below.

Like all good projects, this one had a false start. Deskreen sounds good, as it is an easy way to stream your desktop to a browser. The problem is, it isn’t very crisp, and it can be laggy, according to the post. Of course, VNC is a tried-and-true solution. The Onyx uses Android, so there were plenty of VNC clients, and Linux, of course, has many VNC servers.

Putting everything together as a script lets [Alireza] use the ebook as a second monitor. Using it as a main monitor would be difficult, and [Alireza] reports using the two monitors to mirror each other, so you can glance over at the regular screen for a color image, for example.

Another benefit of the mirrored screens is that VNC lets you use the tablet’s screen as an input device, which is handy if you are drawing in GIMP or performing similar tasks.

We sometimes use VNC on Android just to get to a fake Linux install running on the device.

youtube.com/embed/TeOg7Of8ZU4?…

hackaday.com/2025/12/23/using-…

Nella puntata precedente (La psicologia delle password. Non proteggono i sistemi: raccontano le persone), abbiamo parlato di come le password, oltre a proteggere i sistemi, finiscano per raccontare le persone.

Questa volta facciamo un passo in più: proviamo a capire perché ci affezioniamo proprio a quelle peggiori e perché cambiarle produce spesso l’effetto opposto a quello desiderato.

Paris…

Il punto di partenza è un episodio di cronaca: all’interno di una combolist circolata in ambienti criminali è comparsa una coppia di credenziali che associava un indirizzo istituzionale del Louvre a una password sorprendentemente coerente con il contesto: paris – e le sue inevitabili reincarnazioni.

Partiamo dalla fine: la combo è stravecchia e la password è stata cambiata da anni.

Il riflesso mentale che l’ha prodotta, purtroppo, no.

Ed è proprio quel riflesso che vale la pena osservare.

Paris – e ciò che puntualmente le cresce intorno – non nasce da distrazione né da superficialità.

Nasce perché ha senso. Il Louvre è a Parigi, l’account riguarda il Louvre, e il cervello umano fa ciò che sa fare meglio quando lo sforzo richiesto è minimo: prende il contesto e lo trasforma in soluzione. Non cerca sicurezza, ma coerenza.

La password smette di essere una chiave e diventa qualcosa che “torna”, che non disturba, che non richiede memoria né attrito.

È qui che l’aneddoto smette di essere cronaca e diventa psicologia. Una password costruita così non viene percepita come debole, ma come nostra. L’abbiamo assemblata partendo da ciò che conosciamo, e questo basta a renderla affidabile ai nostri occhi.

È l’Effetto IKEA applicato alla sicurezza: tendiamo a dare più valore a ciò che abbiamo costruito noi, anche quando è fragile.

Il problema emerge nel momento successivo, quando entra in scena il rito del Cambia Password. Se quella parola non è solo una stringa ma un piccolo equilibrio mentale, cambiarla non è un’operazione tecnica. È una rinuncia.

E la mente, davanti a una perdita, non reagisce creando qualcosa di nuovo: reagisce cercando continuità. La forma resta, cambiano i dettagli. Le varianti si moltiplicano, la sicurezza molto meno.

Il sistema chiede complessità. La mente risponde con riconoscibilità.

L’Effetto IKEA (perché difendiamo le password peggiori)

C’è un motivo se una password come paris resiste più a lungo di quanto dovrebbe.
Non è tecnico. È affettivo.

In psicologia si chiama Effetto IKEA: tendiamo a dare più valore agli oggetti che abbiamo costruito noi, anche quando sono fragili, storti o palesemente migliorabili. Non perché siano migliori, ma perché raccontano il tempo e il ragionamento che ci abbiamo messo dentro.

Montare un mobile traballante e difenderlo con orgoglio è un comportamento perfettamente umano. Fare lo stesso con una password lo è ancora di più.

Una password costruita a partire dal contesto – un luogo, un ruolo, un’associazione evidente – non viene vissuta come una scelta debole. Viene vissuta come una scelta “pensata”. L’abbiamo fatta noi, ha un senso, la riconosciamo al volo. E questo basta a farla sembrare affidabile, anche quando non lo è.

Il paradosso è che l’Effetto IKEA funziona meglio proprio dove dovrebbe fallire. Più una password è semplice, leggibile, coerente, più diventa familiare. E più diventa familiare, più facciamo fatica a metterla in discussione.

Non la valutiamo come una chiave. La trattiamo come un oggetto personale.

E quando un sistema ci suggerisce di sostituirle, la reazione istintiva non è migliorare, ma conservare: tenere la forma, aggiustare i bordi, cambiare il minimo indispensabile per poter dire di aver obbedito.

L’Effetto IKEA non ci rende ingenui. Ci rende coerenti con noi stessi.

Ed è proprio questa coerenza, così utile nella vita quotidiana, che nel digitale diventa prevedibile.

Un esempio minimo

Pensiamo a un mobile IKEA.

Lo monti la sera, quando tutti ti guardano. Segui le istruzioni, più o meno. A un certo punto manca una vite. Oppure ce n’è una di troppo, che resta lì sul tavolo a fissarti.

Il mobile alla fine sta in piedi. Un po’ storto. Un’anta non chiude perfettamente.

La famiglia lo guarda in silenzio.
Qualcuno chiede: “È normale?”

E a quel punto difenderlo diventa inevitabile.

Con le password succede la stessa cosa.

Una password costruita a partire dal contesto nasce spesso così: qualcosa manca, qualcosa avanza, ma “funziona”. Non è elegante, non è robusta, ma è nostra. Ci abbiamo messo le mani, il tempo, il ragionamento minimo necessario per farla stare in piedi.

Ed è questo l’Effetto IKEA applicato alla sicurezza: non diamo valore a una password perché è solida, ma perché l’abbiamo assemblata noi, anche se traballa.

E quando qualcuno ci dice che va cambiata, la prima reazione non è rifarla. È difenderla. O, al massimo, stringere meglio una vite.

Cambia Password (il rito che promette ordine)

A questo punto entra in scena il rito.
Quello che tutti conoscono e nessuno ama: Cambia Password.

Arriva puntuale, come una circolare aziendale o una notifica che non puoi ignorare. Non chiede se la password sia stata compromessa. Non chiede se ci sia stato un problema. Chiede solo di cambiarla. Perché è scaduta. Perché lo dice la policy. Perché si fa così.

E non chiede una password qualsiasi.

• La vuole lunga.
• Con numeri.
• Con simboli.
• Con maiuscole.

Non quelli che vuoi tu, quelli giusti.
E possibilmente abbastanza diversa dalle ultime.

A quel punto la password smette definitivamente di essere una chiave e diventa un oggetto da ricordare. Un peso cognitivo.

Ed è qui che scatta il vero ragionamento, quello che nessuna policy contempla:
“Se devo ricordarmela, allora tanto vale usarla per tutto.”

• Social.
• App.
• Account secondari.
• Il supermercato.

Qualsiasi cosa non sembri vitale in quel momento.

Non lo facciamo per incoscienza, ma per economia.

La password diventa un investimento. Se è complessa, la ammortizzo. Se mi costa memoria, la riuso. E così quella stessa stringa comincia a girare, a depositarsi, a comparire dove non dovrebbe.

Prima o poi finisce in una combolist. Non perché qualcuno abbia colpito il sistema giusto, ma perché l’ho portata io in giro abbastanza a lungo.

E infatti la nostra amata paris…

A quel punto non c’è rito che tenga.
Non è più una password.
È un souvenir digitale.

Il sistema crede di aver introdotto complessità.
La mente ha introdotto superficie di attacco.

E quando un design confonde la fatica con la sicurezza, il risultato non è protezione.
È solo un’altra vite stretta sullo stesso mobile storto.

Prossima puntata

Nella prossima puntata faremo un altro passo avanti.
Lasceremo perdere per un momento le password e guarderemo il problema dal punto di vista del design.

Perché c’è un’idea sbagliata, molto diffusa, secondo cui la sicurezza dovrebbe essere comoda, fluida, invisibile.
E invece funziona quasi sempre al contrario.

Parleremo di attrito, di sistemi che si fanno sentire, di autenticazioni che “rompono le palle” – francesismo improprio, ma dopo paris ce lo possiamo concedere – perché stanno facendo il loro lavoro.

Se finora il problema sembrava l’utente, la prossima volta toccherà chiedersi se non sia il progetto ad aver sbagliato bersaglio.

Parleremo anche di come si può ridurre il peso cognitivo senza abbassare la sicurezza: usando passphrase e costruendo password che funzionano davvero per chi le deve usare.

Continua…

L'articolo La mente e le password: l’Effetto “Louvre” spiegato con una password pessima proviene da Red Hot Cyber.

L’analisi che segue esamina il vettore di attacco relativo alla CVE-2025-47761, una vulnerabilità individuata nel driver kernel Fortips_74.sys utilizzato da FortiClient VPN per Windows. Il cuore della problematica risiede in una IOCTL mal gestita che permette a processi user-mode non privilegiati di interagire con il kernel, abilitando una primitiva di scrittura arbitraria di 4 byte.

La falla è stata individuata il 31 gennaio 2025 da Alex Ghiotto, membro della community di Hackerhood. Sebbene la patch correttiva sia stata integrata già a settembre 2025 con il rilascio della versione 7.4.4,

Fortinet ha formalizzato la vulnerabilità solo il 18 novembre 2025 con la pubblicazione del bollettino ufficiale FG-IR-25-112.

Questo caso studio risulta particolarmente interessante per valutare l’efficacia delle moderne mitigazioni di sistema: l’exploit si basa infatti sul reperimento dell’indirizzo kernel del token di processo, un’operazione resa complessa a partire da Windows 11 24H2. In quest’ultima versione, l’accesso a tali informazioni tramite NtQuerySystemInformation richiede ora il privilegio SeDebugPrivilege, innalzando significativamente i requisiti necessari per un attacco efficace da parte di utenti non amministratori.

Analisi Tecnica della CVE-2025-47761

Fortips_74.sys è un driver kernel utilizzato da alcune soluzioni Fortinet, tra cui FortiClientVPN. Nel corso dell’analisi del driver è emersa una vulnerabilità successivamente identificata e corretta come CVE‑2025‑47761. L’obiettivo di questo articolo è descrivere il processo di analisi che ha portato alla sua individuazione e comprenderne le principali implicazioni di sicurezza. La vulnerabilità consente una scrittura arbitraria di 4 byte in un indirizzo controllato dall’utente. Questo comportamento può causare un crash del sistema oppure essere sfruttato per ottenere una completa escalation dei privilegi.

Interagire col Driver

Quando si analizza un driver alla ricerca di una potenziale escalation dei privilegi, la prima domanda fondamentale è: chi può interagirci?
Se anche utenti non privilegiati possono aprire un handle, allora vale la pena approfondire.
In questo caso, il primo passo è osservare chi può interagire con Fortips_74.sys.

Usando WinObj, si nota immediatamente che il driver non imposta permessi restrittivi: questo attira subito l’attenzione.
Una vista più tecnica delle DACL è possibile dal kernel tramite WinDBG

Il driver Fortips_74 crea infatti un device kernel senza definire DACL personalizzate, affidandosi al security descriptor di default. In pratica, qualunque processo nel sistema può aprire un handle verso il driver, compresi quelli a basso livello di integrità (come i processi sandboxati dei browser).
(Su quest’ultimo punto ammetto di non aver effettuato un controllo formale per conferma.)
Analizzando le DACL, risulta che SYSTEM e gli amministratori abbiano accesso completo, ma anche gli altri utenti possono comunque comunicare con il driver, seppur con permessi limitati.
Questo comportamento rende il driver troppo socievole: chiunque può comunicare tramite IOCTL, e in assenza di controlli adeguati il dispatch deve essere gestito in modo estremamente rigoroso per evitare vulnerabilità.

Dispatch delle IOCTL

Prima di entrare nei dettagli specifici del driver Fortips, è utile un breve ripasso.

Le IOCTL (Input/Output Control) permettono ai processi user-mode di inviare comandi specifici ai driver.
In Windows, la funzione DeviceIoControl consente di:

• passare un handle al device
• specificare un codice IOCTL
• fornire buffer di input/output

In sostanza, è il modo per dire:
“Esegui questa operazione con questi dati.”
Analizzando le IOCTL del driver, una in particolare risulta sospetta: 0x12C803.

Questa IOCTL utilizza METHOD_NEITHER, il più pericoloso tra i metodi previsti da Windows: il kernel passa puntatori user‑mode direttamente al driver senza alcuna validazione.
È quindi responsabilità totale del driver verificare:

• validità del puntatore
• accessibilità
• dimensione prevista

Se queste verifiche mancano, l’attaccante può passare puntatori arbitrari, inducendo il driver a leggere/scrivere memoria a cui non dovrebbe accedere.
Tramite questo tool è possibile confermare che il driver utilizza direttamente la IOCTL di tipo METHOD_NEITHER.

Il driver utilizza direttamente il UserBuffer fornito dal chiamante per scrivere l’output, senza alcuna copia o validazione preventiva. Questo significa che un processo user‑mode può passare un puntatore arbitrario, che il driver userà come destinazione dei dati. Senza controlli adeguati, basta un indirizzo malizioso per trasformare un semplice output in una scrittura arbitraria in kernel‑mode, con ovvie implicazioni di sicurezza.

Analisi della funzione vulnerabile

Seguendo il flusso del buffer, la funzione copia il contenuto del buffer user-mode in un buffer locale sullo stack. I primi 24 byte (0x18) vengono interpretati come:

• ULONGLONG Code
• ULONGLONG Size
• ULONGLONG Buffer

Il campo Size non è rilevante in questa catena, mentre Code e Buffer sì.

Per raggiungere il ramo vulnerabile, Code deve essere 0x63.

Dopo la copia preliminare in un buffer locale, il driver salta nella condizione interessata.
A questo punto, uVar7 viene impostato a 4.

Qui si trova il cuore della vulnerabilità:
il driver copia 4 byte da un buffer non inizializzato all’indirizzo specificato dall’utente tramite la IOCTL.
Non vi è alcun controllo o sanitizzazione.
Poiché la sorgente dei dati è stack-junk, la vulnerabilità si traduce in una arbitrary 4-byte write.
Specificando ad esempio l’indirizzo kernel della struttura _TOKEN, è possibile ottenere una privilege escalation.
Nel mio PoC, ho modificato il token per abilitare il privilegio SeDebugPrivilege, quindi ho avviato un cmd come SYSTEM.

Avvio del driver

Per ridurre l’interazione necessaria da parte dell’utente, ho analizzato il meccanismo con cui FortiClient avvia il servizio IPSec.
Il processo principale utilizza una Named Pipe per gestire la comunicazione IPC, inviando un buffer alla pipe
\\Device\\NamedPipe\\FC_{6DA09263-AA93-452B-95F3-B7CEC078EB30}.
All’interno del buffer sono presenti diversi campi, tra cui il nome del tunnel IPSec da inizializzare.Questa chiamata risulta sufficiente ad avviare il driver, anche senza privilegi amministrativi, condizione essenziale per la vulnerabilità.
Nella versione FortiClient VPN 7.4.3.1790 è inoltre possibile creare un profilo IPSec completamente fittizio, utilizzando parametri arbitrari. Nel mio caso, per la fase di test, ho impostato un gateway remoto come “google.it”, un comportamento diverso da quanto indicato da Fortinet nel bollettino ufficiale della CVE.

Proof of Concept

Video Player

Restrizioni

Come già accennato, lo sfruttamento di questa vulnerabilità si basa sulla possibilità di ottenere l’indirizzo kernel del token associato al processo, così da poterne manipolare i privilegi. A partire da Windows 11 24H2 questo non è più possibile da un processo con Integrity Level medio tramite la tradizionale chiamata NtQuerySystemInformation, poiché ora per accedere a tali informazioni è richiesto il privilegio SeDebugPrivilege, normalmente non disponibile agli utenti non amministratori.
Nel mio proof-of-concept ho sfruttato la vulnerabilità [url=https://www.redhotcyber.com/en/cve-details/?cve_id=CVE-2025-53136]CVE-2025-53136[/url], che tramite una race condition consente di ottenere il leak dell’indirizzo del _TOKEN. In questo modo il PoC rimane funzionante fino alla correzione della vulnerabilità prevista per gli aggiornamenti di agosto/settembre 2025.
Al di fuori di questo caso specifico, per sfruttare la vulnerabilità su un sistema completamente aggiornato sarebbe necessario disporre di un ulteriore bug in grado di fornire il leak dell’indirizzo richiesto, poiché le protezioni introdotte nel nuovo kernel impediscono di ottenerlo direttamente.

Timeline

• 31-01-2025: Vulnerabilità segnalata al PSIRT di Fortinet.
• 19-02-2025: Vulnerabilità confermata dal PSIRT di Fortinet.
• 09-05-2025: Fortinet dichiara di aver risolto il problema assegnando CVE-2025-47761.
• 18-11-2025: Fortinet pubblica sul PSIRT il bollettino riguardante la CVE.

L'articolo HackerHood di RHC scopre una privilege escalation in FortiClient VPN proviene da Red Hot Cyber.

Recently, [Edward Schmitz] wrote in to let us know about his Hackaday.io project: SigCore UC: An Open-Source Universal I/O Controller With Relays, Analog I/O, and Modbus for the Raspberry Pi.

In the video embedded below, [Edward] runs us through some of the features which he explains are a complete industrial control and data collection system. Features include Ethernet, WiFi, and Modbus TCP connectivity, regulated 5 V bus, eight relays, eight digital inputs, four analog inputs, and four analog outputs. All packaged in rugged housing and ready for installation/deployment.

[Edward] says he wanted something which went beyond development boards and expansion modules that provided a complete and ready-to-deploy solution. If you’re interested in the hardware, firmware, or software, everything is available on the project’s GitHub page. Beyond the Hackaday.io article, the GitHub repo, the YouTube explainer video, there is even an entire website devoted to the project: sigcoreuc.com. Our hats off to [Edward], he really put a lot of polish on this project.

If you’re interested in using the Raspberry Pi for input/output you might also like to read about Raspberry Pi Pico Makes For Expeditious Input Device and Smart Power Strip Revived With Raspberry Pi.

youtube.com/embed/jJMRukokuP8?…

hackaday.com/2025/12/22/sigcor…

Un uomo ucraino coinvolto in una serie di attacchi ransomware è stato riconosciuto colpevole negli Stati Uniti. Questi crimini informatici hanno colpito aziende di diversi paesi, tra cui Stati Uniti, Canada e Australia. I danni causati dalle azioni degli aggressori ammontano a milioni di dollari.

Artem Aleksandrovych Stryzhak, cittadino ucraino di 35 anni, è stato arrestato a Barcellona nel 2024 ed estradato negli Stati Uniti in primavera. Si è dichiarato colpevole di associazione a delinquere finalizzata alla frode informatica. Il suo processo si sta svolgendo nel distretto orientale di New York, dove la sentenza è stata fissata per maggio 2026. Strizhak rischia fino a dieci anni di carcere.

Secondo l’accusa, Strizhak si è unito all’organizzazione criminale informatica a metà del 2021. Ha quindi ottenuto l’accesso al malware noto come Nefilim e ha accettato di cedere ai suoi sviluppatori una parte del riscatto. Il gruppo ha preso di mira grandi aziende con un fatturato annuo superiore a 100 milioni di dollari. Le loro azioni hanno causato non solo perdite finanziarie dirette, ma anche danni significativi alle infrastrutture delle organizzazioni colpite.

Tra le vittime figuravano aziende operanti nei settori dell’aviazione, dell’ingegneria, della chimica, delle assicurazioni, dell’energia e di altri settori. Gli operatori di Nefilim operavano non solo in Nord America, ma anche all’estero, ricorrendo a un duplice metodo di estorsione : prima bloccando l’accesso ai sistemi e poi minacciando di divulgare i dati rubati.

L’indagine è in corso e il Dipartimento di Giustizia degli Stati Uniti rimane interessato agli altri membri del gruppo. Particolare attenzione è rivolta a Volodymyr Tymoshchuk, che l’accusa identifica come uno degli organizzatori del piano criminale. Una ricompensa di 11 milioni di dollari è ancora in palio per informazioni che portino alla sua posizione.

Secondo il fascicolo, Tymoshchuk non solo supervisionava le attività di Nefilim, ma era anche associato ad altri programmi ransomware, come LockerGoga e MegaCortex.

Dalla fine del 2018 all’autunno del 2021, sarebbe stato responsabile di attacchi a centinaia di organizzazioni negli Stati Uniti e in Europa. Il Dipartimento di Giustizia degli Stati Uniti stima che il danno totale subito superi le decine di milioni di dollari. Tra gli incidenti più noti c’è stato l’attacco alla società norvegese Norsk Hydro nel 2019.

L'articolo Quando il cybercrime cade: Uomo ucraino colpevole di attacchi ransomware negli USA proviene da Red Hot Cyber.

Come sempre riportiamo su queste pagine, le nazioni stanno spingendo alla realizzazione di dispositivi software ed hardware domestici, ovvero tecnologie realizzate all’interno della nazione più facilmente controllabili dal punto di vista della sicurezza nazionale.

Se di per se possano sembrare delle ottime iniziative a livello economico e nazionale, portano con se gravi rischi per il futuro di internet e della “globalizzazione”.

Il fatto di erigere “Muri Digitali”, evitando tecnologie condivise, crea divisioni digitali che isolano le nazioni, limitando la collaborazione e lo scambio tecnologico su scala globale (scopri di più nell’articolo di Massimiliano Brolli).

Questo approccio, pur garantendo un maggiore controllo sulla sicurezza interna, rischia di frammentare il panorama tecnologico, ostacolando l’innovazione e aggravando le tensioni geopolitiche. La corsa alla sovranità digitale “può portare a un mondo in cui ogni nazione costruisce i propri muri tecnologici, generando conflitti e disuguaglianze nel lungo termine”.

Il Roskomnadzor della federazione Russa ha affermato che WhatsApp continua a violare la legge russa e, pertanto, impone costantemente misure restrittive nei confronti dell’app di messaggistica.

Il Roskomnadzor sostiene che WhatsApp venga utilizzata per organizzare e compiere attacchi terroristici nel Paese, reclutare terroristi e commettere frodi e altri reati contro i cittadini.

L’autorità di regolamentazione ha chiarito che le restrizioni verranno introdotte gradualmente per consentire agli utenti di passare ad app di messaggistica alternative e ha raccomandato di passare ai servizi nazionali.

Il Roskomnadzor ha inoltre sottolineato che le restrizioni su WhatsApp continueranno e che, se non verrà rispettata la legge russa, il servizio di messaggistica potrebbe essere completamente bloccato.

Nelle prime ore del mattino del 22 dicembre, gli utenti in Russia si sono lamentati in massa di WhatsApp. Secondo il servizio di monitoraggio SBOY.RF, nelle ultime 24 ore sono state registrate 1.283 segnalazioni e un grafico degli ultimi 14 giorni ha mostrato un forte aumento delle segnalazioni alla fine del periodo.

Il maggior numero di segnalazioni di indisponibilità ed errori di connessione è arrivato da Mosca, seguita da San Pietroburgo e dalla regione di Mosca.

Secondo il feedback degli utenti, alcuni utenti non sono riusciti a inviare messaggi e la versione web e l’app desktop non sono riuscite a connettersi. Tuttavia, la versione mobile ha continuato a funzionare per alcuni, a volte solo tramite VPN .

L'articolo Muri Digitali. Quando la sicurezza diventa isolamento: il caso WhatsApp in Russia proviene da Red Hot Cyber.

Una vulnerabilità critica è stata individuata in MongoDB, tra le piattaforme di database NoSQL più utilizzate a livello globale.

Questa falla di sicurezza, monitorata con il codice CVE-2025-14847, permette agli aggressori di estrarre dati sensibili dalla memoria del server senza necessità di effettuare l’accesso.

La vulnerabilità ha una portata enorme e colpisce quasi tutte le versioni supportate (e non supportate) di MongoDB Server degli ultimi anni. L’avviso elenca impatti che vanno dalla moderna serie 8.2 fino alla versione 3.6.

Questo problema riguarda le versioni di seguito elencate:

• MongoDB dalla versione 8.2.0 alla 8.2.3
• MongoDB dalla versione 8.0.0 alla 8.0.16
• MongoDB dalla versione 7.0.0 alla 7.0.26
• MongoDB dalla versione 6.0.0 alla 6.0.26
• MongoDB dalla versione 5.0.0 alla 5.0.31
• MongoDB dalla versione 4.4.0 alla 4.4.29
• Tutte le versioni di MongoDB Server v4.2
• Tutte le versioni di MongoDB Server v4.0
• Tutte le versioni di MongoDB Server v3.6

La debolezza è legata alla gestione della compressione dei dati da parte del server MongoDB, in particolare all’implementazione della libreria zlib. Come indicato nell’avviso, un exploit sul lato client della implementazione zlib del server può causare il rilascio di memoria heap priva di inizializzazione.

La vulnerabilità, con un punteggio CVSSv4 di 8,7, viene classificata come di “Gravità elevata”, costituendo un rischio considerevole per le distribuzioni non aggiornate, in particolare poiché non richiede autenticazione per essere sfruttata.

In termini di sicurezza informatica, questo bug viene spesso definito “memory leak” o “information disclosure”. Inviando una richiesta appositamente predisposta, un client malintenzionato può ingannare il server inducendolo a rispondere con blocchi di dati dalla sua memoria interna (heap).

Fondamentalmente, il rapporto sottolinea che questo può essere ottenuto “senza autenticarsi al server”. Ciò significa che un aggressore non ha bisogno di un nome utente o di una password; gli basta l’accesso di rete alla porta del database per raccogliere potenzialmente frammenti di dati sensibili, che potrebbero includere qualsiasi cosa, dalle query recenti alle credenziali memorizzate nella cache, residenti nella RAM del server.

I responsabili della manutenzione hanno rilasciato versioni corrette e prive del bug in questione che sono le seguenti:

• 8.2.3
• 8.0.17
• 7.0.28
• 6.0.27
• 5.0.32
• 4.4.30

Esistono soluzioni temporanee per team che non possono interrompere i propri database per un aggiornamento immediato. Un’opzione possibile è disabilitare completamente la compressione zlib, come suggerito dall’avviso, ad esempio avviando mongod o mongos con un’opzione net.compression.compressors che esplicitamente omette zlib.

Tra le alternative sicure per la compressione figurano “snappy” o “zstd“. Un’altra opzione potrebbe essere quella di eseguire il processo con la compressione disabilitata, in attesa di poter applicare la patch.

L'articolo MongoDB colpito da una falla critica: dati esfiltrabili senza autenticazione proviene da Red Hot Cyber.

Il procuratore generale del Texas Ken Paxton ha accusato cinque importanti produttori di televisori di aver raccolto illegalmente dati degli utenti utilizzando la tecnologia di riconoscimento automatico dei contenuti (ACR) per registrare ciò che i proprietari guardano.

Le accuse riguardano Sony , Samsung e LG nonché i produttori cinesi Hisense e TCL Technology Group Corporation.

L’ufficio del Procuratore Generale ha specificamente sottolineato le “serie preoccupazioni” circa le aziende cinesi, tenute a rispettare la legge cinese sulla sicurezza nazionale, consentendo potenzialmente al governo cinese di accedere ai dati degli utenti americani.

Secondo le cause legali intentate presso i tribunali del Texas, i produttori di TV utilizzano la tecnologia ACR per acquisire screenshot ogni 500 millisecondi. Questa tecnologia traccia l’attività degli utenti in tempo reale e trasmette le informazioni raccolte ai server delle aziende (all’insaputa o senza il consenso dei proprietari dei dispositivi). Le informazioni raccolte vengono poi vendute alle aziende che pagano di più per la pubblicità mirata.

“Le aziende, soprattutto quelle legate al Partito Comunista Cinese, non hanno il diritto di registrare illegalmente i dispositivi degli americani all’interno delle loro case”, ha affermato Paxton. “Tali azioni costituiscono un’invasione della privacy, sono ingannevoli e illegali. Il diritto fondamentale alla privacy sarà tutelato in Texas, perché possedere un televisore non significa cedere informazioni personali a giganti della tecnologia o avversari stranieri”.

Vale la pena notare che questa non è la prima volta che i produttori di smart TV vengono accusati di spiare gli utenti.

Ad esempio, nel 2017, il produttore di TV Vizio (di proprietà di Walmart) ha pagato 2,2 milioni di dollari per chiudere le accuse mosse dalla Federal Trade Commission statunitense e dall’ufficio del Procuratore Generale del New Jersey.

È stato poi rivelato che Vizio aveva raccolto dati di visualizzazione da 11 milioni di dispositivi all’insaputa o senza il consenso dei proprietari attraverso la sua funzione Smart Interactivity. Da febbraio 2014, Vizio e un’azienda correlata avevano lanciato sul mercato delle “smart TV” (e aggiornato da remoto i modelli più vecchi con il software necessario) che registravano informazioni dettagliate sui contenuti visualizzati.

I dati raccolti sono stati collegati a informazioni demografiche quali sesso, età, reddito e istruzione degli utenti e poi venduti a terze parti per mostrare pubblicità mirate.

Inoltre, nel 2024, un gruppo di ricercatori aveva già accusato i produttori di smart TV (tra cui Samsung e LG) di utilizzare la suddetta tecnologia di riconoscimento automatico dei contenuti (ACR), simile a Shazam.

Secondo un rapporto preparato da ricercatori dell’University College di Londra, dell’Università della California, Davis e dell’Università Carlos III di Madrid, il sistema di tracciamento funziona anche quando i televisori vengono utilizzati come display esterni, ovvero quando sono collegati ad altri dispositivi tramite HDMI. In questo modo, ACR può intercettare i contenuti provenienti da console di gioco o laptop collegati al televisore.

L'articolo Smart TV sotto accusa: “Vi guardano mentre guardate”. La Privacy è a rischio! proviene da Red Hot Cyber.

I ricercatori di Check Point, pioniere e leader globale nelle soluzioni di sicurezza informatica, hanno scoperto una campagna di phishing in cui gli attaccanti si fingono servizi di condivisione file e firma elettronica per inviare esche a tema finanziario camuffate da notifiche legittime.

Il mondo iperconnesso ha reso più facile che mai per aziende e consumatori scambiarsi documenti, approvare transazioni e completare flussi di lavoro finanziari critici con un semplice clic. Le piattaforme di condivisione di file digitali e di firma elettronica, ampiamente utilizzate nel settore bancario, immobiliare, assicurativo e nelle operazioni commerciali quotidiane, sono diventate essenziali per il funzionamento veloce delle organizzazioni moderne. Questa comodità crea anche un’opportunità per i criminali informatici.

In questa campagna, i dati della telemetria Harmony Email di Check Point mostrano che nelle ultime settimane sono state inviate oltre 40.000 e-mail di phishing che hanno preso di mira circa 6.100 aziende.

Tutti i link malevoli sono stati convogliati attraverso l’indirizzo https://url.za.m.mimecastprotect.com/feed, aumentando la fiducia degli utenti grazie alla riproduzione di flussi di reindirizzamento a loro familiari.

Abuso della funzione di riscrittura dei link sicuri di Mimecast,

Poiché Mimecast Protect è un dominio affidabile, questa tecnica aiuta gli URL malevoli a eludere sia i filtri automatici che i sospetti degli utenti. Per aumentare la credibilità, le e-mail copiavano le immagini ufficiali del servizio (loghi dei prodotti Microsoft e Office), utilizzavano intestazioni, scritte a piè di pagina e pulsanti “Rivedi documento” in stile servizio e nomi visualizzati contraffatti come “X tramite SharePoint (Online)”, “eSignDoc tramite Y” e “SharePoint“, che ricalcavano in modo fedele i modelli di notifica autentici.
Immagine 1: esempio di e-mail di phishing
Oltre alla grande campagna SharePoint/e-signing, i ricercatori hanno identificato anche un’operazione più piccola ma correlata, che imita le notifiche DocuSign. Come l’attacco principale, questa impersona una piattaforma SaaS affidabile e sfrutta un’infrastruttura di reindirizzamento legittima, ma la tecnica utilizzata per mascherare la destinazione malevola è significativamente diversa.

Nella campagna principale, il reindirizzamento secondario agisce come un reindirizzamento aperto, lasciando visibile l’URL di phishing finale nella stringa di query nonostante sia racchiuso in servizi affidabili. Nella variante a tema DocuSign, il link passa attraverso un URL Bitdefender GravityZone e poi attraverso il servizio di tracciamento dei clic di Intercom, con la vera pagina didestinazione completamente nascosta dietro un reindirizzamento tokenizzato. Questo approccio nasconde completamente l’URL finale, rendendo la variante DocuSign ancora più elusiva e difficile da rilevare.
Immagine 2: Esempio di e-mail di phishing dalla variante in stile DocuSign
La campagna ha preso di mira principalmente organizzazioni negli Stati Uniti (34.057), in Europa (4.525), in Canada (767), in Asia (346), in Australia (267) e in Medio Oriente (256), concentrandosi in particolare sui settori della consulenza, della tecnologia e dell’edilizia/immobiliare, con ulteriori vittime nei settori sanitario, finanziario, manifatturiero, dei media e del marketing, dei trasporti e della logistica, dell’energia, dell’istruzione, della vendita al dettaglio, dell’ospitalità e dei viaggi e della pubblica amministrazione. Questi settori sono obiettivi appetibili perché scambiano regolarmente contratti, fatture e altri documenti transazionali, rendendo la condivisione di file e l’usurpazione di identità tramite firme elettroniche molto convincenti e con maggiori probabilità di successo.

Perché è importante

Si è già scritto di campagne di phishing simili negli anni passati, ma ciò che rende unico questo attacco è che mostra quanto sia facile per gli aggressori imitare servizi di condivisione di file affidabili per ingannare gli utenti, e sottolinea la necessità di una consapevolezza continua, soprattutto quando le e-mail contengono link cliccabili, dettagli sospetti sul mittente o contenuti insoliti nel corpo del messaggio.

Cosa dovrebbero fare le organizzazioni

Anche le organizzazioni e gli individui devono adottare misure proattive per ridurre il rischio. Alcuni modi per proteggersi includono:

1. Approcciare sempre con cautela i link incorporati nelle e-mail, soprattutto quando sembrano inaspettati o urgenti.
2. Prestare molta attenzione ai dettagli delle e-mail, come discrepanze tra il nome visualizzato e l’indirizzo effettivo del mittente, incongruenze nella formattazione, dimensioni dei caratteri insolite, loghi o immagini di bassa qualità e qualsiasi cosa che sembri fuori posto.
3. Passare il mouse sui link prima di cliccarci sopra per verificare la destinazione reale e assicurarsi che corrisponda al servizio che presumibilmente ha inviato il messaggio.
4. Aprire il servizio direttamente nel browser e cercare il documento direttamente, piuttosto che utilizzare i link forniti nelle e-mail.
5. Istruire regolarmente i dipendenti e i team sulle tecniche di phishing emergenti, in modo che comprendano quali sono i modelli sospetti.
6. Utilizzare soluzioni di sicurezza come il rilevamento delle minacce e-mail, i motori anti-phishing, il filtraggio degli URL e gli strumenti di segnalazione degli utenti per rafforzare la protezione complessiva.

La campagna di attacco descritta da Check Point ha sfruttato servizi di reindirizzamento URL legittimi per nascondere link dannosi, non una vulnerabilità di Mimecast. Gli aggressori hanno abusato di infrastrutture affidabili, tra cui il servizio di riscrittura URL di Mimecast, per mascherare la vera destinazione degli URL di phishing. Si tratta di una tattica comune in cui i criminali sfruttano qualsiasi dominio riconosciuto per eludere il rilevamento.

“I clienti Mimecast non sono suscettibili a questo tipo di attacco“, afferma un responsabile di Mimecast. “I motori di rilevamento di Mimecast identificano e bloccano questi attacchi. Le nostre funzionalità di scansione degli URL rilevano e bloccano automaticamente gli URL malevoli prima della consegna, dopodiché, il nostro servizio di riscrittura degli URL ispeziona i link al clic, fornendo un ulteriore livello di protezione che intercetta le minacce anche quando sono nascoste dietro catene di reindirizzamento legittime. Continuiamo a migliorare le nostre protezioni contro le tecniche di phishing in continua evoluzione. I clienti possono consultare la nostra analisi del 2024 su campagne simili al link https://www.mimecast.com/threat-intelligence-hub/phishing-campaigns-using-re-written-links/. Apprezziamo che Check Point abbia condiviso i propri risultati attraverso una divulgazione responsabile“.

L'articolo SharePoint e DocuSign come esca: il phishing che ha provato ad ingannare 6000 aziende proviene da Red Hot Cyber.

For people who build their own model trains there are a range of manufacturers from whom a power bogie containing the motor and drive can be sourced. But as [Le petit train du Berry] shows us in a video, it’s possible to make one yourself and it’s easier than you might think (French language video with truly awful YouTube auto-translation).

At the heart of the design is a coreless motor driving a worm gear at each end that engages with a gear on each axle. The wheelsets and power pickups are off-the-shelf items. The chassis meanwhile is 3D printed, and since this is an ongoing project we see two versions in the video. The V5 model adds a bearing, which its predecessor lacked.

The result is a pretty good power bogie, but it’s not without its faults. The gear ratio used is on the high side in order to save height under a model train body, and in the version without a bearing a hard-wearing filament is required because PLA will wear easily. We’re guessing this isn’t the last we’ll see of this project, so we hope those are addressed in future versions.

We like this project and we think you will too after you’ve watched the video below the break. For more home-made model railway power, how about a linear motor?

youtube.com/embed/X7C90o_rN9Q?…

hackaday.com/2025/12/22/an-ho-…

Few of us complain that hot dogs take too long to cook, because we buy them from a stand. Still, if you do have to make your own dog, it can be a frustrating problem. To solve this issue, [Joel Creates] whipped up a solution to cook hot dogs nearly instantaneously. What’s more, it even fits in your pocket!

The idea behind this build is the same as the classic Presto hot dog cooker—pass electricity through a hot dog frank, and it’ll heat up just like any other resistive heating element. To achieve this, [Joel] hooked up a lithium-polymer pack to a 12-volt to 120-volt inverter. The 120-volt output was hooked up to a frank, but it didn’t really cook much. [Joel] then realized the problem—he needed bigger electrodes conducting electricity into the sausage. With 120 volts pumping through a couple of bolts jammed into either end of the frank, he had it cooked in two minutes flat.

All that was left to do was to get this concept working in a compact, portable package. What ensued was testing with a variety of boost converter circuits to take power from the batteries and stepping it up to a high enough voltage to cook with. That, and solving the issue of nasty chemical byproducts produced from passing electricity through the sausages themselves. Eventually, [Joel] comes up with a working prototype which can electrically cook a hot dog to the point of shooting out violent bursts of steam in under two minutes. You’d still have to be pretty brave to eat something that came out of this thing.

The biggest problem with hot dogs remains that the franks are sold in packs of four while buns are sold in packs of six. Nobody’s solved that problem yet, except for those hateful people who inexplicably have eleven friends. If you solve that one, don’t hesitate to notify the tipsline. Don’t forget, either, that the common hot dog can make for an excellent LED tester. Video after the break.

youtube.com/embed/0-OKW5CsKkU?…

hackaday.com/2025/12/22/high-s…

If you need something clever for a gift, consider this two-part 3D-printed Christmas ornament that has a small secret compartment. But there’s a catch: the print is a challenging one. So make sure your printer is up to the task before you begin (or just mash PRINT and find out).
Want a challenging print that’s also useful? This two-piece ornament has a small gift area inside, and prints without supports.
This design is from [Angus] of [Maker’s Muse] and it’s not just eye-catching, but meticulously designed specifically for 3D printing. In fact, [Angus]’s video (embedded under the page break) is a great round-up of thoughtful design for manufacture (DFM) issues when it comes to filament-based 3D printing.

The ornament prints without supports, which is interesting right off the bat because rounded surfaces (like fillets, or a spherical surface) facing the build plate — even when slightly truncated to provide a flat bottom — are basically very sharp overhangs. That’s a feature that doesn’t generally end up with a good surface finish. [Angus] has a clever solution, and replaces a small section with a flat incline. One can’t tell anything is off by looking at the end result, but it makes all the difference when printing.

There are all kinds of little insights into the specific challenges 3D printing brings, and [Angus] does a fantastic job of highlighting them as he explains his design and addresses the challenges he faced. One spot in particular is the flat area underneath the hang hole. This triangular area is an unsupported bridge, and because of its particular shape, it is trickier to print than normal bridges. The workable solution consists of countersinking a smaller triangle within, but [Angus] is interested in improving this area further and is eager to hear ideas on how to do so. We wonder if he’s tried an approach we covered to get better bridges.

Want to print your own? 3D files are available direct from [Angus]’s site in a pay-what-you-like format. If your 3D printer is up to it, you should be able to make a few before Christmas. But if you’d prefer to set your sights on next year with something that uses power and hardware, this tiny marble machine ornament should raise some eyebrows.

youtube.com/embed/Oyy16lbpe_c?…

hackaday.com/2025/12/22/christ…

[Dennis] of [Made by Dennis] has been building a Voron 0 for fun and education, and since this apparently wasn’t enough of a challenge, decided to add a number of scratch-built improvements and modifications along the way. In his latest video on the journey, he rigorously calibrated the printer’s motion system, including translation distances, the perpendicularity of the axes, and the bed’s position. The goal was to get better than 100-micrometer precision over a 100 mm range, and reaching this required detours into computer vision, clock synchronization, and linear algebra.

To correct for non-perpendicular or distorted axes, [Dennis] calculated a position correction matrix using a camera mounted to the toolhead and a ChArUco board on the print bed. Image recognition software can easily detect the corners of the ChArUco board tiles and identify their positions, and if the camera’s focal length is known, some simple trigonometry gives the camera’s position. By taking pictures at many different points, [Dennis] could calculate a correction matrix which maps the printhead’s reported position to its actual position.

Leveling the bed also took surprisingly deep technical knowledge; [Dennis] was using a PZ probe to detect when the hotend contacted the bed in various places, and had made a wiper to remove interfering plastic from the nozzle, but wasn’t satisfied by the bed’s slight continued motion after making contact (this might have introduced as much as five micrometers of error). To correct for this, he had the microcontroller in the hotend record the time of contact and send this along with the hit signal to the Raspberry Pi controller, which keeps a record of times and positions, letting the true contact position be looked up. This required the hotend’s and the printer’s microcontrollers to have their clocks synchronized to within one microsecond, which the Pi managed using USB start-of-frame packets.

The final result was already looking quite professional, and should only get better once [Dennis] calibrates the extrusion settings. If you’re looking for more about ChArUco boards, we’ve covered them before, as well as calibration models. If you’re looking for high-precision bed leveling, you could also check out this Z sensor.

youtube.com/embed/8DvygwWloCc?…

Thanks to [marble] for the tip!

hackaday.com/2025/12/22/calibr…

American and British patents, for comparison.

There’s an interesting cultural observation to be made as a writer based in Europe, that we like our sans-serif fonts, while our American friends seem to prefer a font with a serif. It’s something that was particularly noticeable in the days of print advertising, and it becomes very obvious when looking at government documents.

We’ve brought together two 1980s patents from the respective sources to illustrate this, the American RSA encryption patent, and the British drive circuitry patent for the Sinclair flat screen CRT. The American one uses Times New Roman, while the British one uses a sans-serif font which we’re guessing may be Arial. The odd thing is in both cases they exude formality and authority to their respective audiences, but Americans see the sans-serif font as less formal and Europeans see the serif version as old-fashioned. If you thought Brits and Americans were divided by a common language, evidently it runs much deeper than that.

But What Makes Text Easier To Read?

Is this legible enough for you?

We’re told that the use of fonts such as Arial or Calibri goes a little deeper than culture or style, in that these sans-serif fonts have greater readability for users with impaired vision or other conditions that impede visual comprehension. If you were wondering where the hack was in this article it’s here, because many of us will have made device interfaces that could have been more legible.

So it’s worth asking the question: just what makes a font legible? Is there more to it than the presence or absence of a serif? In answering that question we’re indebted to the Braille Institute of America for their Atkinson Hyperlegible font, and to Mencap in the Uk for their FS Me accessible font. It becomes clear that these fonts work by subtle design features intended to clearly differentiate letters. For example the uppercase “I”, lowercase letter “l”, and numeral “1” can be almost indistinguishable in some fonts: “Il1”, as can the zero and uppercase “O”, the lowercase letters “g”, and “q”, and even the uppercase “B” and the numeral “8”. The design features to differentiate these letters for accessibility don’t dominate the text and make a font many readers would consider “weird”.

Bitmap Fonts For The Unexpected Win

The typeface used in the Commodore 8-bit machines. User:HarJIT, Public domain.

It’s all very well to look at scaleable fonts for high resolution work, but perhaps of more interest here are bitmap fonts. After all it’s these we’ll be sending to our little screens from our microcontrollers. It’s fair to say that attempts to produce smooth typefaces as bitmaps on machines such as the Amiga produced mixed results, but it’s interesting to look at the “classic” ROM bitmap fonts as found in microcomputers back in the day. After years of their just flowing past he eye it’s particularly so to examine them from an accessibility standpoint.

Machines such as the Sinclair Spectrum or Commodore 64 have evidently had some thought put into differentiating their characters. Their upper-case “Ii” has finials for example, and we’re likely to all be used to the zero with a line through it to differentiate it from the uppercase “O”. Perhaps of them all it’s the IBM PC’s code page 437 that does the job most elegantly, maybe we didn’t realise what we had back in the day.

So we understand that there are cultural preferences for particular design choices such as fonts, and for whatever reason these sometimes come ahead of technical considerations. But it’s been worth a quick look at accessible typography, and who knows, perhaps we can make our projects easier to use as a result. What fonts do you use when legibility matters?

Header: Linotype machines: AE Foster, Public domain.

hackaday.com/2025/12/22/just-w…