BREEZE COMET: de la falsul suport IT la sute de tranzacții frauduloase în sistemele de plată

Google Threat Intelligence Group și Mandiant au descris BREEZE COMET, un actor motivat financiar care, din 2024, a compromis organizații braziliene din servicii financiare, retail și comerț electronic. Obiectivul nu este doar furtul datelor unui client: atacatorii urmăresc accesul la aplicații, credențiale și sisteme care pot iniția tranzacții prin infrastructuri precum Pix, STR și Boleto.

Atacul începe uneori cu o decizie umană aparent normală

În compromiterile timpurii, Mandiant a observat password spraying și apeluri în care atacatorii imitau suportul IT pentru a convinge utilizatorii să instaleze instrumente de administrare la distanță precum AnyDesk. Alte intrări au inclus servere vulnerabile și dispozitive conectate direct în rețelele unor magazine. Actorul a folosit și site-uri guvernamentale compromise pentru a găzdui instrumente sau documente-capcană, profitând de reputația domeniului legitim.

După intrare, campania urmărea conturi privilegiate, medii cloud și de dezvoltare, credențiale din pipeline-uri și certificate folosite de aplicațiile financiare. Mandiant descrie mai multe backdoor-uri și un instrument de tunelare pentru acces redundant. Google spune că a găsit indicii ale folosirii AI generative în dezvoltarea unor scripturi; aceasta este o evaluare a cercetătorilor, nu dovada că întregul atac a fost autonom.

De ce semnătura validă nu dovedește intenția legitimă

O tranzacție poate trece verificările criptografice dacă atacatorul controlează aplicația autorizată să o inițieze și credențialele necesare. Controlul nu trebuie să se oprească la întrebarea „este payloadul semnat?”. Echipa trebuie să verifice cine a inițiat operațiunea, din ce context, în ce volum, către ce destinație și dacă se potrivește cu procesul aprobat.

• O aplicație autorizată nu este automat o aplicație integră; modificările și identitatea procesului trebuie monitorizate.
• Un cont de serviciu valid poate fi compromis; privilegiile, originea sesiunii și comportamentul rămân relevante.
• Un certificat mTLS confirmă o relație tehnică, nu justificarea economică a fiecărei tranzacții.
• Validarea antifraudă trebuie să detecteze volume, ferestre orare, destinații și secvențe neobișnuite, inclusiv când autentificarea tehnică reușește.
• Ștergerea logurilor după tranzacții trebuie tratată ca semnal critic și compensată prin jurnale centralizate, protejate separat.

Protocol pentru apelurile de „suport IT”

• Help desk-ul nu cere instalarea spontană a unui instrument remote prin telefon, WhatsApp sau un link trimis în timpul apelului.
• Angajatul închide apelul și contactează suportul prin portalul ori numărul intern cunoscut, fără a folosi datele furnizate de apelant.
• Orice solicitare privind un sistem de plăți, cont privilegiat sau stație financiară necesită ticket, owner și aprobare verificabilă.
• Dacă instrumentul a fost instalat, utilizatorul oprește activitatea și raportează; nu negociază cu apelantul și nu încearcă să curețe singur stația.
• SOC-ul corelează raportul uman cu instalări RMM, autentificări, sesiuni privilegiate și modificări în aplicațiile financiare.

Tabletop: 48 de ore până la frauda în masă

• Inject 1 — un coleg financiar raportează un apel de suport și instalarea AnyDesk. Cine izolează stația, revocă sesiunea și păstrează dovezile?
• Inject 2 — apare activitate într-un cont cloud de dezvoltare folosit de aplicația de plăți. Cine deține contul și ce secrete trebuie rotite?
• Inject 3 — aplicația autorizată transmite comenzi semnate, dar volumul crește brusc. Cine poate opri fluxul și ce proces manual sigur rămâne?
• Inject 4 — furnizorul spune că certificatele sunt valide. Ce dovezi cereți despre integritatea aplicației și conturile care au inițiat tranzacțiile?
• Inject 5 — logurile locale au fost șterse. Ce surse independente păstrează cronologia și cine coordonează banca, partenerii și autoritățile?
• Inject 6 — echipa descoperă acces redundant prin mai multe metode. Ce criteriu folosiți pentru a declara mediul curat?

Comportamente și rezultate măsurabile

• Timpul dintre raportarea apelului și izolarea stației plus revocarea accesului remote.
• Timpul până la corelarea identității, aplicației, certificatului și tranzacției.
• Procentul solicitărilor privilegiate care au ticket, aprobare și verificare prin canal separat.
• Timpul până la oprirea controlată a fluxului și activarea continuității.
• Capacitatea de a reconstrui tranzacțiile din loguri care nu pot fi șterse de sistemul compromis.
• Numărul conturilor, certificatelor și integrărilor fără owner descoperite în exercițiu.

BREEZE COMET arată de ce trainingul pentru fraudă nu poate fi limitat la clienți și carduri. Un apel către un angajat, un cont de dezvoltare sau o aplicație de încredere poate deveni drumul către infrastructura care mută bani. Exercițiul trebuie să lege comportamentul uman de controalele identity, antifraudă și incident response.