«El malware encara no ha tornat» no és una prova. Una porta del darrere pot esperar el cron, un visitant concret, un inici administratiu o un controlador extern. La verificació ha de provar la ruta identificada i observar el web més enllà de l’interval anterior de recurrència.
Defineix quines evidències necessites abans de declarar acabada la neteja.
Descriu amb precisió la ruta sospitosa
Escriu una causa breu: un endpoint de pujada vulnerable va crear un carregador PHP; un compte SFTP robat va modificar tres webs; un cron maliciós va restaurar una opció injectada.
Separa els fets confirmats, les inferències i els logs no disponibles. Si la ruta continua desconeguda, indica-ho i amplia la monitorització en comptes d’afirmar que està tancada.
Registra el període afectat, els components i els comptes implicats.
Verifica el control del punt d’entrada
Confirma, mitjançant comprovacions admeses pel desenvolupador, que el component vulnerable està apedaçat, eliminat o restringit. No reprodueixis exploits destructius contra un web públic.
Si es van robar credencials, demostra que les sessions i els tokens estan revocats i que s’ha assegurat el dispositiu o magatzem d’origen. Si el problema era l’aïllament, verifica amb comprovacions autoritzades que l’usuari d’un web no pot escriure a les rutes d’un altre.
Conserva evidències anteriors i posteriors amb els secrets censurats.
Elimina la persistència establerta
Compara el nucli, els connectors i els temes amb fonts netes. Revisa codi propi, uploads, injeccions a la base, administradors, contrasenyes d’aplicació, cron de WordPress i del servidor i les capes d’allotjament, DNS i CDN.
Busca hashes, rutes, dominis i cadenes coneguts de l’incident. L’absència d’un sol indicador no cobreix les seves variants; combina-la amb comprovacions de procedència i comportament.
Documenta cada element posat en quarantena o eliminat i la font utilitzada per substituir-lo.
Reprodueix els cicles normals
Executa WP-Cron, Action Scheduler, còpies, regeneració de memòria cau, desplegaments i actualitzacions autoritzades. Desa primer a staging els ajustos que abans provocaven la regeneració de fitxers.
Repeteix les condicions originals del visitant —mòbil, referència de cercador, primera visita o ruta afectada— dins d’un perfil de navegador segur.
No contactis amb infraestructura de l’atacant ni executis payloads antics per demostrar el tancament.
Monitoritza canvis que tinguin significat
Crea una referència de hashes posterior a la neteja per al codi de confiança i alertes davant executables a uploads, administradors desconeguts, cron nou i canvis de configuració sensible.
Exclou el moviment normal de memòries cau i mitjans. Si cada miniatura genera una alerta, l’equip acabarà ignorant-les.
Conserva logs web, d’autenticació i de canvis prou temps per cobrir la recurrència anterior i els cicles programats.
Busca evidències fora del servidor compromès
Utilitza registres independents que l’atacant no pogués modificar amb facilitat: peticions del CDN, historial d’autenticació de l’allotjament, monitorització externa, logs del proveïdor de correu i historial del repositori o desplegament.
Compara’ls amb la cronologia del servidor net. Si els logs locals van desaparèixer, les fonts externes encara poden mostrar l’última redirecció, un accés desconegut al panell o el desplegament que va introduir un fitxer.
Documenta les llacunes de conservació; l’absència d’esdeveniments locals no demostra que no hi hagués accés.
Verifica els límits del compte i l’entorn
Comprova cada instal·lació sota l’usuari d’allotjament afectat. Confirma que staging i webs antigues retirades són inaccessibles i que els artefactes de desplegament estan nets.
Revisa usuaris de panell, SFTP i SSH, comptes de correu utilitzats per restablir accessos, claus API, DNS i CDN. Aplica comptes individuals, privilegi mínim i MFA quan s’admeti.
Un directori WordPress net no compensa una sessió activa del panell.
Prova la funcionalitat del negoci
Envia formularis, verifica el correu, prova l’inici i el restabliment de contrasenya i completa un checkout WooCommerce autoritzat en sandbox. Confirma que els canvis de seguretat no han trencat pagaments, webhooks o comandes programades.
Inspecciona l’HTML públic i les connexions sortints buscant els dominis maliciosos anteriors. Comprova que les URL spam retirades retornen correctament 404 o 410.
Defineix l’observació i la resposta
Tria la durada segons les evidències: interval de retorn anterior, horari del cron, desencadenant de trànsit i risc de credencials. Defineix qui rep cada alerta i quina contenció està prèviament autoritzada.
Lliura al propietari les troballes, limitacions, accions sobre credencials i un registre datat de la verificació.
Quan convé una verificació independent
Demana una segona revisió si la ruta d’entrada és incerta, el checkout va estar afectat o diverses webs compartien accessos. L’avaluació pot partir de la cronologia i els indicadors sanejats.
La confiança prové de proves específiques de la ruta i evidències estables, no d’un únic resultat verd de l’escàner.