Siden sender besøkende til spam

Når besøkende blir sendt videre til en spamside, ligger det skadelig kode på nettsiden din. Koden er laget for å skjule seg. Den leser Referer og User-Agent i forespørselen og sender bare videre besøkende som kommer fra Google eller bruker mobil. Er du logget inn, eller skriver du inn adressen selv, får du den vanlige siden. Derfor ser alt normalt ut når du sjekker.

Videresendingen kan ligge i .htaccess, i en PHP-fil eller som et skript i databasen. Gå gjennom stedene under i rekkefølge.

Se det de besøkende ser

1. Åpne et inkognitovindu på mobilen, søk opp firmanavnet ditt i Google og trykk på treffet. Gjør det samme på PC-en.
2. Har du Search Console, limer du inn adressen i søkefeltet øverst og kjører en live-test. Skjermbildet fra testen viser hva Google får se. Ser du en annen side enn din egen, er videresendingen bekreftet.
3. Noter domenet du blir sendt til. Du trenger det når du skal søke i filene og databasen.

Med curl kan du etterligne en mobilbesøkende som kommer fra Google:

curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://dittdomene.no/

Viser svaret statuskode 301 eller 302 og en Location-linje til et annet domene, skjer videresendingen på serveren. En videresending i JavaScript ser du ikke i svarhodene, bare i HTML-koden.

Skann også siden med Sucuri SiteCheck. Den ser etter kjent skadelig kode og sjekker om domenet står på svartelister. Har Google merket siden som farlig, ser du det i Google Safe Browsing.

Sjekk wp-admin

1. Gå til Innstillinger → Generelt. Både «WordPress-adresse (URL)» og «Nettstedsadresse (URL)» skal være ditt eget domene.
2. Se under Brukere etter administratorer du ikke kjenner igjen.
3. Under Utvidelser ser du etter utvidelser du ikke har installert selv. Se også etter fanen «Obligatoriske». Den viser filer i wp-content/mu-plugins, som kjører uten å være aktivert.
4. Bruker du en utvidelse som setter inn kode i <head> eller før </body>, for eksempel WPCode, går du gjennom kodesnuttene der og ser etter skript fra domener du ikke kjenner.

Sjekk .htaccess

Koble til med FTP eller filbehandleren i hostingpanelet, og slå på visning av skjulte filer. I .htaccess i rotmappen ser standardreglene fra WordPress slik ut, med noen kommentarlinjer i tillegg:

# BEGIN WordPress
<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

Cache- og sikkerhetsutvidelser kan legge inn egne regler, merket med navnet på utvidelsen. Se nøye på linjer med HTTP_REFERER eller HTTP_USER_AGENT, og på regler som sender besøkende til et annet domene. Sjekk også .htaccess i undermapper som wp-content og wp-content/uploads.

Sjekk PHP-filene

• index.php i rotmappen er bare noen få linjer som laster wp-blog-header.php. Er den lang eller full av uleselig kode, er den endret.
• Se øverst i wp-config.php etter kode som ikke hører hjemme der, for eksempel include eller require av filer med ukjente navn.
• Med innstillingen auto_prepend_file kjører PHP en fil før hver side. Den kan stå i .user.ini eller php.ini i rotmappen, eller som php_value auto_prepend_file i .htaccess. Wordfence bruker den til brannmuren sin, og da står wordfence-waf.php der. Alle andre filnavn der må du se nærmere på.
• Les gjennom functions.php og header.php i det aktive temaet.

I alle disse filene leter du etter eval, base64_decode, gzinflate og str_rot13, særlig når de står sammen med lange rekker av tilfeldige tegn.

Har du SSH og WP-CLI, sammenligner wp core verify-checksums WordPress-filene med originalene fra wordpress.org. wp plugin verify-checksums --all gjør det samme for utvidelser fra wordpress.org. Begge lister opp filer som er endret eller lagt til.

Søk i databasen

1. Eksporter databasen før du endrer noe.
2. Åpne phpMyAdmin fra hostingpanelet og søk i hele databasen etter domenet du ble sendt til, og etter <script.
3. Se spesielt på treff i tabellene wp_options og wp_posts. Tabellnavnene kan begynne med noe annet enn wp_.

Ikke slett rader du ikke forstår. Fjern bare koden angriperen har lagt inn.

Vær ekstra forsiktig med verdier i wp_options som begynner med a:, med tall som s:12: foran hver tekst. Tallet er antall byte i teksten, og æ, ø og å teller som to. Innstillingen slutter å virke hvis du endrer teksten uten å rette tallet. Slike verdier bør du heller endre i wp-admin hvis du kan.

Når det ikke hjelper å fjerne koden

Hvis videresendingen kommer tilbake etter at du har fjernet koden, ligger det enten en bakdør et annet sted, eller så er sikkerhetshullet angriperen brukte, fortsatt åpent. Det kan også være begge deler. Da må hele siden ryddes, og noen må gå gjennom serverloggene for å finne ut hvordan angriperen kom inn. Hvis du ikke finner noe i WordPress, kan videresendingen ligge i serveroppsettet. Da må hostingleverandøren sjekke serveroppsettet.