# Tjekliste efter et hack: 20 punkter til opfølgningen

> Tjekliste, når websitet er blevet hacket: 20 punkter fra inddæmning og bevissikring over oprydning og nye adgange til anmeldelsespligter.

Kilde: https://phpsos.de/da/ratgeber/checkliste-nach-dem-hack/  
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:** Hvis jeres website er blevet hacket, hjælper denne tjekliste med ikke at glemme noget: først inddæmme og sikre beviser, derefter finde årsagen og rydde op, derefter forny alle adgange, kontrollere pligter og afslutte hændelsen dokumenteret. Rækkefølgen er vigtig, for den, der sletter først, mister spor, og den, der kun rydder op uden at lukke sårbarheden, bliver angrebet igen.

## Hvad denne tjekliste gælder for, når websitet er blevet hacket

Tjeklisten henvender sig til ledelse, ejere og it-ansvarlige efter et bekræftet eller sandsynligt angreb på et website, en shop eller en PHP-webserver. Den egner sig også efter PHP2Shell, hvis en server var tilgængelig før opdateringen, og der foreligger tegn på en kompromittering.

Ikke ethvert punkt passer til ethvert miljø. Gå alligevel listen fuldstændigt igennem, og notér ved hvert punkt, om det er udført, ikke relevant eller åbent. Denne protokol er senere værdifuld for forsikring, databeskyttelse og intern opfølgning.

Notér for hvert trin dato, klokkeslæt, ansvarlig person og resultat ind. Hvis flere personer er involveret, så udpeg én person, der fører listen og fastholder beslutninger.

## Fase 1: Inddæm og sikr straks

1. **Begræns skaden:** Sæt websitet i vedligeholdelsestilstand eller tag det af nettet, hvis besøgende er i fare, eller data kan sive ud. BSI (det tyske forbundskontor for informationssikkerhed) anbefaler ved PHP2Shell midlertidigt at tage upatchede webservere af nettet, hvis en opdatering ikke er mulig med det samme.
2. **Slet intet:** Fjern ingen filer, opsæt ikke serveren på ny, og tøm ingen logs, før spor er sikret.
3. **Sikr logs:** Kopiér access-, error-, PHP-FPM- og systemlogs til et andet system, og notér kontrolsummer. Til PHP2Shell anbefaler fagpressen at gemme logs fra den 20.10.2026.
4. **Sikr et aftryk:** Opret en kopi af filer og database, ved virtuelle servere et snapshot, som bevisstatus, og ændr den ikke.
5. **Underret de ansvarlige:** Inddrag tidligt ledelsen, den databeskyttelsesansvarlige, hosteren og, hvis den findes, cyberforsikringen. Mange forsikringer har anmeldelsesforpligtelser.

## Fase 2: Find årsagen og ryd op

6. **Fastslå indgangen:** Analysér logs, filændringer og versioner. Kontrollér PHP selv, CMS, temaer, udvidelser, adgangsdata og serverens tjenester. Uden kendt årsag består risikoen for et fornyet angreb.
7. **Luk sårbarheden:** Bring PHP til en rettet version (8.5.12, 8.4.27, 8.3.36 eller 8.2.35 henholdsvis udbyderens bekræftede backport), opdatér CMS og udvidelser, genstart alle PHP-workere.
8. **Afgræns tidsrummet:** Fastslå det tidligste tidspunkt for mistænkelig aktivitet. Det afgør, hvilke backups der kan være rene, og hvilke data der kan være berørt.
9. **Fjern bagdøre:** Kontrollér og fjern webshells, fremmede PHP-filer i upload- og cachemapper, ændrede kernefiler, cronjobs, SSH-nøgler og systemtjenester. Erstat kernefiler fra en ren kilde.
10. **Ryd op i databasen:** Fjern ukendte admin-konti, indsmuglede scripts i indhold og indstillinger samt spamindhold.
11. **Overvej genopbygning:** Ved dybtgående kompromittering af serveren er en genopbygning på et frisk, patchet system med kontrollerede data ofte den mere pålidelige vej end en oprydning i det kørende system.

## Fase 3: Forny adgange og hærd

12. **Skift adgangskoder:** Til CMS, hostingkonto, panel, database, FTP, SFTP, SSH og e-mail, og det fra en ren enhed.
13. **Skift nøgler og tokens:** Generér API-nøgler, grænseflader til betalings- og forsendelsestjenester, CMS'ets applikationsnøgler, SSH-nøgler og certifikater, som lå på serveren, på ny.
14. **Afslut sessioner:** Log alle aktive logins i CMS og hos tjenester ud, og kontrollér registrerede tofaktor-enheder.
15. **Aktivér tofaktor-login:** For alle admin-adgange, inklusive hosting, domæne og DNS.
16. **Hærd serveren:** Kontrollér og dokumentér PHP-indstillinger, filrettigheder, kørselsspærringer i upload-mapper, firewall og sikkerhedsheadere.

## Fase 4: Pligter, kommunikation og afslutning

17. **Kontrollér anmeldelsespligter:** Kan personoplysninger være berørt, kan der efter [GDPR art. 33 være brug for en anmeldelse inden for 72 timer](https://phpsos.de/da/compliance/dsgvo-meldepflicht-72-stunden/). Vurderingen hører hjemme hos den databeskyttelsesansvarlige eller en advokat. Kontrollér branchepligter, f.eks. efter NIS2, særskilt.
18. **Overvej politianmeldelse:** De [Zentrale Ansprechstellen Cybercrime (tyske politis centrale kontaktpunkter for cyberkriminalitet)](https://phpsos.de/da/compliance/anzeige-polizei-zac/) modtager anmeldelser fra virksomheder. De sikrede logs er et vigtigt grundlag for det.
19. **Underret kunder og Google:** Underret berørte sagligt og afstemt. Viser Google en advarsel, så anmod efter oprydningen om gennemgang, som beskrevet under [Fjern Google-advarsel](https://phpsos.de/da/ratgeber/google-warnung-entfernen/).
20. **Dokumentér afslutningen og overvåg:** Notér årsag, tidsrum, foranstaltninger og åbne punkter i en rapport, udled erfaringer til nødplanen, og overvåg systemerne skærpet i ugerne derefter.

## Hyppige fejl ved opfølgningen

Mange hændelser trækker ud, fordi der i den første ophidselse spares det forkerte sted, eller der handles for hurtigt. Disse fejl bør I undgå:

- **Kun fjerne det synlige:** En slettet spamside eller en fjernet omdirigering er intet bevis for et rent website. Bagdøre forbliver ofte ubemærket.
- **Skifte adgangskoder fra det berørte system:** Kører der stadig skadelig software på computeren eller serveren, kan nye adgangsdata straks sive ud igen.
- **Spille en backup blindt tilbage:** Uden lukket sårbarhed og uden kontrol af backuppen står angriberen hurtigt i døren igen.
- **Opfatte patchen som afblæsning:** En opdatering til en rettet PHP-version beviser ikke, at der ikke skete noget før, og fjerner ingen indsmuglet skadelig software.
- **Kontrollere pligter for sent:** Frister begynder med kendskabet til hændelsen, ikke med afslutningen af oprydningen.
- **Ingen dokumentation:** Uden protokol kan spørgsmål fra forsikring, myndigheder eller kunder senere næppe besvares.

> **Vigtigt:**
> Denne tjekliste erstatter ikke juridisk rådgivning. Ved spørgsmål om anmeldelsespligter, ansvar eller forsikring kontakter I jeres databeskyttelsesansvarlige, en advokat eller jeres forsikringsselskab.

## Hvordan hjælper PHP SOS konkret?

- Vi overtager den strukturerede [Incident Response](https://phpsos.de/da/leistungen/incident-response/) og gennemgår tjeklisten sammen med jer, punkt for punkt med protokol.
- Vi sikrer logs og systemstatusser, så de forbliver anvendelige for forsikring, myndigheder og en mulig [IT-forensik](https://phpsos.de/da/leistungen/it-forensik/).
- Vi lukker sårbarheden, rydder op eller genopbygger og fornyer adgange i den rigtige rækkefølge.
- Vi leverer en slutrapport med årsag, foranstaltninger og anbefalinger og overvåger efter ønske systemerne videre bagefter.


## Ofte stillede spørgsmål

**Hvad er det første, jeg bør gøre, hvis mit website er blevet hacket?**  
Bevar roen, slet intet, og begræns skaden. Tag om nødvendigt websitet af nettet eller i vedligeholdelsestilstand, og sikr logs og filer, før I rydder op. Derefter følger årsagssøgning og oprydning.

**Er det nok at genoprette websitet fra en backup?**  
Som regel ikke. Backuppen kan allerede indeholde skadelig kode, og den sårbarhed, som angriberen kom ind gennem, er efter tilbagespilningen stadig åben. Luk først årsagen, spil derefter en kontrolleret, ren status ind på et opdateret system.

**Skal jeg anmelde et hack til databeskyttelsesmyndigheden?**  
Hvis personoplysninger kan være berørt, foreskriver art. 33 GDPR i princippet en anmeldelse inden for 72 timer efter kendskab, medmindre en risiko for de berørte er usandsynlig. Vurderingen hører hjemme hos jeres databeskyttelsesansvarlige eller en advokat.

**Hvornår er en hændelse virkelig afsluttet?**  
Når årsagen er lukket, alle kendte bagdøre er fjernet, adgange fornyet, pligter opfyldt og foranstaltningerne dokumenteret. En periode med skærpet overvågning bagefter hører med for at opdage oversete spor.

## Kilder

- [GDPR art. 33: anmeldelse til tilsynsmyndigheden](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Politiet: Zentrale Ansprechstellen Cybercrime (tyske politis centrale kontaktpunkter for cyberkriminalitet)](https://www.polizei.de/)
- [BSI (det tyske forbundskontor for informationssikkerhed): henvisninger om it-sikkerhedshændelser](https://www.bsi.bund.de/)
- [php.net: Sikkerhedsmeddelelser om PHP2Shell](https://www.php.net/)