SilverFox: trzy sterowniki BYOVD chroniły ValleyRAT

30 lipca 2026 roku opisano nową kampanię grupy SilverFox wymierzoną w japońską firmę z sektora produkcji przemysłowej. Łańcuch kończył się wdrożeniem ValleyRAT, znanego również jako Winos 4.0, ale najciekawszym elementem była odporność mechanizmu obrony przed EDR: napastnicy połączyli trzy podatne sterowniki, DLL side-loading, odpinanie hooków NTDLL, wstrzykiwanie procesu oraz dwa niezależne watchdogi.

To rozwinięcie techniki Bring Your Own Vulnerable Driver (BYOVD). Atakujący nie musi wykorzystywać nowej luki w jądrze systemu. Dostarcza legalnie podpisany, lecz podatny sterownik, ładuje go, a następnie nadużywa jego uprzywilejowanych operacji do ingerencji w zabezpieczenia.

Potwierdzony łańcuch kampanii

Analiza Cato CTRL opisana 30 lipca przez The Hacker News wskazuje, że wejściem była wiadomość phishingowa stylizowana na fakturę. Materiały znajdowały się na legalnych usługach QQ i Tencent Cloud, co zwiększało wiarygodność i utrudniało blokowanie wyłącznie na podstawie reputacji domeny.

Pobrane archiwum ZIP zawierało program, który ściągał kolejne komponenty do DLL side-loadingu. Złośliwa biblioteka PDFCORE8.dll była ładowana przez legalne programy ConvertToPDF.exe albo PDFDirect.exe, powiązane z Zeon Corporation.

Loader osadzał trzy sterowniki:

• BootRepair.sys;
• EnPortv.sys;
• wsftprm.sys.

SilverFox używał wcześniej podatnych amsdk.sys i wsftprm.sys. W nowej kampanii badacze po raz pierwszy w tym kontekście zaobserwowali BootRepair.sys i EnPortv.sys. Nie oznacza to, że każdy produkt zawierający plik o takiej nazwie jest malware. Ryzyko wynika z konkretnej wersji, podatności, sposobu załadowania i następującego po niej zachowania.

Po co trzy sterowniki zamiast jednego

Trzy moduły nie były przypadkową redundancją. Tworzyły wymienny framework BYOVD. Jeżeli jeden sterownik nie działał na danej wersji Windows, został zablokowany przez politykę albo wykryty przez produkt bezpieczeństwa, operator mógł przejść do kolejnego bez przebudowy pozostałej części łańcucha.

Taka architektura daje trzy korzyści:

1. zgodność z większą liczbą środowisk;
2. odporność na blokowanie pojedynczego hasha lub certyfikatu;
3. modułowość, która pozwala podmieniać sterowniki niezależnie od loadera i ValleyRAT.

Z perspektywy obrony oznacza to, że reguła „zablokuj wsftprm.sys” jest potrzebna, lecz niewystarczająca. Należy wykrywać klasę: nowy sterownik ładowany przez nietypowy proces, po którym następuje ingerencja w procesy ochronne.

Dlaczego podpis cyfrowy nie rozwiązuje problemu

Sterownik jądra musi mieć wysoki poziom zaufania systemu. Podpis potwierdza pochodzenie pliku i integralność względem podpisanej wersji. Nie gwarantuje, że interfejs sterownika nie udostępnia niebezpiecznych operacji.

BYOVD wykorzystuje właśnie tę lukę w modelu zaufania. Podpisany sterownik może udostępniać możliwość arbitralnego odczytu lub zapisu pamięci, mapowania przestrzeni fizycznej, zakończenia procesów albo modyfikacji ustawień jądra. Funkcja mogła powstać dla diagnostyki lub obsługi sprzętu, lecz po załadowaniu przez napastnika staje się prymitywem ofensywnym.

Dlatego polityka powinna oceniać sterownik przez:

• producenta i podpis;
• dokładny hash oraz wersję;
• obecność na Microsoft Vulnerable Driver Blocklist;
• źródło instalacji;
• proces i użytkownika, który go ładuje;
• cel operacji w jądrze;
• zachowanie następujące bezpośrednio po instalacji.

DLL side-loading jako dyskretny start

Windows pozwala programom ładować biblioteki potrzebne do działania. Jeśli aplikacja wyszukuje DLL w katalogu roboczym przed bezpieczną lokalizacją systemową, napastnik może położyć obok legalnego pliku własną bibliotekę o oczekiwanej nazwie.

W tym przypadku legalne konwertery PDF ładowały PDFCORE8.dll. Użytkownik i część narzędzi mogły widzieć podpisany, rozpoznawalny plik EXE, choć wykonywany kod pochodził ze złośliwej DLL.

Detekcja powinna korelować:

• podpisany EXE uruchomiony z katalogu użytkownika lub archiwum;
• bibliotekę bez zgodnego podpisu w tym samym katalogu;
• nietypowy proces nadrzędny;
• utworzenie usługi sterownika;
• zapis plików .sys;
• następujące po tym manipulacje EDR i wstrzyknięcie do procesu.

Sam fakt ładowania prywatnej DLL nie jest złośliwy. Wiele aplikacji działa w ten sposób. Kluczowe jest połączenie pochodzenia, lokalizacji, podpisu i kolejnych zdarzeń.

NTDLL unhooking i wejście pod obserwację EDR

Produkty EDR często umieszczają hooki w funkcjach użytkownika, aby obserwować wywołania natywnego API Windows. Loader SilverFox wykonywał NTDLL unhooking, przywracając czystszy obraz biblioteki i usuwając część inline hooków.

Nie wyłącza to całej ochrony. EDR może zbierać telemetrię jądra, ETW, sterowników, sieci i zachowania procesów. Unhooking ogranicza jednak widoczność w jednym z istotnych punktów i w połączeniu z BYOVD może utrudnić reakcję.

Sygnały obejmują mapowanie świeżej kopii NTDLL, kopiowanie sekcji kodu do już załadowanego modułu, zmianę ochrony stron pamięci i nagłe rozbieżności w prologach funkcji. Reguły muszą być ostrożne, ponieważ narzędzia ochronne i diagnostyczne również mogą pracować z bibliotekami systemowymi.

Wstrzyknięcie ValleyRAT

Loader kontaktował się z 43.128.26[.]132, pobierał shellcode i uruchamiał nowy svchost.exe. Następnie używał techniki thread-context hijacking, aby rozpocząć wykonanie w tym procesie.

Końcowym implantem był ValleyRAT, wariant Gh0st RAT zapewniający komunikację C2, wykonywanie zadań i dalsze operacje po kompromitacji. Nazwa svchost.exe nie czyni procesu legalnym. Zespół powinien analizować:

• proces nadrzędny;
• ścieżkę obrazu;
• token i sesję użytkownika;
• czas utworzenia względem pobrania archiwum;
• mapowane regiony pamięci bez pliku;
• połączenia sieciowe;
• wątki rozpoczynające się poza normalnymi modułami.

Dwa watchdogi tworzą pętlę odzyskiwania

Łańcuch wykorzystywał wewnętrzną funkcję nadzorującą wstrzyknięty payload oraz zewnętrzny skrypt batch monitorujący loader. Jeżeli ValleyRAT w svchost.exe został zakończony, loader tworzył go ponownie. Jeżeli obrońca zatrzymał loader, skrypt uruchamiał go ponownie przez zadanie harmonogramu.

To ważna lekcja dla reakcji. Zakończenie najbardziej podejrzanego procesu może dać chwilowe poczucie sukcesu, a jednocześnie uruchomić mechanizm odtworzenia. Izolacja powinna objąć:

• proces wstrzyknięty;
• loader;
• zadanie harmonogramu;
• skrypt watchdog;
• sterowniki i usługi;
• źródłowe archiwum;
• połączenie C2 i mechanizm pobierania.

Najbezpieczniej wykonać tę pracę na odizolowanym hoście z zachowaniem obrazu pamięci i artefaktów.

Kogo dotyczy kampania

Potwierdzony przypadek dotyczył japońskiej organizacji produkcyjnej. Nie ma publicznego dowodu masowej kampanii przeciwko wszystkim producentom ani wykorzystania tych samych trzech sterowników w Polsce. Przemysł jest jednak atrakcyjny ze względu na własność intelektualną, ciągłość produkcji, dostawców i starsze systemy.

Zagrożenie ma znaczenie dla każdej organizacji używającej Windows, jeżeli:

• użytkownik może uruchamiać niezatwierdzone programy;
• polityka pozwala ładować znane podatne sterowniki;
• EDR nie monitoruje instalacji usług jądra;
• allowlisting ufa każdemu podpisanemu plikowi;
• stacje produkcyjne mają szeroki dostęp do sieci;
• faktury trafiają bezpośrednio do użytkowników z prawem instalacji.

Detekcja warstwowa

Pojedynczy IOC będzie krótkotrwały. Silniejsza strategia łączy etapy:

1. dostarczenie — archiwum z usługi chmurowej po wiadomości fakturowej;
2. wykonanie — konwerter PDF z nietypowej lokalizacji;
3. side-loading — niepodpisana PDFCORE8.dll;
4. jądro — nowe BootRepair.sys, EnPortv.sys lub wsftprm.sys;
5. obrona — zakończenie procesów ochronnych i NTDLL unhooking;
6. wstrzyknięcie — nowy svchost.exe z nietypowym wątkiem;
7. trwałość — watchdog i zadanie harmonogramu;
8. C2 — połączenie do infrastruktury wskazanej w raporcie.

W praktyce warto utworzyć osobne reguły o średniej wadze, a następnie korelować je w krótkim oknie czasowym. Metodykę opisujemy w przewodniku detection engineering z Sigma i SIEM.

Reakcja i przywracanie

Po wykryciu kombinacji sygnałów:

1. odizoluj host od sieci;
2. zachowaj pamięć oraz listę sterowników, usług, zadań i połączeń;
3. nie ograniczaj się do zabicia svchost.exe;
4. zidentyfikuj oba watchdogi i loader;
5. sprawdź, jakie zabezpieczenia zostały zatrzymane;
6. przeszukaj środowisko po źródłowym ZIP, DLL, sterownikach i infrastrukturze;
7. ustal konta oraz zasoby dostępne z urządzenia;
8. odbuduj system z zaufanego obrazu, jeśli potwierdzono dostęp jądra;
9. wymień poświadczenia użyte na hoście;
10. monitoruj aktywność kont po przywróceniu.

Dostęp do jądra osłabia wiarygodność lokalnych logów. Odbudowa jest zwykle bezpieczniejsza niż próba ręcznego usunięcia wszystkich elementów.

Polityka sterowników, która zatrzymuje cały wzorzec

Lista trzech nazw z tej kampanii jest dobrym początkiem polowania, ale słabą strategią długoterminową. Sterownik może zostać przemianowany, a operator może wymienić go na inną znaną podatną wersję. Skuteczniejsza polityka łączy listę blokowanych sterowników Microsoftu, reguły kontroli aplikacji, ograniczenie praw instalacji oraz telemetrię tworzenia usług jądra. Wyjątki muszą mieć właściciela, uzasadnienie biznesowe, wersję i termin ponownego przeglądu.

W środowisku testowym warto zmierzyć cztery rzeczy: czy polityka blokuje każdy z trzech artefaktów, czy generuje alarm przed uruchomieniem, czy legalne sterowniki produkcyjne nadal działają oraz czy wyłączenie EDR powoduje sygnał z niezależnej warstwy. To ostatnie jest kluczowe, ponieważ celem BYOVD jest właśnie osłabienie narzędzia, które miałoby zgłosić kolejne etapy.

Na stacjach biurowych instalacja nowej usługi typu kernel powinna być rzadkim zdarzeniem. Na systemach przemysłowych dopuszczalny zbiór może być szerszy, lecz jednocześnie bardziej stabilny. Pozwala to budować bazę zachowania na rolę urządzenia, zamiast ufać wyłącznie nazwie pliku lub ważnemu podpisowi.

W telemetrycznej osi czasu instalację sterownika należy połączyć z procesem nadrzędnym, źródłem pliku, zmianą stanu ochrony i uruchomieniem nowego svchost.exe. Szczególnie wartościowa jest sekwencja: aplikacja z katalogu użytkownika tworzy usługę jądra, znika proces zabezpieczający, a chwilę później proces systemowy nawiązuje nowe połączenie. Każdy sygnał osobno może mieć legalne wyjaśnienie; razem opisują cel BYOVD znacznie lepiej niż pojedynczy hash.

Retencja musi obejmować czas dostarczenia archiwum, nie tylko moment alarmu. Pozwala to ustalić, kto otrzymał tę samą przynętę i czy plik został skopiowany na inne stacje.

Atrybucja i granice informacji

Cato przypisuje obserwowany łańcuch grupie SilverFox. ValleyRAT i część technik są z nią kojarzone w wielu kampaniach. Oddzielna analiza 146 próbek Atlas RAT sugerowała szerszą dystrybucję narzędzia, ale związek Atlas RAT z SilverFox określono jako poszlakowy.

Nie należy zatem przypisywać każdej próbki ValleyRAT, Atlas RAT albo każdego użycia podatnego sterownika jednemu operatorowi. Dla obrony ważniejszy jest łańcuch zachowań niż etykieta grupy. Kontekst i poziomy pewności pomagamy porządkować w materiale o cyklu Cyber Threat Intelligence.

Źródła a wnioski Breachroad

Cato potwierdza przynętę fakturową, usługi QQ/Tencent, legalne pliki Zeon, trzy sterowniki, NTDLL unhooking, thread-context hijacking, dwa watchdogi i ValleyRAT. Nie ma publicznego potwierdzenia szerokiej skali ofiar.

Nasze rekomendacje dotyczące korelacji, priorytetu odbudowy i oceny podpisanych sterowników są wnioskami obronnymi. Organizacja może zweryfikować polityki aplikacji, sterowników, segmentację i telemetrię podczas audytu bezpieczeństwa IT.

Największą wartość daje połączenie technologii i zachowania. Szkolenia cyberbezpieczeństwa powinny uczyć weryfikacji faktur i archiwów, a zespoły techniczne muszą potrafić rozpoznać, że podpisany sterownik może być narzędziem ataku. Dalszy kontekst zapewnia przewodnik po atakach na łańcuch dostaw oprogramowania.