Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Grupa powiązana z ransomware DragonForce została zaobserwowana podczas wykorzystywania legalnej infrastruktury Microsoft Teams do ukrywania komunikacji command-and-control. W opisywanym scenariuszu napastnicy użyli niestandardowego trojana zdalnego dostępu Backdoor.Turn, który tunelował ruch przez serwery pośredniczące TURN, utrudniając wykrycie aktywności przez zespoły bezpieczeństwa.
To istotny przykład ewolucji zagrożeń, w której zaufane usługi chmurowe stają się osłoną dla działań post-exploitation. Z perspektywy obrońców oznacza to, że sam fakt komunikacji z renomowanym dostawcą nie może już być traktowany jako wystarczający wskaźnik bezpieczeństwa.
W skrócie
Atakujący przypisywani DragonForce wdrożyli malware Backdoor.Turn przeciwko dużej firmie usługowej w USA. Implant pobierał anonimowy token gościa powiązany z usługami Teams i Skype, wykorzystywał legalny serwer relay TURN do zestawienia połączenia, a następnie uruchamiał sesję QUIC do właściwego serwera C2.
- ruch wyglądał jak zwykła komunikacja wychodząca do usług Microsoft,
- napastnicy utrzymywali obecność w środowisku ofiary przez około 1–2 miesiące,
- incydent uznano za pierwszy publicznie opisany przypadek nadużycia infrastruktury TURN Microsoft Teams przez tego typu aktora.
Kontekst / historia
DragonForce jest kojarzony z działalnością ransomware oraz rosnącym poziomem zaawansowania operacyjnego. W analizowanym przypadku aktywność w sieci ofiary rozpoczęła się w grudniu 2025 roku. Według dostępnych ustaleń początkowy dostęp mógł zostać uzyskany przez wykorzystanie podatności w serwerze SQL lub MS-SQL, choć dokładny wektor wejścia nie został jednoznacznie potwierdzony.
Po uzyskaniu dostępu napastnicy uruchomili polecenie PowerShell, które dostarczyło archiwum ZIP podszywające się pod poprawkę wsparcia technicznego. Łańcuch infekcji obejmował następnie sideloading biblioteki DLL, uruchomienie złośliwego modułu odpowiedzialnego za rekonesans, utrwalenie dostępu oraz osłabianie mechanizmów ochronnych.
W kampanii wykorzystano również technikę BYOVD, czyli Bring Your Own Vulnerable Driver. Polega ona na dostarczeniu legalnie podpisanego, ale podatnego sterownika, który może zostać użyty do obejścia zabezpieczeń systemowych i endpointowych.
Analiza techniczna
Najbardziej interesującym elementem operacji był sam Backdoor.Turn. To napisany w języku Go trojan RAT, którego zadaniem było ukrycie kanału sterowania w pozornie prawidłowym ruchu sieciowym. Mechanizm działania składał się z kilku etapów.
Najpierw malware pozyskiwał anonimowy token odwiedzającego z zaplecza tożsamości obsługującego Teams i Skype. Następnie używał legalnego serwera Microsoft pełniącego rolę przekaźnika TURN do ustanowienia połączenia wychodzącego. Po zakończeniu tej fazy uruchamiana była sesja QUIC do właściwego serwera C2 kontrolowanego przez operatorów ataku.
Z perspektywy monitoringu sieciowego oznaczało to, że widoczny był przede wszystkim ruch do legalnych serwerów Microsoft. Taki model znacząco utrudnia identyfikację złośliwej aktywności na podstawie prostych wskaźników, takich jak domena docelowa, reputacja adresu czy sama obecność połączenia do popularnej usługi SaaS.
Technika ta nawiązuje do podejścia określanego jako Ghost Calls, czyli nadużywania mechanizmów komunikacyjnych i relay do ukrywania kanału C2. W praktyce atakujący starają się wtopić w normalny ruch biznesowy, zamiast polegać na łatwo podejrzanej infrastrukturze.
Backdoor.Turn oferował szeroki zestaw funkcji typowych dla nowoczesnych implantów post-exploitation. Obejmowały one:
- wykonywanie poleceń,
- tworzenie procesów,
- skanowanie sieci,
- wyszukiwanie obiektów LDAP i Active Directory,
- ruch lateralny z użyciem poświadczeń,
- kradzież danych uwierzytelniających z przeglądarek.
Co istotne, implant został uruchomiony przez wstrzyknięcie do legalnego procesu DbgView64.exe już po wdrożeniu ransomware. Może to sugerować, że operatorzy chcieli utrzymać długoterminowy dostęp także po zakończeniu głównej fazy ataku i potencjalnie wrócić do środowiska ofiary w późniejszym czasie.
Dodatkowym mechanizmem obejścia zabezpieczeń było wykorzystanie podatnego sterownika Huawei HWAuidoOs2Ec.sys w modelu BYOVD. Tego typu technika pozwala wyłączyć lub osłabić działanie narzędzi ochronnych poprzez nadużycie legalnych komponentów działających na poziomie jądra systemu.
Konsekwencje / ryzyko
Ryzyko związane z tego typu operacją jest wysokie z kilku powodów. Po pierwsze, użycie legalnej infrastruktury chmurowej i znanych usług komunikacyjnych obniża skuteczność klasycznych mechanizmów blokowania opartych na reputacji. Po drugie, zastosowanie QUIC i relayingu TURN komplikuje inspekcję ruchu, szczególnie w organizacjach, które nie prowadzą pogłębionej analizy połączeń do usług SaaS.
Po trzecie, połączenie ransomware z trwałym backdoorem oznacza, że incydent nie musi kończyć się na jednorazowym szyfrowaniu danych. Organizacja może pozostać skompromitowana również po odtworzeniu systemów, jeśli nie wykryje dodatkowego implantu, mechanizmów persistence oraz nadużytych poświadczeń.
Po czwarte, wykorzystanie BYOVD zwiększa ryzyko skutecznego obchodzenia EDR i innych kontroli endpointowych. Dla zespołów SOC i IR jest to sygnał, że ruch do dużych dostawców chmurowych nie powinien być automatycznie uznawany za bezpieczny tylko dlatego, że korzysta z zaufanej infrastruktury.
Rekomendacje
Organizacje powinny wdrożyć monitorowanie anomalii w ruchu do usług chmurowych, zamiast ograniczać się wyłącznie do list dozwolonych dostawców. W praktyce oznacza to analizę nietypowych wzorców komunikacji do Microsoft 365, Teams oraz usług powiązanych z relay i tożsamością.
Warto rozszerzyć detekcję o następujące obszary:
- korelację uruchomień PowerShell z pobieraniem archiwów i nietypowych bibliotek DLL,
- wykrywanie DLL sideloading oraz code injection do legalnych procesów narzędziowych,
- monitorowanie tworzenia i ładowania sterowników podatnych lub nietypowych dla danej stacji,
- analizę użycia QUIC w kontekstach niezgodnych z profilem biznesowym hosta,
- kontrolę aktywności LDAP i AD wykonywanej przez procesy odbiegające od standardowego wzorca administracyjnego.
Po stronie hardeningu należy ograniczyć możliwość uruchamiania nieautoryzowanych sterowników, egzekwować aktualizacje systemów i serwerów SQL, a także stosować polityki application control oraz mechanizmy ochrony przed BYOVD. Istotne jest również blokowanie lub ścisłe monitorowanie narzędzi administracyjnych wykorzystywanych poza zatwierdzonymi ścieżkami operacyjnymi.
W obszarze reagowania na incydenty zalecane jest pełne polowanie na ślady persistence po ataku ransomware. Powinno ono obejmować analizę pamięci, przegląd legalnych procesów pod kątem iniekcji, walidację integralności sterowników oraz reset poświadczeń uprzywilejowanych i aktywnych sesji dostępowych. Samo usunięcie ładunku szyfrującego nie powinno być traktowane jako zakończenie incydentu.
Podsumowanie
Przypadek DragonForce i Backdoor.Turn pokazuje wyraźną zmianę w technikach ukrywania komunikacji C2. Zamiast polegać na podejrzanej infrastrukturze, napastnicy coraz częściej wykorzystują zaufane usługi biznesowe, aby wtopić się w normalny ruch sieciowy i utrudnić analizę incydentu.
Połączenie legalnych przekaźników TURN, sesji QUIC, iniekcji do prawidłowych procesów oraz techniki BYOVD tworzy trudny do wykrycia zestaw narzędzi post-exploitation. Dla obrońców oznacza to potrzebę głębszej analizy telemetrii endpointowej i sieciowej oraz większej ostrożności wobec ruchu kierowanego do popularnych platform SaaS.
Źródła
- DragonForce Hackers Abuse Microsoft Teams Relays to Hide Backdoor.Turn C2 Traffic — https://thehackernews.com/2026/06/dragonforce-hackers-abuse-microsoft.html
- Microsoft Tech Community — TURN — https://techcommunity.microsoft.com/
- NVD CVE-2023-52271 — https://nvd.nist.gov/vuln/detail/CVE-2023-52271
- NVD CVE-2025-61155 — https://nvd.nist.gov/vuln/detail/CVE-2025-61155
- NVD CVE-2025-1055 — https://nvd.nist.gov/vuln/detail/CVE-2025-1055