What do you look for in a travel keyboard? For me, it has to be split, though this condition most immediately demands a carrying solution of some kind. Wirelessness I can take or leave, so it’s nice to have both options available. And of course, bonus points if it looks so good that people interrupt me to ask questions.

Image by [kleshwong] via YouTubeDepending on your own personal answers to this burning question, the PSKEEB 5 just may be your endgame. And, lucky for you, [kleshwong] plans to open source it soon. All he asks for is your support by watching the video below and doing the usual YouTube-related things.

You’ll see a couple of really neat features, like swing-out tenting feet, a trackpoint, rotary encoders, and the best part of all — a carrying case that doubles as a laptop stand. Sweet!

Eight years in the making, this is the fifth in a series, thus the name: the P stands for Portability; the S for Split. [kleshwong] believes that 36 keys is just right, as long as you have what you need on various layers.

So, do what you can in the like/share/subscribe realm so we can all see the GitHub come to pass, would you? Here’s the spot to watch, and you can enjoy looking through the previous versions while you wait with your forks and stars.

youtube.com/embed/DrDmi9TS-7Q?…

Via reddit

Loongcat40 Has Custom OLED Art

I love me a monoblock split, and I’m speaking to you from one now. They’re split, but you can just toss them across the desk when it’s time to say, eat dinner or carve pink erasers with linoleum tools, and they stay perfectly split and aligned for when you want to pull them back into service.

Image by [Christian Lo] via Hackaday.IOLoongcat40 is like a junior monoblock split, and I dig it visually, but I’d have to try it to see if I find it cramped or not for the long term. And it’s so cute that I just might throw a fork at that GitHub.

In between the halves you’ll find a 2.08″ SH1122 OLED display with lovely artwork by [suh_ga]. Yes, that art is baked into the firmware, free of charge.

Loongcat40 is powered by a Raspi Pico and qualifies as a 40%. The custom case is gasket-mounted and 3D-printed.

[Christian Lo] aka [sporewoh] is no stranger to the DIY keyboard game. You may recognize that name as the builder of some very tiny keyboards, so the Loongcat40 is actually kind of huge by comparison.

Via reddit

The Centerfold: WIP Goes with the Flow

Images by [_dentalt] via redditThis beautiful, as-yet-nameless WIP by [_dentalt] is just captivating to me. It’s amazing what a couple of curves in the right places will do, eh? I love the inspiration for this keyboard. [_dentalt] was at a meetup, and everything was flat and straight except for this one keyboard someone was working on, which was enough for [_dentalt] to give curves a go. There are currently a couple of predicaments at play, so drop by the thread and see if you can help.

Via reddit

Do you rock a sweet set of peripherals on a screamin’ desk pad? Send me a picture along with your handle and all the gory details, and you could be featured here!

Historical Clackers: the Double-Index Pettypet Typewriter

Perhaps the first thing you will notice about the Pettypet after the arresting red color is the matching pair of finger cups. More on this in a minute.
Image via The Antikey Chop
Information is minimal according to The Antikey Chop, and they have collected all that is factual and otherwise about the Pettypet. It debuted in 1930, and was presumably whisked from the world stage the same year.

The Pettypet was invented by someone named Podleci who hailed from Vienna, Austria. Not much else is known about this person. And although the back of the frame is stamped “Patented in all countries — Patents Pending”, the original patent is unknown.

Although it looks like a Bennett, this machine is 25% larger than a Bennett. Those aren’t keycaps, just legends for the two finger cups. You select the character you want, and then press down to print. That cute little red button in the middle is the Spacebar. On the far left, there are two raised Shift buttons, one for capitals and the other for figures.

Somewhat surprisingly, this machine uses a print wheel to apply the type, and a small-looking but otherwise standard two-spool ribbon. There are more cute red buttons on the sides to change the ribbon’s direction. There’s no platen to speak of, just a strip of rubber.

The company name, Pettypet GmbH, and ‘Frankfurt, Germany’ are also stamped into the frame. In addition to this candy-apple red, the Pettypet came in green, blue, and brown. I’d love to see the blue.

Finally, 3D Printed Keyboards That Look Injection-Molded

hackaday.com/wp-content/upload…

Isn’t this lovely? It’s just so smooth! This is a Cygnus printed in PETG and post-processed using only sandpaper and a certain primer filler for car scratches.

About a month ago, [ErgoType] published a guide under another handle. It’s a short guide, and one worth reading. Essentially, [ErgoType], then [FekerFX] sanded it with 400 grit and wiped it down, then applied two coats of primer filler, waiting an hour between coats. Then it gets sanded until smooth.

Finally, apply two more coats, let those dry, and use 1000-grit sandpaper to wet-sand it, adding a drop of soap for a smoother time. Wipe it down again and apply a color primer, then spray paint it and apply a clear coat. Although it seems labor-intensive and time consuming, the results are totally worth it for something you’re going to have your hands on every day.

Got a hot tip that has like, anything to do with keyboards? Help me out by sending in a link or two. Don’t want all the Hackaday scribes to see it? Feel free to email me directly.

hackaday.com/2025/12/23/keebin…

Can a long-obsolete Linux phone from 2009 be of use in 2025? [Yaky] has a Nokia N900, and is giving it a go.

Back in the 2000s, Nokia owned the mobile phone space. They had a smartphone OS even if they didn’t understand app distribution, they had the best cameras, screens, antennas, the lot. They threw it all away with inept management that made late-stage Commodore look competent, Apple and Android came along, and now a Nokia is a rarity. Out of this mess came one good thing though, the N900 was a Linux-based smartphone that became the go-to hacker mobile for a few years.

First up with this N900 is the long-dead battery. He makes a fake battery with a set of supercapacitors and resistors to simulate the temperature sensor, and is then able to power it from an external PSU. This is refined to a better fake battery using the connector from the original. The device also receives a USB-C port, though due to space constraints not the PD identifiers, making it (almost) modern.

Because it was a popular hacker device, it’s possible to upgrade the software on an N900. He’s given it U-Boot, and now it boots Linux form an SD card and functions as an online radio device.

That’s impressive hackability and longevity for a phone, if only we could have more like it.

hackaday.com/2025/12/23/the-no…

To the surprise of almost nobody, the unprecedented build-out of datacenters and the equipping of them with servers for so-called ‘AI’ has led to a massive shortage of certain components. With random access memory (RAM) being so far the most heavily affected and with storage in the form of HDDs and SSDs not far behind, this has led many to ask the question of how we will survive the coming months, years, decades, or however-long the current AI bubble will last.

One thing is already certain, and that is that we will have to make our current computer systems last longer, and forego simply tossing in more sticks of RAM in favor of doing more with less. This is easy to imagine for those of us who remember running a full-blown Windows desktop system on a sub-GHz x86 system with less than a GB of RAM, but might require some adjustment for everyone else.

In short, what can us software developers do differently to make a hundred MB of RAM stretch further, and make a GB of storage space look positively spacious again?

Just What Happened?

At the risk of coming across as an ‘in my day’ rant, around the year 2000 I was using an AMD Duron 600 system with probably about 256 MB of SDRAM that succeeded my previous Intel Celeron 400 system with an amazing 64 MB of SDRAM. With Windows 2000 (arguably still the best version of Windows) on its own roomy 1 GB HDD partition there was still plenty of room on the rest of the HDD for applications, documents and some multimedia content like music and videos.

On these systems I could run a browser with many tabs open, alongside an office suite, an IDE, chat applications like IRC and ICQ, an email client, filesharing applications, and much more, without the system breaking a sweat. In the Duron 600 system I would eventually install a Matrox G550 AGP videocard to do some dual-monitor action, like watching videos or consulting documentation while browsing or programming at the same time.

Fast-forward a few decades and you cannot even install Windows on a 1 GB partition, and it requires more RAM than that. A quick check on the Windows 10 system that I’m typing this on shows that currently the Windows folder is nearly 27 GB in size and just the Thunderbird email client is gobbling up over 150 MB of RAM by itself. Compare this to the minimum Windows 2000 system requirements of a Pentium 133 MHz, 32 MB of RAM and 1 GB of free HDD space.

This raises the question of what the reason is for this increase, when that email client in the early 2000s had effectively the same features in a much smaller package, and Windows 2000 is effectively the same as Windows 7, 10 and now 11, at its core when it comes to its feature set.

The same is true for ‘fast and light’ options like Linux, which I had once running on a 486DX2-66 system, a system on which the average Linux distribution today won’t even launch the installer, unless you go for a minimalistic distro like Alpine Linux, which requires a mere 128 MB of RAM. Where does all this demand for extra RAM and disk storage come from? Is it just all lazy waste and bloat that merely fills up the available space like a noxious gas?

Asking The Right Questions

The Windows 10 desktop. (Source: Microsoft)
Storage and RAM requirements for software are linked in the sense that much of an application’s code and related resources are loaded into RAM at some point, but there is also the part of RAM that gets filled with data that the application generates while running. This gives us a lens to find out where the higher requirements come from.

In the case of Windows, the increase in minimum storage space requirements from 1 GB to 32 GB for Windows 10 can be explained by something that happened when Windows Vista rolled around along with changes to WinSxS, which is Windows’ implementation of side-by-side assembly.

By putting all core OS files in a single WinSxS folder and hard-linking them to various locations in the file system, all files are kept in a single location, with their own manifest and previous versions kept around for easy rollback. In Windows 2000, WinSxS was not yet used for the whole OS like this, mostly just to prevent ‘DLL Hell’ file duplication issues, but Vista and onwards leaned much more heavily into this approach as they literally dumped every single OS file into this folder.

While that by itself isn’t such an issue, keeping copies of older file versions ensured that with each Windows Update cycle the WinSxS folder grew a little bit more. This was confirmed in a 2008 TechNet blog post, and though really old files are supposed to be culled now, it clearly has ensured that a modern Windows installation grows to far beyond that of pre-Vista OSes.

Thus we have some idea of why disk storage size requirements are increasing, leading us to the next thing, which is the noticeable increase in binary size. This can be put down for a large part on increased levels of abstractions, both in system programming languages, as well as scripting languages and frameworks.

Losing Sight Of The Hardware

Over the past decades we have seen a major shift away from programming languages and language features that work directly with the hardware to ones that increasingly abstract away the hardware. This shift was obvious in the 90s already, with for example Visual Basic continuing the legacy of BASIC with a similar mild level of abstraction before Java arrived on the scene with its own virtual hardware platform that insisted that hardware was just an illusion that software developers ought to not bother with.

Subsequently we saw .NET, JavaScript, Python, and kin surge to the foreground, offering ‘easier programming’ and ‘more portable code’, yet at the same time increasing complexity, abstraction levels, as well as file sizes and memory usage. Most importantly, these languages abandoned the concept of programming the underlying hardware with as few levels of indirection as possible. This is something which has even become part of languages like C and C++, with my own loathing for this complexity and abstraction in C++ being very palpable.

In the case of a language like Python, it’s known to be exceedingly slow due to its architecture, which results in the atrocious CPython runtime as well as better, but far more complex alternatives. This is a software architecture that effectively ignores the hardware’s architecture, which thus results in bringing in a lot of unnecessary complexity. Languages such as JavaScript also make this mistake, with a heavy runtime that requires features such as type-checking and garbage collection that add complexity, while needing more code to enable features like Just-In-Time compilation to keep things still somewhat zippy.

With Java we even saw special JVM processor extensions being added to ARM processor with Jazelle direct bytecode execution (DBX) to make mobile games on cellphones programmed in J2ME not run at less than 1 FPS. Clearly if the software refuses to work with the hardware, the hardware has to adapt to the software.

By the time that you’re a few levels of abstraction, various ‘convenient frameworks’ and multiple layers of indirection down the proverbial rabbit hole, suddenly your application’s codebase has ballooned by a few 100k LoC, the final binary comes in at 100+ MB and dial-up users just whimper as they see the size of the installer. But at least now we know why modern-day Thunderbird uses more RAM than what an average PC would have had installed around 1999.

Not All Hope Is Lost

There’s no need to return to the days of chiseling raw assembly into stone tables like in the days when the 6502 and Z80 still reigned supreme. All we need to do to make the most of the RAM and storage we have, is to ask ourselves at each point whether there isn’t a more direct and less complex way. What this looks like will depend on the application, but the approach that I like to use with my own projects is that of the chronically lazy developer who doesn’t like writing more code than absolutely necessary, hates complexity because it takes effort and whose eyes glaze over at overly verbose documentation.

One could argue that there’s considerable overlap between KISS and laziness, in the sense that a handful of source files accompanied by a brief Makefile is simultaneously less work and less complex than a MB+ codebase that exceeds the capabilities of a single developer with a basic editor like Notepad++ or Vim. This incidentally is why I do not use IDEs but prefer to only rely on outrageously advanced features such as syntax highlighting and auto-indent. Using my brain for human-powered Intellisense makes for a good mental exercise.

I also avoid complex file formats like XML and their beefy parsers, preferring to instead use the INI format that’s both much easier to edit and parse. For embedding scripting languages I use the strongly-typed AngelScript, which is effectively scriptable C++ and doesn’t try any cute alternative architectures like Python or Lua do.

Rather than using bulky, overly bloated C++ frameworks like Boost, I use the much smaller and less complex Poco libraries, or my NPoco fork that targets FreeRTOS and similar embedded platforms. With my remote procedure call (RPC) framework NymphRPC I opted for a low-level, zero copy approach that tries to stick as closely to the CPU and memory system’s capabilities as feasible to do the work with the fewest resources possible.

While I’m not trying to claim that my approach is the One True Approach, for me half the fun of programming is to do the required task in a very efficient and low-resource manner, which is why I ported for example FFmpeg to the ESP32 so that I could run the same project code on this MCU, rather than deal with the complexity and documentation Hell of Espressif’s ESP-ADF framework.

Sure, I could probably have done something with MicroPython or so, but at the cost of a lot more storage and with far less performance. Which gets us back again to why modern day PCs need so much RAM and storage. It’s not a bug, but a feature of the system many of us opted for, or were told was the Modern Way.

hackaday.com/2025/12/23/surviv…

In an excellent example of one of the most overused XKCD images, the libxml2 library has for a little while lost its only maintainer, with [Nick Wellnhofer] making good on his plan to step down by the end of the year.
Modern-day infrastructure, as visualized by XKCD. (Credit: Randall Munroe)
While this might not sound like a big deal, the real scope of this problem is rather profound. Not only is libxml2 part of GNOME, it’s also used as dependency by a huge number of projects, including web browsers and just about anything that processes XML or XSLT. Not having a maintainer in the event that a fresh, high-risk CVE pops up would obviously be less than desirable.

As for why [Nick] stepped down, it’s a long story. It starts in the early 2000s when the original author [Daniel Veillard] decided he no longer had time for the project and left [Nick] in charge. It should be said here that both of them worked as volunteers on the project, for no financial compensation. This when large companies began to use projects like libxml2 in their software, and were happy to send bug reports. Beyond a single Google donation it was effectively unpaid work that required a lot of time spent on researching and processing potential security flaws sent in.

Of note is that when such a security report comes in, the expectation is that you as a volunteer software developer drop everything you’re working on and figure out the cause, fix and patched-by-date alongside filing a CVE. This rather than you getting sent a merge request or similar with an accompanying test case. Obviously these kind of cases seems to have played a major role in making [Nick] burn out on maintaining both libxml2 and libxslt.

Fortunately for the project two new developers have stepped up to take over as maintainers, but it should be obvious that such churn is not a good sign. It also highlights the central problem with the conflicting expectations of open source software being both totally free in a monetary fashion and unburdened with critical bugs. This is unfortunately an issue that doesn’t seem to have an easy solution, with e.g. software bounties resulting in mostly a headache.

hackaday.com/2025/12/23/libxml…

Secondo quanto appreso da fonti interne di RedHotCyber, l’offensiva digitale che sta creando problemi al Sistema Postale Nazionale in Francia è stata ufficialmente rivendicata dal collettivo hacker filo-russo NoName057(16).

Gli analisti confermano che l’azione rientra in una strategia di disturbo mirata a colpire i servizi essenziali dei paesi europei, utilizzando la tecnica del sovraccarico dei server per mettere in ginocchio la logistica nazionale.

Il blocco operativo sta interessando in modo critico la gestione della Banque Postale, la branca finanziaria del gruppo. Gli utenti si trovano nell’impossibilità di accedere ai propri conti tramite home banking, un disservizio che, unito alle difficoltà nei pagamenti digitali, sta creando forti tensioni proprio nel pieno della stagione degli acquisti natalizi.

Nonostante il caos generato sui portali web, i vertici de La Poste hanno diffuso una nota rassicurante riguardante la protezione dei dati sensibili. Al momento, non risulterebbero evidenze di esfiltrazione di informazioni personali o violazioni dei database dei clienti, suggerendo che l’attacco sia stato concepito principalmente per generare disservizi e non per il furto di identità.

La situazione più complessa si registra nel settore della logistica e delle spedizioni. Il sistema di monitoraggio dei pacchi risulta offline, rendendo impossibile per i cittadini tracciare i propri ordini. In molte aree, incluse diverse zone della capitale Parigi, il ritiro e l’invio delle merci sono stati parzialmente sospesi, provocando un accumulo di spedizioni nei depositi.

Le autorità d’oltralpe leggono questo incidente come l’ennesimo capitolo della cosiddetta “guerra ibrida“ russa.

Solo dieci giorni fa, il Ministero dell’Interno francese era stato bersaglio di un’intrusione informatica simile, a conferma di un inasprimento del conflitto digitale che mira a destabilizzare la fiducia dei cittadini nelle istituzioni pubbliche.
Schermata prelevata dal servizio CheckHost il 23/12/2025 alle ore 13:40.
Per chi si reca fisicamente negli uffici postali, l’esperienza è segnata da lunghe attese e procedure manuali. Molte filiali hanno dovuto interrompere le operazioni di sportello per problemi tecnici con i sistemi, tornando a modalità di lavoro analogiche che rallentano drasticamente l’erogazione di ogni servizio, dalle raccomandate ai servizi di sportello finanziario.

Questo attacco DDoS (Distributed Denial of Service) ha colpito con una tempistica chirurgica, sfruttando il picco di traffico che precede il Natale. L’obiettivo dei NoName sembra essere l’ottenimento del massimo impatto mediatico e sociale, colpendo un simbolo della quotidianità francese in un momento di massima vulnerabilità logistica per l’intero Paese.
Post dal canale telegram di Noname057(16), in lingua italiana, pubblicato poco fa.
Mentre gli esperti di sicurezza lavorano per ripristinare la piena funzionalità dei sistemi, resta alta l’allerta per possibili nuove ondate di attacchi. La resilienza delle infrastrutture critiche francesi è ora sotto esame, evidenziando la necessità di protocolli di difesa più robusti contro gruppi organizzati che operano con finalità di propaganda politica attraverso il sabotaggio informatico.

L'articolo Attacco DDoS contro La Poste francese: NoName057(16) rivendica l’operazione proviene da Red Hot Cyber.

Gli attivisti e pirati informatici di Anna’s Archive hanno riferito di aver rastrellato quasi l’intera libreria musicale del più grande servizio di streaming, Spotify. Affermano di aver raccolto metadati per 256 milioni di tracce e di aver scaricato direttamente i file audio: 86 milioni di brani, per un totale di circa 300 TB.

Anna’s Archive è un meta-motore di ricerca per biblioteche underground, lanciato nel 2022 da un’attivista anonima di nome Anna, poco dopo i tentativi delle forze dell’ordine di chiudere Z-Library. Il progetto aggrega contenuti provenienti da Z-Library, Sci-Hub, Library Genesis (LibGen), Internet Archive e altre fonti. Gli attivisti descrivono il loro lavoro come “preservare la conoscenza e la cultura umana”.

I membri di Anna’s Archive hanno annunciato la creazione del primo “archivio per la conservazione della musica”. Secondo gli attivisti, hanno recentemente scoperto un modo per effettuare lo scraping di massa di Spotify e hanno deciso di sfruttare questa opportunità per archiviare i contenuti.

“Qualche tempo fa, abbiamo scoperto un modo per estrarre dati da Spotify su larga scala. Abbiamo visto in questa un’opportunità per creare un archivio musicale incentrato principalmente sulla conservazione dei contenuti”, ha scritto la band sul proprio blog. “Certo, Spotify non ha tutta la musica del mondo, ma è un ottimo inizio.”

Secondo gli attivisti, tutte le raccolte musicali esistenti, sia fisiche che digitali, presentano gravi carenze. Questi archivi si concentrano principalmente su artisti popolari, puntano alla massima qualità audio (ad esempio, FLAC lossless), il che aumenta le dimensioni dei file, e non dispongono di un elenco centralizzato di torrent. Anna’s Archive ha deciso di colmare queste lacune.

Vale la pena notare che l’Archivio si concentra tipicamente su libri e articoli accademici, poiché il testo possiede la più alta densità di informazioni. Tuttavia, la missione del gruppo – la conservazione della conoscenza e della cultura umana – non fa distinzioni tra i diversi tipi di media. “A volte si presenta l’opportunità di preservare contenuti non testuali. Questo è esattamente uno di questi casi”, osservano gli attivisti.

Si dice che il dump di metadati risultante contenga informazioni sul 99,9% di tutte le tracce presenti sulla piattaforma, ovvero circa 256 milioni di composizioni. Questo lo rende il più grande database di metadati musicali pubblicamente disponibile al mondo. A titolo di confronto, i concorrenti dispongono di un numero di dischi compreso tra 50 e 150 milioni, mentre MusicBrainz ha solo 5 milioni di codici ISRC univoci, rispetto ai 186 milioni di Anna’s Archive.

Tuttavia, i metadati da soli non erano sufficienti. Gli attivisti hanno archiviato i file audio di 86 milioni di tracce. Sebbene ciò rappresenti solo il 37% del numero totale di brani disponibili su Spotify, queste tracce rappresentano il 99,6% di tutti gli streaming sulla piattaforma. In altre parole, c’è una probabilità del 99,6% che qualsiasi traccia ascoltata da un utente sia finita nell’archivio degli attivisti.

Per ordinare i brani è stata utilizzata la metrica di popolarità di Spotify, un valore numerico da 0 a 100 calcolato in base al numero di ascolti e alla loro pertinenza. I brani con popolarità superiore a 0 sono stati conservati nella loro qualità originale Ogg Vorbis a 160 kbps. I brani meno popolari sono stati transcodificati in Ogg Opus a 75 kbps. Sebbene la differenza non sia evidente per la maggior parte degli ascoltatori, aiuta a risparmiare spazio.

L’intero archivio sarà distribuito tramite torrent nel formato Anna’s Archive Containers (AAC), lo standard proprietario per la distribuzione dei file. La pubblicazione sarà suddivisa in diverse fasi: tutti i metadati raccolti sono già stati pubblicati, seguiti dalla pubblicazione dei brani stessi (ordinati per popolarità, dal più popolare al meno popolare), metadati aggiuntivi, copertina dell’album e patch per il ripristino dei file originali.

Gli attivisti hanno aggiunto quanti più metadati possibili a ciascun file: titolo della traccia, URL, codice ISRC, UPC, copertina dell’album, dati di replaygain e altre informazioni. I file Spotify originali non contenevano metadati, quindi il gruppo li ha incorporati nei file Ogg senza ricodificare l’audio.

I rappresentanti di Spotify hanno dichiarato ai media che si era effettivamente verificata una violazione dei dati. Hanno sottolineato che l’azienda aveva già identificato e bloccato gli account coinvolti nello scraping illegale e aveva implementato nuove misure di sicurezza per prevenire attacchi simili in futuro.

“Spotify ha identificato e sospeso account senza scrupoli utilizzati per lo scraping illegale. Abbiamo implementato nuove misure di sicurezza contro tali attacchi e stiamo monitorando attivamente le attività sospette. Ci impegniamo a supportare gli artisti nella lotta alla pirateria fin dal primo giorno e collaboriamo attivamente con i partner del settore per proteggere i creatori di contenuti e tutelare i loro diritti”, ha dichiarato la portavoce di Spotify, Laura Batey.

Per ora, l’archivio è focalizzato esclusivamente sulla conservazione dei contenuti ed è accessibile solo tramite torrent. Tuttavia, il gruppo ammette che, se ci sarà sufficiente interesse, potrebbe aggiungere la possibilità di scaricare singoli file direttamente dal suo sito web.

L'articolo 86 milioni di brani Spotify senza abbonamento: la minaccia degli attivisti di Anna’s Archive proviene da Red Hot Cyber.

serena bortone: "nessuno parlerebbe di fascismo se evitassero di inneggiare alla decima mas, fare francobolli sui fascisti, picchiare un deputato in aula. basterebbe avere un minimo di decenza" (https://x.com/grande_flagello/status/1802299304628941244)

e vogliamo parlare dei busti dell'appeso, che la seconda carica dello stato si tiene in casa?

#fascismo #neofascismo #governo #governoitaliano #antifascismo #Resistenza

ma gli studi decoloniali che ci stanno a fare, se non si vede quello che israhell ha fatto e fa da un secolo circa?
marcogiovenale.me/2025/08/03/c…

#israhell #colonialismo #genocidio #Palestinalibera #Palestina #gaza

“Leoncavallo, i giorni dello sgombero” / Alberto Grifi, Paola Pannicelli + Collettivo Video csoa Leoncavallo

differx.noblogs.org/2025/12/23…

#leoncavallo

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.