La primera resposta ha de reduir el dany sense esborrar la informació necessària per conèixer accés, abast i recuperació. Eliminar fitxers sospitosos pot treure símptomes mentre destrueix dates i deixa l’atacant actiu.
Treballa amb una cronologia escrita i canvis reversibles sempre que sigui possible.
Minut 0–5: confirma el risc
Registra qui ho ha informat, hora i zona, URL afectada i símptomes. Comprova si checkout, login, descàrregues o administració poden exposar clients.
No visitis pàgines sospitoses autenticat a WordPress, hosting o correu al mateix perfil. Utilitza un dispositiu net o navegador aïllat i no descarreguis arxius desconeguts.
Si podria haver-hi dades de targeta, activa immediatament el procés del proveïdor de pagament i de l’organització.
Minut 5–10: conserva una instantània
Demana al host una còpia de fitxers, base i logs abans de netejar. Registra identificador del servidor i hores. Desa-ho protegit i amb accés limitat.
No restauris encara sobre la web: eliminaria evidències i pot tornar una versió vulnerable. No enviïs l’arxiu per email ni el deixis dins del directori públic.
Confirma que la còpia ha acabat i quan rotaran els logs. Calcula un hash o conserva el checksum del proveïdor per comparar.
Minut 10–15: contén el dany públic
Tria la mesura més estreta que protegeixi: desactivar checkout, servir manteniment controlat, bloquejar una ruta maliciosa o suspendre el compte compromès.
Quan WordPress no és fiable, utilitza una pàgina estàtica fora de l’aplicació, no un plugin de manteniment. Conserva l’accés dels responsables mitjançant el hosting sense publicar la IP d’origen.
Documenta quines URL i funcions han quedat bloquejades perquè negoci i suport coneguin l’impacte.
Minut 15–20: assegura el pla de control
Des d’un equip net rota hosting/panell, administradors WordPress, claus SSH/deploy i base potencialment exposats. Protegeix primer el correu principal i activa MFA.
No canviïs tots els secrets a cegues abans de registrar dependències: podries trencar serveis i logs. Prioritza comptes que modifiquin fitxers, base, DNS i còpies.
Revoca sessions desconegudes i anota cada acció. Si diverses webs comparteixen credencial, amplia l’abast.
Minut 20–25: recull evidència volàtil
Preserva access/error logs, PHP, events de seguretat, cua de correu, processos/tasques i administradors. Registra fitxers modificats sense executar PHP sospitós.
Captura DNS, redirects i configuració relacionada. Identifica fitxers amb hashes. Minimitza dades del client i utilitza el repositori d’evidències aprovat.
No instal·lis un scanner nou a producció si altera dates o consumeix el servidor abans de la còpia.
Minut 25–30: defineix recuperació neta
Llista fonts fiables de core, plugins i temes; backups coneguts; PHP; propietari del codi i serveis externs. Decideix si cal reconstruir components i importar contingut validat en lloc de «netejar en lloc».
Assigna responsables de contenció, investigació, comunicació i conciliació. Defineix què s’ha de verificar abans d’obrir. No prometis hora fins a entendre vector i persistència.
Evita reaccions destructives
No eliminis tot el que és recent, sobreescriguis la base, executis scripts desconeguts o donis accés il·limitat a tercers. Un atacant pot canviar timestamps i els fitxers legítims també poden ser recents.
No paguis rescat ni contactis amb el suposat atacant sense responsable autoritzat i assessorament jurídic. Comunica als clients per canals aprovats quan calgui.
Defineix la primera verificació
La contenció funciona quan cessa el comportament maliciós públic, els comptes de control estan protegits i l’evidència conservada. No demostra que la web sigui neta.
La recuperació exigeix identificar persistència, substituir codi, revisar base/usuaris, tancar l’entrada, rotar secrets i provar la reconstrucció.
Registra també qui autoritza cada pas.
Demana rescat urgent si afecta checkout, administració, correu o diverses webs. Comparteix accés gestionat i logs redactats, mai contrasenyes, backups o dades públicament.