Kort sagt: Er I berørt? Ring til os. Vi hjælper. Har I mistanke om, at jeres server er blevet hacket, tæller først og fremmest én ting: bevare spor. Vi overtager på afstand fra den første besked situationsbilledet, sikringen, inddæmningen, oprydningen og dokumentationen, indtil hændelsen er afsluttet.
Slet intet og opsæt intet på ny nu. Indspil heller ingen backup, før der er sikret. Den, der rydder op, ødelægger netop de spor, der viser, hvordan angriberen kom ind. Meld en nødsituation, så går vi frem sammen.
Er I berørt? Tegn på, at en server er blevet hacket
En mistanke er nok til at kontakte os. I behøver ikke at bevise angrebet. Typiske tegn er:
- Webserveren eller PHP-FPM starter processer som
shellerbash. Det er et stærkt advarselssignal, som vi forklarer på siden Webserveren starter en shell. - I upload-, cache- eller temp-mapper ligger der nye eller ukendte PHP-filer.
- Der er cronjobs, som ingen har oprettet, eller SSH-nøgler, som ingen kan placere.
- Belastningen er uden synlig grund høj, eller serveren opbygger usædvanlige udgående forbindelser.
- Mails fra jeres server havner i spam eller afvises.
- Hostingudbyderen, en kunde eller en advarsel i browseren melder skadelig kode.
- I CMS'et dukker der administratorkonti op, som ingen har oprettet.
Flere tegn finder I under Er vi allerede kompromitteret?. Passer flere punkter, så behandl serveren som hacket, indtil det modsatte er dokumenteret.
Server hacket: Hvad I gør med det samme
- Bevar roen og ændr intet. Slet ingen filer, ingen »hurtige reparationer«, ingen nyinstallation oven på den gamle tilstand.
- Fasthold tidspunktet. Notér, hvad I har observeret hvornår, og hvem der sidst har foretaget ændringer på systemet.
- Bevar logs. Adgangs-, fejl- og systemlogs må ikke roteres eller overskrives. Ved PHP2Shell anbefaler fagpressen at gemme serverlogs fra den 20.10.2026.
- Gør angrebsfladen mindre. Tag serveren af det offentlige net eller spær den med firewall, hvis data kan sive ud. Sluk den ikke bare.
- Saml adgangene. Hvem har SSH-, panel-, FTP-, CMS- og databaseadgang? Ændr adgangskoder først efter aftale og kun fra en ren enhed.
- Udpeg en kontaktperson. En person med beslutningskompetence bør være tilgængelig, også til nedlukning og genstart.
- Kontakt os nu. Ring til os eller skriv på WhatsApp. Alt det øvrige afklarer vi med jer skridt for skridt.
Tag af nettet eller lade køre?
Det er det hyppigste spørgsmål i de første minutter, og det har intet generelt svar. Kører der en onlineshop med betalinger eller en portal med kundedata, vejer beskyttelsen af data som regel tungest. Så er en midlertidig afskærmning rigtig, for eksempel via en vedligeholdelsesside eller en firewallregel, der kun tillader jeres administratorer.
En hård nedlukning er derimod sjældent det bedste første skridt, fordi der ligger spor i arbejdshukommelsen, som en genstart sletter. Bedre er et aftryk af systemet, for eksempel et snapshot hos hostingudbyderen, før noget ændres. I PHP2Shell-situationen anbefaler BSI at tage webservere midlertidigt af nettet, hvis en opdatering ikke straks er mulig. Det betyder ikke, at hver afbrudt server er blevet hacket.
Om I i jeres tilfælde afskærmer, drosler eller lader køre, afgør vi sammen med jer ud fra det, der ligger på systemet.
Opsætte på ny eller rense?
Mange vil helst bygge serveren op på ny med det samme. Det er ikke forkert, men først efter sikringen. Ellers forbliver det uklart, hvordan angriberen kom ind, og den samme vej står også åben for det nye system. Afvejningen beskriver siden Opsætte serveren på ny eller rense den?, sikringen før en genopbygning siden Sikr beviser, før I opsætter på ny.
Vigtigt: En PHP-opdatering alene løser ikke problemet. Den lukker sårbarheden, men fjerner ikke skadelig software, der allerede er indsmuglet. Hvordan spor kan findes i protokollerne, står under Analysér webserverlogs efter et angreb. Og gå ud fra, at adgangsdata fra konfigurationsfiler er blevet læst med: Database-, mail- og API-adgange hører med på listen over hemmeligheder, der skal fornyes.
Hvordan hjælper PHP SOS konkret?
- Danne overblik over situationen: Vi afklarer sammen med jer, hvad der er observeret, hvilke systemer der kan være berørt, og hvilke data der ligger dér.
- Sikre og lukke: Vi sikrer filer, database og logs, før noget ændres. Derefter inddæmmer vi angrebet og lukker indgangsdøren, ved PHP2Shell med rettelse og genstart af alle PHP-processer.
- Kontrollere og rense: Vi leder efter webshells, bagdøre, cronjobs og fremmede adgange og fjerner dem. Detaljer står under Få malware og webshells fjernet.
- Hærde og rapportere: I modtager en dokumentation med tidslinje, fund og anbefalinger. Rækker hændelsen ud over én server, skifter vi til en struktureret incident response.
Hvad I ikke bør gøre
I stress sker der undgåelige fejl. Slet ikke »mistænkelige« filer på mistanke uden først at have sikret dem. Kør ikke kommandoer fra fora, som I ikke forstår. Og installer ikke sikkerhedsplugins på en server, der muligvis allerede er kompromitteret: Skadelig kode kan narre scannere, og resultatet vugger jer ind i en falsk sikkerhed. Vær også forsigtige med tips om at blokere alle forespørgsler med et bestemt sessions-ID; fagforfattere afviser udtrykkeligt sådanne råd om PHP2Shell. Sikkert kontrollere kan I jeres egen version med php -v og et blik i pakkens changelog i jeres distribution, for backports lader ofte versionsnummeret forblive det samme.
Hvad I bør sende til os
- en kort beskrivelse: hvad er blevet påfaldende, siden hvornår, hvad blev ændret senest
- systemets type: egen server, vServer, managed server eller hostingpakke
- adgangen via SSH eller panel eller tilladelsen til at tale med jeres hostingudbyder
- oplysninger om eksisterende sikkerhedskopier og deres alder
- advarsler fra hostingudbyder, browser eller kunder i deres ordlyd
Mangler I noget af det, så kontakt os alligevel. Hullerne lukker vi i samtalen.
Hvorfor PHP SOS
Vi arbejder Made in Germany og har sammen med vores partnernetværk af cyberprofessionelle i over 25 år specialiseret os i it-sikkerhed. I har én kontaktperson, vi arbejder på afstand, uden transport, i hele Tyskland og Europa. Hvert skridt bliver dokumenteret, og vi skelner åbent mellem dokumenteret, sandsynligt og ukendt. Løfter, som ingen kan holde, afgiver vi ikke. Et overblik over efterbehandlingen står i tjeklisten efter et hack, den samlede nødhjælp under Website hacket? Nødhjælp på afstand. Om anmeldelsespligten ved databrud kan I læse 72-timersreglen; den juridiske vurdering forbliver hos databeskyttelsesrådgivere og advokater.
Er I berørt? Ring til os. Vi hjælper.
Vent ikke, til mistanken bliver til en større skade. Vi overtager fra den første besked og bliver ved, indtil hændelsen er afsluttet og dokumenteret. Meld en nødsituation nu.
Ofte stillede spørgsmål
Server hacket: Skal jeg slukke den med det samme?
Ikke forhastet. En nedlukning kan ødelægge flygtige spor i arbejdshukommelsen. Bedre er det at afbryde serveren fra nettet eller afskærme den med firewall og først sikre. Hvis I er usikre, så kontakt os først.
Hvordan finder jeg ud af, om min server virkelig er blevet hacket?
Tegn er processer, som webserveren starter, nye PHP-filer i upload- eller cachemapper, ukendte cronjobs og SSH-nøgler samt usædvanlige udgående forbindelser. Sikkerhed giver først en analyse af logs og filer. Der findes ingen bekræftede PHP2Shell-indikatorer; opdagelsen bygger på adfærdsanalyse.
Er en PHP-opdatering nok, hvis serveren allerede er blevet hacket?
Nej. En rettelse lukker indgangsdøren, men fjerner ikke skadelig software, der allerede er indsmuglet, og beviser ikke, at der ikke er sket noget før. Efter opdateringen skal desuden alle PHP-processer genstartes.
Skal jeg anmelde en hacket server?
Hvis personoplysninger kan være berørt, kan en anmeldelse til tilsynsmyndigheden inden for 72 timer være nødvendig. Vurderingen træffer jeres databeskyttelsesrådgiver eller jeres advokat; vi leverer de tekniske fakta hertil.
Kan jeg selv rense den hackede server?
Ved små systemer er det muligt, men risikabelt: Den, der kun fjerner synlige filer, overser ofte bagdøre, cronjobs eller adgange. Vi kontrollerer, om en oprydning er nok, eller om en genopbygning fra rene kilder er mere fornuftig.