Hledání cizích účtů správců v CMS a na serveru

Stručně: Cizí účty správců najdete, jen když zkontrolujete všechny úrovně: CMS nebo e-shop, hostingový panel, systémové uživatele serveru, přístupy SSH a uživatele databáze. Nespoléhejte na seznam uživatelů v backendu, protože vložený kód tam může účty skrýt. Nálezy nejprve zdokumentujte a zablokujte, pak objasněte příčinu, teprve potom smažte.

Proč je neznámý administrátor tak nebezpečný

Přidaný účet správce je pro útočníky nejpohodlnějším zadními vrátky. Nepotřebuje žádný škodlivý kód, při skenech souborů neupoutá pozornost a přežije každou aktualizaci. Kdo se tímto účtem později přihlásí, vypadá v protokolu jako běžný redaktor.

Po PHP2Shell tato kontrola nabývá na významu. Zranitelnosti CVE-2026-109618 a CVE-2026-109619 umožňují spuštění škodlivého kódu bez přihlášení. Kdo může spouštět kód na serveru, může zapisovat i do databáze a zakládat tak účty. Aktualizace PHP zranitelnost uzavře, ale neodstraní účet, který vznikl dříve.

Pro PHP2Shell neexistují zveřejněné, potvrzené indikátory kompromitace (Indicators of Compromise), tedy žádný seznam typických stop. Neznámý účet proto není důkazem PHP2Shell, ale jasným náznakem neoprávněného přístupu, ať už jakoukoli cestou. Přehled dalších příznaků najdete v článku Jsem už kompromitován?.

Kde mohou cizí účty správců sedět

Mnoho provozovatelů se dívá jen do CMS. Útočníci myslí v úrovních a každá úroveň má vlastní účty:

Úroveň SSH je dost samostatná na vlastní článek: Hledání a odstranění neznámých klíčů SSH.

Cizí účty správců v CMS najít, i skryté

Seznam uživatelů v backendu vytváří sama aplikace. Běží-li s ní vložený kód, může jednotlivé záznamy odfiltrovat. Spolehlivější jsou proto nástroje, které se dívají přímo na uložená data. Pro WordPress vypíše WP-CLI všechny administrátory s datem založení:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Ještě o úroveň hlouběji jde čtecí dotaz v databázi. Ukáže každý účet, kterému je přiřazena role administrátora, bez ohledu na to, co zobrazuje rozhraní. Prefix tabulky wp_ přizpůsobte své instalaci:

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;

Porovnejte výsledky backendu, WP-CLI a databáze. Objeví-li se účet jen v databázi, je to silný varovný signál, protože je pak ve hře navíc kód, který jej skrývá. Pro jiné systémy jako Shopware, TYPO3 nebo Joomla platí stejný princip: dotázat se přímo tabulky uživatelů a porovnat se zobrazením v backendu. Které tabulky to jsou, stojí v dokumentaci výrobce.

Zkontrolovat systémové uživatele a uživatele databáze

Na samotném serveru zajímají především účty s právy root a účty, které se mohou přihlásit. Následující příkazy jen čtou:

# Účty s UID 0 (normálně jen root)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Účty se skutečným přihlašovacím shellem
grep -vE '(nologin|false)$' /etc/passwd

# Členové administrátorských skupin
getent group sudo wheel

# Dodatečná pravidla sudo
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/

# Poslední přihlášení s úplným datem
last -F | head -30

Na databázovém serveru zkontrolujte, jací uživatelé existují a jaká mají práva:

SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';

Aplikace zpravidla potřebuje jednoho uživatele s právy na právě jednu databázi. Dodatečný uživatel s globálními právy, který smí přistupovat z libovolných hostitelů (%), patří objasnit.

Nezapomeňte na účty mimo server. Kdo má přístup ke smlouvě o doméně nebo ke správě DNS, může přesměrovat návštěvníky nebo nechat vystavit certifikáty na cizí servery. Další vlastník v Google Search Console může odesílat sitemapy a měnit nastavení. U registrátora, poskytovatele DNS, CDN a Search Console proto projděte seznam oprávněných osob a porovnejte jej s tím, co zná váš tým.

Jak s nálezem správně naložit

První impuls je cizí účet okamžitě smazat. Tím zmizí i důležitá stopa: Datum založení často vymezuje, kdy byl útočník v systému. Lepší je toto pořadí:

1. Zdokumentovat: Uživatelské jméno, ID, e-mail, datum založení, roli a poslední aktivitu zaznamenat s časem, nejlépe jako snímek obrazovky a export.
2. Zablokovat, ne smazat: Odebrat roli, nahradit heslo náhodnou hodnotou nebo účet deaktivovat.
3. Vymezit období: Zkontrolovat logy kolem data založení. Jaké požadavky byly krátce předtím, které soubory se změnily?
4. Zkontrolovat další úrovně: Kdo účet založí, málokdy zanechá jen jeden. Prohlédněte také soubory, cron úlohy, klíče SSH a databázi.
5. Vyčistit a obnovit přístupy: Teprve po vyčištění a aktualizaci PHP obnovit všechna hesla, klíče a relace.

Upozornění na opatrnost: Ne každý neznámý účet je zlovolný. Agentury, dřívější dodavatelé nebo pluginy údržby někdy zakládají vlastní účty. Objasněte to dřív, než spustíte poplach, ale objasněte to včas.

Zabránit návratu

Po vyčištění by účty správců měly být výjimkou, ne pravidlem. Osvědčily se osobní účty místo sdílených přístupů, co nejméně administrátorů a dvoufázové přihlášení pro přístupy správců. Stanovte navíc, kdo smí zakládat nové účty správců a kde se to dokumentuje.

Pravidelný dotaz, jako jsou výše uvedené, například týdně a s porovnáním s minulým týdnem, činí nové účty rychle viditelnými. U WordPressu pomáhá navíc průvodce Hledání backdoorů ve WordPressu.

Jak konkrétně pomáhá PHP SOS?

• Kontrolujeme všechny úrovně účtů od CMS přes server až po databázi a porovnáváme zobrazení v backendu s uloženými daty.
• Nálezy zajišťujeme s časovými razítky dříve, než se účty zablokují nebo odstraní.
• V rámci Incident Response objasňujeme, jak účet vznikl a zda existují další zadní vrátka.
• Přístupy obnovujeme ve správném pořadí a zavádíme průběžnou kontrolu nových účtů správců.

Časté dotazy

Zdroje

• WordPress
• php.net: bezpečnostní oznámení
• BSI: pokyny k bezpečnostním incidentům IT