#banking

#Google #Cloud Outage in London Disrupts #Revolut #Banking Services
https://securityaffairs.com/201358/breaking-news/google-cloud-outage-in-london-disrupts-revolut-banking-services.html
#securityaffairs #hacking

Read Time:3 Minute, 30 Second

A post on a well-known hacking forum has reignited fears over the security of one of India’s largest banks. A user operating under the handle Siriusim claims to be in possession of a dataset tied to the State Bank of India (SBI), reportedly containing around 375,000 rows of customer data spread across CSV files, along with more than 2,700 supporting PDF documents such as loan applications and account-opening forms.

What the Claim Actually SaysAccording to posts tracked by security researchers and first surfaced publicly on October 16, 2026, the seller says the trove includes personal identifiers, loan paperwork, and residential address details for SBI customers. Four sample records were reportedly shared as proof of access. Indian media outlets that reviewed the claim reported that the dataset may also touch on Know Your Customer (KYC) information, which in India typically includes government identity numbers used for account verification.

It is important to stress what this is, and what it isn’t, at this stage. It is an unverified claim made by an anonymous actor on a criminal marketplace. It is not, so far, a confirmed breach acknowledged by SBI or validated by an independent forensic review.

Why the Numbers Don’t Tell the Whole StoryHeadlines built around round numbers like “375,000 records” can be misleading. A row in a spreadsheet is not necessarily a unique person — the same customer could appear multiple times across different loan applications, amended forms, or duplicate entries. Similarly, a count of PDF files says nothing about how many distinct individuals are represented inside them. Establishing real-world impact requires matching the leaked samples against known, verified records, something that can only be done through a proper investigation rather than by reading a forum post.

At the time local reporting went to print, SBI had not issued a public response confirming or denying that any of its systems, subsidiaries, or third-party vendors were compromised. That silence is not unusual in the early hours of a breach claim, but it does leave customers and journalists without a clear picture of what, if anything, actually happened.

An Open Question: Where Did This Data Come From?None of the public reporting so far identifies a specific vulnerability, stolen credential set, or compromised server behind the claim. That gap matters. Banking data can leak from many places that have nothing to do with a bank’s own core infrastructure — a third-party loan processor, a careless partner, or even a recycled dataset from an older, unrelated incident. Until SBI or an independent researcher traces the material back to its source, it is premature to say the bank’s own network was breached.

The Real-World Risk, Regardless of VerificationEven an unverified claim carries risk for customers, because fraudsters do not need confirmation to act. If any portion of the data is genuine, it could fuel highly convincing social engineering: fake calls referencing real loan details, fraudulent SMS messages urging “urgent KYC updates,” or phishing emails that cite a customer’s actual address or application history to appear legitimate. SBI has previously had to warn customers about fake reward apps and spoofed account-deactivation messages impersonating the bank, so attackers already have a playbook for exploiting SBI’s brand recognition.

What Customers and the Bank Should Do NextTreat unsolicited calls, texts, or emails referencing loan or KYC details with suspicion, even if they contain accurate-sounding information.

Never share passwords, PINs, or one-time passcodes over the phone or through a link sent via SMS or WhatsApp.

Verify any account or KYC-related request only through SBI’s official app, website, or branch — not through a number or link provided in the suspicious message itself.

Watch statements and credit reports for unfamiliar loan applications opened using stolen identity details.

For its part, SBI would be expected to investigate the forum listing, preserve relevant access logs, validate whether the sample records match real customer data, and notify affected individuals if an internal review confirms exposure. Until that process plays out, this remains a serious allegation rather than a confirmed breach — but one worth watching closely given the scale of SBI’s customer base and the sensitivity of the data types involved.

Si parla di:

Toggle

Un messaggio #WhatsApp che sembra arrivare dal capo. Una telefonata di conferma con la voce, riconoscibilissima, di un legale di fiducia. Bastano questi due elementi — nessun #malware, nessun #exploit, nessuna vulnerabilità da patchare — per far sparire 95 milioni di euro dai #conti di Fideuram, la divisione di private #banking di Intesa Sanpaolo. È una delle #frodi con voice cloning AI più costose mai documentate contro un istituto finanziario europeo, e il modo in cui è stata condotta dice più cose sul futuro del social engineering di dieci #report su #ChatGPT.

La dinamica: un BEC “potenziato” dall’AISecondo la ricostruzione emersa da fonti vicine all’inchiesta e riportata da Reuters, la truffa è iniziata a febbraio 2026. L’allora presidente di Fideuram, Paolo Molesini, ha ricevuto un messaggio WhatsApp che sembrava provenire dal CEO di Intesa Sanpaolo, Carlo Messina, con una richiesta di assistenza urgente per una transazione estera riservata. È lo schema classico del Business Email Compromise — impersonare un dirigente di vertice per aggirare i controlli interni — solo che il canale non era la posta elettronica ma una chat istantanea, già di per sé più informale e meno sottoposta a filtri di sicurezza aziendali.

In questo scenario ha influito molto sicuramente la capacità di voler evitare i controlli Consob su un’operazione finanziaria, evidentemente modus operandi praticato, che di fatto non è un buon modo di pensare. Così come la riservatezza dell’operazione. Guarda caso proprio nel momento in cui qualcuno della catena, ha avuto il coraggio di tradire questa “riservatezza”, chiamando gli interessati ai contatti noti, si è immediatamente scoperta l’azione criminale.

Il salto di qualità rispetto al BEC tradizionale arriva nel passaggio successivo. A confermare l’autenticità della richiesta è intervenuta una telefonata da quello che sembrava un avvocato senior di uno studio legale di primo piano: gli autori della frode avevano ricreato la voce del legale tramite intelligenza artificiale, rendendo la chiamata sufficientemente convincente da spingere Molesini a istruire il dipartimento finanze a eseguire i bonifici. Il voice cloning, qui, non è servito a impersonare la vittima ma a far superare alla vittima stessa un secondo livello di verifica — un dettaglio che dovrebbe far riflettere chiunque basi ancora le proprie procedure anti-frode sulla “voce riconoscibile” come fattore di autenticazione informale.

I 95 milioni di euro sono stati incanalati principalmente verso conti in Cina e Hong Kong. Fideuram ha rilevato le irregolarità relativamente in fretta, allertando banche e autorità in più paesi; la cooperazione tra investigatori italiani, cinesi e portoghesi ha permesso di recuperare circa 53 milioni di euro, mentre 36 milioni risultano ancora dispersi, in parte già convertiti in criptovalute — la solita ultima tappa di riciclaggio che rende il tracciamento sensibilmente più difficile. Un cittadino straniero residente fuori dall’Unione Europea risulta indagato per frode informatica; nessun dirigente di Fideuram è sotto inchiesta. Molesini si è dimesso a marzo, ufficialmente per “ragioni personali” — la banca e Intesa Sanpaolo hanno declinato di commentare nel merito con Reuters.

Non è un caso isolatoIl caso Fideuram si inserisce in un trend che nel 2026 sta diventando strutturale piuttosto che aneddotico. In Italia lo scorso anno un caso analogo aveva coinvolto l’imprenditore Massimo Moratti, indotto tramite una voce AI che imitava un ministro italiano a disporre un trasferimento di circa un milione di euro, poi recuperato. A livello internazionale, dal caso Arup di Hong Kong (2024, 25 milioni di dollari sottratti con una videochiamata deepfake multi-partecipante) in avanti, gli attacchi CEO fraud potenziati da sintesi vocale e video generativa si sono moltiplicati, spostando il baricentro della minaccia dal “clic sbagliato” alla fiducia riposta in un canale di comunicazione che fino a poco tempo fa era considerato inattaccabile: sentire la voce di una persona che si conosce.

Il punto tecnico da cogliere è che questi attacchi non hanno bisogno di violare nessun sistema. Non compaiono in nessun SIEM, non generano alert su nessun endpoint. Sfruttano dati biometrici vocali spesso pubblicamente disponibili — interviste, conferenze, video aziendali, contenuti social — per addestrare modelli di voice cloning che oggi richiedono pochi secondi di audio sorgente e strumenti facilmente reperibili. La superficie di attacco, in altre parole, non è il perimetro IT ma la reputazione pubblica dei dirigenti: più un top manager è mediaticamente esposto, più materiale vocale è disponibile per clonarlo.

Due righe per i difensoriPer i team di sicurezza e compliance, il caso Fideuram è un promemoria che i controlli anti-frode pensati per l’email non traslano automaticamente su WhatsApp, Telegram o altre chat, e che la “conferma vocale” non può più essere considerata un secondo fattore affidabile quando la richiesta riguarda un trasferimento di fondi fuori standard. Alcune contromisure concrete che le organizzazioni finanziarie dovrebbero già avere in produzione:

Vietare l’autorizzazione di bonifici straordinari sulla sola base di messaggistica istantanea o chiamate vocali, imponendo sempre un secondo canale di verifica indipendente e pre-registrato (callback su numero noto in rubrica aziendale, non su numero fornito nel messaggio sospetto).

Introdurre una parola d’ordine o passphrase condivisa fuori banda per le richieste finanziarie urgenti provenienti da dirigenti, da rinnovare periodicamente.

Applicare limiti di importo e “cooling off period” obbligatori per bonifici verso giurisdizioni ad alto rischio, indipendentemente dal livello gerarchico di chi autorizza.

Formare specificamente i ruoli finanziari e di vertice sul rischio di voice cloning e deepfake, con simulazioni realistiche (non solo phishing via email).

Limitare la disponibilità pubblica di materiale audio/video ad alta qualità dei dirigenti più esposti, dove ragionevolmente possibile, e monitorare la superficie OSINT associata.

Predisporre playbook di risposta rapida con le banche corrispondenti per il blocco/richiamo dei bonifici SWIFT in caso di sospetto, sul modello di quanto messo in atto — con successo parziale — da Fideuram stessa.

Il recupero di oltre metà della somma sottratta dimostra che una risposta rapida e una buona cooperazione internazionale tra autorità possono limitare i danni. Ma affidarsi alla velocità di reazione dopo il fatto, quando l’attacco costa zero exploit e sfrutta solo la fiducia interpersonale, significa accettare che la prossima vittima — banca, azienda o studio professionale — sarà scelta semplicemente in base a quanto materiale vocale dei suoi dirigenti è disponibile online.

Si parla di:

Toggle

Da febbraio 2026 un nuovo #trojan bancario per #Android circola con un obiettivo dichiarato: l’#Ucraina. Ma “trojan bancario” è ormai una definizione troppo stretta per Manic, il #malware descritto in un #report di ThreatFabric come “un ibrido tra malware bancario e #spyware”. Oltre a rubare PIN e credenziali finanziarie, Manic intercetta #SMS, seed phrase di wallet #crypto, cronologia chiamate e posizione #GPS — e, quando il telefono infetto è #offline, trova comunque il modo di far uscire i dati sfruttando altri dispositivi compromessi nelle vicinanze via Bluetooth e Wi-Fi Direct. È una capacità che ridefinisce cosa significhi davvero “isolare” un dispositivo compromesso.

Non una schermata di phishing, ma una tastiera che origliaLa maggior parte dei trojan bancari Android si affida a overlay che imitano l’interfaccia dell’app bersaglio per catturare le credenziali digitate dalla vittima. Manic fa qualcosa di più subdolo: grazie ai permessi di Accessibility Service, determina la posizione della tastiera digitale legittima dell’app e registra i singoli tocchi dell’utente senza alterare in alcun modo il funzionamento dell’app originale. Il risultato è che la vittima interagisce con la sua banca reale, sullo schermo reale, mentre in background il malware classifica ogni sequenza digitata — PIN di sblocco, seed phrase di wallet, codici OTP, password — semplicemente osservando dove e quando avvengono i tocchi.

A questa capacità si aggiungono sessioni di controllo remoto vere e proprie via WebRTC, con visualizzazione live dello schermo, mascherate dietro overlay neri o finte schermate di aggiornamento di sistema; la possibilità di sbloccare il dispositivo da remoto tramite la funzione autoEnterPin, una volta che il PIN è stato catturato; e comandi dedicati per disattivare Google Play Protect (disable_gp), così da ridurre le probabilità di essere rilevati anche dalle protezioni native di Android.

169 applicazioni monitorate, priorità all’UcrainaThreatFabric ha censito 169 identificatori di applicazioni nella lista bersagli di Manic: banche, exchange di criptovalute, app di pagamento P2P e “buy now pay later”, client email e browser. Il dato più significativo, però, è la composizione geografica dei target: il malware dà priorità esplicita a banche ucraine, servizi eID e piattaforme governative, oltre ad app di messaggistica sia commerciali sia a uso militare — una scelta che, nel contesto del conflitto in corso, suggerisce un interesse che va oltre la semplice frode finanziaria. La lista si estende poi a istituti finanziari in Russia, Polonia, Repubblica Ceca, Slovacchia, Austria, Germania, Francia, Spagna, Paesi Bassi, Estonia, Lituania e Regno Unito, con distribuzione tramite siti di phishing e dropper che si spacciano per utility di sistema o aggiornamenti di componenti Android/produttore (i nomi dei package individuati imitano deliberatamente Huawei, Honor, Lenovo, Motorola e persino Apple).

Lo sviluppo del malware appare tutt’altro che concluso. ThreatFabric ricostruisce una timeline chiara: la prima infrastruttura viene registrata a febbraio 2026, i servizi di produzione entrano in funzione tra marzo e aprile, la prima versione operativa di wrapper e implant compare a maggio, mentre a luglio arriva un aggiornamento che introduce protezioni anti-analisi rafforzate, caricamento del codice DEX direttamente in memoria (per complicare l’analisi statica) e un meccanismo di phishing per il “lock secret” del dispositivo.

Quando internet non basta: l’esfiltrazione mesh via BluetoothLa caratteristica più originale di Manic — e quella che lo distingue nettamente dal panorama dei trojan Android — è il meccanismo di esfiltrazione dati progettato per funzionare anche quando il dispositivo infetto non ha accesso diretto a internet. I dati rubati vengono cifrati con AES-GCM e messi in una coda locale; il malware cerca poi altri dispositivi infetti nelle vicinanze tramite Wi-Fi Direct, Bluetooth RFCOMM o BLE GATT, costruendo percorsi “store-and-forward” multi-hop — fino a 4 salti per impostazione predefinita — capaci di far arrivare i dati a internet passando di device in device, finché uno di essi non trova connettività diretta. Se nessuna rotta è disponibile nell’immediato, i dati restano semplicemente in coda per essere ritrasmessi al primo tentativo utile.

Come sintetizzano gli stessi ricercatori di ThreatFabric, “rimuovere l’accesso diretto a internet da un dispositivo infetto non impedisce necessariamente l’esfiltrazione dei dati”. È una considerazione che dovrebbe far riflettere chi progetta contromisure basate solo su segmentazione di rete o blocco della connettività cellulare/Wi-Fi: in scenari con più dispositivi compromessi nello stesso ambiente — un ufficio, un’abitazione, persino un evento pubblico — la rete mesh creata dal malware stesso diventa il canale di comunicazione, aggirando completamente i controlli perimetrali tradizionali pensati per un singolo endpoint.

Due righe per i difensoriPer i team di sicurezza mobile e per gli istituti finanziari nei paesi target, Manic impone di ripensare due assunzioni comuni. La prima è che il monitoraggio comportamentale lato server (fraud detection basata su pattern di digitazione o velocità di interazione) rimane efficace anche quando l’attaccante non altera l’interfaccia dell’app: qui serve piuttosto rilevare l’uso anomalo di servizi di Accessibility da parte di app di terze parti non correlate al contesto bancario. La seconda è che l’isolamento di rete di un dispositivo sospetto non è più una garanzia sufficiente, quando l’esfiltrazione può avvenire tramite protocolli short-range verso dispositivi terzi già compromessi.

Verificare quali app hanno richiesto e ottenuto permessi di Accessibility Service e Notification Listener, specie se provenienti da fonti fuori Google Play

Monitorare pattern anomali di connessioni Wi-Fi Direct/Bluetooth in ambienti aziendali e finanziari sensibili

Diffidare di dropper che si presentano come aggiornamenti di componenti di sistema legati a specifici produttori (Huawei, Honor, Lenovo, Motorola)

Mantenere attivo Google Play Protect e verificare periodicamente lo stato di attivazione, dato che Manic include comandi dedicati per disattivarlo

Per le banche: rafforzare l’autenticazione multi-fattore fuori-banda, poiché OTP e SMS risultano tra i dati intercettati con priorità

Indicatori di compromissione[Wrapper - luglio 2026]
SHA-256: 80be0942d0e20b5006e240434f42512c8b3cd0d54eee858a25663c1a4224a576
Package: tech.intel.dialer.updater

[Implant - luglio 2026]
SHA-256: feea425cde1223fe7afdd7a1ea631678ec6282f6cc20c3d3c0fb97cdbcf65b9b
Package: org.lenovo.storage.processor

[Implant primario]
SHA-256: e7abc375f24d0dd2419e0bce4686c7301b3ee82ae38906c67d3481580f6c648e
Package: tech.apple.dialer.scheduler

[Wrapper - maggio 2026]
SHA-256: 2884108b35eba7b8099087405653c1b23c3839f0d5058c4d61341fc31cfc6040
Package: org.honor.secure.helper

[Implant - maggio 2026]
SHA-256: 2fb5b01ea5a483d60b659e85327a53c6661bdd630d4afd93dc5fe0941d3ccbbe
Package: dev.huawei.media.helper

[Implant correlato]
SHA-256: 7c12f1237090e32c18583f66f1a9e44b029ad7c1e61179e1d524fb3093abd59a
Package: io.motorola.secure.executor

[Comandi bot principali]
remote_control - sessione schermo/webcam via WebRTC
get_logs - esportazione log accessibility
export_sms - esportazione SMS
export_calls - esportazione cronologia chiamate
export_contacts - esportazione contatti
export_file - raccolta file locali
send_sms - invio SMS dal dispositivo
ussd - esecuzione codici USSD
geo - attivazione geolocalizzazione
disable_gp - disattivazione Google Play ProtectFonte primaria: ThreatFabric Mobile Threat Intelligence. Report completo disponibile sul blog ufficiale di ThreatFabric.