usunięcie zagrożenia

Usunięcie zagrożenia to etap reagowania na incydenty, w którym ze środowiska trwale usuwa się składniki incydentu: złośliwe oprogramowanie, konta i mechanizmy, przez które napastnik utrzymuje dostęp, oraz wykorzystane podatności. NIST opisuje ten etap jako eliminowanie komponentów incydentu, na przykład usuwanie złośliwego oprogramowania i wyłączanie przejętych kont użytkowników, a także identyfikowanie i łagodzenie wszystkich wykorzystanych podatności ^[1]. Nowsza wersja wytycznych dodaje, że chodzi o usunięcie mechanizmów utrzymania dostępu i punktów wejścia ^[2]. Polska ustawa o krajowym systemie cyberbezpieczeństwa zalicza do zarządzania incydentem „usuwanie przyczyn ich wystąpienia” ^[3].

Miejsce w procesie

Wytyczne NIST SP 800-61 w wersji 2 z 2012 roku dzielą obsługę incydentu na przygotowanie, wykrywanie i analizę, powstrzymanie, usunięcie i przywrócenie oraz działania po incydencie ^[1]. Usunięcie zagrożenia następuje po opanowaniu incydentu, a przed przywróceniem działania. W kwietniu 2025 roku NIST zastąpił tę publikację wersją 3, która osadza reagowanie w strukturze CSF 2.0; usunięcie zagrożenia odpowiada tam wynikowi RS.MI-02 „Incidents are eradicated” ^[2].

RYS. 1Usunięcie zagrożenia w obsłudze incydentu

Granice między etapami nie są ostre. NIST zaznacza, że przy części incydentów usunięcie zagrożenia jest zbędne albo wykonuje się je w ramach przywracania ^[1]. Wersja 3 wytycznych dopuszcza częściową automatyzację. NIST sugeruje rozważenie takiej konfiguracji systemów operacyjnych, urządzeń sieciowych i narzędzi bezpieczeństwa, by część działań usuwających wykonywały samodzielnie, a także upoważnienie stron trzecich, na przykład dostawców internetu i usług chmurowych, do automatycznego usuwania niektórych typów incydentów ^[2]. Jednocześnie zaleca, by osoby obsługujące incydent mogły ręcznie wybrać i wykonać działania zamiast albo obok automatycznych ^[2].

Polska ustawa definiuje też szerszą obsługę incydentu jako czynności obejmujące wykrywanie, rejestrowanie, analizowanie, klasyfikowanie, priorytetyzację, podejmowanie działań naprawczych i ograniczenie skutków incydentu ^[3]. Usunięcie zagrożenia mieści się w działaniach naprawczych.

NIST zaleca też podejście etapowe: najpierw szybkie zmiany o dużej wartości, później zmiany długoterminowe, bo przy dużych incydentach odtwarzanie może trwać miesiącami ^[1].

Składniki

Usunięcie zagrożenia obejmuje trzy grupy działań. Pominięcie którejkolwiek z nich pozwala napastnikowi wrócić tą samą drogą.

Istotne jest ustalenie pełnego zasięgu. NIST zaleca zidentyfikowanie wszystkich hostów i usług objętych incydentem, tak aby naprawić wszystkie słabości ^[2]. Pominięty serwer albo zapomniane konto pozwala napastnikowi odtworzyć obecność po sprzątaniu. Pomaga w tym analiza wskaźników kompromitacji (IoC) z etapu wykrywania.

W WordPressie

Na stronie WordPress usunięcie zagrożenia to w praktyce czyszczenie przejętej strony. Typowym narzędziem utrzymania dostępu jest webshell: MITRE opisuje go jako skrypt umieszczony na publicznie dostępnym serwerze WWW, dający napastnikowi trwały dostęp i bramę do sieci ^[6]. CERT Polska zaleca zwrócić uwagę na pliki nieobecne wcześniej na serwerze, w szczególności umożliwiające zdalne wykonywanie kodu ^[5].

Pliki rdzenia. Dokumentacja WordPress.org zaleca ponowne wgranie katalogów /wp-admin i /wp-includes w tej samej wersji przez FTP albo SFTP, a nie przez opcję ponownej instalacji w panelu, bo instalator zwykle tylko nadpisuje istniejące pliki, a włamania często dodają nowe ^[4]. Wskazuje też pliki szczególnie często modyfikowane: .htaccess, index.php, header.php, footer.php i plik funkcji motywu ^[4]. Zmienione pliki rdzenia wykaże polecenie WP-CLI, które pobiera sumy kontrolne MD5 bieżącej wersji z WordPress.org i porównuje je z zainstalowanymi plikami ^[7].

wp core verify-checksums --include-root

Opcja --include-root sprawdza także katalog główny i ostrzega o plikach, które nie należą do WordPressa ^[7].

Konta i sesje. Dokumentacja zaleca wymuszenie zmiany haseł wszystkich użytkowników, zwłaszcza administratorów, i wymianę kluczy bezpieczeństwa i soli w wp-config.php, co wylogowuje wszystkie aktywne sesje ^[4]. Hasła trzeba zmienić dla wszystkich punktów dostępu: FTP i SFTP, panelu WordPress, panelu hostingu i bazy MySQL ^[4]. Należy też sprawdzić listę użytkowników pod kątem nieautoryzowanych kont administratora.

Punkt wejścia. Bywa nim nieaktualna wtyczka albo motyw, zob. podatność we wtyczce. Po oczyszczeniu dokumentacja zaleca aktualizację instalacji do najnowszej wersji, bo starsze wersje są bardziej podatne na włamania ^[4].

Najczęstsze błędy

• Usunięcie objawu zamiast przyczyny. Skasowanie spamu ze strony głównej nie usuwa tylnej furtki, przez którą spam trafił. Bez zamknięcia wektora wejścia infekcja wraca.
• Zmiana haseł tylko raz. WordPress.org przypomina, że hasła trzeba zmienić ponownie po upewnieniu się, że strona jest czysta ^[4]. Hasła zmienione na zainfekowanym serwerze mogły zostać przechwycone.
• Brak śladów do analizy. Przed czyszczeniem warto zabezpieczyć logi serwera HTTP i logi systemowe ^[5] oraz wykonać kopię zainfekowanego środowiska ^[4]. Bez nich informatyka śledcza nie ustali, jak napastnik wszedł.
• Przywrócenie kopii bez ustalenia czasu infekcji. CERT Polska dopuszcza odtworzenie z kopii zapasowej sprzed incydentu wtedy, gdy udało się jednoznacznie ustalić wektor i czas infekcji ^[5]. Kopia sprzed złego dnia może już zawierać webshell.

Po usunięciu

Usunięcie zagrożenia nie kończy obsługi. NIST zauważa, że zasób raz skutecznie zaatakowany często jest atakowany ponownie, dlatego odtwarzanie obejmuje zwykle wyższy poziom logowania i monitoringu sieci ^[1]. CERT Polska zaleca po przywróceniu strony dalsze monitorowanie logów serwera pod kątem żądań wskazujących na pliki webshell ^[5]. Wnioski z incydentu trafiają do post-incident review, a stałą kontrolę zmian w plikach zapewnia monitorowanie integralności plików.