Накратко: Чужди админ акаунти намирате само ако проверите всички нива: CMS или магазина, хостинг панела, системните потребители на сървъра, SSH достъпите и потребителите на базата данни. Не разчитайте на списъка с потребители в бекенда, защото вмъкнат код може да скрие акаунти там. Находките първо документирайте и блокирайте, после изяснете причината, едва след това изтрийте.
Защо непознатият администратор е толкова опасен
Допълнителният админ акаунт е най-удобната задна вратичка за нападателите. Не се нуждае от злонамерен код, не прави впечатление при сканиране на файлове и преживява всяка актуализация. Който по-късно влезе с този акаунт, в протокола изглежда като обикновен редактор.
След PHP2Shell тази проверка придобива тежест. Уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват изпълнение на злонамерен код без влизане. Който може да изпълнява код на сървъра, може и да пише в базата данни и така да създава акаунти. Актуализацията на PHP затваря уязвимостта, но не премахва акаунт, възникнал преди това.
За PHP2Shell няма публикувани, потвърдени Indicators of Compromise, тоест няма списък с типични следи. Непознатият акаунт затова не е доказателство за PHP2Shell, но е ясно указание за неоторизиран достъп, независимо по кой път. Преглед на други признаци има в Компрометиран ли съм вече?.
Къде могат да се крият чужди админ акаунти
Много оператори поглеждат само в CMS. Нападателите мислят на нива и всяко ниво има собствени акаунти:
| Ниво | Къде да погледнете | На какво да обърнете внимание |
|---|---|---|
| CMS или магазин | Управление на потребителите и таблицата с потребители в базата данни | Роля администратор, дата на създаване, чужд имейл адрес |
| Хостинг панел | Потребители, допълнителни акаунти, FTP акаунти | Акаунти, които никой в екипа не е създавал |
| Linux сървър | /etc/passwd, групи sudo или wheel, sudoers |
Допълнителни акаунти с UID 0, нови login shell-ове |
| SSH | authorized_keys на всички потребители |
Ключове без известен собственик |
| База данни | Таблица с потребители на сървъра на базата данни | Потребители с глобални права или хост % |
| Външни услуги | Домейн, DNS, Search Console, CDN | допълнителни собственици или упълномощени лица |
SSH нивото е достатъчно самостоятелно за отделна статия: Намиране и премахване на непознати SSH ключове.
Намиране на чужди админ акаунти в CMS, и скритите
Списъкът с потребители в бекенда се създава от самото приложение. Ако работи вмъкнат код, той може да филтрира отделни записи. По-надеждни затова са инструменти, които гледат директно записаните данни. За WordPress WP-CLI изброява всички администратори с дата на създаване:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Едно ниво по-дълбоко стига заявка само за четене в базата данни. Тя показва всеки акаунт, към който е причислена ролята администратор, независимо от онова, което показва интерфейсът. Префикса на таблиците wp_ пригодете към Вашата инсталация:
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;
Сравнете резултатите от бекенда, от WP-CLI и от базата данни. Ако акаунт се появява само в базата данни, това е силен предупредителен сигнал, защото тогава е замесен допълнително код, който го крие. За други системи като Shopware, TYPO3 или Joomla важи същият принцип: заявете директно таблицата с потребители и я сравнете с показаното в бекенда. Кои са таблиците, стои в документацията на производителя.
Проверка на системните потребители и потребителите на базата данни
На самия сървър интересуват най-вече акаунтите с права на root и акаунтите, които могат да влизат. Следните команди само четат:
# Акаунти с UID 0 (обикновено само root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Акаунти с истински login shell
grep -vE '(nologin|false)$' /etc/passwd
# Членове на админ групите
getent group sudo wheel
# Допълнителни правила на sudo
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Последни влизания с пълна дата
last -F | head -30
На сървъра на базата данни проверявате какви потребители съществуват и какви права имат:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Приложението по правило се нуждае от потребител с права върху точно една база данни. Допълнителен потребител с глобални права, който може да достъпва от произволни хостове (%), трябва да се изясни.
Не забравяйте акаунтите извън сървъра. Който има достъп до договора за домейна или до управлението на DNS, може да пренасочва посетители или да издава сертификати на чужди сървъри. Допълнителен собственик в Google Search Console може да подава sitemap и да променя настройки. Затова при регистратора, DNS доставчика, CDN и Search Console преминете през списъка с упълномощените и го сравнете с онова, което екипът Ви познава.
Как да постъпите правилно с находка
Първият импулс е да изтриете веднага чуждия акаунт. С това обаче изчезва и важна следа: датата на създаване често ограничава кога нападателят е бил в системата. По-добър е следният ред:
- Документирайте: Запишете потребителско име, ID, имейл, дата на създаване, роля и последна активност с час, най-добре като снимка на екрана и експорт.
- Блокирайте вместо да изтривате: Отнемете ролята, заменете паролата със случайна стойност или деактивирайте акаунта.
- Ограничете периода: Проверете логовете около датата на създаване. Какви заявки е имало малко преди това, кои файлове са се променили?
- Проверете други нива: Който създава акаунт, рядко оставя само един. Прегледайте и файловете, cron задачите, SSH ключовете и базата данни.
- Почистете и подновете достъпите: Едва след почистване и актуализация на PHP подновете всички пароли, ключове и сесии.
Бележка за предпазливост: Не всеки непознат акаунт е злонамерен. Агенции, бивши доставчици на услуги или добавки за поддръжка понякога създават собствени акаунти. Изяснете това, преди да вдигнете тревога, но го изяснете своевременно.
Предотвратяване на повторение
След почистването админ акаунтите трябва да са изключение, не правило. Доказали са се личните акаунти вместо споделени достъпи, възможно най-малко администратори и двуфакторно влизане за админ достъпи. Определете освен това кой може да създава нови админ акаунти и къде това се документира.
Редовна заявка като горните, например седмично и със сравнение с предишната седмица, прави новите акаунти бързо видими. При WordPress допълнително помага ръководството Намиране на задни вратички в WordPress.
Как помага PHP SOS конкретно?
- Проверяваме всички нива на акаунти от CMS през сървъра до базата данни и сверяваме показаното в бекенда със записаните данни.
- Запазваме находките с времеви печати, преди акаунтите да бъдат блокирани или премахнати.
- В рамките на Incident Response изясняваме как е възникнал акаунтът и дали има други задни вратички.
- Подновяваме достъпите в правилния ред и настройваме текущ контрол на новите админ акаунти.
Често задавани въпроси
Трябва ли веднага да изтрия непознат админ акаунт?
По-добре не веднага. Документирайте първо потребителско име, дата на създаване, имейл адрес и последна активност и блокирайте акаунта. Изтрива се едва след като следите са запазени, защото датата на създаване често е важна индикация за момента на проникването.
Може ли админ акаунт да бъде невидим в бекенда?
Да. Вмъкнат код може да скрие отделни акаунти от списъка с потребители в интерфейса. Директна заявка към базата данни или инструмент от командния ред, напротив, показват всички записани акаунти. Затова не бива да гледате само в бекенда.
Кои нива трябва да проверя освен CMS?
Хостинг панел, FTP и SFTP достъпи, системни потребители на сървъра, включително права sudo, SSH ключове, потребители на базата данни, както и акаунти при домейн, DNS и Search Console. На нападателя му трябва само една от тези врати, за да се върне.
Стига ли да сменя всички пароли след находката?
Не. Чуждият акаунт показва, че някой е имал достъп. Тогава трябва да се изяснят и входната врата, другите задни вратички и възможните изтичания на данни. Паролите променяте едва след почистването и от чисто устройство.