Aktuel situation: PHP2Shell. To kritiske PHP-sårbarheder (CVSS 9,2) tillader skadelig kode uden login. Rettelser siden 21.10.2026.Hvad der skal gøres nu →

Kryptominer på webserveren: Tegn og fremgangsmåde

Konstant fuld CPU, uden at der kommer flere besøgende: Det kan være en kryptominer. Sådan kontrollerer I belastningen, finder processen og dens genstartsmekanismer og går ordnet frem.

Status 5 min. læsetidOpdagelse og forensik

Kort sagt: En kryptominer på serveren viser sig som regel ved vedvarende høj CPU-belastning uden synlig grund, ved fremmede processer, ofte under webserverbrugeren, og ved udgående forbindelser til ukendte mål. Afslut ikke processen overilet: Sikr først spor, søg de mekanismer, der genstarter den, og luk indgangen. En miner betyder, at nogen kunne udføre kode på jeres server.

Når cloududbyderens regning er den første advarsel

Ofte opdages en kryptominer ikke ved en sikkerhedsalarm, men i forbifarten. Websitet bliver sløvt, hostingudbyderen melder en overskridelse af regnetiden, blæseren i det egne datacenter kører konstant, eller afregningen hos cloududbyderen stiger uden nye projekter. For angribere er en miner en enkel vej til at tjene penge på en kompromitteret server.

Mining betyder at bruge et fremmed systems regnekraft til at frembringe kryptovaluta. Skaden synes overskuelig, fordi ingen data krypteres. Det er misvisende: Den, der kan starte en miner, kan også læse adgangsdata, kopiere databaser og oprette yderligere bagdøre.

Efter PHP2Shell er kontrollen særligt umagen værd. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 tillader udførelse af skadelig kode uden login. Bekræftede indicators of compromise findes ikke, og en miner er intet specifikt tegn på disse sårbarheder. Høj belastning fra ukendte processer hører dog til de generelle tegn, der er beskrevet under Er jeg allerede kompromitteret?.

Tolk tegnene på en kryptominer korrekt

Høj belastning har mange harmløse årsager. Tabellen hjælper ved den første vurdering:

Observation Harmløs forklaring mulig Hvad I kontrollerer
CPU vedvarende nær fuld udnyttelse backup, billedbehandling, indeksopbygning Er belastningen jævn også om natten og i weekenden?
Proces med navn som en systemtjeneste sjældent Ligger programfilen i den forventede systemsti?
Proces under www-data, apache eller nginx, der ikke er PHP næppe Hvem har startet den, fra hvilken mappe?
Program i /tmp, /var/tmp eller /dev/shm næppe Siden hvornår findes filen, hvem ejer den?
Vedvarende udgående forbindelse til et ukendt mål overvågning, opdateringer Hører målet til en kendt tjeneste?
Belastningen falder, så snart I logger ind sjældent Nogle skadelige programmer holder pause, når overvågningsværktøjer kører

Jo flere linjer der passer, desto mere sandsynligt er et fund. At webserverbrugeren overhovedet starter fremmede programmer, er i sig selv et stærkt advarselstegn, som indlægget Webserveren starter en shell viser.

Sådan kontrollerer I processer og forbindelser

Følgende kommandoer læser kun. Notér resultat og klokkeslæt, før I ændrer noget som helst:

# Processer efter CPU-forbrug, med bruger, starttidspunkt og fuld kommando
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20

# Programfil og arbejdsmappe for en mistænkelig proces (indsæt PID)
sudo ls -l /proc/PID/exe /proc/PID/cwd

# Udgående forbindelser med proces
sudo ss -tnp state established

# Eksekverbare filer i midlertidige mapper
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null

Peger /proc/PID/exe på en fil med tilføjelsen (deleted), blev programmet slettet efter starten. Det er et typisk camouflageforsøg. Processen kører videre, og så længe den kører, kan programfilen stadig sikres via /proc. Det bør en, der kan omgås skadelig software, overtage; kør aldrig filen.

Hvordan I gennemgår processer systematisk ud over mineren, beskriver Find mistænkelige processer på Linux-servere.

Hvorfor mineren altid kommer tilbage

Mange driftsansvarlige afslutter processen, glæder sig over den faldende belastning og opdager næste dag, at alt begynder forfra. Minere installeres næsten altid med en genstartsmekanisme. Typiske steder er:

  1. Cronjobs for webserverbrugeren eller systemdækkende, som med få minutters mellemrum kontrollerer, om mineren kører, og ellers henter den igen.
  2. Systemtjenester med upåfaldende navne, som starter ved opstart.
  3. En webshell i webmappen, via hvilken angriberen når som helst genstarter mineren.
  4. Ændrede startscripts eller brugeres profilfiler.
  5. Fremmede SSH-nøgler, med hvilke angriberen straks logger ind igen.
# Cronjobs for webserverbrugeren og systemdækkende poster
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null

# Senest ændrede systemd-units
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls

Først når alle mekanismer er fundet, bliver serveren varigt rolig. Havde angriberen root-rettigheder, er en nyopbygning på et friskt system som regel mere pålidelig end søgningen efter hvert gemmested.

Den rette rækkefølge efter fundet

En miner virker som en teknisk gene, men er en sikkerhedshændelse. Gå derfor ordnet frem:

  • Sikr: Kopiér procesliste, forbindelser, mistænkelige filer og logs med kontrolsum, før noget afsluttes.
  • Inddæm: Isolér serveren, eller spær udgående forbindelser, hvis det er muligt uden datatab.
  • Luk årsagen: Bring PHP op på en rettet status (8.5.12, 8.4.27, 8.3.36, 8.2.35 eller bekræftet backport), genstart alle workers, opdatér CMS og udvidelser.
  • Ryd op eller byg på ny: Fjern mineren, genstartsmekanismer og bagdøre, sæt i tvivlstilfælde op på ny.
  • Kontrollér følgerne: Kunne adgangsdata eller personoplysninger læses? Så afklar databeskyttelse og eventuelt anmeldelsespligter.

Inddrag tidligt jeres hostingudbyder eller cloududbyder. Mange udbydere spærrer forebyggende servere med påfaldende belastning eller netværkstrafik. Den, der selv informerer udbyderen og afstemmer fremgangsmåden, beholder snarere kontrollen over tidspunktet for lukningen. Spørg i den forbindelse også efter udbyderens netværks- og adgangslogs, for de ligger uden for jeres server og er svære for en angriber at ændre.

For ledelsen er en kort, ærlig vurdering vigtig: Selve mineren koster først og fremmest regnetid og ydelse. Det egentlige spørgsmål lyder dog, hvad angriberen ellers har set. Indtil det er afklaret, bør hændelsen ikke regnes for afsluttet, selv om belastningen igen er normal.

Vigtigt

En kryptominer viser, at kode er blevet udført på jeres server. Behandl alle adgangsdata, der lå på serveren, som muligvis udsivede, og forny dem efter oprydningen.

Hvordan hjælper PHP SOS konkret?

  • Vi vurderer belastningen og skelner mellem harmløse årsager og fremmede processer.
  • Vi sikrer processer, filer og forbindelser, før mineren afsluttes.
  • Vi søger alle genstartsmekanismer og bagdøre og renser serveren som led i malwarefjernelsen eller bygger den op på ny.
  • Vi lukker indgangen, fornyer adgange og sætter en belastningsovervågning op, der tidligt melder usædvanlige mønstre.

Ofte stillede spørgsmål

Hvordan genkender jeg en kryptominer på min server?

Typisk er en vedvarende høj CPU-belastning, der ikke passer til besøgstal eller planlagte opgaver. Dertil kommer processer med ukendte eller harmløst klingende navne, ofte under webserverbrugeren, og udgående forbindelser til fremmede adresser. Et enkelt kendetegn er endnu intet bevis.

Er det nok at afslutte mining-processen?

Nej. Minere startes som regel igen og igen via cronjobs, systemtjenester eller en webshell. Den, der kun afslutter processen, ser den ofte igen kort tid efter. Desuden forbliver den indgang åben, som mineren kom ind på serveren gennem.

Er en kryptominer harmløs, fordi den kun stjæler regnekraft?

Nej. Den, der kunne installere en miner, kunne udføre kode på serveren. Dermed var der som regel også adgang til konfigurationsfiler, adgangsdata og databaser. Mineren er det synlige symptom på et indbrud.

Hvilke harmløse årsager har en høj serverbelastning?

Backups, billedbehandling, opbygning af søgeindeks, aggressive crawlere eller en fejlbehæftet udvidelse kan også forbruge meget regnetid. Disse årsager lader sig som regel knytte til en kendt proces og tidsplan. Forbliver belastningen uden forklaring, bør I kontrollere nøjere.

Kilder

Akut kontakt

Hver time tæller. Skriv til os nu.

Beskriv kort system, PHP-version og observation. Vi vender tilbage, afklarer situationen og arbejder på afstand, indtil hændelsen er afsluttet og dokumenteret.

Akut hjælp