WordPress-website stuurt door naar een andere site: de doorverwijzing vinden

Waarom u de doorverwijzing zelf niet ziet

Een doorverwijzing die bij een hack is geplaatst, kiest voor wie ze geldt. Meestal spaart ze de persoon die de site beheert, zodat ze zo lang mogelijk blijft zitten. De meest voorkomende voorwaarden:

• De herkomst: alleen bezoekers die via een zoekmachine of een sociaal netwerk binnenkomen, worden doorgestuurd. De code leest de header Referer van het verzoek.
• Het apparaat: alleen telefoons worden doorgestuurd. De code leest de header User-Agent.
• De aanmelding: een beheerder die bij WordPress is ingelogd, ziet de normale site.
• Het eerste bezoek: een cookie onthoudt dat de bezoeker al is doorgestuurd, en het volgende bezoek verloopt normaal. De storing lijkt dan met tussenpozen op te treden.

Een klant die schrijft “uw site stuurt me ergens anders heen”, neemt u dus serieus, ook als bij u alles correct wordt weergegeven.

De doorverwijzing nabootsen

Verplaats u in de bezoeker die ermee te maken krijgt:

1. Open een privévenster, zoek de naam van uw bedrijf in een zoekmachine en klik op uw eigen resultaat.
2. Doe hetzelfde vanaf een telefoon, op mobiele data in plaats van wifi.
3. Noteer het bestemmingsadres, het tijdstip en het apparaat: deze drie gegevens dienen uw hostingprovider en later de aanvraag voor een beoordeling bij Google.

Hebt u toegang tot een terminal, dan vraagt deze opdracht uw homepage op en doet zich daarbij voor als een iPhone die van Google komt:

curl -s -i -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://www.uw-site.com/

Lees de eerste regels van het antwoord. Een code 301 of 302 gevolgd door een regel Location: naar een onbekend adres wijst op een doorverwijzing door de server: die zit in .htaccess of in een PHP-bestand. Een code 200 terwijl de browser wel wordt doorgestuurd, wijst op een doorverwijzing in de pagina, in JavaScript: die zit meestal in de database of in een bestand van het thema.

Voordat u de site aanraakt: drie stappen

1. Een volledige kopie, zoals hij is. Bestanden en database, gedateerd, buiten de server bewaard. Ze dient als bewijs, als vergelijkingspunt, en als vangnet als het opschonen iets nuttigs weghaalt.
2. De wachtwoorden, vanaf een schoon apparaat. Klantenaccount bij de hostingprovider, FTP- of SFTP-accounts, databasegebruiker (zet het nieuwe wachtwoord in wp-config.php, constante DB_PASSWORD), en daarna elk WordPress-beheerdersaccount.
3. De beveiligingssleutels. Vervang de acht regels van AUTH_KEY tot NONCE_SALT in wp-config.php door een nieuwe set, gegenereerd op https://api.wordpress.org/secret-key/1.1/salt/. Alle open sessies worden afgesloten, ook die van de indringer.

wp config shuffle-salts

Waar de doorverwijzing zich verbergt

1. Het bestand .htaccess

In de root van de site, en soms in een submap, kan .htaccess herschrijfregels bevatten die de indringer heeft toegevoegd. Het blok dat WordPress zelf schrijft, is kort en staat tussen # BEGIN WordPress en # END WordPress:

# BEGIN WordPress
# De richtlijnen (regels) tussen "BEGIN WordPress" en "END WordPress" worden
# dynamisch gegenereerd en zouden alleen aangepast mogen worden via WordPress filters.
# Alle wijzigingen aan de richtlijnen tussen deze markeringen worden overschreven.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Een regel RewriteCond die %{HTTP_REFERER} (google, bing, facebook) of %{HTTP_USER_AGENT} (android, iphone, mobile) test, gevolgd door een RewriteRule naar een extern adres, is de doorverwijzing. Cache- en beveiligingsplugins schrijven ook eigen blokken, gemarkeerd met hun naam: leg elk blok naast de lijst van uw plugins voordat u het verwijdert.

2. De PHP-bestanden

WP-CLI vergelijkt de bestanden van de WordPress-kern en van de plugins met de controlesommen die WordPress.org publiceert, en toont elk gewijzigd of toegevoegd bestand:

wp core verify-checksums
wp plugin verify-checksums --all

De tweede opdracht dekt de plugins die via de repository van WordPress.org worden verspreid. Een plugin die u bij de maker hebt gekocht, vergelijkt u met een verse kopie uit uw account bij die maker. Dat komt vaak voor: van de 540 WordPress-websites van mkb-bedrijven in onze meting van 1 september 2026 draagt 66 % minstens één plugin die niet in de publieke repository staat.

Zonder WP-CLI geven twee zoekopdrachten een eerste selectie:

find . -name "*.php" -mtime -30
find wp-content/uploads -name "*.php"

De eerste toont de PHP-bestanden die de afgelopen 30 dagen zijn gewijzigd, de tweede de PHP-bestanden in de mediamap, waar ze standaard verdacht zijn (sommige plugins zetten er een lege index.php, en die is legitiem). Een wijzigingsdatum is te vervalsen: een oud bestand op de verkeerde plek blijft het bekijken waard.

Open eerst wp-config.php, de index.php in de root, de functions.php en de header.php van het actieve thema, en de map wp-content/mu-plugins: de plugins daarin worden automatisch geladen en zijn niet vanuit het dashboard uit te schakelen. De signalen om naar te zoeken: eval(, base64_decode(, gzinflate(, str_rot13(, lange onleesbare tekenreeksen, of window.location gevolgd door een adres dat u niet kent.

3. De database

Een doorverwijzing in JavaScript nestelt zich graag in de inhoud van pagina’s of in de instellingen, waar geen enkel bestand haar laat zien. WP-CLI zoekt een tekenreeks in alle tabellen van WordPress:

wp db search "<script"
wp db search "fromCharCode"

Zonder WP-CLI voert u dezelfde zoekopdrachten uit in phpMyAdmin, tabblad SQL:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

Sommige resultaten zijn legitiem: een tool voor bezoekersstatistieken, een cookiebanner of een widget die u zelf hebt geplaatst. Wat met niets overeenkomt dat u hebt geïnstalleerd, verdient een nadere blik, vooral een script dat een adres opbouwt uit tekencodes.

4. De adresinstellingen en de accounts

Onder Instellingen > Algemeen moeten “WordPress adres (URL)” en “Site adres (URL)” uw eigen domein tonen. Dezelfde waarden kunnen in wp-config.php worden afgedwongen met de constanten WP_HOME en WP_SITEURL: controleer beide plaatsen.

wp option get home
wp option get siteurl
wp user list --role=administrator

Zijn de constanten gedefinieerd, dan geven de eerste twee opdrachten hun waarde terug. De laatste toont de beheerders met hun registratiedatum; in het dashboard vindt u dezelfde lijst in het menu Gebruikers, gefilterd op de rol Beheerder. Een account dat niemand herkent, verwijdert u, waarbij u de inhoud ervan aan een legitiem account toewijst.

De doorverwijzing verwijderen, en daarna de toegang

De regel die doorstuurt verwijderen, stopt het symptoom. De toegang die de indringer gebruikte, blijft open zolang ze niet is gevonden, en de doorverwijzing komt binnen enkele dagen terug. De volgorde die standhoudt:

1. Vervang de kernbestanden door een verse kopie: verwijder de mappen wp-admin en wp-includes en voer daarna wp core download --skip-content --force uit, dat de kern opnieuw schrijft zonder uw plugins, thema’s en media aan te raken. De opdracht overschrijft bestaande bestanden maar verwijdert geen toegevoegde bestanden: daarom gaan de twee mappen eerst weg, en daarom verwijdert u onbekende PHP-bestanden in de root met de hand.
2. Installeer het thema en elke plugin opnieuw vanuit hun officiële bron, en verwijder wat de site niet meer gebruikt, ook wat gedeactiveerd is: die bestanden staan nog op de server.
3. Verwijder vreemde PHP-bestanden uit wp-content/uploads, de regels die aan .htaccess zijn toegevoegd en de scripts die in de database zijn gevonden.
4. Controleer de geplande taken met wp cron event list: een taak met een onbekende naam kan de code terugzetten.
5. Werk WordPress, het thema en de plugins bij.
6. Herhaal de tests van het begin, vanaf meerdere apparaten en gedurende meerdere dagen.

Bewaart de site persoonsgegevens (formulieren, klantaccounts, bestellingen), noteer dan het tijdstip waarop u de hack hebt vastgesteld. In de Europese Unie schrijft de AVG voor dat een inbreuk in verband met persoonsgegevens uiterlijk 72 uur nadat u er kennis van hebt genomen aan de toezichthoudende autoriteit wordt gemeld, tenzij het niet waarschijnlijk is dat de inbreuk een risico inhoudt voor de rechten en vrijheden van natuurlijke personen.

Google, en wat uw bezoekers zien

Zodra Google de doorverwijzing opmerkt, kan Chrome een rode pagina “Gevaarlijke site” tonen voordat de site opent, en kan Google onder uw resultaat “Deze site is mogelijk gehackt” zetten. Het rapport Beveiligingsproblemen in Google Search Console laat zien wat is gevonden en op welke adressen. Is de site opgeschoond, dan start de knop Beoordeling aanvragen de controle.