From cheats to exploits: Webrat spreading via GitHub

In early 2025, security researchers uncovered a new malware family named Webrat. Initially, the Trojan targeted regular users by disguising itself as cheats for popular games like Rust, Counter-Strike, and Roblox, or as cracked software. In September, the attackers decided to widen their net: alongside gamers and users of pirated software, they are now targeting inexperienced professionals and students in the information security field.

Distribution and the malicious sample

In October, we uncovered a campaign that had been distributing Webrat via GitHub repositories since at least September. To lure in victims, the attackers leveraged vulnerabilities frequently mentioned in security advisories and industry news. Specifically, they disguised their malware as exploits for the following vulnerabilities with high CVSSv3 scores:

This is not the first time threat actors have tried to lure security researchers with exploits. Last year, they similarly took advantage of the high-profile RegreSSHion vulnerability, which lacked a working PoC at the time.

In the Webrat campaign, the attackers bait their traps with both vulnerabilities lacking a working exploit and those which already have one. To build trust, they carefully prepared the repositories, incorporating detailed vulnerability information into the descriptions. The information is presented in the form of structured sections, which include:

• Overview with general information about the vulnerability and its potential consequences
• Specifications of systems susceptible to the exploit
• Guide for downloading and installing the exploit
• Guide for using the exploit
• Steps to mitigate the risks associated with the vulnerability

Contents of the repository

In all the repositories we investigated, the descriptions share a similar structure, characteristic of AI-generated vulnerability reports, and offer nearly identical risk mitigation advice, with only minor variations in wording. This strongly suggests that the text was machine-generated.

The Download Exploit ZIP link in the Download & Install section leads to a password-protected archive hosted in the same repository. The password is hidden within the name of a file inside the archive.

The archive downloaded from the repository includes four files:

1. pass – 8511: an empty file, whose name contains the password for the archive.
2. payload.dll: a decoy, which is a corrupted PE file. It contains no useful information and performs no actions, serving only to divert attention from the primary malicious file.
3. rasmanesc.exe (note: file names may vary): the primary malicious file (MD5 61b1fc6ab327e6d3ff5fd3e82b430315), which performs the following actions:
   
   • Escalate its privileges to the administrator level (T1134.002).
   • Disable Windows Defender (T1562.001) to avoid detection.
   • Fetch from a hardcoded URL (ezc5510min.temp[.]swtest[.]ru in our example) a sample of the Webrat family and execute it (T1608.001).

   
   

4. start_exp.bat: a file containing a single command: start rasmanesc.exe, which further increases the likelihood of the user executing the primary malicious file.

The execution flow and capabilities of rasmanesc.exe

Webrat is a backdoor that allows the attackers to control the infected system. Furthermore, it can steal data from cryptocurrency wallets, Telegram, Discord and Steam accounts, while also performing spyware functions such as screen recording, surveillance via a webcam and microphone, and keylogging. The version of Webrat discovered in this campaign is no different from those documented previously.

Campaign objectives

Previously, Webrat spread alongside game cheats, software cracks, and patches for legitimate applications. In this campaign, however, the Trojan disguises itself as exploits and PoCs. This suggests that the threat actor is attempting to infect information security specialists and other users interested in this topic. It bears mentioning that any competent security professional analyzes exploits and other malware within a controlled, isolated environment, which has no access to sensitive data, physical webcams, or microphones. Furthermore, an experienced researcher would easily recognize Webrat, as it’s well-documented and the current version is no different from previous ones. Therefore, we believe the bait is aimed at students and inexperienced security professionals.

Conclusion

The threat actor behind Webrat is now disguising the backdoor not only as game cheats and cracked software, but also as exploits and PoCs. This indicates they are targeting researchers who frequently rely on open sources to find and analyze code related to new vulnerabilities.

However, Webrat itself has not changed significantly from past campaigns. These attacks clearly target users who would run the “exploit” directly on their machines — bypassing basic safety protocols. This serves as a reminder that cybersecurity professionals, especially inexperienced researchers and students, must remain vigilant when handling exploits and any potentially malicious files. To prevent potential damage to work and personal devices containing sensitive information, we recommend analyzing these exploits and files within isolated environments like virtual machines or sandboxes.

We also recommend exercising general caution when working with code from open sources, always using reliable security solutions, and never adding software to exclusions without a justified reason.

Kaspersky solutions effectively detect this threat with the following verdicts:

• HEUR:Trojan.Python.Agent.gen
• HEUR:Trojan-PSW.Win64.Agent.gen
• HEUR:Trojan-Banker.Win32.Agent.gen
• HEUR:Trojan-PSW.Win32.Coins.gen
• HEUR:Trojan-Downloader.Win32.Agent.gen
• PDM:Trojan.Win32.Generic

Indicators of compromise

Malicious GitHub repositories
https://github[.]com/RedFoxNxploits/CVE-2025-10294-Poc
https://github[.]com/FixingPhantom/CVE-2025-10294
https://github[.]com/h4xnz/CVE-2025-10294-POC
https://github[.]com/usjnx72726w/CVE-2025-59295/tree/main
https://github[.]com/stalker110119/CVE-2025-59230/tree/main
https://github[.]com/moegameka/CVE-2025-59230
https://github[.]com/DebugFrag/CVE-2025-12596-Exploit
https://github[.]com/themaxlpalfaboy/CVE-2025-54897-LAB
https://github[.]com/DExplo1ted/CVE-2025-54106-POC
https://github[.]com/h4xnz/CVE-2025-55234-POC
https://github[.]com/Hazelooks/CVE-2025-11499-Exploit
https://github[.]com/usjnx72726w/CVE-2025-11499-LAB
https://github[.]com/modhopmarrow1973/CVE-2025-11833-LAB
https://github[.]com/rootreapers/CVE-2025-11499
https://github[.]com/lagerhaker539/CVE-2025-12595-POC

Webrat C2
http://ezc5510min[.]temp[.]swtest[.]ru
http://shopsleta[.]ru

MD5
28a741e9fcd57bd607255d3a4690c82f
a13c3d863e8e2bd7596bac5d41581f6a
61b1fc6ab327e6d3ff5fd3e82b430315

securelist.com/webrat-distribu…

Using an e-Book Reader as a Secondary Display

[Alireza Alavi] wanted to use an e-ink tablet as a Linux monitor. Why? We don’t need to ask. You can see the result of connecting an Onyx BOOX Air 2 to an Arch Linux box in the video below.

Like all good projects, this one had a false start. Deskreen sounds good, as it is an easy way to stream your desktop to a browser. The problem is, it isn’t very crisp, and it can be laggy, according to the post. Of course, VNC is a tried-and-true solution. The Onyx uses Android, so there were plenty of VNC clients, and Linux, of course, has many VNC servers.

Putting everything together as a script lets [Alireza] use the ebook as a second monitor. Using it as a main monitor would be difficult, and [Alireza] reports using the two monitors to mirror each other, so you can glance over at the regular screen for a color image, for example.

Another benefit of the mirrored screens is that VNC lets you use the tablet’s screen as an input device, which is handy if you are drawing in GIMP or performing similar tasks.

We sometimes use VNC on Android just to get to a fake Linux install running on the device.

youtube.com/embed/TeOg7Of8ZU4?…

hackaday.com/2025/12/23/using-…

La mente e le password: l’Effetto “Louvre” spiegato con una password pessima

Nella puntata precedente (La psicologia delle password. Non proteggono i sistemi: raccontano le persone), abbiamo parlato di come le password, oltre a proteggere i sistemi, finiscano per raccontare le persone.

Questa volta facciamo un passo in più: proviamo a capire perché ci affezioniamo proprio a quelle peggiori e perché cambiarle produce spesso l’effetto opposto a quello desiderato.

Paris…

Il punto di partenza è un episodio di cronaca: all’interno di una combolist circolata in ambienti criminali è comparsa una coppia di credenziali che associava un indirizzo istituzionale del Louvre a una password sorprendentemente coerente con il contesto: paris – e le sue inevitabili reincarnazioni.

Partiamo dalla fine: la combo è stravecchia e la password è stata cambiata da anni.

Il riflesso mentale che l’ha prodotta, purtroppo, no.

Ed è proprio quel riflesso che vale la pena osservare.

Paris – e ciò che puntualmente le cresce intorno – non nasce da distrazione né da superficialità.

Nasce perché ha senso. Il Louvre è a Parigi, l’account riguarda il Louvre, e il cervello umano fa ciò che sa fare meglio quando lo sforzo richiesto è minimo: prende il contesto e lo trasforma in soluzione. Non cerca sicurezza, ma coerenza.

La password smette di essere una chiave e diventa qualcosa che “torna”, che non disturba, che non richiede memoria né attrito.

È qui che l’aneddoto smette di essere cronaca e diventa psicologia. Una password costruita così non viene percepita come debole, ma come nostra. L’abbiamo assemblata partendo da ciò che conosciamo, e questo basta a renderla affidabile ai nostri occhi.

È l’Effetto IKEA applicato alla sicurezza: tendiamo a dare più valore a ciò che abbiamo costruito noi, anche quando è fragile.

Il problema emerge nel momento successivo, quando entra in scena il rito del Cambia Password. Se quella parola non è solo una stringa ma un piccolo equilibrio mentale, cambiarla non è un’operazione tecnica. È una rinuncia.

E la mente, davanti a una perdita, non reagisce creando qualcosa di nuovo: reagisce cercando continuità. La forma resta, cambiano i dettagli. Le varianti si moltiplicano, la sicurezza molto meno.

Il sistema chiede complessità. La mente risponde con riconoscibilità.

L’Effetto IKEA (perché difendiamo le password peggiori)

C’è un motivo se una password come paris resiste più a lungo di quanto dovrebbe.
Non è tecnico. È affettivo.

In psicologia si chiama Effetto IKEA: tendiamo a dare più valore agli oggetti che abbiamo costruito noi, anche quando sono fragili, storti o palesemente migliorabili. Non perché siano migliori, ma perché raccontano il tempo e il ragionamento che ci abbiamo messo dentro.

Montare un mobile traballante e difenderlo con orgoglio è un comportamento perfettamente umano. Fare lo stesso con una password lo è ancora di più.

Una password costruita a partire dal contesto – un luogo, un ruolo, un’associazione evidente – non viene vissuta come una scelta debole. Viene vissuta come una scelta “pensata”. L’abbiamo fatta noi, ha un senso, la riconosciamo al volo. E questo basta a farla sembrare affidabile, anche quando non lo è.

Il paradosso è che l’Effetto IKEA funziona meglio proprio dove dovrebbe fallire. Più una password è semplice, leggibile, coerente, più diventa familiare. E più diventa familiare, più facciamo fatica a metterla in discussione.

Non la valutiamo come una chiave. La trattiamo come un oggetto personale.

E quando un sistema ci suggerisce di sostituirle, la reazione istintiva non è migliorare, ma conservare: tenere la forma, aggiustare i bordi, cambiare il minimo indispensabile per poter dire di aver obbedito.

L’Effetto IKEA non ci rende ingenui. Ci rende coerenti con noi stessi.

Ed è proprio questa coerenza, così utile nella vita quotidiana, che nel digitale diventa prevedibile.

Un esempio minimo

Pensiamo a un mobile IKEA.

Lo monti la sera, quando tutti ti guardano. Segui le istruzioni, più o meno. A un certo punto manca una vite. Oppure ce n’è una di troppo, che resta lì sul tavolo a fissarti.

Il mobile alla fine sta in piedi. Un po’ storto. Un’anta non chiude perfettamente.

La famiglia lo guarda in silenzio.
Qualcuno chiede: “È normale?”

E a quel punto difenderlo diventa inevitabile.

Con le password succede la stessa cosa.

Una password costruita a partire dal contesto nasce spesso così: qualcosa manca, qualcosa avanza, ma “funziona”. Non è elegante, non è robusta, ma è nostra. Ci abbiamo messo le mani, il tempo, il ragionamento minimo necessario per farla stare in piedi.

Ed è questo l’Effetto IKEA applicato alla sicurezza: non diamo valore a una password perché è solida, ma perché l’abbiamo assemblata noi, anche se traballa.

E quando qualcuno ci dice che va cambiata, la prima reazione non è rifarla. È difenderla. O, al massimo, stringere meglio una vite.

Cambia Password (il rito che promette ordine)

A questo punto entra in scena il rito.
Quello che tutti conoscono e nessuno ama: Cambia Password.

Arriva puntuale, come una circolare aziendale o una notifica che non puoi ignorare. Non chiede se la password sia stata compromessa. Non chiede se ci sia stato un problema. Chiede solo di cambiarla. Perché è scaduta. Perché lo dice la policy. Perché si fa così.

E non chiede una password qualsiasi.

• La vuole lunga.
• Con numeri.
• Con simboli.
• Con maiuscole.

Non quelli che vuoi tu, quelli giusti.
E possibilmente abbastanza diversa dalle ultime.

A quel punto la password smette definitivamente di essere una chiave e diventa un oggetto da ricordare. Un peso cognitivo.

Ed è qui che scatta il vero ragionamento, quello che nessuna policy contempla:
“Se devo ricordarmela, allora tanto vale usarla per tutto.”

• Social.
• App.
• Account secondari.
• Il supermercato.

Qualsiasi cosa non sembri vitale in quel momento.

Non lo facciamo per incoscienza, ma per economia.

La password diventa un investimento. Se è complessa, la ammortizzo. Se mi costa memoria, la riuso. E così quella stessa stringa comincia a girare, a depositarsi, a comparire dove non dovrebbe.

Prima o poi finisce in una combolist. Non perché qualcuno abbia colpito il sistema giusto, ma perché l’ho portata io in giro abbastanza a lungo.

E infatti la nostra amata paris…

A quel punto non c’è rito che tenga.
Non è più una password.
È un souvenir digitale.

Il sistema crede di aver introdotto complessità.
La mente ha introdotto superficie di attacco.

E quando un design confonde la fatica con la sicurezza, il risultato non è protezione.
È solo un’altra vite stretta sullo stesso mobile storto.

Prossima puntata

Nella prossima puntata faremo un altro passo avanti.
Lasceremo perdere per un momento le password e guarderemo il problema dal punto di vista del design.

Perché c’è un’idea sbagliata, molto diffusa, secondo cui la sicurezza dovrebbe essere comoda, fluida, invisibile.
E invece funziona quasi sempre al contrario.

Parleremo di attrito, di sistemi che si fanno sentire, di autenticazioni che “rompono le palle” – francesismo improprio, ma dopo paris ce lo possiamo concedere – perché stanno facendo il loro lavoro.

Se finora il problema sembrava l’utente, la prossima volta toccherà chiedersi se non sia il progetto ad aver sbagliato bersaglio.

Parleremo anche di come si può ridurre il peso cognitivo senza abbassare la sicurezza: usando passphrase e costruendo password che funzionano davvero per chi le deve usare.

Continua…

L'articolo La mente e le password: l’Effetto “Louvre” spiegato con una password pessima proviene da Red Hot Cyber.

HackerHood di RHC scopre una privilege escalation in FortiClient VPN

L’analisi che segue esamina il vettore di attacco relativo alla CVE-2025-47761, una vulnerabilità individuata nel driver kernel Fortips_74.sys utilizzato da FortiClient VPN per Windows. Il cuore della problematica risiede in una IOCTL mal gestita che permette a processi user-mode non privilegiati di interagire con il kernel, abilitando una primitiva di scrittura arbitraria di 4 byte.

La falla è stata individuata il 31 gennaio 2025 da Alex Ghiotto, membro della community di Hackerhood. Sebbene la patch correttiva sia stata integrata già a settembre 2025 con il rilascio della versione 7.4.4,

Fortinet ha formalizzato la vulnerabilità solo il 18 novembre 2025 con la pubblicazione del bollettino ufficiale FG-IR-25-112.

Questo caso studio risulta particolarmente interessante per valutare l’efficacia delle moderne mitigazioni di sistema: l’exploit si basa infatti sul reperimento dell’indirizzo kernel del token di processo, un’operazione resa complessa a partire da Windows 11 24H2. In quest’ultima versione, l’accesso a tali informazioni tramite NtQuerySystemInformation richiede ora il privilegio SeDebugPrivilege, innalzando significativamente i requisiti necessari per un attacco efficace da parte di utenti non amministratori.

Analisi Tecnica della CVE-2025-47761

Fortips_74.sys è un driver kernel utilizzato da alcune soluzioni Fortinet, tra cui FortiClientVPN. Nel corso dell’analisi del driver è emersa una vulnerabilità successivamente identificata e corretta come CVE‑2025‑47761. L’obiettivo di questo articolo è descrivere il processo di analisi che ha portato alla sua individuazione e comprenderne le principali implicazioni di sicurezza. La vulnerabilità consente una scrittura arbitraria di 4 byte in un indirizzo controllato dall’utente. Questo comportamento può causare un crash del sistema oppure essere sfruttato per ottenere una completa escalation dei privilegi.

Interagire col Driver

Quando si analizza un driver alla ricerca di una potenziale escalation dei privilegi, la prima domanda fondamentale è: chi può interagirci?
Se anche utenti non privilegiati possono aprire un handle, allora vale la pena approfondire.
In questo caso, il primo passo è osservare chi può interagire con Fortips_74.sys.

Usando WinObj, si nota immediatamente che il driver non imposta permessi restrittivi: questo attira subito l’attenzione.
Una vista più tecnica delle DACL è possibile dal kernel tramite WinDBG

Il driver Fortips_74 crea infatti un device kernel senza definire DACL personalizzate, affidandosi al security descriptor di default. In pratica, qualunque processo nel sistema può aprire un handle verso il driver, compresi quelli a basso livello di integrità (come i processi sandboxati dei browser).
(Su quest’ultimo punto ammetto di non aver effettuato un controllo formale per conferma.)
Analizzando le DACL, risulta che SYSTEM e gli amministratori abbiano accesso completo, ma anche gli altri utenti possono comunque comunicare con il driver, seppur con permessi limitati.
Questo comportamento rende il driver troppo socievole: chiunque può comunicare tramite IOCTL, e in assenza di controlli adeguati il dispatch deve essere gestito in modo estremamente rigoroso per evitare vulnerabilità.

Dispatch delle IOCTL

Prima di entrare nei dettagli specifici del driver Fortips, è utile un breve ripasso.

Le IOCTL (Input/Output Control) permettono ai processi user-mode di inviare comandi specifici ai driver.
In Windows, la funzione DeviceIoControl consente di:

• passare un handle al device
• specificare un codice IOCTL
• fornire buffer di input/output

In sostanza, è il modo per dire:
“Esegui questa operazione con questi dati.”
Analizzando le IOCTL del driver, una in particolare risulta sospetta: 0x12C803.

Questa IOCTL utilizza METHOD_NEITHER, il più pericoloso tra i metodi previsti da Windows: il kernel passa puntatori user‑mode direttamente al driver senza alcuna validazione.
È quindi responsabilità totale del driver verificare:

• validità del puntatore
• accessibilità
• dimensione prevista

Se queste verifiche mancano, l’attaccante può passare puntatori arbitrari, inducendo il driver a leggere/scrivere memoria a cui non dovrebbe accedere.
Tramite questo tool è possibile confermare che il driver utilizza direttamente la IOCTL di tipo METHOD_NEITHER.

Il driver utilizza direttamente il UserBuffer fornito dal chiamante per scrivere l’output, senza alcuna copia o validazione preventiva. Questo significa che un processo user‑mode può passare un puntatore arbitrario, che il driver userà come destinazione dei dati. Senza controlli adeguati, basta un indirizzo malizioso per trasformare un semplice output in una scrittura arbitraria in kernel‑mode, con ovvie implicazioni di sicurezza.

Analisi della funzione vulnerabile

Seguendo il flusso del buffer, la funzione copia il contenuto del buffer user-mode in un buffer locale sullo stack. I primi 24 byte (0x18) vengono interpretati come:

• ULONGLONG Code
• ULONGLONG Size
• ULONGLONG Buffer

Il campo Size non è rilevante in questa catena, mentre Code e Buffer sì.

Per raggiungere il ramo vulnerabile, Code deve essere 0x63.

Dopo la copia preliminare in un buffer locale, il driver salta nella condizione interessata.
A questo punto, uVar7 viene impostato a 4.

Qui si trova il cuore della vulnerabilità:
il driver copia 4 byte da un buffer non inizializzato all’indirizzo specificato dall’utente tramite la IOCTL.
Non vi è alcun controllo o sanitizzazione.
Poiché la sorgente dei dati è stack-junk, la vulnerabilità si traduce in una arbitrary 4-byte write.
Specificando ad esempio l’indirizzo kernel della struttura _TOKEN, è possibile ottenere una privilege escalation.
Nel mio PoC, ho modificato il token per abilitare il privilegio SeDebugPrivilege, quindi ho avviato un cmd come SYSTEM.

Avvio del driver

Per ridurre l’interazione necessaria da parte dell’utente, ho analizzato il meccanismo con cui FortiClient avvia il servizio IPSec.
Il processo principale utilizza una Named Pipe per gestire la comunicazione IPC, inviando un buffer alla pipe
\\Device\\NamedPipe\\FC_{6DA09263-AA93-452B-95F3-B7CEC078EB30}.
All’interno del buffer sono presenti diversi campi, tra cui il nome del tunnel IPSec da inizializzare.Questa chiamata risulta sufficiente ad avviare il driver, anche senza privilegi amministrativi, condizione essenziale per la vulnerabilità.
Nella versione FortiClient VPN 7.4.3.1790 è inoltre possibile creare un profilo IPSec completamente fittizio, utilizzando parametri arbitrari. Nel mio caso, per la fase di test, ho impostato un gateway remoto come “google.it”, un comportamento diverso da quanto indicato da Fortinet nel bollettino ufficiale della CVE.

Proof of Concept

Video Player

Restrizioni

Come già accennato, lo sfruttamento di questa vulnerabilità si basa sulla possibilità di ottenere l’indirizzo kernel del token associato al processo, così da poterne manipolare i privilegi. A partire da Windows 11 24H2 questo non è più possibile da un processo con Integrity Level medio tramite la tradizionale chiamata NtQuerySystemInformation, poiché ora per accedere a tali informazioni è richiesto il privilegio SeDebugPrivilege, normalmente non disponibile agli utenti non amministratori.
Nel mio proof-of-concept ho sfruttato la vulnerabilità [url=https://www.redhotcyber.com/en/cve-details/?cve_id=CVE-2025-53136]CVE-2025-53136[/url], che tramite una race condition consente di ottenere il leak dell’indirizzo del _TOKEN. In questo modo il PoC rimane funzionante fino alla correzione della vulnerabilità prevista per gli aggiornamenti di agosto/settembre 2025.
Al di fuori di questo caso specifico, per sfruttare la vulnerabilità su un sistema completamente aggiornato sarebbe necessario disporre di un ulteriore bug in grado di fornire il leak dell’indirizzo richiesto, poiché le protezioni introdotte nel nuovo kernel impediscono di ottenerlo direttamente.

Timeline

• 31-01-2025: Vulnerabilità segnalata al PSIRT di Fortinet.
• 19-02-2025: Vulnerabilità confermata dal PSIRT di Fortinet.
• 09-05-2025: Fortinet dichiara di aver risolto il problema assegnando CVE-2025-47761.
• 18-11-2025: Fortinet pubblica sul PSIRT il bollettino riguardante la CVE.

L'articolo HackerHood di RHC scopre una privilege escalation in FortiClient VPN proviene da Red Hot Cyber.

"La complicata anima di #Torino.
Ogni città ha una sua magia impenetrabile, che si rivela attraverso l’arcano di apparenti contraddizioni.
Torino nel suo umore profondo, sta reagendo infastidita a quella che viene percepita, ogni giorno di più, come una pesante intrusione militarizzata motivata dallo sgombero di Askatasuna.
Ma è anche la stessa Torino che non ha sopportato l’azione vandalica contro il quotidiano La Stampa, considerato un simbolo. Pur non sempre amandolo.
Questa città non tollera vedere sfregiati i suoi simboli, ma allo stesso tempo non li ostenta e sembra non curarsene più di tanto.
Non è mai una città allineata: non è stata fascista: Mussolini la chiamava “la porca città”. Non è stata biologicamente democristiana, comunista, craxiana, leghista, berlusconiana ma nemmeno moderata, perchè sempre attraversata da tensioni profonde.
Reagisce alla montatura mediatica sull’Immam Shanin, con il tono di chi rifiuta le sciatte e triviali dinamiche che regolano oggi il dibattito d’opinione in Italia.
Si mobilità quando si sente violata, ma non si lascia semplificare da uno slogan.

È un luogo difficile da capire e anche da amare. Ma tutti coloro che pensano di applicare qui, forzatamente, regole di funzionamento che altrove sembrano offrire facili risultati…restano con niente in mano. Senza mai capire perchè."
Subsonica.

L'operazione di sgombero del centro sociale Askatasuna ha, di fatto, isolato militarmente un quartiere. È avvenuto dopo la nomina di un nuovo prefetto, organizzata con il rinforzo di 300 agenti dal resto d'Italia. È una macchia nera nel cielo di Torino.

@piemonte