W dzisiejszym wpisie zaprezentuję możliwości związane z wykorzystaniem oprogramowania Evilginx do przeprowadzania testów socjotechnicznych. Jest to doskonałe narzędzie, które można wykorzystać w (etycznych) testach socjotechnicznych oraz działaniach Red Team w celu uzyskania dostępu do zasobów chronionych przez 2FA. Zapraszam!

Wstęp teoretyczny

Program Evilginx to narzędzie będące serwerem proxy, które umożliwia wykonanie ataku MiTM (lub jak kto woli AiTM – Adversary in the Middle). Jego zadaniem jest przekierowywanie zapytań od użytkownika końcowego do serwera docelowego i odwrotnie, a w międzyczasie udostępnianie potencjalnemu adwersarzowi wartościowych danych w postaci:

• ciasteczek sesyjnych
• danych logowania

Idea Evilginxa polega na tym, że serwer ten nie terminuje połączenia SSL. Użytkownik jest w rzeczywistości połączony do złośliwej domeny login-outloook.com (w dalszej części zwanej również jako nasza-domena,pl), a wyświetlana jest mu zawartość z login.outlook.com na takiej samej zasadzie na jakiej dowolny serwer reverse proxy (Nginx) przekierowuje ruch.

Ponieważ cały ruch przechodzi przez serwer Evilginx, który terminuje połączenie SSL i otwiera oddzielne z docelowym serwerem, możliwe jest logowanie wszelkich danych przesyłanych przez użytkownika, jak również przesłanie atakującemu ciasteczek, które Użytkownik otrzymuje od docelowego serwera (np. od poczty Outlook.com).

Przygotowanie infrastruktury – praktyka

Aby serwer Evilginx działał poprawnie, musi być on serwerem DNS dla naszej domeny. Dlaczego? W przypadku logowania z wykorzystaniem usług Microsoft, „pod spodem” dzieje się dosyć dużo w kontekście ruchu HTTP/S. Wysyłanych jest bardzo dużo danych, do różnych domen i subdomen związanych z Microsoftem. Połączenia wykonywane są do takich subdomen jak:

• account
• cdn
• login
• www
• live

Aby każda z tych subdomen (np. login.nasza-domena.pl) była rozwiązana na adres IP naszego serwera Evilginx, najlepiej aby był on sam dla siebie serwerem DNS i dowolne zapytanie rozwiązywał na swój adres IP.

W tym celu, na OVH, należy dokonać kilku zmian:

• utworzyć wpis GLUE który wskazuje na nazwe ns1.nasza-domena.pl na adres IP evilginxa
• utworzyć dwa wpisy w strefie DNS, które będą wskazywać na serwer evilginx. Dlaczego dwa? Ponieważ OVH nie pozwoli na dodanie jednego serwera DNS. Więc możemy go oszukać podając dwie nazwy wskazujące na ten sam adres IP
  • ns1.nasza-domena.pl
  • ns2.nasza-domena.pl
• Zmienić serwer DNS na evilginxa

Niektóre z powyższych kroków (lub ich rezultaty) przedstawiłem na poniższych zrzutach ekranu:

Należy pamiętać, że OVH (nie wiem jak inni providerzy) nie pozwolą na dodanie serwerów DNS, które nie odpowiadają prawidłowo na zapytania DNS. Aby pokonać ten problem należy przepuścić na firewallu ruch na portach 53 (UDP oraz TCP) na naszym VPSie. Powinniśmy również dopuścić ruch HTTPS (rzecz jasna) i dla spokoju – HTTP.

Konfiguracja Evilginxa

Działanie Evilginxa w głównej mierze oparte jest o pliki zwane phishletami. Jest to plik konfiguracyjny, szablon, w którym ustawiane są parametry zachowania serwera proxy (Evilginx oparty jest, niespodzianka, na Nginxie). Możemy zdefiniować w nim jakie parametry zapytań i jakie ciasteczka chcemy przechwytywać, jak przekierowywać zapytania do docelowego serwera, jakie nagłówki trzeba dołączać, a jakich nie należy.

Struktura phishletu oparta jest o składnię YAML, w której definiujemy poszczególne elementy w oparciu o dokumentację. Samodzielne tworzenie phishletu od zera nie jest łatwe, a sam twórca Evilginxa usunął gotowe phishlety ze swojej strony, odsyłając do społeczności na Githubie lub do swojego kursu ;-).

Phishlety do popularnych usług możemy bardzo łatwo znaleźć w sieci. Część działa od lat, a używanie innych jest regularnie mitygowane przez dostawców usług. Microsoft od czasu do czasu zmienia network flow procesu uwierzytelnienia, nazwy ciasteczek i na moment pisania tego tekstu nie znalazłem gotowego phishletu, który działałby z usługą Microsoft 365. Możemy jednak względnie szybko doprowadzić te dostępne w Internecie do działania (regexy w auth_tokens Twoim przyjacielem ;)).

Mając przygotowany phishlet, przenosimy go do katalogu ./phishlets i uruchamiamy Evilginxa:

make
sudo ./build/evilginx -p ./phishlets -t ./redirectors

W kolejnym kroku konfigurujemy domenę i wskazujemy adres IP naszego hosta, a także włączamy nasz phishlet

config domain nasza-domena.pl
config ipv4 [adres IP Evilginxa]
phishlets hostname [Twój Phishlet] nasza-domena.pl
phishlets enable [Twój Phishlet]

Gdy włączamy phishlet po raz pierwszy, program automatycznie pozyskuje wszelkie niezbędne certyfikaty z wykorzystaniem certbota. W chwilę po uzyskaniu certyfikatow, w logach programu pojawiają się dziesiątki (o ile nie setki) połączeń od publicznie znanych botów i crawlerów różnych dostawców. Uważam, że skuteczne blokowanie tych botów jest prawdziwym kluczem do sukcesu w powodzeniu kampanii phishingowej. Jeżeli nasza domena zostanie oflagowana jako złośliwa – nici z naszego Red Teamu.

Po pozyskaniu certyfikatów i włączeniu phishleta, tworzymy tzw. lures, czyli linki do wysłania.

lures create [Twój phishlet]
lures get-url 0

Po stworzeniu URLa nie pozostaje nam nic innego jak wysłać go w wiadomości phishingowej. Legendę i pretekst pozostawiam Wam 🙂

No ale jak to wygląda w praktyce?

W praktyce, ofiara po wejściu na phishingowy link otrzymuje prawdziwą stronę logowania, przeproxowaną zgodnie z regułami zapisanymi w phishlecie. Działa to jak zwykłe reverse proxy, więc w oknie przeglądarki mamy naszą, złośliwą domenę i jej certyfikat.

Wpisaniu danych logowania bez problemu przechwytujemy wpisane credentiale – końcu cały ruch przechodzi przez nasz serwer. Po chwili ofiara przepisuje też kod 2FA z telefonu i zostaje przekierowana na docelową stronę (w tym przypadku www.office.com), a my cieszymy się z przejętych ciasteczek.

W ostatnim kroku, aby wykorzystać ww. ciasteczka należy skorzystać z wtyczki cookie-editor w programie Firefox. Czyścimy stare ciasteczka, klikamy „Import” i zaznaczamy wszystkie ciasteczka przejęte przez program Evilginx, wklejamy w oknie cookie-editora i klikamy „Import”.

Po zaimportowaniu ciasteczek wchodzimy na stronę www.office.com i cieszymy się sesją użytkownika 8-).

Jak się bronić? Dla strony Blue

Przede wszystkim powinniśmy korzystać z drugiego składnika uwierzytelnienia, który jednoznaczenie identyfikuje stacje kliencką, dzięki czemu połączenie do docelowego serwera wykonywane de-facto przez serwer Evilginxa nie będzie traktowane jako zaufane. Przykładem mogą być klucze sprzętowe FIDO2 (Yubikey etc.), które chronią przed tym scenariuszem. Niżej wklejam dobrze znaną tabelkę, która pokazuje która metoda dostarczania drugiego składnika chroni przez atakiem AiTM:

Co jeszcze możemy zrobić? Z pomocą przychodzi nam też Microsoftowy Conditional Access Policies, dzięki któremu możemy ograniczyć połączenia z wykorzystaniem:

• Trusted Locations
• Compliant devices only

Te dwie metody, które intuicyjnie rozumiemy, pozwalają na ograniczenie możliwości logowania do firmowych zasobów z określonych lokalizacji, a drugi pozwala na logowanie tylko sprzętu spełniającego określone warunki. Ubuntu Linux adwersarza, na którym wystawiony jest Evilginx prawdopodobnie nie będzie spełniać tych warunków 😉

Jak się lepiej atakować? Dla strony Red

Domena z uruchomionym Evilginxem nie przeżyje długo przy domyślnej konfiguracji. Crawlery takich firm jak Microsoft, Palo Alto czy innych dużych korporacji związanych z bezpieczeństwem szybko oflagują naszą infrastrukturę. Skorzystaj z porad zawartych w tym tekście aby ograniczyć to ryzyko 😉