Tio sajter och en malware som byggde upp sig själv igen

Vad var problemet

Tio WordPress-sajter på samma hostingkonto var komprometterade. Spåren gick tillbaka ett och ett halvt år, och fem tidigare saneringsförsök med ett vanligt säkerhetsplugin hade misslyckats. Filer togs bort, och var tillbaka vid nästa sidladdning — i ett fall sex gånger för samma fil.

Orsaken var att man letade på fel ställe. Det som syntes var filer, men filerna var bara kopior. Den riktiga nyttolasten låg i databasen, komprimerad, tillsammans med malwarens egen förteckning över var alla dess filer skulle ligga. Så länge databasen var orörd byggde den upp sig själv igen, utan att ens behöva nå ut på nätet: den hade lagt undan återställningsarkiv i tre kopior per sajt, i mappar man normalt inte tittar i.

Till det kom miljön. Alla tio sajterna låg under samma systemanvändare, och det som kan skriva i en sajts filer kan skriva i de andras. En kompromettering blev därför tio.

Hur löste vi det

Ordningen var det som avgjorde. Exekveringen stoppades före rensningen: kontot spärrades, pågående PHP-processer dödades, och utgående trafik stängdes av på systemanvändarnivå i brandväggen. Först därefter rörde vi en enda fil. Att radera på en levande sajt är precis vad de tidigare försöken gjorde, och det är också vad malwaren räknade med.

Brandväggen visade sig inte vara en försiktighetsåtgärd. Mitt under saneringen triggade ett av malwarens schemalagda jobb och försökte hämta hem sig själv igen. Hämtningen blockerades, och kvar låg en tom fil i stället för en fungerande bakdörr. Utan den regeln hade alla tio sajterna infekterats om.

Malwarens eget manifest blev facit. Koden låg gömd på sju olika sätt per sajt — i mu-plugins, i sex olika falskt namngivna plugin, i dolda kataloger, i temats funktionsfil, i de drop-in-filer som WordPress laddar allra först, och i lösa filer med slumpmässiga namn. Den sista gruppen hade inga igenkänningsbara markörer alls och gick inte att söka fram. Men malwaren förde bok över sig själv i databasen, och den listan pekade ut trettiotvå filer som annars hade blivit kvar.

Ingenting raderades utan kopia. Full backup före varje destruktivt steg, och allt som togs bort flyttades till karantän. Sedan rensades databasen: de dolda inställningarna, elva dolda administratörskonton, ett schemalagt återhämtningsjobb och drygt sjutusen spaminlägg på en av sajterna.

Till sist det som stänger dörren. Nya lösenord på samtliga konton, roterade säkerhetsnycklar och tömda sessioner, eftersom inloggningsuppgifter bevisligen varit exponerade. Kärnfiler och plugin verifierades mot wordpress.org för att utesluta ändringar vi inte sett. Brandväggsreglerna låg kvar i flera dygn medan vi kontrollerade att ingenting kom tillbaka.

Vad resultatet blev

Tio sajter i drift igen, och den här gången utan att något byggde upp sig självt. Efteråt togs pluginet bort som var den mest sannolika vägen in, WordPress-versionerna kom i fas, och tvåfaktor slogs på för administratörerna.

Den viktigaste slutsatsen handlar dock inte om skadlig kod, utan om hur kontot var byggt. De omkring femtio andra kontona på samma server var helt opåverkade — filsystemet höll isär dem. Att de tio drabbade sajterna delade en systemanvändare var skillnaden mellan ett problem och tio, och rekommendationen framåt är därefter: en systemanvändare per kundsajt.