Industroyer2 - niedokończony atak na ukraińską sieć elektroenergetyczną

8 kwietnia 2022 roku, godzina 16:10 czasu UTC. Gdzieś na terenie ukraińskiej stacji wysokiego napięcia należącej do Ukrenergo - krajowego operatora sieci przesyłowej - zaplanowane zadanie systemu Windows próbuje uruchomić plik o nazwie 108_100.exe. To niewielki program, zaledwie 37 kilobajtów. Gdyby zadziałał zgodnie z zamierzeniem swoich twórców, wysłałby sekwencję poleceń protokołem IEC 60870-5-104 do urządzeń automatyki stacyjnej, otwierając wyłączniki mocy na stacji wysokiego napięcia. Trwa szósty tydzień rosyjskiej inwazji na Ukrainę. Rakiety uderzają w infrastrukturę energetyczną. Ale ten atak ma nadejść z cyberprzestrzeni.

Plik nie zostaje uruchomiony. Analitycy CERT-UA i badacze ESET wykryli go wcześniej. Industroyer2 - następca pierwszego w historii malware zaprojektowanego do ataku na sieci energetyczne - zostaje zneutralizowany, zanim zdąży wykonać choćby jedno polecenie.

Sandworm wraca na Ukrainę

Grupa Sandworm (znana też jako Unit 74455 GRU, Voodoo Bear, IRIDIUM) nie jest anonimowym kolektywem hakerskim. To jednostka rosyjskiego wywiadu wojskowego, której sześciu oficerów zostało w 2020 roku postawionych w stan oskarżenia przez Departament Sprawiedliwości USA. Na ich koncie znajdują się jedne z najpoważniejszych cyberataków w historii - od BlackEnergy w 2015 roku, przez NotPetya (10 mld USD szkód globalnie), po sabotaż Zimowych Igrzysk Olimpijskich w Pjongczangu 2018.

W kontekście rosyjskiej agresji na Ukrainę Sandworm otrzymał nowe zadanie - powtórzyć sukces z grudnia 2016 roku, kiedy Industroyer wyłączył jedną piątą Kijowa z zasilania. Tym razem cel był ambitniejszy: stacja wysokiego napięcia, a nie stacja dystrybucyjna. Uderzenie w sieć przesyłową mogłoby odciąć od prądu całe regiony.

Chronologia ataku

Data	Zdarzenie
Luty 2022	Sandworm uzyskuje dostęp do sieci IT Ukrenergo (dokładny wektor początkowy nieujawniony)
Marzec 2022	Lateralne przemieszczanie się w sieci - atakujący mapują architekturę OT i kompromitują kontroler domeny
23 marca 2022	Kompilacja pliku Industroyer2 (108_100.exe) z zakodowanymi na stałe adresami IP urządzeń stacyjnych
Początek kwietnia	Wdrożenie wiperów CaddyWiper, ORCSHRED, SOLOSHRED i AWFULSHRED na systemach Windows, Linux i Solaris
8 kwietnia, 14:58 UTC	Zaplanowane uruchomienie wipera AWFULSHRED na systemach Linux (zadanie cron)
8 kwietnia, 16:10 UTC	Zaplanowane uruchomienie Industroyer2 - wykryte i zablokowane przez CERT-UA/ESET
12 kwietnia 2022	ESET publikuje analizę techniczną; CERT-UA wydaje alert UA-2022-002

Anatomia Industroyer2 - prostota jako wybór

Oryginalny Industroyer z 2016 roku był rozbudowanym frameworkiem z czterema modułami atakującymi różne protokoły przemysłowe: IEC 104, IEC 101, IEC 61850 i OPC DA. Komunikował się z serwerem C2 przez sieć Tor. Był narzędziem uniwersalnym - mógł zaatakować praktycznie każdą stację elektroenergetyczną w Europie.

Industroyer2 poszedł w przeciwnym kierunku. Zawierał wyłącznie moduł IEC 60870-5-104 - tego samego protokołu, który stanowił najskuteczniejszy komponent oryginału. Konfiguracja była zakodowana na stałe w pliku binarnym: adresy IP stacji RTU, numery ASDU (Application Service Data Unit), zakresy IOA (Information Object Address) oraz sekwencje poleceń do wysłania. Nie było serwera C2, nie było szyfrowanej komunikacji zwrotnej, nie było dynamicznej konfiguracji.

To nie był krok wstecz. To był wybór operacyjny. Sandworm potrzebował narzędzia, które zadziała w jednym konkretnym celu - stacji wysokiego napięcia obsługującej określony region. Kompilując malware z hardkodowanymi parametrami, wyeliminowali ryzyko wykrycia komunikacji C2 i zminimalizowali ślad sieciowy. Każde wdrożenie wymagało osobnej kompilacji, ale w warunkach wojny liczyła się skuteczność, nie uniwersalność.

Mechanizm ataku był prosty: Industroyer2 łączył się z RTU (Remote Terminal Unit) na wskazanych adresach i wysyłał prawidłowe polecenia IEC 104 - komendy otwarcia wyłączników mocy. Z perspektywy urządzeń stacyjnych te polecenia były nieodróżnialne od legalnych komend operatora. Protokół IEC 104 nie przewiduje uwierzytelniania nadawcy - każdy host z dostępem sieciowym może wysyłać komendy sterujące.

Pięć wiperów - niszczenie śladów i infrastruktury

Industroyer2 nie działał sam. Sandworm wdrożył równolegle pięć programów niszczących, obejmujących trzy systemy operacyjne:

CaddyWiper (Windows) - rekurencyjnie nadpisywał pliki zerami, zaczynając od katalogu C:\Users, następnie przechodząc przez dyski D-Z. Na koniec zerował MBR pierwszych dziesięciu dysków fizycznych. Uruchamiany przez GPO (Group Policy Object) z kontrolera domeny.

ORCSHRED (Linux) - komponent robaka rozprzestrzeniający się po systemach Linux w sieci OT. Jego zadaniem było dostarczenie i uruchomienie AWFULSHRED na każdym osiągalnym hoście.

SOLOSHRED (Solaris) - wiper dedykowany systemom Solaris, wciąż obecnym w wielu instalacjach energetycznych jako platformy dla starszych systemów SCADA.

AWFULSHRED (Linux) - skrypt Bash niszczący dane, zaplanowany do uruchomienia przez ORCSHRED jako zadanie cron na 8 kwietnia o 14:58 UTC - ponad godzinę przed planowanym uruchomieniem Industroyer2.

Sekwencja była przemyślana: najpierw wipery niszczą systemy IT i stacje robocze w sieci OT, utrudniając reakcję obrońców. Następnie Industroyer2 wysyła polecenia sterujące do urządzeń stacyjnych, powodując wyłączenie zasilania. Po ataku brak sprawnych systemów uniemożliwia szybkie przywrócenie sterowania SCADA.

MITRE ATT&CK - mapowanie technik (S1072)

Industroyer2 jest katalogowany w bazie MITRE ATT&CK jako S1072. Poniżej kluczowe techniki ICS:

Technika	ID	Opis w kontekście Industroyer2
Unauthorized Command Message	T0855	Wysyłanie poleceń IEC 104 (otwarcie wyłączników) bez autoryzacji operatora
Remote Services	T0886	Wykorzystanie usług zdalnych do przemieszczania się między segmentami IT i OT
Manipulation of Control	T0831	Zmiana stanów wyłączników mocy w stacji wysokiego napięcia
Data Destruction	T0809	CaddyWiper, ORCSHRED, SOLOSHRED, AWFULSHRED - niszczenie danych na Windows, Linux, Solaris
Scheduled Task/Job	T0803	Uruchomienie malware przez zaplanowane zadanie Windows (16:10 UTC) i cron (14:58 UTC)

Więcej o frameworku MITRE ATT&CK i jego zastosowaniu w analizie zagrożeń OT - w naszym przewodniku po MITRE ATT&CK.

Dlaczego atak się nie powiódł

Sukces obrońców wynikał z kilku czynników. CERT-UA od początku inwazji działał w stanie podwyższonej gotowości, monitorując infrastrukturę krytyczną pod kątem oznak kompromitacji. Współpraca z ESET - który od lat badał aktywność Sandworm na Ukrainie - pozwoliła na szybką identyfikację malware. Kluczowe było wykrycie Industroyer2 przed jego zaplanowanym uruchomieniem, co umożliwiło neutralizację bez konieczności reagowania na aktywny incydent.

Warto podkreślić: atak nie został powstrzymany dzięki zabezpieczeniom technologicznym protokołu IEC 104 (które nie istnieją) ani dzięki izolacji sieci OT (która została przełamana). Zadziałał czynnik ludzki - kompetencje zespołów reagowania i ich zdolność do współpracy pod presją.

Jak się chronić

1. Segmentacja i monitoring sieci OT

Industroyer2 mógł komunikować się z RTU, ponieważ atakujący uzyskali dostęp do segmentu sieci OT. Prawidłowa segmentacja sieci OT z dedykowanymi strefami i korytarzami - zgodnie z modelem defense-in-depth - utrudnia lateralne przemieszczanie się.

2. Ochrona kontrolerów domeny

Sandworm wykorzystał skompromitowany kontroler domeny do dystrybucji CaddyWiper przez GPO. Kontroler domeny z dostępem do sieci OT to jeden z najcenniejszych celów dla atakującego.

3. Różnorodność systemów operacyjnych nie jest obroną

Wdrożenie wiperów na trzy platformy (Windows, Linux, Solaris) pokazuje, że Sandworm przygotował się na heterogeniczne środowisko typowe dla sektora energetycznego. Nie wystarczy zabezpieczyć Windows - trzeba objąć monitoringiem wszystkie systemy.

4. Procedury manualne i gotowość zespołów

Ukraińscy operatorzy wielokrotnie udowodnili, że potrafią przywrócić zasilanie w trybie manualnym. Ta zdolność - przełączenie na sterowanie lokalne bez systemu SCADA - jest kluczowa w sytuacji, gdy systemy cyfrowe zostały zniszczone przez wipery.

Podsumowanie

Industroyer2 potwierdził to, co analitycy podejrzewali od lat - kod Industroyera jest aktywnie rozwijany przez Sandworm i stanowi trwałe zagrożenie dla sektora energetycznego. Uproszczenie architektury - z czterech protokołów do jednego - nie było oznaką słabości, lecz pragmatycznej adaptacji do warunków operacyjnych. W warunkach wojny liczy się precyzja, nie uniwersalność.

Jednocześnie przypadek Industroyer2 niesie pozytywny przekaz: dobrze przygotowane zespoły obronne, wspierane przez ekspertów z sektora prywatnego, potrafią wykryć i zneutralizować nawet zaawansowane ataki na infrastrukturę krytyczną. Warunkiem jest jednak ciągła czujność, odpowiednie narzędzia monitoringu i przećwiczone procedury reagowania.

---

Źródła

• MITRE ATT&CK - Industroyer2 S1072
• MITRE ATT&CK - Industroyer S0604
• ESET - Industroyer2: Industroyer reloaded (2022)
• Claroty Team82 - Industroyer2 Variant Analysis
• Securonix - Industroyer2/CaddyWiper Detailed Analysis
• CISA - CrashOverride Malware Alert
• SecurityWeek - Energy Provider in Ukraine Targeted With Industroyer2