Firma miała EDR. Mimo to ransomware zaszyfrował całą sieć

„Co może wydarzyć się o 2 w nocy, gdy mamy EDR?”. Gdy od alertu bezpieczeństwa do pierwszej reakcji mija kilka godzin, nawet najlepszy EDR nie wyeliminuje zagrożenia. Technologie dają spokój, ale tylko pozorny. Zobacz, jak rozwijał się ransomware w firmie, która zainwestowała w renomowany EDR – i dlaczego narzędzia tym razem nie pomogły.

Z tego artykułu dowiesz się:

• Jak działa EDR w przypadku ataku ransomware.
• Dlaczego posiadanie EDR nie zawsze eliminuje problem zagrożeń.
• Jakie znaczenie mają procedury bezpieczeństwa, analiza alertów, ćwiczenia zespołu ds. bezpieczeństwa.
• Dlaczego warto stosować monitoring EDR 24/7

Co wydarzyło się w firmie po 2 w nocy?

„Mamy EDR – możemy spać spokojnie!”. W ten sposób zarząd zakomunikował sukces zespołowi. Wystarczyło kilka dni, by te słowa okazały się… nieprawdziwe. Co się stało? Firma miała EDR – to fakt. O godzinie 2:19 system wygenerował alert krytyczny. Mimo to nocny atak ransomware poczynił szkody w serwerach, środowisku produkcyjnym i stacjach roboczych. Administrator zauważył zagrożenie, ale dopiero… rano. Podejrzenia od razu padły na EDR. System był jednak niewinny.

Czy EDR zawiódł?

Nie. EDR, czyli Endpoint Detection and Response – zaawansowany system cyberbezpieczeństwa, monitorujący w czasie rzeczywistym urządzenia końcowe (laptopy, komputery stacjonarne, serwery), zadziałał prawidłowo. Jego zadanie nie polegało wyłącznie na wykryciu zagrożenia i wygenerowaniu alertu bezpieczeństwa. Cofnijmy się o kilka kroków i przyjrzyjmy temu, co działo się wcześniej. Bo EDR jest najbardziej widoczny w czasie incydentów, ale pracuje także w „czasie pokoju”.

System EDR zadziałał według tych kroków:

• Wszystkie urządzenia końcowe w firmie zostały podłączane do systemu. Od tego momentu EDR monitoruje ich pracę. Jest to monitoring bezpieczeństwa 24/7 – odbywa się również poza godzinami pracy firmy. System sprawdza i analizuje, jakie programy są uruchamiane, jakie pliki są zapisywane na urządzeniach, jakie połączenia sieciowe są nawiązywane. Zauważa również nietypowe zdarzenia: próbę przejęcia uprawnień czy uruchomienia podejrzanych skryptów.
• EDR zwracał uwagę na każde pojedyncze zdarzenia budzące wątpliwości, ale nie analizował ich osobno. Łączył je w całość – przyglądał się całemu ciągowi zdarzeń i wykrywał w nim nietypowe elementy. To przykład takiego ciągu: pracownik otwiera wiadomość e-mail → klika załącznik → pobrany dokument uruchamia makro → makro uruchamia PowerShell → PowerShell pobiera plik → plik próbuje wyłączyć zabezpieczenia → komputer zaczyna się komunikować z nieznanym serwerem. Przynajmniej część z tych zdarzeń wygląda niewinnie. Dopiero gdy spojrzy się na nie w kontekście całości, okazuje się, że są elementem scenariusza cyberataku.
• W ramach monitoringu bezpieczeństwa EDR zauważył zagrożenie i wygenerował alert. W alercie znalazły się informacje, jakiego urządzenia i użytkownika dotyczy podejrzany incydent, co dokładnie się zdarzyło, od czego się zaczęło.

Odpowiednio skonfigurowany EDR jest także w stanie zatrzymać cyberatak lub odizolować zainfekowany komputer. Dzięki temu zapobiega się dalszym, bardziej dezorganizującym pracę firmy szkodom.

Co robi EDR?

EDR działa w znacznie bardziej zaawansowany sposób niż typowy program antywirusowy na pojedynczym urządzeniu. Nie ogranicza się do sprawdzenia, czy pliki czy programy znajdują się na liście zagrożeń. Analizuje zachowania, które wyglądają na podejrzane. To może być próba pobrania pliku z internetu przez program Excel, próba wyłączenia zabezpieczeń przez zwykłego użytkownika czy masowe szyfrowanie plików. Szybkie wykrywanie takich zachowań i łączenie ich w całość pozwala wykryć również ataki w formie, jaka wcześniej nie miała miejsca.

Największą różnicą między EDR a programami antywirusowymi nie jest samo wykrywanie zagrożeń, ale sposób ich analizowania (analiza behawioralna) i możliwość natychmiastowej reakcji. EDR nie tylko wykrywa podejrzane zachowania, lecz także pokazuje cały przebieg ataku i umożliwia jego zatrzymanie.

Skoro EDR działa tak skutecznie i szybko, dlaczego nie udało mu się zatrzymać ataku ransomware na firmowe urządzenia i serwery? Przeanalizujmy dokładnie całą sytuację. Sprawdźmy, na jakim etapie doszło do błędu i czym był on spowodowany. Przyjrzymy się nie tylko samemu EDR – w tym procesie równie ważne jest to, jak działali ludzie i czy mieli do dyspozycji odpowiednie procedury.

Czy EDR wykrył ransomware?

Tak – i dzięki działaniu w trybie 24/7 zrobił to natychmiast. Polegało to przede wszystkim na analizie nietypowych zachowań: prób wyłączenia zabezpieczeń, masowego otwierania i zapisywania plików, uzyskania dostępu administratora. W ramach monitoringu EDR połączył te zachowania w całość i na tej podstawie stwierdził, że sytuacja jest krytyczna. Od razu „wiedział”, co robić. Wygenerował alert, który…

…i tu pojawia się problem. Sygnał o zagrożeniu trafił w próżnię. Brak procedur reagowania na alerty sprawił, że działania ze strony zespołu ds. bezpieczeństwa rozpoczęły się dopiero rano.

EDR wykrył atak ransomware na czas. Nie zapobiegło to jednak niekorzystnemu rozwojowi sytuacji. Atakujący stosunkowo swobodnie działał na firmowych urządzeniach i serwerach przez kilka godzin, uzyskując dostęp do kolejnych danych.

Dlaczego nikt nie zareagował na alert EDR?

Gdzie szukać odpowiedzi na pytanie: dlaczego EDR nie zatrzymał ransomware? Kto zawinił: technologia czy ludzie?

Zabrakło tu szybkiej reakcji (nie ze strony EDR – bo system zadziałał prawidłowo, ale pracowników), a przede wszystkim procedur. W firmie nie prowadzono monitoringu SOC 24/7. Z tego powodu administratorzy systemu nie mogli od razu dowiedzieć się o podejrzanej aktywności na urządzeniach końcowych i wygenerowanym przez EDR alercie. Gdy szkodliwy plik działań na serwerach, pracownicy… spali (to częsty przypadek, bo wiele ataków odbywa się nocą, właśnie ze względu na brak monitoringu 24/7 i słabszą ochronę o tej porze).

Natychmiastowa i właściwa reakcja według procedur, analiza alertów krok po kroku – tego EDR za administratorów systemów nie wykona. Dostarcza uporządkowanych, wiarygodnych i wartościowych danych do takiej analizy, ale to tylko podstawa do samodzielnego działania ludzi.

Chcesz realnie zwiększyć bezpieczeństwo informatyczne firmy i skrócić czas reakcji na incydenty? Nie skupiaj się wyłącznie na wdrażaniu technologii. Zadbaj także o to, by alerty trafiały do właściwych osób, w jak najkrótszym czasie.

Jak rozwijał się atak ransomware?

Od pierwszej próby ataku do wygenerowania alertu bezpieczeństwa przez EDR minęło kilka minut. Od alertu do faktycznego poinformowania administratora o zagrożeniu minęło… ponad 5 godzin.

Oto, jak rozwijał się atak ransomware na firmową infrastrukturę minuta po minucie:

• 2:13 – cyberprzestępca skanuje sieć w poszukiwaniu serwerów z podatnym oprogramowaniem i zdalnym dostępem.
• 2:15 – jeden z firmowych serwerów odpowiada na zapytanie. Atakujący wykorzystuje podatność i uzyskuje dostęp do serwera. To zdarzenie zostaje zarejestrowane przez EDR jako podejrzana, nietypowa aktywność.
• 2:16 – napastnik sprawdza, jakie serwery i dyski są dostępne, kto jest zalogowany w sieci, a kto ma uprawnienia administratora. EDR zauważa również te działania: widzi je jako serię działań, które rzadko wykonywane są na serwerach produkcyjnych.
• 2:18 – następuje próba wyłączenia zabezpieczeń, mechanizmów ochronnych, usług umożliwiających odzyskiwanie danych.
• 2:19 – na serwer zostaje pobrany plik ransomware. Następuje jego uruchomienie. EDR widzi to jako próby szybkiego otwarcia dużych ilości plików, masowe operacje zapisu, nietypowy wzorzec szyfrowania danych. Generuje alert krytyczny.
• 2:20 – EDR reaguje na zagrożenie. Nie jest jednak w pełni skonfigurowany, dlatego jego reakcja jest tylko częściowa. System blokuje niektóre działania, oznacza plik ransomware jako złośliwy, zapisuje ścieżkę ataku. Firma nie ma jednak całodobowego monitoringu SOC, więc alert trafia do kolejki zgłoszeń.
• 2:20-5:30 – ransomware działa dalej: szyfruje kolejne pliki, ogranicza pracownikom dostęp do danych. Wykonuje ruchy boczne (Lateral Movement), następuje eskalacja uprawnień – napastnik uzyskuje dostępy do kolejnych serwerów. EDR przez cały czas rejestruje te zdarzenia. I dopiero o…
• 7:30 administrator przychodzi do pracy. Loguje się do systemu i zauważa alert. Analizuje go i po kilkunastu minutach przystępuje do działań naprawczych.

Porównanie: EDR bez SOC i EDR z SOC

Można mieć jeden z najlepszych EDR na rynku, a jednocześnie nie mieć SOC działającego w trybie 24/7 – i zastanawiać się, dlaczego renomowane, polecane przez ekspertów rozwiązanie nie sprawdza się w firmie. Co zmienia SOC Przyjrzyjmy się, co działo się po ataku ransomware na system chroniony przez EDR w firmie, która nie miała SOC. I
przeanalizujmy, jak mogłoby to wyglądać, gdyby firma wdrożyła SOC. Kto zareagował, a kto mógłby zareagować? Jaka jest różnica w czasie reakcji? Jakie były skutki i jak można było ich uniknąć?

Jakie najczęstsze błędy organizacji są widoczne na tym przykładzie?

Organizacja skupiła się na wykrywaniu incydentów, a nie reagowaniu na nie. I to był jej podstawowy błąd, którego skutki odczuwała przez wiele godzin. Z wykrywaniem zagrożeń EDR poradził sobie świetnie – zdiagnozował podejrzane aktywności w systemie, wygenerował alert, a nawet do pewnego stopnia zablokował rozprzestrzenianie się ransomware. Zabrakło jednak dalszych działań w odpowiednio krótkim czasie.

Wdrożenie EDR od polecanego na rynku dostawcy dało organizacji złudny spokój. Osoby decyzyjne założyły, że takie narzędzie skutecznie rozwiąże problem ataków ransomware. Z tego powodu zaniedbano inne obszary. Zespół SOC nie był dostępny w trybie 24/7, nie miał procedur reagowania na incydenty w czasie rzeczywistym. Zabrakło także szybkiej analizy alertów – oceny, w jakim stopniu zdarzenie zagraża infrastrukturze IT i jakie działania należy podjąć.

To wszystko trzeba postrzegać raczej jako błędy w obszarze zarządzania, a nie doboru technologii. EDR działał prawidłowo, ale nie był w stanie wykonać całej pracy za ludzi.

Co zrobić, by historia z atakiem ransomware mimo EDR się nie powtórzyła?

Firma, której przypadek opisujemy, po ataku zrobiła dokładnie to, co należało. Nie skupiła się na szukaniu winnych i wyciąganiu konsekwencji wobec administratorów. Zajęła się tym, co można zrobić w przyszłości, by historia się nie powtórzyła. Wie już, że skuteczna reakcja zależy nie tylko od działania samego EDR, ale również od wypracowania procedur, stosowania i ćwiczenia ich w praktyce. Zarządzanie incydentami ma być procesem, w którym biorą udział i narzędzia, i ludzie.

Co ważne, wdrażane zmiany nie miały całkowicie wyeliminować ataków ransomware. To niemożliwe – pochodzące z zewnątrz zagrożenia pozostają poza kontrolą firmy. Znacznie skuteczniejsze jest inne podejście: skupienie na jak najszybszym wykrywaniu ataków ransomware i zapobieganie poważnym szkodom.

Wnioski

Jakie wnioski wyciągnęła organizacja z ataku ransomware wykrytego dopiero po kilku godzinach? Osoby odpowiedzialne za bezpieczeństwo zaproponowały wdrożenie kilku rozwiązań, a zarząd zgodził się na te zmiany. Obecnie firma jest lepiej chroniona przed cyberatakami dzięki:

• Wprowadzeniu monitoringu SOC 24/7 – dzięki temu można analizować alerty i reagować na nie w czasie rzeczywistym. Szybkość technologii łączy się w takim rozwiązaniu z doświadczeniem i decyzyjnością ludzi.
• Zaprojektowaniu i wdrożeniu procedur Incident Response – dzięki temu unika się chaosu i powolnego działania. W przypadku ataków ransomware, gdy zagrożenie rozprzestrzenia się błyskawicznie, pozwala to zaoszczędzić cenne minuty. Incident Response to szczegółowe informacje na temat kolejnych kroków działania, odpowiedzialności i ról pracowników, komunikacji wewnątrz organizacji.
• Opracowaniu playbooków – konkretnych scenariuszy działania w przypadku różnych zagrożeń bezpieczeństwa. Dzięki nim po wykryciu incydentu można od razu przejść do reakcji. Playbooki eliminują także sytuacje, gdy skuteczne działania zależą od doświadczenia jednej osoby. Wszyscy członkowie zespołu mogą działać w ten sam sposób.
• Prowadzeniu regularnych ćwiczeń z zakresu cyberbezpieczeństwa – dzięki nim można przećwiczyć procedury Incident Response i scenariusze z playbooków. Ćwiczenia pomagają zespołom ds. bezpieczeństwa działać szybciej w sytuacji realnego zagrożenia. Pozwalają także zweryfikować, czy proponowane działania są skuteczne, czy trzeba je zmodyfikować.

Co ważne, wszystkie rozwiązania z zakresu bezpieczeństwa wprowadzono równolegle. Monitoring SOC 24/7 sprawił, że alerty nie trafiają „w próżnię”, a procedury Incident Response, playbooki i ćwiczenia pozwalają działać szybko i skutecznie, gdy zagrożenie zostanie już wykryte. To wszystko skraca MTTR (Mean Time To Respond) – czas reakcji na incydent i przywrócenia normalnego działania systemu. Przeczytaj więcej o tym kluczowym wskaźniku: MTTD i MTTR — dlaczego czas wykrycia decyduje o skali incydentu.

Incydent na szeroką skalę budzi emocje. Warto jednak powtrzymać się od szukania winnych za wszelką cenę. To nie powstrzyma kolejnych ataków i nie ograniczy ich skutków. Zamiast zatrzymywać się w przeszłości, warto skupić się na przyszłości – i na tym, co pozostaje pod kontrolą firmy.

Jak łączymy technologie, procedury i zespoły w sprawnie działający system? Podejście VigilHorizon do cyberbezpieczeństwa w firmie

Nasze wsparcie dla firm nie ogranicza się do wdrożenia EDR. Wiemy, że to nie wystarcza – a opisywana historia jest tego przykładem. EDR jest dla nas narzędziem, ważnym, ale stanowiącym tylko część całego systemu zapewniającego firmie bezpieczeństwo informatyczne.

W naszym podejściu monitoring bezpieczeństwa zawsze idzie w parze z właściwą reakcją. Aby ta reakcja była szybka i skuteczna, potrzeba wypracowanych i przećwiczonych w praktyce procedur, a także odpowiedzialnego, zaangażowanego zespołu. Tylko w ten sposób można obsłużyć incydent od wykrycia do zamknięcia i przez cały czas mieć proces pod kontrolą.

Masz EDR, ale czy masz pewność, że zadziała?

Twoja firma jest na podobnym etapie rozwoju: EDR działa, a mimo to zdarzają się ataki ransomware i inne zagrożenia bezpieczeństwa, dezorganizujące działanie infrastruktury IT? Warto podejść do tego obszaru kompleksowo: zadbać o monitoring 24/7 i wdrożenie skutecznych procedur reakcji na incydenty, a Nasi specjaliści pomogą Ci osiągnąć ten cel!

Skontaktuj się z nami, a przeanalizujemy sytuację Twojej firmy i zaproponujemy najlepsze rozwiązania w ramach pakietu SOC.

Skontaktuj się z nami

Najczęściej zadawane pytania (FAQ)

Dowiedz się więcej

Czym jest SOC 24/7 i dlaczego jest wymagany przez NIS2?

SIEM w firmie — dlaczego samo wdrożenie nie zwiększa bezpieczeństwa

Jak wygląda realna obsługa incydentu? Incident Response krok po kroku

MTTD i MTTR — dlaczego czas wykrycia decyduje o skali incydentu?