El missatge que ens va arribar era curt: no es podia completar el procés de compra. Ni avisos de Google ni textos en xinès. Un checkout que es quedava penjat i un client que, amb raó, volia vendre.
Era un hackeig. I és una cosa que he vist força vegades: el símptoma gairebé mai s’assembla al problema.
Quan a algú li hackegen el WordPress, el normal és demanar que l’hi netegin: s’esborra el que és estrany, es restaura una còpia, es canvien contrasenyes i la web torna a funcionar. Cas tancat.
No ho està. Netejar un WordPress hackejat sense saber per on van entrar és deixar la porta oberta. Per tancar-la cal respondre quatre preguntes. Aquí explico com les vam respondre en un cas real de finals de setembre de 2026 amb un agent d’IA, en què ens va ajudar i quines decisions no li vam deixar prendre.
Continguts
Les quatre preguntes que cal respondre abans de donar una web per neta
Una web neta no és el mateix que una web investigada. Abans de restaurar res, algú ha de poder respondre:
- Per on van entrar. Si no ho saps, no saps què has de tancar.
- Des de quan eren a dins. Això decideix quina còpia de seguretat és fiable i quines dades van quedar exposades.
- Què es van poder endur. Comandes, dades de clients, claus de pagament, credencials de correu.
- Si poden tornar. Usuaris falsos, fitxers que es regeneren, contrasenyes que continuen sent vàlides.
Gairebé totes les guies sobre WordPress hackejat parlen de netejar: escanejar i restaurar. Serveixen, però responen una altra cosa. Si vols el pas a pas de la neteja, el tens a com arreglar una web WordPress infectada (article en castellà).
Com va començar: una botiga on no es podia comprar
La botiga era un WooCommerce amb un plugin de pressupostos B2B. Tot apunta que l’atacant va entrar pujant un fitxer PHP pel formulari de «sol·licitar pressupost», que el plugin acceptava sense comprovar qui l’enviava: la seva primera webshell era a la carpeta de pujades d’aquell mòdul. Amb això va tenir un administrador fals i, des del tauler, va muntar la resta.
Anava a buscar SEO parasitari, no els pagaments: milers de pàgines brossa que imitaven una botiga gran i se servien sobretot a cercadors i a bots d’IA. En les dues hores i escaig de log que vam mirar primer en van sortir 1.971, gairebé totes cap a Googlebot, ClaudeBot, bingbot i Bytespider.
I el checkout? El codi maliciós imprimia un script al principi de gairebé totes les respostes de la web, incloses les peticions AJAX amb què WooCommerce processa la comanda. WooCommerce esperava dades i rebia brossa. Per això no es podia comprar.
El client va veure un error de compra. El problema era una intrusió amb persistència.
Què va fer la IA en la investigació
Vaig treballar amb Claude Code, un agent d’IA, connectat al servidor per SSH en mode només lectura. Qualsevol canvi a producció necessitava que jo l’aprovés abans. I abans de tocar res vam fer una còpia forense del servidor sencer, logs inclosos. És la mateixa manera de treballar que expliquem a la migració de PHP 5 a PHP 8 amb IA: l’eina llegeix i proposa, la persona decideix.
Això és el que va fer l’eina:
Reconstruir la cronologia. Li vam demanar que creués les altes d’usuaris amb les dates de modificació dels fitxers, i després amb els logs d’accés. L’administrador fals va aparèixer sis segons abans que el plugin creés la seva carpeta temporal de pujades. Aquesta coincidència és la que assenyala la porta, i trobar-la a mà entre milers de línies porta molt més temps.
Separar el que era de l’atacant del que era legítim. En un servidor real hi ha coses estranyes que no són codi maliciós: el repositori Git de desplegament, carpetes d’un proveïdor, clients normals que es van registrar aquells mateixos dies. La IA ho va classificar i nosaltres vam revisar la classificació.
Verificar el resultat. Després de netejar, va comparar el nucli de WordPress i els plugins oficials amb els checksums publicats per WordPress.org, i va buscar les signatures del codi maliciós a tot l’arbre de fitxers.
Mesurar què va fer l’atacant. Vam filtrar els logs per les seves IP i en va sortir això: 444 peticions dinàmiques, 7,97 MB en total, i la resposta més gran de les seves webshells va ser de 4,5 KB. No va obrir mai comandes, clients, exportacions ni els ajustos de pagament. Amb aquests números es pot descartar un bolcat de la base de dades per la web.
La primera anàlisi i la neteja es van fer el mateix dia. La neteja en si, per SSH, van ser onze minuts. El llarg va ser el d’abans: saber què calia treure.
El que l’escàner del hosting no va veure
Quan vam entrar, el hosting ja havia detectat el codi maliciós i el seu escàner havia esborrat part dels fitxers. Sobre el paper, la web era neta.
No ho era. El que continuava al disc ho deixava força clar. L’atacant havia deixat un «guardià»: còpies xifrades del seu codi repartides per diverses carpetes i un procés que tornava a crear els fitxers esborrats. L’escàner treia el que veia i el guardià ho reposava hores després. A més hi havia codi injectat en tres plugins legítims, un carregador a mu-plugins i un administrador fals que continuava existint.
Que el hosting digui que ha netejat alguna cosa no vol dir que la web sigui neta. Vol dir que ha esborrat el que el seu escàner reconeix.
La còpia de seguretat que no s’havia de restaurar
En ple incident, el primer que vaig fer va ser una còpia de seguretat completa de la web. És el lògic: abans de tocar res, guardes el que hi ha.
Aquella còpia estava infectada, és clar. Serveix com a prova, no com a punt de restauració. Restaurar-la hauria reinstal·lat el codi maliciós, guardià inclòs.
La còpia bona, la que vam marcar com a referència, era la de cinc dies abans: l’última anterior a l’entrada de l’atacant. Ho vam poder saber perquè ja teníem resposta a la segona pregunta, des de quan eren a dins. Sense cronologia, «restaurar l’última còpia» hauria estat restaurar el problema.
El que els logs no expliquen
És la part que gairebé ningú explica, i la que més importa a qui ha de decidir.
Els logs d’accés registren les peticions web: quina URL, des de quina IP, quina resposta i quants bytes. No registren el que una webshell executa dins del servidor. Si l’atacant hagués enviat dades cap a fora amb una ordre des del mateix servidor, no apareixeria en cap log d’accés.
Tampoc teníem els logs del moment exacte de l’entrada. La porta la vam deduir per les dates i per on era la seva primera webshell, no perquè veiéssim la petició.
Així que el que vam dir al client no va ser «no us han robat dades». Va ser: no hi ha exfiltració visible als logs, i aquests són els límits del que els logs poden veure.
L’atacant va ser administrador durant unes 26 hores. En aquest temps va poder llegir les comandes, les claus de les passarel·les de pagament, les credencials de correu i la configuració de la base de dades. No hi ha rastre que ho fes, però tampoc es pot demostrar que no.
Una IA tendeix a donar respostes rodones. En aquesta investigació, bona part de la meva feina va ser frenar-la i escriure igual de clar el que no sabíem.
El que no deleguem
La IA va trobar i va comprovar. Les decisions les vam prendre nosaltres:
Què tancar i quan. Desactivar el plugin sospitós en plena investigació, i després actualitzar-lo i deixar apagat el mòdul de pressupostos. Actualitzar un plugin en calent té els seus riscos, i els hem explicat en un altre article (en castellà), però amb una porta oberta no hi havia alternativa.
Què rotar. Vam regenerar les claus de seguretat de WordPress, cosa que va tancar de cop 503 sessions obertes. I vam decidir quines de les credencials que l’atacant va poder llegir calia canviar de seguida, començant per les de les passarel·les de pagament i el correu.
Quina còpia restaurar i quina no. Pel que hem vist abans.
Què explicar al client. Inclòs el que no podíem descartar.
I una que ni tan sols és nostra: si cal notificar la bretxa. Segons l’AEPD, el responsable del tractament, que és l’empresa propietària de la web i no la seva agència, ha de valorar el risc i notificar-ho a l’autoritat en un termini de 72 hores des que en té constància, quan hi hagi risc per a les persones. El nostre paper és donar-li la informació perquè pugui decidir dins de termini. Si la web ja anava justa amb la protecció de dades, això és el que sol fallar en el compliment del RGPD.
Què has de demanar a qui netegi el teu WordPress
Si t’han hackejat la web i algú et diu que ja està solucionat, demana que et respongui això per escrit:
- Per on van entrar i què s’ha fet per tancar aquella porta concreta.
- Des de quan eren a dins i com s’ha determinat.
- Quina còpia s’ha restaurat i per què és anterior a la intrusió.
- Què van poder veure o endur-se, i què no es pot descartar.
- Quines credencials s’han canviat.
- Com s’ha comprovat que no queda res: usuaris, fitxers que es regeneren, codi injectat en plugins legítims.
- Què cal vigilar les properes setmanes, començant per l’informe de «Problemes de seguretat» de Search Console.
Si la resposta a la primera pregunta és «no ho sabem», la web no està tancada. Està neta fins a la propera vegada.
Quan torna a funcionar no s’ha acabat
La IA ha abaratit investigar un hackeig. Llegir milers de línies de log i comparar centenars de fitxers amb els seus checksums és just la feina on una eina així rendeix, i en aquest cas ens va estalviar la part més feixuga.
El que no ha canviat és qui en respon. Decidir quina còpia és fiable i què cal explicar al client continua sent feina d’algú que coneix la web i n’assumeix les conseqüències. Nosaltres, en aquest cas.
Un WordPress hackejat no es tanca quan torna a funcionar. Es tanca quan saps com van entrar.
Fonts i referències
| Institució / organisme | Títol / publicació | Què sustenta | Enllaç |
|---|---|---|---|
| AEPD | Notificación de brechas de datos personales a la Autoridad de Control | Responsable del tractament, termini de 72 hores, eina Asesora Brecha | aepd.es |
| AEPD | Guía para la notificación de brechas de datos personales | Context sobre què és una bretxa i com es notifica | aepd.es |
| WordPress.org | wp core verify-checksums (WP-CLI) | Verificació del nucli amb els checksums oficials | developer.wordpress.org |
| WordPress.org | wp plugin verify-checksums (WP-CLI) | Verificació dels plugins oficials | developer.wordpress.org |
| Resum dels informes de Search Console | Informe «Problemes de seguretat» | support.google.com |
T’han netejat la web però ningú t’ha dit per on van entrar?
A Èmfasi revisem què ha passat al teu WordPress i tanquem la porta per on van entrar. I et deixem per escrit què sabem i què no. Forma part del nostre servei de suport i manteniment web.
Preguntes freqüents sobre WordPress hackejat
Nosaltres vam començar creuant les altes d'usuaris amb les dates de modificació de fitxers, i després ho vam contrastar amb els logs d'accés del servidor. L'entrada sol aparèixer com una coincidència entre totes dues coses, per exemple un usuari administrador creat just quan un plugin escriu un fitxer. Sense els logs d'accés del dia de la intrusió, la porta d'entrada sol quedar com a hipòtesi.
Només si la còpia és anterior a la intrusió i, a més, es tanca la vulnerabilitat per on van entrar. Una còpia feta durant l'incident pot estar infectada, i restaurar una còpia neta sense corregir l'error deixa la web exposada al mateix atac.
Pot fer bona part de la feina mecànica: llegir logs, reconstruir cronologies, classificar fitxers i verificar checksums. No pot decidir quins canvis fer a producció ni què es comunica al client o a l'autoritat de protecció de dades. En el nostre cas va treballar en mode només lectura i cada canvi va necessitar aprovació humana.
No necessàriament. Els escàners del hosting esborren el que reconeixen, però alguns codis maliciosos deixen còpies xifrades i processos que tornen a crear els fitxers. També hi poden quedar administradors falsos o codi injectat en plugins legítims.
Ho decideix el responsable del tractament, és a dir, l'empresa propietària de la web. Si la bretxa pot suposar un risc per a les persones, cal notificar-la a l'AEPD en un termini de 72 hores des que se'n té constància. L'AEPD ofereix una eina, Asesora Brecha, per ajudar a valorar-ho.
