Wstęp
Ataki socjotechniczne są ciągle jedną z najskuteczniejszych
metod wykorzystywaną przez intruzów. Aby zrozumieć metody stosowane przez
intruzów od czasu do czasu musimy zasymulować taki atak. W tym artykule krok po
kroku pokażemy jak wygląda przykładowa faza przygotowania scenariusza ataku
socjotechnicznego z użyciem złośliwego oprogramowania.
Opisane przykłady mogą być stosowane wyłącznie w celach
edukacyjnych.
Veil-Evasion
Veil-Evasion jest aplikacją z zestawu narzędzi Veil-Framework,
który służy do generowania złośliwego oprogramowania (obecnie 51 modułów) oraz
obfuskacji już wcześniej wygenerowanego złośliwego kodu. Veil-Evasion pozwala
nam na generowanie payload-ów w różnych językach programowania.
Poniżej fragment dostępnych modułów:
Nie wszystkie modułu tego generatora są jednakowo skutecznie.
Co ciekawe zastosowanie niektórych z nich powoduje większą wykrywalność niż w
przypadku zastosowania natywnych modułów metasploit. Przyjrzyjmy się bliżej jak
działa jeden z dostępnych modułów. Użyjemy modułu ruby/shellcode_inject/base64, który możemy zaliczyć do tych bardziej
skutecznych (czyli mających małą wykrywalność).
Poniżej przykład konfiguracji:
W ustawieniach samego payloadu, zostawiamy opcje
COMPILE_TO_EXE na wartość Y oraz domyślną metodę iniekcji czyli INJECT_METHOD
na Virtual. Następnym krokiem będzie wybranie opcji generate oraz dostarczenie
potrzebnego shellcode’u poprzez oprogramowanie msfvenom.
Veil-Evasion w tym wypadku da nam możliwość wybrania i
wygenerowania shellcode używając bazy msfvenom. Wspominaliśmy wcześniej że
payloady wygenerowane w msfvenom są wykrywalne, jednakże w połączeniu z metodą
obfuskacji jaką dostarcza Veil-Evasion możemy spokojnie skorzystać z już gotowych
modułów msfvenom, oczywiście jeżeli chodzi o sam shellcode.
Wybieramy payload: windows/meterpreter/reverse_https,
następnie podajemy adres serwera C&C. Dlaczego https? Nie wszystkie
organizacje analizują ruch https. Oczywiście możemy też użyć np. komunikacji
DNS ale tak jak już kiedyś pisaliśmy testy socjotechniczne mają też na celu
przetestowanie infrastruktury zamawiającego pod katem różnych ustawień
bezpieczeństwa.
Na koniec zostaniemy poproszeni o nazwę naszego payload-u, np.
ruby_payload.
Poniżej znajduję się kod malware przed przekształceniem do
formy pliku wykonywalnego exe:
Możemy zauważyć że zawarte tam są:
- Wywołania API
dzięki którym załadowany i uruchomiony zostanie shellcode,
- Zakodowany ciąg
kodu malware (shellcode) w postaci base64.
Wiadomość
email
Często powtarzającym się scenariuszem (ze względu na
skuteczność) jest przygotowanie wiadomości z załącznikiem. Treść wiadomości to
zazwyczaj informacja o nieopłaconej fakturze albo „ważne dokumenty” dla
odbiorcy. Jest to jeden z ważniejszych elementów ataku – a treść i forma jest
bardzo istotna i ma kluczowy wpływ na skuteczność całego przedsięwzięcia.
Załącznik
Czasami atakujący załącza bezpośrednio złośliwy plik do
wiadomości – np. javascript dodatkowo kompresuje go i zabezpiecza hasłem. Czasami
jest to link do dokumentu pdf znajdujący się na zewnętrznym serwerze. Innym
mechanizmem jest implementacja złośliwego makra w dokumencie Office. O ile makro
jest dosyć skutecznym sposobem osadzenia malware to okazuje się że organizacje
coraz częściej blokują ich obsługę.
W opisywanym scenariuszu zastosujemy inną ciekawą opcję umieszczenia
złośliwego oprogramowania w dokumencie. Jest nim umieszczenie obiektu OLE (Object
Linking and Embedding) w wcześniej stworzonym dokumencie. Z naszego
doświadczenia wynika że jest to często zapomniany element, który nie jest
poddawany weryfikacji pod kątem obecności malware (niektóre rozwiązania
bezpieczeństwa mają możliwość blokowania „aktywnej zawartości” w dokumentach).
Sposób osadzania obiektu w dokumencie pozwala nam ma
utworzenie bardzo przekonującego scenariusza, który zwiększa szanse na
przeprowadzenie udanego ataku.
Załóżmy, że naszym celem będzie dział reklamacji firmy X. Z
informacji z strony www wiemy że na adres mailowy firmy X czyli reklamacje@firma_x.pl
można zgłaszać reklamacje jako klient indywidualny.
Stwórzmy najpierw prosty dokument Microsoft Word, który po
uruchomieniu będzie wyglądał jakby jego czcionka nie została poprawnie
wyświetlona. Robimy tak pisząc na przykład w mniej używanej czcionce np. MT
Extra. Inną metodą jest po prostu utworzeniu ciągu znaków [] co będzie
przypominało ciąg znaków z źle wyświetloną czcionką.
Dodajemy do dokumentu również informacje o tym, iż jeżeli
dokument nie został wyświetlony poprawnie to prosimy o uruchomienie/instalację
czcionek. Dodajemy więc informacje, tak jak zostało to przedstawione poniżej:
Teraz zostaje nam jedynie osadzenie obiektu OLE, który jest
plikiem ze złośliwym oprogramowaniem, a dla osoby która otrzyma ten dokument, jedynie
„przyciskiem” do „aktywacji czcionek”. Przed wstawieniem zmieniamy jeszcze nazwę wygenerowanego
złośliwego pliku na „Microsoft Word.exe”.
Samo umieszczenie obiektu OLE z pliku nie jest zbyt
zachęcające nawet dla przeciętnego użytkownika, dlatego też zaznaczamy opcje
„Wyświetl jako ikonę”. W tym przypadku nazwiemy nasz plik „Aktywuj czcionki” a
ikonę wybierzemy z znanej biblioteki shell32.dll. Po spreparowaniu odpowiednio
naszego obiektu oraz wprowadzeniu go do dokumentu, całość powinna przedstawiać
się tak:
Nasz dokument jest prawie gotowy, teraz jedynie należy mu
nadać odpowiednią nazwę.
Każda próba „aktywacji czcionek” powodowała nawiązywanie sesji
do serwera C&C na którym znajdował się skrypt wykonujący kilka podstawowych
komend na komputerze ofiary.
Podsumowanie
Pomimo faktu, że technologia osadzania obiektów OLE w plikach z
pakietu MS Office była już w przeszłości używana do przenoszenia złośliwego
oprogramowania, to z wykorzystaniem odpowiednich sztuczek socjotechnicznych
oraz braku odpowiednich mechanizmów ochrony jest duża szansa udanego ataku.
Ataku, który jest prosty i skuteczny.
Źródła