Infrastruktura testów socjotechniczny – Gophish cz. 2

Dzisiejszy wpis to kontynuacja wpisu sprzed tygodnia, w którym pokazałem w jaki sposób uruchomić instancję Gophisha. W poprzednim wpisie powiedzieliśmy, iż pomiędzy serwerem Gophish, a odbiorcą wiadomości powinien istnieć serwer SMTP Relay. Działa on analogicznie do redirectorów w przypadku serwerów C2. SMTP Relay umożliwia bezpieczne operowanie serwerem Gophish, a ewentualne „spalenie” serwera SMTP Relay nie jest bolesne, ponieważ możemy względnie gwałtownie uruchomić kolejny.

Przypomnijmy też, iż ideą serwerów SMTP Relay jest to, aby były one godne zaufania dla serwerów poczty przychodzącej. Wiarygodność zwiększają np. wpisy SPF lub DKIM w domenie. W ramach tego artykułu pokażę jak dodać ww. wpisy.

Mailjet

W końcówce poprzedniego wpisu wspomniałem o usłudze Amazon SES, jednak stwierdziłem, iż chodzenie na skróty się nie opłaca. W rzeczywistej kampanii phishingowej, nikt nie będzie korzystać z serwisów, które wymagają KYC (Know Your Customer). Dlatego postanowiłem pójść drogą drogą nieco bardziej wyboistą, ale bardziej real-life. Po krótkim researchu odkryłem, iż platformą, która umożliwia tworzenie kampanii e-mail bez weryfikacji np. kartą płatniczą jest Mailjet.

Rejestracja w serwisie Mailjet

Po dokonaniu rejestracji możemy dodać domenę z której będziemy wysyłać wiadomości. Rzecz jasna, musimy być właścicielem tej domeny co zostanie gwałtownie zweryfikowane poprzez dodanie odpowiedniego wpisu TXT w strefie DNS.

SPF

Po zweryfikowaniu domeny nadszedł czas na uzupełnienie wpisów SPF oraz DKIM. W tym celu klikamy na „Authenticate this domain (SPF/DKIM)” i otwieramy stronę zawierającą odpowiednie wpisy. Prawidłowy wpis SPF znacząco podnosi rating naszej domeny, więc warto zadbać o to, aby był on poprawnie zaimplementowany.

W strefie DNS na OVH należy dokonać następującego wpisu SPF, zgodnego z wpisem wyświetlanym na powyższym zrzucie ekranu:

Wpis SPF w DNS

Wpis ten oznacza, ze zarówno serwery określone w rekordach SPF spf.mailjet.com oraz mx.ovh.com będą autoryzowane do wysyłania wiadomości w imieniu domeny red-academy.pl. Niezwykle ważnym elementem jest również „-all”, który oznacza, iż wszystkie inne serwery nie są autoryzowane do wysyłania wiadomości e-mail.

Gdy serwer odbiorcy otrzyma naszą wiadomość, sprawdzi czy serwer SMTP Mailjet jest upoważniony do wysyłania informacji w imieniu red-academy.pl o ile tak, ryzyko odrzucenia takiej wiadomości pod pretekstem SPAMu drastycznie spada.

DKIM

Kolejnym elementem, który poprawia wiarygodność naszych wiadomości jest DKIM. DKIM to nic innego jak podpisywanie emaili. Podpisywanie, jak wszyscy wiemy, służy zapewnieniu integralności wiadomości oraz jej autentyczności. W jaki sposób to działa? Gdy wiadomość jest wysyłana, serwer pocztowy (w tym przypadku Mailjet) używa klucza prywatnego do podpisywania części wiadomości (skrótu całości, nagłówków, całej treści itp.). Podpis cyfrowy jest dodawany do wiadomości jako nagłówek. Kiedy serwer odbiorcy otrzymuje wiadomość, pobiera klucz publiczny z rekordu DKIM strefy DNS i używa klucza publicznego do weryfikacji podpisu. Magia kryptografii asymetrycznej. o ile podpisy się zgadzają – wiadomość jest uznawana za autentyczną, a jej integralność jest nienaruszona. Ryzyko odrzucenia wiadomości pod pretekstem SPAMu po raz kolejny drastycznie nam spada.

Podobnie jak w przypadku SPFu, odpowiedni wpis DKIM pobieramy z interfejsu Mailjet i umieszczamy w strefie DNS OVH.

Wpis DKIM w DNS

Po dodaniu odpowiednich wpisów należy poczekać kilka minut na ich propagację w strefach DNS. Po chwili możemy zweryfikować w serwisie Mailjet poprawność wpisów.

Weryfikacja poprawności wpisów

Świetnie, wygląda na to, iż SPF i DKIM są skonfigurowane poprawnie.

Generowanie username i hasła dla SMTP – API Key i Secret Key

Pamiętacie Sending Profile w Gophish? Należało tam wskazać adres serwera SMTP, port oraz nazwę użytkownika i hasło. Ustawienia te możemy łatwo pozyskać w zakładce SMTP and SEND API settings w serwisie Mailjet.

Okej, mamy nazwę hosta oraz port(y). Ale chwila chwila, gdzie jest login i hasło? Chwilę (całe 30 sekund) zajęło mi dojście do tego, że:

• Username to API Key
• Hasło to Secret Key

API Key można podejrzeć na Dashboardzie, a Secret Key należy dodatkowo wygenerować.

Uwaga! Po wygenerowaniu Secret Key zapiszcie go, ponieważ nie ma możliwości aby podejrzeć go później.

Mając zestaw wszystkich niezbędnych informacji, możemy przejść do tworzenia Sending Profile w Gophish.

Sending Profile

Jeżeli nie chcecie sobie spalić konta zanim jeszcze rozpoczęliście kampanię, nie wysyłajcie testowej wiadomości. Dacie znać wszystkim dookoła, iż wasza domena oraz wasze konto na Mailjet będzie służyć do phishingu. I nikogo nie interesuje to, iż robicie to w szczytnym celu, duże serwisy nie maja czasu w weryfikowanie czy kampania phishingowa jest etycznym testem socjotechnicznym czy rzeczywistą, złośliwą kampanią.

Czy to w ogóle działa?

Zweryfikujmy poprawność konfiguracji, wysyłając próbną kampanię.

Po wystartowaniu kampanii, po chwili wiadomości dotarły na 4 skrzynki pocztowe (M365 Exchange, Personal Outlook, Gmail, Onet). W żadnym z powyższych przypadków wiadomość nie znalazła się w SPAMie.

Wiadomość w skrzynce GMAIL

Po wyświetleniu szczegółów wiadomości, w żadnym z nagłówków nie znajdowała się informacja o adresie IP mojego Gophisha. Świetnie! Udało się skorzystać z SMTP Relay w celu ochrony serwera Gophish.

Wyniki testowej kampanii

HTTP Redirector

Chwila chwila. Wnikliwy czytelnik zauważy, iż adres IP Gophisha i tak jest udostępniany, ponieważ landing page znajduje się pod adresem IP serwera Gophish. Po kliknięciu w link, użytkownik jest przekierowywany na stronę:

Tym samym, zdradzamy adres IP naszej infrastruktury do phishingu.

Generalna zasada jest taka, iż potencjalne ofiary naszych działań, nie powinny mieć nigdy bezpośredniego dostępu do naszej kluczowej infrastruktury. Zależy nam na tym również po to, aby zmylić ewentualne działania Blue Teamów oraz Threat Hunterów. Każda interakcja ofiary z naszymi zasobami powinna odbywać się poprzez Redirectory – łatwo zastępowalne i zanonimizowane zasoby.

Powinniśmy dążyć do infrastruktury przypominającej poniższą:

SMTP Relay pośredniczy pomiędzy odbiorcą wiadomości email, a naszym serwerem Gophish. Serwer Nginx pośredniczy pomiędzy odbiorcą, a serwerem HTTP Gophish, który wystawia Landing Page.

Powiedzmy, iż chcemy kontynuować kampanię z Voucherem. W tym celu, dodajmy rekord A voucher.red-academy.pl, który wskazuje na VPS z Nginxem. Następnie, na VPS należy zainstalować certbota oraz Nginxa.

sudo apt install nginx sudo apt install certbot python3-certbot-nginx

A następnie generujemy niezbędne certyfikaty dzięki certbota.

sudo certbot --nginx -d voucher.red-academy.pl --register-unsafely-without-email

Po poprawnym wygenerowaniu certyfikatów, przechodzimy do edycji pliku konfiguracyjnego Nginxa. Dzięki niemu, wszystkie połączenia przychodzące na adres voucher.red-academy.pl, będą przesyłane do Gophisha poprzez Nginxa. Jest to klasyczne zastosowanie tego serwera w roli tzw. reverse proxy. Co interesujące – program Certbot sam wygenerował część pliku konfiguracyjnego. Należy więc jedynie sprawdzić czy wszystkie wygenerowane dane się zgadzają.

server { server_name voucher.red-academy.pl; location / { proxy_pass http://X.Y.A.B; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/voucher.red-academy.pl/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/voucher.red-academy.pl/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } server { if ($host = voucher.red-academy.pl) { return 301 https://$host$request_uri; } # managed by Certbot listen 80; server_name voucher.red-academy.pl; return 404; # managed by Certbot

Nie pozostaje nam nic innego jak sprawdzić poprawność konfiguracji Nginxa i zrestartować usługę.

sudo nginx -t sudo systemctl restart nginx

Świetnie! Voucher.red-academy.pl przekierowuje nas na serwer Gophisha (wiem to po komunikacie błędu „404 page not found”).

Należy uruchomić zatem jeszcze jedną kampanię, która tym razem będzie zawierała inny URL i szablon wiadomości. Zwróćcie uwagę, iż w polu „URL” nie wskazuje tym razem adresu IP Gophisha. Podaję ładną nazwę domenową, która wskazuje na nasz serwer Nginx.

Wiadomość dotarła. Sprawdźmy co stanie się gdy klikniemy w link.

Świetnie! Pod linkiem kryje się nasza niewinna nazwa „voucher.red-academy.pl” z prawidłowym certyfikatem. „Pod spodem” Nginx wykonuje magię i proxuje ruch do serwera Gophish. Otrzymujemy więc Landing Page z Gophisha. Wygląda to dużo, dużo lepiej niż brzydki adres IP oraz brak SSLa.

Ponadto, po wejściu na stronę Gophish poprawnie zinterpretował wejście i odznaczył kliknięty link na Dashboardzie.

Podsumowanie

W tym wpisie pokazałem w jaki sposób możemy skonfigurować środowisko do testów socjotechnicznych. Pokazałem też w jaki sposób zabezpieczyć swoją kluczową infrastrukturę (serwer Gophish) dzięki redirectorów SMTP oraz HTTP. W podobny sposób możemy zabezpieczyć serwery C2 czy serwery hostujące nasze payloady, podczas działań Red Teamowych.

Jeżeli chcielibyście nauczyć się więcej takich, prostszych czy trudniejszych zagadnień – zapraszam na Red Academy .