# Find fremde admin-konti i CMS og server

> Find fremde admin-konti: Sådan kontrollerer I CMS, hostingpanel, Linux-server og database for ukendte adgange og håndterer fund rigtigt.

Kilde: https://phpsos.de/da/blog/fremde-admin-konten-finden/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Fremmede admin-konti finder I kun, hvis I kontrollerer alle niveauer: CMS eller shop, hostingpanelet, serverens systembrugere, SSH-adgangene og databasebrugerne. Stol ikke på brugerlisten i backend, for indsmuglet kode kan skjule konti dér. Dokumentér og spær fund først, afklar så årsagen, og slet først derefter.

## Hvorfor en ukendt administrator er så farlig

En ekstra admin-konto er den mest bekvemme bagdør for angribere. Den kræver ingen skadelig kode, falder ikke i øjnene ved filscanninger og overlever enhver opdatering. Den, der senere logger ind med denne konto, ser i protokollen ud som en normal redaktør.

Efter PHP2Shell får denne kontrol større vægt. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 tillader udførelse af skadelig kode uden login. Den, der kan udføre kode på serveren, kan også skrive i databasen og dermed oprette konti. En PHP-opdatering lukker sårbarheden, men fjerner ingen konto, der er opstået før.

For PHP2Shell findes der ingen offentliggjorte, bekræftede indicators of compromise, altså ingen liste over typiske spor. En ukendt konto er derfor intet PHP2Shell-bevis, men et klart fingerpeg om uautoriseret adgang, uanset ad hvilken vej. Et overblik over yderligere tegn står under [Er jeg allerede kompromitteret?](https://phpsos.de/da/php2shell/bin-ich-gehackt-anzeichen/).

## Hvor fremmede admin-konti kan sidde

Mange driftsansvarlige kigger kun i CMS. Angribere tænker i niveauer, og hvert niveau har egne konti:

| Niveau | Hvor I skal kigge | Hvad I skal være opmærksomme på |
|---|---|---|
| CMS eller shop | brugeradministration og databasetabellen med brugere | rollen administrator, oprettelsesdato, fremmed mailadresse |
| Hostingpanel | brugere, ekstrakonti, FTP-konti | konti, som ingen i teamet har oprettet |
| Linux-server | `/etc/passwd`, grupperne `sudo` eller `wheel`, sudoers | yderligere konti med UID 0, nye login-shells |
| SSH | `authorized_keys` for alle brugere | nøgler uden kendt ejer |
| Database | databaseserverens brugertabel | brugere med globale rettigheder eller host `%` |
| Eksterne tjenester | domæne, DNS, Search Console, CDN | ekstra ejere eller berettigede |

SSH-niveauet er selvstændigt nok til et eget indlæg: [Find og fjern ukendte SSH-nøgler](https://phpsos.de/da/blog/ssh-schluessel-pruefen/).

## Find fremmede admin-konti i CMS, også skjulte

Brugerlisten i backend genereres af applikationen selv. Kører indsmuglet kode med, kan den filtrere enkelte poster fra. Mere pålidelige er derfor værktøjer, der ser direkte på de gemte data. Til WordPress opregner WP-CLI alle administratorer med oprettelsesdato:

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

Et niveau dybere går en læsende forespørgsel i databasen. Den viser hver konto, som administratorrollen er tildelt, uanset hvad grænsefladen viser. Tabelpræfikset `wp_` tilpasser I til jeres installation:

```sql
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;
```

Sammenlign resultaterne fra backend, WP-CLI og databasen. Dukker en konto kun op i databasen, er det et stærkt advarselstegn, for så er der desuden kode i spil, som skjuler den. For andre systemer som Shopware, TYPO3 eller Joomla gælder samme princip: Forespørg brugertabellen direkte, og sammenlign med visningen i backend. Hvilke tabeller det er, står i producentens dokumentation.

## Kontrollér systembrugere og databasebrugere

På selve serveren er det især konti med root-rettigheder og konti, der kan logge ind, der har interesse. Følgende kommandoer læser kun:

```bash
# Konti med UID 0 (normalt kun root)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Konti med en ægte login-shell
grep -vE '(nologin|false)$' /etc/passwd

# Medlemmer af admin-grupperne
getent group sudo wheel

# Yderligere sudo-regler
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/

# Seneste logins med fuld dato
last -F | head -30
```

På databaseserveren kontrollerer I, hvilke brugere der findes, og hvilke rettigheder de har:

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

En applikation har som regel brug for en bruger med rettigheder til præcis én database. En ekstra bruger med globale rettigheder, som må få adgang fra vilkårlige hosts (`%`), bør afklares.

Glem ikke konti uden for serveren. Den, der har adgang til domæneaftalen eller DNS-administrationen, kan omdirigere besøgende eller lade certifikater udstede til fremmede servere. En ekstra ejer i Google Search Console kan indsende sitemaps og ændre indstillinger. Gennemgå derfor hos registrar, DNS-udbyder, CDN og Search Console listen over berettigede, og sammenlign den med det, jeres team kender.

## Sådan håndterer I et fund rigtigt

Den første impuls er at slette den fremmede konto straks. Dermed forsvinder dog også et vigtigt spor: Oprettelsesdatoen indkredser ofte, hvornår angriberen var i systemet. Bedre er denne rækkefølge:

1. **Dokumentér:** Notér brugernavn, ID, mail, oprettelsesdato, rolle og seneste aktivitet med klokkeslæt, helst som skærmbillede og eksport.
2. **Spær i stedet for at slette:** Fratag rollen, erstat adgangskoden med en tilfældig værdi, eller deaktivér kontoen.
3. **Indkreds tidsrummet:** Kontrollér logs omkring oprettelsesdatoen. Hvilke forespørgsler var der kort før, hvilke filer ændrede sig?
4. **Kontrollér yderligere niveauer:** Den, der opretter en konto, efterlader sjældent kun én. Gennemse også filer, cronjobs, SSH-nøgler og database.
5. **Ryd op og forny adgange:** Først efter oprydning og PHP-opdatering fornyes alle adgangskoder, nøgler og sessioner.

En bemærkning om forsigtighed: Ikke enhver ukendt konto er ondsindet. Bureauer, tidligere tjenesteydere eller vedligeholdelsesplugins opretter nogle gange egne konti. Afklar det, før I slår alarm, men afklar det hurtigt.

## Forhindr tilbagevenden

Efter oprydningen bør admin-konti være undtagelsen, ikke reglen. Personlige konti i stedet for delte adgange, så få administratorer som muligt og [tofaktorlogin til admin-adgange](https://phpsos.de/da/ratgeber/zwei-faktor-admin/) har vist sig at fungere. Fastlæg desuden, hvem der må oprette nye admin-konti, og hvor det dokumenteres.

En regelmæssig forespørgsel som de ovenstående, f.eks. ugentligt og med sammenligning med ugen før, gør nye konti hurtigt synlige. Ved WordPress hjælper desuden vejledningen [Find bagdøre i WordPress](https://phpsos.de/da/ratgeber/backdoor-wordpress-finden/).

## Hvordan hjælper PHP SOS konkret?

- Vi kontrollerer alle kontoniveauer fra CMS over server til database og afstemmer visningen i backend med de gemte data.
- Vi sikrer fund med tidsstempler, før konti spærres eller fjernes.
- Vi afklarer som led i [incident response](https://phpsos.de/da/leistungen/incident-response/), hvordan kontoen er opstået, og om der består yderligere bagdøre.
- Vi fornyer adgange i den rette rækkefølge og sætter en løbende kontrol af nye admin-konti op.


## Ofte stillede spørgsmål

**Skal jeg straks slette en ukendt admin-konto?**  
Helst ikke straks. Dokumentér først brugernavn, oprettelsesdato, mailadresse og seneste aktivitet, og spær kontoen. Slet først, når sporene er sikret, for oprettelsesdatoen er ofte et vigtigt fingerpeg om tidspunktet for indbruddet.

**Kan en admin-konto være usynlig i backend?**  
Ja. Indsmuglet kode kan skjule enkelte konti fra grænsefladens brugerliste. En direkte forespørgsel til databasen eller et kommandolinjeværktøj viser derimod alle gemte konti. Derfor bør I ikke kun kigge i backend.

**Hvilke niveauer skal jeg kontrollere ud over CMS?**  
Hostingpanel, FTP- og SFTP-adgange, serverens systembrugere inklusive sudo-rettigheder, SSH-nøgler, databasebrugere samt konti hos domæne, DNS og Search Console. En angriber behøver kun én af disse døre for at komme tilbage.

**Er det nok at ændre alle adgangskoder efter fundet?**  
Nej. En fremmed konto viser, at nogen har haft adgang. Så skal også indgangen, yderligere bagdøre og mulig dataudsivning afklares. Adgangskoder ændrer I først efter oprydningen og fra en ren enhed.

## Kilder

- [WordPress](https://wordpress.org/)
- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [BSI (det tyske forbundsagentur for informationssikkerhed): Henvisninger om it-sikkerhedshændelser](https://www.bsi.bund.de/)