Kort sagt: Främmande adminkonton hittar ni bara om ni kontrollerar alla nivåer: CMS eller butik, hostingpanelen, serverns systemanvändare, SSH-åtkomsterna och databasanvändarna. Förlita er inte på användarlistan i backend, för insmugglad kod kan gömma konton där. Dokumentera och spärra fynd först, klargör sedan orsaken, radera först därefter.
Varför en okänd administratör är så farlig
Ett extra adminkonto är angriparnas bekvämaste bakdörr. Det behöver ingen skadlig kod, syns inte vid filskanningar och överlever varje uppdatering. Den som senare loggar in med det kontot ser i protokollet ut som en vanlig redaktör.
Efter PHP2Shell får den här kontrollen större tyngd. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 tillåter körning av skadlig kod utan inloggning. Den som kan köra kod på servern kan också skriva i databasen och därmed skapa konton. En PHP-uppdatering stänger sårbarheten, men tar inte bort något konto som har uppstått tidigare.
För PHP2Shell finns inga publicerade, bekräftade Indicators of Compromise, alltså ingen lista över typiska spår. Ett okänt konto är därför inget PHP2Shell-bevis, men ett tydligt tecken på obehörig åtkomst, oavsett på vilken väg. En översikt över fler tecken finns under Är jag redan komprometterad?.
Var främmande adminkonton kan finnas
Många driftansvariga tittar bara i CMS. Angripare tänker i nivåer, och varje nivå har egna konton:
| Nivå | Var ni tittar | Vad ni ska se upp med |
|---|---|---|
| CMS eller butik | användarhantering och databastabellen för användare | roll administratör, skapandedatum, främmande e-postadress |
| Hostingpanel | användare, extrakonton, FTP-konton | konton som ingen i teamet har skapat |
| Linux-server | /etc/passwd, grupperna sudo eller wheel, sudoers |
fler konton med UID 0, nya inloggningsskal |
| SSH | authorized_keys för alla användare |
nycklar utan känd ägare |
| Databas | databasserverns användartabell | användare med globala rättigheter eller värd % |
| Externa tjänster | domän, DNS, Search Console, CDN | ytterligare ägare eller behöriga |
SSH-nivån är fristående nog för ett eget inlägg: Hitta och ta bort okända SSH-nycklar.
Hitta främmande adminkonton i CMS, även dolda
Användarlistan i backend skapas av applikationen själv. Körs insmugglad kod med kan den filtrera bort enskilda poster. Mer tillförlitliga är därför verktyg som tittar direkt på de lagrade uppgifterna. För WordPress listar WP-CLI alla administratörer med skapandedatum:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Ännu en nivå djupare går en läsande förfrågan i databasen. Den visar varje konto som har tilldelats administratörsrollen, oberoende av vad gränssnittet visar. Tabellprefixet wp_ anpassar ni till er installation:
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;
Jämför resultaten från backend, WP-CLI och databasen. Dyker ett konto bara upp i databasen är det en stark varningssignal, eftersom det då dessutom finns kod med i spelet som döljer det. För andra system som Shopware, TYPO3 eller Joomla gäller samma princip: fråga användartabellen direkt och jämför med visningen i backend. Vilka tabeller det är står i tillverkarens dokumentation.
Kontrollera systemanvändare och databasanvändare
På själva servern är det framför allt konton med root-rättigheter och konton som kan logga in som är intressanta. Kommandona nedan läser bara:
# Konton med UID 0 (normalt bara root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Konton med ett riktigt inloggningsskal
grep -vE '(nologin|false)$' /etc/passwd
# Medlemmar i admingrupperna
getent group sudo wheel
# Ytterligare sudo-regler
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Senaste inloggningar med fullständigt datum
last -F | head -30
På databasservern kontrollerar ni vilka användare som finns och vilka rättigheter de har:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
En applikation behöver som regel en användare med rättigheter till exakt en databas. En extra användare med globala rättigheter som får ansluta från godtyckliga värdar (%) bör klarläggas.
Glöm inte konton utanför servern. Den som har åtkomst till domänavtalet eller DNS-förvaltningen kan omdirigera besökare eller låta utfärda certifikat åt främmande servrar. En extra ägare i Google Search Console kan skicka in sitemaps och ändra inställningar. Gå därför igenom listan över behöriga hos registrator, DNS-leverantör, CDN och Search Console och jämför den med det som ert team känner till.
Så hanterar ni ett fynd rätt
Den första impulsen är att radera det främmande kontot direkt. Då försvinner dock också ett viktigt spår: skapandedatumet avgränsar ofta när angriparen fanns i systemet. Bättre är den här ordningen:
- Dokumentera: Notera användarnamn, ID, e-post, skapandedatum, roll och senaste aktivitet med klockslag, helst som skärmbild och export.
- Spärra i stället för att radera: Dra in rollen, ersätt lösenordet med ett slumpvärde eller inaktivera kontot.
- Avgränsa tidsperioden: Kontrollera loggar kring skapandedatumet. Vilka förfrågningar fanns strax före, vilka filer ändrades?
- Kontrollera fler nivåer: Den som skapar ett konto lämnar sällan bara ett. Gå också igenom filer, cronjobb, SSH-nycklar och databas.
- Sanera och förnya åtkomster: Först efter sanering och PHP-uppdatering förnyar ni alla lösenord, nycklar och sessioner.
En försiktighetsnotering: inte varje okänt konto är illasinnat. Byråer, tidigare tjänsteleverantörer eller underhållsplugins skapar ibland egna konton. Klargör det innan ni slår larm, men klargör det snabbt.
Förhindra återkomst
Efter saneringen bör adminkonton vara undantaget, inte regeln. Personliga konton i stället för delade åtkomster, så få administratörer som möjligt och en tvåfaktorsinloggning för adminåtkomster har visat sig fungera. Bestäm dessutom vem som får skapa nya adminkonton och var det dokumenteras.
En regelbunden förfrågan som de ovan, till exempel varje vecka och med jämförelse mot veckan före, gör nya konton snabbt synliga. För WordPress hjälper dessutom guiden Hitta bakdörrar i WordPress.
Hur hjälper PHP SOS konkret?
- Vi kontrollerar alla kontonivåer från CMS över server till databas och stämmer av backend-visningen mot lagrade data.
- Vi säkrar fynd med tidsstämplar innan konton spärras eller tas bort.
- Vi klarlägger inom ramen för incidenthanteringen (Incident Response) hur kontot uppstod och om fler bakdörrar finns.
- Vi förnyar åtkomster i rätt ordning och sätter upp en löpande kontroll av nya adminkonton.
Vanliga frågor
Ska jag radera ett okänt adminkonto direkt?
Helst inte direkt. Dokumentera först användarnamn, skapandedatum, e-postadress och senaste aktivitet och spärra kontot. Radera först när spåren är säkrade, för skapandedatumet är ofta en viktig ledtråd om tidpunkten för intrånget.
Kan ett adminkonto vara osynligt i backend?
Ja. Insmugglad kod kan dölja enskilda konton ur gränssnittets användarlista. En direkt förfrågan mot databasen eller ett kommandoradsverktyg visar däremot alla lagrade konton. Titta därför inte bara i backend.
Vilka nivåer måste jag kontrollera utöver CMS?
Hostingpanel, FTP- och SFTP-åtkomster, serverns systemanvändare inklusive sudo-rättigheter, SSH-nycklar, databasanvändare samt konton hos domän, DNS och Search Console. En angripare behöver bara en av dessa dörrar för att komma tillbaka.
Räcker det att byta alla lösenord efter fyndet?
Nej. Ett främmande konto visar att någon hade åtkomst. Då måste också ingångsvägen, fler bakdörrar och möjliga dataläckor klarläggas. Lösenorden byter ni först efter saneringen och från en ren enhet.