Pe 12 septembrie 2026, Revolut a confirmat că date ale clienților au ajuns la un terț neautorizat, în urma a ceea ce compania a descris ca o înșelătorie sofisticată de impersonare externă. Cererea a venit pe e-mail, de pe o adresă aflată pe domeniul real al unei agenții guvernamentale. A trecut toate verificările de autentificare, pentru că nu avea ce să pice — domeniul chiar aparținea instituției în numele căreia se scria. În interiorul Revolut, mesajul a fost tratat drept ceea ce părea: o solicitare legală obligatorie de informații despre clienți.
Revolut afirmă că sistemele, bazele de date, conturile și fondurile clienților nu au fost compromise. Afirmația este aproape sigur corectă și exact aici este miezul problemei. Nu s-a rupt nimic tehnic. A cedat un proces — succesiunea de pași pe care îi urmează un om atunci când primește o cerere de date de la cineva care pare îndreptățit să o facă.
Relatările din presă indică aproximativ 680 de clienți contactați. Categoriile de date sunt considerabil mai grave decât sugerează cifra: nume complet, data nașterii, ocupația, adresă poștală și de e-mail, număr de telefon, copii după pașaport și permis de conducere, selfie-uri de verificare KYC, extrase de cont, IBAN-uri, istoricul retragerilor și istoricul complet al tranzacțiilor, inclusiv activitatea cripto. Revolut declară că a blocat adresa expeditorului și a sesizat agenția guvernamentală vizată, autoritățile de aplicare a legii și autoritățile de reglementare, iar autosesizarea trimisă către Information Commissioner's Office din Marea Britanie a dus la deschiderea unei investigații formale pe 14 septembrie.
Din 13 septembrie, cine deține datele a început să publice dosare de clienți pe Telegram, cu amenințarea unor publicări zilnice până la plată.
Autentificarea răspunde la altă întrebare
SPF, DKIM și DMARC stabilesc că un mesaj a fost trimis de un server autorizat de proprietarul domeniului și că expeditorul vizibil corespunde. Sunt controale utile și orice organizație ar trebui să le aibă configurate corect. Ele răspund la întrebarea „de unde vine mesajul".
Configurarea lor corectă rămâne obligatorie și se verifică repede. ClickScan, serviciul nostru de scanare, citește DNS-ul public al unui domeniu și îți arată dacă SPF se termină cu -all sau doar cu ~all — variantă pe care serverele destinatare o ignoră în mare parte —, dacă ești sub limita de zece interogări DNS care invalidează tăcut înregistrarea pe măsură ce fiecare departament adaugă câte un furnizor, dacă semnarea DKIM acoperă toate serviciile care trimit în numele tău și dacă DMARC chiar aplică o politică, nu stă la p=none. Nu cere nicio dovadă de proprietate, pentru că toate înregistrările pe care le citește sunt publice, așa că durează un minut — rulează o scanare pe propriul domeniu.
Niciuna dintre cele trei nu răspunde însă la singura întrebare care conta aici: am voie să trimit asta, acestui solicitant, pe acest canal?
Întrebarea nu este tehnică și nu poate fi delegată unui gateway de e-mail. La ea răspunde un om care urmează o procedură sau care nu o urmează. De aceea aceeași organizație poate avea înregistrări de autentificare impecabile, un program de securitate matur și un buget generos, și totuși să trimită scanuri de pașapoarte pentru că un e-mail arăta oficial și suna urgent.
Există un precedent în aceeași companie. În septembrie 2022, un atacator a combinat o campanie de inginerie socială foarte țintită cu o credențială de angajat obținută prin phishing și a ajuns la datele a 50.150 de clienți, dintre care 20.687 din Spațiul Economic European și 379 din Lituania, conform notificării care a determinat Inspectoratul de Stat pentru Protecția Datelor din Lituania să deschidă o investigație. Mecanică diferită, aceeași slăbiciune, la patru ani distanță.
Procedura, integral
Procedura de mai jos este scrisă ca să poată fi adoptată ca atare sau adaptată la propriile praguri de aprobare. Controlul care ar fi oprit incidentul din 2026 este un comportament, iar un comportament se poate specifica, antrena și măsura.
- Nu răspunzi niciodată pe canalul pe care a venit cererea. Datele de contact din mesaj — adresa de reply, numărul din semnătură, linkul către un portal — sunt conținut furnizat de solicitant, nu identificare. Confirmarea se face pe un canal ales de tine.
- Folosești o cale de contact publicată și independentă. Numărul oficial al instituției de pe propriul ei site, o adresă dintr-un registru pe care îl ții tu, o persoană de legătură deja stabilită. Nu numărul din e-mail.
- Ceri un număr de referință al cererii și verifici pe canalul independent că acesta există. O autoritate legitimă care emite o solicitare obligatorie își poate identifica propria cerere, iar un solicitant de bună-credință nu se va supăra că este întrebat.
- Confirmi înainte să plece ceva, nu după. Verificarea se face cât timp datele sunt încă în organizație. Un telefon de confirmare dat după ce fișierele au fost trimise este o notă de incident, nu un control.
- Introduci al doilea aprobator peste un prag. Definește pragul prin volum și prin sensibilitate — documente de identitate, materiale KYC, istoric complet de tranzacții și orice cerere care privește mai mult de câțiva clienți ar trebui să ceară două persoane, dintre care una să nu fi primit cererea inițială.
- Dai angajaților dreptul explicit și scris de a întârzia o cerere. Urgența este instrumentul atacatorului, nu al autorității. Un angajat care încetinește o cerere care se dovedește autentică nu trebuie să suporte nicio consecință. Dacă garanția aceasta nu există în scris, procedura nu va rezista la primul apel al cuiva care sună a om important și grăbit.
- Înregistrezi fiecare cerere, verificarea ei și rezultatul. Este ceea ce arăți la un control și ceea ce îți permite să observi a doua încercare.
Același tipar, în orice organizație
Orice organizație care are un proces prin care cineva trimite date unui solicitant ce pare legitim este expusă la asta.
Resursele umane primesc o cerere de state de plată care pare să vină de la Fisc. Contabilitatea primește o schimbare de IBAN al furnizorului, pe ceea ce pare antetul furnizorului. Helpdesk-ul primește o cerere de recuperare de cont de la cineva care știe data nașterii angajatului și numele șefului. Juridicul primește o citație sau o adresă oficială pe e-mail. În fiecare caz, factorul decisiv este același: dacă persoana este obligată să confirme pe un canal ales de ea înainte de a acționa.
Ce măsoară greșit simulările pe rata de click
O simulare clasică de phishing măsoară dacă cineva a dat click pe un link. În scenariul de față nu există link. Există o cerere de date și o decizie de divulgare. Un angajat cu o rată de click impecabilă poate trimite un folder cu scanuri de pașaport unei cereri bine scrise, de pe un domeniu care arată autentic.
O simulare care măsoară acest risc arată altfel. Trimite o cerere de date plauzibilă pe un canal pe care destinatarul îl consideră de încredere și apoi înregistrează ce a făcut omul:
- A încercat o verificare independentă, pe un canal ales de el, în loc să răspundă?
- Cât a durat până când cererea a fost raportată către securitate, măsurat de la primire?
- S-a aplicat regula celui de-al doilea aprobator acolo unde pragul o cerea?
- A divulgat cineva, parțial sau total, ori a promis că va divulga?
Acestea sunt metricile. Rata de click nu se află printre ele. Cele două care susțin un program sunt rata de verificare independentă și timpul până la raportare, pentru că sunt singurele care descriu ce au făcut oamenii, nu ce au evitat.
Acesta este modelul după care construim scenarii de cerere de date și de vishing în activitatea de management al riscului uman și motivul pentru care programele noastre de simulare de phishing sunt structurate ca măsurare continuă, cu scenarii pe rol, nu ca o campanie anuală. Angajații care au cea mai mare nevoie de acest scenariu — financiar, resurse umane, helpdesk, juridic, operațiuni clienți — sunt de regulă cei pe care o simulare generică îi servește cel mai prost. Instruirea de securitate dedicată acestor roluri este cealaltă jumătate a răspunsului.
Obligațiile și coada lungă
Pentru entitățile financiare, un incident major legat de TIC în sensul DORA (Regulamentul (UE) 2022/2554) atrage o notificare inițială în patru ore de la clasificarea ca incident major și cel târziu în 24 de ore de la momentul în care entitatea a luat cunoștință de el, un raport intermediar în cel mult 72 de ore de la notificarea inițială și un raport final în termen de o lună. În România, supravegherea merge prin BNR pentru bănci și instituții financiare nebancare și prin ASF pentru asigurători, fonduri de pensii și entitățile de pe piața de capital. În paralel, art. 33 din GDPR prevede 72 de ore pentru notificarea autorității de supraveghere — ANSPDCP —, iar art. 34 cere informarea persoanelor vizate atunci când riscul pentru ele este ridicat. Stabilirea rutei fiecărui raport se face înainte de incident, ca parte din pregătirea de audit, risc și conformitate, nu la trei dimineața.
Mai există partea care nu se închide odată cu incidentul. Documentele de identitate și selfie-urile de verificare nu se reemit cum se schimbă o parolă. Devin materie primă pentru frauda următoare: vishing cu date personale corecte, recuperare frauduloasă de cont, SIM swap, identitate sintetică. Pentru clienții ale căror dețineri cripto sunt acum documentate alături de adresa de domiciliu, riscul nu este doar financiar.
Acesta este argumentul pentru a investi în decizia de divulgare, nu în încă un strat de filtrare. Mesajul care a provocat totul a trecut fiecare verificare tehnică existentă și le-ar trece din nou și mâine.
Acest articol are caracter informativ general și nu constituie consultanță juridică sau de reglementare. Pentru modul în care DORA, GDPR sau NIS 2 se aplică organizației tale, consultă cadrul legal aplicabil și consilierul juridic.
Notă privind sursele: confirmarea Revolut, categoriile de date și investigația ICO provin din declarațiile companiei și din presa de specialitate. Cifra de aproximativ 680 de clienți afectați aparține Financial Times și nu a fost confirmată de Revolut. Cererea de răscumpărare și volumul datelor publicate provin din relatări secundare despre un canal de Telegram și nu au fost verificate independent de noi.
Surse: TechCrunch — Revolut confirmă breșa de date prin cereri guvernamentale false; The Register — Revolut a căzut în capcana unor cereri guvernamentale false; Help Net Security — Ce știm până acum despre breșa Revolut; RTÉ — Breșă de date Revolut după cereri guvernamentale false; SecurityWeek — Peste 50.000 de clienți Revolut afectați de breșa din 2022; Regulamentul (UE) 2022/2554 (DORA), art. 19; GDPR, art. 33 și 34; DNSC.