Krótko: Obce konta administratora znajdą Państwo tylko wtedy, gdy sprawdzą wszystkie poziomy: CMS lub sklep, panel hostingowy, użytkowników systemowych serwera, dostępy SSH i użytkowników bazy danych. Nie należy polegać na liście użytkowników w panelu administracyjnym, ponieważ wprowadzony kod może tam ukrywać konta. Znaleziska najpierw udokumentować i zablokować, potem wyjaśnić przyczynę, dopiero potem usunąć.
Dlaczego nieznany administrator jest tak niebezpieczny
Dodatkowe konto administratora to dla atakujących najwygodniejsza tylna furtka. Nie potrzebuje złośliwego kodu, nie rzuca się w oczy przy skanowaniu plików i przetrwa każdą aktualizację. Kto później loguje się tym kontem, w protokole wygląda jak zwykły redaktor.
Po PHP2Shell ta kontrola zyskuje na wadze. Luki CVE-2026-109618 i CVE-2026-109619 pozwalają na wykonanie złośliwego kodu bez logowania. Kto może wykonać kod na serwerze, może też zapisywać do bazy danych i tym samym zakładać konta. Aktualizacja PHP zamyka lukę, ale nie usuwa konta, które powstało wcześniej.
Dla PHP2Shell nie ma opublikowanych, potwierdzonych wskaźników kompromitacji (Indicators of Compromise), czyli listy typowych śladów. Nieznane konto nie jest więc dowodem PHP2Shell, lecz wyraźną wskazówką nieuprawnionego dostępu, niezależnie od drogi. Przegląd dalszych oznak znajdą Państwo w Czy już zostałem skompromitowany?.
Gdzie mogą tkwić obce konta administratora
Wielu operatorów zagląda tylko do CMS. Atakujący myślą poziomami, a każdy poziom ma własne konta:
| Poziom | Gdzie zajrzeć | Na co zwrócić uwagę |
|---|---|---|
| CMS lub sklep | zarządzanie użytkownikami i tabela użytkowników w bazie danych | rola administratora, data założenia, obcy adres e-mail |
| Panel hostingowy | użytkownicy, konta dodatkowe, konta FTP | konta, których nikt w zespole nie założył |
| Serwer Linux | /etc/passwd, grupy sudo lub wheel, sudoers |
dalsze konta z UID 0, nowe powłoki logowania |
| SSH | authorized_keys wszystkich użytkowników |
klucze bez znanego właściciela |
| Baza danych | tabela użytkowników serwera bazy danych | użytkownicy z uprawnieniami globalnymi lub hostem % |
| Usługi zewnętrzne | domena, DNS, Search Console, CDN | dodatkowi właściciele lub uprawnieni |
Poziom SSH jest na tyle samodzielny, że ma własny artykuł: Znajdowanie i usuwanie nieznanych kluczy SSH.
Znajdowanie obcych kont administratora w CMS, także ukrytych
Lista użytkowników w panelu administracyjnym jest generowana przez samą aplikację. Jeśli działa wprowadzony kod, może odfiltrować pojedyncze wpisy. Wiarygodniejsze są więc narzędzia, które patrzą bezpośrednio na zapisane dane. Dla WordPress WP-CLI wypisuje wszystkich administratorów z datą założenia:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Jeszcze poziom głębiej sięga zapytanie tylko do odczytu w bazie danych. Pokazuje każde konto, któremu przypisana jest rola administratora, niezależnie od tego, co wyświetla interfejs. Prefiks tabel wp_ proszę dostosować do swojej instalacji:
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
Proszę porównać wyniki z panelu administracyjnego, WP-CLI i bazy danych. Jeśli konto pojawia się tylko w bazie danych, jest to silny sygnał ostrzegawczy, ponieważ wtedy w grze jest dodatkowo kod, który je ukrywa. W innych systemach, takich jak Shopware, TYPO3 czy Joomla, obowiązuje ta sama zasada: odpytać bezpośrednio tabelę użytkowników i porównać z widokiem w panelu administracyjnym. Jakie to tabele, wynika z dokumentacji producenta.
Sprawdzanie użytkowników systemowych i użytkowników bazy danych
Na samym serwerze interesują przede wszystkim konta z uprawnieniami roota oraz konta, które mogą się logować. Poniższe polecenia tylko odczytują dane:
# Konta z UID 0 (normalnie tylko root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Konta z prawdziwą powłoką logowania
grep -vE '(nologin|false)$' /etc/passwd
# Członkowie grup administratorów
getent group sudo wheel
# Dodatkowe reguły sudo
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Ostatnie logowania z pełną datą
last -F | head -30
Na serwerze bazy danych proszę sprawdzić, którzy użytkownicy istnieją i jakie mają uprawnienia:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Aplikacja potrzebuje zwykle użytkownika z uprawnieniami do dokładnie jednej bazy danych. Dodatkowego użytkownika z uprawnieniami globalnymi, który może łączyć się z dowolnych hostów (%), należy wyjaśnić.
Nie wolno zapominać o kontach poza serwerem. Kto ma dostęp do umowy domeny lub zarządzania DNS, może przekierowywać odwiedzających albo kazać wystawiać certyfikaty na obce serwery. Dodatkowy właściciel w Google Search Console może zgłaszać mapy witryn i zmieniać ustawienia. Dlatego przy rejestratorze, dostawcy DNS, CDN i Search Console proszę przejrzeć listę uprawnionych i porównać ją z tym, co zna Państwa zespół.
Jak właściwie postąpić ze znaleziskiem
Pierwszym impulsem jest natychmiastowe usunięcie obcego konta. Znika jednak wtedy także ważny ślad: data założenia często zawęża, kiedy atakujący był w systemie. Lepsza jest ta kolejność:
- Udokumentować: Zapisać nazwę użytkownika, ID, e-mail, datę założenia, rolę i ostatnią aktywność z godziną, najlepiej jako zrzut ekranu i eksport.
- Zablokować zamiast usuwać: Odebrać rolę, zastąpić hasło losową wartością lub dezaktywować konto.
- Zawęzić okres: Sprawdzić logi wokół daty założenia. Jakie były żądania krótko wcześniej, jakie pliki się zmieniły?
- Sprawdzić dalsze poziomy: Kto zakłada konto, rzadko zostawia tylko jedno. Przejrzeć także pliki, zadania cron, klucze SSH i bazę danych.
- Oczyścić i odnowić dostępy: Dopiero po oczyszczeniu i aktualizacji PHP odnowić wszystkie hasła, klucze i sesje.
Uwaga dla ostrożności: nie każde nieznane konto jest złośliwe. Agencje, dawni usługodawcy lub wtyczki serwisowe zakładają czasem własne konta. Proszę to wyjaśnić, zanim wszczęty zostanie alarm, ale wyjaśnić niezwłocznie.
Zapobieganie powrotowi
Po oczyszczeniu konta administratora powinny być wyjątkiem, a nie regułą. Sprawdziły się konta osobiste zamiast dzielonych dostępów, jak najmniej administratorów i uwierzytelnianie dwuskładnikowe dla dostępów administratora. Proszę ponadto ustalić, kto może zakładać nowe konta administratora i gdzie jest to dokumentowane.
Regularne zapytanie, jak powyższe, na przykład co tydzień i z porównaniem do poprzedniego tygodnia, szybko uwidacznia nowe konta. W WordPress pomaga dodatkowo poradnik Znajdowanie backdoorów w WordPress.
Jak konkretnie pomaga PHP SOS?
- Sprawdzamy wszystkie poziomy kont, od CMS przez serwer po bazę danych, i porównujemy widok w panelu administracyjnym z zapisanymi danymi.
- Zabezpieczamy znaleziska ze znacznikami czasu, zanim konta zostaną zablokowane lub usunięte.
- W ramach Incident Response wyjaśniamy, jak konto powstało i czy istnieją dalsze tylne furtki.
- Odnawiamy dostępy we właściwej kolejności i konfigurujemy bieżącą kontrolę nowych kont administratora.
Częste pytania
Czy powinienem od razu usunąć nieznane konto administratora?
Lepiej nie od razu. Najpierw proszę udokumentować nazwę użytkownika, datę założenia, adres e-mail i ostatnią aktywność oraz zablokować konto. Usuwa się je dopiero po zabezpieczeniu śladów, ponieważ data założenia jest często ważną wskazówką co do momentu włamania.
Czy konto administratora może być niewidoczne w panelu administracyjnym?
Tak. Wprowadzony kod może ukryć pojedyncze konta na liście użytkowników w interfejsie. Bezpośrednie zapytanie do bazy danych lub narzędzie wiersza poleceń pokazuje natomiast wszystkie zapisane konta. Dlatego nie należy zaglądać tylko do panelu administracyjnego.
Jakie poziomy muszę sprawdzić poza CMS?
Panel hostingowy, dostępy FTP i SFTP, użytkowników systemowych serwera łącznie z uprawnieniami sudo, klucze SSH, użytkowników bazy danych oraz konta przy domenie, DNS i Search Console. Atakujący potrzebuje tylko jednych z tych drzwi, aby wrócić.
Czy po znalezisku wystarczy zmienić wszystkie hasła?
Nie. Obce konto pokazuje, że ktoś miał dostęp. Wtedy trzeba wyjaśnić także punkt wejścia, dalsze tylne furtki i możliwe wycieki danych. Hasła zmienia się dopiero po oczyszczeniu i z czystego urządzenia.