Rumuński urząd gospodarki wodnej „Apele Române” zaatakowany ransomware: ok. 1000 systemów zaszyfrowanych przez nadużycie BitLockera - Security Bez Tabu

Rumuński urząd gospodarki wodnej „Apele Române” zaatakowany ransomware: ok. 1000 systemów zaszyfrowanych przez nadużycie BitLockera

Wprowadzenie do problemu / definicja luki

W weekend 20–22 grudnia 2025 rumuńska administracja gospodarki wodnej Administrația Națională „Apele Române” (ANAR) padła ofiarą ataku ransomware, który objął ok. 1000 systemów w centrali i 10 z 11 regionalnych administracji dorzeczy. Incydent dotknął głównie warstwę IT (serwery i stacje robocze), a nie systemy operacyjne OT sterujące infrastrukturą hydrotechniczną.

To zdarzenie jest dobrym przykładem trendu, który obserwujemy coraz częściej w sektorze publicznym i krytycznym: „ransomware” nie musi oznaczać wgrania egzotycznego szyfratora. Atakujący potrafią wykorzystać legalne mechanizmy systemu (tzw. living-off-the-land), aby uzyskać efekt paraliżu, a jednocześnie utrudnić detekcję i analizę.

W skrócie

  • Skala: ok. 1000 zaszyfrowanych/„zablokowanych” systemów; 10/11 jednostek regionalnych dotkniętych incydentem.
  • Zakres: serwery GIS, bazy danych, e-mail/web, DNS oraz stacje robocze Windows.
  • Technika: nadużycie wbudowanego w Windows BitLockera do zablokowania danych.
  • OT bez zmian: według komunikatów systemy OT nie zostały naruszone, a infrastruktura hydrotechniczna miała działać normalnie (koordynacja przez łączność głosową/radiową).
  • Żądanie okupu: pozostawiono notę z żądaniem kontaktu w terminie 7 dni.

Kontekst / historia / powiązania

„Apele Române” odpowiada za zarządzanie zasobami wodnymi i elementami infrastruktury hydrotechnicznej, a więc obszar, który w wielu krajach bywa klasyfikowany jako krytyczny (z punktu widzenia ciągłości działania państwa i bezpieczeństwa publicznego). Dlatego nawet „tylko IT” może mieć realne konsekwencje operacyjne: prognozowanie, raportowanie, dyspozytornie, obieg dokumentów, GIS i łączność to często krwioobieg działań terenowych.

W tle pojawia się też aspekt systemowy: w komunikatach cytowanych przez media wskazywano, że infrastruktura ANAR nie była wcześniej objęta krajowym systemem ochrony krytycznych infrastruktur IT, a po incydencie rozpoczęto działania integracyjne.

Analiza techniczna / szczegóły incydentu

1) Co dokładnie zostało dotknięte?

Z opisu incydentu wynika, że atak objął mieszankę typową dla środowisk administracji publicznej:

  • GIS (systemy informacji geograficznej),
  • serwery baz danych,
  • poczta i usługi web,
  • serwery DNS,
  • stacje robocze Windows oraz Windows Server.

To zestaw krytyczny dla pracy operacyjnej (planowanie, mapy, dane terenowe, komunikacja, rozliczenia), nawet jeśli sterowanie OT odbywa się osobnymi kanałami.

2) „Ransomware” przez BitLockera – dlaczego to ważne?

Najciekawszy technicznie element tej sprawy to ustalenie, że atakujący użyli BitLockera (wbudowanej funkcji Windows do szyfrowania dysków) w sposób złośliwy, by zablokować pliki na przejętych systemach.

To ma kilka praktycznych implikacji dla obrony:

  • mniej „sygnatur” malware – bo narzędzie jest legalne i często używane przez administratorów,
  • wyższe ryzyko błędnej interpretacji w SIEM/EDR, jeśli reguły „admin activity” są zbyt szerokie,
  • kluczowe staje się zarządzanie kluczami odzyskiwania (escrow) i kontrola uprawnień do włączania BitLockera.

3) Atak wektor i atrybucja

Na moment publikacji doniesień nie wskazano publicznie jednoznacznego wektora wejścia ani sprawcy (brak przypisania do konkretnej grupy).

Warto zauważyć, że przy scenariuszu „BitLocker jako szyfrator” atakujący zwykle potrzebują:

  • uprawnień administratora lokalnego lub domenowego (żeby masowo włączać szyfrowanie),
  • możliwości uruchamiania poleceń zdalnie (np. przez narzędzia administracyjne lub skrypty),
  • dostępu do kontrolerów domeny / polityk (GPO), jeśli szyfrowanie rozlewa się na dużą flotę.

To nie jest dowód na konkretną technikę w tym przypadku, ale pomaga zrozumieć, dlaczego wnioski obronne zwykle koncentrują się na AD, segmentacji i kontroli uprawnień.

Praktyczne konsekwencje / ryzyko

1) Ryzyko dla ciągłości działania

Nawet przy braku naruszenia OT, awaria warstwy IT potrafi:

  • opóźnić reakcję na zdarzenia hydrologiczne (mapy, dane, raporty),
  • utrudnić koordynację pracy terenowej,
  • zablokować obieg dokumentów i komunikację (e-mail),
  • zwiększyć ryzyko błędów operacyjnych, gdy organizacja przechodzi na tryb ręczny/telefoniczny.

W materiałach podkreślano, że dyspozytornie miały przejść na łączność głosową (telefon/radio), a podstawowe działania miały być kontynuowane.

2) Ryzyko danych i „podwójnego wymuszenia”

W dostępnych informacjach mowa jest o szyfrowaniu/zablokowaniu (ransom note), ale brak potwierdzenia publicznego, czy doszło do eksfiltracji danych.
W praktyce wiele kampanii łączy szyfrowanie z kradzieżą danych, więc organizacje zwykle muszą równolegle prowadzić analizę pod kątem wycieku (logi proxy, ruch wychodzący, konta uprzywilejowane, narzędzia do transferu).

3) Aspekt prawny i śledczy

Media informowały także o reakcji organów ścigania – wątek postępowania karnego pojawił się w relacjach dot. incydentu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „do wdrożenia” w organizacjach, które chcą ograniczyć ryzyko scenariusza „ransomware przez BitLocker” i podobnych ataków na IT w instytucjach publicznych/CI.

1) Kontrola BitLockera i kluczy odzyskiwania

  • Wymuś centralny escrow kluczy odzyskiwania (AD/Azure AD/MDM) i audytuj pokrycie.
  • Ogranicz, kto może włączać BitLockera masowo (role, GPO, MDM), oraz monitoruj zmiany polityk.
  • W SIEM/EDR zbuduj alerty na:
    • nagłe fale „Enable BitLocker / manage-bde”,
    • masowe modyfikacje ochrony dysku,
    • nietypowe procesy uruchamiające komponenty BitLockera (np. z kontekstu usług zdalnych).

2) Ochrona AD i kont uprzywilejowanych

  • Wprowadź Tiering / PAW (oddzielne stacje dla adminów), MFA wszędzie, gdzie to możliwe.
  • Zastosuj zasadę Just Enough Administration i Just-In-Time dla uprawnień wysokiego ryzyka.
  • Odetnij możliwość lateral movement: segmentacja, blokady administracji z „user VLAN” do serwerów.

3) Twarde kopie zapasowe i odtwarzanie

  • Kopie 3-2-1 + offline/immutable (nieosiągalne z domeny).
  • Regularne testy odtwarzania: RTO/RPO dla GIS, DB, poczty, DNS.
  • Oddziel backup adminów od zwykłego AD (inny las/tenant lub przynajmniej inne konta i strefy zaufania).

4) Reakcja na incydent (checklista „pierwsze 24–72 h”)

  • Izolacja segmentów, blokada kont podejrzanych, rotacja haseł uprzywilejowanych.
  • Szybkie ustalenie „blast radius”: które hosty mają włączony BitLocker i czy klucze są dostępne.
  • Zabezpieczenie artefaktów (logi, obrazy dysków krytycznych systemów) zanim rozpocznie się masowe odtwarzanie.

5) Polityka okupu

W komunikatach przywoływano podejście, by nie negocjować z atakującymi w ramach rekomendacji krajowych instytucji cyber. Niezależnie od polityki organizacji, decyzja o płatności powinna wynikać z analizy prawnej, ryzyka oraz realnych możliwości odtworzenia usług (a nie z presji czasu w nocie okupu).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Wątek wyróżniający tę sprawę na tle „klasycznych” ataków ransomware to użycie BitLockera zamiast dedykowanego szyfratora. To wpisuje się w szerszą kategorię ataków „LOTL”, gdzie przestępcy minimalizują własny kod na ofierze, a maksymalizują użycie narzędzi wbudowanych lub powszechnych (co utrudnia detekcję i atrybucję).

BleepingComputer wskazywał też, że to kolejny głośny incydent ransomware w Rumunii w ostatnich latach, przypominając m.in. o wcześniejszych atakach na podmioty krytyczne (energetyka, ochrona zdrowia).

Podsumowanie / kluczowe wnioski

  • Incydent w „Apele Române” pokazuje, że paraliż IT w instytucji odpowiedzialnej za zasoby wody może być poważnym problemem nawet bez naruszenia OT.
  • Technicznie najważniejsza lekcja to ryzyko nadużycia BitLockera: legalna funkcja bezpieczeństwa może stać się narzędziem wymuszenia, jeśli atakujący zdobędą uprawnienia administracyjne.
  • Dla obrony kluczowe są: kontrola uprawnień (AD), segmentacja, backupy offline/immutable oraz monitoring aktywności związanej z szyfrowaniem dysków.

Źródła / bibliografia

  1. BleepingComputer – raport o ataku na Romanian Waters (ANAR), skala i BitLocker. (BleepingComputer)
  2. Digi24 – szczegóły dot. zakresu systemów, BitLocker i kontekst działań krajowych zespołów. (Digi24)
  3. HotNews – aktualizacja o braku wpływu na działania kluczowe, komunikacja głosowa, OT bez zmian. (HotNews.ro)
  4. Europa Liberă România (RFE/RL) – informacje o bezpieczeństwie obiektów hydrotechnicznych i wątku śledczym. (Europa Liberă România)
  5. The Register – dodatkowe potwierdzenie skali i czasu rozpoczęcia ataku. (go.theregister.com)