Kort gezegd: Als de website doorverwijst naar vreemde sites, zit de oorzaak in een van zes lagen: DNS, CDN of proxy, webserverconfiguratie, PHP-code, database of ingevoegde scripts. Omdat veel doorverwijzingen alleen onder voorwaarden werken, test u gericht met verschillende identificaties en verwijzende pagina's. Bescherm eerst de bezoekers, stel sporen veilig en sluit na het verwijderen de toegangspoort.
Als klanten op prijsvraagsites belanden
De melding komt meestal van buiten. Een klant schrijft dat hij bij het openen van uw site op een prijsvraag of een twijfelachtige webwinkel is beland. U controleert het op uw eigen computer en alles lijkt normaal. Dat is geen tegenstrijdigheid maar opzet: doorverwijzingen na een hack zijn zo gebouwd dat beheerders ze zo laat mogelijk opmerken.
Voor uw bedrijf is dat netelig. Bezoekers verliezen vertrouwen, zoekmachines en browsers kunnen waarschuwingen tonen en op de doelpagina's wachten soms oplichting of schadelijke software. Een doorverwijzing is bovendien bijna nooit het enige wat een aanvaller achterlaat.
Na PHP2Shell, de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 met code-uitvoering zonder aanmelding, horen doorverwijzingen bij de zichtbare gevolgen die beheerders serieus moeten nemen. Ze zijn geen specifieke PHP2Shell-aanwijzing, want bevestigde Indicators of Compromise bestaan niet. Maar ze tonen wel aan dat iemand inhoud van uw website kon wijzigen.
Vaak komen doorverwijzingen niet alleen. Wie bezoekers doorstuurt, maakt er vaak ook spampagina's voor zoekmachines bij om nog meer verkeer af te romen. Toont Google al een melding over een gehackte website, dan beschrijft de gids Google-waarschuwing verwijderen de route naar de herbeoordeling. Vreemde pagina's in de zoekindex behandelt het artikel SEO-spam en vreemde pagina's in de Google-index.
Waarom de website maar soms doorverwijst
Voorwaardelijke doorverwijzingen beoordelen kenmerken van het verzoek. Vaak zijn dat deze:
- Herkomst: alleen wie via een zoekresultaat komt, wordt doorgestuurd. Directe bezoeken tonen de normale pagina.
- Apparaat: alleen mobiele apparaten of bepaalde browsers zijn getroffen.
- Herhaling: de doorverwijzing werkt één keer per bezoeker, zet daarna een cookie en zwijgt.
- Aanmelding: wie in het CMS is ingelogd, ziet nooit iets.
- Tijd of toeval: de doorverwijzing werkt maar bij een deel van de aanroepen.
Test dus niet alleen op uw eigen werkplek. Met een alleen-lezen opdracht ziet u hoe de server op uiteenlopende aanroepen antwoordt:
# Normale aanroep: statuscode en doel van een mogelijke doorverwijzing
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Aanroep zoals van een mobiel apparaat dat via een zoekopdracht komt
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/
Verschijnt alleen bij de tweede opdracht een vreemd doel, dan zit de doorverwijzing op de server. Blijven beide onopvallend, dan kan ze in de browser via JavaScript plaatsvinden. Dan helpt een blik in de broncode van de uitgeleverde pagina of in de netwerkweergave van de ontwikkelaarstools van de browser, bij voorkeur in een privévenster.
Website stuurt door: de zes lagen controleren
Ga van buiten naar binnen te werk. Zo voorkomt u dat u urenlang in de code zoekt terwijl de oorzaak in een DNS-record zit:
| Laag | Typische oorzaak | Controle |
|---|---|---|
| Domein en DNS | gewijzigd A-record of nameserver | DNS-records vergelijken met de bekende juiste waarden, toegang tot de registrar controleren |
| CDN of proxy | vreemde doorverwijzings- of paginaregel | Regels in het klantenpaneel van de aanbieder doornemen |
| Webserver | regels in .htaccess of serverconfiguratie |
zoeken naar Rewrite- en Redirect-regels met voorwaarden |
| PHP-code | extra code in startbestanden, sjablonen of uitbreidingen | Kernbestanden vergelijken met het origineel |
| Database | gewijzigde adresinstellingen, scripts in inhoud of opties | gericht zoeken naar vreemde adressen en scripts |
| Externe scripts | gecompromitteerde inbedding van een derde partij | ingevoegde scriptbronnen opsommen en beoordelen |
De buitenste lagen worden graag overgeslagen omdat ze niet op de eigen server liggen. Juist daardoor zijn ze gevaarlijk: wie het account bij de registrar of de CDN-aanbieder heeft overgenomen, heeft geen toegang tot de server nodig. Controleer daar naast de regels ook wie toegang heeft en of tweefactorauthenticatie actief is.
Voor de webserverlaag zijn alleen-lezen zoekopdrachten geschikt naar regels die op herkomst of apparaat reageren:
# Doorverwijzingsregels met voorwaarden in alle .htaccess-bestanden
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Doorverwijzingen in de serverconfiguratie (Apache en Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Voor de PHP-laag beschrijft CMS-kernbestanden vergelijken met het origineel de aanpak. Voor de database loont het artikel De database controleren op ingebrachte code.
Als de oorzaak buiten de server ligt
Niet elke doorverwijzing betekent een gecompromitteerde server. Ingevoegde scripts van derden, bijvoorbeeld voor chat, statistiek of reclame, worden rechtstreeks in de browser van de bezoeker uitgevoerd. Wordt zo'n aanbieder gecompromitteerd of verloopt een domein waarvan uw pagina nog een script laadt, dan kan daardoor een doorverwijzing ontstaan zonder dat er op uw server een bestand is gewijzigd.
Een Content Security Policy beperkt uit welke bronnen de browser scripts mag laden en maakt zulke gevallen zichtbaar. Aanwijzingen daarover staan onder Beveiligingsheaders voor websites. Zeer zelden ligt de oorzaak bij de bezoeker zelf: advertentie- of schadelijke software op zijn computer stuurt dan ook op andere websites door.
De juiste volgorde na de vondst
- Bezoekers beschermen: zet de website in de onderhoudsmodus of sluit de getroffen delen af.
- Sporen veiligstellen: kopieer verdachte regels, bestanden en database-inhoud met tijdstempel voordat u ze verwijdert.
- Verwijderen: doorverwijzing wegnemen en kernbestanden vervangen vanuit een schone bron.
- Toegangspoort sluiten: PHP bijwerken naar een verholpen versie, CMS en uitbreidingen updaten, alle workers herstarten, toegangen vernieuwen.
- Natesten: met alle varianten uit de tweede paragraaf opnieuw controleren en de Search Console in de gaten houden.
Een verwijderde doorverwijzingsregel is geen bewijs van een schone website. Komt de regel na dagen terug, dan zit er ergens nog een achterdeur die haar opnieuw schrijft.
Hoe helpt PHP SOS concreet?
- Wij reproduceren de doorverwijzing met verschillende identificaties en verwijzende pagina's en bakenen de laag af.
- Wij stellen sporen veilig en verwijderen doorverwijzingen, schadelijke code en achterdeuren in bestanden, configuratie en database.
- Bij acute besmetting neemt onze noodhulp bij gehackte websites de beheersing over, totdat het incident is afgerond en gedocumenteerd.
- Wij controleren ingevoegde scripts van derden en adviseren een passende Content Security Policy.
Veelgestelde vragen
Waarom zie ik de doorverwijzing zelf niet?
Veel doorverwijzingen werken alleen onder bepaalde voorwaarden: voor bezoekers uit de Google-zoekresultaten, alleen op mobiele apparaten, alleen bij het eerste bezoek of niet voor ingelogde beheerders. Test daarom met verschillende apparaten, zonder in te loggen en via een link uit de zoekresultaten.
Kan een doorverwijzing ook zonder hack ontstaan?
Ja. Een verouderde plug-in, een gecompromitteerd extern script, onjuiste DNS-records of schadelijke software op de computer van de bezoeker kunnen vergelijkbare effecten hebben. Ligt de oorzaak op de eigen computer, dan doet de doorverwijzing zich meestal ook op andere websites voor.
Waar verstoppen aanvallers doorverwijzingen het vaakst?
Typisch zijn regels in .htaccess of de serverconfiguratie, extra code in startbestanden van de applicatie, gewijzigde adresinstellingen in de database en ingebrachte stukjes JavaScript in inhoud of sjablonen.
Wat moet ik direct doen als mijn website doorverwijst?
Bezoekers beschermen, bijvoorbeeld met een onderhoudsmodus, en sporen veiligstellen voordat u iets verwijdert. Zoek daarna laag voor laag naar de oorzaak en sluit de toegangspoort. Een verwijderde regel zonder dat de kwetsbaarheid is gedicht, komt meestal terug.