Japansk nøkkelord-hack: derfor overså sikkerhetspluginen den

#Skanneren lyver ikke til deg, den blir løyet til

29. juli 2026 publiserte Joe Youngblood en advarsel om at det japanske nøkkelord-hacket sprer seg raskt gjennom WordPress-sider, og med hans egne ord “easily defeating WordFence, Securi, and Malcare along with other security methods / plugins.”

Den siste delen er den interessante, og det er ikke en svikt hos de produktene slik det ser ut. Grunnen til at en skanning kommer tilbake ren, er at nyttelasten ikke er der når skanneren spør etter den.

Det injiserte innholdet serveres betinget. Nettstedet har et web shell, og skallet avgjør ved hver forespørsel om det skal injisere. Ser forespørselen ut som en nettleser, får den den vanlige siden din. Ser den ut som Googlebot, får den en side full av japanske netthandelsord med lenker til forfalskede varer. Sikkerhetspluginen din henter siden som seg selv, får den vanlige versjonen og melder ingenting.

Derfor dukker det første symptomet nesten aldri opp på nettstedet. Det dukker opp i Search Console, i et Google-resultat på ditt eget merkenavn, eller i et trafikkfall ingen klarer å forklare.

#Bevis det med én kommando før du rører noe

Før du begynner å slette filer, må du slå fast hva du faktisk står overfor. Hent samme URL to ganger fra et skall:

curl -s https://example.com/some-page/ > browser.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/some-page/ > crawler.html
diff browser.html crawler.html

Hvis de to er ulike, og robotversjonen bærer lenker eller nøkkelord som nettleserversjonen ikke har, har du cloaking og diagnosen er ferdig. Ingen plugin-skanning, ingen gjetning.

Gjør det samme med sitemapet. Et hyppig følgesymptom er at Search Console melder at sitemapet “ser ut til å være en HTML-side” mens sitemapet lastes helt normalt i nettleseren din. Det er samme mekanisme: noe fanger opp sitemap-ruten og serverer roboten noe annet.

To steder til å se, begge utenfor nettstedet:

• Search Console, sikkerhetsproblemer. Har Google klassifisert nettstedet, navngir rapporten mønsteret og rommer forespørselen om ny vurdering som du trenger senere.
• Search Console, ytelse, filtrert på søk du ikke kjenner igjen. Japanske netthandelsord på en norsk eller tysk side er ikke tvetydig.

#Hva hvert verktøy kan og ikke kan se

Det er verdt å være presis på hvorfor skannerne kommer tilbake rene, for “pluginen sviktet” får folk til å kjøpe en annen plugin i stedet for å bytte metode.

Mønsteret i den tabellen er hele poenget. Alle metoder som inspiserer filer, svarer på “ligger det noe i filsystemet”, og alle metoder som inspiserer atferd, svarer på “lyver dette nettstedet til roboter akkurat nå”. Du trenger begge, og bare den ene selges som et produkt.

#Oppdage det tidlig, og oppdage tilbakefall

Gapet mellom infeksjon og oppdagelse er der SEO-skaden skjer. Tre signaler kommer før trafikkfallet.

Visninger på søk som ikke gir mening for virksomheten din. Search Console, ytelse, sorter på visninger, se etter alt som står i et skriftsystem du ikke publiserer i. Dette er som regel det tidligste signalet du har tilgang til, og det koster ett minutt i uka.

En side som plutselig skyter i været. I den pågående bølgen får den første injiserte siden ofte et brått hopp i visninger før resten følger etter. En side du ikke har rørt på et år som plutselig presterer, er verdt tretti sekunders nysgjerrighet.

Favikonet i resultatene som endrer seg. Youngblood påpeker at denne bølgen bærer et karakteristisk favikon, synlig i Search Console. Et favikon du ikke har satt, er en fil du ikke har skrevet.

Når du har ryddet opp, fungerer den samme to-hentingstesten som en brukbar overvåkning av tilbakefall. Den kjøres fra hvilken som helst maskin med curl, ikke fra nettstedet selv, og det er poenget: et kompromittert nettsted er en dårlig dommer over sin egen tilstand.

#!/usr/bin/env bash
# cloaking-watch.sh - varsler hvis robotvisningen avviker fra nettleservisningen
URL="https://example.com/"
UA_BOT="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

a=$(curl -s --max-time 20 "$URL" | md5sum | cut -d' ' -f1)
b=$(curl -s --max-time 20 -A "$UA_BOT" "$URL" | md5sum | cut -d' ' -f1)

if [ "$a" != "$b" ]; then
  echo "DIVERGENCE on $URL at $(date -u +%FT%TZ)"
  exit 1
fi

To forbehold før du legger dette i cron. Sider med roterende innhold, A/B-tester eller personaliserte blokker vil avvike helt legitimt, så pek den mot en stabil side, for eksempel et tidløst innlegg eller sitemapet. Og et målrettet skall kan avlese mer enn user agent, blant annet IP-området forespørselen kommer fra, så et rent resultat her er indisium og ikke bevis. Den fanger likevel det vanlige tilfellet, og den fanger det innen et døgn i stedet for innen et kvartal.

#Skille det fra de andre spamvariantene

Tre infeksjoner blir kalt “SEO-spam”, og de krever ulike første trekk, så det er verdt å bruke et minutt på å avgjøre hvilken du har.

Pharma-spam legger legemiddelord inn i innleggstitler, utdrag og innhold. Den bor i databasen, den er synlig for vanlige besøkende, og du finner den ved å søke i wp_posts og wp_options etter ordene Google viser. Finner en SELECT ordene, står du i dette tilfellet og ikke i det japanske.

Kasino- og bettingspam ligger mellom de to. Den driver ofte cloaking slik den japanske varianten gjør, men den kommer gjerne med injiserte hreflang-blokker og oppdiktede språkversjoner av sidene dine, fordi operatørene vil ha flere markeder på én gang. Viser robotvisningen lenker til språkversjoner du aldri har laget, er det der du skal lete.

Det japanske nøkkelord-hacket lar databasen være i fred. Nyttelasten ligger i filer, den gjengis ved forespørselstidspunkt, og bare for roboter. Nettopp den kombinasjonen slår ut både databasesøket og plugin-skanningen.

Det finnes også en variant som bare omdirigerer på mobil, og den slår inn på user agent på samme måte som denne, bortsett fra at den ser etter telefoner i stedet for Googlebot. Melder besøkende at de blir sendt til et annet nettsted, mens dine egne tester på desktop stadig kommer tilbake rene, gjenta to-hentingstesten med en mobil user agent-streng i stedet for Googlebot. Mekanismen er identisk, det er bare betingelsen som er en annen.

#Verifiser filer deterministisk, se så på datoene

Youngbloods gjennomgang foreslår å søke gjennom filsystemet etter base64 og be en AI-modell vurdere listen. Det virker, men det er steg to og ikke steg én, for det ber en modell gjette hvilke filer som hører til WordPress. WordPress vet det allerede:

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

Dette sammenligner hver kjerne- og pluginfil mot de offisielle sjekksummene fra WordPress.org og navngir alt som er endret eller lagt til. Det er deterministisk, det tar sekunder, og det gir en mye kortere liste å resonnere rundt enn en base64-grep gjennom hele treet.

Det sjekksummene ikke kan verifisere: temaet ditt, alt som er premium, wp-content/uploads og mu-plugins. Det er der den manuelle runden hører hjemme:

grep -rl --include="*.php" -E "base64_decode|eval\(|gzinflate|str_rot13" wp-content/ | head -50
find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins/

En PHP-fil inne i uploads har ingen legitim grunn til å finnes. Det har heller ikke en mu-plugins-fil du ikke har skrevet, og den mappen fortjener særlig oppmerksomhet fordi den lastes automatisk og aldri dukker opp i pluginlisten.

Sorter deretter det du fant etter endringstidspunkt. Hovedtyngden av injiserte filer deler som regel ett tidsstempel, og det er øyeblikket for det synlige angrepet. Unntaket er det Youngblood kaller seed-filen: én enkelt fil plantet uker, måneder eller av og til år tidligere, med et tidsstempel som ikke matcher noe annet. Renser du alt bortsett fra seed-filen, kommer infeksjonen tilbake, og den kommer tilbake stille.

Den praktiske testen på om du fikk den: legg tilbake en ren index.php, vent to minutter, og les filen på nytt. Har den endret seg tilbake, er det fortsatt noe som kjører og skriver den om, og da er du ikke ferdig.

#Rekkefølgen som betyr noe

Rekkefølgen i oppryddingen er der gjenopprettinger går galt, og sekvensen er ikke intuitiv.

Kopier før du renser. Ta en full filkopi og en databaseeksport av den kompromitterte tilstanden først. Å legge en sikkerhetskopi rett over ødelegger det eneste beviset på hvordan inngangen skjedde, og er sikkerhetskopien selv allerede infisert, har du ingenting igjen å sammenligne mot.

Og her er retensjonstiden det virkelige problemet i Norden. Hos de fleste norske leverandørene, Domeneshop og PRO ISP inkludert, ligger den automatiske sikkerhetskopien noen få uker tilbake, ikke måneder. En seed-fil kan være eldre enn hele det vinduet. Det mønsteret går igjen i denne typen opprydding: den eldste kopien leverandøren har ligger noen uker tilbake, seed-filen er eldre enn det, og “rull tilbake til før angrepet” er aldri et reelt alternativ. Sjekk hvor langt tilbake du faktisk kan gå før du planlegger rundt en gjenoppretting, og behandle “legg tilbake forrige måneds kopi” som en antakelse og ikke en løsning.

Rens, roter så nøkler, ta så søk. I den rekkefølgen. Å bytte legitimasjon før skallet er borte er bare å levere fra seg de nye.

Roter mer enn passord. Dette er steget nesten alle guider stopper foran:

• Applikasjonspassord, i hver brukerprofil under Brukere, overlever et passordbytte og beholder full tilgang til REST-API-et. De er per bruker, de er enkle å opprette programmatisk når en angriper først har admin, og de fleste vet ikke at funksjonen finnes. List dem opp og slett dem.
• Delegerte eiere i Search Console, under Innstillinger, brukere og tillatelser, lever helt utenfor nettstedet ditt. Ingenting du gjør i WordPress fjerner dem. Sjekk eierskapsverifiseringen også, etter løse HTML-filer eller DNS TXT-oppføringer.
• Database- og FTP- eller SSH-legitimasjon, for var inngangen credential stuffing mot wp-admin, er alt annet som delte det passordet også eksponert.

Så søk. Generer sitemapet på nytt, bekreft med en live URL-inspeksjon i Search Console at Googlebot nå får den ekte siden, og be om ny vurdering i rapporten for sikkerhetsproblemer. Å sende inn sitemapet på nytt fjerner ikke en manuell straff, det gjør vurderingsforespørselen.

#To råd fra standardoppskriften det er verdt å diskutere

Advarselen som utløste denne artikkelen er god feltrapportering, og to av anbefalingene fortjener motstand.

“Immediately request to remove your full website via Search Console.” Dette er et tyngre virkemiddel enn situasjonen vanligvis krever. Fjerningsverktøyet skjuler URL-er fra resultatene i omtrent seks måneder, det endrer ingenting ved infeksjonen og ingenting ved hvordan Google til slutt vurderer nettstedet på nytt. Å fjerne de injiserte URL-mønstrene med en prefiksfjerning står i forhold til problemet. Å fjerne hele nettstedet fjerner også sidene som fortsatt gir henvendelser, og hver eneste av dem må tilbake gjennom en kansellering og en ny gjennomsøking du ikke styrer. Grip til hele nettstedet når de injiserte sidene reelt er flere enn de ekte, ikke som steg én.

“Find any excuse imaginable to run a press release to drive fresh interest from Googlebot.” Ny gjennomsøking drives av ting du faktisk kan påvirke: korrekte lastmod-verdier i sitemapet, interne lenker fra sider som gjennomsøkes ofte, og forespørsler om URL-inspeksjon på sidene som betyr noe. En pressemelding er en dyr måte å kjøpe noen robotbesøk på.

Resten av den gjennomgangen, særlig observasjonen om at seed-filen har et unikt tidsstempel og advarselen om å sjekke index.php på nytt etter å ha lagt den tilbake, stemmer med hvordan disse oppryddingene ser ut i praksis.

#Lukke døra angrepet faktisk brukte

Den rapporterte inngangskjeden i denne bølgen er konkret: credential stuffing mot wp-admin med lekkede e-post- og passordlister, deretter installasjon av en plugin for å få tilgang til filsystemet, deretter opplasting av én enkelt nyttelastfil. Hvert av de stegene har en kontroll som stopper det.

Tofaktorautentisering på hver administrator. Credential stuffing virker fordi passordet allerede er kjent. Tofaktor gjør et riktig passord utilstrekkelig, og det er hele angrepet.

DISALLOW_FILE_MODS. I wp-config.php:

define( 'DISALLOW_FILE_MODS', true );

Dette blokkerer installasjon av plugins og temaer fra kontrollpanelet fullstendig. I den rapporterte kjeden er det steg to. En angriper med en gyldig admin-økt kan ikke installere filbehandlerpluginen som gir dem filsystemet. Avveiingen er reell og du bør kjenne den: automatiske oppdateringer stopper også, så oppdateringer går da via WP-CLI eller en utrullingspipeline. På et nettsted som rulles ut fra et repository er det uansett slik det bør fungere.

Ingen PHP-kjøring i uploads. På webserveren, ikke i en plugin. Dette gjør den vanligste veien mindre verdt, fra “angriperen lastet opp en fil” til “angriperen kjører kode”.

Færre administratorer. Byråansatte, en utvikler som hjalp til én gang, en supportkonsulent fra to år tilbake. Hver av dem er legitimasjon som kan stuffes. Nedgrader alt som ikke trenger rollen.

Følg med i Search Console i stedet for kontrollpanelet. Kontrollpanelet er der dette angrepet er usynlig av design. En ukentlig titt på ytelsesrapporten etter søk du ikke kjenner igjen fanger det tidligere enn noen skanning gjør.

#Hva du skal si til kunden eller sjefen

Rydder du dette for noen andre, er det vanskelige i samtalen ikke det tekniske, det handler om tid. Oppryddingen tar timer, gjenopprettingen tar uker, og de to smelter lett sammen til én forventning: fiks det i kveld, så er trafikken tilbake i morgen. Det blir den ikke, for Google må besøke sider den allerede har klassifisert som spam på nytt, og køen avhenger av hvor ofte nettstedet ble gjennomsøkt fra før.

Det andre som er verdt å si rett ut: du kan ikke svare ærlig på “ble kundedata hentet ut” når serverloggene bare oppbevares i sju dager og seed-filen er fra februar. Svaret er “vi vet ikke, og vi kommer ikke til å finne det ut”, og det er informasjon snarere enn en unnvikelse. På en nettbutikk som håndterer personopplysninger har det gapet betydning for om plikten til å varsle Datatilsynet utløses, så det hører hjemme på bordet med en gang og ikke en uke senere.

Det tredje: kostnaden ved denne infeksjonen er sjelden selve oppryddingen. Det er trafikken som ikke kom i de ukene, og det tallet er verdt å regne på sammen, ut fra data fra tiden før infeksjonen, i stedet for å la det bli en vag følelse av at noe dippet.

#Hvis du står midt oppi et akkurat nå

Kortversjonen: bevis cloakingen med to-hentingstesten, verifiser kjerne og plugins med sjekksummer, jakt seed-filen på tidsstempel, kopier alt før du legger tilbake noe, og husk at applikasjonspassord og delegerte eiere i Search Console overlever passordbyttet du er i ferd med å gjøre.

Vi kjører denne sekvensen som del av en WordPress sikkerhetsrevisjon, og den bredere oppryddingsprosessen, inkludert databasearbeid og logggjennomgang, står i vår guide til å rense en hacket WordPress-side.

Sist oppdatert: 30. juli 2026, etter at den pågående bølgen ble rapportert.