Hacket hjemmeside: det skal I gøre de første timer

De fleste hacks er ikke til at se, når man selv åbner forsiden. Angriberne vil have, at sitet bliver ved med at køre, fordi det er sitet, de tjener penge på: det sender trafik videre til svindelsider, viser spam til Google eller samler betalingsoplysninger ind. Derfor opdager mange virksomheder det først, når en kunde, Google eller hostingudbyderen siger det.

Her er de tegn, vi oftest ser, og hvad de typisk dækker over:

Google beskriver selv en særlig variant, hvor siderne ser tomme eller normale ud i jeres browser, men viser spamord og links til søgemaskinerne. Det kaldes cloaking, og det er grunden til, at "jeg kan ikke se noget" ikke er et bevis på, at sitet er rent.

Mekanismen er enkel. Den inficerede kode læser to felter i hver forespørgsel: User-Agent (hvilken browser eller robot der spørger) og Referer (hvilken side den besøgende kom fra). Googlebot får spam, mobilbrugere fra Google bliver omdirigeret, og I selv ser det normale site. Ofte er det få linjer i en .htaccess-fil med Apaches mod_rewrite:

RewriteEngine On
RewriteCond %{HTTP_REFERER} (google|bing|yahoo) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (android|iphone) [NC]
RewriteRule ^(.*)$ https://svindel.example/ [R=302,L]

[NC] ignorerer store og små bogstaver, og [OR] binder betingelserne sammen med "eller". Samme logik kan ligge i PHP, fx i index.php eller et plugin, og er så usynlig i .htaccess.

Før I går i gang, så få bekræftet, hvad der er sket. Det tager under ti minutter og giver jer noget konkret at handle på:

1. Søg efter jeres eget domæne. Skriv site:jeresdomæne.dk i Google. Kig efter sider, I ikke kender, og prøv også site:jeresdomæne.dk sammen med ord som "viagra", "casino" eller "replica". Google anbefaler selv denne fremgangsmåde.
2. Åbn Search Console. Find rapporten Sikkerhedsproblemer (Security Issues) i menuen. Her viser Google eksempler på berørte webadresser og typen af problem, fx malware, kodeindsprøjtning, indholdsindsprøjtning eller vildledende sider. Har I ikke Search Console, så bekræft domænet nu. I skal bruge det senere.
3. Se siden, som Google ser den. Indsæt en berørt adresse i Webadresseinspektion (URL Inspection), klik Test live URL og derefter View tested page. Her ser I den rå HTML, headers og et skærmbillede fra Googlebot. Google anbefaler værktøjet til at afsløre cloaking.
4. Tjek Google Safe Browsing. På Googles Transparency Report kan I slå jeres domæne op og se, om det lige nu er markeret som farligt, uden at besøge sitet.
5. Test på en telefon over mobilnettet. Søg efter jeres firmanavn i Google på en telefon, der ikke er på kontorets wifi, og klik på resultatet. Mange omdirigeringer slår kun til for mobiltrafik, der kommer fra en søgemaskine.
6. Kig i brugerlisten. I WordPress er det Brugere i kontrolpanelet, filtreret på rollen Administrator. I PrestaShop ligger medarbejderne under Avancerede parametre (Advanced Parameters > Team). Skriv navn, mail og oprettelsesdato ned på alle, I ikke kender.

En tekniker kan efterligne besøgende med curl: -A sætter User-Agent, -e sætter Referer, og -w skriver statuskode og omdirigering. Giver den første 200 og den anden 302 mod et fremmed domæne, er der en betinget omdirigering:

# Direkte besøg
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://www.webshop.dk/

# iPhone, der kommer fra Googles søgeresultater
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X)" -e "https://www.google.com/" https://www.webshop.dk/

# Som Googlebot: led efter spamord og skjulte iframes i HTML
curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://www.webshop.dk/ | grep -iE "casino|viagra|<iframe"

Et rent resultat i curl frikender ikke sitet. User-Agent kan forfalskes, og ægte Googlebot kendes ifølge Google på IP-adresse og omvendt DNS. Avancerede bagdøre tjekker netop det, så Webadresseinspektion er den test, der tæller.

Brug en computer, I stoler på, til tjekket. Har sitet sendt malware ud, vil I ikke klikke rundt på det fra den maskine, I bruger til netbank.

Når I har bekræftet hacket, skal sitet ud af drift. Det beskytter jeres besøgende, og det forhindrer angriberen i at ændre mere, mens I arbejder.

Googles vejledning er her ret præcis, og den modsiger det, mange gør af sig selv: det er ikke nok, at det hackede site selv viser en fejlside. Svaret skal komme udefra, fra et sted angriberen ikke har kontrol over. I praksis har I tre muligheder:

• Stop webserveren eller sitet i hostingpanelet, så der ikke kører kode fra de inficerede filer.
• Peg domænet midlertidigt over på en statisk side på en anden server, der svarer med HTTP-status 503 (midlertidigt utilgængelig). Det fortæller også Google, at sitet er nede for en tid, og ikke at siderne er væk.
• Bed hostingudbyderen om at lukke det for jer med en 503 uden for de inficerede mapper. Sig samtidig, at I skal kunne slå sitet til og fra, mens I tester.

Har I selv en server, er en midlertidig nginx-opsætning på en separat maskine det hurtigste. return sender status 503, og add_header skal have always, fordi nginx ellers kun tilføjer headers ved 2xx- og 3xx-svar. Retry-After angiver i sekunder, hvornår klienter kan prøve igen:

server {
    listen 80;
    listen 443 ssl;
    server_name webshop.dk www.webshop.dk;
    ssl_certificate     /etc/ssl/webshop.dk/fullchain.pem;
    ssl_certificate_key /etc/ssl/webshop.dk/privkey.pem;

location / {
        add_header Retry-After 3600 always;
        return 503 "Webshoppen er midlertidigt lukket. Vi er snart tilbage.\n";
    }
}

Ved DNS-skift kan den gamle adresse hænge i resolvere, så længe postens TTL er, så tjek med dig +short A webshop.dk. Lad 503 stå i dage, ikke uger: adresser, der vedvarende svarer med serverfejl, fjernes til sidst fra Googles indeks.

Ring eller skriv til hostingudbyderen under alle omstændigheder. Ligger I på delt hosting, kan andre kunder være ramt, og udbyderen ser ofte ting i deres logs, som I ikke har adgang til.

Det virker ikke at slå CMS'ets vedligeholdelsestilstand til. Den kører i den samme kode, som er kompromitteret, og bagdøre i fx uploadmappen kan stadig kaldes direkte. En ændring i robots.txt hjælper heller ikke, fordi den kun stopper søgemaskiner, ikke mennesker.

Vores hjælp efter hackerangreb starter med netop dette trin, og løftet er, at sitet eller shoppen kører igen inden for 24 timer.

Det er fristende at slette de mærkelige filer med det samme. Lad være, før I har taget en kopi. Kopien er jeres bevis over for politi, forsikring og Datatilsynet, og den er det eneste, der kan vise, hvad angriberen faktisk har lavet.

WordPress anbefaler at tage et øjebliksbillede af hele miljøet, selv om det er inficeret, før selve oprydningen begynder. Det samme gælder for alle andre systemer. Gem:

• Alle filer i webroden, inklusive skjulte filer som .htaccess.
• Databasen som et samlet dump.
• Webserverens adgangslogs og fejllogs, så langt tilbage som de findes. Mange hostingudbydere sletter dem efter få dage, så bed om dem i dag.
• FTP-, SFTP- og panel-logs, hvis udbyderen har dem.
• Skærmbilleder af advarsler, spamsider, omdirigeringer og ukendte brugere, med dato og klokkeslæt.

Med SSH-adgang tager det få minutter. tar bevarer filernes ændringstidspunkter, som I skal bruge til at finde angrebets start, og en SHA-256-checksum dokumenterer senere, at kopien ikke er ændret:

ts=$(date +%Y%m%d-%H%M)
mkdir -p /root/haendelse-$ts && cd /root/haendelse-$ts

# Filer inklusive skjulte filer
tar -czf filer.tar.gz -C /var/www webshop.dk

# Databasen
wp db export database.sql --path=/var/www/webshop.dk/public_html --skip-plugins --skip-themes

# Logfiler
tar -czf logs.tar.gz /var/log/nginx /var/log/apache2 2>/dev/null

# Checksummer (kontrolleres senere med sha256sum -c)
sha256sum filer.tar.gz database.sql logs.tar.gz > checksummer.sha256

WP-CLI indlæser normalt plugins og tema og dermed angriberens kode. Brug derfor --skip-plugins --skip-themes på alle WP-CLI-kommandoer, indtil sitet er rent.

Skriv samtidig en kort hændelseslog: hvornår I opdagede det, hvad I så, hvem der har gjort hvad, og hvad der er ændret på sitet de seneste uger (nye plugins, moduler, temaer eller brugere). WordPress kalder det grundlaget for en hændelsesrapport, og den sparer tid, uanset om I selv rydder op eller får hjælp.

Flyt kopien væk fra serveren, og husk, at den indeholder skadelig kode.

Gå ud fra, at angriberen kender de adgangskoder, der lå på serveren eller blev brugt til den. Google nævner eksplicit, at alle brugere og konti skal have ny adgangskode: FTP, database, systemadministrator og CMS. Tag dem i denne rækkefølge, og gør det fra en computer, der er scannet for virus. Både Google og WordPress peger på inficerede administratorcomputere som en almindelig indgang.

Husk SSH-nøgler. En ekstra offentlig nøgle i ~/.ssh/authorized_keys giver adgang uanset adgangskode, så gennemgå filen for hver bruger.

Slå tofaktorgodkendelse til overalt, hvor det kan lade sig gøre, mens I alligevel er inde. Det er en af de mest effektive ting, I kan gøre, og vi har skrevet mere om det under adgangsstyring og MFA.

I WordPress skal de hemmelige nøgler (salts) i wp-config.php også skiftes. De indgår i login-cookies, så når de er skiftet, er alle eksisterende cookies ugyldige, og alle bliver logget ud, også angriberen:

# Nye salts i wp-config.php
wp config shuffle-salts

# Afslut alle aktive sessioner for alle brugere
wp user list --field=ID | xargs -n 1 wp user session destroy --all

Ukendte administratorer skal slettes, men først når I har skrevet navnene ned. Og husk, at adgangskoderne skal skiftes igen, når sitet er rent. Hvis en bagdør stadig lå på serveren, mens I skiftede første gang, kan de nye koder være opsnappet.

En bagdør, ofte kaldet en webshell, er et lille stykke kode, der lader angriberen køre kommandoer på serveren via en almindelig HTTP-forespørgsel. Den ligger typisk, hvor ingen kigger: i uploadmappen, i en cachemappe, i et ubrugt tema eller inde i en ellers normal fil. Følg tre spor: ændringstidspunkt, placering og indhold.

GNU find kan liste filer efter ændringstidspunkt. -mtime -14 betyder ændret inden for 14 døgn (-newermt 2026-10-01 tager i stedet en dato), og -printf skriver dato og sti, så listen kan sorteres:

cd /var/www/webshop.dk/public_html

# PHP-filer ændret de seneste 14 døgn, nyeste først
find . -type f -name "*.php" -mtime -14 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort -r

# Kørbar kode i uploads, hvor der kun skal ligge billeder og dokumenter
find wp-content/uploads -type f \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.phar" \)

Ændringstidspunktet kan forfalskes, så det er et spor, ikke et bevis. Søg derfor også på indhold. Bagdøre skjuler deres kode og pakker den ud, når filen kaldes. Google nævner base64_decode, eval, gzinflate, str_rot13 og strrev som tegn på tilsløring:

Med grep søges i alle PHP-filer. -l viser kun filnavne, og [[:space:]]* fanger de mellemrum, angribere indsætter for at undgå simple søgninger:

# Kode, der pakkes ud og køres
grep -rlE --include="*.php" "eval[[:space:]]*\((base64_decode|gzinflate|gzuncompress|str_rot13)" .

# Input fra forespørgslen sendt direkte til kodeudførelse
grep -rlE --include="*.php" '(eval|assert|system|shell_exec|passthru)[[:space:]]*\([[:space:]]*\$_(POST|GET|REQUEST|COOKIE)' .

Nogle legitime plugins bruger base64_decode, så hvert fund skal ses af et menneske. I WordPress er den hurtigste vej at sammenligne med de officielle checksummer. wp core verify-checksums tjekker kernen mod WordPress.org, --include-root advarer også om fremmede filer i roden, og wp plugin verify-checksums --all gør det samme for plugins:

wp core verify-checksums --include-root --skip-plugins --skip-themes
wp plugin verify-checksums --all --skip-plugins --skip-themes

En ændret fil giver en linje som Warning: File doesn't verify against checksum: wp-includes/version.php. Tjekket bygger på WordPress.org's checksummer, så betalte plugins og temaer skal sammenlignes med en frisk kopi fra leverandøren.

Logfilerne fortæller, hvordan og hvornår angriberen kom ind. nginx' standardformat combined skriver én linje pr. forespørgsel med IP-adresse, tidspunkt, metode og sti, statuskode, bytes, Referer og User-Agent. Apache bruger et tilsvarende format. Sådan ser brug af en bagdør typisk ud:

203.0.113.45 - - [14/Oct/2026:03:12:44 +0200] "POST /wp-content/uploads/2026/09/cache.php HTTP/1.1" 200 312 "-" "Mozilla/5.0"

En POST til en PHP-fil i uploadmappen, der svarer 200, betyder, at koden er kørt. Det første af den slags kald fortæller, hvilken backup der kan være ren. Opdelt på mellemrum, som awk gør, er felt 1 IP-adressen, felt 4 tidspunktet, felt 6 metoden, felt 7 stien og felt 9 statuskoden:

# Hvilke PHP-filer modtager flest POST-forespørgsler
awk '$6 == "\"POST" && $7 ~ /\.php/ {print $7}' access.log | sort | uniq -c | sort -rn | head -20

# Alle kald til PHP-filer i uploads, også i roterede og komprimerede logs
zgrep -hE "\"(GET|POST) /wp-content/uploads/[^ ]*\.php" access.log*

# Login i wp-admin: et vellykket login svarer typisk 302, et forkert 200
awk '$6 == "\"POST" && $7 ~ /wp-login\.php/ && $9 == 302 {print $1, $4}' access.log

Et vellykket login kan genkendes, fordi WordPress sender brugeren videre med wp_safe_redirect, der som standard svarer 302, mens et forkert login viser formularen igen med 200.

Derefter databasen, som angribere bruger både til spam og til at komme tilbage:

# Peger sitet stadig på jeres eget domæne
wp option get siteurl
wp option get home

# Administratorer med oprettelsesdato
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Script- og iframe-kode gemt i tekstfelter
wp db search "<(script|iframe)" --regex --all-tables-with-prefix --stats

# De største options, der indlæses på hver side
wp option list --autoload=on --fields=option_name,size_bytes | sort -n -k 2 | tail

# Planlagte opgaver
wp cron event list --fields=hook,next_run_relative,recurrence
crontab -l

Autoload-options indlæses på hver sidevisning og er derfor et yndet gemmested. Undersøg options med ukendte navne og store værdier, cron-hooks uden kendt plugin og crontab-linjer, der henter noget med curl eller wget.

Oprydning er det sværeste trin, fordi I skal have det hele med. Én overset fil er nok til, at angriberen er tilbage i morgen. Der er to veje:

Gendan fra en backup fra før hacket. Det er den hurtigste vej, hvis I har en backup, I ved er ren. Brug tidspunktet fra logfilerne, altså det første kald til bagdøren eller det første ukendte login, og vælg en backup fra før det. Ordrer og kunder fra perioden derefter skal I så hente ind igen fra databasekopien.

Rens det eksisterende site. Har I ikke en ren backup, skal koden udskiftes. WordPress anbefaler at lægge præcis den samme version af kernen på igen via SFTP, ikke via geninstallér-knappen i kontrolpanelet, fordi den kun overskriver eksisterende filer, mens hacks ofte lægger nye filer ind. Mapperne /wp-admin og /wp-includes kan udskiftes helt. Med WP-CLI ser det sådan ud:

# Gem versionen, før kernen fjernes
v=$(wp core version --skip-plugins --skip-themes)
echo "$v"

# Udskift kernemapperne med en ren kopi uden standardtemaer og plugins
rm -rf wp-admin wp-includes
wp core download --version="$v" --skip-content --force

# Kontrollér resultatet
wp core verify-checksums --include-root --skip-plugins --skip-themes

Tjek, at versionen giver mening, da version.php også kan være ændret. Plugins og temaer hentes rene fra deres officielle kilde. Kig især efter ændringer i:

• .htaccess, som ofte bruges til omdirigeringer, og som kan ligge i flere mapper
• index.php, wp-load.php, header.php, footer.php, functions.php og 404.php
• PHP-filer i upload-, cache- og billedmapper, hvor der normalt ikke skal ligge kode
• tekstfelter i databasen, der pludselig indeholder <script> eller <iframe>

Find derefter hullet. Google nævner fire almindelige årsager: en virusinficeret computer hos en administrator, svage eller genbrugte adgangskoder, forældet software (CMS, plugins, moduler eller selve serveren) og usikker kode som åbne omdirigeringer eller SQL-injection. Der kan være flere huller på én gang, så stop ikke ved det første. Loglinjerne lige før det første kald til bagdøren viser ofte, hvilket plugin der blev brugt.

Luk til sidst for, at uploadmappen kan køre kode. I nginx skal blokken stå før den, der sender PHP til PHP-FPM, fordi nginx bruger det første regulære udtryk, der matcher:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

På Apache lægges en .htaccess i wp-content/uploads med dette indhold:

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

Slå også filredigering i kontrolpanelet fra med define( 'DISALLOW_FILE_EDIT', true ); i wp-config.php, så en stjålet administratorkonto ikke kan skrive PHP direkte i et tema.

Bagefter opdateres alt til nyeste version, og der sættes overvågning på, så I ser det, hvis filer ændrer sig igen. Specifikke guides til de mest almindelige systemer har vi under hacket WordPress, hacket WooCommerce og hacket server eller hosting.

Når sitet er rent, skal Google vide det. Advarslen forsvinder ikke af sig selv, før Google har tjekket sitet igen, og den koster både klik fra søgning og salg fra annoncer.

Sådan gør I:

1. Åbn rapporten Sikkerhedsproblemer i Search Console.
2. Kontrollér, at alle problemer på listen er løst på alle berørte sider, ikke kun på de eksempler, Google viser. Kør de berørte adresser gennem Webadresseinspektion igen, og tjek, at den testede side er ren.
3. Klik på Anmod om gennemgang (Request Review).
4. Beskriv kort, hvad problemet var, hvad I har gjort for at løse det, og hvordan I har sikret, at det ikke sker igen.

Google svarer med en mail, når anmodningen er modtaget, og når gennemgangen er færdig. Send ikke en ny anmodning, mens den første stadig behandles. Googles egne tidsangivelser er:

Er sitet godkendt som rent, fjernes advarslerne i browsere og søgeresultater inden for 72 timer, skriver Google. Spamsider, som angriberen har lagt ind, kan ligge i Googles indeks lidt endnu. Sørg for, at de svarer med 404 eller 410, så forsvinder de over tid, og fjern dem fra sitemaps, hvor Google nævner, at spamadresser ofte gemmes.

Et hack er et brud på persondatasikkerheden, hvis personoplysninger er blevet tilgængelige for uvedkommende, er ændret eller er gået tabt. På en webshop eller et site med kontaktformular, kundelogin eller nyhedsbrev er det oftere tilfældet, end man skulle tro. Kunders navne, adresser, mails, ordrehistorik og loginoplysninger er alle personoplysninger.

Reglerne kort:

• Anmeldelse til Datatilsynet skal ske uden unødig forsinkelse og om muligt inden 72 timer efter, at I er blevet opmærksomme på bruddet. Det gælder ikke, hvis det er usandsynligt, at bruddet medfører en risiko for personernes rettigheder.
• Fristen løber også i weekender og på helligdage. Ferie og sygdom er ikke en gyldig grund til at vente, skriver Datatilsynet i sin vejledning.
• Mangler I oplysninger, så anmeld med det, I ved, og supplér senere. En for sen anmeldelse skal have en begrundelse.
• Anmeldelsen sker digitalt via den fælles løsning på virk.dk, som Datatilsynet linker til fra siden Anmeld sikkerhedsbrud. Skriv ikke personoplysninger om de berørte ind i blanketten, og download en kopi, fordi anmeldelsen slettes i Erhvervsstyrelsens system efter 30 dage.
• De berørte skal have besked, hvis bruddet sandsynligvis medfører en høj risiko for dem, fx hvis adgangskoder eller betalingsoplysninger kan være lækket.
• Alle brud skal dokumenteres internt, også dem, I vurderer ikke skal anmeldes.

Logfilerne er også grundlaget for vurderingen. Svar med usædvanligt mange bytes, kald til eksportfunktioner og nye SQL- eller zip-filer i webroden tyder på, at kundedata er kopieret.

Er der tale om kriminalitet, kan I anmelde det til politiet på politi.dk eller på 114. Politiet anbefaler, at virksomheder anmelder cyberangreb hurtigt, fordi digitale spor bliver overskrevet. Det er også her, kopien, checksummerne og logfilerne fra trin fire bliver vigtige. Læs mere om reglerne under databrud og GDPR.

For en webshop er et hack ikke kun et teknisk problem. Det rammer omsætningen fra flere sider på én gang:

• Betalingssiden er det mest attraktive mål. Kode, der er sprøjtet ind i checkout, kan sende kortoplysninger videre til angriberen, mens shoppen ser helt normal ud. Bruger I en betalingsløsning, hvor kortnummeret indtastes hos udbyderen, er risikoen mindre, men falske betalingsformularer kan stadig blive lagt ind. Mistænker I det, så kontakt jeres betalingsudbyder med det samme.
• Annoncerne kan blive stoppet. Googles annoncepolitik tillader ikke annoncer, der fører til hackede sider, og overtrædelser behandles som alvorlige. Trafikken falder altså også på de betalte kanaler.
• Placeringerne i Google lider. Spamsider og omdirigeringer trækker jeres domæne ned, og det tager tid at komme tilbage.
• Mails kan ende i spam. Bruges serveren til at sende spam, kan dens IP-adresse komme på sortlister. Det rammer ordrebekræftelser, hvis de sendes fra samme server.
• Kunderne mister tilliden. En rød advarsel i browseren er det sidste, en ny kunde ser, før de lukker fanen.

Derfor tæller tiden. En shop, der er nede et døgn og kommer rent op igen, er bedre stillet end en, der kører inficeret videre i en uge.

Det er de samme fejl, vi ser igen og igen:

• At rydde op uden at tage en kopi først. Så er beviserne væk, og ingen kan sige, om kundedata er lækket.
• At gendanne en backup uden at lukke hullet. Sitet bliver hacket igen på samme måde, ofte inden for få dage.
• At skifte adgangskoder fra en inficeret computer. De nye koder bliver opsnappet med det samme.
• Kun at fjerne det synlige. Spamsiderne forsvinder, men bagdøren i uploadmappen bliver.
• At glemme databasen, cron og SSH-nøgler. Filerne er rene, men en autoload-option, en planlagt opgave eller en ekstra nøgle lægger bagdøren ind igen.
• At bruge vedligeholdelsestilstand som nedlukning. Den kører i den kompromitterede kode.
• At vente på at se, om det går over. 72-timersfristen for anmeldelse løber fra det tidspunkt, I opdagede bruddet.

Tjekliste til det første døgn:

1. Bekræft hacket med site:-søgning, Search Console, Webadresseinspektion og Transparency Report.
2. Luk sitet ned udefra, via hosting eller DNS, med en 503.
3. Giv hostingudbyderen besked.
4. Tag en fuld kopi af filer, database og logfiler, og lav checksummer.
5. Skriv en hændelseslog med tidspunkter.
6. Skift alle adgange fra en ren computer, gennemgå SSH-nøgler, skift salts, og notér og slet ukendte administratorer.
7. Vurder, om persondata er berørt, og anmeld til Datatilsynet inden 72 timer, hvis det er.
8. Find bagdøre med find, grep og checksumtjek, og gennemgå database, cron og logfiler.
9. Gendan fra en ren backup eller rens koden, og find hullet.
10. Bloker PHP i uploads, opdater alt, og skift adgangskoderne igen.
11. Anmod om gennemgang i Search Console.
12. Hold øje med filer, logins og trafik de næste uger.

Kan jeg bare gendanne en backup? Ja, hvis den er fra før hacket, og I samtidig lukker hullet. Ellers sidder angriberen inde igen kort efter. Tag altid en kopi af det hackede site, før I gendanner, og brug logfilerne til at finde det tidspunkt, backuppen skal være fra.

Hvor lang tid tager det at få Googles advarsel fjernet? Det afhænger af typen. Google angiver omkring en dag for phishing, nogle dage for malware og op til flere uger for spamhacks. Når sitet er godkendt, forsvinder advarslen inden for 72 timer.

Skal vi anmelde det til politiet? Det er ikke et krav, men politiet anbefaler det, og en anmeldelse kan være nødvendig over for forsikringen. Det gøres på politi.dk eller på 114.

Skal vi fortælle kunderne det? Kun hvis bruddet sandsynligvis medfører en høj risiko for dem, er det et krav. Er adgangskoder eller betalingsoplysninger i spil, bør I gøre det hurtigt og konkret, så de kan skifte kode og holde øje med kontoudtog.

Hvordan undgår vi, at det sker igen? Opdateringer, tofaktorgodkendelse, færre administratorer, backup uden for serveren, blokering af PHP i uploadmappen og overvågning af filændringer dækker de fleste af de årsager, Google nævner.

Står I med et hacket site lige nu, så skriv eller ring til os. Vi lukker det ned på den rigtige måde, gemmer beviserne og får det til at køre igen inden for 24 timer.

Kilder

• Google: Rapporten Sikkerhedsproblemer
• Google: Webadresseinspektion
• Google: This site may be hacked
• Google: HTTP-statuskoder og netværksfejl
• Google: Googles crawlere
• web.dev: Quarantine your site
• web.dev: How do I know if my site was hacked
• web.dev: Fix the Japanese keyword hack
• web.dev: Identify the vulnerability
• web.dev: Request a review
• Google Ads: Kompromitterede sider
• Google Transparency Report
• WordPress: FAQ My site was hacked
• WordPress: Hardening WordPress
• WP-CLI: core verify-checksums
• WP-CLI: plugin verify-checksums
• WP-CLI: config shuffle-salts
• WP-CLI: db search
• WP-CLI: option list
• nginx: ngx_http_rewrite_module
• nginx: ngx_http_headers_module
• nginx: location
• nginx: log_format combined
• Apache: mod_rewrite
• PHP: assert
• find(1)
• Datatilsynet: Anmeld sikkerhedsbrud
• Datatilsynet: Håndtering af brud på persondatasikkerheden
• Sikker Digital: Du kan anmelde cyberangreb til politiet