Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Nowo opisany klaster zagrożeń oznaczony jako OP-512 został powiązany z kampanią wymierzoną w serwery Microsoft Internet Information Services (IIS). Napastnicy wykorzystują niestandardowy framework web shelli, którego zadaniem jest zapewnienie trwałego, trudnego do wykrycia dostępu do przejętego hosta oraz wsparcie dalszych działań po kompromitacji.
W praktyce oznacza to odejście od prostych, łatwo rozpoznawalnych implantów na rzecz zestawu narzędzi zaprojektowanych pod kątem unikania klasycznej detekcji, zaciemniania śladów oraz utrudniania analizy incydentu. Tego typu aktywność jest szczególnie niebezpieczna dla organizacji utrzymujących publicznie dostępne usługi webowe oparte o starsze środowiska Windows i .NET.
W skrócie
- OP-512 to wcześniej nieudokumentowany klaster aktywności ukierunkowany na serwery Microsoft IIS.
- Atakujący wdrażają zestaw trzech web shelli odpowiedzialnych za zarządzanie plikami, wykonywanie poleceń i raportowanie lokalizacji implantu.
- Kampania była obserwowana w środowisku opartym o Windows Server 2016 oraz niewspierany .NET Framework 4.0.
- Napastnicy stosują unikalne mechanizmy kryptograficzne dla każdej instancji oraz timestomping w celu ukrycia artefaktów.
- W dalszym etapie wykorzystywane są narzędzia z rodziny Potato do prób eskalacji uprawnień do poziomu SYSTEM.
Kontekst / historia
Serwery IIS od lat pozostają atrakcyjnym celem dla operatorów kampanii szpiegowskich i grup APT, ponieważ często pełnią rolę systemów brzegowych. Są one wystawione do internetu, a jednocześnie komunikują się z zasobami wewnętrznymi, co czyni je dogodnym punktem wejścia i platformą do dalszej penetracji środowiska.
W przypadku OP-512 badacze wskazali, że aktywność mogła rozpocząć się znacznie wcześniej niż główna faza incydentu. Oznaki wcześniejszej obecności na tym samym hoście, widoczne nawet około 75 dni przed ujawnieniem pełnej aktywności, sugerują metodyczne i cierpliwe działanie charakterystyczne dla operacji nastawionych na długotrwały dostęp oraz zbieranie informacji.
Znaczenie tej kampanii rośnie także dlatego, że jest to kolejny publicznie opisany przypadek skoncentrowany na IIS w krótkim czasie. Wskazuje to, że infrastruktura oparta o technologie Microsoft nadal pozostaje wysoko na liście priorytetów zaawansowanych przeciwników.
Analiza techniczna
Rdzeniem operacji był niestandardowy framework składający się z trzech web shelli. Pierwszy komponent, zapisany jako plik ASPX, pełnił rolę menedżera plików oraz mechanizmu samorejestracji. Po uruchomieniu implant automatycznie przekazywał informację o swojej lokalizacji do infrastruktury operatora, wykorzystując przede wszystkim DNS z zakodowaną ścieżką w subdomenie, a w wariancie zapasowym komunikację HTTP do oddzielnego serwera C2.
Dwa kolejne komponenty miały formę handlerów ASHX i służyły do wykonywania poleceń po uwierzytelnieniu. Ich logika obejmowała wieloetapowe przetwarzanie danych wejściowych: dekodowanie Base64, odszyfrowanie RC4, weryfikację podpisu RSA i dopiero potem uruchomienie komendy. Takie podejście utrudnia analizę ruchu oraz ogranicza skuteczność prostych reguł detekcyjnych.
Istotnym wyróżnikiem OP-512 była unikalność każdej instancji web shella. Operatorzy losowali nazwy metod i zmiennych, a także dodawali zbędne fragmenty kodu, aby utrudnić tworzenie stabilnych sygnatur opartych na hashach lub prostych wzorcach tekstowych. W praktyce oznacza to, że nawet wykrycie jednego wariantu nie gwarantuje skutecznego zablokowania kolejnych.
Kolejną techniką maskowania był timestomping. Web shelle analizowały pliki i katalogi znajdujące się w otoczeniu, wyznaczały medianę czasu modyfikacji, a następnie nadpisywały własne znaczniki czasu tak, aby wyglądały na elementy obecne w systemie od dawna. To znacząco utrudnia pracę zespołów forensic, które często polegają na osi czasu zmian w katalogach aplikacyjnych.
Po wdrożeniu implantów napastnicy przechodzili do fazy post-exploitation. Telemetria wskazuje na ładowanie narzędzi bezpośrednio do pamięci procesu w3wp.exe, co pozwalało ograniczyć liczbę śladów na dysku. Wśród obserwowanych narzędzi znalazły się BadPotato, SweetPotato oraz EfsPotato, używane do prób eskalacji uprawnień. Następnie wykonywano polecenia diagnostyczne służące do ustalenia kontekstu użytkownika i zakresu posiadanych przywilejów.
Istotnym problemem operacyjnym okazały się także biblioteki DLL generowane przez ASP.NET w katalogach tymczasowej kompilacji. Nawet jeśli oryginalne pliki ASPX lub ASHX zostały usunięte, skompilowane artefakty mogły nadal pozostać na serwerze. To oznacza, że powierzchowne czyszczenie środowiska po incydencie może nie wystarczyć do pełnego usunięcia skutków kompromitacji.
Konsekwencje / ryzyko
Największe ryzyko związane z OP-512 wynika z połączenia trwałości, elastyczności oraz niskiej podatności na klasyczną detekcję sygnaturową. Organizacje korzystające z publicznie dostępnych serwerów IIS, zwłaszcza opartych o starsze platformy, powinny traktować takie zagrożenie jako wysoki priorytet operacyjny.
Skutki kompromitacji mogą obejmować długotrwałą obecność atakującego w środowisku, rekonesans sieci wewnętrznej, kradzież danych, podsłuch komunikacji administracyjnej, a także wykorzystanie serwera webowego jako punktu pivotingu do kolejnych etapów ataku. Dodatkowo szyfrowanie i uwierzytelnianie komend utrudnia analizę ruchu sieciowego, a manipulacja metadanymi plików komplikuje rekonstrukcję przebiegu incydentu.
Z perspektywy obrony szczególnie niebezpieczne jest to, że samo zatrzymanie złośliwego procesu lub usunięcie pojedynczego pliku nie musi oznaczać końca zagrożenia. Automatyczne odtwarzanie procesów IIS oraz obecność skompilowanych artefaktów ASP.NET mogą umożliwić dalszą aktywność lub utrudnić pełne oczyszczenie hosta.
Rekomendacje
W pierwszej kolejności organizacje powinny zinwentaryzować wszystkie serwery IIS dostępne z internetu i sprawdzić, czy nie korzystają one z niewspieranych wersji .NET Framework lub przestarzałych komponentów aplikacyjnych. Jeżeli natychmiastowa migracja nie jest możliwa, należy ograniczyć ekspozycję usług, wzmocnić segmentację sieciową i wdrożyć podwyższony monitoring tych zasobów.
Od strony detekcji kluczowe jest skupienie się na zachowaniach zamiast wyłącznie na sygnaturach plików. Warto monitorować zarówno aktywność procesów IIS, jak i anomalie w ruchu sieciowym oraz systemie plików.
- Nietypowe zapytania DNS inicjowane przez proces w3wp.exe, zwłaszcza z długimi i zakodowanymi subdomenami.
- Ładowanie komponentów .NET do pamięci procesu IIS metodami refleksyjnymi.
- Pojawianie się nowych plików ASPX lub ASHX poza standardowym cyklem wdrożeniowym.
- Generowanie bibliotek DLL w katalogach tymczasowej kompilacji ASP.NET.
- Nietypowe odpowiedzi z endpointów ASHX, w tym zaszyfrowane lub niestandardowe treści.
- Próby eskalacji uprawnień z użyciem narzędzi z rodziny Potato.
W procesie reagowania na incydent należy odizolować host przed rozpoczęciem analizy interaktywnej. Zespół bezpieczeństwa powinien założyć, że wejście w interakcję z web shellem może uruchomić mechanizmy powiadamiania operatora. Niezbędne jest również sprawdzenie pamięci procesu IIS, przegląd logów DNS i HTTP, analiza ścieżek aplikacyjnych oraz dokładne oczyszczenie katalogów tymczasowej kompilacji ASP.NET.
Długoterminowo warto wdrożyć EDR zapewniający widoczność aktywności .NET, monitoring integralności plików dla katalogów aplikacyjnych oraz polityki wykrywania anomalii dla serwerów w strefie DMZ. Ochrona serwerów webowych nie powinna opierać się wyłącznie na blokowaniu znanych hashy i prostych IOC.
Podsumowanie
OP-512 pokazuje, że serwery Microsoft IIS pozostają atrakcyjnym celem dla zaawansowanych operacji nastawionych na długoterminowy dostęp i działania szpiegowskie. Kampania wyróżnia się zastosowaniem niestandardowego frameworka web shelli, unikalnością kryptograficzną każdej instancji, automatycznym raportowaniem kompromitacji oraz technikami utrudniającymi analizę forensic.
Dla obrońców najważniejsza lekcja jest jednoznaczna: sama detekcja sygnaturowa to za mało. Priorytetem powinny być aktualizacja przestarzałych komponentów, pełna widoczność aktywności procesów IIS, analiza behawioralna oraz dokładne procedury reagowania obejmujące także artefakty kompilacji ASP.NET.
Źródła
- New Threat Cluster OP-512 Targets Microsoft IIS Servers with Custom Web Shell Framework — https://thehackernews.com/2026/06/new-threat-cluster-op-512-targets.html
- ReliaQuest’s Agentic AI Uncovers New China-Linked Cluster OP-512 — https://reliaquest.com/blog/threat-spotlight-reliaquests-agentic-ai-uncovers-new-china-linked-cluster-op-512
- MITRE ATT&CK: Timestomp — https://attack.mitre.org/techniques/T1070/006/