atak hackerski

Jak nie reagować na atak hackerski – 10 często spotykanych błędów

Złośliwe oprogramowanie, atak hackerski, przejęcie systemu. Jak najczęściej informatycy reagują na tego typu zdarzenia? Pod wpływem stresu i presji czasu postępują intuicyjnie, co niestety w większości przypadków oznacza problemy. Poniżej przygotowałem listę dziesięciu często spotykanych zachowań w obliczu wystąpienia poważnego zagrożenia. Wszystkie one stanowią przykłady działań, które w większości przypadków są nie wskazane i mogą utrudnić prawidłową obsługę incydentu bezpieczeństwa:

  1. Odcięcie zasilania – ten krok wydaje się uzasadniony ponieważ pozwala na natychmiastowe zatrzymanie działań destrukcyjnych. Niestety w chwili wykrycia incydentu intruz najczęściej wyrządził już określone szkody i nagłe wyłączenie systemu spowoduje utratę cennych danych, których analiza mogłaby pomóc w jego identyfikacji. Również standardowe, bezpieczne wyłączenie systemu nie jest dużo lepszym rozwiązaniem.
  2. Logowanie się do systemu dotkniętego incydentem bezpieczeństwa. System przejęty przez intruza może być wykorzystany do działań przeciwko nam. Już samo zalogowanie się w nim może spowodować przejęcie danych uwierzytelniających.
  3. Pobieranie i instalowanie w systemie, którego dotyczy incydent narzędzi diagnostycznych lub śledczych w celu przeprowadzenia analizy. Może to spowodować nadpisanie danych na dysku i utrudnić analizę incydentu i poczynań intruza.
  4. Pobieranie na dysk systemu dotkniętego incydentem jakichkolwiek danych, zwłaszcza poufnych (np. procedur postępowania, instrukcji, dokumentacji środowiska IT lub haseł). Poza opisanym w punkcie poprzednim ryzykiem nadpisania cennych informacji na dysku zachodzi ryzyko przejęcia poufnych danych przez intruza.
  5. Podłączanie do analizowanego systemu nośników pamięci, na których mogą występować poufne dane. Administratorzy chcąc uniknąć pobierania narzędzi na dysk komputera mogą posługiwać się nośnikami zewnętrznymi. Częstym błędem jest jednak stosowanie nośników, na których zgromadzone zostały dane, które mogą zostać przejęte przez intruza.
  6. Mapowanie w systemie objętym incydentem zasobów sieciowych zawierających poufne dane, lub zasobów do których dany użytkownik ma prawa zapisu. Należy pamiętać, że w przypadku przejęcia systemu intruz będzie miał dostęp do mapowanych zasobów z uprawnieniami użytkownika prowadzącego obsługę incydentu.
  7. Usuwanie z dysku wszelkich śladów złośliwego oprogramowania. Pozbywając się zainfekowanych plików uniemożliwiamy jednocześnie ich analizę. Może to utrudnić identyfikację zagrożenia i określanie skali incydentu.
  8. Unicestwianie podejrzanych procesów systemowych bez uprzedniego ich analizowania. Procesy związane ze złośliwym oprogramowaniem mogą dostarczyć cennych informacji do analizy.
  9. Przywracanie stanu systemu bez uprzedniej analizy. Wykorzystanie punktow przywracania systemu Windows pozwala cofnąć system do stanu sprzed wystąpienia zagrożenia. Eliminuje jednak jednocześnie możliwość ustalenia w jaki sposób doszło do incydentu i jakie mogą być jego konsekwencje.
  10. Formatowanie dysku. Często podejmowanym działaniem wobec systemów zainfekowanych złośliwym oprogramowaniem jest formatowanie dysku i postawienie systeemu od zera. Podobnie jak w punkcie poprzednim pozbawiamy się w ten sposób możliwości przeanalizowania zagrożenia, w związku z czym może się ono pojawić ponownie.

Powyższa lista ma na celu uświadomienie, że reakcja na incydent bezpieczeństwa nie jest rzeczą łatwą. Należy się do niej dobrze przygotować i zaopatrzyć w odpowiednią wiedzę teoretyczną oraz procedury i narzędzia. Jeżeli chciałbyś się dowiedzieć więcej na ten temat polecamy Twojej uwadze cykl artykułów  poświęconych obsłudze incydentów. W pierwszym z nich opisujemy jak przygotować się do obsługi incydentu bezpieczeństwa.


Zostaw e-mail aby otrzymać powiadomienia o nowościach oraz dostęp do wszystkich bonusowych materiałów przygotowanych wyłącznie dla subskrybentów.

2 komentarze

  1. ekhm, albo ratujemy życie (firmę), albo zdrowie (nie utrudniamy sledztwa)… a tutaj ewidentnie idziemy na rękę śledczym, ale niekoniecznie uratujemy tak przedsiębiorstwo… trochę to nie tak…

    1. Tutaj niestety nie ma jednej złotej recepty. Każdy przypadek i każda firma są inne. Wymaga to jednak posiadania z góry ustalonych procedur lub wytycznych do analizy ryzyka, na podstawie których zostanie podjęta decyzja. Dla jednego priorytetem będzie minimalizacja czasu przestoju, dla innego wytropienie gdzie mogły powędrować dane. Działanie w pośpiechu i stresie niestety często kończy się pogłębieniem kryzysu. Trochę szerzej ten problem omówiony jest w cyklu artykułów poświęconych reakcji na incydent bezpieczeństwa: https://opensecurity.pl/obsluga-incydentu-bezpieczenstwa-przygotowanie-na-incydent/

Leave a Reply

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.