RANSOMWARE ACTIVEDIRECTORY CYBERBEZPIECZENSTWO

PAYLOAD uderza bez szyfrowania plików

Ransomware PAYLOAD wykorzystał dwie Group Policy w Active Directory, by sparaliżować firmę bez uruchamiania klasycznego szyfrowania.

PAYLOAD uderza bez szyfrowania plików

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.txt z udziału SYSVOL na pulpit oraz do katalogów głównych dysków C: i D: jako README-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.jpg przechowywany w SYSVOL,
  • 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.

VIDEO_FEED

SHARE_PACKET

>_ RELATED_PACKETS

Flink i Cleanfix po cyberatakach
CYBERATAK WYCIEKDANYCH RANSOMWARE

Flink i Cleanfix po cyberatakach

Dwa kolejne ataki wyciekami danych uderzyły w Flink i Cleanfix. W sieci mogą pojawić się dane klientów, partnerów i dostawców.

Execute