Breeze Comet uderza w brazylijskie systemy płatnicze i realizuje setki nieautoryzowanych transakcji

Wprowadzenie do problemu / definicja

Breeze Comet to grupa cyberprzestępcza nastawiona na zysk, która koncentruje się na przejmowaniu dostępu do środowisk finansowych oraz manipulowaniu procesami płatniczymi w Brazylii. W odróżnieniu od klasycznych kampanii wymierzonych w pojedynczych użytkowników, operatorzy tej aktywności atakują organizacje mające bezpośredni dostęp do infrastruktury bankowej, interfejsów API oraz krajowych systemów rozliczeniowych.

Taki model działania oznacza istotną zmianę w krajobrazie zagrożeń. Celem atakujących nie jest już wyłącznie kradzież danych logowania lub przejęcie jednego rachunku, lecz infiltracja środowisk odpowiedzialnych za inicjowanie i autoryzowanie transferów środków.

W skrócie

Breeze Comet od co najmniej 2024 roku prowadzi kampanie przeciwko podmiotom z sektorów finansowego, handlowego i e-commerce w Brazylii. Na celowniku znajdują się organizacje mogące realizować operacje przez krajowe mechanizmy płatnicze, takie jak Pix, STR i Boleto.

Grupa uzyskuje dostęp początkowy m.in. przez password spraying, socjotechnikę oraz kompromitację podatnych serwerów JBoss.
Po wejściu do środowiska wykorzystuje legalne narzędzia zdalnego dostępu, tunele sieciowe, własne backdoory i przejęte konta uprzywilejowane.
Końcowym celem jest wykonywanie masowych, nieautoryzowanych transakcji i zacieranie śladów aktywności.

Kontekst / historia

Aktywność przypisywana Breeze Comet była wcześniej łączona z innymi klastrami zagrożeń obserwowanymi przez firmy bezpieczeństwa. Grupa działa co najmniej od 2023 roku i stopniowo rozszerza swój arsenał, przechodząc od prostszych, komercyjnych narzędzi do bardziej złożonych implantów oraz własnej infrastruktury pośredniczącej.

Na wcześniejszych etapach kampanii operatorzy opierali się głównie na legalnych rozwiązaniach RMM, które zapewniały trwały i pozornie wiarygodny dostęp do stacji roboczych i serwerów. Z czasem schemat działania rozbudowano o kompromitację zaufanych witryn, wykorzystanie podatnych systemów pośrednich, nadużycia w środowiskach chmurowych oraz wdrażanie niestandardowego malware.

Co istotne, grupa nie ogranicza się do bezpośrednich ataków na banki. Celem są także procesory płatności, fintechy, dostawcy oprogramowania bankowego, sieci handlowe oraz inne organizacje podłączone do krytycznych ścieżek transferu środków.

Analiza techniczna

Łańcuch ataku Breeze Comet jest wieloetapowy i dobrze dopasowany do realiów środowisk finansowych. W fazie initial access napastnicy stosują password spraying oraz socjotechnikę z podszywaniem się pod wsparcie IT. Ofiary są nakłaniane do instalacji narzędzi zdalnego dostępu, takich jak AnyDesk, albo do uruchamiania skryptów PowerShell pod pretekstem aktualizacji aplikacji firmowych.

Alternatywną ścieżką wejścia jest kompromitacja podatnych serwerów JBoss, na których osadzane są web shelle umożliwiające dalszą eksploatację. Po uzyskaniu przyczółka grupa rozwija dostęp przy użyciu narzędzi tunelujących i proxy, w tym Chisel, Netcat oraz własnych komponentów.

W środowisku wewnętrznym prowadzone jest rozpoznanie z użyciem narzędzi takich jak Impacket, ADRecon i ADVipscan, a także autorskiego narzędzia do brute force wobec LDAP. Ruch lateralny odbywa się następnie przez nieautoryzowane sesje RDP, udziały SMB oraz przejęte poświadczenia uprzywilejowane.

Jednym z kluczowych komponentów kampanii jest malware COBALTSPIN, opisywany jako narzędzie routujące napisane w Rust. Jego rola polega na tunelowaniu ruchu pomiędzy infrastrukturą dowodzenia a wewnętrznymi systemami finansowymi. Dzięki odwrotnemu proxy SOCKS5 zestawionemu przez WebSocket operatorzy mogą komunikować się z zasobami odpowiedzialnymi za obsługę finansowych API, omijając część zabezpieczeń brzegowych.

Mechanizmy utrzymania dostępu również są rozbudowane. Oprócz komercyjnych narzędzi RMM zaobserwowano złośliwe pody Kubernetes, eksfiltrację sekretów chmurowych oraz kilka niestandardowych backdoorów.

LIGHTPAINT – komponent oparty na Javie służący do wdrażania trwałości z użyciem legalnego VPN.
MILDFROST – pasywny implant JAR wykorzystujący tunele DNS.
KICKPLATE – backdoor w Nim podszywający się pod komponenty Windows Update Health Tools.
BOATBEAM – implant w Go uruchamiający fałszywy serwer HTTPS imitujący IIS.

Aby utrudnić wykrycie, operatorzy wyłączają ochronę czasu rzeczywistego Windows Defendera za pomocą poleceń PowerShell. Następnie, wykorzystując przejęte konta oraz tunele sieciowe, uzyskują dostęp do kluczowych aplikacji finansowych i inicjują masowe, fałszywe operacje płatnicze. Po zakończeniu działań czyszczone są logi zdarzeń, usuwane katalogi robocze i ograniczany jest ślad powłamaniowy.

Interesującą obserwacją jest również to, że część skryptów i komponentów zawiera rozbudowane komentarze oraz ustandaryzowane nagłówki wykonania. Może to sugerować wykorzystanie modeli językowych do przyspieszania tworzenia i modyfikacji narzędzi ofensywnych.

Konsekwencje / ryzyko

Ryzyko związane z Breeze Comet wykracza daleko poza typowy incydent endpointowy. Ponieważ grupa koncentruje się na organizacjach zdolnych do inicjowania lub pośredniczenia w transferach finansowych, skutki kompromitacji mogą obejmować bezpośrednie straty pieniężne, zakłócenie ciągłości operacyjnej, utratę integralności rozliczeń oraz poważne konsekwencje regulacyjne.

Szczególnie narażone są podmioty mające dostęp do infrastruktury międzyinstytucjonalnej, poświadczeń mTLS, środowisk Active Directory, integracji fintech oraz procesów antyfraudowych. Jeżeli napastnik zrozumie logikę autoryzacji transferów i uzyska odpowiedni poziom dostępu do kont oraz interfejsów, część klasycznych mechanizmów detekcji może okazać się niewystarczająca, ponieważ transakcje będą wyglądały jak wygenerowane z legalnego środowiska operacyjnego.

Dodatkowe zagrożenie wynika z użycia skompromitowanych, zaufanych witryn oraz legalnych narzędzi administracyjnych. Taki model znacząco utrudnia wykrywanie oparte wyłącznie na reputacji domen, sygnaturach malware czy prostych wskaźnikach IOC. W praktyce oznacza to konieczność większego nacisku na detekcję behawioralną, monitoring tożsamości oraz analizę nietypowych przepływów transakcyjnych.

Rekomendacje

Organizacje z sektora finansowego, handlowego i płatniczego powinny traktować tego typu aktywność jako atak na proces biznesowy, a nie tylko na infrastrukturę IT. Skuteczna obrona wymaga połączenia kontroli technicznych, nadzoru nad tożsamością oraz monitoringu anomalii transakcyjnych.

Ograniczyć zdalną administrację wyłącznie do zatwierdzonych narzędzi i zaufanych adresów źródłowych.
Wdrożyć odporne na phishing mechanizmy MFA dla dostępu uprzywilejowanego, VPN, paneli administracyjnych i systemów płatniczych.
Regularnie audytować serwery aplikacyjne, zwłaszcza JBoss, pod kątem podatności, web shelli i niestandardowych artefaktów.
Segmentować sieć tak, aby stacje użytkowników, systemy administracyjne, środowiska finansowe i integracje API były logicznie odseparowane.
Monitorować wykorzystanie RDP, SMB, PowerShell, LDAP oraz narzędzi takich jak Chisel, Netcat, AnyDesk i SoftEther VPN.
Wdrożyć detekcję nadużyć w warstwie tożsamości, obejmującą password spraying, nietypowe logowania i eskalację uprawnień.
Chronić i regularnie rotować poświadczenia mTLS, sekrety aplikacyjne oraz klucze używane do komunikacji z systemami płatniczymi.
Rozbudować monitoring transakcyjny o korelację zdarzeń bezpieczeństwa z aktywnością biznesową.
Zabezpieczyć środowiska Kubernetes i chmurowe przed nieautoryzowanym wdrażaniem workloadów oraz eksfiltracją sekretów.
Przygotować procedury incident response obejmujące SOC, IAM, zespoły płatnicze, fraud detection i zgodność regulacyjną.

Podsumowanie

Breeze Comet pokazuje, że współczesna cyberprzestępczość finansowa coraz częściej przenosi się z poziomu oszustw detalicznych na poziom bezpośrednich włamań do organizacji obsługujących płatności. Kluczową cechą tych kampanii jest połączenie socjotechniki, legalnych narzędzi administracyjnych, autorskiego malware, ruchu lateralnego oraz dobrego zrozumienia procesów transferowych.

Dla obrońców najważniejszy wniosek jest jednoznaczny: ochrona systemów płatniczych nie może ograniczać się do zabezpieczeń aplikacyjnych. Musi obejmować tożsamość, segmentację, obserwowalność ruchu wewnętrznego, ochronę poświadczeń, kontrolę narzędzi zdalnych oraz analizę anomalii biznesowych, zanim atakujący przejdzie od dostępu technicznego do realnej kradzieży środków.