Kort sagt: For at kontrollere CMS-kernefiler sammenligner I de installerede filer med en ren original af samme version: ved WordPress via de officielle kontrolsummer, ved andre systemer via en frisk download eller en genopbygning ud fra composer.lock. Hver afvigelse er en kontrolopgave. Afstemningen finder også ukendt skadelig kode, men dækker kun filer, hvortil der findes en original.
Hvorfor sammenligningen finder mere end enhver signatur
Malwarescannere leder efter kendte mønstre. Det, de ikke kender, overser de. En afstemning med originalen arbejder omvendt: Den spørger ikke, om en fil ser mistænkelig ud, men om den præcis svarer til det, producenten har leveret. Hver afvigelse falder i øjnene, uanset om den følger et kendt mønster eller ej.
Det er efter PHP2Shell særligt værdifuldt. For sårbarhederne CVE-2026-109618 og CVE-2026-109619 findes der ingen offentliggjorte, bekræftede indicators of compromise. Scannere kan altså ikke søge målrettet efter PHP2Shell-spor. En afstemning med originalen finder derimod enhver ændring i kernen, uanset hvordan den er opstået. Hvorfor scannere alene ikke er nok, forklarer indlægget Malwarescannere til websites: Hvad de finder, og hvad ikke.
Princippet: samme version, ren kilde
En sammenligning er kun så god som dens reference. Tre betingelser skal være opfyldt:
- Nøjagtig samme version: En sammenligning med en nyere version viser hundredvis af harmløse forskelle. Find den installerede version i applikationen eller i
composer.lock. - Officiel kilde: Originalen stammer fra producenten, fra det officielle pakkekatalog eller fra jeres eget versionsstyringssystem. Ikke fra en gammel backup af den berørte server.
- Sammenligning på en kopi: Arbejd på en sikret kopi af webmappen, så tidsstempler og spor bevares.
| System | Reference | Værktøj |
|---|---|---|
| WordPress-kerne og plugins fra kataloget | kontrolsummer fra WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Composer-projekter (f.eks. Shopware 6, Laravel, Symfony, Drupal, TYPO3 i Composer-tilstand) | genopbygning ud fra composer.lock |
composer install i tom mappe, derefter diff |
| CMS med downloadpakke | pakke af samme version fra producenten | diff -rq |
| Egne projekter med Git | seneste kendte commit | git status, git diff |
| Serverens systempakker | distributionens pakkedatabase | dpkg --verify, rpm -Va |
WordPress: mere end verify-checksums
Hvordan I kontrollerer kerne og plugins med WP-CLI, står i vejledningen Find bagdøre i WordPress. Et supplement er umagen værd: Ifølge WP-CLI-dokumentationen kontrollerer tilvalget --include-root alle filer og mapper i hovedmappen og advarer om poster, som ikke hører til WordPress. Dér lægger angribere gerne filer, hvis navne minder om kernefiler.
# Kerne mod officielle kontrolsummer, inklusive fremmede filer i hovedmappen
wp core verify-checksums --include-root
Kommercielle plugins og temaer dækker denne vej ikke. Til dem henter I originalpakken i samme version hos udbyderen og sammenligner med diff.
Kontrollér CMS-kernefiler ved Composer-projekter
Mange moderne PHP-applikationer består for den største del af pakker, som Composer installerer, pakkehåndteringen til PHP. Hvordan den arbejder, forklarer siden Composer: Pakkehåndteringen til PHP. Filen composer.lock fastholder, hvilke versioner der præcis er installeret. Ifølge Composer-dokumentationen bruger composer install disse nøjagtige versioner. Dermed kan leveringstilstanden genopbygges:
# På et rent system, ikke på den berørte server
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Opregn forskelle i vendor-mappen
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Tilvalgene --no-scripts og --no-plugins forhindrer, at scripts fra pakkerne udføres ved genopbygningen. Blev produktionen installeret med --no-dev, bruger I også dette tilvalg ved genopbygningen, ellers vises udviklingspakker som forskel. Vær opmærksom på to slags resultater: filer, der er forskellige, og filer, der kun findes på serveren. Den anden gruppe er ofte den mest interessante. Hvordan I desuden kontrollerer de installerede pakker for kendte sårbarheder, beskriver vejledningen Kontrollér Composer-afhængigheder for sårbarheder.
Sammenlign også operativsystemet
Havde en angriber root-rettigheder, kan han også have erstattet systemprogrammer. Pakkehåndteringerne har en egen afstemning med:
# Debian, Ubuntu: filer, hvis indhold afviger fra pakken
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: kontrollér alle pakker
sudo rpm -Va
Et 5 på tredje plads i outputtet betyder, at en fils indhold er ændret. Ifølge dpkg-håndbogen er indholdsafstemningen dér p.t. den eneste virksomme kontrol. Ændrede konfigurationsfiler er normale og markeret med c. Et ændret program i /usr/bin er derimod et alvorligt alarmtegn. Bemærk: En angriber med root-rettigheder kan også manipulere pakkedatabasen. Ved mistanke om root-adgang er en genopbygning mere pålidelig end enhver afstemning.
Et versionsstyringssystem til applikationskoden gør fremtidige afstemninger til en sag på sekunder. git status viser så enhver afvigelse fra den frigivne tilstand.
Vurdér afvigelser, og kend grænserne
Ikke enhver afvigelse er et angreb. Nogle bureauer har tidligere tilpasset kernefiler direkte i stedet for at bruge udvidelser. Sprogpakker, linjeskift efter en overførsel via FTP eller efterfølgende indspillede rettelser giver også forskelle. Afgørende er, om nogen kan forklare ændringen.
Gå hver afvigelse igennem for sig, og noter resultatet: kendt og dokumenteret, harmløst forklarlig eller uklar. Uklare filer åbner I kun som tekst på en kopi og erstatter dem fra den rene kilde. Ved filer, der kun findes på serveren, er spørgsmålet enklere: Den, der ikke kender dem, bør sikre dem og lade dem fjerne, efter at deres indhold er kontrolleret.
Uploads, konfigurationsfiler som wp-config.php eller .env, egne tilpasninger og caches har ingen original. De skal kontrolleres målrettet, ligesom databasen, cronjobs, brugerkonti og SSH-nøgler. En ren afstemning er derfor en vigtig byggesten, men ingen frifindelse af hele serveren.
Hvordan hjælper PHP SOS konkret?
- Vi finder de installerede versioner og opbygger en ren reference ud fra officielle kilder.
- Vi sammenligner kerne, udvidelser, Composer-pakker og systemprogrammer og vurderer hver afvigelse.
- Vi kontrollerer de områder uden original målrettet og erstatter ændrede filer inden for rammerne af malwarefjernelsen fra ren kilde.
- Vi opsætter efter ønske en versionstilstand, som fremtidige kontroller kører mod.
Ofte stillede spørgsmål
Hvordan kontrollerer jeg, om WordPress-kernefiler er ændret?
Med WP-CLI og kommandoen wp core verify-checksums. Den sammenligner filerne med de kontrolsummer, WordPress.org offentliggør for den installerede version. Med tilvalget --include-root advarer WP-CLI desuden om filer i hovedmappen, som ikke hører til WordPress.
Hvad gør jeg ved et CMS uden indbygget kontrolfunktion?
I henter nøjagtig den samme version fra producentens officielle kilde og sammenligner begge mapper med diff. Ved Composer-projekter genopbygger I tilstanden ud fra composer.lock i en tom mappe og sammenligner vendor-mappen.
Finder afstemningen også skadelig kode i plugins og temaer?
Kun hvis der findes en ren original til dem, f.eks. fra det officielle katalog eller fra udbyderen. Egne tilpasninger, uploads og konfigurationsfiler har ingen original og skal kontrolleres separat.
Erstatter afstemningen en malwarescanner?
Den supplerer den. Afstemningen finder enhver ændring af kendte filer, også ukendt skadelig kode. Men den siger intet om filer uden original, databasen, cronjobs eller adgange.