Niebezpiecznik

Pod koniec każdego roku w prasie i w internecie pojawiają się raporty podsumowujące ostatnie 12 miesięcy w bezpieczeństwie. Zwracają one uwagę na trendy i zjawiska, które w kolejnym roku będą na topie. Większość ekspertów zgadza się, że w 2021 roku, jak w poprzednich latach, nie zabraknie phishingu. Spróbujmy więc przyjrzeć się temu atakowi bliżej, na przykładzie organizacji zajmującej się wypiekiem świątecznych ciast i jej pracownika, Roberta. 




Poszczególne etapy naszego przykładowego kill chaina ilustruje poniższa grafika:

To co zwraca uwagę, to fakt, że współczesny phishing nierzadko składa się etapów, a na każdym z nich możemy dostrzec artefakty pojawiające się w telemetrii lub w ramach alertów odpowiednich systemów.

Teza niniejszego artykułu jest następująca: rozpatrywanie informacji i alertów z każdego etapu jest o wiele skuteczniejsze przy wykorzystaniu systemu, który potrafi je gromadzić z tych wielu źródeł w jednym miejscu. I nie chodzi tutaj o rozwiązanie klasy SIEM, a o “orkiestratora”, w ramach którego rozwiązania chroniące organizację na poszczególnych etapach będą nie tylko przesyłać swoje informacje (właśnie tak, jak ma to miejsce w SIEM-ach), ale także korzystać ze wspólnego źródła Threat Intelligence. Będą także, co ważniejsze, wymieniać sygnały i działania. Jednym słowem: systemy klasy XDR (eXtended Detection & Response) to nie kolejny security buzz-word, a urzeczywistnienie faktycznej potrzeby związanej z holistycznym podejściem do organizacji. Bo przecież nie za bardzo jest sens rozpatrywać email z wiadomością phishingową od przejęcia poświadczeń użytkownika i realizacji technik persistence na urządzeniu, skoro, jak widać na grafice, to jeden i ten sam atak, którego celem może być zarówno przejęcie kontroli nad organizacją, jak i wykradzenie świątecznych przepisów z organizacji naszego użytkownika. Patrzenie na tego typu zdarzenia jako oddzielne i niezwiązane ze sobą może skutkować ich zlekceważeniem lub zduplikowaniem alertów, co w konsekwencji będzie skutkować tzw. alert fatigue. Bardzo często też do połączenia faktów, które na pierwszy rzut oka wydawały się niezależne od siebie dochodzi dopiero po skutecznym ataku.

Najważniejszy pierwszy krok

Pomimo znacznego wzrostu bardziej wyrafinowanych form phishingu jak smishing, to oczywiście poczta elektroniczna pozostaje najważniejszym i najczęściej wykorzystywanym wektorem. Biorąc pod uwagę nasz kill chain, wejście emaila z phishingiem do organizacji stanowi pierwszy i najważniejszy krok, na którym można zatrzymać atak. Najważniejszy – ponieważ dostarczenie takiej „przesyłki” do adresata będzie oznaczało, że każdy z pozostałych etapów będzie już ratowaniem sytuacji.

Wykrywanie i usuwanie emaili z wiadomością phishingową przed jej otrzymaniem (i otwarciem) przez użytkownika jest trudne; my musimy wyłapać wszystkie takie ataki, a atakującemu w teorii wystarczy tylko jedna udana próba. Proces komplikuje wyrafinowanie kampanii, kierowanych specjalnie do określonych osób (spear-phishing), które mają dostęp do wrażliwych informacji czy systemów oraz hostowanie stron wyłudzających informacje w zaufanych źródłach, takich jak Google Cloud czy Microsoft Azure, a nawet zatruwanie wyników wyszukiwania w popularnych wyszukiwarkach.
W jaki sposób nasz Robert mógłby nie otrzymać i nigdy nie zobaczyć złośliwego emaila?

Wydaje się, że o ile edukacja w zakresie bezpieczeństwa jest istotna, nie powinna stanowić być wyłącznym elementem ochrony z dwóch powodów. Po pierwsze jest to – nieco niesprawiedliwe – przerzucanie odpowiedzialności za bezpieczeństwo organizacji na pracownika – użytkownika końcowego. Wzmacnianie świadomości i inteligentne szkolenia w zakresie bezpieczeństwa są ważne, ale nie można wymagać, żeby to użytkownik brał na siebie całą odpowiedzialność. Po drugie, niezależnie od liczby szkoleń i kampanii informacyjnych, w każdej organizacji znajdzie się ktoś, kto kliknie – z nieuwagi czy przez to, że faktycznie dał się oszukać lub w szkoleniu jeszcze nie wziął udziału. Nie można winić użytkowników i zarzucać im, że nie sprawdzili każdego znaku w każdym linku, nie przejrzeli nagłówków, a w ogóle to po co otwierają jakiekolwiek emaile. W związku z tym jedynym logicznym wyjściem wydają się inteligentne systemy filtrujące pocztę pod kątem phishingu. Inteligentne – bo nie można już opierać się w takim działaniu jedynie na prostych słowach-kluczach czy czarnych listach.

Microsoft Defender


W całym 2019 roku Microsoft Defender for Office 365 zatrzymał ok. 13 miliardów szkodliwych emaili, z czego ponad 1,5 miliarda stanowiły emaile zawierające złośliwe URLe. Wg Microsoft 70% ataków phishingowych ma na celu wyłudzenie poświadczeń użytkownika – tak jak w przypadku Roberta. Tu przydatny będzie Microsoft Defender for Office 365 czy wbudowany w Windows 10 SmartScreen które analizują każde kliknięcie na link.

Microsoft Defender for Office 365 posiada także wbudowany mechanizm wewnętrznych testowych kampanii phishingowych, tzw. Attack Simulation Training. Dzięki kilku kliknięciom możemy wysłać grupie określonych użytkowników próbne emaile phishingowe, które wcześniej zmodyfikujemy tak, aby jak najbardziej pasowały do profilu naszej organizacji. Po zakończeniu testów otrzymamy raport pokazujący, ilu użytkowników otworzyło email, ilu kliknęło, jaka zmiana nastąpiła od poprzedniej kampanii testowej. A użytkownikowi, który kliknął na linka w emailu możemy automatycznie wyświetlić edukacyjne wideo o zagrożeniach związanych z phishingiem.

Podsumowując: jeśli możemy, nie dopuśćmy do pojawienia się emaila w skrzynce. Co z oczu to z serca. Jeśli zaś do tego już dojdzie, chrońmy użytkownika przy kliknięciu. Niestety, w przypadku naszego Roberta takich rozwiązań nie stosowano. Zobaczmy więc, co stało się dalej.

Jak się zalogować, żeby nie zwariować?

Robert nie wykrył phishingu a jego organizacja nie korzystała z rozwiazań, które mogłyby to zrobić za niego. Podał więc swoje dane na stronie phishingowej lub ściągął i uruchomił plik wykonywalny, który zautomatyzował atak i umożliwił przestępcy pozyskiwania poświadczeń z systemu operacyjnego.

Posiadając login i hasło użytkownika do systemu czy do aplikacji chmurowych atakujący nie potrzebuje nic więcej – ma dostęp do tych informacji, do których dostęp ma użytkownik oraz może rozpocząć poruszanie się po organizacji (lateral movement). Najprostszym sposobem zapobiegnięcia takiej sytuacji jest stosowanie uwierzytelnienia wieloskładnikowego (MFA – Multi-Factor Authentication). Wtedy kradzież hasłą użytkownika niczego nie da atakującemu.

MFA to tylko przykład możliwości, które można wdrożyć w celu ochrony tożsamości użytkownika. Niestety zarówno mnogość tzw. źródeł tożsamości w organizacji jak i brak wsparcia przez nie zaawansowanych funkcjonalności bezpieczeństwa sprawia, że bardzo często jedyną możliwością logowania dla użytkownika pozostaje login i hasło, także w przypadku Active Directory Domain Services.

Nowoczesne systemy-dostawcy tożsamości (IdP – Identity Provider) takie jak Azure Active Directory umożliwiają konsolidację tożsamości w jednym miejscu i wykorzystanie jej do logowania do wszystkich systemów, zarówno chmurowych jak i on-premise. Dla użytkownika będzie oznaczało to komfort pojedynczego logowania (Single Sign-On), a dla organizacji prostsze zarządzanie tożsamością, a przed wszystkim możliwość wdrożenia lepszej ochrony kont i tożsamości użytkowników. To nie tylko MFA, ale także Dostęp Warunkowy (Conditional Access), umożliwiający, blokujący lub ograniczający dostęp do aplikacji w zależności od warunków takich jak lokalizacja użytkownika, urządzenie, z którego korzysta i wiele innych charakterystyk.

Spróbujcie taki system zaimplementować w lokalnym AD. Także w wariancie passwordless, dzięki któremu użytkownik nawet nie musi znać swojego hasła i loguje się za pomocą klucza sprzętowego zgodnego ze standardem FIDO2 czy poprzez aplikację uwierzytelniającą na telefonie. Trudno użytkownikowi wykraść coś, czego on sam nie zna.

Dodatkowo takie IdP jak Azure AD posiadają inteligentny system monitorowania prób logowania użytkownika. Inteligentny – bo oparty o Threat Intelligence dostawcy, w tym przypadku Microsoft. Każde logowanie jest oceniane pod kątem kilku charakterystyk, np. czy nie następuje z adresu IP powiązanego w przeszłości z phishingiem. Skąd wiadomo, że adres IP jest podejrzany? Powinien o tym wiedzieć dostawca. Proces taki kończy się przyznaniem każdemu logowaniu poziomu ryzyka od 0 do 3, który następnie może być wykorzystany w Dostępie Warunkowym. Stosując powyższe rozwiązania w przypadku Roberta, nawet jeśli kliknąłby on na linka w emailu phishingowym, a następnie wprowadził swoje poświadczenia – atakujący nic by na tym nie zyskał. Niestety, Robert podzielił się z atakującym swoim hasłem i nie miał skonfigurowanego MFA. To prowadzi nas do kolejnej, ostatniej “deski ratunku”…

Lokalna ochrona…

Jeśli Robert nie ma uprawnień administracyjnych, wykorzystanie przez atakującego narzędzi hakerskich służących do poszukiwania możliwości eskalacji uprawnieńczy exploitów wykorzystujących podatności w jądrze systemu operacyjnego mogą zostać zauważone i zablokowane przez rozwiązania antywirusowe. Co jednak, jeśli atakujący będzie ostrożny i wykorzysta PowerShell do uruchomienia kodu w pamięci, bez potrzeby dotykania dysku lub skorzysta z wielu znanych plików wykonywalnych i bibliotek typu LOLBIN/LOLBAS?

Takie działania mogą nie tylko umożliwić mu uzyskanie trwałej obecności na urządzeniu Roberta (persistence), ale także dzięki nim może rozpocząć przemieszczać się poprzecznie w organizacji. Może Robert jest administratorem na innym urządzeniu? Może nie jest administratorem domeny, ale ma wrażliwą rolę, taką jak DNS Admin?

Tego typu rekonesans, ściąganie dodatkowego payloadu czy obchodzenie UAC zazwyczaj nie zostanie zauważone przez antywirusa. I nie dlatego, że ten na urządzeniu Roberta jest zły; przyczyną jest to, że klasyczny mechanizm AV został zaplanowany z myślą o innego typu zagrożeniach – o szkodliwym kodzie.

Robertowi i jego organizacji z pomocą może przyjść system klasy Endpoint Detection & Response (EDR). Będzie on rozpatrywał działania atakującego nie w kategoriach dobry/zły plik, a zwykłe/anomalne jego wykorzystanie.

Narzędzie certutil.exe z odpowiednimi przełącznikami ( -urlcache -split -f) może ściągnąć plik. Zazwyczaj CRL. To jest jego normalne działanie. Czy w ten sposób powinien być ściągany plik wykonywalny i uruchamiany na komputerze? Raczej nie i to z pewnością stanowi anomalię. Ten sam plik, ten sam użytkownik, to samo użycie – inny kontekst. To będzie kontrolował EDR, ale siła jego działania zależy od jakości dostarczanego przez dostawcę Threat Intelligence. W skrócie – czy dostawca rozwiązania pomyślał o tego typu technice i jest w stanie ją rozpoznać w napływającej telemetrii.

System klasy EDR Microsoft – Microsoft Defender for Endpoint (MDE) idzie dalej. Nie tylko jest w stanie wskazać tego typu działania na urządzeniu Roberta, ale także może je cofnąć przywracając poprzedni, prawidłowy stan urządzenia. Spływająca telemetria jest na tyle bogata, że MDE może cofnąć każde działanie atakującego: na przykład usunąć klucze rejestru, lokalnych użytkowników, odinstalować sterowniki czy zatrzymać proces i usunąć plik. I najlepsze: zrobi to całkowicie automatycznie, a sama usługa jest wbudowana w Windows 10.

Wracając do orkiestracji – w sytuacji, kiedy szkodliwe działanie będzie pochodzić np. z dokumentu zapisanego z emaila, chociażby poprzez wykorzystanie w tym celu złośliwego makro, MDE wyśle taką informację do Microsoft Defender for Office 365, aby usunąć retrospektywnie wszystkie takie emaile ze wszystkich skrzynek. W końcu nie ma sensu czekać, aż kolejny użytkownik otworzy emaila na kolejnym urządzeniu.

… i ochrona chmury

A co, jeśli atakującego nie interesuje urządzenie Roberata i po przejęciu poświadczeń nie ma zamiaru się w ogóle na nie logować, ponieważ jego cel stanowi co innego – dane w usługach chmurowych?

Organizacja zazwyczaj korzysta z kilkudziesięciu aplikacji chmurowych (a użytkownicy z jeszcze większej liczby – tzw. Shadow IT). Zachowanie spójności polityk dostępu do informacji, zapanowanie nad danymi poufnymi, DLP i ochrona informacji – to wszystko należy przemnożyć przez liczbę aplikacji. A jeśli użytkownicy przesyłają dane służbowe na prywatne konta emailowe (a przesyłają, przesyłają – bo tak wygodniej), nie będziemy w ogóle na tym w stanie zapanować.

Co, jeśli Robert ma roboczy dostęp do kilku aplikacji, na których znajdują się poufne pliku dotyczące nowego, nieopublikowanego jeszcze przepisu na makowiec? Tu pomóc może rozwiązanie klasy Cloud Access Security Broker (CASB).

Dzięki np. Microsoft CloudApp Security organizacja może w znaczny sposób zabezpieczyć się przed tego typu atakami. Po wykryciu anomalnego użycia aplikacji (np. logowania z miejsca, z którego użytkownik nigdy się nie logował, nagłego ściągania dużej ilości danych) w ruch idą polityki, które mogą ograniczyć lub odebrać dostęp użytkownikowi. Shadow IT można łatwo wyeliminować poprzez automatyczne wykrywanie użycia w organizacji nowej aplikacji chmurowej i jej blokowanie, jeśli nie spełnia ona postawionych przez nas wymagań.

Better together

Synergia to „współdziałanie różnych czynników, których efekt jest większy niż suma poszczególnych oddzielnych działań”. To właśnie ma miejsce przy wykorzystaniu różnych systemów, które potrafią się ze sobą komunikować nie tylko w zakresie wymiany informacji, ale także koordynowania działań, również tych automatycznych.

System klasy XDR, taki jak Microsoft 365 Defender ma za zadanie nie tylko zbierać informacje i korelować zdarzenia, ale także organizować działania pozostałych elementów ekosystemu bezpieczeństwa, a natywna integracja Microsoft 365 Defender z innymi systemami bezpieczeństwa w obrębie rozwiązań Microsoft 365 gwarantuje szybkość wdrożenia oraz łatwość użycia nawet najbardziej zaawansowanych funkcjonalności.

Rzućcie okiem, potestujcie. A jeśli macie pytania, zadajcie je w komentarzach. Poprosimy Pawła, aby na nie odpowiedział.