TRITON (TRISIS) - malware, który zaatakował systemy bezpieczeństwa ludzi
TRITON/TRISIS - analiza najbardziej niebezpiecznego malware ICS w historii. Atak na systemy SIS w saudyjskiej rafinerii (2017), techniki MITRE ATT&CK S1009, atrybucja TEMP.Veles/CNIIHM.
Sierpień 2017. Gdzieś na Bliskim Wschodzie, w jednej z największych rafinerii petrochemicznych Arabii Saudyjskiej, operatorzy z nocnej zmiany obserwują na monitorach coś niepokojącego. System bezpieczeństwa - ten, który w razie awarii powinien natychmiast zatrzymać instalację, zanim dojdzie do wybuchu - nagle przechodzi w tryb awaryjny. Produkcja staje. Przez chwilę nikt nie rozumie dlaczego. Kontrolery działają poprawnie, nie wykryto żadnej anomalii procesowej. Kilka godzin później instalacja wraca do pracy. Incydent trafia do dziennika zdarzeń jako niewyjaśniona usterka.
Nikt jeszcze nie wie, że ta “usterka” właśnie uratowała życie ludziom. I że za kilka miesięcy świat dowie się o malware, którego celem nie było kradzież danych ani okup - lecz pozbawienie rafinerii ostatniej linii obrony przed katastrofą przemysłową.
Czym jest Safety Instrumented System i dlaczego jego kompromitacja może zabijać
Aby zrozumieć wyjątkowość TRITON-a, trzeba najpierw zrozumieć, co atakował.
Safety Instrumented System (SIS) to niezależny układ automatyki bezpieczeństwa, którego jedynym zadaniem jest ochrona ludzi, instalacji i środowiska. SIS działa równolegle do podstawowego systemu sterowania (DCS/BPCS), ale jest od niego fizycznie i logicznie oddzielony. Gdy czujniki wykryją warunki zagrażające bezpieczeństwu - nadmierne ciśnienie, temperaturę, stężenie gazów - SIS podejmuje automatyczne działania: zamyka zawory, wyłącza pompy, uruchamia systemy gaszenia. To ostatnia bariera między normalną pracą a katastrofą.
W rafinerii petrochemicznej przetwarzającej węglowodory, kwas siarkowy i siarkowodór (H2S), awaria SIS w momencie krytycznym może oznaczać:
- Niekontrolowany wzrost ciśnienia prowadzący do rozerwania reaktora
- Uwolnienie toksycznego siarkowodoru - gaz śmiertelny w stężeniu 100 ppm
- Eksplozję i pożar w instalacjach przetwarzających materiały łatwopalne
Systemy SIS projektuje się zgodnie z normą IEC 61511, z wymaganym poziomem nienaruszalności bezpieczeństwa (SIL) od 1 do 4. Kontrolery Triconex firmy Schneider Electric, zastosowane w saudyjskiej rafinerii, to jedne z najpowszechniej stosowanych urządzeń SIS na świecie - działają w tysiącach instalacji w sektorach petrochemicznym, energetycznym i gazowym.
TRITON był pierwszym malware w historii zaprojektowanym celowo do ataku na systemy, których zadaniem jest ochrona życia ludzkiego.
Anatomia ataku - od sieci korporacyjnej do kontrolera bezpieczeństwa
Faza 1: Infiltracja sieci IT i przejście do OT
Atakujący uzyskali dostęp do sieci korporacyjnej co najmniej rok przed atakiem na SIS. Wykorzystali prawdopodobnie spearphishing lub skompromitowane usługi zdalnego dostępu. Z sieci IT przeszli lateralnie do sieci OT, ostatecznie uzyskując kontrolę nad stacją inżynierską (engineering workstation) połączoną z kontrolerami SIS.
Stacja inżynierska działała pod kontrolą systemu Windows i miała zainstalowane oprogramowanie TriStation - narzędzie Schneider Electric służące do programowania i konfiguracji kontrolerów Triconex. To właśnie ta stacja stała się przyczółkiem ataku na SIS.
Faza 2: Reverse engineering protokołu TriStation
Protokół TriStation to zastrzeżony protokół komunikacyjny Schneider Electric, działający na porcie UDP/1502. Służy do przesyłania programów, konfiguracji i poleceń diagnostycznych między stacją inżynierską a kontrolerami Triconex. Protokół ten nie był publicznie udokumentowany.
Atakujący musieli go poddać inżynierii wstecznej - przeanalizować ruch sieciowy, zrozumieć strukturę pakietów, zaimplementować własną bibliotekę komunikacyjną. Sam ten fakt świadczy o zasobach i czasie, jakim dysponowali - to nie jest praca pojedynczego hakera, lecz zespołu z dostępem do sprzętu Triconex i wielomiesięcznym budżetem badawczym.
Faza 3: Framework TRITON
TRITON to nie pojedynczy plik - to modularny framework ataku składający się z kilku komponentów:
| Komponent | Funkcja |
|---|---|
| trilog.exe | Dropper podszywający się pod legalne narzędzie Triconex do analizy logów (trilog.exe). Skrypt Python skompilowany do pliku wykonywalnego Windows |
| inject.bin | Shellcode PowerPC - injector wykorzystujący podatność zero-day w firmware Triconex do eskalacji uprawnień i wstrzyknięcia backdoora |
| imain.bin | Implant (backdoor) - kod rezydujący w pamięci firmware kontrolera, zapewniający atakującym dostęp do odczytu, zapisu i wykonywania kodu na kontrolerze |
| Biblioteka TriStation | Własna implementacja protokołu TriStation umożliwiająca komunikację z kontrolerami |
Framework umożliwiał atakującym:
- Odczyt i zapis pamięci kontrolera
- Modyfikację logiki programu SIS
- Zmianę trybu pracy kontrolera (z RUN na PROGRAM)
- Wgrywanie własnego kodu do firmware
Faza 4: Atak na kontrolery Triconex
Celem końcowym było wgranie backdoora (imain.bin) do pamięci firmware kontrolerów Triconex obsługujących jednostki odzysku siarki (Sulfur Recovery Units) i systemy zarządzania spalaniem. Backdoor miał zapewnić trwały, ukryty dostęp do kontrolerów - niezależny od normalnego procesu programowania.
Atakujący wykorzystali podatność zero-day w firmware Triconex - lukę umożliwiającą eskalację uprawnień, dzięki której kod mógł zostać zapisany nie w standardowej pamięci użytkownika, lecz w obszarze pamięci firmware. To kluczowe rozróżnienie: kod w pamięci firmware przetrwa restart kontrolera i jest znacznie trudniejszy do wykrycia.
Błąd, który uratował życie
I tu dochodzimy do momentu, który zmienił bieg wydarzeń.
Malware zawierał błąd w kodzie walidacji. Podczas próby wstrzyknięcia backdoora do jednego z kontrolerów, kod nie przeszedł wewnętrznej kontroli integralności firmware. Kontroler Triconex - zaprojektowany tak, by w każdej wątpliwej sytuacji preferować bezpieczeństwo nad ciągłość pracy - przeszedł w tryb bezpiecznego zatrzymania (fail-safe state).
To właśnie było to “niewyjaśnione” wyłączenie z sierpnia 2017.
Gdyby malware zadziałał poprawnie, atakujący uzyskaliby trwały, ukryty dostęp do kontrolerów bezpieczeństwa. Mogliby następnie - w koordynacji z atakiem na system DCS - wyłączyć zabezpieczenia w momencie, gdy instalacja potrzebuje ich najbardziej. Scenariusz celowej katastrofy przemysłowej - wybuchu, uwolnienia toksycznych gazów, pożaru - stałby się realny.
Jak później ustalili badacze z Mandiant, malware zawierał warunkowe sprawdzenie, które uniemożliwiało persystencję payloadu. Po skorygowaniu tego fragmentu kodu, backdoor persystował w pamięci kontrolera prawidłowo. Innymi słowy: gdyby atakujący naprawili jeden warunek w swoim kodzie, kontroler nie wykryłby intruza.
TRITON w MITRE ATT&CK for ICS
MITRE ATT&CK kataloguje TRITON jako oprogramowanie S1009, a cały incydent jako kampanię C0030. Poniższa tabela przedstawia kluczowe techniki ICS wykorzystane przez TRITON.
| Taktyka | Technika | ID | Zastosowanie w ataku TRITON |
|---|---|---|---|
| Execution | Change Operating Mode | T0858 | Zmiana trybu kontrolera z RUN na PROGRAM, umożliwiająca wgranie nowego kodu |
| Execution | Native API | T0834 | Wykorzystanie natywnych funkcji API kontrolera Triconex do komunikacji |
| Persistence | System Firmware | T0857 | Wstrzyknięcie backdoora do obszaru pamięci firmware (nie user memory) |
| Persistence | Modify Program | T0889 | Modyfikacja programu użytkownika w kontrolerze SIS |
| Evasion | Masquerading | T0849 | Plik trilog.exe podszywający się pod legalne narzędzie Schneider Electric |
| Inhibit Response Function | Block Command Message | T0803 | Możliwość blokowania komend bezpieczeństwa do kontrolera |
| Inhibit Response Function | Modify Parameter | T0836 | Modyfikacja parametrów konfiguracyjnych kontrolera SIS |
| Lateral Movement | Program Download | T0843 | Pobranie (wgranie) nowego programu do kontrolera przez TriStation |
| Impair Process Control | Modify Controller Tasking | T0821 | Zmiana logiki sterowania w kontrolerze bezpieczeństwa |
Pełna lista technik, w tym techniki IT wykorzystane w fazie infiltracji sieci korporacyjnej i lateralnego ruchu, dostępna jest na stronie kampanii C0030 w MITRE ATT&CK. Więcej o tym, jak korzystać z frameworka ATT&CK w praktyce, opisujemy w artykule MITRE ATT&CK - jak wykorzystać framework do ochrony organizacji.
Kto stoi za TRITON - atrybucja TEMP.Veles i CNIIHM
Firma FireEye (obecnie Mandiant/Google Cloud) śledziła aktywność związaną z TRITON-em pod oznaczeniem TEMP.Veles. W październiku 2018 roku Mandiant opublikował analizę atrybucyjną, w której z wysokim poziomem pewności powiązał działalność TEMP.Veles z Centralnym Naukowo-Badawczym Instytutem Chemii i Mechaniki (CNIIHM, ros. ЦНИИХМ) - rosyjskim instytutem badawczym podlegającym Ministerstwu Obrony, zlokalizowanym w Moskwie przy ulicy Nagatinskaja.
Kluczowe dowody obejmowały:
- Adres IP zarejestrowany na CNIIHM, wykorzystywany przez TEMP.Veles do monitorowania publicznych doniesień o TRITON-ie, rekonesansu sieciowego i aktywności wspierającej intruzję
- Powiązania personalne - profile mediów społecznościowych łączące badaczy z CNIIHM z aktywnością TEMP.Veles
- Kompetencje instytucjonalne - CNIIHM posiada deklarowane zdolności badawcze w zakresie systemów sterowania przemysłowego i bezpieczeństwa krytycznej infrastruktury
- Narzędzia testowe - ślady testowania narzędzi TRITON w środowisku zgodnym z profilem instytutu badawczego
W październiku 2020 roku Departament Skarbu USA nałożył sankcje na CNIIHM w związku z rolą instytutu w rozwoju malware TRITON.
Warto podkreślić: Mandiant nie stwierdził jednoznacznie, że CNIIHM opracował sam framework TRITON - powiązanie dotyczyło wsparcia operacyjnego i narzędzi intruzyjnych. Niemniej poziom zaawansowania ataku - inżynieria wsteczna zastrzeżonego protokołu, exploit zero-day na firmware kontrolera, modularny framework - jednoznacznie wskazuje na aktora państwowego.
Dlaczego TRITON zmienił postrzeganie cyberbezpieczeństwa przemysłowego
TRITON przekroczył granicę, której wcześniejsze ataki ICS - nawet Stuxnet czy BlackEnergy - nie naruszały. Stuxnet niszczył wirówki, ale nie wyłączał systemów bezpieczeństwa chroniących ludzi. BlackEnergy powodował przerwy w dostawie prądu, ale nie stwarzał bezpośredniego zagrożenia dla życia operatorów.
TRITON celowo zaatakował systemy, których jedynym zadaniem jest ochrona przed śmiercią i katastrofą. To przesunięcie intencji - z destrukcji infrastruktury na potencjalne zabójstwo - zmieniło sposób, w jaki branża OT myśli o bezpieczeństwie.
Implikacje dla organizacji przemysłowych
1. Separacja SIS od DCS nie jest opcjonalna
Jednym z czynników umożliwiających atak było fizyczne lub logiczne połączenie stacji inżynierskiej SIS z siecią, do której atakujący mieli dostęp. Norma IEC 62443 wymaga segmentacji sieci na strefy i korytarze - systemy SIS powinny znajdować się w oddzielnej strefie z minimalną liczbą punktów połączenia.
2. Monitorowanie komunikacji z kontrolerami SIS
Protokoły takie jak TriStation nie były tradycyjnie monitorowane - traktowano je jako zaufane kanały wewnętrzne. Po TRITON-ie monitorowanie ruchu do i z kontrolerów SIS (szczególnie poleceń Program Download i Change Operating Mode) stało się krytycznym wymogiem.
3. Kontrola dostępu do stacji inżynierskich
Stacja inżynierska połączona z SIS to jeden z najcenniejszych celów w sieci OT. Wymaga wieloskładnikowego uwierzytelniania, pełnego logowania aktywności, regularnych audytów i minimalnych uprawnień - zasady opisujemy szerzej w artykule o bezpiecznym zdalnym dostępie do systemów ICS.
4. Walidacja integralności firmware kontrolerów
TRITON wykorzystał fakt, że kontrolery Triconex nie weryfikowały wystarczająco dokładnie kodu wgrywanego do firmware. Schneider Electric wydał aktualizacje bezpieczeństwa, ale problem dotyczy całej branży - wielu producentów kontrolerów SIS nie implementuje kryptograficznej weryfikacji podpisu firmware.
5. Ćwiczenia zakładające kompromitację SIS
Organizacje powinny regularnie testować scenariusze, w których systemy bezpieczeństwa zostały skompromitowane. Red teaming obejmujący warstwę OT - nie tylko IT - jest jedynym sposobem weryfikacji, czy organizacja potrafi wykryć i zareagować na atak klasy TRITON.
Podsumowanie
TRITON pozostaje ostrzeżeniem. Nie dlatego, że atak się udał - paradoksalnie, nie udał się, dzięki błędowi w kodzie malware i poprawnej reakcji kontrolera na naruszenie integralności. Ostrzeżeniem jest sam fakt, że ktoś zainwestował lata pracy, miliony dolarów i kompetencje zespołu badawczego, aby opracować narzędzie zdolne wyłączyć systemy chroniące ludzi przed śmiercią w wybuchu rafinerii.
Pytanie nie brzmi “czy ktoś spróbuje ponownie”, lecz “kiedy”. I czy tym razem malware nie będzie zawierał błędu.
Źródła
- MITRE ATT&CK - Triton, Software S1009
- MITRE ATT&CK - Triton Safety Instrumented System Attack, Campaign C0030
- Mandiant/FireEye - TRITON Attribution: Russian Government-Owned Lab Most Likely Built Custom Intrusion Tools
- Mandiant - Attackers Deploy New ICS Attack Framework TRITON
- Schneider Electric - TRITON/TRISIS Attack Used 0-Day Flaw in Triconex SIS
- MIT Technology Review - Triton is the world’s most murderous malware, and it’s spreading
- CISA/FBI - TRITON Malware Remains Threat to Global Critical Infrastructure (2022)
- Cisco - How Does Triton Attack Triconex Industrial Safety Systems?