Kort sagt: Når websitet omdirigerer til fremmede sider, ligger årsagen i et af seks lag: DNS, CDN eller proxy, webserverkonfigurationen, PHP-koden, databasen eller indbundne scripts. Fordi mange omdirigeringer kun virker under betingelser, bør I teste målrettet med forskellige kendetegn og henvisende sider. Beskyt først de besøgende, sikr spor, og luk indgangen, når omdirigeringen er fjernet.
Når kunder havner på konkurrencesider
Meldingen kommer som regel udefra. En kunde skriver, at han ved besøg på jeres side endte på en konkurrence eller en tvivlsom shop. I kontrollerer det på jeres egen computer, og alt ser normalt ud. Det er ikke en modsigelse, men hensigten: Omdirigeringer efter et hack er bygget, så de driftsansvarlige opdager dem så sent som muligt.
For jeres virksomhed er det følsomt. Besøgende mister tillid, søgemaskiner og browsere kan vise advarsler, og på målsiderne venter til tider svindel eller skadelig software. En omdirigering er desuden næsten aldrig det eneste, en angriber efterlader.
Efter PHP2Shell, sårbarhederne CVE-2026-109618 og CVE-2026-109619 med kodeudførelse uden login, hører omdirigeringer til de synlige følger, som driftsansvarlige bør tage alvorligt. De er ikke et specifikt PHP2Shell-tegn, for der findes ingen bekræftede indicators of compromise. Men de viser, at nogen har kunnet ændre indhold på jeres website.
Omdirigeringer kommer ofte ikke alene. Den, der omdirigerer besøgende, opretter tit også spamsider til søgemaskiner for at fange endnu mere trafik. Viser Google allerede en meddelelse om et hacket website, beskriver vejledningen Fjern Google-advarslen vejen til en fornyet gennemgang. Fremmede sider i søgeindekset behandler indlægget SEO-spam og fremmede sider i Googles indeks.
Hvorfor websitet kun nogle gange omdirigerer
Betingede omdirigeringer vurderer forespørgslens kendetegn. Ofte er det disse:
- Henvisning: Kun den, der kommer via et søgeresultat, bliver omdirigeret. Direkte kald viser den normale side.
- Enhed: Kun mobile enheder eller bestemte browsere er berørt.
- Gentagelse: Omdirigeringen virker én gang pr. besøgende, derefter sætter den en cookie og tier.
- Login: Den, der er logget ind i CMS'et, ser aldrig noget.
- Tid eller tilfældighed: Omdirigeringen virker kun ved en del af kaldene.
Test derfor ikke kun ved arbejdspladsen. Med en læsende forespørgsel ser I, hvordan serveren svarer på forskellige kald:
# Normalt kald: statuskode og mål for en mulig viderestilling
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Kald som fra en mobil enhed, der kommer via en søgning
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
-A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
-e "https://www.google.com/" https://www.ihre-domain.de/
Dukker der kun ved den anden forespørgsel et fremmed mål op, sidder omdirigeringen på serveren. Er begge upåfaldende, kan den ske i browseren via JavaScript. Så hjælper et kig i kildeteksten til den leverede side eller i netværksvisningen i browserens udviklerværktøjer, helst i et privat vindue.
Website omdirigerer: Kontrollér de seks lag
Gå fra yderst til inderst. Så undgår I at lede i timevis i koden, mens årsagen ligger i en DNS-post:
| Lag | Typisk årsag | Kontrol |
|---|---|---|
| Domæne og DNS | ændret A-post eller navneserver | sammenlign DNS-poster med den kendte målstilstand, kontrollér adgangen hos registrator |
| CDN eller proxy | fremmed viderestillings- eller sideregel | gennemgå reglerne i udbyderens kundeområde |
| Webserver | regler i .htaccess eller serverkonfigurationen |
led efter Rewrite- og Redirect-regler med betingelser |
| PHP-kode | ekstra kode i indgangsfiler, skabeloner eller udvidelser | sammenlign kernefiler med originalen |
| Database | ændrede adresseindstillinger, scripts i indhold eller indstillinger | led målrettet efter fremmede adresser og scripts |
| Eksterne scripts | kompromitteret indlejring fra tredjepart | opregn og vurdér indbundne scriptkilder |
De ydre lag springes gerne over, fordi de ikke ligger på jeres egen server. Netop derfor er de farlige: Den, der har overtaget kontoen hos registrator eller CDN-udbyderen, har ikke brug for adgang til serveren. Kontrollér dér ud over reglerne, hvem der har adgang, og om tofaktorlogin er aktivt.
Til webserverlaget egner sig læsende søgninger efter regler, der reagerer på henvisning eller enhed:
# Viderestillingsregler med betingelser i alle .htaccess-filer
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Viderestillinger i serverkonfigurationen (Apache og Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Til PHP-laget beskriver Sammenlign CMS-kernefiler med originalen fremgangsmåden. Til databasen er indlægget Kontrollér databasen for indsmuglet kode umagen værd.
Når årsagen ligger uden for serveren
Ikke enhver omdirigering betyder en kompromitteret server. Indbundne scripts fra tredjeparter, f.eks. til chat, statistik eller reklamer, udføres direkte i de besøgendes browser. Kompromitteres sådan en udbyder, eller udløber et domæne, som jeres side stadig indlæser et script fra, kan der opstå en omdirigering, uden at en fil på jeres server er ændret.
En Content Security Policy begrænser, fra hvilke kilder browseren må indlæse scripts, og gør sådanne tilfælde synlige. Oplysninger herom findes under Sikkerhedsheadere til websites. Meget sjældent ligger årsagen hos den besøgende selv: Reklame- eller skadelig software på hans computer omdirigerer så også på andre websites.
Den rigtige rækkefølge efter fundet
- Beskyt de besøgende: Sæt websitet i vedligeholdelsestilstand, eller spær de berørte områder.
- Sikr spor: Kopiér mistænkelige regler, filer og databaseindhold med tidsstempel, før I fjerner dem.
- Fjern: Fjern omdirigeringen, og erstat kernefiler fra en ren kilde.
- Luk indgangen: Bring PHP op på en rettet version, opdatér CMS og udvidelser, genstart alle workers, forny adgange.
- Test igen: Kontrollér påny med alle varianter fra det andet afsnit, og hold Search Console under opsyn.
En fjernet viderestillingsregel er ikke noget bevis for et rent website. Kommer reglen tilbage efter nogle dage, sidder der stadig en bagdør et sted, som skriver den påny.
Hvordan hjælper PHP SOS konkret?
- Vi gengiver omdirigeringen med forskellige kendetegn og henvisende sider og afgrænser laget.
- Vi sikrer spor og fjerner omdirigeringer, skadelig kode og bagdøre i filer, konfiguration og database.
- Ved akut angreb overtager vores nødhjælp ved hackede websites inddæmningen, til hændelsen er afsluttet og dokumenteret.
- Vi kontrollerer indbundne tredjepartsscripts og anbefaler en passende Content Security Policy.
Ofte stillede spørgsmål
Hvorfor ser jeg ikke selv omdirigeringen?
Mange omdirigeringer virker kun under bestemte betingelser: for besøgende fra Google-søgning, kun på mobile enheder, kun ved første besøg eller ikke for loggede ind administratorer. Test derfor med forskellige enheder, uden login og via et link fra et søgeresultat.
Kan en omdirigering opstå uden et hack?
Ja. Et udløbet plugin, et kompromitteret eksternt script, forkerte DNS-poster eller skadelig software på den besøgendes computer kan give lignende effekter. Ligger årsagen på den egen computer, optræder omdirigeringen som regel også på andre websites.
Hvor skjuler angribere oftest omdirigeringer?
Typisk er det regler i .htaccess eller serverkonfigurationen, ekstra kode i applikationens indgangsfiler, ændrede adresseindstillinger i databasen og indsmuglede JavaScript-stumper i indhold eller skabeloner.
Hvad bør jeg gøre med det samme, hvis mit website omdirigerer?
Beskyt de besøgende, f.eks. med en vedligeholdelsestilstand, og sikr spor, før I sletter noget. Led derefter efter årsagen lag for lag, og luk indgangen. En fjernet regel uden en lukket sårbarhed kommer som regel tilbage.