Niech dane pozostaną z Tobą! Sieciowe techniki eksfiltracji danych

— Leszek Miś —

Moja prezentacja będzie generalnie pewnego rodzaju wstępem dotyczącym eksfiltracji. Jest to temat rzeka i tak naprawdę należałoby zrobić trzydniowe szkolenie z samego Data Exfiltration. My mamy 30 minut, także zrobimy sobie pewnego rodzaju przegląd przez techniki i elementy dotyczące detekcji tego typu działań w sieci, stąd też tytuł mojej prezentacji: „Niech dane pozostaną z Tobą!” lub też lepiej brzmiące po angielsku: „May the data stay with you”.

Krótko o mnie. Reprezentuję w tym momencie dwie firmy. Defensive Security to moja firma, w obrębie której dostarczam usług edukacyjnych z zakresu open source’owego defensive security, czyli np. podczas trzydniowego szkolenia, omawiamy tematy dotyczące Web security, Linux security i Network security i to tak naprawdę są moje trzy elementy na których się w tym momencie skupiam. Oprócz tego jestem szefem zespołu Security w Collective Sense, start-upie w którym zajmujemy się budową bardzo fajnego produktu w którym kolekcjonujemy dane, a później robimy analizy machine learningowe i deep learningowe. Oprócz tego w międzyczasie udało się zdobyć OSCP i uzyskać sporo Red Hatowych certyfikacji, także jestem mocno Linuxowy i sfokusowany na Security. Od dwóch lat również threat hunting jest też dość ciekawym elementem w mojej przygodzie z IT Security.

Mamy slajd dotyczący tego, że zagrożenia pojawiają się wszędzie. Nie wiem czy ktoś z Państwa jest już dzisiaj świadomy – wczoraj zostały udostępnione informacje na temat kolejnego krytycznego buga – Stack Clash. Polega to na tym, że praktycznie NetBSD, OpenBSD i wszystkie Linuxy, są podatne na lokalne eksploitacje. Wydawać by się mogło, że ze względu na fakt w obrębie którego znajduje się bug, tak naprawdę, możemy doczekać się też remote’owej eksploatacji. Także bardzo krytycznie. Zagrożenia kryją się wszędzie, eksploitujemy błędy w obszarze systemów operacyjnych, w obszarze serwisów, usług i aplikacji. Często ze względu na to, że nie zwracamy na to dość mocnej uwagi, mamy zwyczajnie niepoprawną konfigurację, która pozwala na nieautoryzowany dostęp do systemów, usług, aplikacji. Naturalnym jest, że nawet jeśli mamy rozwiązania bezpieczeństwa zaimplementowane w obrębie architektury, da się pewne elementy omijać. Da się omijać firewalle, istnieją oczywiście bypassy IDS-ów, IPS-ów, szczególnie dlatego że bazują one na sygnaturach, więc te sygnatury naturalnie jesteśmy w stanie omijać. Idąc dalej tym tropem, po eksploitacji następuje oczywiście proces tzw. „późnych skoków”* (lateral movement) i między innymi takim elementem tego typu procesu jest eksfiltracja danych i o tym tak naprawdę będziemy mówić podczas mojego wykładu.

Należy również zwrócić szczególną uwagę, że bardzo często (siłą rzeczy ciągle) widzimy niepoprawną architekturę sieciową, tzn. brak segmentacji jakiejkolwiek sieci, co też jest zdecydowanie pewnego rodzaju zagrożeniem, które ułatwia eksploitowanie czy też chodzenie po sieci już po uzyskaniu dostępu, np. poprzez client side buga, za pomocą cross-site scriptingowego ataku możemy dostać się bezpośrednio do wnętrza LAN-u i uzyskać dostęp np. do desktopa poprzez wadliwą apkę i XSS-a. Dobrym przykładem jest Framework który nazywa się BeEF – powinniście Państwo zdecydowanie znać tego typu narzędzie. Następnie mamy kieszenie pełne błędów i to jest coś o czym zapominamy, skupiamy się na warstwie serwerowej, skupiamy się na warstwie sieciowej w organizacji, natomiast później finalnie tak czy siak bierzemy tego laptopa firmowego – jeśli polityka na to pozwala, lub nie, to też bierzemy – i podpinamy tego laptopa do naszej sieci domowej. W tym momencie tak naprawdę taka sieć nie jest już zapewne tak zabezpieczona jak nasza firmowa i jest to też pewnego rodzaju ryzyko, które jest na pewno ważne. I do tego dochodzi socjotechnika. Tak naprawdę, jest to tylko z grubsza kilka punktów, które wymiksowane razem, dają naprawdę potężne możliwości atakującym.

Jak się przed tego typu atakami bronić? Odpowiedzią na tego typu pytanie, jest proaktywna analiza i ocena zagrożeń, czyli tzw. element który nazywamy threat huntingiem. Threat hunting powinien odpowiedzieć Państwu na pytania, które zostały wymienione na slajdzie, czyli: kto próbował uzyskać dostęp, w jaki sposób, kiedy, gdzie, na jakiej warstwie i z uwzględnieniem jakich cech charakterystycznych. Tak naprawdę możemy bawić się w taką analizę za pomocą wielu różnych narzędzi, korzystając również z wielu różnych warstw. Pierwsza taka podstawowa, która w zasadzie od dłuższego czasu jest stosunkowo popularna, to aktywna analiza logów oraz zdarzeń systemowych, czyli tak naprawdę próbujemy skupiać się na analizie tego co faktycznie dzieje się w obrębie naszych logów. Prostym przykładem będzie np. w dmesg, czyli w takim buforze kernela w systemie Linuxowym, informacje, tudzież adnotacje dotyczące segfaultów, czyli pewnego rodzaju problemów z zarządzaniem pamięcią dla danego procesu. Taki element będzie pewnego rodzaju triggerem do tego by wykonać dalszą analizę tego co w systemie się dzieje. Życzyłbym sobie żeby analiza logów była automatyczna, tzn. nie chciałbym dłubać w tych logach za każdym razem gdy zmieni się np. struktura custom loga dla Apache czy innej dowolnej usługi. Chciałbym żeby odbywało się to automatycznie, np. za pomocą patternów nad którymi akurat my w tym momencie pracujemy.

Inny element to behawioralna analiza zachowań użytkowników, czyli: użytkownik X loguje się przez ostatni miesiąc do stacji Y i zazwyczaj od godziny 8 rano i jego sesja trwa zazwyczaj do godziny 17. Nagle pojawia się pewnego rodzaju sesja o 3 w nocy w sobotę i tenże użytkownik próbuje uzyskać dostęp do wielu różnych innych systemów, np. za pomocą smbexeca czy pass-the-hasha taka sytuacja może mieć miejsce. To jest pewnego rodzaju odejście od normy. Sądzę, że powinniśmy wiedzieć i analizować aktywnie tego typu sytuacje. Jakiś czas temu autor Volatility – jest to pewnego rodzaju Framework do analizy pamięci RAM, który jest multiplatformowy ale głównie stosujemy go dla Linuxów – powiedział że „Jeśli nie wykonujecie okresowej analizy pamięci RAM waszych krytycznych systemów, to znaczy że threat hunting, tudzież active response, wykonujecie źle”. Zdaję sobie sprawę, że analiza RAM-u jest trudna, szczególnie gdy ma się setki lub tysiące systemów, natomiast zdecydowanie warto pamiętać że taką metodę również mamy i takie możliwości są dostępne. Tak naprawdę nie jest to jakiś rocket science, to są kolejne polecenia systemowe – istotna jest tutaj najbardziej architektura, czyli ten RAM należałoby zrzucać nie w obrębie badanej maszyny, tylko np. na zewnętrzny storage. Pamiętać z kolei należy, aby ten storage był totalnie odseparowany od reszty produkcyjnych danych.

Idąc tym tropem, kolejny bardzo istotny element oceny i analizy zagrożeń to wielopoziomowa analiza ruchu sieciowego. Mamy kilka możliwości. Żeby mieć pełny wgląd i pełny przegląd tego co się w sieci dzieje, należy pamiętać o takich źródłach danych. Te źródła danych, to różne warstwy oczywiście. Mamy Packet_Headery, które oczywiście powinny dążyć do tzw. Full_Packet_Capture, natomiast Full_Packet_Capture jest drogi w utrzymaniu. Zdajemy sobie z tego oczywiście sprawę, dlatego możemy np. analizować Packet_Headery. Możemy je łączyć z Netflowami, czyli kolejnym źródłem danych. Netflow, to pewnego rodzaju billing dla połączeń sieciowych. Nie mamy payloadu, tego co znajduje się w zawartości, ale wiemy kto, co, gdzie, kiedy, skąd, jak wyglądał rozmiar transmisji, jak wyglądał jej czas – pewnego rodzaju cechy charakterystyczne. Idealnie byłoby zasilać taką analizę ruchu sieciowego analizą pasywną DNS-ów. Jakby nie patrzeć, analiza DNS-ów wraz z analizą protokołu http, to jest coś, co powinniśmy mieć i z czego już dawno tak naprawdę powinniśmy korzystać i to jest pewnego rodzaju kolejne źródło danych. Pasywne TLS-y jak najbardziej, jeszcze przed tym finalnym handshakiem jesteśmy w stanie sprawdzić tak naprawę jakie common name’y znajdują się w certyfikatach, kto jest wystawcą, od kiedy dany certyfikat jest valid i kiedy wygasa. Tego typu rzeczy powinny być szczególnie istotne przy analizie, jeżeli macie wdrożony PKI własne, bo bardzo szybko da się uzyskać informacje na temat tego, jaka transmisja, tudzież jaka stacja wykorzystuje połączenia szyfrowane, które nie są podpisane przez wasze CA. Można to zrobić, dodając do tego sygnatury, security feedy i listy reputacyjne.

W naszym projekcie stosujemy również bardzo mocno i dość agresywnie protokół SNMP do aktywnego odpytywania serwerów o wykorzystanie IO procesora. Bardzo fajnie można to zmiksować właśnie z tymi elementami, które tutaj Państwo widzicie, do wykrywania tzw. ataków łańcuchowych (chains attacks), nad którymi w tym momencie pracujemy i się mocno skupiamy. Periodyczne skanowanie portów to superważna rzecz. Po pierwsze powinniśmy rozpoczynać to od analizy publicznych adresów IP, publicznej adresacji, ale również to co dzieje się wewnątrz sieci też jest istotne, bo dzięki temu szybko wykryjemy czy jakiś bind shell nasłuchuje na jakimś serwerze, a nie było go wczoraj. GEO IP oczywiście, analiza Whois_records to superważna sprawa, szczególnie pod kątem zmiksowania Packet_Headerów z Netflowami i z Passive_DNS-em gdzie możemy sprawdzić czy domena np. została zarejestrowana wczoraj lub przedwczoraj i jest stosunkowo świeża, a to jest pewnego rodzaju sygnał, który może świadczyć o tym, że ktoś próbuje w jakiś sposób albo nas sphisingować albo wykorzystać tego typu domenę do jakiś innych celów. Te źródła sygnałów możemy wrzucać do jednej konkretnej bazy i ta baza pozwala nam tak naprawdę wykonywać machine learning, czyli jakąś niskopoziomową analizę i korelację, zarówno zachowania jak i tych cech charakterystycznych, które się odbywają. Możemy oczywiście stosować Supervised Model albo Unsupervised Model (zarządzalny lub niezarządzany przez nas) i wykrywać anomalia, nie bazując na sygnaturach lub bazując na sygnaturach ale tylko jako jeden ,specyficzny, drobny sygnał, tudzież źródło sygnału. Ja to tak osobiście odczuwam. Czyli warto korzystać. Oczywiście mówi się że sygnatury są niepoprawne, to pamiętajmy że to ciągle jest źródło danych. Jeśli mamy powiedzmy 30sygnałów, to sygnaturka jako jeden z nich jest jak najbardziej wskazany i nie widzę powodów do tego by z tego nie korzystać. Natomiast nie należy oczywiście ufać stuprocentowo takiemu podejściu.

Przechodząc do esencji: eksfiltracja danych, czyli element procesu tzw. posteksploitacyjnego. Atakujący lubią tunelować ruch i robić to na różne sposoby. Robią to piwotując, forwardując ruch, dodając statyczne tablice routingów w obrębie zaatakowanej stacji czy to za pomocą Metasploita czy też meterpreterów – tego typu narzędzia o których z pewnością większość z Państwa słyszała. Atakujący lubią rootkitować i backdoorować systemy i usługi. Przykładem rootkitowania będzie np. dodatkowy moduł do Apache do jakiegoś serwera webowego albo aplikacyjnego, który requesty http, a przede wszystkim responsy http, modyfikuje w locie. To są tego typu rzeczy, które występują i powinniśmy o tym jak najbardziej pamiętać. Najpopularniejszymi metodami i protokołami w użyciu pod kątem eksfiltracji danych, są DNS-y, ICMP, TCP/UDP, a potem reszta. Najtrudniejsze do wykrycia są te bazujące na cloudowych rozwiązaniach, czyli Gmaile, Slacki, Twittery. Pokażę Państwu jeden z przykładów, który powinien zadziałać, a który będzie wykorzystywać właśnie cloudowe środowisko do tego by wyciągnąć i wysłać pewne dane z poziomu zainfekowanej stacji lub takiej którą atakujący przejął gdzieś na zewnątrz.

Jeśli chodzi o eksfiltrację danych DNS-owych, to chciałbym zwrócić uwagę na kilka istotnych elementów. Po pierwsze, powinniśmy mieć zdefiniowane wewnętrzne serwery DNS, które są w użyciu i tylko i wyłącznie te konkretne na whitelistach powinny obsługiwać naszych klientów, tudzież nasze stacje w obrębie sieci. Analizujmy więc czy tak się dzieje, sprawdźmy czy rzeczywiście nie ma czasem w obrębie naszej sieci serwera DNS, który jest w Chinach czy w dowolnym innym miejscu. Sprawdźmy czy któryś z naszych klientów nie wykorzystuje tego typu serwerów. Czy kojarzycie tę domenę? Z pewnością. Mamy union i exit, to są domeny z kolei typowo TOR-owe. Analizujmy pasywnie DNS-y pod kątem wykorzystania takich właśnie domen. I wspomniane rekordy Whois o których mówiłem. To jest jedna rzecz. Drugi element dotyczący DNS-a, dotyczy śledzenia zapytań pod kątem konkretnych rekordów o które klienci pytają. Czyli nie może być tak, że stacja desktopowa odpytuje o rekordy mx, no bo po co. Nie może być tak żeby stacja desktopowa – choć tu akurat bardziej jest to prawdopodobne, ale ciągle egzotyczne – odpytywała o rekordy txt. Sprawdźmy jak dużo zapytań o rekordy txt ma miejsce w obrębie waszej sieci. To są pewnego rodzaju kolejne odejścia od normy bazujące tylko na DNS-ach. Narzędzi mamy mnóstwo, oczywiście może to być implementacja customowa malware’a, ale my również możemy się pobawić tymi narzędziami, które znajdują się tutaj: Dnscat, Dns2tcp – fajne narzędzia które pozwalają szybko wykonać tunele DNS-owe.

Po lewej stronie mamy taką sytuację, że odpaliłem na serwerze znajdującym się gdzieś w Azji, Dnscata i teraz te polecenie, które znajduje się tutaj wraz z kluczem który będzie nam służyć do szyfrowania czy też do uwierzytelnienia tego połączenia. Spróbujemy odpalić w obrębie zaatakowanego hosta, czyli typowo malware’owego, tego typu polecenie gdzie IP zmienimy z XXX na 104.199.238.197. Na dole z kolei odpalimy Sniffera, takiego lokalneg. To oczywiście może być span port, natomiast my nie posiadamy tu span portów więc zrobimy to lokalnie na interfejsie. Nasłuchujemy pod kątem portu 53, czyli DNS-a i odpalamy sobie tego klienta. Zobaczcie co się dzieje – w tym momencie ta stacja kliencka wykorzystuje rekordy txt, w tym momencie CNAME i MX – oczywiście możemy to zrestrykcjonować – i ta stacja już zachowuje się dziwnie. To jest już nietypowe podejście, nietypowe zachowanie, nietypowa charakterystyka. Pytanie brzmi: czy rozwiązania DLP – rozwiązania które stosujecie, czyli IDS-y, IPS-y – w tym momencie wykryją tego typu alert u Państwa? Czy zostaniecie poinformowani o takim zdarzeniu czy nie?

Chciałem jeszcze pokazać shella, bo tak naprawdę w tym momencie wykorzystujemy DNS-a do tego żeby uzyskać dostęp do konsoli w obrębie tego serwera, ale możemy sobie to swobodnie zostawić. Poniżej, mam nadzieję że Państwo zauważyliście, mamy te rekordy MX i jest ich tu bardzo dużo. Należy dbać o to, należy analizować tego typu sytuacje.

Potem mamy kolejne fajne narzędzie, które nazywa się DET, ale o nim może za chwilę. Pamiętać również należy, że za pomocą zwykłego wbudowanego w system operacyjny polecenia takiego jak nslookup/dig, również jesteśmy w stanie za pomocą DNS-a wstrzykiwać takie requesty, żeby trafiały do naszego serwera DNS, którego jesteśmy właścicielem jako atakujący i też w logach tego serwera zobaczymy tak naprawdę dane, które potem możemy zgrupować, skonkatenować i uzyskać np. dostęp do pełnego pliku.

Inny typ danych, protokół ICMP, kojarzący się zazwyczaj z poleceniem „ping” (dla większości oczywiście), natomiast też pytanie: ilu z Państwa analizuje na bieżąco protokół ICMP, jego wykorzystanie, kto, skąd i w jakiej ilości danych korzysta z tego protokołu? Narzędzi jest mnóstwo i jednym z nich jest tutaj ICMP_exif, ale również można skorzystać właśnie ze wspomnianego wcześniej DET-a i to też spróbujemy sobie zobaczyć na żywo. DET to pewnego rodzaju toolkit do wykonywania eksfiltracji danych, bazując na różnych typach transmisji. Odpalamy i on w tym momencie nasłuchuje, tudzież powinien, natomiast z poziomu stacji zaatakowanej też sobie przejdziemy do DET-a. To polecenie wysyła np. plik bazy danych w eter korzystając z DNS-a. Proszę zauważyć jakie dziwne domeny są wykorzystywane. Pytanie brzmi: czy wasze systemy wykrywają bardzo długie domeny w użyciu? Bo to też jest nietypowe. Należy pamiętać, że Defense In depth polega na tym, że zwracamy uwagę na jak najmniejsze detale i skupiamy się na nich tak długo, aż zrozumiemy je perfekcyjnie. Dlatego należy zrozumieć perfekcyjnie DNS-a, ICMP itd. To sprawdźmy jak łatwo da się wykonać eksfiltrację danych bazując na ICMP. Wystarczy tutaj tak naprawdę zmienić „-p dns” na „icmp”, odpalamy ICMP. Nie będziemy się logować. Dlaczego to nie działa, dlatego że musi być Root żeby dostać się do raw socket ICMP, dlatego mamy persmission denied z poziomu DET-a, ale to jest nieważne, można sobie wyobrazić, że lata sobie tutaj dużo ICMP Echo Request i Echo Response, którymi wysyłamy dane bazując właśnie na ICMP.

Odnośnie TCP/UDP, należy sobie odpowiedzieć na pytanie: Dlaczego stacja X łączy się do publicznego adresu IP na „egzotycznym” porcie? Moje podejście jest takie, że chciałbym w sieci którą zarządzam (w miarę możliwości oczywiście), ograniczyć ruch wychodzący tylko i wyłącznie do portu 80 i 443. Tylko i wyłącznie. Jeśli któraś stacja próbuje dostać się do portów typu, 5, 4, 3, 2, 1 na UDP albo 1, 2, 3, 4, 5 na TCP, to znaczy że coś jest nie tak i jest to prawdopodobnie sygnał, że stacja jest zmalware’owana lub coś niepoprawnego się dzieje. To samo dotyczy podstawowego wykrywania TOR-a. Mamy oczywiście dostępne w sieci publiczne listy exit node’ów, możemy je sobie aktualizować na bieżąco i mieć aktualną informację dotyczącą tego która stacja w obrębie mojej sieci łączy się do TOR-a.

Http, kolejny bardzo istotny protokół, bardzo popularny z resztą i tutaj już nie jest tak łatwo dlatego że fajnie http, plaintekstowy, można zobaczyć wszystko co się w jego obrębie dzieje, natomiast malware jak i wszelkie serwisy wykorzystuje https-s. Jaka jest na to recepta? W zasadzie to tylko jedna – mieć PKI w obrębie swojej sieci i klaster forward SSL Proxy serwerów rozpinających SSL-a i wtedy dających możliwość dostępu do contentu, tudzież payloadu wysyłanego taką drogą. Dzięki temu zdobędziemy również informacje na temat specyficznych zapytań, payloadów wysyłanych w obrębie takiego połączenia, jakiś egzotycznych query, np. symptomów ataków typu open redirect czy innych takich, które ciągle się zdarzają i są dość często wykorzystywane np. przy atakach drive by download. Narzędzi jest mnóstwo, a jedno z ciekawszych to XSShell/XSStunell, czyli bazując np. na podatności XSS-a możemy eksfiltrować również dane. Dlatego jeśli ktoś z Państwa zapyta czy warto i powinno się analizować cookies, to odpowiedź brzmi tak, mimo iż jest to krytyczna wartość, bo tam znajdują się nasze sesje i sesje użytkowników, o tyle cookies również mogą zawierać dane krytyczne, mogą być wykorzystywane do przesyłania krytycznych danych jak i mogą być wykorzystywane do przesyłania złośliwego payloadu, takiego jak np. SQL injection w cookiesach w tego typu operacjach.

I mamy pozostałe eksfiltracyjne techniki bazujące na Powershellach, dlatego bardzo istotnym jest analizowanie logów i eventów powershellowych (bodajże Powershell od wersji 4.0 daje opcję takiego full audytyu). Mamy eksfiltrujące techniki bazujące na NAT-ach, korzystające z Meterpreterów, oczywiście SSH standardowo – Local port forwarding czy Remote port forwarding, bardzo specyficzne i wykorzystywane przez administratorów. Przykładem takim może być transmisja RDP przez SSH albo HTTP przez SMB (SMB – otoczenie sieciowe w Windowsach) i dowolne inne rzeczy takie jak HTTPS na jakimś wysokim, egzotycznym porcie, co też tak naprawdę nie powinno się wydarzyć w obrębie waszej sieci.

Jeśli chodzi o serwisy w cloudzie, to mamy Gmaila, Slacka, Twittera i tutaj też jest konkretny przykład gdzie możemy sobie ten plik database.dump wyeksfiltrować. W każdym razie ta eksfiltracja polega na tym, że ten plik który chcemy wyeksfiltrować, najpierw jest szyfrowany i przesyłany na rzeczywiste konto Gmailowe, które sobie utworzyłem, a później przesyłane z kolei z tego konta na stację atakującą, czyli tutaj po lewej stronie gdzie stacja atakującego się znajduje. Czyli tak naprawdę to jest nic innego jak „kopiuj i pobierz” z poziomu Gmaila dane, które są na koncie Gmailowym zaszyfrowane. Nie będziemy w stanie uzyskać bezpośrednio dostępu do danych, które są na tym koncie zapisane, dopiero przez takie narzędzie jak DET będziemy w stanie to zrobić.

Zdaję sobie sprawę, że jest to podsumowanie totalnie niekompletne, bo jest to temat rzeka, natomiast co jest istotne przede wszystkim, to żeby te elementy podłączyć do pewnego rodzaju metod aktywnej ochrony, czyli żeby systemy takie jak machine learning, który zrobi coś na danych, które macie, żeby wykonał reakcję na akcję. Czyli jak śpimy o trzeciej w nocy, to dla krytycznych systemów taki moduł wykonałby akcję dropowania na firewallach czy wylogowania wszystkich użytkowników z obrębu danego systemu. To jest tak naprawdę podejście z grsecurity. Jest taki fajny patch na kernel Linuxowy, gdzie jest moduł aktywnej ochrony, tzw. aktywnego responsa i polega to na tym, że jeśli kernel wykryje jakąś zabawę, powiedzmy z pamięcią kernela (mowa o jakiejś eksploitacji), to może wykonać akcję w postaci wylogowania wszystkich użytkowników z tego systemu albo w ogóle spanikowania takiego systemu. Myślę, że jak najbardziej tego typu moduły aktywnej ochrony, bazujące na deep learning, machine learning, są istotne. Oczywiście aktualizacja systemów i urządzeń. Lubię również monitorować domeny pod kątem takich elementów jak Typosquatting, Bitsquatting czy PunyCode o którym ostatnio było głośno. Jest sporo narzędzi, które tak naprawdę można podłączyć pod wasze SIEM-y, dla waszych SOC-ów które będą analizować domeny pod kątem np. domen łudząco podobnych, zarejestrowanych niedawno. To też jest bardzo cenne źródło informacji bo będziecie w stanie Państwo szybciej uzyskać informację na temat potencjalnych ataków phishingowych i będziecie ciut szybciej niż atakujący.

Co dalej z tymi danymi? My mamy kilka elementów. Oczywiście dane idą na sprzedaż. Pierwsza z lepszych odpowiedzi Google’a: jakieś bardzo cenione wydawać by się mogło forum policyjne, gdzie dostęp mają wyłącznie funkcjonariusze o określonej randze – 700 tysięcy rekordów użytkowników wypłynęło i jest na sprzedaż. Jakby nie patrzeć bardzo fajne, cenne dane. Dane oczywiście lądują do okupu i tutaj ransomware jest typowym przykładem, dla wywiadu, upublicznianie eksploitów o których też w ostatnim czasie jest dość głośno, a oprócz tego wystarczy wpisać „pastebin database dump” i zobaczycie Państwo, że z baz Insatgramowych, LinkedInowych, to wszystko jest dostępne. W jaki sposób musiało to wypłynąć? Testujmy, sprawdzajmy czy tego typu rzeczy, przykładowo Red Teamy wykonujące czy Blue Teamy w obrębie waszych infrastruktur i organizacji, czy będą w stanie wykryć. Czy rozwiązania które stosujecie będą w stanie wykryć tego typu sytuacje.