PAYLOAD uderza bez szyfrowania plików
Ransomware PAYLOAD wykorzystał dwie Group Policy w Active Directory, by sparaliżować firmę bez uruchamiania klasycznego szyfrowania.
PAYLOAD pokazuje nowy sposób na ransomware
Atak ransomware zwykle kojarzy się z szyfrowaniem plików i blokadą systemów. W przypadku PAYLOAD scenariusz wyglądał inaczej: napastnicy nie uruchomili klasycznego szyfrowania na stacjach roboczych, lecz wykorzystali dwie Group Policy Objects (GPO) w Active Directory, by sparaliżować działanie całej organizacji.
Celem była firma z sektora przemysłowego na Bliskim Wschodzie. Choć jej nazwa nie została ujawniona, opis incydentu dobrze pokazuje, jak mocno atakujący mogą dziś nadużywać mechanizmów administracyjnych, które normalnie służą do centralnego zarządzania środowiskiem Windows.
Jak doszło do ataku
Według analizy, pierwsze ślady aktywności pojawiły się 11 kwietnia 2026 r., kiedy napastnik zalogował się do firmowego VPN SSL FortiGate przy użyciu prawidłowego, ale wcześniej przejętego konta domenowego. Nie wiadomo, czy dostęp uzyskano przez password spraying, phishing, czy też zakup danych od pośrednika dostępu początkowego.
Dwa dni później atakujący miał już uprawnienia porównywalne z administratorem domeny. Tego samego dnia rozpoczęto też eksfiltrację danych z serwerów plików i innych systemów, a później informacje trafiły do publikacji w darknecie.
Dwie GPO zamiast szyfrowania
Zamiast wdrażać ransomware na każdej maszynie, napastnik utworzył GPO o nazwie „PAYLOAD” i podłączył ją do roota domeny. To oznaczało, że polityka zaczęła obejmować praktycznie wszystkich użytkowników i wszystkie stacje robocze w domenie.
Ta pojedyncza polityka wykonywała kilka działań:
- kopiowała plik z żądaniem okupu
hello.txtz udziału SYSVOL na pulpit oraz do katalogów głównych dyskówC:iD:jakoREADME-payload.txt, - modyfikowała wpisy rejestru legalnoticecaption i legalnoticetext, aby podczas logowania wyświetlać komunikat z żądaniem okupu i tytułem „Welcome to Payload!”,
- podmieniała tapetę oraz ekran blokady na obraz
payload.jpgprzechowywany wSYSVOL, - wyłączała wbudowane konto Administrator na stacjach roboczych.
Druga polityka, nazwana „win Firewall Off”, wyłączała Zapora Windows dla profili domenowego, prywatnego i publicznego. W praktyce atakujący zapewnili sobie szerokie pole manewru i utrudnili obronę infrastruktury.
Efekt pojawił się dopiero po restarcie
Z analizy historii Group Policy wynika, że GPO dotarły na stacje już 13 kwietnia, ale ich skutki stały się widoczne dopiero 14 kwietnia, gdy pracownicy zaczęli uruchamiać ponownie komputery. Wtedy w firmie masowo zaczęły pojawiać się tapety z żądaniem okupu, a działalność organizacji została zakłócona.
To ważny szczegół: w wielu środowiskach monitorowanie opiera się na wykrywaniu podejrzanych plików wykonywalnych lub procesów ransomware. Tutaj nic takiego nie wystąpiło. Na systemach Windows nie znaleziono ani szyfrowanych plików, ani złośliwego binarium, ani trwałej persystencji, ani podejrzanych procesów.
Jedyny odzyskany próbnik ransomware związany z tym incydentem dotyczył wariantu PAYLOAD dla ESXi i znajdował się na serwerach Linux.
Active Directory jako broń
To, co wyróżnia ten incydent, to sposób wykorzystania infrastruktury Windows. W tym przypadku całe uderzenie „żyło” wewnątrz Active Directory. GPO nie były jedynie kanałem dystrybucji złośliwego oprogramowania — stały się samym narzędziem ataku.
Nie jest to zupełnie nowa technika. W przeszłości podobne mechanizmy wykorzystywały już m.in. Ryuk, BlackCat i LockBit. Różnica polega na tym, że PAYLOAD ograniczył się do działań wykonywanych przez polityki grupowe, bez klasycznego etapu uruchamiania ransomware na endpointach.
Co może pomóc w wykrywaniu podobnych incydentów
Tego typu atak pokazuje, jak ważne jest nie tylko zabezpieczanie kont uprzywilejowanych, ale też dokładne monitorowanie zmian w katalogu i w politykach grupowych. W praktyce warto zwrócić uwagę na kilka obszarów:
- audyt zmian w Active Directory — szczególnie zdarzenia 5136, 5137 i 5141,
- monitorowanie atrybutu gPLink na poziomie root domeny,
- kontrolę zawartości SYSVOL, gdzie nie powinny pojawiać się nieoczekiwane obrazy, pliki tekstowe czy skrypty,
- rozdzielenie uprawnień do tworzenia i podpinania GPO,
- ochronę dostępu zdalnego i kont uprzywilejowanych przez MFA odporną na phishing, Windows LAPS oraz model administracji warstwowej.
Zalecane jest też stosowanie dodatkowych mechanizmów wykrywania, na przykład „kanaryjnych” GPO, których nieoczekiwane użycie może wskazać, że ktoś uzyskał możliwość zapisu do polityk grupowych.
Bez szyfrowania, ale z dużym wpływem na biznes
Największą zagadką pozostaje brak szyfrowania plików na stacjach roboczych. Jedna z hipotez zakłada, że był to świadomy zabieg — z pozostawieniem pełnego szyfrowania jako kolejnej fazy presji. Druga możliwość jest prostsza: operacja mogła zostać przerwana, zanim napastnicy zdążyli pójść dalej.
Niezależnie od przyczyny, incydent pokazuje wyraźnie, że ransomware nie zawsze musi szyfrować pliki, by skutecznie unieruchomić firmę. Wystarczy dobrze przejęte Active Directory i umiejętne wykorzystanie jego zaufanych mechanizmów.