Usually when we see a project using a software-defined radio (SDR), the SDR’s inputs and outputs are connected to antennae, but [FromConceptToCircuit]’s project connected an ADALM-Pluto SDR to an RF bridge and a few passive components to make a surprisingly effective network analyzer (part two of the video).

The network analyzer measures two properties of the circuit to which it is connected: return loss (S11) and insertion gain or loss (S21). To measure S21, the SDR feeds a series of tones to the device under test, and reads the device’s output from one of the SDR’s inputs. By comparing the amplitude of the input to the device’s output, a Python program can calculate S21 over the range of tested frequencies. To find S11, [FromConceptToCircuit] put an RF bridge in line with the device being tested and connected the bridge’s output to the SDR’s second input. This allowed the program to calculate the device’s impedance, and from that S11.
The RF bridge and other components introduce some inaccuracies to the measurements, so before making any other measurements, the system is calibrated with both a through connection and an open circuit in place of the tested device. The RF bridge’s directivity was the biggest limiting factor; transfer back from the bridge’s output line caused the reflection under load to exceed the reflection of an open circuit in some frequency ranges, at which point the analyzer couldn’t accurately operate.

[FromConceptToCircuit] was eventually able to make measurements throughout most of the 0.1-3 GHz range with a dynamic range of at least 10 dB, and expects a more directive RF bridge to give even better results. If you’d like to repeat the experiment, he’s made his Python program available on GitHub.

We’ve previously seen [FromConceptToCircuit] use the Pluto SDR to make a spectrum analyzer. We’ve also featured a guide to the Pluto, covered a project that improved its frequency stability, and seen it used to transmit video.

youtube.com/embed/IFquLM-xF30?…

hackaday.com/2025/06/05/turnin…

Think of a circuit model that lets you move magnetic leakage around like sliders on a synth, without changing the external behavior of your coupled inductors. [Sam Ben-Yaakov] walks you through just that in his video ‘Versatile Coupled Inductor Circuit Model and Examples of Its Use’.

The core idea is as follows. Coupled inductors can be modeled in dozens of ways, but this one adds a twist: a tunable parameter 𝑥 between k and ₁ (where k is the coupling coefficient). This fourth degree of freedom doesn’t change L_₁, L_₂ or mutual inductance M (they remain invariant) but it lets you shuffle leakage where you want it, giving practical flexibility in designing or simulating transformers, converters, or filters with asymmetric behavior.

If you need leakage on one side only, set 𝑥=k. Prefer symmetrical split? Set 𝑥=1. It’s like parametric EQ, but magnetic. And: the maths holds up. As [Sam Ben-Yaakov] derives and confirms that for any 𝑥 in the range, external characteristics remain identical.

It’s especially useful when testing edge cases, or explaining inductive quirks that don’t behave quite like ideal transformers should. A good model to stash in your toolbox.

As we’ve seen previously, [Sam Ben-Yaakov] is at home when it comes to concepts that need tinkering, trial and error, and a dash of visuals to convey.

youtube.com/embed/VLoMeBYQ1Rc?…

hackaday.com/2025/06/05/leakag…

Satellite images show a new militia operating in southern Gaza in an area under IDF control, and a former Israeli defense minister claimed Israel is arming an ISIS-affiliated militia in Gaza to counter Hamas. In response, PM Netanyahu's office said the country is "working to defeat Hamas in various ways."

Se fosse vero sarebbe l'ennesima prova di quanto Israele sia sceso in basso.

Many engineers graduate from their studies and head out into the workforce, seeking a paycheck and a project at some existing company or other. Often, it’s not long before an experienced engineer begins to contemplate striking out on their own, working as a skilled gun-for-hire that makes their own money and their own hours.

It’s a daunting leap, but with the promise of rich rewards for those that stick the landing. That very leap is one that our own Dave Rowntree made. He came to Supercon 2024 to tell us what the journey was like, and how he wound up working on some very special shoes.

The Journey

youtube.com/embed/dxB8GEvKevc?…

Dave’s talk begins right at the start of his career. He graduated from college around the turn of the millenium, and headed right into to the big game. He landed a job at Phillips Semiconductors, and dived into what was then a rapidly-developing field—digital television! He quickly learned a great deal about embedded programming, but found the actual electronics skills he’d picked up during his studies weren’t being put to much use. Sadly, redundancies struck his company, and he was forced to pivot to stick around. A spot opened up in the IC test and manufacturing support group, and he jumped in there, before later decamping to a fabless semiconductor company as a test engineer. He then used his education and experience to leverage a leap into the design side of things, which brought the benefit of allowing him to join the royalty program.

Things were on the up for Dave, right until the redundancy train came around once again. The inconvenience, combined with a lack of jobs in his field in the UK, pushed him to consider a major lifestyle change. He’d strike out on his own.
Early on in his consulting and prototyping career, Dave found himself type cast as “the PCB guy.”
At this time, he explains how he tangled with the many challenges involved in working for one’s self. Not least of which, the difficulty of actually establishing a functional business in the UK, from bureaucratic red tape to handling the necessary marketing and financials.

He found his first jobs by working with so-called “innovation companies”—which provide services to those looking for design help to bring their ideas to life. These companies generally lacked engineering staff, so Dave’s services proved valuable to this specific market. It provided Dave some income, but came with a problem. After several years, he realized he had no public portfolio of work, because everything he’d worked on was under a non-disclosure agreement of some form or other.
He’s currently engaged in research and development of airbag-equipped shoes that could theoretically protect against ankle injuries.
Eventually, he realized he’d ended up in a “box.” He’d become “the PCB guy,” finding his work stagnating despite having such a broad and underexploited skillset. This didn’t sit right, and it was time for change once again. “I’m just thinking I don’t want to be a PCB guy,” Dave explains. “I want to do it all.” Thus was born his push into new fields. He built an arcade machine, art installations, and kept working to push himself out of his comfort zone.

Eventually, something exciting came down the line that really inspired him. “Some guys wanted me to build something, and it was totally oddball,” he says. “They wanted me to put an airbag in a basketball shoe.” The concept was simple enough—the airbag was intended to deploy to protect the wearer if excessive ankle roll was detected. Building the shoe in real life would be the perfect opportunity for him to stretch his abilities.

Despite his initial misgivings around the idea of putting explosives in shoes, the team behind the idea were able to twist Dave’s arm. “If I want to break out of the box of being just a PCB guy, maybe this is it,” he thought. “Why the hell not!”
While Dave’s engineering training didn’t focus a whole lot on feet, he’s been learning a great deal of late as he produces his own custom podiatric force sensors.
The rest of Dave’s talk covers how the project came to break him out of his design funk, and how he’s tackling the difficult engineering problems involved. Even more joyously, he’s able to talk openly about it since there’s no NDA involved. He compares plans to use pyrotechnic devices versus stored gas systems, tears down commercial shoes for research, and even his journey into the world of scanning feet and making his own force sensors. As much as he was leveraging his existing skill base, he’s also been expanding it rapidly to meet the new challenges of a truly wild shoe project.

Dave’s talk is an inspiring walk through how he developed a compelling and satisfying engineering career without just going by the book. It’s also an enjoyable insight into the world of weird airbag shoes that sound too fantastical to exist. If you’ve ever thought about leaving the career world behind and going out on your own, Dave’s story is a great one to study.

hackaday.com/2025/06/05/superc…

Negli ultimi giorni, su due noti forum underground specializzati nella compravendita di dati trafugati e metodi fraudolenti, sono comparsi tre post separati (ma identici nel contenuto), riguardanti un presunto leak di dati appartenenti ad AT&T.

Secondo quanto riportato dagli utenti coinvolti, il file conterrebbe oltre 73 milioni di record per un totale di 3 GB compressi, contenenti dati potenzialmente sensibili appartenenti a clienti AT&T.

Disclaimer: Questo rapporto include screenshot e/o testo tratti da fonti pubblicamente accessibili. Le informazioni fornite hanno esclusivamente finalità di intelligence sulle minacce e di sensibilizzazione sui rischi di cybersecurity. Red Hot Cyber condanna qualsiasi accesso non autorizzato, diffusione impropria o utilizzo illecito di tali dati. Al momento, non è possibile verificare in modo indipendente l’autenticità delle informazioni riportate, poiché l’organizzazione coinvolta non ha ancora rilasciato un comunicato ufficiale sul proprio sito web. Di conseguenza, questo articolo deve essere considerato esclusivamente a scopo informativo e di intelligence.

Due post, stesso contenuto

I thread sui un forum underground (che coincidono con quanto pubblicato anche su un noto forum chiuso in lingua russa), pubblicati a distanza di poche ore l’uno dall’altro, presentano lo stesso titolo:
“AT&T Division Database [New Link]” o “AT&T 70M Customer Records (2024)”. Entrambi descrivono un archivio massivo con i seguenti dettagli:

• Linee: 73.481.539
• Formato: file compresso (.zip) da circa 3 GB
• Contenuto: presumibilmente dati personali o aziendali collegati ad AT&T

Gli autori: USD e WHT

Il primo post è stato condiviso da un utente chiamato WHT, mentre il secondo ad USD.

Non è la prima volta che AT&T viene associata a incidenti di sicurezza o presunte fughe di dati. Tuttavia, al momento non vi è alcuna conferma ufficiale da parte dell’azienda riguardo a questo specifico leak. Se autentico, un file di queste dimensioni potrebbe rappresentare una seria minaccia alla privacy di milioni di utenti, con impatti che spaziano da phishing mirato e SIM swapping, fino a frodi su larga scala.

Il record apparentemente esfiltrato riportato all’interno di più post nei canali underground sembrerebbe essere il seguente:

• Full names
• Dates of birth
• Phone numbers
• Email addresses
• Physical addresses
• Social Security numbers (SSNs)

Il fatto che lo stesso leak venga pubblicato da più forum e in più varianti è indicativo di una distribuzione virale all’interno delle community cybercriminali.

La presenza di sample visibili e la mole di dati dichiarata rendono questa fuga di informazioni particolarmente degna di attenzione. Resta ora da verificare la reale autenticità del database e, se confermata, sarà fondamentale monitorare l’eventuale impatto sulla clientela AT&T e sulle infrastrutture correlate.

Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione dell’organizzazione qualora voglia darci degli aggiornamenti su questa vicenda e saremo lieti di pubblicarla con uno specifico articolo dando risalto alla questione.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono accedere utilizzare la mail crittografata del whistleblower.

L'articolo Un Database AT&T da 3GB viene Venduto nel Dark Web: 73 Milioni di Record a Rischio proviene da il blog della sicurezza informatica.

E se le intelligenze artificiali producessero del codice vulnerabile oppure utilizzassero librerie e costrutti contenenti bug vecchi mai sanati? Si tratta di allucinazione o apprendimento errato?

Una vulnerabilità risalente a quindici anni fa, pubblicata per la prima volta come Gist su GitHub nel 2010 , continua a infettare progetti open source, tutorial e persino modelli linguistici di grandi dimensioni. Nonostante gli avvertimenti degli sviluppatori del 2012, 2014 e 2018, un esempio del codice vulnerabile è migrato nella documentazione di MDN e nelle risposte di Stack Overflow, per poi finire nei dati di training di LLM.

Il ricercatore Yafar Akhundali dell’Università di Leida e i suoi colleghi hanno sviluppato un sistema automatizzato in grado di individuare, sfruttare e correggere questa vulnerabilità nei progetti GitHub. Il lavoro è descritto in un preprint su arXiv intitolato “Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub”.

Questo è un caso di CWE-22, una tipica vulnerabilità di path traversal in cui un costrutto può essere utilizzato per accedere a directory al di fuori dell’area consentita. In pratica, questo può portare sia a perdite di file che ad attacchi DoS tramite overflow di memoria.

Gli autori hanno condotto un test che ha coinvolto Claude, Gemini, GPT-3.5, GPT-4, GPT-4o e diverse modalità Copilot. Quando ai modelli è stato chiesto di scrivere un server semplice senza librerie di terze parti, 76 richieste su 80 hanno restituito codice vulnerabile. Anche richiedendo direttamente la versione “sicura”, 56 esempi su 80 sono rimasti vulnerabili. GPT-3.5 e Copilot (bilanciato) hanno ottenuto prestazioni particolarmente scarse, non generando una singola variante sicura.

Il sistema automatizzato sviluppato dal team è in grado di analizzare repository pubblici, riprodurre un attacco in un ambiente sandbox e, se una vulnerabilità viene confermata, generare e inviare automaticamente una patch. Per generare le patch viene utilizzato il protocollo GPT-4 e le notifiche relative ai risultati vengono inviate via email agli autori del progetto, in modo da non divulgare pubblicamente le vulnerabilità.

Dei 40.546 repository, il sistema ha identificato 41.870 file vulnerabili. Dopo averli filtrati con l’analisi statica, ne sono rimasti 8.397, di cui 1.756 vulnerabili. Sono state generate e inviate 1.600 patch valide. Tuttavia, il numero totale di progetti che hanno applicato le correzioni è stato di soli 63, meno del 15% di quelli che hanno ricevuto una notifica.

Secondo Akhundali, il motivo della scarsa risposta è che molti progetti vengono abbandonati o il codice vulnerabile non raggiunge l’ambiente di produzione. Tuttavia, questo non riduce il rischio: se la vulnerabilità viene sfruttata, può portare alla compromissione del sistema.

Gli autori osservano: gli LLM oggi stanno diventando non solo uno strumento di generazione di codice, ma anche un canale per la distribuzione di vulnerabilità. Persino i modelli più diffusi producono con sicurezza soluzioni non sicure, pur dichiarando di essere protetti.

Data la crescita degli “agenti di programmazione” e la pratica del “vibe coding”, la fiducia cieca negli assistenti AI senza analizzarne l’output è la strada diretta verso gli incidenti .

L'articolo Non fidarti del codice prodotto dalle AI! Un bug Giurassico del 2010 infetta anche GPT-4 proviene da il blog della sicurezza informatica.

If you think of a 1960s mainframe computer, it’s likely that your mental image includes alongside the cabinets with the blinkenlights, a row of reel-to-reel tape drives. These refrigerator-sized units had a superficial resemblance to an audio tape deck, but with the tape hanging down in a loop either side of the head assembly. This loop was held by a vacuum to allow faster random access speeds at the head, and this fascinates [Thorbjörn Jemander]. He’s trying to create a cassette tape drive that can load 64 kilobytes in ten seconds, so he’s starting by replicating the vacuum columns of old.

The video below is the first of a series on this project, and aside from explaining the tape drive’s operation, it’s really an in-depth exploration of centrifugal fan design. He discovers that it’s speed rather than special impeller design that matters, and in particular a closed impeller delivers the required vacuum. We like his home-made manometer in particular.

What he comes up with is a 3D printed contraption with a big 12 volt motor on the back, and a slot for a cassette on the front. It achieves the right pressure, and pulls the tape neatly down into a pair of loops. We’d be curious to know whether a faster motor such as you might find in a drone would deliver more for less drama, but we can see the genesis of a fascinating project here. Definitely a series to watch.

Meanwhile, if your interest extends to those early machine rooms, have a wallow in the past.

youtube.com/embed/avpn8rIkkRY?…

hackaday.com/2025/06/05/a-stea…

We exposed as a lie the Trump administration’s basis for repealing restrictions on surveilling journalists to investigate leaks. The “fake news” that the administration claimed to be combating — reports that the intelligence community disputed its claim that the Venezuelan government directed the activities of the Tren de Aragua gang in the United States – was, in fact, 100 percent accurate.

But just in case that bombshell and the widespread news coverage that followed doesn’t shame the administration into changing course, Freedom of the Press Foundation (FPF) hosted a discussion about past efforts by the government to out reporters’ sources and what journalists should expect when federal prosecutors come after their newsgathering.

Our panelists would know better than most. Former New York Times reporter and Pulitzer Prize-winner James Risen fought a seven-year battle against attempts by both the George W. Bush and Barack Obama administrations to force him to testify and reveal his sources in a leak investigation. He detailed the Obama administration’s endless litigation against him, while at the same time it engaged in secret digital surveillance of his communications.

Ryan Lizza, the founder and editor of Telos.news and a former reporter at Politico, CNN, and The New Yorker, also joined to discuss his reporting on the Obama administration’s overreach in secretly spying on Fox News reporter James Rosen, as well as efforts by former U.S. representative and current Trump sycophant Devin Nunes to obtain Lizza’s communications from tech companies in separate litigation.

And Lauren Harper, Daniel Ellsberg chair on government secrecy at FPF, discussed the aforementioned revelations about the Trump administration’s false pretexts for cracking down on leaks, which she obtained through the Freedom of Information Act.

youtube.com/embed/5_SDsXS5s8g?…

Risen started by laying out the stakes that emerged after 9/11. “Basically everything about the American conduct in the war on terror was classified,” he explained. “Everything that we now take for granted about our body of knowledge about how the United States conducts warfare in the 21st century came through leaks or unauthorized disclosures of one form or another.”

Lizza agreed, adding that critics of the Iraq War in the current administration would not have been able to mount their criticisms without leaks. Politicians, he explained, use leaked information to form the basis for their political platforms and then turn against leakers when they’re the ones in power.

Harper disputed the administration’s apparent belief that the solution to leaks is more secrecy, not less. “Upwards of 90% of information that is classified ought not to be. So I think in some ways, we can look at leaks as a response to a broken classification system,” she said.

Risen observed that the Obama administration finally backed down from forcing him to testify not due to the law but due to bad press. Lizza had similar impressions from his coverage of the Rosen case, explaining that his reporting “got the ear of some people in the Obama administration who did not like being accused of attacking the First Amendment and going after reporters.”

As Risen explained, when the government comes after journalists it’s often not about finding out who they’re talking to, it’s about “having a chilling effect on journalism in general and making sure everybody is afraid of the government.” Added Risen, “They’ll go after journalists not because they need them, but because they want to punish them and set an example.”

It remains to be seen whether the Trump administration will respond to public shaming like Obama did, but we won’t know unless we try. First, the press needs to avoid surveillance, by implementing digital security best practices when storing data and communicating electronically with sources, but also, as Risen said, going “off the grid” and communicating face-to-face whenever possible.

When that fails and the government comes after journalists’ sources anyway, it’s imperative that the press stand up for itself and its sources, by raising alarms about the risks to investigative reporting and press freedom when the government is able to snoop into reporters’ notebooks and emails. Caving to the pressure only encourages more retaliation.

freedom.press/issues/burn-afte…

There comes a moment in the life of any operating system when an unforeseen event will tragically cut its uptime short. Whether it’s a sloppily written driver, a bug in the handling of an edge case or just dumb luck, suddenly there is nothing more that the OS’ kernel can do to salvage the situation. With its last few cycles it can still gather some diagnostic information, attempt to write this to a log or memory dump and then output a supportive message to the screen to let the user know that the kernel really did try its best.

This on-screen message is called many things, from a kernel panic message on Linux to a Blue Screen of Death (BSOD) on Windows since Windows 95, to a more contemplative message on AmigaOS and BeOS/Haiku. Over the decades these Screens of Death (SoD) have changed considerably, from the highly informative screens of Windows NT to the simplified BSOD of Windows 8 onwards with its prominent sad emoji that has drawn a modicum of ridicule.

Now it seems that the Windows BSOD is about to change again, and may not even be blue any more. So what’s got a user to think about these changes? What were we ever supposed to get out of these special screens?

Meditating On A Fatal Error

AmigaOS fatal Guru Meditation error screen.
More important than the color of a fatal system error screen is what information it displays. After all, this is the sole direct clue the dismayed user gets when things go south, before sighing and hitting the reset button, followed by staring forlorn at the boot screen. After making it back into the OS, one can dig through the system logs for hints, but some information will only end up on the screen, such as when there is a storage drive issue.

The exact format of the information on these SoDs changes per OS and over time, with AmigaOS’ Guru Meditation screen being rather well-known. Although the naming was the result of an inside joke related to how the developers dealt with frequent system crashes, it stuck around in the production releases.

Interestingly, both Windows 9x and ME as well as AmigaOS have fatal and non-fatal special screens. In the case of AmigaOS you got a similar screen to the Guru Meditation screen with its error code, except in green and the optimistic notion that it might be possible to continue running after confirming the message. For Windows 9x/ME users this might be a familiar notion as well :
BSOD in Windows 95 after typing “C:\con\con” in the Run dialog.
In this series of OSes you’d get these screens, with mashing a key usually returning you to a slightly miffed but generally still running OS minus the misbehaving application or driver. It could of course happen that you’d get stuck in an endless loop of these screens until you gave up and gave the three-finger salute to put Windows out of its misery. This was an interesting design choice, which Microsoft’s Raymond Chen readily admits to being somewhat quaint. What it did do was abandon the current event and return to the event dispatcher to give things another shot.
Mac OS X 10.2 thru 10.2.8 kernel panic message.
A characteristic of these BSODs in Windows 9x/ME was also that they didn’t give you a massive amount of information to work with regarding the reason for the rude interruption. Incidentally, over on the Apple side of the fence things were not much more elaborate in this regard, with OS X’s kernel panic message getting plastered over with a ‘Nothing to see here, please restart’ message. This has been quite a constant ever since the ‘Sad Mac’ days of Apple, with friendly messages rather than any ‘technobabble’.

This quite contrasts with the world of Windows NT, where even the already trimmed BSOD of Windows XP is roughly on the level of the business-focused Windows 2000 in terms of information. Of note is also that a BSOD on Windows NT-based OSes is a true ‘Screen of Death’, from which you absolutely are not returning.
A BSOD in Windows XP. A true game over, with no continues.
These BSODs provide a significant amount of information, including the faulting module, the fault type and some hexadecimal values that can conceivably help with narrowing down the fault. Compared to the absolute information overload in Windows NT 3.1 with a partial on-screen memory dump, the level of detail provided by Windows 2000 through Windows 7 is probably just enough for the average user to get started with.

It’s here interesting that more recent versions of Windows have opted to default to restarting automatically when a BSOD occurs, which renders what is displayed on them rather irrelevant. Maybe that’s why Windows 8 began to just omit that information and opted to instead show a generic ‘collecting information’ progress counter before restarting.

Times Are Changing

People took the new BSOD screen in Windows 8 well.
Although nobody was complaining about the style of BSODs in Windows 7, somehow Windows 8 ended up with the massive sad emoji plastered on the top half of the screen and no hexadecimal values, which would now hopefully be found in the system log. Windows 10 also added a big QR code that leads to some troubleshooting instructions. This overly friendly and non-technical BSOD mostly bemused and annoyed the tech community, which proceeded to brutally make fun of it.

In this context it’s interesting to see these latest BSOD screen mockups from Microsoft that will purportedly make their way to Windows 11 soon.

These new BSOD screens seem to have a black background (perhaps a ‘Black Screen of Death’?), omit the sad emoji and reduce the text to an absolute minimum:
The new Windows 11 BSOD, as it’ll likely appear in upcoming releases.
What’s noticeable here is how it makes the stop code very small on the bottom of the screen, with the faulting module below it in an even smaller font. This remains a big departure from the BSOD formats up till Windows 7 where such information was clearly printed on the screen, along with additional information that anyone could copy over to paper or snap a picture of for a quick diagnosis.

But Why

The BSODs in ReactOS keep the Windows 2000-style format.
The crux here is whether Microsoft expects their users to use these SoDs for informative purposes, or whether they would rather that they get quickly forgotten about, as something shameful that users shouldn’t concern themselves with. It’s possible that they expect that the diagnostics get left to paid professionals, who would have to dig into the memory dumps, the system logs, and further information.

Whatever the case may be, it seems that the era of blue SoDs is well and truly over now in Windows. Gone too are any embellishments, general advice, and more in-depth debug information. This means that distinguishing the different causes behind a specific stop code, contained in the hexadecimal numbers, can only be teased out of the system log entry in Event Viewer, assuming it got in fact recorded and you’re not dealing with a boot partition or similar fundamental issue.

Although I’ll readily admit to not having seen many BSODs since probably Windows 2000 or XP — and those were on questionable hardware — the rarity of these events makes it in my view even more pertinent that these screens are as descriptive as possible, which is sadly not a feature that seems to be a priority for mainstream desktop OSes. Nor for niche OSes like Linux and BSD, tragically, where you have to know your way around the Systemd journalctl tool or equivalent to figure out where that kernel panic came from.

This is definitely a point where the SoD generated upon a fiery kernel explosion sets the tone for the user’s response.

hackaday.com/2025/06/05/screen…

Il Dipartimento di Stato americano ha annunciato una ricompensa fino a 10 milioni di dollari per informazioni sugli hacker che lavorano per governi stranieri e sono collegati al malware RedLine, nonché sul presunto creatore di questo malware, Maxim Rudometov. La ricompensa copre anche informazioni sull’utilizzo di RedLine in attacchi informatici contro infrastrutture critiche negli Stati Uniti.

Il programma Rewards for Justice specifica espressamente che le informazioni devono riguardare attacchi informatici condotti su indicazione o sotto il controllo di governi stranieri e che violano il Computer Fraud and Abuse Act statunitense. Di particolare interesse sono i partecipanti a operazioni informatiche che utilizzano il malware RedLine, un popolare infostealer utilizzato per rubare le credenziali degli utenti.

Il Dipartimento di Stato ha osservato che chiunque abbia informazioni sui soci di Rudometov, sulle loro attività informatiche dannose o sull’uso del malware RedLine dovrebbe contattare Rewards for Justice tramite un canale di messaggistica basato su Tor .

Le autorità statunitensi ritengono che Maxim Rudometov fosse lo sviluppatore e l’amministratore dell’intera infrastruttura di RedLine Infostealer. Nell’ottobre 2024, è stato incriminato nell’ambito dell’Operazione Magnus, un’operazione internazionale durante la quale le forze dell’ordine statunitensi e i loro partner stranieri hanno condotto un’operazione su larga scala per bloccare contemporaneamente le attività di due servizi: RedLine e META, che operavano secondo il modello malware-as-a-service (MaaS).

Secondo il Dipartimento di Giustizia degli Stati Uniti, Rudometov gestiva i server di RedLine, riceveva e riciclava i proventi tramite wallet di criptovalute e interagiva direttamente con il codice e la distribuzione del malware. Durante l’indagine, sono stati accertati i suoi collegamenti con i principali canali di distribuzione, inclusi gli account Telegram utilizzati per promuovere e vendere malware agli utenti finali. Ad oggi, sono stati identificati oltre 1.200 server utilizzati per gestire le botnet RedLine e META.

L’operazione ha coinvolto anche la polizia olandese e l’agenzia Eurojust.

Due sospettati sono stati arrestati in Belgio e tre server e due domini utilizzati come nodi di controllo sono stati sequestrati. Tuttavia, non è stato confermato ufficialmente se Rudometov sia stato arrestato.

Se riconosciuto colpevole, potrebbe rischiare fino a 35 anni di carcere per frode su dispositivi di accesso, associazione a delinquere finalizzata a commettere intrusioni informatiche e riciclaggio di denaro.

L'articolo Gli USA vogliono il creatore di RedLine. 10 milioni per chi tradisce l’hacker del più noto infostealer proviene da il blog della sicurezza informatica.