Starsze próbki łączą się z serwerem kontrolowanym przez napastnika za pomocą nieszyfrowanego HTTP i wykorzystują zadania zapisane w formacie JSON. Raporty opisują bardzo częste odpytywanie serwera — nawet mniej więcej co sekundę — co może tworzyć charakterystyczny wzorzec widoczny w telemetrii sieciowej lub na punkcie końcowym.
Beacon identyfikuje ofiarę za pomocą danych obejmujących między innymi:
Informacje te są wysyłane na ścieżkę /api/beacon, natomiast wyniki wykonanych poleceń trafiają na /api/result/.
Zestaw dostępnych poleceń daje operatorowi praktyczną kontrolę nad zainfekowanym systemem. Obejmuje on:
Szczególnie interesujący jest mechanizm aktualizacji wykorzystujący polecenie upload. Malware pobiera przenośny plik wykonywalny z adresu URL podanego przez operatora i zapisuje go jako bibliotekę DLL w lokalnym katalogu OneDrive użytkownika. Następnie może zatrzymać proces OneDrive i wykorzystać legalny plik wykonywalny OneDrive do załadowania podstawionej biblioteki w ramach tzw. DLL sideloadingu. W analizowanych próbkach używano pliku wtsapi32.dll w lokalizacji %LocalAppData%\\Microsoft\\OneDrive.
Sideloading DLL polega na umieszczeniu złośliwej biblioteki obok zaufanego programu i wykorzystaniu jego normalnego mechanizmu ładowania zależności. Dla zespołów bezpieczeństwa ważnym sygnałem nie jest więc sama obecność OneDrive, lecz sytuacja, w której legalny plik OneDrive ładuje nieoczekiwaną bibliotekę z nietypowego lub zapisywalnego przez użytkownika katalogu.
C2Looper wykorzystuje deszyfrowanie napisów w czasie działania przy użyciu operacji XOR. Według dostępnych analiz stosowany klucz ma osiem bajtów i jest ponownie wykorzystywany. Malware dynamicznie rozwiązuje także funkcje systemu Windows za pośrednictwem LoadLibrary i GetProcAddress. Takie techniki mogą ograniczać skuteczność prostej analizy statycznej, zwiększając znaczenie telemetrii behawioralnej z narzędzi EDR.
Nowsza kompilacja C2Looper zastępuje tradycyjny serwer C2 repozytoriami GitHub. Służą one do przekazywania zadań, rejestrowania beaconów, odbierania wyników poleceń, a według opisów nowszego wariantu także do przechowywania danych związanych z ładunkami.
Każdy zainfekowany komputer otrzymuje własny katalog w repozytorium. Implant odczytuje instrukcje z pliku cmd.json, wykonuje wskazane działanie, a następnie zapisuje wynik w pliku result.json w tym samym katalogu. Operator otrzymuje w ten sposób prosty, oparty na plikach mechanizm wydawania poleceń i zbierania odpowiedzi bez konieczności utrzymywania klasycznego serwera C2.
Wykorzystanie GitHuba może utrudniać proste blokowanie domen, ponieważ serwis jest legalną infrastrukturą używaną przez programistów, firmy i systemy automatyzacji. Obrona powinna więc opierać się przede wszystkim na zachowaniu: warto badać cykliczne połączenia z repozytoriami lub API GitHuba z punktów końcowych, które zwykle nie potrzebują takich usług, oraz odróżniać podejrzaną aktywność z plikami JSON dla poszczególnych hostów od zatwierdzonych procesów programistycznych i CI/CD.
Przejście na GitHuba oraz dodatkowe możliwości wykonywania ładunków wskazane w nowszych próbkach sugerują, że C2Looper pozostaje aktywnie rozwijanym zagrożeniem.
ThreatLabz ocenia z niską lub średnią pewnością, że C2Looper może być dostarczany za pośrednictwem wieloetapowego łańcucha infekcji ClickFix. W tego typu kampaniach ofiara widzi fałszywy monit weryfikacyjny, błąd przeglądarki, CAPTCHA lub komunikat rzekomo informujący o konieczności naprawy systemu. Następnie jest nakłaniana do skopiowania i uruchomienia polecenia w PowerShellu, oknie Uruchamianie systemu Windows albo innym interfejsie poleceń.
To sprawia, że interakcja z użytkownikiem jest kluczowym punktem zapobiegania. Strona internetowa ani komunikat przeglądarki nie powinny wymagać wklejania poleceń do PowerShella, Terminala czy okna Uruchamianie w celu zakończenia weryfikacji lub naprawy problemu.
W szerszym ekosystemie socjotechniki opisywane są również kampanie wykorzystujące vishing w Microsoft Teams oraz nadużywanie narzędzia Quick Assist. Dostępne dowody nie potwierdzają jednak, że każda tego typu kampania dostarczała C2Looper. Należy traktować te podobieństwa jako prawdopodobny kontekst, a nie potwierdzone przypisanie kampanii.
Organizacje mogą skoncentrować się na kilku zachowaniach o wysokiej wartości detekcyjnej, zamiast próbować blokować każde narzędzie lub usługę potencjalnie powiązaną z malware’em:
/api/beacon i /api/result/, jeśli pojawiają się w połączeniu z nowym lub podejrzanym procesem. cmd.json i result.json. Nie należy blokować GitHuba bez rozróżnienia — trzeba uwzględnić legalne procesy deweloperskie i automatyzację. cmd.exe, aktywności okna Uruchamianie, rozpoznania systemu, etapowego pobierania plików i uruchamiania powłoki przez nowo zaobserwowane binaria. Kontrole techniczne powinny być połączone z ochroną przed socjotechniką. Tam, gdzie pozwalają na to wymagania biznesowe, warto ograniczyć lub kontrolować uruchamianie PowerShella, skryptów, niepodpisanych plików binarnych oraz programów z katalogów zapisywalnych przez użytkownika. Dodatkową warstwę ochrony może zapewnić allowlisting aplikacji, czyli uruchamianie wyłącznie zatwierdzonego oprogramowania.
Pracownicy i zespoły wsparcia technicznego powinni wiedzieć, że nie należy wklejać poleceń przekazywanych przez stronę internetową, CAPTCHA, komunikat o błędzie przeglądarki ani nieoczekiwany kontakt z rzekomym konsultantem. Narzędzia zdalnej pomocy powinny być używane w zatwierdzonych procedurach, przez zweryfikowane kanały, z silnym uwierzytelnianiem, rejestrowaniem sesji i szybką analizą nietypowych połączeń.
Segmentacja sieci, zasada najmniejszych uprawnień, uwierzytelnianie wieloskładnikowe, szybkie aktualizowanie systemów wystawionych do internetu oraz przetestowane kopie zapasowe offline lub niezmienialne mogą ograniczyć skutki uzyskania dostępu przez napastnika. Jeśli na punkcie końcowym pojawi się podejrzany beaconing, aktywność powłoki lub sideloading DLL, należy niezwłocznie odizolować urządzenie, zachowując logi systemowe, dane sieciowe oraz — w razie potrzeby — obraz pamięci do dalszego postępowania.
Znaczenie C2Looper wynika przede wszystkim z jego ewolucji: od stosunkowo prostego backdoora komunikującego się przez HTTP do bardziej elastycznego implantu, który może wykorzystywać repozytoria GitHub jako infrastrukturę operacyjną. Zdalna powłoka, rozpoznanie, pobieranie plików i aktualizowanie implantu czynią z niego wiarygodne narzędzie do uzyskania przyczółka przed atakiem ransomware. Dostępne dowody uzasadniają jednak ostrożną ocenę, a nie definitywne przypisanie do konkretnej grupy.
Najlepsza strategia obrony łączy odporne na ClickFix procedury użytkowników z polowaniem na zachowania: nietypowe wykonywanie poleceń, sideloading DLL przez OneDrive, bardzo częste odpytywanie HTTP oraz niewyjaśnioną aktywność w repozytoriach GitHub.