Ataki vishingowe w Microsoft Teams prowadzą do wdrożeń Chaos ransomware - Security Bez Tabu

Ataki vishingowe w Microsoft Teams prowadzą do wdrożeń Chaos ransomware

Cybersecurity news

Wprowadzenie do problemu / definicja

Vishing, czyli phishing głosowy, należy dziś do najbardziej skutecznych metod uzyskiwania dostępu początkowego do środowisk firmowych. W najnowszych incydentach przestępcy wykorzystywali Microsoft Teams, podszywając się pod pracowników wsparcia IT i nakłaniając ofiary do uruchomienia narzędzi zdalnego dostępu. Taka socjotechnika otwierała drogę do przejęcia stacji roboczych, ustanowienia persystencji oraz wdrożenia ransomware z rodziny Chaos.

W skrócie

  • Kampania oznaczona jako STAC4749 była obserwowana od lutego do czerwca 2026 roku.
  • Celem były dziesiątki organizacji w Ameryce Północnej, głównie w USA i Kanadzie.
  • Napastnicy kontaktowali się z ofiarami przez Microsoft Teams, podszywając się pod helpdesk IT.
  • Ofiary były nakłaniane do uruchomienia Quick Assist lub innych narzędzi zdalnej administracji.
  • Po uzyskaniu dostępu atakujący wdrażali skrypty PowerShell, backdoory i implanty C2.
  • W co najmniej trzech przypadkach końcowym etapem było uruchomienie Chaos ransomware.
  • W jednym z incydentów od pierwszego kontaktu do szyfrowania minęło mniej niż 17 godzin.

Kontekst / historia

Nadużywanie Microsoft Teams do działań socjotechnicznych nie jest nowym zjawiskiem, jednak w 2026 roku technika ta wyraźnie zyskała na znaczeniu. Wcześniejsze operacje również wykorzystywały zewnętrzne konta i podszywanie się pod wsparcie techniczne, ale obecna kampania wyróżnia się większą dojrzałością operacyjną, lepszym przygotowaniem infrastruktury oraz szybkim przechodzeniem od dostępu początkowego do etapu ransomware.

Analizowane przypadki dotyczyły organizacji z wielu branż, w tym usług, produkcji, energetyki, budownictwa i inżynierii. Taki profil ofiar wskazuje na motywację finansową, a nie na wyspecjalizowane działania wymierzone w jeden sektor. Badacze zwracają również uwagę, że operatorzy stale zmieniali nazwy plików, mechanizmy persystencji i sposób dostarczania ładunków, aby utrudnić detekcję opartą wyłącznie na statycznych wskaźnikach kompromitacji.

Analiza techniczna

Atak rozpoczynał się od wiadomości lub połączenia głosowego w Microsoft Teams z kont zewnętrznych podszywających się pod dział IT. W celu zwiększenia wiarygodności przestępcy korzystali z domen tematycznie powiązanych z pomocą techniczną i bezpieczeństwem. Głównym celem rozmowy było przekonanie użytkownika do uruchomienia sesji zdalnej, najczęściej za pomocą Microsoft Quick Assist, a w innych przypadkach przy użyciu alternatywnych narzędzi RMM, takich jak RemSupp.

Po uzyskaniu interaktywnego dostępu napastnicy uruchamiali PowerShell i pobierali pierwszy ładunek do katalogów dostępnych dla użytkownika, najczęściej do AppData\Roaming. Początkowo był to loader odpowiedzialny za rozpoznanie systemu, ustanowienie persystencji oraz pobranie kolejnych komponentów, ale z czasem łańcuch infekcji został uproszczony i częściej wdrażano bezpośrednio backdoor.

Złośliwe oprogramowanie zbierało informacje o hoście, w tym nazwę komputera, identyfikator maszyny, wersję systemu operacyjnego oraz dane z rejestru Windows. Dodatkowo próbowało identyfikować aktywne rozwiązania bezpieczeństwa, co mogło pomóc operatorom dobrać dalsze techniki omijania ochrony.

Persystencja była realizowana głównie przez klucze Run w HKCU, maskowane jako legalne komponenty audio, między innymi nawiązujące nazwami do Realtek i WinAudio. Zaobserwowano także skrypty VBS tworzące skróty w folderze autostartu i podszywające się pod pozornie legalne pliki systemowe. Takie podejście zwiększało szansę na pozostanie niezauważonym podczas podstawowej analizy hosta.

Po ustanowieniu persystencji backdoor łączył się z infrastrukturą command-and-control i pobierał implanty napisane w Go. Komunikacja z serwerami C2 była dodatkowo zabezpieczona mechanizmami certificate pinning, co utrudniało analizę ruchu i wskazywało na wyższy poziom dojrzałości operacyjnej grupy. W części incydentów atakujący instalowali również dodatkowe narzędzia dostępu zdalnego, takie jak AnyDesk lub DWAgent, a także próbowali aktywować RDP na przejętych hostach.

Końcowym etapem operacji było wdrożenie Chaos ransomware. W kilku przypadkach szyfrowanie uruchamiano dopiero po rozszerzeniu dostępu na większą liczbę systemów, a w co najmniej jednym incydencie pojawiły się przesłanki wskazujące na wcześniejszą eksfiltrację danych. Na zainfekowanych systemach pozostawiano noty okupu zapisane jako readme.chaos.txt.

Konsekwencje / ryzyko

Największe ryzyko w tej kampanii wynika z połączenia skutecznej socjotechniki, legalnych narzędzi administracyjnych oraz bardzo krótkiego czasu potrzebnego do przejścia od pierwszego kontaktu do etapu ransomware. W praktyce oznacza to, że organizacje mogą nie zdążyć zareagować, jeśli nie monitorują aktywnie komunikatorów biznesowych i nietypowych sesji zdalnych.

Szczególnie problematyczne jest wykorzystywanie narzędzi powszechnie obecnych w środowiskach enterprise. Odróżnienie legalnej pomocy technicznej od aktywności napastnika staje się trudniejsze, a proste reguły IOC mogą okazać się niewystarczające. Nawet krótkotrwały dostęp interaktywny do stacji użytkownika może wystarczyć do ustanowienia trwałej obecności, ruchu bocznego i przygotowania środowiska do szyfrowania.

Rekomendacje

Organizacje powinny traktować Microsoft Teams jako pełnoprawną powierzchnię ataku i objąć go monitoringiem bezpieczeństwa. Szczególną uwagę należy zwrócić na wiadomości i połączenia od kont zewnętrznych, zwłaszcza jeśli dotyczą nagłego wsparcia technicznego lub zachęcają użytkownika do uruchomienia sesji zdalnej.

  • Wdrożyć detekcję dla nietypowego użycia PowerShell i pobierania plików do katalogów profilu użytkownika.
  • Monitorować tworzenie kluczy Run w HKCU, skrótów w folderach autostartu oraz uruchamianie plików z AppData i katalogów tymczasowych.
  • Ograniczyć użycie Quick Assist, AnyDesk, DWAgent i innych narzędzi RMM wyłącznie do zatwierdzonych scenariuszy administracyjnych.
  • Kontrolować próby aktywacji RDP oraz zmiany konfiguracji usług systemowych.
  • Szkolić pracowników, że dział IT nie inicjuje wsparcia przez niezweryfikowane połączenia bez wcześniejszego zgłoszenia.
  • Przygotować procedury szybkiej izolacji hosta i odcięcia aktywnych sesji zdalnych.

Kluczowe znaczenie ma także weryfikacja wszystkich próśb o instalację nowych narzędzi, uruchomienie zdalnego wsparcia lub wykonanie działań administracyjnych poza standardowym procesem helpdesk. Tego typu zgłoszenia powinny być traktowane jako potencjalne incydenty bezpieczeństwa.

Podsumowanie

Kampania STAC4749 pokazuje, że vishing w Microsoft Teams przekształcił się z prostego oszustwa socjotechnicznego w skuteczny wektor prowadzący bezpośrednio do ransomware. Połączenie podszywania się pod helpdesk, legalnych narzędzi zdalnego dostępu, modularnego malware i szybkiej eskalacji sprawia, że zagrożenie jest szczególnie istotne dla organizacji intensywnie korzystających z platform współpracy chmurowej.

Najważniejszy wniosek jest praktyczny: ochrona poczty elektronicznej nie wystarcza. Komunikatory firmowe, połączenia głosowe, narzędzia wsparcia zdalnego oraz mechanizmy persystencji na endpointach muszą być objęte wspólną strategią detekcji i reakcji.

Źródła

  1. BleepingComputer — https://www.bleepingcomputer.com/news/security/microsoft-teams-vishing-attacks-lead-to-chaos-ransomware-attacks/
  2. Sophos — Chaos in Teams vishing — https://www.sophos.com/en-us/blog/chaos-in-teams-vishing