Nie od dziś wiadomo, iż phishing od wielu lat pozostaje najpopularniejszą i najskuteczniejszą metodą ataku, która jest wykorzystywana przez cyberprzestępców. Stali czytelnicy z pewnością wiedzą, iż napisałem już wiele artykułów na temat samego phishingu, jak i narzędzi Microsoft, które pozwalają się przed nim chronić. Jak na pewno część z Was wie, pisząc czy mówiąc o phishingu często można usłyszeć ode mnie stwierdzenie „szkolenie użytkowników jest niezwykle ważne, ale tam gdzie to możliwe, wspomagajmy się technologią”. Po serii artykułów opisujących wspominaną technologię czas przejść do pierwszej części edukacji użytkowników – tym razem na warsztat bierzemy symulator ataków.
Wiele firm przeprowadza cykliczne szkolenia bezpieczeństwa, które użytkownicy często traktują jako „kolejne szkolenie do odhaczenia”. Co z tego, iż przeprowadzamy cykliczne szkolenia, być może po to, żeby wykazać to przy audycie, skoro nie dają one żadnych efektów? A co, o ile dzięki kilku kliknięć moglibyśmy przeprowadzać realnie wyglądające testy na naszych użytkownikach? Z jednej strony sprawdzać ich wiedzę i odporność na socjotechnikę, z drugiej edukować, o ile ich wiedza nie jest wystarczająca? Właśnie do tego służy nam symulator ataków, który również jest oferowany w portfolio usług Microsoft.
Czym jest symulator ataków?
Jak sama nazwa wskazuje, symulator ataków pozwala nam na wysyłanie próbnych ataków phishingowych do naszych użytkowników. W ten sposób możemy nie tylko testować odporność naszych użytkowników na tego typu zabiegi, ale też odkrywać obszary czy typy phishingu, na które są oni bardziej czy mniej podatni. Wśród technik phishingu możemy znaleźć:
- Credential Harvest – technikę polegającą na podstawieniu łudząco podobnej do prawdziwej strony internetowej, na której użytkownik zostawi swoje dane uwierzytelniające
- Malware attachment – technika polegająca na dodaniu do maila załącznika, po otwarciu którego na komputerze ofiary wykonany zostaje złośliwy kod
- Link in Attachment – połączenie powyższych technik – tym razem link nie znajduje się w treści wiadomości, a w załączniku, który jest do niej dołączony
- Link to malware – typ ataku polegający na umieszczeniu linku do złośliwego załącznika (umieszczonego na znanych hostingach typu SharePoint, DropBox, Google Drive) zamiast załączania go do wiadomości
- Drive-by URL – w tym przypadku po kliknięciu w link w wiadomości użytkownik trafia na stronę, która automatycznie próbuje wykonać złośliwy kod na komputerze ofiary
- OAuth Consent Grant – technika, w której atakujący próbuje pozyskać od użytkownika uprawnienia dla działania złośliwej aplikacji (np. dostęp do skrzynki odbiorczej czy danych na urządzeniu)
Samych technik można by pewnie wymienić więcej, choć omawiany mechanizm definiuje je tak jak powyżej. Dla każdej z technik symulator ataków posiada dedykowane payloady (oferowane przez Microsoft lub możliwe do zdefiniowania przez organizację), a przede wszystkim, dedykowane, tematyczne szkolenia, które zostają przypisane do użytkownika w momencie, gdy złapie się on na atak o danej technice. To, jakie szkolenie zostanie finalnie przypisane do użytkownika jest oczywiście definiowane przez osobę wysyłającą próbny atak.
Tworzenie własnych payloadów
Zanim przejdziemy do konfiguracji i wysłania próbnego ataku phishingowego omówmy możliwości budowy bazy elementów, które będziemy mogli wykorzystywać w kampaniach. Zaczynamy od payloadów, które znajdziemy w zakładce Simulation content library:
Sam Payload to oczywiście nic innego, jak treść maila, złośliwy link czy załącznik oraz inne elementy, z których składa się atak phishingowy. Na moment pisania artykułu Microsoft oferuje nam ponad 200 gotowych, starannie przygotowanych payloadów w różnych językach, które możemy wykorzystywać do przeprowadzania symulacji ataków na naszych użytkownikach:
W zakładce Tenant payloads znajdziemy z kolei te, które zostały przygotowane przez naszą organizację, jak również możliwość ich tworzenia:
Tworząc nowy payload w pierwszym kroku musimy określić jego typ. Na moment pisania tego artykułu dostępny jest wyłącznie email, choć wyszarzona opcja sugeruje możliwość przygotowywania ataków egzekwowanych poprzez Teams w najbliższej przyszłości (aktualnie dokumentacja potwierdza Email jako jedyny dostępny typ):
Następnie przypisujemy technikę, czy jedną z kategorii phishingu, które opisywałem powyżej:
W kolejnym kroku określamy nazwę tworzonego payloadu oraz jego opis:
I wreszcie możemy przejść do adekwatnej konfiguracji tworzonej wiadomości phishingowej. Dostępne do konfiguracji pola różnią się w zależności od wybranej techniki ataku. Treść samego ataku zależy już tylko i wyłącznie od nas.
Więcej informacji na temat wypełniania pól, możliwych do wykorzystania domen czy innych możliwości konfiguracyjnych można znaleźć w dokumentacji.
Tworząc payloady i testując użytkowników warto chociażby obserwować bieżące trendy, publikowane np. przez polski CERT, aby wykorzystywać w atakach najnowsze techniki, z którymi mogą spotkać się nasi użytkownicy w przypadku prawdziwego ataku.
Poza ręcznym tworzeniem payloadów możemy również skorzystać z mechanizmu, który pod pewnymi warunkami będzie robił to za nas automatycznie, na bazie wiadomości zgłaszanych jako phishing przez użytkowników. Mechanizm ten, zwany Payload automations znajdziemy w zakładce Automations:
Jego konfiguracja jest niezwykle prosta – poza wskazaniem podstawowych informacji typu nazwa musimy jedynie określić warunki, dla których payloady będą zbierane i zapisywane:
Inne elementy Simulation content library
Poza omawianymi wyżej payloadami możemy jeszcze definiować inne elementy, które będziemy mogli wykorzystać w kampaniach phishingowych. Bez wchodzenia w szczegóły, ponieważ sam kreator wygląda dość podobnie, musimy tutaj wymienić dwa pozostałe elementy:
- Strony logowania
- Powiadomienia dla użytkowników
W sytuacji, gdy np. realizujemy próbny atak wykradający dane uwierzytelniające poza przygotowaniem samej wiadomości czy linku musimy jeszcze podstawić odpowiednią stronę logowania. Ponownie, od Microsoft dostajemy przygotowane już strony logowania do serwisów typu GitHub czy LinkedIn, ale możemy również przygotować interesujące nas strony samodzielnie.
Nie mniej istotne jest również poinformowanie użytkowników, iż złapali się na próbny phishing czy o tym, iż mają do wykonania określone szkolenie. Ponownie – możemy skorzystać z gotowców przygotowanych przez Microsoft lub przygotować powiadomienia samodzielnie (np. obrandowane w logo firmy)
Tworzenie symulacji ataku
Znając już możliwości zapełniania bazy elementami, które będziemy wykorzystywali do tworzenia symulacji ataków, możemy przejść do części adekwatnej – utworzenia i wysłania testowej kampanii. W tym celu w zakładce simulations przechodzimy do Launch a simulation (jeżeli nie mamy włączonego logowania aktywności na naszym tenancie zróbmy to przed uruchomieniem ataku, o ile chcemy zbiera dane – Turn auditing on or off – Microsoft Purview (compliance) | Microsoft Docs).
W pierwszym kroku kreatora wybieramy technikę ataku, którą chcemy zastosować:
Następnie określamy nazwę oraz opis symulacji ataku:
W kolejnym kroku wybieramy wcześniej zdefiniowany payload oraz stronę logowania (w zależności od wybranego typu ataku), która będzie wykorzystana w ataku. Na tym etapie możemy również przejść to tworzenia nowego payloadu. dla wszystkich payloadu dostępny jest oczywiście podgląd jego zawartości, ale o ile nie jest on dla nas wystarczający – możemy z tego miejsca wysłać testowego maila z zaznaczonymi elementami:
Następnie określamy użytkowników, którzy będą celem kampanii. Wybierając użytkowników możemy wskazać konkretne osoby czy grupy, zdefiniować ich na podstawie różnych parametrów np. oddział w którym pracują, dział czy nazwa stanowiska, a także skorzystać z prostych, mniej typowych filtrów np. „Użytkownicy, którzy nie byli celem symulacji w ostatnich 3 miesiącach”:
W kolejnym kroku definiujemy szkolenie, które zostaje przypisane do użytkowników. Szkolenia powiązane z techniką ataku mogą być przypisywane automatycznie, możemy też wskazywać je manualnie. Naturalnie, o ile nie chcemy korzystać ze szkoleń przygotowanych przez Microsoft możemy wskazać URL do którego przekierowany zostanie użytkownik – z nagraniem ze szkolenia, czy z zapisem na szkolenie prowadzone na żywo.
Przygotowane przez Microsoft szkolenia realizowane są z reguły nie więcej niż kilka minut i zawierają różnego typu animacje obrazujące dane zagrożenia. Dla prowadzonej kampanii możemy wskazywać jedno lub więcej szkoleń, które będą przypisywane do użytkowników pod pewnymi warunkami – np. wyłącznie, o ile dadzą się złapać.
Następnie wskazujemy landing page (własny lub przygotowany przez Microsoft), na który trafią użytkownicy, o ile dadzą złapać się na wysłaną symulację. Wybierając odpowiedni landing możemy skorzystać w dostępnego pod przyciskiem na dole podglądu:
W kolejnym kroku konfigurujemy powiadomienia, które będą wysyłane użytkownikom. Wysyłając kampanię możemy skorzystać z domyślnych powiadomień przygotowanych przez Microsoft lub przygotować własne. Istotne będzie również wskazanie kiedy mają być one dostarczane do użytkowników – jeszcze w trakcie trwania kampanii czy może po jej zakończeniu (np. żeby informacja o próbnym ataku nie rozeszła się pomiędzy pracownikami zbyt szybko). Oprócz tego determinujemy chociażby to, jak często użytkownicy, którym zostało przypisane szkolenie, mają dostawać powiadomienia o konieczności jego wykonania:
Ostatnim krokiem jest określenie kiedy dokładnie ma zostać wysłana kampania. Możemy zrobić to oczywiście od razu po jej skonfigurowaniu, ale możemy ją również opóźnić i wysłać we wskazanym dniu o określonej godzinie. Dodatkowo na dole możemy określić jak długo ma trwać cała symulacja (szczególnie istotne, o ile powiadomienia chcemy wysyłać dopiero po jej zakończeniu), a także dostosować czas wysyłania maili do stref czasowych, w których pracują nasi pracownicy:
Automatyzacja wysyłania symulacji
A co, o ile chcielibyśmy wysyłać próbne kampanie phishingowe cyklicznie? Możemy naturalnie przygotowywać je manualnie za każdym razem, gdy chcielibyśmy je wysłać, ale możemy też zrobić to automatycznie. Korzystając z Simulation Automations możemy skonfigurować cykliczne wysyłanie symulacji wskazując ich częstotliwość.
Jeżeli chcemy zachować większą nieprzewidywalność możemy również wskazać losowy czas wysyłania kampanii, zamiast dokładnie go określać. W tym przypadku również możemy określić pewne ograniczenia – dni tygodnia, w których może być wysyłana kampania, czy maksymalna liczba symulacji, która może być wysłana we wskazanym okresie jej trwania (max 10):
Oczywiście automatyczne, cykliczne czy losowe wysyłanie kolejnych symulacji nie miałoby sensu, o ile korzystali byśmy z dokładnie takiej samej wiadomości czy payloadu. Konfigurując symulację możemy wskazać interesujące nas payloady z danej techniki lub pozostawić mechanizmowi pełną swobodę wyboru. dzięki poniższych opcji możemy dodatkowo zadbać o jakość wysyłanych symulacji:
- Unique payloads – pozwoli zadbać o to, aby w trakcie trwania kampanii nie zostały wysłane dwa, takie same payloady
- Target all selected users in every simulation run – wskazuje mechanizmowi, iż wysyłając symulację zawsze musi uwzględniać wszystkich wskazanych użytkowników, a nie wyłącznie ich podgrupę.
- Target repeat offenders – opcja, którą aktualnie testuję, ponieważ nie znalazłem na jej temat wiele w dokumentacji. Zgodnie z moimi obserwacjami – pozwala na ponawianie symulacji na osobach, które dały się na nią złapać.
- Enable region aware delivery – możliwość wysyłania symulacji w czasie dostosowanym do strefy czasowej użytkowników
Symulator ataków w praktyce
Znając możliwości konfiguracyjne symulatora ataków czas zobaczyć, jak zachowuje się on w praktyce. Oczywiście w zależności od wybranego payloadu będzie to wyglądało zupełnie inaczej, ale spójrzmy na wybrany przykład w wysłanej przeze mnie symulacji.
Użytkownik otrzymuje, może nie najwyższych lotów, ale stosunkowo starannie przygotowanego maila, w tym przypadku z informacją, iż został mu udostępniony dokument za pośrednictwem Teams. To co przede wszystkim rzuca się w oczy (pomijając szatę graficzną) to dziwna, nienależąca do Microsoftu oraz organizacji domene widoczna zarówno w polu adresata, jak i po najechaniu na widoczny w mailu link.
Zakładając, iż użytkownik nie zauważa przesłanek świadczących o tym, iż dostał phishing, klikając w link trafia na ekran logowania wyglądający identycznie jak prawdziwy:
Jedynym wyjątkiem jest oczywiście zupełnie niezwiązana z usługami Microsoft domena, na którą może on zwrócić uwagę na tym etapie:
Po wprowadzeniu danych uwierzytelniających (swoją drogą, niekoniecznie prawdziwych, nie są one w żaden sposób weryfikowane) trafia na landing page informujący go o tym, iż został złapany na testowy atak. Landing page w tym przypadku wskazuje od razu na jakie elementy powinien zwrócić uwagę, aby nie dać złapać się w przyszłości – na przykładzie otrzymanej przed chwilą wiadomości:
Użytkownik otrzymuje również informację o tym, iż zostało do niego przypisane niezbędne do wykonania szkolenie. W załączeniu ma on od razu przygotowany bloker, który może w prosty sposób dodać do kalendarza, aby zarezerwować sobie czas na jego wykonanie:
Słowo końcowe
Ten sposób edukacji może się okazać niezwykle skutecznym elementem całego awareness-u prowadzonego w naszej firmie. Przetestowanie użytkowników od strony praktycznej może pomóc chociażby przekonać opornych, iż szkolenia bezpieczeństwa to nie tylko nudny obowiązek, ale niezbędny element bezpiecznego funkcjonowania organizacji i jego samego w cyfrowym świecie.
Wysyłane cyklicznie kampanie pozwalają skutecznie weryfikować wiedzę naszych pracowników na temat różnych typów phishingu i przygotowywać ich na sytuację, gdy w organizacji pojawi się ten prawdziwy. choćby o ile część użytkowników i tak da się złapać, to nawyk zgłaszania podejrzanych wiadomości do administratora/działu bezpieczeństwa pozwoli odpowiednio wcześnie zareagować i uniknąć bardziej poważnych skutków ataku.
