[PL] OPSEC w cyberbezpieczeństwie: jak drobne błędy operacyjne dekonspirują zarówno przestępców, jak i zespoły SOC
Bezpieczeństwo operacyjne (OPSEC) to zestaw praktyk chroniących wrażliwe informacje oraz działania organizacji przed przypadkowym lub celowym ujawnieniem. W testach penetracyjnych i pracy zespołów red team oraz blue team OPSEC decyduje o tym, czy operacja zakończy się sukcesem, czy dekonspiracją.
Błędy w OPSEC po stronie zespołów obrony potrafią sparaliżować reakcję na incydent, a wpadki atakujących często prowadzą do ujawnienia ich tożsamości. Dlatego zarówno Blue Team (specjaliści obrony), jak i Red Team (symulujący ataki) doskonalą techniki ukrywania swoich zamiarów.
Wpadki OPSEC mogą przydarzyć się każdemu
Wpadki OPSEC potrafią się przydarzyć każdemu. Aktualnym przykładem jest zdjęcie Karola Nawrockiego, który w ramach kampanii wyborczej udostępnił swoje zdjęcie z wynikami badań na obecność narkotyków.
Ze zdjęcia jesteśmy w stanie odczytać nie tylko wynik badania, ale również numer zlecenia oraz datę urodzenia, które są potrzebne do pobrania oryginalnego zlecenia. Doprowadziło to do tego, że Diagnostyka+ zablokowała usługę pobierania zleceń w taki sposób.
Silk Road i cena drobnych błędów OPSEC
Mogłoby się wydawać, że cyberprzestępcy nie będą tak „nierozsądni”, skoro są aktywnie poszukiwani przez służby. Otóż nic bardziej mylnego - właściciel jednego z pierwszych i największych sklepów internetowych darknetu (Silk Road) został namierzony przez podstawowe błędy OPSEC. Jednym z nich było poszukiwanie administratora do tego sklepu, a kandydaci mieli się odezwać na adres rossulbricht@gmail.com.
Sama historia ujęcia przestępcy jest ciekawa — śledzenie Ulbrichta wykazało, że pracuje w filii Glen Park Library. Agenci zainscenizowali kłótnię, by odciągnąć jego uwagę, po czym przejęli otwarty i wciąż zalogowany laptop, zanim zdążył go zamknąć lub zablokować — co uruchomiłoby pełne szyfrowanie dysku. Dopiero wtedy podłączyli pendrive z oprogramowaniem kopiującym kluczowe pliki. To, w połączeniu z brakiem szyfrowania danych, spowodowało, że Ross Ulbricht został skazany na dożywocie. Pomimo tego, przestępca został ułaskawiony przez prezydenta Donalda Trumpa i obecnie przebywa na wolności.
Jak atakujący wykorzystują OPSEC przeciwko zespołom Blue Team
Atakujący nie tylko muszą dbać o OPSEC, ale przez jego zrozumienie są w stanie go wykorzystać przy swoich operacjach. Przedstawię kilka tricków, które wykorzystują atakujący w trakcie ofensywnych operacji, opierając się na złych praktykach OPSEC zespołów Blue Team.
Canary tokens (kanarki)
Kanarki to takie pliki, które po otwarciu wysyłają zapytanie DNS na wybrany przez nas adres. Taki trick daje atakującemu przewagę - po pierwsze wie, kto otworzył maila, co zawęża jego pole zainteresowań. A po drugie, gdy SOC (centrum operacji cyberbezpieczeństwa) jest nierozważny, dostaje sygnał, że jest pod lupą i czas zacierać ślady. Jednym z przykładów skonstruowania takiego beacona (sygnały wywoławczego) w emailu jest wrzucenie obrazu 1x1 ze źródłem kierującym na kontrolowany przez nas serwer.
<html>
<body style="font-family:Arial, sans-serif">
<p>Cześć,<br>
Tutaj jest jakaś wiadomość.<br>
Pozdrawiam,<br>
Tester
</p>
<img src="http://[serwer]/kanarek"
width="1" height="1" style="display:none" alt="" />
</body>
</html>
Wykorzystałem do tego Burp Collaboratora - tak wygląda collaborator po otwarciu maila, w którym na pierwszy rzut oka nie widać nic szpiegowskiego. Mail został otwarty przez klienta pocztowego Gmail i oprócz zapytań DNS wysyła również zapytanie HTTP.
Takim „kanarkiem” wcale nie musi być wiadomość lub plik. Na przykład, gdy atakujący korzysta z przejętego konta, może sobie ustawić opcję „powiadom mnie po zmianie hasła / aktywacji MFA”. Zawsze trzeba patrzeć szeroko przy analizie udanego ataku, żeby wychwycić wszystkie strategie atakującego. Blue Team, aby się nie zdradzić, powinien maile czy pliki sprawdzać zawsze na odizolowanych (od sieci wewnętrznej oraz od internetu) specjalnie przygotowanych maszynach.
Monitorowanie VirusTotala jako źródło wycieku informacji o incydencie
Wyobraźmy sobie sytuację. Analityk 1. linii wsparcia obsługuje incydent - jeden z plików został skwarantannowany przez antywirusa. Analityk wyciąga plik z kwarantanny, odszyfrowuje go i wrzuca do VirusTotala (VT). Niedługo później na maszynach uruchamia się moduł szyfrujący, próbujący zatrzeć ślady oraz zyskać na czasie przy ucieczce. Skąd atakujący wiedział, że został wykryty?
VirusTotal to nie tylko narzędzie dla obrońców - atakujący może sam policzyć sumę kontrolną swojego payloadu i skryptem o taką sumę odpytywać. W momencie, w którym dostanie informację o liczbie silników antywirusowych, które wykryły plik jako szkodliwy, wie, że jest w trakcie rozpracowywania. To nie tyczy się tylko hashy, ale tak naprawdę każdego IoC (artefaktu wskazującego na atak), czyli domen, adresów IP czy TTP (taktyk, technik i procedur atakujących). Ta strategia jest znana grupom APT, takim jak APT-28 czy APT-29.
Jak się przed tym uchronić? Przede wszystkim nie wrzucać plików do VT przed pełną obsługą incydentu komputerowego (wyjątkiem jest „prywatne skanowanie” dla użytkowników wersji enterprise), a analizę przeprowadzać lokalnie. Warto odpytać VT o hash złośliwego oprogramowania lub sprawdzić, czy domeny/adresy były wcześniej wrzucane przez kogoś innego (odpytanie o hash nie jest widoczne dla atakujących), ale jeśli nie były, nie uruchamiać skanowania (VT oraz inne narzędzia mogą to zrobić automatycznie przy wpisywaniu adresu IP - należy być ostrożnym). Ponadto, jeśli chcemy odpytać o domenę czy adres, powinniśmy robić to z komputera „spoza SOC”, podłączonego do VPN.
Pamiętaj, że domena też może być „słabo ukryta” celowo - tak, aby zwykły użytkownik nie mógł jej znaleźć, ale analityk czy informatyk już tak. Dodatkowo, jeśli znajdziesz stronę phishingową, nie wpisuj tam adresu admin@test.pl i hasła Password123, ponieważ atakujący domyśli się, że ktoś testuje jego stronę phishingową, i ucieknie. Podobnie komputer może być monitorowany przez atakującego - gdy zobaczy, że ktoś próbuje podłączyć się po RDP (zdalny pulpit), może spanikować i zacząć zacierać ślady. Lepiej jest monitorować atakującego przez narzędzia SOC-owe.
Oto przykład wyszukania IoC na VT, które nie powoduje skanowania, gdy IoC nie znajduje się w bazie. Hash nigdy nie zostanie przeskanowany, ale domeny i adresy IP, gdy nie były wcześniej wprowadzone - tak. Nie można tego zrobić w darmowej wersji.
Za darmo możemy przeszukać urlscan lub AbuseIPDB.
To samo dotyczy raportów, które publikujemy. Czasem jest to nieuniknione (np. publikacja raportu przez firmę bezpieczeństwa), ale warto pamiętać, że atakujący uważnie czytają raporty i analizy dotyczące ich własnych operacji. Grupy APT często zmieniają narzędzia i TTP natychmiast po wykryciu. Przykładem jest chińska grupa APT12 (znana też jako IXESHE/DynCalc): po opublikowaniu przez Arbor Networks szczegółów ich backdoora Etumbot operatorzy APT12 szybko zmodyfikowali malware, tworząc nową wersję (ochrzczoną przez FireEye jako HIGHTIDE) różniącą się protokołem i stringami. Zmiany te powstały wprost w reakcji na bloga Arbor - by obniżyć wykrywalność przez rozwiązania bezpieczeństwa.
Monitorowanie przejętego kanału komunikacji SOC
Trzeba być bardzo ostrożnym przy prowadzeniu korespondencji w trakcie incydentu. Jeżeli w trakcie analizy coś wskazuje na choćby cień szansy, że stacje robocze lub skrzynki pocztowe należące do SOC również mogą być przejęte - należy przerzucić się na alternatywny kanał komunikacji. Czy są to osobne VoIP, telefony komórkowe, czy po prostu inne systemy - jeżeli atakujący będzie znał strategię SOC-u, to będzie o wiele kilometrów przed nim. Dlatego nie można dopuścić, aby się o niej dowiedział.
Błędy w konfiguracji: Sysmon i sandbox evasion
Sysmon (System Monitor) to serwis odpowiadający za logowanie wielu zdarzeń w dzienniku systemowym. To, co będzie logowane, możemy skonfigurować w pliku konfiguracyjnym (np. domyślnie c:\windows\config.xml). Jednak trzeba się liczyć z tym, że jeśli umieszczamy reguły detekcji w jawnym pliku, w domyślnej lokalizacji i bez alertów, jesteśmy skazani na porażkę - atakujący wie, co zostaje w logach, a co nie, co pozwala mu przeprowadzić skuteczniejszy i cichszy atak. Przykład z Sysmonem jest wzięty z ćwiczenia, a raport z niego można przeczytać na: cisa.gov/news-events/cybersecurity-advisories/aa24-193a.
Ciekawym przypadkiem do analizy jest nowoczesny malware kontra środowiska sandboxowe. Złośliwe oprogramowanie jest w stanie wyłapać, czy siedzi w prostym sandboxie: sprawdza liczbę procesów, liczbę dostępnych wątków, typowe adresy MAC/IP dla rozwiązań skonteneryzowanych lub zwirtualizowanych, i jeśli uzna, że środowisko jest podejrzane, wstrzymuje swoje działania. Doświadczony inżynier wsteczny będzie w stanie obejść takie zabezpieczenia malware, jednak wystarczy odpowiednio przygotować sandbox przed analizą.
Podsumowanie
OPSEC to kluczowa strategia zarówno dla obrońców, jak i atakujących. Zabezpieczenie czy skrycie nawet drobnych detali może przesądzić o powodzeniu całej operacji. Przykłady od polityka z numerem zlecenia, przez Silk Road, po mechanizmy monitoringu VirusTotal i kanarki DNS pokazują, że każdy etap (od maili po analizę sandboxów) wymaga izolacji, szyfrowania i stałej czujności. Blue Team musi zawsze korzystać z bezpiecznych, odizolowanych środowisk; Red Team z kolei wykorzystuje wszelkie „szpiegowskie” triki, by wyprzedzić detekcję. Skuteczna ochrona to nie tylko nowoczesne narzędzia, ale przede wszystkim dyscyplina i świadomość, że najmniejszy wyciek informacji może zniweczyć cały plan.