O platformă SaaS cu autentificare corectă, MFA disponibil, infrastructură monitorizată și o echipă de securitate cu experiență. Nimic din toate acestea nu a contat. În două săptămâni, lucrând remote împotriva unui client SaaS european, echipa Zerotak a preluat controlul asupra unui cont de utilizator fără să atingă nicio componentă software. Am înregistrat un email care arăta aproape identic cu cel al țintei, am scris un email politicos către suport și am așteptat.
Helpdesk-ul a procesat cererea de schimbare a adresei de email. Fără apel telefonic de confirmare. Fără verificare secundară. Contul era al nostru.
Așa arată social engineering atunci când funcționează și acesta este motivul pentru care pentestele care se opresc la stratul tehnic îți oferă o încredere falsă.
De ce funcționează social engineering-ul asupra helpdesk-ului
Suportul pentru clienți există pentru a rezolva probleme rapid. Acesta este întregul scop. Agenții sunt evaluați în funcție de timpul de rezolvare, satisfacția clienților și volumul de tickete. Structura de incentive recompensează încrederea și viteza.
Atacatorii exploatează exact această structură de incentive. O cerere bine scrisă, venită de la cineva care pare un client legitim, cu un motiv plauzibil pentru schimbare, ajunge în aceeași coadă cu alte o sută de cereri legitime pe zi. Agentul care se oprește pentru a verifica este agentul ale cărui KPI-uri scad.
Aceasta nu este o problemă de training. Este un eșec procedural.
În acest engagement, ținta a fost o platformă SaaS care operează pe piața europeană. Obiectivul a fost definit restrâns: să se determine dacă un atacator poate compromite un cont de utilizator prin manipularea fluxului de suport. Engagementul s-a desfășurat pe parcursul a două săptămâni, remote, împotriva unui cont țintă dummy furnizat de client.
Rezultatul a fost compromiterea completă a contului.
Metodologia
Engagementul a urmat o metodologie structurată, concepută pentru a produce constatări defensibile fără a perturba utilizatorii reali. Pașii:
- Cercetare Open Source Intelligence (OSINT): construirea unui profil al organizației țintă, al canalelor sale de suport, al tiparelor comune de solicitări și al informațiilor disponibile public despre angajați și clienți.
- Dezvoltarea scenariului: proiectarea unei cereri pe care helpdesk-ul ar putea să o primească în mod plauzibil în operarea normală.
- Confirmarea scenariului de către client: clientul a aprobat scenariul exact de atac înainte de execuție. Fără tactici surpriză, fără ambiguitate etică.
- Notificare înainte de execuție: un grup restrâns de stakeholderi din partea clientului știa că engagementul este activ, pentru a evita escaladarea către autorități sau către echipa de incident response.
- Execuția social engineering-ului: încercarea propriu-zisă, realizată în condiții controlate împotriva unui cont dummy.
- Observare și analiză a răspunsului: documentarea modului în care helpdesk-ul a procesat cererea la fiecare pas.
- Notificare de succes după execuție: echipa de suport a fost informată că engagementul a reușit imediat ce acesta a reușit.
- Analiză de risc: maparea lacunelor procedurale la impactul asupra businessului.
- Documentare și raportare: livrabile pentru audiențe tehnice și executive.
Această secvență contează. Evaluările de social engineering care omit confirmarea scenariului produc constatări pe care clientul le contestă. Evaluările care omit notificarea după execuție lasă echipa de suport cu impresia că a fost prinsă într-o ambuscadă. Ambele reduc valoarea engagementului.
Constatarea critică: Account takeover prin helpdesk
Lanțul de atac reușit a fost simplu:
- Înregistrarea unei adrese de email vizual similare cu adresa utilizatorului legitim. Substituții comune: zero în loc de litera O mare, litera l mică în loc de cifra 1, domenii typosquat.
- Contactarea suportului prin impersonarea utilizatorului legitim, folosind adresa lookalike ca aparent expeditor.
- Transmiterea unei cereri formatate profesionist pentru schimbarea emailului contului către unul aflat sub controlul atacatorului.
- Susținerea faptului că o confirmare telefonică avusese deja loc, deși niciun apel nu fusese realizat vreodată. Acesta este elementul central al social engineering-ului: o referință plauzibilă la un proces pe care agentul nu îl poate verifica ușor.
Echipa de suport a procesat cererea de schimbare a emailului fără a efectua o verificare secundară a identității. 
Preluare completă a contului, realizată exclusiv prin manipulare procedurală. Fără payload de phishing. Fără vulnerabilitate tehnică.
Remedierea în acest caz nu este un patch software. Este o schimbare de proces: verificare secundară obligatorie printr-un canal diferit de cel din care a venit cererea inițială, de fiecare dată.
Constatarea cu severitate ridicată: Expunerea credențialelor
În paralel cu activitatea de social engineering, cercetarea OSINT a identificat mai multe credențiale ale clienților expuse în breșe publice și leak-uri de date.
Nu au fost găsite credențiale interne ale angajaților și nu a fost efectuată nicio exploatare activă bazată pe credențiale împotriva sistemului live. Dar prezența credențialelor clienților în seturi publice de date provenite din breșe înseamnă că:
- Baza de clienți a platformei este expusă oricând la atacuri automate de credential stuffing.
- Campaniile țintite de social engineering au șanse semnificativ mai mari să reușească, deoarece atacatorii pot corela credențiale scurse cu date publice de profil pentru a construi impersonări convingătoare.
Platforma nu avea implementată monitorizare proactivă a breșelor și nu exista resetare forțată a parolei declanșată de detectarea credențialelor în leak-uri. Ambele sunt controale standard pentru platformele SaaS care operează la scară. Ambele lipseau.
Ce a demonstrat acest engagement
Slăbiciunile umane și procedurale pot ocoli controale tehnice altfel sigure.
Platforma avea securitate rezonabilă a infrastructurii, autentificare modernă și sisteme monitorizate. Nimic din acestea nu a fost relevant pentru calea de atac care a reușit.
Aceasta este lecția pe care testarea de penetrare tradițională o ratează. Un pentest de aplicație web, oricât de detaliat, nu va testa dacă echipa ta de suport verifică identitatea înainte de a schimba emailul unui cont. O evaluare de securitate cloud nu va testa dacă fluxurile tale orientate către clienți au puncte unice de eșec procedural. Aceste lacune sunt descoperite doar prin analizarea directă a stratului uman și procedural.
O postură de securitate matură necesită testare pe trei straturi:
- Tehnic: aplicații web, API-uri, infrastructură, configurare cloud.
- Procedural: fluxuri de suport, procese de recuperare a conturilor, căi interne de escaladare.
- Uman: rezistență la phishing, awareness, disponibilitatea de a verifica sub presiune socială.
O platformă care a testat doar primul strat nu este sigură. Este o platformă care știe că software-ul său este greu de atacat. Atacatorii vor găsi o cale în jurul lui.
Discută cu Zerotak
Dacă administrezi o platformă SaaS, un serviciu financiar sau orice produs cu un flux de suport pentru clienți care poate schimba proprietatea asupra contului, procesul tău de suport are nevoie de aceeași atenție pe care o acorzi codului.
Proiectăm engagementuri de social engineering cu scope clar, scenarii aprobate de client și impact zero asupra utilizatorilor reali. Livrabilul nu este o listă cu agenți care au greșit. Este un diagnostic procedural: unde permite fluxul preluarea contului, ce schimbări închid breșa și cum verifici remedierea.
- Email: collaboration@zerotak.com
- Telefon: +40 748 860 512