The Gentlemen rivendica Abaco Viaggi: nuova vittima italiana sul leak site del gruppo ransomware

Il gruppo ransomware The Gentlemen ha inserito Abaco Viaggi nel proprio sito di divulgazione dati. Ransomfeed ha registrato la rivendicazione la sera del 7 settembre 2026 (ore 21:51, scheda 35801), indicando come dominio colpito abacoviaggi.it; Ransomware.live la riporta alla stessa ora UTC e indica come data stimata dell’attacco lo stesso 7 settembre, che coincide però con il giorno della pubblicazione sul leak site e non documenta quando sia avvenuta l’intrusione. Al momento non risultano conferme da parte della società, di ACN o di CSIRT Italia: il caso va trattato come rivendicazione criminale, non come compromissione accertata.

Chi è la vittima indicata

Il dominio abacoviaggi.it è quello delle caselle di posta delle agenzie di Abaco Viaggi S.r.l., tour operator specializzato in viaggi di gruppo con accompagnatore dall’Italia. Secondo il sito ufficiale, la società ha sede legale a Codroipo (Udine), in Piazza Garibaldi 44, e sede operativa in Via Italia 30 nello stesso comune; partita IVA 02902530274, capitale sociale di 50.000 euro, iscrizione REA UD-233689. I punti vendita si trovano a Codroipo, Udine, Fiume Veneto, San Michele al Tagliamento e Portogruaro. Ufficio Camerale, che precisa di non attingere direttamente al Registro Imprese, riporta 45 dipendenti e un fatturato 2024 di circa 28,6 milioni di euro.

La scheda pubblicata dagli attaccanti descrive invece un’agenzia “fondata nel 1997 a Bologna”, con una partita IVA diversa. Nessun registro pubblico consultato conferma l’esistenza di una società con quei dati; l’unico elemento oggettivo del post resta il dominio, che rimanda all’azienda friulana. All’8 settembre la home page di Abaco Viaggi non riporta alcuna comunicazione sull’incidente.

Cosa sostengono gli attaccanti

Nel post il gruppo afferma di aver scaricato dati personali riservati e informazioni sui clienti, documenti finanziari e contabili, corrispondenza commerciale e documenti legali, e-mail, informazioni sull’infrastruttura IT, accessi e credenziali. È una dichiarazione di parte, che nessun soggetto indipendente ha verificato. Il post non indica la data dell’incidente né la quantità di dati; non sono noti il vettore iniziale e l’eventuale cifratura dei sistemi.

Chi è The Gentlemen

The Gentlemen è un’operazione ransomware-as-a-service comparsa a metà 2025. Microsoft traccia gli operatori come Storm-2697: il gruppo è nato come operazione chiusa e ha aperto il programma agli affiliati nel settembre 2025. Secondo Halcyon e Blackpoint, il nucleo operava in precedenza con il nome ArmCorp come affiliato di Qilin; la separazione è stata resa pubblica il 22 luglio 2025 con una disputa su circa 48.000 dollari di commissioni non pagate, mentre il primo campione del malware era comparso su VirusTotal il 17 luglio.

La crescita è stata rapida. Unit 42 riporta 580 vittime in 77 paesi al 7 luglio 2026, con un picco di 117 rivendicazioni nel solo mese di giugno. Comparitech, al 20 agosto, contava 675 attacchi dall’estate 2025, di cui 600 nei primi sette mesi del 2026: una media di 2,8 al giorno, seconda solo a Qilin. Il gruppo cede agli affiliati il 90% di ogni riscatto, contro il 70-80% dei programmi concorrenti, e nel maggio 2026 ha annunciato un accordo con BreachForums per reclutare affiliati, penetration tester e broker di accessi iniziali. Un modello di affiliazione aggressivo accomuna The Gentlemen ad altre sigle recenti, come Panzer ransomware, che ha colpito due aziende italiane nelle scorse settimane.

Gli operatori praticano la doppia estorsione: cifrano i dati e li esfiltrano, minacciandone la pubblicazione. Secondo l’analisi Microsoft del 28 maggio 2026, la variante Windows è scritta in Go, cifra ogni file con una chiave distinta e include un modulo di autopropagazione che tenta 21 diverse operazioni di esecuzione remota su ogni host raggiungibile. Halcyon indica come vettore d’accesso principale CVE-2024-55591, un bypass di autenticazione in FortiOS e FortiProxy. Nel maggio 2026 il gruppo ha subito a sua volta una violazione del proprio backend, con esposizione di chat interne, dati sugli affiliati e trascrizioni delle trattative; secondo Blackpoint l’attività è ripresa dopo la ricostruzione dell’infrastruttura. Le fasi di ricognizione, movimento laterale e disattivazione delle difese seguono lo schema del ransomware human-operated, in cui l’intrusione è condotta manualmente prima della cifratura.

Il contesto italiano

Nel 2026 The Gentlemen è una presenza costante negli elenchi delle vittime italiane. Il motore di ricerca di Ransomfeed, interrogato l’8 settembre, restituisce 21 rivendicazioni del gruppo contro organizzazioni con sede in Italia tra il 4 aprile e il 30 agosto: tra le più recenti, General Gruppo ed Exacta Optech Labcenter (30 agosto), Ariel Energia (21 agosto), ACLI e IPS (14 agosto) e cinque aziende pubblicate nella stessa mattinata del 7 agosto, tra cui il produttore HIWIN. Comparitech, con un criterio di conteggio diverso, attribuisce al gruppo 18 attacchi in Italia tra gennaio e luglio, di cui uno solo confermato dalla vittima, proprio HIWIN.

Abaco Viaggi non figura in quell’elenco: nella scheda Ransomfeed i campi paese, settore e dati pubblicati sono vuoti, quindi la rivendicazione non compare a chi filtra per Italia. È un dettaglio operativo utile a chi monitora le minacce nazionali con strumenti automatici: una vittima italiana può restare fuori dai conteggi finché la classificazione non viene corretta.

Cosa aspettarsi

Fino a una comunicazione della società o a una segnalazione istituzionale il caso resta una rivendicazione non confermata. Check Point Research osserva che, di norma, i leak site elencano le vittime che non hanno pagato: il numero reale di organizzazioni colpite è quindi superiore a quello pubblicato. Se l’incidente fosse confermato, il titolare dovrebbe notificarlo al Garante entro 72 ore dal momento in cui ne viene a conoscenza (art. 33 GDPR) e, in caso di rischio elevato per gli interessati, comunicarlo direttamente ai clienti (art. 34).

https://www.ictsecuritymagazine.com/cybercrime/the-gentlemen-ransomware-abaco-viaggi/




Manchester Airports Group Data on 8.8 Million People Leaked After Ransom Refusal

Hacker group published roughly 550GB of data after MAG reportedly refused to pay a ransom demand; the group says it gained access via exposed admin keys.

The post Manchester Airports Group Data on 8.8 Million People Leaked After Ransom Refusal appeared first on SecurityWeek.

https://www.securityweek.com/manchester-airports-group-data-on-8-8-million-people-leaked-after-ransom-refusal/




153 Million Driver License Images Offered on Dark Web

Cybercriminals are offering digital scans of US and Canadian driver’s licenses, likely stolen from IDScan.net.

The post 153 Million Driver License Images Offered on Dark Web appeared first on SecurityWeek.

https://www.securityweek.com/153-million-driver-license-images-offered-on-dark-web/




Prova digitale e anti-forensics: cosa cambia con l’AI generativa

L’adozione di sistemi di intelligenza artificiale generativa sta producendo una trasformazione profonda nel modo in cui il diritto processuale penale interpreta, valuta e utilizza la prova digitale. Ciò che per anni è stato considerato un elemento relativamente stabile e verificabile ovvero il dato digitale come traccia dell’origine di un evento o di un’azione entra oggi in una fase di progressiva instabilità epistemica. La possibilità di generare contenuti artificiali altamente coerenti, completi di metadati plausibili e strutture tecniche formalmente corrette, incrina infatti uno dei presupposti storici della digital forensics: la corrispondenza tra traccia e origine.

Questo articolo si inserisce all’interno della serie di approfondimenti a cura di Cosimo de Pinto dal titolo “Quando l’AI mente bene – Deepfake, prova digitale e anti-forensics nel processo penale”. L’approfondimento analizza la frattura introdotta dall’AI generativa nel paradigma tradizionale della prova informatica, evidenziando come la “plausibilità sintetica” possa sostituirsi alla tracciabilità dell’origine come criterio implicito di affidabilità.

Nel testo si esamina la discontinuità tra anti-forensics classica e nuove tecniche abilitate dall’intelligenza artificiale, mettendo in luce il passaggio da strategie di occultamento o distruzione della prova a sistemi capaci di costruire evidenze artificiali credibili e difficilmente distinguibili da quelle autentiche. L’analisi si concentra inoltre sulle implicazioni processuali di tale evoluzione, con particolare attenzione ai rischi per la valutazione giudiziale della prova digitale e alle possibili ricadute sulla presunzione di innocenza e sulla libertà personale.

La fine dell’innocenza digitale

L’AI generativa incrina il presupposto che la prova digitale rifletta sempre la propria origine.

La digital forensics si è sviluppata, nel corso dei suoi tre decenni di storia disciplinare, attorno a un presupposto implicito: i dati digitali conservano tracce della propria origine, e tali tracce possono essere estratte, interpretate e presentate come prova con ragionevole certezza scientifica. Un file aveva una biografia verificabile: nasceva in un momento preciso, recava l’impronta del software che lo aveva generato, i metadati del sistema operativo, le impronte dell’hardware. Su questo fondamento, ben descritto nella manualistica di riferimento, si è costruita l’intera architettura processuale della prova digitale nei sistemi giuridici occidentali.

Dal paradigma classico alla frattura epistemica

Computer forensics classica Scenario AI generativa
Presupposto di base Le tracce digitali riflettono l’origine del dato Un contenuto può simulare un’origine credibile
Obiettivo dell’analisi Ricostruire eventi e attribuire provenienza Verificare anche la possibilità di un’origine sintetica
Segni di manipolazione Spesso lasciano anomalie residue Possono imitare pattern statisticamente plausibili
Ruolo dell’esperto Interpretare tracce e coerenze tecniche Corroborare, autenticare e contestualizzare
Rischio giuridico Errore tecnico circoscritto Potenziale violazione della libertà personale

L’avvento dei modelli generativi di intelligenza artificiale, in particolare dei Large Language Models (LLM), dei modelli text-to-image, dei sintetizzatori vocali neurali e dei sistemi di video synthesis, ha introdotto nella catena della prova digitale una variabile che i framework forensi tradizionali non erano stati progettati per gestire: la plausibilità sintetica. Un documento, un’immagine, una registrazione audio o video possono oggi essere generati artificialmente in modo da superare non soltanto la percezione umana, ma anche una parte significativa delle analisi strumentali disponibili ai laboratori forensi. Come osservato dalla letteratura tecnica più recente, gli avversari non si limitano più a nascondere le prove: le costruiscono, le avvelenano e orientano l’investigatore verso una narrazione falsa.

Le conseguenze di questa trasformazione non sono confinabili all’ambito tecnico. Nei procedimenti penali, ogni errore nella valutazione di una prova digitale si traduce in una potenziale violazione della libertà personale. Un soggetto innocente può essere condannato sulla base di una conversazione WhatsApp mai avvenuta, di un’immagine fotografica manipolata, di un video che lo mostra in un luogo in cui non si è mai recato, di un log di sistema artatamente costruito per collocarlo in prossimità di un reato. L’AI non mente come un essere umano: produce output statisticamente coerenti, difficili da smascherare con gli strumenti tradizionali, e capaci di ingannare persino analisti esperti.

Ogni errore nella valutazione di una prova digitale si traduce in una potenziale violazione della libertà personale.

Il presente paper analizza le intersezioni tra AI generativa, tecniche di anti-forensics e il concetto giuridico di prova digitale, con attenzione alle implicazioni pratiche per consulenti tecnici, avvocati e magistrati. Vengono esaminate le principali superfici di attacco, le tecniche di evasione forense abilitate dall’AI, i framework di auditabilità esistenti, le lacune normative che rendono urgente un ripensamento del valore probatorio del dato digitale e, soprattutto, i rischi concreti per la libertà delle persone che derivano da un approccio acritico all’impiego dell’AI in sede processuale.

Metodo, contributo e domanda di ricerca

Metodo. Sintesi critica interdisciplinare che incrocia letteratura peer-reviewed, casi documentati, standard normativi e implicazioni processuali della prova digitale nell’era dell’AI generativa.

Contributo. Un quadro di sintesi tra tecnica di attacco, artefatto colpito, contromisure e rischio residuo; ricostruzione del nesso tra auditabilità tecnica e tenuta probatoria; proposta di principi guida per una digital forensics AI-resistant.

Domanda di ricerca. In che modo l’AI generativa trasforma la natura della prova digitale e quali condizioni metodologiche e giuridiche sono necessarie per conservarne l’affidabilità?

Questo paper affronta una delle sfide più critiche e meno sistematizzate dell’attuale panorama della sicurezza informatica applicata al diritto: l’impatto dell’intelligenza artificiale generativa sull’affidabilità delle prove digitali nei procedimenti penali. Non si tratta di uno scenario futuro. Le tecniche qui analizzate (data poisoning, log crafting, PRNU manipulation, deepfake, voice cloning, evasion attacks) sono operative già oggi, e i loro effetti sul sistema giustizia sono documentabili. Il taglio è deliberatamente duplice, tecnico e giuridico, perché duplice è il pubblico cui il problema si rivolge: professionisti della sicurezza, consulenti tecnici d’ufficio e di parte, magistrati e avvocati che si trovano a maneggiare prove digitali la cui affidabilità non può più essere data per scontata.

Sul piano del metodo, il lavoro è una sintesi critica di taglio interdisciplinare. Sul versante tecnico incrocia la letteratura peer-reviewed su anti-forensics e adversarial machine learning con casi documentati di rilevanza processuale o geopolitica; sul versante giuridico procede a un’analisi dottrinale e giurisprudenziale del diritto della prova, ancorata alla normativa italiana ed europea vigente e agli standard tecnici internazionali della famiglia ISO/IEC 27000. Le fonti sono state selezionate privilegiando, ove disponibili, gli atti originali (paper, whitepaper, testi normativi, massime ufficiali) rispetto alle fonti secondarie.

Per onestà epistemica, ogni affermazione tecnica viene qualificata secondo tre gradi di evidenza, esplicitati nel testo: risultato dimostrato sperimentalmente in letteratura; condotta documentata in un caso reale; rischio metodologico emergente, ipotizzato in via teorica ma non ancora consolidato in giudicato.

Il contributo originale è triplice: un quadro di sintesi che mette in relazione ciascuna tecnica di attacco con l’artefatto forense colpito, la contromisura di rilevazione e il rischio residuo (sezione 5); un raffronto comparato tra l’ordinamento italiano e il modello angloamericano (sezione 7); e un framework forense resistente all’AI articolato in cinque principi operativi e quattro proposte normative (sezione 10). La domanda di ricerca che tiene insieme l’intero discorso è la seguente: a quali condizioni una prova digitale generata o mediata da sistemi AI può fondare un giudizio di responsabilità penale senza violare la presunzione di innocenza e il diritto a un equo processo?

Anatomia dell’anti-forensics tradizionale e la discontinuità dell’AI

Dalle tecniche che cancellano le tracce a un’AI che le costruisce: una rottura qualitativa, non solo quantitativa.

L’anti-forensics prima dell’AI

La disciplina dell’anti-forensics, intesa come l’insieme delle tecniche volte a ostacolare, fuorviare o rendere impossibile l’analisi forense di un sistema digitale, è quasi coeva alla nascita della computer forensics stessa. Harris la definisce come qualsiasi tentativo di compromettere la disponibilità o l’utilità delle prove in un processo forense.

Le tecniche classiche si articolano in quattro categorie principali:

  • distruzione dei dati (data destruction) tramite sovrascrittura multipla secondo lo standard DoD 5220.22-M, degaussing o distruzione fisica del supporto;
  • occultamento dei dati (data hiding) mediante steganografia, cifratura di volumi interi (VeraCrypt, BitLocker) e slack space exploitation;
  • trail obfuscation mediante applicazioni portable, timestamp manipulation (Timestomp) e cancellazione selettiva dei log di sistema;
  • attacchi alla capacità di analisi attraverso exploit nei tool forensi (FTK, EnCase, Autopsy), file artatamente costruiti (crafted) e tecniche anti-VM e anti-sandbox.

La caratteristica comune di queste tecniche è che esse lasciano tracce della propria applicazione: assenza dove dovrebbe esserci presenza, anomalie statistiche, pattern inusuali. In questa prospettiva, la forensics tradizionale lavora spesso sulla deviazione rispetto all’atteso: l’anti-forensics classica mirava a cancellare, occultare o rendere non interpretabile l’evidenza. Nell’ecosistema AI la logica cambia radicalmente.

La discontinuità dell’AI: quando l’assenza non fa rumore

L’AI generativa introduce una rottura epistemica nel paradigma descritto. Il problema non è produrre contenuti falsi: è produrre contenuti coerenti con le aspettative statistiche di un analista forense. Un LLM avanzato istruito a generare la trascrizione di una conversazione WhatsApp produrrà testo con le peculiarità linguistiche del presunto autore, con riferimenti contestualmente plausibili e struttura temporale coerente; se integrato con un generatore di metadati, produrrà file con timestamp consistenti, encoding corretto, struttura interna del database SQLite di WhatsApp formalmente valida.

La differenza rispetto all’anti-forensics tradizionale è qualitativa, non soltanto quantitativa: non si tratta necessariamente di un’anti-forensics più efficiente, ma di una crisi del concetto stesso di autenticità digitale. Il bersaglio reale diventa ciò che il modello vede: dati, log, metadati, timestamp, immagini, testo, prompt, contesto RAG, workflow, plug-in, API e catena software. L’AI non mente in senso umano; produce un output coerente rispetto all’input e al contesto che riceve. Se input e contesto sono manipolati, la conclusione può essere tecnicamente elegante e probatoriamente falsa.

L’AI non mente in senso umano; produce un output coerente rispetto all’input e al contesto che riceve.

L’approfondimento ha mostrato come l’AI generativa stia alterando in modo strutturale il concetto stesso di prova digitale, spostando l’attenzione dalla tracciabilità dell’origine alla plausibilità sintetica del contenuto. Questo passaggio segna una discontinuità profonda per la digital forensics e apre scenari in cui la distinzione tra dato autentico e dato costruito diventa sempre più complessa da stabilire, con conseguenze dirette sul piano processuale e sulla tutela della libertà personale.

Il prossimo articolo approfondirà le principali tecniche anti-forensics assistite dall’AI insieme alle nuove superfici di attacco lungo la catena della prova digitale, dai documenti alle comunicazioni fino al codice generato automaticamente.

Per un inquadramento più completo e sistematico, è possibile approfondire il paper di Cosimo de Pinto “Quando l’AI mente bene – Deepfake, prova digitale e anti-forensics nel processo penale”: la lettura consente di comprendere in modo organico le dinamiche tra attacco, prova digitale e rischio probatorio, offrendo un riferimento utile sia per l’analisi tecnica sia per l’applicazione nel contesto processuale.

 

https://www.ictsecuritymagazine.com/articoli/prova-digitale/




Belarusian Ransom Cartel Mastermind Gets 16 Years in Prison

The Belarusian creator and administrator of the Ransom Cartel ransomware was sentenced to 16 years in prison in the US.

Maksim Silnikau, 40, built the ransomware operation and recruited other individuals through cybercrime forums, according to documents presented in court.

Silnikau provided Ransom Cartel conspirators with stolen credentials and other information on compromised computers, as well as with tools to encrypt those systems.

Additionally, the court documents show, he maintained a hidden website used to manage and monitor ransomware attacks, communicate with other conspirators and with victims, and manage the distribution of funds between participants.

Between 2021 and 2023, Ransom Cartel targeted at least 18 organizations in the US and abroad, stealing victims’ data and demanding monetary payments in exchange for decryption keys or the promise not to publish the stolen information.

According to the documents presented in court, the Ransom Cartel operation was disrupted when Silnikau was arrested in 2023.

Advertisement. Scroll to continue reading.

In a separate case, Silnikau was charged with participating in the distribution of Angler (a notorious exploit kit disrupted in 2016 that was widely used for the deployment of malware) and of other malware and online scams.

Together with Volodymyr Kadariya, a Belarusian and Ukrainian national, and Andrei Tarasov, a Russian national, Silnikau allegedly distributed malware and other threats through malvertising and other means between 2013 and 2022.

Silnikau was arrested in Spain and extradited to the US in 2024 from Poland. Tarasov was arrested in Germany, but was released after six months and returned to Russia. In 2024, the US posted a $2.5 million reward for information on Kadariya.

On August 5, Silnikau was sentenced to 16 years for conspiracy to commit offenses against the US, wire fraud conspiracy, and aggravated identity theft.

Related: Two Scattered Spider Hackers Sentenced to Jail in UK

Related: Alleged Scattered Spider Hacker Extradited to US

Related: Google, FBI Disrupt NetNut Residential Proxy Network Powered by Millions of Devices

Related: Microsoft and Allies Smash Shared Infrastructure of Amadey and StealC Malware

https://www.securityweek.com/belarusian-ransom-cartel-mastermind-gets-16-years-in-prison/




ServiceNow, la RCE pre-autenticazione CVE-2026-6875 è sfruttata in the wild: istanze self-hosted da mettere in sicurezza

Una vulnerabilità critica nella piattaforma AI di ServiceNow consente a un attaccante non autenticato di eseguire codice da remoto e prendere il controllo dell’istanza. Identificata come CVE-2026-6875
, è passata dalla pubblicazione del proof of concept tecnico ai primi payload osservati in rete in circa 72 ore, e la finestra di esposizione per chi gestisce ambienti self-hosted resta aperta.

Il perimetro non è marginale. ServiceNow dichiara di elaborare oltre 100 miliardi di workflow l’anno e di alimentare più di 100.000 applicazioni AI enterprise presso l’85 per cento delle aziende Fortune 500: la superficie interessata è quella dei processi di IT service management, workflow e automazione su cui poggiano interi reparti IT, e il raggio d’azione di un singolo exploit riuscito è proporzionale.

La catena tecnica di CVE-2026-6875: dall’iniezione all’esecuzione di codice

La ricerca è firmata da Assetnote, il team di attack surface management di Searchlight Cyber, che l’ha documentata nel report Smashing the ServiceNow Sandbox. Il punto di ingresso è la GlideRecord
query API, l’interfaccia con cui centinaia di percorsi applicativi recuperano dati dalle tabelle. In diversi punti raggiungibili prima dell’autenticazione, l’input dell’utente arriva fino alla query senza sanitizzazione.

Il primo trucco sfrutta una funzione documentata: anteponendo javascript:
a un valore, ServiceNow valuta la stringa come JavaScript prima di usarla come argomento di query. Ogni sink non autenticato diventa così un potenziale punto di esecuzione di script. La piattaforma anticipava questo scenario con un secondo strato di isolamento, lo script sandbox, che blocca eval
, limita le classi Java accessibili e rende le tabelle in sola lettura per gli utenti non autenticati.

L’elemento centrale della ricerca è l’evasione di quello strato. Sovrascrivendo Object.clone
con il costruttore Function
e assegnando AbstractAjaxProcessor.prototype
al payload dell’attaccante, una successiva chiamata a gs.include('ItemViewElementsProvider')
induce la sandbox a invocare Function(payload)
in un contesto privo di restrizioni: il risultato è una funzione eseguibile che lancia codice arbitrario. Il sink pre-autenticazione effettivamente raggiungibile è l’endpoint /assessment_thanks.do
, tramite il parametro sysparm_assessable_type
, che passa l’input direttamente nella query. Da lì, spiega il report, si possono estrarre dati da qualunque tabella, creare utenti amministratori a piacere ed eseguire comandi sui MID Server proxy configurati, spesso collocati all’interno delle reti aziendali.

La vulnerabilità, un sandbox escape nella piattaforma AI, è valutata 9,5 su 10, severità critica. Come sempre nei sistemi che introducono un rischio di questo tipo attraverso AI e automazione, l’esposizione dipende anche dai privilegi concessi agli agenti che operano nella piattaforma, un tema già affrontato analizzando la identity security degli agenti.

Tempistiche: cloud protetto ad aprile, patch self-hosted da giugno

La cronologia aiuta a inquadrare il rischio residuo. Assetnote ha segnalato il difetto a ServiceNow il 1° aprile 2026; il vendor ha applicato una mitigazione lato cloud entro 24 ore, bloccando la modifica delle funzioni JavaScript chiave. Per i clienti e i partner self-hosted le patch e gli aggiornamenti di sicurezza sono stati resi disponibili nel corso di giugno, come precisato da Help Net Security in una rettifica esplicita; il 13 luglio ServiceNow ha poi pubblicato l’advisory ufficiale (
KB3137947
), consolidando la comunicazione pubblica, e il giorno seguente Searchlight ha diffuso i dettagli tecnici, con un proof of concept finito pubblico.

Le correzioni risultano incluse in Brazil EA e GA, Australia Patch 2, Zurich Patch 7b e Patch 9, Yokohama Patch 12 Hot Fix 1b e Patch 13. Chi ha già ricevuto la mitigazione cloud è coperto; il punto critico riguarda le organizzazioni che gestiscono ServiceNow in casa e non hanno ancora applicato gli aggiornamenti disponibili, a prescindere dalla data esatta di prima distribuzione.

Lo sfruttamento è già in corso

I primi tentativi di sfruttamento sono stati osservati venerdì 17 luglio; la conferma pubblica è arrivata il giorno successivo, quando la società di threat intelligence Defused ha documentato lo sfruttamento in the wild, rilevando payload che colpiscono lo stesso sink pre-autenticazione documentato da Searchlight, /assessment_thanks.do
, ma raggiungono l’esecuzione di codice attraverso una diversa gadget chain. Il quadro è riportato anche da Security Affairs.

Non è la prima volta che ServiceNow si trova in questa posizione. Nel luglio 2024 la critica CVE-2024-4879
, anch’essa individuata da Assetnote, fu sfruttata contro oltre 105 organizzazioni tra agenzie governative, aziende energetiche e software house entro pochi giorni dalla pubblicazione di un writeup tecnico, con dati finiti su forum criminali e successivo inserimento nel catalogo Known Exploited Vulnerabilities della CISA il 29 luglio 2024; lo documentano i rilievi di Resecurity, ripresi da BleepingComputer e TechTimes. Il ritardo tra disponibilità della correzione e adozione è quindi un rischio concreto, non teorico.

Vale la pena segnalare una tensione: l’advisory di ServiceNow, al momento, continua a dichiarare di non aver riscontrato prove che l’attività sia legata alle istanze che ospita. La rilevazione indipendente di attività ostile mentre la comunicazione ufficiale non la registra ancora è un elemento che i team di sicurezza dovrebbero pesare nella propria valutazione del rischio, senza attendere una conferma dal fornitore per agire.

Per chi amministra istanze self-hosted, l’indicazione operativa è diretta: applicare gli aggiornamenti disponibili come intervento urgente, verificare gli accessi ai /assessment_thanks.do
nei log e trattare come sospetta la creazione di nuovi utenti amministrativi o l’esecuzione di comandi sui MID Server. Sul piano più ampio, la vicenda ribadisce che l’estensione delle piattaforme aziendali verso funzioni agentiche moltiplica i sink raggiungibili e i percorsi di escape, una dinamica già osservata con la prompt injection negli agenti sulla stessa classe di prodotti.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/servicenow-cve-2026-6875-rce-sfruttata/




wp2shell, la RCE pre-autenticazione che rimette in discussione il WordPress Core

Una vulnerabilità critica nel cuore di WordPress consente a un attaccante anonimo di eseguire codice da remoto su un’installazione standard, senza credenziali, senza plugin e senza interazione della vittima. La falla, battezzata wp2shell dai ricercatori di Searchlight Cyber (divisione Assetnote) che l’hanno scoperta, colpisce il core della piattaforma che, secondo la stessa società, sostiene oltre 500 milioni di siti nel mondo. WordPress ha rilasciato le correzioni il 17 luglio 2026 e ha attivato gli aggiornamenti forzati; una scala di esposizione di questa portata impone una verifica immediata a chiunque gestisca un sito pubblico, dalla PA alle testate ai siti aziendali.

Nota di trasparenza sulla freschezza: la prima pubblicazione risale alla sera del 17 luglio 2026 (advisory Searchlight alle 19:10 UTC, release WordPress e GitHub Security Advisory in pari data), quindi appena fuori dalla finestra stretta delle sei ore ma nettamente all’interno delle ultime 24. È la storia dominante del ciclo e il rischio è in evoluzione: nelle prime ore del 18 luglio è comparso un primo proof-of-concept pubblico (vedi sotto), motivo in più per selezionarla segnalando in chiaro i timestamp.

Cosa è, tecnicamente

wp2shell non è un singolo bug ma una catena. Il remote code execution pre-autenticazione è tracciato come CVE-2026-63030
e nasce da una route confusion sull’endpoint /wp-json/batch/v1
delle REST API: la logica che smista le richieste batch può essere indotta a raggiungere percorsi non previsti. A valle si innesta una SQL injection, CVE-2026-60137
, nel parametro author__not_in
di WP_Query
, la classe che costruisce quasi ogni query verso il database. La combinazione dei due difetti porta dall’accesso anonimo all’esecuzione di codice.

Attenzione al disallineamento nei riferimenti: diversi tracker etichettano l’intera catena come la sola CVE-2026-63030
, che è però l’identificativo della sola route confusion. I due Security Advisory ufficiali mappano con precisione difetti e scopritori: la route confusion nella batch API (
CVE-2026-63030
, GHSA-ff9f-jf42-662q
, gravità Critical) è stata trovata da Adam Kues di Assetnote e Searchlight Cyber; la SQL injection nel parametro author__not_in
di WP_Query
(
CVE-2026-60137
, GHSA-fpp7-x2x2-2mjf
, gravità Moderate) è stata segnalata in team da TF1T, dtro e haongo. Non esiste un terzo difetto: la RCE nasce dalla combinazione dei due e la seconda metà della catena non è opera di Searchlight, ma del secondo gruppo. Chi mappa l’esposizione tenga conto di entrambi gli identificativi.

Un elemento operativo utile arriva da Cloudflare, citata nell’analisi di Rapid7: il percorso vulnerabile risulta raggiungibile quando non è attiva una persistent object cache, condizione che riguarda molte installazioni predefinite ma non tutte.

Versioni colpite e correzioni

Il GitHub Security Advisory GHSA-ff9f-jf42-662q
circoscrive la RCE CVE-2026-63030
alle versioni 6.9.0
–
6.9.4
e 7.0.0
–
7.0.1
; le release precedenti alla 6.9
non sono esposte alla route confusion. La SQL injection CVE-2026-60137
risale invece al ramo 6.8
e copre 6.8.0
–
6.8.5
, 6.9.0
–
6.9.4
e 7.0.0
–
7.0.1
. Le correzioni sono in WordPress 7.0.2, nella backport 6.9.5
, nella 6.8.6
e nella 7.1 Beta 2
. Qui sta la ragione per cui il ramo 6.8
riceve solo una patch parziale: la 6.8.6
chiude la sola SQL injection, classificata Moderate, mentre la catena RCE Critical non lo tocca, non essendo presente su quel ramo la route confusion. WordPress.org ha forzato l’aggiornamento automatico sulle installazioni interessate; resta da verificare manualmente ogni sito esposto, perché hosting con auto-update disabilitato o deploy sotto controllo di versione possono restare scoperti.

Sul punteggio conviene essere precisi: l’advisory GitHub classifica la gravità come Critical sul piano qualitativo, mentre il CVSS numerico finora assegnato è 7.5, come segnala Rapid7. La divergenza tra etichetta e punteggio riflette metriche e contesti diversi; per la prioritizzazione pesa più la superficie (esecuzione di codice senza autenticazione su una piattaforma ubiqua) del numero isolato.

Sfruttamento e mitigazioni

La sera del 17 luglio, alla pubblicazione degli advisory, non circolava alcun proof-of-concept pubblico: Searchlight aveva volutamente omesso i dettagli tecnici per dare tempo alle patch, rilasciando solo un servizio di verifica dell’esposizione. La finestra si è però chiusa in poche ore. Nelle prime ore del 18 luglio è comparso su GitHub un PoC (repository Icex0/wp2shell-poc
), affiancato da uno strumento di detection che sfrutta la SQL injection di tipo time-based. La sfumatura conta, per non esagerare in senso opposto: non risulta ancora sfruttamento confermato in-the-wild, e il PoC pubblico dimostra l’injection e la lettura del database, inclusi gli hash delle password degli amministratori, ma non l’esecuzione di codice completa. Il salto finale dalla SQL injection alla RCE, che richiede di craccare un hash recuperato e caricare un plugin, non è stato pubblicato da Searchlight. Rapid7 aveva previsto un PoC in tempi brevi e i tempi brevi si sono rivelati poche ore: conferma di quanto la finestra tra disclosure e weaponizzazione si stia comprimendo, come già discusso a proposito della crisi della patch management su queste pagine.

La contromisura efficace è l’aggiornamento. Come misura d’emergenza temporanea, e solo in attesa della patch, Searchlight indica il blocco dell’accesso anonimo alla batch API, filtrando a livello di WAF /wp-json/batch/v1
e ?rest_route=/batch/v1
oppure installando un plugin che chiuda le REST API agli utenti non autenticati. Entrambe le opzioni hanno un costo: possono rompere integrazioni e funzionalità legittime che usano quell’endpoint, ragione per cui Rapid7 sconsiglia i workaround e raccomanda di correggere direttamente. Chi è dietro un WAF gestito ha una copertura parziale già disponibile: Cloudflare ha distribuito regole in concomitanza con la disclosure e Wordfence ha rilasciato una regola firewall il 17 luglio. La dinamica di sfruttamento di massa di una piattaforma diffusissima ricorda, per portata, la campagna ToolShell su SharePoint, con la differenza che qui il bersaglio è il web pubblico nella sua parte più capillare.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/wordpress-core-wp2shell-rce/




OkoBot: il framework modulare che carpisce le seed phrase da dentro Ledger Live e Trezor Suite

Il team GReAT di Kaspersky ha documentato nel report di Securelist OkoBot, un framework malevolo composto da oltre venti moduli che colpisce gli utenti di criptovaluta su Windows. La catena di attacco è stata ridisegnata a fine aprile 2025; la telemetria sulle vittime copre il periodo aprile 2025-giugno 2026 e GReAT ne ha identificato gli attacchi a gennaio 2026. La campagna è attiva da oltre un anno ed è tuttora in corso, con centinaia di vittime in più di venticinque Paesi, concentrate in Brasile, Vietnam, Canada, Messico e Turchia. Secondo Dmitry Galov (GReAT), citato nel comunicato di Kaspersky, i vettori osservati indicano gli sviluppatori tra i bersagli primari: un dettaglio che sposta la vicenda dal solo furto di criptovaluta al rischio d’ingresso in ambienti aziendali.

Vettori d’ingresso: repository GitHub fasulli e ClickFix

Il primo canale è la tecnica ClickFix, che induce la vittima a incollare ed eseguire comandi apparentemente innocui. Il secondo è più raffinato: un repository GitHub esistito da fine marzo 2025 a giugno dello stesso anno, composto dal solo README.md
con una finta guida d’installazione in stile ufficiale, indicizzato in cima ai risultati dei motori per la query SSMS
. Il pacchetto che prometteva SQL Server Management Studio consegnava in realtà una versione dell’editor audio Audacity con un impianto malevolo incorporato in una libreria. Non è avvelenamento della catena di fornitura, perché non risultano compromessi né un pacchetto legittimo né l’account di un manutentore: è abuso di piattaforma e SEO poisoning. Il perno, tuttavia, è lo stesso già osservato nelle campagne di pacchetti open source avvelenati contro gli sviluppatori, la fiducia implicita negli strumenti di lavoro quotidiani. Cambia il vettore, resta la superficie.

La catena e la persistenza RDP

Lo script TookPS
installa SSH sulla macchina della vittima, apre una connessione verso il server SSH controllato dagli attaccanti e inoltra la porta del demone SSH locale. Dopo un ritardo, è un bot SSH automatizzato, operante lato attaccante, a collegarsi alla porta inoltrata per consegnare i payload: il bot non risiede sull’host colpito. È questo bot a costruire la persistenza più interessante per un pubblico enterprise. Apre le porte del firewall per il traffico RDP in ingresso, crea un utente nel gruppo “Remote Desktop Users”, sostituisce la termsrv.dll
legittima con una versione modificata per consentire sessioni RDP concorrenti e crea un’attività pianificata chiamata Apple Sync
che mantiene ogni ora un tunnel SSH inverso sulla porta RDP locale.

Da qui parte l’anello che porta ai plugin. Il bot recupera i moduli via SFTP e li esegue tramite HDUtil
, un launcher protetto con VMProtect, usando il comando target
; l’argomento opzionale nouac
di quel comando esegue il bypass dell’UAC tramite RPC di Windows e un msconfig.exe
auto-elevato, tecnica descritta da Google Project Zero nel 2019. L’ultima consegna è Volume2
, un’utility open source collegata a una protobuf.dll
malevola: la libreria appare legittima ma espone una funzione ProtobufGetVer2
che decritta e avvia l’implant vero, cioè il dispatcher di plugin. Il payload è cifrato con AES-GCM e chiave statica a 256 bit, ma con il tag di autenticazione omesso, quindi senza verifica d’integrità. Il meccanismo è quello del DLL hijacking, utile come indicatore per la detection; tra i verdetti con cui Kaspersky rileva il framework figura infatti anche Trojan.Win32.Dllhijack.*
.

L’arsenale modulare e il dispatcher

Il dispatcher interroga il server di comando ogni venti secondi; i ricercatori hanno individuato cinque plugin: un wrapper per CMD, uno per PowerShell, un enumeratore d’ambiente, un dropper e un process injector. È il process injector a mettere in campo i quattro implant veri e propri, iniettandoli in processi legittimi: ext_daemon
, SeedHunter
, MC Keylogger
e OkoSpyware
. Il primo si aggancia ai processi dei browser basati su Chromium, non solo Chrome: per Microsoft Edge, ad esempio, viene agganciata la msedge.dll
. Installa estensioni malevole concedendo tutti i permessi richiesti; nell’attacco analizzato l’estensione installata era Rilide
. L’occultamento passa dalle stesse funzioni interne del browser agganciate dal loader: le estensioni malevole finiscono in un array dedicato e, quando quelle funzioni vengono invocate con tali estensioni come parametro, non fanno nulla e restituiscono un valore costante, sopprimendo le notifiche ed escludendole dall’elenco visibile, mentre le altre estensioni continuano a comportarsi normalmente. In fase d’installazione le estensioni vengono inoltre scompattate nella directory non predefinita Local Extension Settings
, con il manifest modificato al volo per iniettare un oggetto custom_args
contenente l’identificativo della macchina infetta (
hwid
) e il browser.

Il MC Keylogger
registra tasti e appunti (testo, immagini e percorsi dei file copiati), traccia i dispositivi USB collegati e cattura uno screenshot ogni cinque minuti. OkoSpyware
confronta le finestre attive con un elenco di oltre cento nomi di eseguibili, tra cui wallet come Exodus e Litecoin QT e gestori di password come KeePassXC e 1Password, e intercetta anche i titoli delle finestre dei browser tramite espressioni regolari (ad esempio le pagine delle estensioni MetaMask o Tonkeeper), avviando la registrazione video con FFmpeg e il logging dei tasti. L’esfiltrazione chiude il ciclo ed è anche anti-forense: uno script TookPS
lanciato da un’attività pianificata riceve dal C2 uno script PowerShell dedicato, invia all’endpoint ir-post.php
tutti i file prodotti da MC Keylogger
e OkoSpyware
, poi li cancella dal sistema e svuota il file di cronologia ConsoleHost_history.txt
.

L’inganno su Ledger e Trezor

Il modulo SeedHunter
si inietta nei processi di Trezor Suite, Ledger Wallet e Ledger Live agganciando le funzioni interne del framework Electron delle applicazioni: la finestra fraudolenta nasce quindi dentro l’app legittima. Il modulo interroga il C2 moonsand[.]store
e riceve un flag Wait
: se è true
, avvia scansioni periodiche dei dispositivi USB filtrate per VID e PID e attende che venga collegato un Ledger o un Trezor per mostrare la pagina di phishing; se è false
, la pagina compare subito. Il punto controintuitivo è proprio questo: il dispositivo hardware non viene compromesso, viene aggirato il software companion, ed è l’utente a consegnare la seed phrase digitandola nella schermata falsa. Chi cede quella sequenza perde il controllo dei fondi, perché la frase di recupero vale più della password e non è revocabile.

Un framework mantenuto, attribuzione prudente

L’evoluzione documentata da Kaspersky è la prova che il framework è manutenuto attivamente. Già a marzo 2026 il componente Volume2
viene installato direttamente da TookPS
, la vecchia catena HDUtil
verso extl
verso Rilide
risulta abbandonata e sostituita integralmente dal plugin ext_daemon
(funzionalmente identico a extl.exe
, solo meno offuscato e privo di VMProtect), mentre TeviRAT
è stato rimosso perché le sue funzioni sono coperte dal nuovo dispatcher; sempre da marzo 2026 la protobuf.dll
è stata rinominata version.dll
. Sull’attribuzione Kaspersky è netta: non collega la campagna ad alcun attore noto. Segnala però indizi circostanziali che rimandano ad attori di lingua russa, tecnica peraltro diffusa in quell’ambiente: i server della prima fase restituiscono una risposta vuota agli indirizzi IP di Russia e CSI, il codice sorgente delle pagine di phishing di SeedHunter
contiene commenti in russo e l’infostealer Rilide
circola su forum di cybercrime di lingua russa ad accesso su invito. Un’avvertenza sugli indicatori: il post pubblico ne espone solo un sottoinsieme, mentre la lista completa e gli script di decrittazione sono riservati ai clienti del servizio Kaspersky Threat Intelligence Reporting.

Sul piano difensivo gli artefatti non mancano: file come %PROGRAMDATA%hwid.dat
(l’identificativo di macchina che ogni componente verifica all’avvio, terminando se assente o non valido, il che ostacola anche l’analisi fuori dall’host bersaglio), %PROGRAMDATA%HDVideoHDUtil.exe
e %USERPROFILE%.sshgo.bat
, account non autorizzati nel gruppo “Remote Desktop Users”, traffico SSH in uscita da endpoint utente, la sostituzione di termsrv.dll
e l’attività pianificata Apple Sync
, fino allo svuotamento di ConsoleHost_history.txt
come segnale post-esfiltrazione. Il messaggio operativo resta duplice: trattare le workstation degli sviluppatori come asset ad alto rischio e ricordare agli utenti che nessun software legittimo chiede di digitare la seed phrase del wallet hardware su schermo.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/okobot-seed-phrase-ledger-trezor/




Two Scattered Spider Hackers Sentenced to Jail in UK

Two members of the Scattered Spider cybercrime group have been sentenced to jail in the United Kingdom, the country’s National Crime Agency (NCA) announced on Thursday.

Thalha Jubair, 20, and Owen Flowers, 18, were charged over their role in a 2024 cyberattack targeting Transport for London (TfL), which caused significant disruptions and generated costs of £29 million ($39 million).

Jubair and Flowers were arrested in September 2025. They initially pleaded not guilty but changed their pleas to guilty when their trial started in June.

On Thursday, they were each sentenced to five years and six months in prison following what officials described as “the largest cybercrime prosecution ever brought before the UK courts”. 

Despite several arrests last year, hackers operating under the Scattered Spider name continued to take credit for cyberattacks through the first months of 2026, although no new attacks have been announced in recent months.

Following the sentencing of Jubair and Flowers, the NCA noted, “Although other cybercriminals may continue to use the damaged Scattered Spider brand, the NCA’s action against Jubair and Flowers effectively halted the group’s criminal activity. Independent assessment supports this, with Microsoft confirming that the arrests materially degraded the group’s ability to continue conducting cybercriminal operations.”

Advertisement. Scroll to continue reading.

In the meantime, authorities continue prosecuting other suspected members of the group. An alleged member, 19-year-old Peter Stokes, a dual US-Estonian national, was recently extradited to the US to face charges. 

Tyler Buchanan, a British national believed to be part of the cybercrime gang, pleaded guilty in a US court in April. 

Related: Third US Security Expert Sentenced to Prison for Helping Ransomware Gang

Related: Romanian Hacker Sentenced to Prison in US for Selling Access to State Network

Related: Third DraftKings Hacker Sentenced to 18 Months in Prison

https://www.securityweek.com/two-scattered-spider-hackers-sentenced-to-jail-in-uk/




Albiriox, il RAT bancario che si finge UniCredit su Telegram

Una finta promozione, la promessa di 100 dollari e un bot Telegram: è la trappola con cui, in una campagna a tema italiano documentata dalla società italiana D3Lab, viene distribuito Albiriox, un banking trojan Android costruito per la frode on-device. Il marchio abusato è quello di UniCredit, ma conviene chiarirlo subito per non generare equivoci: la banca e i suoi clienti sono le vittime dell’operazione, non la fonte di una compromissione. La catena descritta non coinvolge alcun sistema dell’istituto; ad essere sfruttata è la sua identità, usata come esca.

La catena di infezione

Secondo l’analisi di D3Lab, l’allarme è partito da un servizio di brand monitoring che ha intercettato un dominio appena registrato, unicredit-tme[.]shop
, creato l’8 luglio 2026. La pagina promette una ricompensa e invita a scaricare un’app, ma invece di rimandare a uno store ufficiale porta a un bot Telegram (
@UniCreditit_bot
) che guida la vittima nell’installazione. L’incentivo è esplicito: 100 dollari per chi installa l’applicazione e altri 50 per chi invita un amico, un meccanismo referral che trasforma il raggiro in un moltiplicatore di diffusione.

La campagna non risulta appoggiarsi a Google Play né ad altri store ufficiali: l’utente viene convinto a installare l’APK manualmente, presumibilmente dopo aver abilitato le sorgenti sconosciute. Il dettaglio tecnico più rilevante è che il file scaricato è un dropper autocontenuto: il payload di secondo stadio non viene prelevato dalla rete a runtime, ma è già incorporato nell’APK, spezzato in più asset con estensioni fuorvianti, ricomposto in locale, decifrato in AES-CBC e decompresso con GZIP. Così la catena di consegna deve solo convincere la vittima a installare il primo file: il resto avviene sul dispositivo, senza un secondo download che potrebbe fallire o essere intercettato dai controlli di rete.

Che cosa fa Albiriox una volta a bordo

Il secondo stadio si registra come servizio di Accessibility e da lì controlla il telefono. Le capacità osservate sono quelle di un banking trojan moderno: overlay per catturare credenziali (con schermate configurabili per PIN, pattern, coppie utente/password), intercettazione degli SMS e degli OTP, controllo remoto in stile VNC con manipolazione dello schermo, fino alla modalità black screen che nasconde all’utente ciò che l’operatore sta facendo.

L’operatore non si limita a rubare le password: agisce direttamente dentro le sessioni bancarie legittime, aggirando i passaggi di autenticazione. La comunicazione con il server avviene su un protocollo TCP grezzo con messaggi JSON, verso 179[.]43[.]159[.]210
sulle porte 5555
e 5552
; nel codice compare persino un marcatore di campagna con il paese bersaglio scritto in cirillico, Италия
, indizio dell’ecosistema in cui il builder è stato configurato.

L’attribuzione ad Albiriox, spiega D3Lab, poggia sul confronto manuale con un campione noto, sulle somiglianze di protocollo e sul materiale Telegram del progetto: il sample italiano appare una build personalizzata e offuscata. Vale la cautela d’obbligo sui nomi: si tratta di una build riconducibile alla famiglia, le cui funzionalità D3Lab allinea alla versione 1.5 annunciata dagli sviluppatori a gennaio 2026.

Perché conta per il mercato italiano

Albiriox non nasce oggi. La ricerca di Cleafy, che per prima ne ha descritto la famiglia, lo inquadra come offerta Malware-as-a-Service commercializzata su forum di lingua russa, con una fase beta a settembre 2025 e la commercializzazione dall’ottobre successivo, a canoni mensili nell’ordine delle centinaia di dollari; la lista hardcoded dei bersagli superava le 400 applicazioni bancarie, di pagamento e crypto, come riportato dalla stampa specializzata. La novità della campagna italiana non è quindi il malware in sé, ma la sua localizzazione: un pacchetto pronto all’uso viene calato su un marchio bancario nazionale e distribuito con un funnel social semplice ed economico.

Il segnale non è isolato: nella sintesi settimanale del 4-10 luglio il CERT-AGID ha rilevato campagne italiane a tema banking veicolate via SMS con link al download di APK malevoli, tra cui Albiriox insieme a RedWing e RedHook. Vettori diversi, stessa famiglia: nella stessa settimana Albiriox arriva agli utenti italiani per almeno due strade distinte.

Per il settore finanziario italiano contano soprattutto due elementi. La superficie di attacco resta il fattore umano unito al sideloading, mentre il brand monitoring si conferma un segnale di early warning: un dominio appena registrato che imita una banca è spesso il primo anello di una catena malevola, non solo phishing. Il mobile banking trojan a tema Italia è del resto un filone già noto al mercato, come mostra il caso del trojan Xenomorph.

La difesa passa per il presidio dei domini simili al proprio marchio, il blocco dei bot Telegram usati come vettore, la comunicazione ai clienti che nessuna banca distribuisce APK fuori dagli store, e il monitoraggio dei dispositivi che installano app con permessi di Accessibility e connessioni TCP verso porte anomale. Sul versante utente, la logica è la stessa che vale contro ogni account takeover: diffidare di premi che chiedono un’installazione, e trattare ogni APK ricevuto via messaggistica come ostile.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/albiriox-rat-bancario-italia/