Sikkerhetspluginen meldte nettstedet rent – vi fant tre skjulte bakdører i WordPress

En kundes WordPress-nettsted hadde sluttet å oppføre seg som det skulle. Bookingskjemaer sviktet innimellom, sidebyggeren ville ikke laste, og feilloggen ga ingenting å gå etter. Sikkerhetspluginen deres var installert og aktiv, og meldte nettstedet som rent. Vi verifiserte installasjonen fil for fil mot de offisielle kildene, og fant tre skjulte bakdørsfiler inne i den – hver eneste bygget spesifikt for å overleve akkurat den typen skanning som allerede hadde friskmeldt nettstedet.

Utgangspunktet

Nettstedet kjørte WordPress 7.0 med et kommersielt sidebyggertema, et system for timebooking, og femten plugins – blant dem en mye brukt sikkerhetspakke og et rammeverk for egendefinerte felt. Et helt vanlig oppsett, profesjonelt bygget, med flere premiumkomponenter.

To detaljer stakk seg ut før vi åpnet en eneste fil.

Sikkerhetspluginen var installert, aktiv og meldte om null problemer. Hva enn som var galt, hadde allerede passert en skanning fra et av de mest utbredte sikkerhetsverktøyene i økosystemet.

Og feilloggen var nesten tom. Seks oppføringer, alle fra ett og samme attenminutters vindu elleve dager tidligere, alle knyttet til de planlagte oppgavene til én enkelt plugin. Ingen fatale feil. Ingen stack traces. Ingenting som beskrev feilene kunden rapporterte. Loggen fanget rett og slett ikke opp det faktiske problemet i det hele tatt.

Utfordringen

Symptomene som ble rapportert, var vage på den måten slike ting som regel er. Noen funksjoner virket, andre gjorde det ikke. Bookingsystemet sviktet uforutsigbart. Ingen kunne si når det begynte.

Den tvetydigheten er den egentlige vanskeligheten. Symptomer som dette har minst tre plausible forklaringer: en pluginkonflikt, en endring i serverkonfigurasjonen, eller en kompromittering. Hver av dem krever en helt annen respons, og å gjette feil koster dager. Så vi gjettet ikke. Vi verifiserte alt.

Undersøkelsen

Hvorfor signaturskanning bommer på moderne WordPress-bakdører

De fleste jakter på skadevare starter med å søke etter mistenkelige funksjoner: eval, base64_decode, shell_exec. På en moderne WordPress-installasjon er dette nesten ubrukelig. WordPress-kjernen, kryptografibiblioteker, HTTP-klienter, temarammeverket og sikkerhetspluginens egen skanner bruker alle disse funksjonene helt legitimt.

Vårt heuristiske gjennomløp flagget 49 filer på tvers av premiumpluginene og temaet. Hver eneste var ren bibliotekskode.

Du finner ikke en velskrevet bakdør ved å lete etter kode som ser ondsinnet ut. Det finnes altfor mye legitim kode som ser ondsinnet ut.

Så vi snudde spørsmålet på hodet. I stedet for å spørre hvilke filer som ser mistenkelige ut, spurte vi hvilke filer som ikke har noe der å gjøre.

Verifisering av WordPress-kjernen mot den offisielle utgivelsen

Vi lastet ned den offisielle WordPress 7.0-utgivelsen og sammenlignet alle 1 921 kjernefilene ved hjelp av sjekksummer.

Dette er den mest verdifulle testen som finnes for et WordPress-nettsted. Kjernefilene er publiserte, versjonerte og identiske på hver eneste installasjon i verden, så ethvert avvik er per definisjon noe noen har lagt inn. Nesten ingen kjører denne sjekken.

Verifisering av hver plugin mot repositoriet

Vi hentet den nøyaktig samme versjonen av hver plugin som var tilgjengelig i WordPress-repositoriet, og sammenlignet dem på samme måte – ti plugins til sammen. Premiumplugins og kommersielle temaer publiserer ingen sjekksummer, så de ble i stedet analysert strukturelt: entropianalyse, obfuskeringsmønstre, kode lagt til etter lange mellomrom, og unormalt lange enkeltlinjer.

Linjeskift-fellen som skaper falske positive

Én felle er verdt å nevne, fordi den vil ramme alle som prøver seg på dette.

Vår første pluginsammenligning rapporterte 210 av én plugins 459 filer som endret. Det ser ut som en katastrofal kompromittering. Det var linjeskift. Hostingoppsettet hadde konvertert CRLF til LF gjennom hele kodebasen, og etter å ha normalisert for det, var hver eneste av disse filene byte-identisk med den offisielle utgivelsen.

En sammenligning som ikke tar høyde for linjeskift, vil begrave deg i falske positive og ødelegge troverdigheten til alt annet i rapporten din.

Hovedfunn

Tre bakdører, to separate innbrudd

Sammenligningen avdekket det mønstergjenkjenning aldri ville ha funnet: en fil som lå i WordPress-administrasjonskatalogen, og som ikke finnes i noen WordPress-utgivelse.

Til sammen fant vi tre bakdørsfiler på tvers av to kopier av nettstedet – to unike nyttelaster, hver beskyttet av et eget passord. To separate innbrudd, ikke ett.

Hver var på 402 byte. Enkelt forklart:

1. Angriperen sender en forespørsel som inneholder et passord.
2. Uten passordet produserer filen ingen utdata og avslutter.
3. Med passordet dekrypterer filen en nyttelast sendt i samme forespørsel, og kjører den som PHP.
4. Svaret krypteres før det sendes tilbake.

Det er uautentisert ekstern kjøring av kode. Ingen WordPress-innlogging kreves, og full lese- og skrivetilgang til hver eneste fil på kontoen.

Hvordan bakdørene holdt seg skjult

Tre designvalg forklarer hvorfor sikkerhetspluginen ikke fant noe.

• Ingen strenger å matche mot. Ingen shell_exec, ingen system, ingen lang kodet blob. Bare kjøring av en variabel som ble dekryptert et øyeblikk tidligere. Det er ingenting for en signaturskanner å matche på.
• Stillhet ved feil. Uten riktig passord avslutter filen umiddelbart uten utdata. Be om URL-en, og du får en blank side og en HTTP 200. Ingenting når frem til noen logg.
• Troverdige filnavn. Den ene utga seg for å være en bufferfil i administrasjonskatalogen. Den andre utga seg for å være en språkfil, plassert blant rundt 85 ekte oversettelsesfiler.

Språkfilen avslørte seg selv på struktur snarere enn innhold. Hver legitim oversettelsesfil i den katalogen har tilhørende .mo– og .po-filer ved siden av seg. Denne hadde ingen av delene, og med sine 402 byte lå den blant ekte filer på mellom 12 KB og 488 KB.

Feilsøkingsmodus stod på i produksjon

Den aktive konfigurasjonen hadde feilsøkingsmodus slått på, med den trygge standardinnstillingen kommentert ut rett under. En bevisst endring, ikke et uhell.

Med feilsøkingsvisning aktiv skrives PHP-varsler inn i hvert svar. Det ødelegger JSON-en som REST-drevne funksjoner er avhengige av, og det er nettopp derfor bookingsystemet og sidebyggeren sviktet mens resten av nettstedet så helt greit ut. Skadevaren og de synlige symptomene hadde ulike årsaker.

Brannmurens sterkeste lag var slått av

Sikkerhetspluginens utvidede beskyttelse, som inspiserer forespørsler før WordPress lastes, var kommentert ut i serverens konfigurasjonsfil. Pluginen meldte likevel om seg selv som aktivert.

Uten det laget blir forespørsler som treffer en PHP-fil direkte, aldri inspisert – nettopp den veien begge bakdørene brukte.

Tre kjernefiler var håndpatchet

Ikke ondsinnet. Koden var godt kommentert og tydelig en utviklers verk, som adresserte en reell feil. Men kjernepatcher tilbakestilles i det stille av hver WordPress-oppdatering, og én av dem kunne returnere tomme svar på tvers av hele REST-API-et under forhold som oppstår ved helt normal bruk.

Gjenopprettingsstrategi

Vi leverte en prioritert plan i stedet for en liste over filer.

Fjern bakdørene først, roter deretter alle påloggingsdetaljer – i den rekkefølgen, fordi å bytte passord mens en bakdør fortsatt er aktiv, bare gir angriperen de nye.

Derfra: gjenopprett den trygge produksjonskonfigurasjonen, aktiver brannmurlaget som kjører før WordPress, gjennomgå databasen for innsprøytede administratorkontoer og ondsinnede option-rader, og rett opp feilkonfigurasjonene som ødela nettstedet uavhengig av skadevaren.

Vi dokumenterte også hva gjennomgangen ikke kunne dekke. En gjennomgang på filnivå kan ikke se databasen, og et kompromittert WordPress-nettsted bærer ofte på innsprøytede kontoer og option-rader som overlever at hver eneste fil byttes ut. Å si det rett ut er forskjellen mellom en rapport en kunde kan handle på, og en som etterlater kunden trygt i villfarelse.

Resultatet

Kunden fikk et komplett kart over kompromitteringen:

• ✅ Tre bakdørsfiler identifisert og lokalisert
• ✅ To separate innbrudd skilt fra hverandre
• ✅ Alle 1 921 WordPress-kjernefiler verifisert byte-identiske med den offisielle utgivelsen
• ✅ Hver repositorieplugin verifisert mot sin publiserte versjon
• ✅ Fire feilkonfigurasjoner dokumentert, inkludert feilsøkingsmodus og det avslåtte brannmurlaget
• ✅ En prioritert gjenopprettingssekvens, med gjennomgangens begrensninger sagt rett ut

Den rene helseattesten betydde like mye som funnene. Å bekrefte at hver kjernefil og hver repositorieplugin stemte med sin offisielle utgivelse, gjør «vi tror vi renset det» om til «vi vet hva som var der» – og gir hver fremtidig skanning en referanse å måle mot.

Én begrensning preget hele oppdraget. Alle filtidsstempler var blitt skrevet om da nettstedet ble kopiert for analyse, noe som ødela enhver mulighet for tidslinjeforensikk. Vi kunne ikke fastslå når bakdørene ble plassert, eller i hvilken rekkefølge.

Skulle du noen gang trenge å få undersøkt et kompromittert nettsted: bevar endringstidspunktene før du kopierer noe som helst. Bruk et arkivformat som beholder dem. Når de først er borte, mister du muligheten til å svare på det første spørsmålet hver kunde stiller: hvor lenge har dette pågått?

Viktige lærdommer

Signaturskanning har ikke vært tilstrekkelig på mange år. En bakdør som returnerer en blank side og ikke inneholder noen gjenkjennelige strenger, er usynlig for den. Integritetsverifisering mot kjente, rene kilder finner det mønstergjenkjenning ikke kan.

Utløpte premiumlisenser er et sikkerhetsproblem, ikke et faktureringsproblem. Kommersielle temaer og plugins får ingen sikkerhetsoppdateringer uten en gyldig lisens, og en fornyelse som har gått ut, gjør i det stille et vedlikeholdt nettsted om til et uvedlikeholdt ett.

Og å fjerne en bakdør er ikke det samme som å avslutte en kompromittering. Den som hadde tilgang, kunne ha lagt til administratorkontoer, sprøytet inn databaserader, eller planlagt oppgaver som gjenskaper filene. Helt til inngangspunktet er identifisert, kjøper opprydding tid snarere enn trygghet. Vi så det samme prinsippet i et kompromittert Multisite-nettverk vi undersøkte, der det delte laget gjorde at ett enkelt innbrudd nådde hvert eneste nettsted på installasjonen.

Det tydeligste signalet i dette oppdraget var at de to nyttelastene brukte ulike passord. Det er ikke ett innbrudd. Det er noen som kom tilbake.

---

Oppfører WordPress-nettstedet ditt seg på måter ingen kan forklare?

Hvis et nettsted svikter på måter sikkerhetspluginen din ikke kan gjøre rede for, er det som regel raskest å verifisere det mot de offisielle kildene for å finne ut om problemet er en feil – eller noe som har ligget der i månedsvis. Webnorly kan kjøre den verifiseringen, identifisere hva som faktisk er ondsinnet, og gi deg en gjenopprettingsplan du kan handle på. Send oss nettstedet, så forteller vi deg hva som faktisk ligger i det.