BREEZE COMET: fałszywe wsparcie IT, AnyDesk i przejęte strony urzędowe

Z perspektywy PHISHLY najważniejsza jest droga wejścia. W części obserwowanych kompromitacji napastnicy dzwonili do pracowników, podszywali się pod wsparcie IT i nakłaniali do instalacji legalnych narzędzi zdalnego monitorowania i zarządzania (RMM), takich jak AnyDesk. W innych operacjach wykorzystywali przejęte strony administracji publicznej do hostowania narzędzi i plików, co pomagało ominąć prostą ocenę reputacji domeny.

To świeży przykład dwóch pułapek, które łatwo pomylić z oznakami bezpieczeństwa: legalnego programu i znanej, zaufanej domeny. Żaden z tych elementów nie potwierdza, że polecenie wykonania konkretnej czynności jest prawidłowe.

Szersze podstawy rozpoznawania manipulacji opisujemy w poradniku co to jest phishing i jak go rozpoznać.

Co Google ujawnił o BREEZE COMET

Google Threat Intelligence Group i Mandiant śledzą tę aktywność jako BREEZE COMET, wcześniej oznaczaną UNC5669. Raport z 1 września opisuje działania obserwowane od 2024 roku przeciw organizacjom z sektora finansowego, handlu i e-commerce w Brazylii.

Celem aktora jest dostęp do środowisk, które mogą wykonywać transakcje przez systemy i interfejsy płatnicze. Raport obejmuje rozbudowaną część techniczną, ale z punktu widzenia użytkownika kluczowy jest wcześniejszy moment: w jaki sposób ktoś uzyskuje pierwszy dostęp do firmy.

Google wymienia kilka dróg. Wśród nich są próby odgadywania haseł do wielu kont, wykorzystanie podatnych serwerów, fizyczne podłączanie nieautoryzowanych urządzeń do sieci oraz socjotechnika. Nie należy więc przedstawiać BREEZE COMET jako grupy używającej wyłącznie vishingu.

Fałszywe wsparcie IT i legalny AnyDesk

W pierwszych analizowanych kompromitacjach Mandiant obserwował rozmowy głosowe, podczas których napastnicy podszywali się pod zespoły wsparcia IT. Celem było przekonanie pracownika do instalacji narzędzia zdalnego dostępu.

Jednym z wymienionych programów jest AnyDesk. To legalne oprogramowanie używane przez prawdziwe zespoły pomocy technicznej. Właśnie dlatego sama nazwa programu nie jest dobrym kryterium oceny sytuacji.

Różnica leży w procesie:

• kto zainicjował kontakt;
• czy pracownik oczekiwał interwencji;
• czy istnieje zgłoszenie lub inny ślad w firmowym procesie wsparcia;
• czy instalacja danego narzędzia jest zgodna ze standardem organizacji;
• czy prośbę można potwierdzić przez drugi, samodzielnie wybrany kanał.

Axur, opisując pokrywającą się aktywność Plump Spider, przedstawił również przypadek rozmowy przez WhatsApp, w której osoba podszywająca się pod analityka wsparcia IT przez dłuższy czas prowadziła ofiarę przez kolejne kroki. Pretekstem była aktualizacja firmowej aplikacji, a skutkiem uruchomienie skryptu rozpoznającego sieć.

To pokazuje, dlaczego szkolenie ograniczone do hasła „nie instaluj podejrzanych programów” jest zbyt proste. Napastnik może poprosić o instalację programu, który jest prawidłowy i znany administratorom.

Przejęta strona urzędowa nadal może prowadzić do ataku

Drugi element raportu jest równie istotny. Od połowy 2025 roku GTIG obserwował wykorzystanie przejętych stron małych jednostek administracji publicznej w Brazylii do hostowania narzędzi RMM, programów kradnących informacje oraz programów zapewniających ukryty dostęp.

Google wskazuje, że taka infrastruktura służyła także do wspierania operacji socjotechnicznych. Przejęta domena miała reputację legalnej strony, co mogło utrudniać filtrowanie oparte wyłącznie na reputacji domeny.

Dla użytkownika wynika z tego prosty problem decyzyjny: adres może wyglądać wiarygodnie, bo domena rzeczywiście należy do prawdziwej instytucji, ale serwer lub część strony mogła zostać przejęta.

Dlatego pytanie „czy to jest znana domena?” nie wystarcza. Trzeba jeszcze zapytać:

• dlaczego dział IT wysyła mnie akurat na tę stronę;
• czy plik pasuje do normalnego procesu wsparcia;
• czy tę czynność potwierdza zgłoszenie lub oficjalny kanał;
• czy organizacja w ogóle korzysta z tego narzędzia.

Podobny mechanizm zaufania do interfejsu i procesu opisujemy szerzej w artykule o fałszywym wsparciu IT i zdalnej pomocy.

Czego nie należy dopowiadać

Raport Google łączy obserwacje z kilku lat i opisuje wiele technik. Nie oznacza to, że w każdym incydencie przebieg wyglądał tak samo.

Nie ma podstaw, aby twierdzić, że:

• każda skuteczna kradzież pieniędzy zaczynała się od telefonu;
• każdy pracownik był nakłaniany do instalacji AnyDesk;
• każda przejęta strona urzędowa była używana w tej samej kampanii;
• samo pojawienie się legalnego programu RMM jest dowodem działania BREEZE COMET.

Warto też oddzielić źródła. Google/Mandiant opisuje własne obserwacje i odwołuje się do Axur jako niezależnego potwierdzenia części aktywności związanej z vishingiem. Te dane wzajemnie się uzupełniają, ale nie należy ich przedstawiać jako jednego zbioru telemetrycznego.

Jak powinien zareagować pracownik

Przy nieoczekiwanym telefonie od osoby podającej się za wsparcie IT najbezpieczniejsza procedura jest krótka:

1. nie instaluj programu ani nie uruchamiaj polecenia podczas rozmowy;
2. przerwij kontakt;
3. samodzielnie otwórz firmowy kanał wsparcia — portal zgłoszeń, znany numer lub komunikator używany zgodnie z procedurą;
4. potwierdź, czy interwencja naprawdę została zlecona;
5. jeżeli coś zostało już uruchomione, zgłoś to od razu zespołowi odpowiedzialnemu za bezpieczeństwo lub obsługę incydentów.

Nie chodzi o zakaz używania zdalnej pomocy. Chodzi o to, aby nie oddawać kontroli nad urządzeniem na podstawie samej wiarygodności rozmówcy.

Co może zrobić organizacja

Google rekomenduje między innymi kontrolę uruchamiania aplikacji, wykrywanie nieautoryzowanych narzędzi RMM oraz szkolenie pracowników w zakresie podszywania się pod wsparcie IT.

Z punktu widzenia security awareness warto połączyć te zabezpieczenia z jasnym procesem:

• określić, jakich narzędzi zdalnego wsparcia firma rzeczywiście używa;
• powiedzieć pracownikom, czy dział IT może inicjować niezapowiedziane sesje;
• wymagać numeru zgłoszenia lub innego potwierdzenia dla zdalnej interwencji;
• zapewnić łatwy kanał do weryfikacji podejrzanego telefonu;
• mierzyć w symulacjach nie tylko kliknięcia, ale także to, czy pracownik zatrzyma proces i zweryfikuje rozmówcę.

Scenariusz ćwiczenia może być bardzo prosty: telefon od „IT”, prośba o instalację znanego narzędzia oraz link prowadzący do strony wyglądającej wiarygodnie. Celem nie powinno być nauczenie jednej nazwy programu, lecz sprawdzenie, czy użytkownik rozpoznaje nieoczekiwany proces wsparcia jako moment wymagający potwierdzenia.

Jeżeli organizacja chce sprawdzić takie zachowania w kontrolowanych warunkach, testy phishingowe i scenariusze socjotechniczne mogą obejmować także kontakt wykraczający poza klasyczny e-mail.

Wniosek

BREEZE COMET jest świeżym przykładem tego, że skuteczne zdobycie pierwszego dostępu nie musi opierać się na egzotycznym narzędziu. Napastnik może połączyć zwykły telefon, legalny program zdalnego dostępu i prawdziwą domenę przejętej instytucji.

Dla pracownika najważniejsza jest więc nie nazwa programu ani wygląd adresu, lecz zgodność całej prośby z normalnym procesem firmy. Gdy ktoś nieoczekiwanie podaje się za IT i prosi o instalację narzędzia lub uruchomienie pliku, właściwym krokiem jest niezależne potwierdzenie tej czynności przed jej wykonaniem.