Wiedza
9 m
5
Operacja szpiegowska SolarWinds (2020): największy cyberatak na łańcuch dostaw
Atak na SolarWinds w 2020 roku stanowi jeden z najbardziej wyrafinowanych i destrukcyjnych incydentów w historii, będąc podręcznikowym przykładem operacji szpiegowskiej wymierzonej w łańcuch dostaw oprogramowania (supply chain attack). Rosyjska Służba Wywiadu Zagranicznego (SVR), znana w środowisku cyberbezpieczeństwa jako APT29, Cozy Bear lub The Dukes, przeprowadziła wielofazową kampanię, która trwała blisko 19 miesięcy. Operacja ta dotknęła około 18 000 organizacji na całym świecie, w tym 9 agencji federalnych USA oraz ponad 100 firm z listy Fortune 500. Atak charakteryzował się niezwykłą precyzją, cierpliwością i zaawansowanymi zdolnościami operacyjnymi, a jego głównym celem było zbieranie informacji wywiadowczych dotyczących polityki sankcyjnej USA, kontrwywiadu oraz strategii bezpieczeństwa cybernetycznego.
Faza przygotowania: oszukane fundamenty bezpieczeństwa
Geneza ataku na SolarWinds sięga znacznie wcześniej niż moment jego ujawnienia w grudniu 2020 roku. Zgodnie z ustaleniami śledczymi, rosyjscy hakerzy uzyskali pierwszy dostęp do sieci firmy nie później niż 4 września 2019 roku. Od tego momentu napastnicy prowadzili intensywną kampanię rozpoznawczą i przygotowawczą, trwającą przez kolejne dziewięć miesięcy. W tym czasie utrzymywali dostęp do infrastruktury programistycznej SolarWinds, w tym do środowiska Microsoft Office 365, co pozwoliło im na dogłębną analizę procesów tworzenia oprogramowania oraz infrastruktury bezpieczeństwa firmy.
Kluczowym osiągnięciem fazy przygotowawczej było opracowanie zaawansowanego narzędzia o nazwie SUNSPOT. Stanowiło ono innowacyjne rozwiązanie umożliwiające bezpośrednią manipulację procesem budowania oprogramowania (build process) bez konieczności trwałego modyfikowania repozytorium kodu źródłowego. Między 12 września a 4 listopada 2019 roku atakujący przeprowadzili serię próbnych uruchomień SUNSPOT, testując jego zdolność do wstrzykiwania kodu do kompilacji platformy Orion. Ta ostrożna faza testowa pozwoliła im na udoskonalenie techniki i upewnienie się, że narzędzie zadziała bezbłędnie w rzeczywistym środowisku produkcyjnym.
Geneza ataku na SolarWinds sięga znacznie wcześniej niż moment jego ujawnienia w grudniu 2020 roku. Zgodnie z ustaleniami śledczymi, rosyjscy hakerzy uzyskali pierwszy dostęp do sieci firmy nie później niż 4 września 2019 roku. Od tego momentu napastnicy prowadzili intensywną kampanię rozpoznawczą i przygotowawczą, trwającą przez kolejne dziewięć miesięcy. W tym czasie utrzymywali dostęp do infrastruktury programistycznej SolarWinds, w tym do środowiska Microsoft Office 365, co pozwoliło im na dogłębną analizę procesów tworzenia oprogramowania oraz infrastruktury bezpieczeństwa firmy.
Kluczowym osiągnięciem fazy przygotowawczej było opracowanie zaawansowanego narzędzia o nazwie SUNSPOT. Stanowiło ono innowacyjne rozwiązanie umożliwiające bezpośrednią manipulację procesem budowania oprogramowania (build process) bez konieczności trwałego modyfikowania repozytorium kodu źródłowego. Między 12 września a 4 listopada 2019 roku atakujący przeprowadzili serię próbnych uruchomień SUNSPOT, testując jego zdolność do wstrzykiwania kodu do kompilacji platformy Orion. Ta ostrożna faza testowa pozwoliła im na udoskonalenie techniki i upewnienie się, że narzędzie zadziała bezbłędnie w rzeczywistym środowisku produkcyjnym.
Techniki wstrzykiwania i operacyjne zaawansowanie SUNSPOT
SUNSPOT był technicznym ewenementem w świecie złośliwego oprogramowania – niezwykle wyrafinowanym narzędziem zainstalowanym bezpośrednio na serwerach kompilacyjnych (build servers) SolarWinds. Malware monitorował procesy MSBuild.exe (komponenty Visual Studio używane do kompilacji) w poszukiwaniu momentu rozpoczęcia budowania pakietu Orion. Po zidentyfikowaniu właściwego procesu, SUNSPOT podmieniał plik kodu źródłowego (konkretnie InventoryManager.cs) na zainfekowaną wersję zawierającą backdoora SUNBURST. Działo się to na ułamki sekund przed kompilacją, zanim kompilator zdążył odczytać oryginalny kod.
Geniusz podejścia grupy APT29 polegał na wbudowaniu w SUNSPOT systemu walidacji. Aby uniknąć błędów kompilacji, które mogłyby zaalarmować programistów SolarWinds, złośliwe oprogramowanie weryfikowało sumy kontrolne MD5, zapewniając pełną kompatybilność wstrzykiwanego kodu z wersją źródłową. Po pomyślnej kompilacji malware natychmiast przywracał oryginalny plik źródłowy, zacierając ślady swojej ingerencji. Taka metodologia świadczy o doskonałym rozpoznaniu procesów deweloperskich wewnątrz SolarWinds oraz naukowym podejściu do unikania wykrycia.
SUNSPOT posiadał również zaawansowane mechanizmy przetrwania i zacierania śladów. Logi operacyjne – szyfrowane algorytmem RC4 – były zapisywane w pliku vmware-vmdmp.log, co miało sugerować, że są to standardowe dzienniki systemu VMware. Malware zapewnił sobie trwałość w systemie poprzez zaplanowane zadanie (scheduled task) uruchamiane przy starcie serwera. Wszystkie dane konfiguracyjne, w tym ścieżki do plików rozwiązania Orion i kod SUNBURST, były szyfrowane za pomocą AES-128-CBC, co stanowiło dodatkową barierę dla analityków zagrożeń.
SUNSPOT był technicznym ewenementem w świecie złośliwego oprogramowania – niezwykle wyrafinowanym narzędziem zainstalowanym bezpośrednio na serwerach kompilacyjnych (build servers) SolarWinds. Malware monitorował procesy MSBuild.exe (komponenty Visual Studio używane do kompilacji) w poszukiwaniu momentu rozpoczęcia budowania pakietu Orion. Po zidentyfikowaniu właściwego procesu, SUNSPOT podmieniał plik kodu źródłowego (konkretnie InventoryManager.cs) na zainfekowaną wersję zawierającą backdoora SUNBURST. Działo się to na ułamki sekund przed kompilacją, zanim kompilator zdążył odczytać oryginalny kod.
Geniusz podejścia grupy APT29 polegał na wbudowaniu w SUNSPOT systemu walidacji. Aby uniknąć błędów kompilacji, które mogłyby zaalarmować programistów SolarWinds, złośliwe oprogramowanie weryfikowało sumy kontrolne MD5, zapewniając pełną kompatybilność wstrzykiwanego kodu z wersją źródłową. Po pomyślnej kompilacji malware natychmiast przywracał oryginalny plik źródłowy, zacierając ślady swojej ingerencji. Taka metodologia świadczy o doskonałym rozpoznaniu procesów deweloperskich wewnątrz SolarWinds oraz naukowym podejściu do unikania wykrycia.
SUNSPOT posiadał również zaawansowane mechanizmy przetrwania i zacierania śladów. Logi operacyjne – szyfrowane algorytmem RC4 – były zapisywane w pliku vmware-vmdmp.log, co miało sugerować, że są to standardowe dzienniki systemu VMware. Malware zapewnił sobie trwałość w systemie poprzez zaplanowane zadanie (scheduled task) uruchamiane przy starcie serwera. Wszystkie dane konfiguracyjne, w tym ścieżki do plików rozwiązania Orion i kod SUNBURST, były szyfrowane za pomocą AES-128-CBC, co stanowiło dodatkową barierę dla analityków zagrożeń.
SUNBURST: cyfrowo podpisana luka w zaufaniu
20 lutego 2020 roku złośliwy kod SUNBURST został skompilowany i wstrzyknięty do oficjalnych plików instalacyjnych Oriona. Od 26 marca do czerwca 2020 roku firma SolarWinds nieświadomie rozpowszechniała zainfekowane aktualizacje poprzez swój automatyczny system dystrybucji, docierając do około 18 000 klientów na całym świecie. To kluczowy aspekt ataku – SUNBURST nie był anonimowym wirusem pobranym z internetu. Był to legalnie wyglądający komponent SolarWinds, cyfrowo podpisany ważnymi certyfikatami firmy i dostarczany oficjalnymi kanałami. Z perspektywy użytkownika końcowego instalacja wyglądała jak rutynowa aktualizacja bezpieczeństwa.
SUNBURST wykorzystywał zaawansowane techniki maskowania i komunikacji z serwerami sterującymi (C2). Malware łączył się z infrastrukturą atakujących poprzez protokoły HTTP (GET/POST) lub DNS, naśladując przy tym ruch generowany przez natywne API SolarWinds – a konkretnie protokół Orion Improvement Program (OIP). Dzięki temu ruch sieciowy generowany przez backdoora wyglądał niewinnie dla systemów monitorowania bezpieczeństwa. Dane przesyłane do serwerów C2 były szyfrowane prostym szyfrem XOR i dodatkowo obfuskowane (zaciemniane) algorytmem FNV-1a, co skutecznie ukrywało treść komunikacji.
Malware wyposażono również w mechanizmy unikania detekcji i analizy środowiska (anti-forensics). SUNBURST posiadał zakodowaną na stałe listę procesów, usług i sterowników powiązanych z oprogramowaniem antywirusowym lub narzędziami śledczymi. Jeśli wykrył ich obecność, wstrzymywał działanie. Przed wykonaniem szkodliwych akcji sprawdzał domenę hosta, aby upewnić się, że działa w rzeczywistej sieci korporacyjnej, a nie w środowisku testowym (sandbox). Ponadto, SUNBURST pozostawał w stanie uśpienia przez okres do dwóch tygodni po pierwszej infekcji, co drastycznie zmniejszało szanse na skojarzenie ataku z momentem aktualizacji oprogramowania.
20 lutego 2020 roku złośliwy kod SUNBURST został skompilowany i wstrzyknięty do oficjalnych plików instalacyjnych Oriona. Od 26 marca do czerwca 2020 roku firma SolarWinds nieświadomie rozpowszechniała zainfekowane aktualizacje poprzez swój automatyczny system dystrybucji, docierając do około 18 000 klientów na całym świecie. To kluczowy aspekt ataku – SUNBURST nie był anonimowym wirusem pobranym z internetu. Był to legalnie wyglądający komponent SolarWinds, cyfrowo podpisany ważnymi certyfikatami firmy i dostarczany oficjalnymi kanałami. Z perspektywy użytkownika końcowego instalacja wyglądała jak rutynowa aktualizacja bezpieczeństwa.
SUNBURST wykorzystywał zaawansowane techniki maskowania i komunikacji z serwerami sterującymi (C2). Malware łączył się z infrastrukturą atakujących poprzez protokoły HTTP (GET/POST) lub DNS, naśladując przy tym ruch generowany przez natywne API SolarWinds – a konkretnie protokół Orion Improvement Program (OIP). Dzięki temu ruch sieciowy generowany przez backdoora wyglądał niewinnie dla systemów monitorowania bezpieczeństwa. Dane przesyłane do serwerów C2 były szyfrowane prostym szyfrem XOR i dodatkowo obfuskowane (zaciemniane) algorytmem FNV-1a, co skutecznie ukrywało treść komunikacji.
Malware wyposażono również w mechanizmy unikania detekcji i analizy środowiska (anti-forensics). SUNBURST posiadał zakodowaną na stałe listę procesów, usług i sterowników powiązanych z oprogramowaniem antywirusowym lub narzędziami śledczymi. Jeśli wykrył ich obecność, wstrzymywał działanie. Przed wykonaniem szkodliwych akcji sprawdzał domenę hosta, aby upewnić się, że działa w rzeczywistej sieci korporacyjnej, a nie w środowisku testowym (sandbox). Ponadto, SUNBURST pozostawał w stanie uśpienia przez okres do dwóch tygodni po pierwszej infekcji, co drastycznie zmniejszało szanse na skojarzenie ataku z momentem aktualizacji oprogramowania.
Atakowanie selektywne i druga faza operacji
Szczególnie godnym uwagi aspektem operacji SolarWinds był fakt, że mimo iż SUNBURST trafił do 18 000 organizacji, hakerzy nie aktywowali backdoora we wszystkich przypadkach. Microsoft zidentyfikował nieco ponad 40 organizacji, w których atakujący faktycznie przeprowadzili dalsze działania szpiegowskie (hands-on-keyboard activity). Wskazuje to na wysoce selektywne podejście APT29 – szeroka dystrybucja "zarazka", ale aktywacja jedynie w celach o najwyższej wartości strategicznej. Aby to osiągnąć, w kodzie SUNBURST zawarto mechanizmy profilowania ofiary, które pozwalały operatorom ocenić, czy dana sieć jest warta dalszego zaangażowania.
Po aktywacji SUNBURST w wybranych celach następowała druga faza operacji. Backdoor tworzył na dysku dwa kluczowe pliki: skrypt VBScript o nazwie naśladującej istniejące usługi systemowe oraz niestandardowy loader Cobalt Strike (w postaci biblioteki DLL), kompilowany indywidualnie dla każdego celu. Te wtórne ładunki – nazwane przez badaczy TEARDROP i RAINDROP – umożliwiały pełną kontrolę nad przejętą siecią. TEARDROP służył do załadowania agenta Cobalt Strike Beacon bezpośrednio do pamięci, co pozwalało na wykonywanie poleceń bez zapisywania plików na dysku. RAINDROP był wariantem wykorzystującym zamaskowaną bibliotekę 7-Zip jako przykrywkę oraz steganografię do ukrycia właściwego kodu.
Atakujący wykazali się nadzwyczajną dbałością o dyskrecję operacyjną (OPSEC). Zamiast natychmiastowego uruchamiania TEARDROP czy RAINDROP, tworzyli wpisy w rejestrze systemowym (Image File Execution Options) dla procesu dllhost.exe. Dzięki temu złośliwy skrypt uruchamiał się dopiero wtedy, gdy system naturalnie wywoływał ten proces. Ta technika opóźnionej aktywacji miała na celu ukrycie działań w "szumie" legalnych procesów systemowych. Atakujący kalkulowali, że nawet w przypadku wykrycia i usunięcia Cobalt Strike'a, oryginalny SUNBURST mógł pozostać nienaruszony, zapewniając trwały dostęp.
Szczególnie godnym uwagi aspektem operacji SolarWinds był fakt, że mimo iż SUNBURST trafił do 18 000 organizacji, hakerzy nie aktywowali backdoora we wszystkich przypadkach. Microsoft zidentyfikował nieco ponad 40 organizacji, w których atakujący faktycznie przeprowadzili dalsze działania szpiegowskie (hands-on-keyboard activity). Wskazuje to na wysoce selektywne podejście APT29 – szeroka dystrybucja "zarazka", ale aktywacja jedynie w celach o najwyższej wartości strategicznej. Aby to osiągnąć, w kodzie SUNBURST zawarto mechanizmy profilowania ofiary, które pozwalały operatorom ocenić, czy dana sieć jest warta dalszego zaangażowania.
Po aktywacji SUNBURST w wybranych celach następowała druga faza operacji. Backdoor tworzył na dysku dwa kluczowe pliki: skrypt VBScript o nazwie naśladującej istniejące usługi systemowe oraz niestandardowy loader Cobalt Strike (w postaci biblioteki DLL), kompilowany indywidualnie dla każdego celu. Te wtórne ładunki – nazwane przez badaczy TEARDROP i RAINDROP – umożliwiały pełną kontrolę nad przejętą siecią. TEARDROP służył do załadowania agenta Cobalt Strike Beacon bezpośrednio do pamięci, co pozwalało na wykonywanie poleceń bez zapisywania plików na dysku. RAINDROP był wariantem wykorzystującym zamaskowaną bibliotekę 7-Zip jako przykrywkę oraz steganografię do ukrycia właściwego kodu.
Atakujący wykazali się nadzwyczajną dbałością o dyskrecję operacyjną (OPSEC). Zamiast natychmiastowego uruchamiania TEARDROP czy RAINDROP, tworzyli wpisy w rejestrze systemowym (Image File Execution Options) dla procesu dllhost.exe. Dzięki temu złośliwy skrypt uruchamiał się dopiero wtedy, gdy system naturalnie wywoływał ten proces. Ta technika opóźnionej aktywacji miała na celu ukrycie działań w "szumie" legalnych procesów systemowych. Atakujący kalkulowali, że nawet w przypadku wykrycia i usunięcia Cobalt Strike'a, oryginalny SUNBURST mógł pozostać nienaruszony, zapewniając trwały dostęp.
Cele i osiągnięcia szpiegowskie
Analiza ofiar operacji SolarWinds ujawnia precyzyjną strategię wywiadowczą. Z grupy ponad 40 celów, które padły ofiarą drugiej fazy ataku, 44% stanowiły firmy technologiczne (dostawcy oprogramowania, producenci sprzętu, firmy cyberbezpieczeństwa), a 18% agencje rządowe. Rosjanie z chirurgiczną precyzją wybierali podmioty o kluczowym znaczeniu: FireEye (firma chroniąca rząd USA), Microsoft, Cisco, Deloitte, a także Departamenty: Skarbu, Handlu, Obrony, Energii, Bezpieczeństwa Krajowego, Stanu i Zdrowia USA.
Cele wywiadowcze stały się jasne dzięki raportom służb specjalnych. Agencja Reuters informowała, że hakerzy wykradli wrażliwe dane dotyczące polityki sankcji USA wobec Rosji, działań amerykańskiego kontrwywiadu wymierzonych w rosyjskich hakerów oraz ogólnej strategii zagranicznej. Departament Skarbu był celem priorytetowym ze względu na dokumenty dotyczące międzynarodowych przepływów finansowych. Z kolei włamanie do Departamentu Energii, nadzorującego arsenał nuklearny USA, wzbudziło obawy, że napastnicy mogli szukać planów procedury "Black Start" – czyli przywracania krajowej sieci energetycznej po katastrofalnej awarii.
Analiza ofiar operacji SolarWinds ujawnia precyzyjną strategię wywiadowczą. Z grupy ponad 40 celów, które padły ofiarą drugiej fazy ataku, 44% stanowiły firmy technologiczne (dostawcy oprogramowania, producenci sprzętu, firmy cyberbezpieczeństwa), a 18% agencje rządowe. Rosjanie z chirurgiczną precyzją wybierali podmioty o kluczowym znaczeniu: FireEye (firma chroniąca rząd USA), Microsoft, Cisco, Deloitte, a także Departamenty: Skarbu, Handlu, Obrony, Energii, Bezpieczeństwa Krajowego, Stanu i Zdrowia USA.
Cele wywiadowcze stały się jasne dzięki raportom służb specjalnych. Agencja Reuters informowała, że hakerzy wykradli wrażliwe dane dotyczące polityki sankcji USA wobec Rosji, działań amerykańskiego kontrwywiadu wymierzonych w rosyjskich hakerów oraz ogólnej strategii zagranicznej. Departament Skarbu był celem priorytetowym ze względu na dokumenty dotyczące międzynarodowych przepływów finansowych. Z kolei włamanie do Departamentu Energii, nadzorującego arsenał nuklearny USA, wzbudziło obawy, że napastnicy mogli szukać planów procedury "Black Start" – czyli przywracania krajowej sieci energetycznej po katastrofalnej awarii.
Niespodziewane odkrycie i konsekwencje dla branży cyberbezpieczeństwa
Paradoksalnie, atak na SolarWinds został wykryty przypadkiem. 8 grudnia 2020 roku FireEye, jedna z czołowych firm zajmujących się cyberbezpieczeństwem, ogłosiła, że sama padła ofiarą ataku. Podczas wewnętrznego śledztwa analitycy FireEye odkryli, że źródłem infekcji nie był błąd ich pracowników, lecz zmanipulowana aktualizacja oprogramowania SolarWinds Orion. To odkrycie wywołało wstrząs – atakujący, którzy tak starannie zacierali ślady, zostali zdemaskowani przez jedną z ofiar, którą zaatakowali pośrednio.
13 grudnia 2020 roku SolarWinds publicznie potwierdziła naruszenie, a amerykańska agencja CISA (Cybersecurity and Infrastructure Security Agency) wydała nadzwyczajną dyrektywę nakazującą agencjom federalnym natychmiastowe odłączenie systemów SolarWinds Orion. Czas reakcji był kluczowy – instytucje rządowe miały zaledwie kilka godzin na zidentyfikowanie i wyłączenie zagrożonych serwerów, co stanowiło ogromne wyzwanie logistyczne. Dopiero 15 kwietnia 2021 roku administracja prezydenta Bidena oraz rząd Wielkiej Brytanii oficjalnie przypisały atak Rosyjskiej Służbie Wywiadu Zagranicznego (SVR).
Straty finansowe i operacyjne
Finansowe skutki ataku SolarWinds szacuje się na miliardy dolarów, choć dokładne kwoty są trudne do ustalenia ze względu na tajność danych firmowych i rządowych. Analitycy z Bitsight i Kovrr oszacowali straty objęte ubezpieczeniem na około 90 milionów dolarów (koszty reakcji na incydent, informatyka śledcza, doradztwo prawne). Jest to jednak tylko wierzchołek góry lodowej – wiele agencji rządowych nie posiada ubezpieczeń komercyjnych, a całkowite koszty naprawy infrastruktury były znacznie wyższe.
Sama firma SolarWinds zapłaciła wysoką cenę. W ciągu pierwszych dziewięciu miesięcy 2021 roku koszty bezpośrednio związane z incydentem wyniosły 40 milionów dolarów. Firma wdrożyła również inicjatywę "Secure by Design", mającą na celu całkowitą przebudowę środowiska deweloperskiego, z rocznym budżetem szacowanym na 20 milionów dolarów. Podatnicy w USA również ponieśli ogromne koszty związane z koniecznością przeprowadzenia audytów sieci federalnych, wymiany sprzętu i wdrożenia nowych protokołów bezpieczeństwa.
Badania IronNet wykazały, że przeciętna organizacja dotknięta atakiem straciła równowartość około 11% swoich rocznych przychodów. W październiku 2024 roku amerykańska Komisja Papierów Wartościowych i Giełd (SEC) nałożyła kary na cztery firmy technologiczne – Unisys, Avaya Holdings, Check Point Software i Mimecast – za wprowadzające w błąd raporty dotyczące stopnia ich narażenia na skutki tego ataku.
Finansowe skutki ataku SolarWinds szacuje się na miliardy dolarów, choć dokładne kwoty są trudne do ustalenia ze względu na tajność danych firmowych i rządowych. Analitycy z Bitsight i Kovrr oszacowali straty objęte ubezpieczeniem na około 90 milionów dolarów (koszty reakcji na incydent, informatyka śledcza, doradztwo prawne). Jest to jednak tylko wierzchołek góry lodowej – wiele agencji rządowych nie posiada ubezpieczeń komercyjnych, a całkowite koszty naprawy infrastruktury były znacznie wyższe.
Sama firma SolarWinds zapłaciła wysoką cenę. W ciągu pierwszych dziewięciu miesięcy 2021 roku koszty bezpośrednio związane z incydentem wyniosły 40 milionów dolarów. Firma wdrożyła również inicjatywę "Secure by Design", mającą na celu całkowitą przebudowę środowiska deweloperskiego, z rocznym budżetem szacowanym na 20 milionów dolarów. Podatnicy w USA również ponieśli ogromne koszty związane z koniecznością przeprowadzenia audytów sieci federalnych, wymiany sprzętu i wdrożenia nowych protokołów bezpieczeństwa.
Badania IronNet wykazały, że przeciętna organizacja dotknięta atakiem straciła równowartość około 11% swoich rocznych przychodów. W październiku 2024 roku amerykańska Komisja Papierów Wartościowych i Giełd (SEC) nałożyła kary na cztery firmy technologiczne – Unisys, Avaya Holdings, Check Point Software i Mimecast – za wprowadzające w błąd raporty dotyczące stopnia ich narażenia na skutki tego ataku.
Szczegóły dotyczące preferencji operacyjnych APT29
Analiza wzorców zachowań APT29 podczas operacji SolarWinds ujawnia metodyczne, niemal biurokratyczne podejście do szpiegostwa. Po uzyskaniu dostępu poprzez SUNBURST i zainstalowaniu Cobalt Strike, hakerzy prowadzili działania głównie w godzinach biznesowych – między 8:00 a 17:00 czasu UTC. Sugeruje to, że mamy do czynienia z profesjonalnym zespołem pracującym w ustrukturyzowanej organizacji rządowej, a nie z grupą niezależnych hakerów działających po nocach.
Grupa APT29 wykazała się również doskonałą znajomością technik "living off the land" (wykorzystywania narzędzi dostępnych w systemie). Wszystkie używane przez nich programy (np. ADFIND do rekonesansu Active Directory) były modyfikowane i ukrywane w katalogach naśladujących legalne oprogramowanie. Atakujący dostosowywali nazwy filtrów WMI i zapytań systemowych tak, aby pasowały do schematów nazewnictwa stosowanych przez administratorów konkretnej ofiary. Ta zdolność do "wtapiania się w tło" świadczy o głębokim zrozumieniu procedur operacyjnych atakowanych podmiotów.
Analiza wzorców zachowań APT29 podczas operacji SolarWinds ujawnia metodyczne, niemal biurokratyczne podejście do szpiegostwa. Po uzyskaniu dostępu poprzez SUNBURST i zainstalowaniu Cobalt Strike, hakerzy prowadzili działania głównie w godzinach biznesowych – między 8:00 a 17:00 czasu UTC. Sugeruje to, że mamy do czynienia z profesjonalnym zespołem pracującym w ustrukturyzowanej organizacji rządowej, a nie z grupą niezależnych hakerów działających po nocach.
Grupa APT29 wykazała się również doskonałą znajomością technik "living off the land" (wykorzystywania narzędzi dostępnych w systemie). Wszystkie używane przez nich programy (np. ADFIND do rekonesansu Active Directory) były modyfikowane i ukrywane w katalogach naśladujących legalne oprogramowanie. Atakujący dostosowywali nazwy filtrów WMI i zapytań systemowych tak, aby pasowały do schematów nazewnictwa stosowanych przez administratorów konkretnej ofiary. Ta zdolność do "wtapiania się w tło" świadczy o głębokim zrozumieniu procedur operacyjnych atakowanych podmiotów.
Wnioski i reformy bezpieczeństwa
Atak na SolarWinds wymusił fundamentalną zmianę w podejściu do bezpieczeństwa łańcucha dostaw (supply chain security). Aż 91% firm dokonało ponownej oceny bezpieczeństwa swoich dostawców po tym incydencie, a 42% wdrożyło nowe programy ochronne. Branża i rządy uznały, że tradycyjny model ochrony – skupiony na bezpieczeństwie wewnętrznym – jest niewystarczający w świecie, w którym zaufany dostawca oprogramowania może stać się koniem trojańskim.
Kluczowe rekomendacje po ataku obejmują: wdrożenie wielowarstwowej obrony (defense in depth), rygorystyczną segmentację sieci, przyjęcie modelu Zero Trust oraz zwiększenie wymiany informacji o zagrożeniach między sektorem prywatnym a publicznym. W odpowiedzi na incydent administracja USA wydała rozporządzenia wykonawcze wymuszające stosowanie uwierzytelniania wieloskładnikowego (MFA) oraz zaawansowanego monitorowania punktów końcowych (EDR) w agencjach federalnych.
Zaproponowano również rewolucyjne zmiany w procesie tworzenia oprogramowania. Koncepcja "Reproducible Builds" (powtarzalnych kompilacji) – zapewniająca, że ten sam kod źródłowy zawsze daje identyczny binarnie plik wynikowy – zyskała na znaczeniu jako metoda weryfikacji integralności oprogramowania. Dodatkowo, coraz powszechniejszym wymogiem staje się Software Bill of Materials (SBOM) – szczegółowy wykaz wszystkich komponentów i bibliotek użytych w oprogramowaniu, co ułatwia zarządzanie ryzykiem.
Atak na SolarWinds wymusił fundamentalną zmianę w podejściu do bezpieczeństwa łańcucha dostaw (supply chain security). Aż 91% firm dokonało ponownej oceny bezpieczeństwa swoich dostawców po tym incydencie, a 42% wdrożyło nowe programy ochronne. Branża i rządy uznały, że tradycyjny model ochrony – skupiony na bezpieczeństwie wewnętrznym – jest niewystarczający w świecie, w którym zaufany dostawca oprogramowania może stać się koniem trojańskim.
Kluczowe rekomendacje po ataku obejmują: wdrożenie wielowarstwowej obrony (defense in depth), rygorystyczną segmentację sieci, przyjęcie modelu Zero Trust oraz zwiększenie wymiany informacji o zagrożeniach między sektorem prywatnym a publicznym. W odpowiedzi na incydent administracja USA wydała rozporządzenia wykonawcze wymuszające stosowanie uwierzytelniania wieloskładnikowego (MFA) oraz zaawansowanego monitorowania punktów końcowych (EDR) w agencjach federalnych.
Zaproponowano również rewolucyjne zmiany w procesie tworzenia oprogramowania. Koncepcja "Reproducible Builds" (powtarzalnych kompilacji) – zapewniająca, że ten sam kod źródłowy zawsze daje identyczny binarnie plik wynikowy – zyskała na znaczeniu jako metoda weryfikacji integralności oprogramowania. Dodatkowo, coraz powszechniejszym wymogiem staje się Software Bill of Materials (SBOM) – szczegółowy wykaz wszystkich komponentów i bibliotek użytych w oprogramowaniu, co ułatwia zarządzanie ryzykiem.
Konsekwencje regulacyjne i dialog międzyagencyjny
Raport Government Accountability Office (GAO) ujawnił, że wymiana informacji między agencjami federalnymi w trakcie reagowania na incydent SolarWinds była "powolna i utrudniona". Różne poziomy klauzul tajności między organami ścigania, sektorem prywatnym i wywiadem komplikowały szybką analizę zagrożeń. Wnioski te doprowadziły do postulatów utworzenia scentralizowanego forum koordynującego działania międzyagencyjne w przypadku przyszłych kryzysów cybernetycznych o skali krajowej.
Raport Government Accountability Office (GAO) ujawnił, że wymiana informacji między agencjami federalnymi w trakcie reagowania na incydent SolarWinds była "powolna i utrudniona". Różne poziomy klauzul tajności między organami ścigania, sektorem prywatnym i wywiadem komplikowały szybką analizę zagrożeń. Wnioski te doprowadziły do postulatów utworzenia scentralizowanego forum koordynującego działania międzyagencyjne w przypadku przyszłych kryzysów cybernetycznych o skali krajowej.
Źródła:
https://attack.mitre.org/campaigns/C0024/
https://www.solarwinds.com/blog/an-investigative-update-of-the-cyberattack
https://www.reuters.com/world/us/hackers-solarwinds-breach-stole-data-us-sanctions-policy-intelligence-probes-2021-10-07/
https://www.crowdstrike.com/en-us/blog/sunspot-malware-technical-analysis/
https://attack.mitre.org/software/S0559/
https://www.picussecurity.com/resource/blog/apt29-cozy-bear-evolution-techniques
https://www.datacenterknowledge.com/data-breaches/the-list-of-known-solarwinds-breach-victims-grows-as-do-attack-vectors
https://www.cybersecuritydive.com/news/solarwinds-1-year-later-cyber-attack-orion/610990/
https://arxiv.org/pdf/2211.02341.pdf
https://ieeexplore.ieee.org/document/10179320/
https://eurepoc.eu/pl/publication/major-cyber-incident-solarwinds/
https://www.ncsc.gov.uk/guidance/dealing-with-the-solarwinds-orion-compromise
https://www.kiuwan.com/blog/solarwinds-hack-timeline/
https://www.cnbc.com/2021/01/05/us-feds-say-russians-likely-behind-solarwinds-hack.html
http://arxiv.org/pdf/2408.07054.pdf
https://attack.mitre.org/campaigns/C0024/
https://www.solarwinds.com/blog/an-investigative-update-of-the-cyberattack
https://www.reuters.com/world/us/hackers-solarwinds-breach-stole-data-us-sanctions-policy-intelligence-probes-2021-10-07/
https://www.crowdstrike.com/en-us/blog/sunspot-malware-technical-analysis/
https://attack.mitre.org/software/S0559/
https://www.picussecurity.com/resource/blog/apt29-cozy-bear-evolution-techniques
https://www.datacenterknowledge.com/data-breaches/the-list-of-known-solarwinds-breach-victims-grows-as-do-attack-vectors
https://www.cybersecuritydive.com/news/solarwinds-1-year-later-cyber-attack-orion/610990/
https://arxiv.org/pdf/2211.02341.pdf
https://ieeexplore.ieee.org/document/10179320/
https://eurepoc.eu/pl/publication/major-cyber-incident-solarwinds/
https://www.ncsc.gov.uk/guidance/dealing-with-the-solarwinds-orion-compromise
https://www.kiuwan.com/blog/solarwinds-hack-timeline/
https://www.cnbc.com/2021/01/05/us-feds-say-russians-likely-behind-solarwinds-hack.html
http://arxiv.org/pdf/2408.07054.pdf