2018-06-15

Lazarus C2 - miło Cię upolować

Threat Actor


Guardians of Peace, Hidden Cobra, NICKEL ACADEMY, ZINC, Lazarus, a może ... jeden z poniższych?

Unit 180

Unit 121
Silent Chollima
Stardust Chollima
Bluenoroff
Labyrinth Chollima
Ricochet Chollima
Andariel

Wymienione grupy realizujące ataki na instytucje finansowe oraz pokrewne, ale także na infrastrukturę krytyczną mają jedną cechę wspólną... współdzielenie narzędzi z jakich korzystają.

Robią tak od ponad 4 lat (!).

Kwestię atrybucji zaniedbujemy.


Motywacja


W żołnierskich słowach chcemy pokazać co może wynikać z analizy narzędzi używanych przez zaawansowanego Threat Actora by uzyskać zdolność do jego detekcji niezależnie od posiadania IOC typu: IP, domena, hash.



Założenia


Publicznie udostępniamy wyłącznie podsumowanie analizy. Wersja bardziej interaktywna oraz szczegółowa w zakresie detekcji FakeTLS dostępna jest podczas prezentacji, które prowadzi Bartek Jerzman - szukajcie Bartka w agendach konferencji lub w naszych social media.


Detekcja


Jeśli chcesz wykryć narzędzia wspomnianego Threat Actora, komunikujące się do serwerów C2, wykrywaj 1 lub więcej z wymienionych artefaktów podzielonych na dwie kategorie.


Low hanging-fruit



  • Certyfikaty self-signed
  • Certyfikaty “zaufane” (kopie oryginalnych certyfikatów), ale już nieważne (expired)
  • Negocjowany SSLv3 i nic innego
  • Certyfikaty o znanym fingerprintcie jako Lazarusowe

Try harder


  • Kilka prób negocjacji TLS z tym samym serwerem C2 - za każdym razem inny SNI i często inne Cipher Suites 
  • Sprawdzanie, czy IP serwera przynależy do adresacji wskazywanej przez SNI (reverseDNS, WHOIS)
  • Połączenia TLS nie poprzedzają zapytania DNS
  • SSL profiling - ustalenie profilu charakterystycznego dla narzędzi Lazarus

Na ten moment publicznie możemy udostępnić ten fragment naszej analizy.


Poniżej slajdy z premierowej edycji prezentacji Bartka na temat FakeTLS.


Detekcja cech dystynktywnych kanałów Dowodzenia i Kontroli (C2)


Po więcej, szczególnie w zakresie profilowania SSL dla mechanizmu FakeTLS, używanego przez część analizowanych narzędzi, zapraszam w imieniu Bartka oraz swoim na kolejne prezentacje White Cat Security.


Pytania?

2017-12-28

fit SIEM

Wprowadzenie


W przerwach w polowaniu na infrastrukturę niebezpiecznych grup jak Lazarus, tudzież analizy ruchu sieciowego wygenerowanego przez narzędzia typu RAT lub wiper, zastanawiamy się jak wyniki naszej pracy mogą zostać wykorzystane.

Prawdopodobnie spora część czytających ten artykuł dojdzie do wniosku, że do konsumpcji wskaźników kompromitacji (IOC), rozszerzonych o artefakty sieciowe, użyty zostanie lub powinien zostać użyty SIEM. Ewentualnie inny system bezpieczeństwa, który potrafi konsumować takie informacje.

Rozmawiamy z różnymi partnerami, klientami oraz osobami z naszej branży na temat sposobów wdrożenia oraz używania systemów typu SIEM. Poniżej kilka wybranych przykładów jak można "zabić" taki system oraz jak sprawić by znów chciało się do niego zaglądać.

Podczas wyborów lub wdrożeń systemów typu SIEM, dość często przechodzi się przez kilka jego faz.

Fazy wyboru i wdrożenia SIEM


Dla wyboru rozwiązania:

  • ekscytacji - "wszystko wrzucimy do SIEMa!"
  • zdziwienia - "jak to tyle kosztuje dla wszystkich zdarzeń?!"
  • racjonalizacji - "ok, potrzebujemy licencje na 50% wszystkich zdarzeń"
  • poddenerwowania - "wydaliśmy tyle pieniędzy, SIEM musi robić wszystko, trzeba udowodnić business case!"


Dla wdrożenia systemu:

  • ekscytacji - "wow, logujemy się do uruchomionego systemu! zobacz jakie raporty na zarząd będą i to z naszym logo!"
  • zdziwienia - "erm, szybciej wyszukiwałem zdarzeń grep'em, a to dopiero 10 źródeł podpiętych do SIEMa"
  • racjonalizacji - "ok, nieważne, trzeba dowieźć business case"
  • poddenerwowania - "dlaczego parsery nie rozpoznają tych zdarzeń poprawnie (wszystkie ich pola), przecież mają dedykowany parser!"



Brzmi znajomo?

Po przejściu przez te fazy, zazwyczaj mamy wyskalowany i wdrożony SIEM, który zasilany jest częścią zdarzeń docelowo istotnych, parsery rzadko radzą sobie z nowszymi wersjami zasilających je źródeł zdarzeń, nie mówiąc o sytuacji, w której źródła zdarzeń mają format i zawartość zdarzeń zgoła inny niż DOMYŚLNY.

Aby zmiękczyć skalę trudności obcowania z systemem typu SIEM po wdrożeniu i business case szybko został zrealizowany potrzeba sporo pracy kosztującej dużo wysiłku przed rozpoczęciem wdrożenia, na zdefiniowanie oczekiwań (tzw. mierzalne produkty), ale także przygotowanie możliwie dokładnych założeń związanych z tym, czym będziemy system SIEM "karmić".

Każdy może to zrobić sam lub np. z naszą pomocą (zapraszam na kontakt {@} whitecatsec {.} com) - pracujemy z różnymi systemami SIEM od 2008 roku.

Wg relacji osób, z którymi rozmawiamy taki nieco "otyły" i nie spełniający oczekiwań SIEM staje się czasem dowodem na to, że firma posiada SIEM i daje zgodność z np. rekomendacjami, regulacjami lub czymkolwiek innym mogącym dać "spokój".

Nie musi tak być. Jeśli chcesz by Twój SIEM był nieco bardziej fit, czytaj dalej.

Dane:


Żeby właściwie przygotować źródła zdarzeń zasilające SIEM trzeba je odpowiednio skonfigurować.
Odpowiednia konfiguracja w kontekście danych to wybranie właściwych kolumn/pól oraz ich format, które mają się znaleźć w zdarzeniu przesłanym do systemu SIEM.

Co to są te mityczne "właściwe kolumny/pola"?

Właściwe to te, które będą:

  • używane w SIEMie do wyszukiwania lub przetwarzania
  • używane przez osoby pracujące w SIEM do wyjaśniania zdarzeń (np. alarmów), takie które mogą nadać/dodać kontekst i ułatwić pracę analityka


Jeśli któreś z możliwych do osadzenia kolumn/pól w źródle zdarzeń spełnia powyższe wymagania, rekomenduję je włączyć i poprawnie parsować przez SIEM.

Czy trzeba to zrobić dla wszystkich źródeł zdarzeń podpiętych do SIEM?

Krótka odpowiedź: Nie.
Dłuższa: Najpierw zrób to dla najważniejszych dla Ciebie źródeł zdarzeń (o nich poniżej), a następnie lub równolegle zajmij się resztą. Dlaczego reszta może mieć znaczenie skoro nie są "najważniejsze"? Otóż mogą one stanowić dużą ilość lub wielkość zdarzeń przez co w przypadku komercyjnych systemów SIEM zjadają Ci:

  • licencję
  • łącza
  • wolną przestrzeń dyskową wpływając na retencję
  • wydajność źródeł oraz SIEM


a tym samym prawdopodobnie czas Twoich analityków, bo dłużej czekają na rezultaty pracy w SIEM.

Dlatego nie trzymaj "darmozjadów" (zbędnych kolumn w zdarzeniach) i odchudź swój SIEM.

Które źródła zdarzeń są prawdopodobnie najważniejsze? Wg nas te, które biorą udział w realizacji tzw. scenariuszy.

Scenariusze dzielimy na takie, które

wymagają reakcji człowieka:

  • alarmy (reguły korelacyjne, wyszukiwania zdarzeń, itp.)
  • raporty (zbiory zdarzeń z okresu czasu, agregacje, itp.)
  • dashboardy (te, z alarmami i raportami, które mogą zostać przeoczone jak wpadną np. na skrzynkę e-mailową, nie rekomendujemy tutaj dashboardów, które nie wymagają reakcji człowieka i stałej ich obserwacji)


nie wymagają reakcji

  • wzbogacające (nadające lub zwiększające kontekst dla alarmów i raportów)


Podsumowanie


Oto mamy cały łańcuch przyczynowo-skutkowy, jak poprawić kondycję narzędzia typu SIEM.

W dietetyce mówi się, że jeśli nowe ferrari zalejesz słabej jakości paliwem, nie dziw się, że "słabo" jeździ. To samo powiedzenie świetnie nadaje się do rozwiązań typu SIEM.

Na dietetyce też sie trochę znamy (potwierdzone certyfikatami!) natomiast w White Cat Security wspieramy klientów tworząc założenia przed wdrożeniem i po wdrożeniu, pomagając dojść do nich, w tym także budując procesy i procedury pracy ze SIEM, aby nie przerosły one możliwości ludzkich osób z nim pracujących.

W przypadku zainteresowania zapraszamy do kontaktu (kontakt {@} whitecatsec {.} com)

2017-12-11

IOC is dead: Lazarus, Autumn 2017

Czy wskaźniki kompromitacji to przeszłość?

Zaczniemy od tego co najpopularniejsze by w końcu pokazać najbardziej wartościowe informacje, które mogą nieść IOC (ang. Indicator of Compromise).

IOC powiązane z grupą Lazarus (upolowane przez White Cat Security)
Powyższy zrzut IOC (wersja tekstowa znajduje się tutaj) prawdopodobnie różni się od tego co można znaleźć w popularnych oraz płatnych żródłach IOC, dlatego śpieszę wytłumaczyć kolejne kolumny oraz jak czytać takie zestawienie.


  • Kill Chain Phase - jest to faza ataku, z którą powiązany jest dany IOC. Ma pozwolić określić stopień zaawansowania ataku, a tym samym może on zostać użyty do nadawania priorytetu alarmu wywołanego odnalezieniem IOC w organizacji. Faza Instalacji lub komunikacji z serwerami Command&Control powinna wzbudzić większe zainteresowanie niż np. faza Rekonesansu
  • Impact - wskazuje potencjał narzędzia skojarzonego z IOC, w tym przypadku jest to możliwość  m.in. wysyłania danych do serwera C2, wg przyjętej nomenklatury - Eksfiltracja
  • tool (hash: md5/sha1/sha256) - hash próbek, z którymi skojarzony jest dany IOC wraz z informacją o tym za pomocą którego algorytmu wyliczono hash. Preferujemy by był podany hash wyliczony z pomocą wszystkich trzech algorytmów, ponieważ w różnych systemach bezpieczeństwa mamy czasem różne możliwości aplikowania IOC. Zdarza się, że udostępniane na rynku IOC w postaci hashy plików, są wyliczane wyłącznie z pomocą algorytmy sha256 bez udostępniania próbki, co często ma wymiar wyłącznie PR'owy, gdyż stosunkowo mało narzędzi pozwala aplikować IOC w tej formie hasha. Nasza rekomendacja jest następująca: jeśli nie chcesz udostępniać próbki, udostępnij jej hash wyliczony za pomocą wszystkich trzech algorytmów. Ironia losu, natomiast w tym zestawieniu, całkiem realnym, nie możemy udostępnić skrótów tych próbek ani próbek - życie.
  • tool (type) - typ narzędzia powiązanego z IOC ma podpowiedzieć do czego służy. Z jednej strony można by pomyśleć, że już opis fazy ataku (Kill Chain Phase) oraz jego potencjalnego wpływu (Impact) to tłumaczy, natomiast z naszego doświadczenia, używanie sporo dłużej funkcjonującej nomenklatury pozwala uzupełnić opis i dać lepsze zrozumienie pojawienia się danego IOC w firmie
  • type (IP) - wskazuje do czego używany jest IP, w tym przypadku do C2 (Command&Control)
  • IOC type: IP - wskazuje na typ samego IOC (adres IP) oraz na wartość tego IP zarazem
  • date - wskazuje na dzień, w którym dany IOC występował w przyrodzie, w tym przypadku w adresacji IP dostępnej w sieci Internet

Czytając wiersz po wierszu możemy dojść do wniosków, że:

29 września 2017 roku, pod adresem IP 200.119.114.170, pojawił sie serwer służący do kontroli przejętego komputera z zainstalowanym oprogramowaniem typu backdoor, które pozwala na m.in. eksfiltrację (kradzież) danych

Co  możemy z tym zrobić dalej?

Przeszukać występowanie adresu IP 200.119.114.170 w zdarzeniach pozwalających wykryć komunikację z siecią Internet z dnia 29 września 2017 roku. Ewentualnie rozszerzyć okno czasowe o nie mniej niż 72h (3 dni) przed i po tej dacie - jest to dobra praktyka. Okres 1, w porywach do 7 dni, z którego trzeba przeszukać zdarzenia brzmią lepiej niż "zobacz za ostatni miesiąc albo... cokolwiek, nie wiem", kiedy nie wiemy w jakim okresie dany IOC miał znaczenie, prawda? 

Co jeśli nie mamy tak precyzyjnych danych?

Czas spróbować wzbogacić to co mamy do formy możliwie zbliżonej do tej, która został przedstawiona w tym artykule. Zamawiając lub wybierając dostawcę IOC, warto stawiać wymagania pozwalające efektywnie używać przekazywanych informacji. Wg White Cat Security najlepiej by "gołe" IOC w postaci np. adresów IP, były wzbogacone informacjami, które przedstawiliśmy w artykule. Mamy wtedy do czynienia już z wiedzą na temat zagrożenia, potrafimy ocenić jego krytyczność, a tym samym priorytet.

Korelacja

Korelacje czasowe pozwalają budować hipotezy, czasem pomagając zwiększyć ich prawdopodobieństwo. Poniżej obrazek, który podpowiada korelacje pomiędzy nim, a naszym przykładowym (choć realnym) zestawieniem IOC.

Źródło: http://baesystemsai.blogspot.co.uk/2017/10/taiwan-heist-lazarus-tools.html

Czy dostrzegasz korelację?

Podsumowanie

W tym artykule podsumowaliśmy jeden z przykładów jak efektywniej używać IOC oraz jakie informacje towarzyszące powinny zawierać źródła IOC. Są to przykłady nie wyczerpujące tematu. W White Cat Security nie jesteśmy największymi fanami IOC, natomiast jeśli ich używamy to z możliwie rozszerzonym kontekstem jak w tym artykule. O tym dlaczego preferujemy jeszcze inne podejście niż IOC można przeczytać w naszych innych artykułach (linki na samym dole).


Krótki oświadczenie

Arkusz kalkulacyjny (.xls) z IOC dotyczącymi kampanii grupy Lazarus/Bluenoroff, z przełomu roku 2016 i 2017, rozdawany za darmo przez White Cat Security każdej firmie, która się zgłosiła do nas, zawierał wyłącznie IOC zebrane ze źródeł typu OSINT. Jak tłumaczyłem podczas prezentacji w Katowicach (spotkanie ISACA Katowice), IOC w takiej formie są trudne do aplikowania, mogą zawierać błędy, czasem celowo prezentowane w danej postaci, nie są preferowane przez White Cat Security. Próba weryfikacji i rozszerzenia kontekstu zakończyła się sukcesem tylko w części przypadków. Oświadczenie to wydane jest w związku z nieprawdziwymi informacji powtarzanymi publicznie przez jednego z badaczy, który nigdy nie zapytał nas o zawartość ani kontekst przedmiotowych IOC. Nie powinien też mieć do nich dostępu gdyż on jak i jego pracodawca, nigdy się o nie do nas nie zwrócił. Wiemy, że grupa IP (o których wspomina badacz) oraz kilka domen (o których nie wspomina) jest błędnych w zestawieniu, natomiast nie ingerowaliśmy w to zestawienie by stanowiło ono lekcję o IOC - jak niskiej jakości krążą IOC w kontekście incydentu, który się wydarzył i dotknął m.in. sektor finansowy w Polsce.


Linki


2017-09-05

Podsumowanie 1H2017

  • Zaktualizowaliśmy opis flagowej usługi: Threat Intelligence. Odbiorcą usługi może być zarówno  firma/organizacja jak i centrum usług IT działające na rzecz większej ilości klientów.

  • Na twitterze (@whitecatsec) oraz LinkedIn (White Cat Security) powstały profile firmy, gdzie pojawiają się informacje częściej niż na blogu. Zapraszamy do obserwowania.

  • Na blogu pojawiać się będą wyłącznie dłuższe artykuły lub podsumowania. 

  • Wszystkie prezentacje użyte podczas prezentacji w Katowicach oraz Wrocławiu są już dostępne online. Lektura obowiązkowa dla ludzie zainteresowanych tematyką "threat intelligence".





2017-03-22

White Cat Security wspiera

White Cat Security już od 2 lat aktywnie podnosi poziom monitoringu, obsługi incydentów nie tylko przez komercyjną współpracę z firmami, ale również przez wspieranie organizatorów wydarzeń związanych z bezpieczeństwem. Przy okazji tych oraz innych kluczowych imprez w Polsce, jest możliwość spotkania się z przedstawicielami naszego zespołu by porozmawiać w kuluarach.

Spotkania nie zawsze mają charakter biznesowy, to miejsce i czas budowania relacji (Know Meet Trust) niezbędnych w procesie wymiany informacji o zagrożeniach, a wiemy relatywnie dużo agregując i analizując informacje pochodzące od zaufanych partnerów z różnych sektorów oraz własne działania.

Chronologicznie.

  • 30-31 marca 2017 - na konferencji SEMAFOR 2017 w Warszawie będzie można porozmawiać z nami w kuluarach - prośba o kontakt mailowy w przypadku chęci rozmowy lub nawiązanie kontaktu na miejscu, najlepiej przez kogoś kto ma już z nami relację. Działamy głównie w oparciu o zaufane kontakty.

 
(#KNF #stage2? - opowiem w Katowicach)
  • 12 kwietnia 2017 - na spotkaniu ISACA Katowice w Katowicach (video stream w Warszawie i prawdopodobnie Wrocławiu), założyciel brandu White Cat Security - Przemek Skowron, opowie o przypadku kampanii APT powiązanej z serwisem www Komisji Nadzoru Finansowego - pojawią się informacje dotychczas niedostępne publicznie. Więcej informacji oraz zapisy pod tym linkiem.
  • 27-28 kwietnia 2017 - na konferencji x33fcon w Gdyni, będzie można porozmawiać z nami. Gorąco zachęcamy do uczestnictwa w konferencji oraz w unikalnych na naszym kontynencie warsztatach - nie czekajcie na ostatni moment ryzykując, że część warsztatów zostanie odwołanych z powodu braku wykupionych wejściówek.
    • Jesteśmy sponsorem tego wydarzenia, o tyle nietypowym sponsorem, że budżet przekazany przez White Cat Security wykorzystany jest do sfinansowania kosztów sprowadzenia do Polski jednego z najbardziej potrzebnych prelegentów w naszym kraju - który obala mity i marketing, pokazując pragmatyczne, dojrzałe podejście (w naszej opinii).
    • Mieliśmy też wpływ na zapraszanych prelegentów - bez związku ze sponsoringiem. Dziękuję tym samym organizatorom za obdarzenie nas takim zaufaniem!
  • 18-19 maja 2017 - na konferencji CONFidence 2017 w Krakowie, będzie można porozmawiać z nami.

W razie zainteresowania kontaktem, standardowo: kontakt {@} whitecatsec.com lub bezpośrednio do znanego już konsultanta.

2017-02-14

KNF: studium przypadku - pytania

Ostatnie ataki na banki oraz inne instytucje z użyciem strony KNF spowodowały spore zamieszanie w wielu firmach.



Zespół Threat Intelligence White Cat Security pracuje nad raportem opisującym atak, jego fazy oraz jak poszukać w swojej sieci śladów po napastnikach - coś czego w sieci nie opublikowano - IOC oparte o IP/domeny/URLe to tylko początek.

Chcemy przyjąć perspektywę odbiorców raportu, dlatego proszę o kontakt (najlepiej bezpośredni) i przekazanie pytań dla których szukasz odpowiedzi by spać spokojnie(j).

Ty pytasz, my szukamy odpowiedzi.

PS
Raport zostanie udostępniony bezpłatnie dla wszystkich Partnerów, którzy włożą do naszego garnka informacje/próbki pozwalające wzbogacić opracowanie.

Dla pozostałych, studium przypadku zostanie udostępnione odpłatnie i może zostać indywidualnie wzbogacone.

2017-02-04

"Skuteczny" atak na KNF: co teraz?

W sprawie nowych (z przełomu 2016/2017) włamań do banków opisanych przez z3s chcę odnieść się wyłącznie do początku całej historii czyli stron KNF'u. Szkoda papieru - zapraszam do starego artykułu "Skuteczny" atak na bank: co teraz - rekomendacje są aktualne, wystarczy zastosować.

Jeśli napastnicy używają tych samych TTP (Technik, Taktyk, Procedur) i Narzędzi do ataku od lat, a są one nadal skuteczne w Twoim środowisku to przed Tobą jeszcze dużo pracy.

Pytanie brzmi: ile TTP/Narzędzi stosowanych przez Twoich wrogów jesteś w stanie wymienić jednym tchem?

Weź oddech i wymieniaj dalej - jeśli jest ich mniej niż 50 to bardzo długa droga przed Tobą.

A przed iloma z nich jesteś zabezpieczony, wykryjesz próbę ich użycia oraz zareagujesz na czas?

Aktualizacja [04.02.2017, 0:42] Podobny scenariusz miał miejsce m.in. w rok 2014 - slajdy (od slajdu 8), opis. Omawiałem go swego czasu na szkoleniach.