
Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Nadużywanie zaufanej infrastruktury chmurowej do maskowania komunikacji command-and-control staje się jednym z najpoważniejszych wyzwań dla zespołów bezpieczeństwa. W opisywanym przypadku grupa DragonForce wykorzystała mechanizmy powiązane z Microsoft Teams, aby sprawić, że ruch złośliwego oprogramowania wyglądał jak legalna aktywność biznesowa. Taka technika znacząco utrudnia wykrywanie incydentu na poziomie sieci, ponieważ połączenia mogą przypominać standardowe sesje użytkowników korzystających z narzędzi współpracy.
To ważny sygnał ostrzegawczy dla organizacji, które nadal opierają ochronę głównie na reputacji domen, adresów IP i listach dozwolonych usług chmurowych. Jeżeli napastnik potrafi ukryć kanał C2 wewnątrz zaufanego ekosystemu, tradycyjne metody filtrowania ruchu przestają być wystarczające.
W skrócie
- DragonForce utrzymywał obecność w środowisku ofiary przez okres od jednego do dwóch miesięcy.
- Atakujący użyli niestandardowego backdoora Backdoor.Turn napisanego w języku Go.
- Komunikacja C2 była tunelowana przez infrastrukturę relay powiązaną z Microsoft Teams.
- W kampanii wykorzystano DLL sideloading, iniekcję do legalnego procesu oraz techniki BYOVD.
- Napastnicy prowadzili rekonesans, ruch lateralny, kradzież poświadczeń i działania utrzymujące dostęp po ataku ransomware.
Kontekst / historia
DragonForce to grupa ransomware aktywna co najmniej od 2023 roku, która z czasem rozwinęła model działania w kierunku bardziej dojrzałej i zorganizowanej struktury. Tego typu ewolucja zwykle oznacza lepszą specjalizację operatorów, większe zaplecze techniczne oraz zdolność do budowania własnych narzędzi wykorzystywanych na różnych etapach ataku.
Analizowana kampania pokazuje, że grupa nie polega wyłącznie na typowych narzędziach dostępnych na cyberprzestępczych forach. Zamiast tego wdraża własne komponenty malware i łączy je z nowoczesnymi metodami obchodzenia zabezpieczeń. Szczególnie niepokojące jest wykorzystanie infrastruktury związanej z popularnym środowiskiem komunikacyjnym, ponieważ ruch do takich usług bywa domyślnie zaufany i słabiej kontrolowany.
Według opisu incydentu początkowy dostęp mógł zostać uzyskany przez podatność w środowisku SQL lub Microsoft SQL Server. Nie wykluczono także scenariusza zakupu dostępu od brokera dostępu. Po kompromitacji sieci, od grudnia 2025 roku, operatorzy rozwijali kolejne etapy infekcji i rozszerzali swoją obecność w środowisku ofiary.
Analiza techniczna
Kluczowym elementem operacji był backdoor Backdoor.Turn. Malware pozyskiwał anonimowy token gościa, następnie zestawiał połączenie przez legalny serwer TURN, a później uruchamiał sesję QUIC do właściwego serwera kontrolowanego przez napastników. Dzięki temu z perspektywy monitoringu sieciowego ruch mógł wyglądać jak zwykła komunikacja związana z Microsoft Teams, a nie jak klasyczny kanał sterowania malware.
To podejście istotnie przesuwa ciężar detekcji z warstwy sieciowej na telemetrykę endpointów, analizę zachowań procesów oraz korelację zdarzeń związanych z tożsamością i sesjami. Organizacje, które ufają samemu faktowi komunikacji z rozpoznawalną usługą chmurową, mogą przez długi czas nie zauważyć aktywności intruza.
Backdoor został napisany w Go i wstrzyknięty do legalnego procesu DbgView64.exe. Po uruchomieniu umożliwiał wykonywanie poleceń, skanowanie sieci, mapowanie środowiska Active Directory, przemieszczanie się lateralne z użyciem przejętych poświadczeń oraz pozyskiwanie haseł zapisanych w przeglądarkach. Z punktu widzenia obrony był to więc wielofunkcyjny komponent wspierający zarówno rekonesans, jak i utrzymanie dostępu oraz dalsze działania poeksploatacyjne.
We wcześniejszej fazie ataku wykorzystano archiwum ZIP zawierające legalny plik wykonywalny VirtualBox oraz złośliwą bibliotekę DLL ładowaną metodą sideloadingu. Takie podejście pozostaje skuteczne, ponieważ opiera się na zaufanych binariach i legalnych ścieżkach wykonywania kodu, co utrudnia jednoznaczne odróżnienie aktywności prawidłowej od złośliwej.
Na etapie omijania zabezpieczeń operatorzy zastosowali technikę Bring Your Own Vulnerable Driver. Wskazano użycie wielu podpisanych sterowników, w tym komponentu HWAuidoOs2Ec.sys. Dodatkowo użyto także niestandardowego złośliwego sterownika podszywającego się pod legalny komponent Palo Alto, co pokazuje, że kampania wykraczała poza klasyczne nadużywanie znanych podatnych sterowników i obejmowała również własne mechanizmy maskowania.
Istotny jest również moment wdrożenia Backdoor.Turn, który miał nastąpić po uruchomieniu ransomware. Taki układ sugeruje, że celem mogło być pozostawienie trwałego dostępu do środowiska po głównej fazie ataku albo przygotowanie zaplecza do dalszego wykorzystania lub odsprzedaży dostępu.
Konsekwencje / ryzyko
Incydent pokazuje, że klasyczne podejście do wykrywania zagrożeń, oparte głównie na sygnaturach sieciowych i reputacji domen, nie zapewnia już wystarczającej ochrony. Jeżeli komunikacja C2 przebiega przez zaufaną usługę chmurową, wiele narzędzi bezpieczeństwa może błędnie uznać taki ruch za nieszkodliwy.
Dla organizacji oznacza to wzrost ryzyka na kilku poziomach. Po pierwsze, wydłuża się czas obecności napastnika w środowisku, co zwiększa skalę rekonesansu, kradzieży danych i ruchu lateralnego. Po drugie, wykorzystanie sterowników oraz technik działających blisko poziomu jądra może osłabiać skuteczność rozwiązań EDR, a nawet ułatwiać ich obchodzenie. Po trzecie, użycie legalnych procesów i zaufanej infrastruktury utrudnia szybkie odróżnienie incydentu od normalnej aktywności operacyjnej.
Dla zespołów SOC i threat huntingu to wyraźny sygnał, że analiza behawioralna musi obejmować również ruch do popularnych platform komunikacyjnych oraz nietypowe zależności pomiędzy procesami, tożsamością użytkownika i aktywnością sieciową.
Rekomendacje
Organizacje powinny monitorować ruch do usług chmurowych w modelu opartym na kontekście, a nie wyłącznie na reputacji dostawcy. Sam fakt, że połączenie trafia do znanej platformy biznesowej, nie może być traktowany jako wystarczający wskaźnik bezpieczeństwa.
Należy zwiększyć widoczność na poziomie endpointów, zwłaszcza w obszarach związanych z uruchamianiem legalnych narzędzi w nietypowym kontekście, iniekcją kodu, ładowaniem bibliotek DLL z niestandardowych lokalizacji oraz instalacją nowych sterowników.
- Egzekwować polityki allowlistingu sterowników i stale monitorować ich ładowanie.
- Blokować lub ograniczać użycie znanych podatnych sterowników podpisanych cyfrowo.
- Analizować ruch QUIC pod kątem anomalii oraz odstępstw od typowego profilu użytkowego.
- Monitorować nietypowe uruchomienia DbgView64.exe i podobnych narzędzi administracyjnych.
- Wzmacniać segmentację sieci i ograniczać uprawnienia kont serwisowych.
- Chronić serwery SQL i MSSQL poprzez szybkie łatanie, ograniczenie ekspozycji oraz monitorowanie prób wykonania kodu.
- Korelować zdarzenia związane z tokenami gościnnymi, sesjami tymczasowymi i połączeniami do usług współpracy.
- Regularnie testować odporność środowiska na techniki obejścia EDR i scenariusze BYOVD.
Z perspektywy reagowania na incydenty szczególnie ważne jest sprawdzenie, czy po ataku ransomware nie pozostawiono dodatkowych mechanizmów trwałości. W wielu przypadkach największym problemem nie jest samo szyfrowanie danych, lecz ukryty dostęp utrzymywany przez tygodnie lub miesiące po zakończeniu głównej fazy ataku.
Podsumowanie
Kampania DragonForce pokazuje rosnącą dojrzałość techniczną grup ransomware oraz zwrot w stronę bardziej wyrafinowanych metod ukrywania komunikacji C2. Wykorzystanie infrastruktury powiązanej z Microsoft Teams, sesji QUIC, DLL sideloadingu, malware napisanego w Go oraz technik BYOVD stworzyło łańcuch ataku trudny do wykrycia zarówno na poziomie sieci, jak i hosta.
Najważniejszy wniosek dla obrońców jest prosty: zaufana usługa nie oznacza zaufanej aktywności. Skuteczna detekcja wymaga połączenia telemetrii endpointowej, analizy behawioralnej, kontroli sterowników oraz szerszej widoczności nad ruchem do legalnych platform chmurowych.
Źródła
- Security Affairs – DragonForce Hid Inside Microsoft Teams and Nobody Noticed for Two Months
- Symantec – DragonForce hid for months by abusing Microsoft Teams
- Huntress – Technical analysis of vulnerable driver abuse involving HWAuidoOs2Ec.sys
- Black Hat – Ghost Calls research on covert C2 through communication infrastructure