Mechanizm
Atakujący rzadko zostawiają tylko jedną furtkę.
Kiedy komuś uda się przejąć stronę, pierwszym krokiem po instalacji głównego narzędzia (webshella) jest zwykle wdrożenie zapasowego mechanizmu dostępu — na wypadek, gdyby ten pierwszy został znaleziony i usunięty. W jednym z prowadzonych przez nas przeglądów zapasowy zestaw narzędzi pojawił się na serwerze dosłownie kilkadziesiąt sekund po pierwszym włamaniu.
Jednorazowe „posprzątanie" — usunięcie znalezionego pliku, przywrócenie plików rdzenia WordPressa — bardzo często pomija właśnie ten zapasowy mechanizm. Efekt: strona wygląda na naprawioną, a atakujący wraca po kilku dniach dokładnie tą samą drogą, tyle że teraz już wie, że nikt nie monitoruje sytuacji.
Druga pułapka: przypadkowe wyłączenie zabezpieczeń przy naprawie.
Ręczna naprawa bez pełnego doświadczenia często wiąże się z przypadkowym wyłączeniem lub dezaktywacją wtyczki zabezpieczającej (WAF) — np. przy próbie identyfikacji, który komponent powoduje problem. Jeśli nikt tego nie zauważy, strona zostaje bez ochrony na czas nieokreślony.
Co naprawdę zamyka sprawę.
Skuteczna naprawa to nie usunięcie jednego pliku, lecz: przywrócenie z czystej, zweryfikowanej kopii zapasowej, wielokrotny pełny przegląd całego systemu plików, rotacja wszystkich danych dostępowych i weryfikacja, że zabezpieczenia (WAF, aktualizacje, uprawnienia) są aktywne i działają. Dokładnie ten proces opisujemy na stronie jak analizujemy włamania, a jego efekt — na przykładzie prawdziwego incydentu — w naszym case study.