Po czym poznać, że WordPress został zhakowany?
Z tym najczęściej przychodzą do nas klienci.
Strona przekierowuje na obce strony, a w Google pojawiają się podstrony ze spamem.
W panelu są administratorzy, których nikt nie dodawał, albo konta klientów z uprawnieniami admina.
Na stronie płatności pojawił się dodatkowy formularz karty, a klienci zgłaszają kradzież danych.
Google albo przeglądarka ostrzega: „Ta witryna może być niebezpieczna”.
Biała strona, błąd 403 przy logowaniu do panelu albo dziwne wpisy w .htaccess.
Złośliwe pliki wracają kilka dni po usunięciu, mimo wtyczki bezpieczeństwa.
Strona zhakowana: co zrobić w pierwszych 60 minutach
Pięć kroków, które możesz zrobić sam, zanim zaczniemy. Każdy chroni dowody albo Twoich klientów.
Nie kasuj na ślepo
Zrób kopię plików i bazy w obecnym stanie, nawet zainfekowaną. To dowód i mapa infekcji.
Zmień hasła z czystego komputera
Panel, hosting, FTP/SFTP, baza danych, poczta. Włącz 2FA tam, gdzie się da.
Sprawdź listę administratorów
Zanotuj konta, których nie znasz. Nie usuwaj ich jeszcze, data utworzenia pomaga ustalić początek włamania.
Sklep? Wyłącz płatność kartą
Jeśli klienci zgłaszają podejrzane obciążenia, przełącz płatności na przekierowanie do bramki albo czasowo je wyłącz.
Zadzwoń do nas
Dalej przejmujemy: odcięcie atakującego, diagnoza, czyszczenie i utwardzenie.
Jak usuwamy malware z WordPressa
Pięć kroków. Ostatnie dwa sprawiają, że strona nie wraca do atakującego po tygodniu.
Odcięcie atakującego
Kończymy aktywne sesje, zmieniamy hasła i klucze, zabezpieczamy logi jako dowód.
Pełna diagnoza
Szukamy webshelli, ukrytych administratorów, złośliwego kodu w bazie danych, w wp-config, w cronie i w plikach udających wtyczki.
Czyszczenie
Podmieniamy rdzeń WordPressa na czysty z oficjalnego źródła, porównujemy pliki z oryginałem i usuwamy wszystkie elementy infekcji, także te, które same się odtwarzają.
Utwardzenie
Reguły WAF w Cloudflare, dodatkowa weryfikacja przy logowaniu, 2FA dla administratorów, blokada wgrywania wtyczek z panelu, dostęp do serwera tylko przez Cloudflare.
Monitoring
Codzienne sprawdzanie integralności plików z alertem e-mail. Zmianę widzimy w godziny, a nie po miesiącach.
Z czym realnie mamy do czynienia
Ostatnie włamania, które sprzątaliśmy
| Strona i sytuacja | Co znaleźliśmy |
|---|---|
| Sklep WooCommerce, skimmer typu Magecart podmieniał formularz karty | 7 ukrytych administratorów, sprzątanie ok. 15 min, sklep offline ok. 2 min |
| Sklep PrestaShop, skimmer ukryty w legalnym module i backdoor | backdoor działał ok. 16 miesięcy, porównane 4269 plików rdzenia |
| Serwer z 41 stronami WordPress | to samo ukryte konto admina na 11 stronach, luka w dodatku do motywu zablokowana |
| Sklep WooCommerce, loader w bazie udawał Google Tag Manager | polecenia pobierane z blockchaina, klasyczne skanery go nie widziały |
| Strona firmowa, backdoor podszyty pod wtyczkę Akismet | wykonywanie kodu bez logowania, dostęp przez ok. 9 miesięcy |
| Sklep, jedno włamanie | 27 webshelli, w tym pliki udające obrazki z kodem PHP |
| Strona, złośliwy plik wracał po każdym usunięciu | kod w wp-config odtwarzał go z kopii base64 zapisanej w bazie danych |
| Strona WordPress, fałszywa wtyczka, która sama się odnawiała | 11 kopii (mu-plugin, drop-iny, .user.ini) i 35 wpisów w bazie usunięte w jednym przejściu, potem monitoring co 10 minut |
| Strona firmowa wysyłała spam przez formularz kontaktowy | przyczyna w jednej linii motywu; 34 661 plików z prawem zapisu dla wszystkich poprawionych do 0 |
Zhakowany sklep PrestaShop
W PrestaShop złośliwy kod najczęściej siedzi w module: dopisany do legalnego modułu albo udający nowy. Dlatego porównujemy pliki rdzenia i modułów z oficjalnymi wydaniami tej samej wersji. W jednym sklepie porównaliśmy w ten sposób 4269 plików rdzenia i znaleźliśmy skimmer w module, który na co dzień działał poprawnie.
Drugą rzeczą jest porządek na serwerze. W audycie jednego sklepu w katalogu publicznym leżały klient bazy danych, phpinfo i 10 skryptów diagnostycznych, a logi urosły do 1,9 GB. Po sprzątaniu logi zajmują 20 KB, a narzędzia, które pomagają atakującemu, zniknęły z serwera.
Audyt bezpieczeństwa WordPressa i sklepu, zanim ktoś się włamie
Nie każdy przychodzi po włamaniu. W audycie sprawdzamy wersje wtyczek i motywu, nagłówki bezpieczeństwa, wystawione porty serwera, czy da się wylistować użytkowników przez REST API, czy działa xmlrpc, oraz skrypty na stronie płatności. Pliki porównujemy z oficjalnymi wydaniami WordPressa, WooCommerce albo PrestaShop. Wynik to lista poprawek od najpilniejszych.
Przykłady z naszych interwencji: 403 na wp-login i webshelle w wp-includes, koparka kinsing w kontenerze WordPress poradnik jak sprawdzić, czy checkout nie kradnie kart, dlaczego malware wraca po usunięciu i ukryci administratorzy z rolą klienta.
Wyciekły dane klientów? Pamiętaj o 72 godzinach
Jeśli atak dotknął danych osobowych albo płatności, administrator ma 72 godziny na zgłoszenie naruszenia do UODO. Przygotujemy techniczny opis incydentu: co się stało, od kiedy, jakie dane mogły wyciec i co zrobiliśmy.
Większość włamań, które sprzątamy, zaczyna się od nieaktualnej wtyczki albo słabego hasła. W ramach Pogotowia IT w abonamencie pilnujemy aktualizacji, kopii zapasowych i monitoringu na bieżąco. Prowadzisz sklep? Zobacz też opiekę nad sklepem WooCommerce. Pierwsze kroki po włamaniu opisujemy w poradniku wirus na stronie WordPress.
Najczęstsze pytania o zhakowany WordPress
Zgłoś włamanie. Odpowiadamy najszybciej, jak się da
Współpraca z ASAPDevs przebiegła bardzo profesjonalnie. Zespół był odpowiedzialny za przygotowanie naszej platformy do sprzedaży biletów i wywiązał się z zadania doskonale – wszystko zostało zrealizowane terminowo, zgodnie z ustaleniami.
Rekomenduję. Jestem zadowolona ze współpracy. Firma jest terminowa, rzetelnie wywiązuje się ze zobowiązań. Pełen profesjonalizm i rzadka cecha u informatyków – empatia, życzliwe i cierpliwe wsparcie.
Z bloga
Monitoring sklepu WooCommerce i PrestaShop: co sprawdzać poza uptime →
Strona główna odpowiadała 200 z cache, a koszyk zwracał 521. Co sprawdzamy w sklepach poza dostępnością, jak często i co te kontrole wyłapały.
Malware wraca po usunięciu? Fałszywa wtyczka, .user.ini i drop-iny w WordPressie →
Fałszywa wtyczka siedziała w 11 miejscach i 35 wierszach bazy. Usunięcie jednej kopii kończyło się odbudową z pozostałych. Gdzie szukać i dlaczego verify-checksums tego nie widzi.
Zhakowany WordPress: 403 na wp-login, 404 na podstronach i webshelle w wp-includes →
Przypadek z hostingu bez SSH: podmieniony .htaccess odciął właściciela od panelu, a kopie webshella siedziały w katalogach rdzenia WordPressa.