El web de producció està actualitzat, però els fitxers maliciosos tornen. Un subdomini de staging oblidat encara executa un WordPress antic, un connector vulnerable o una còpia d’un compte administrador. Si comparteix propietari d’allotjament, credencials de base o rutes de desplegament, l’atac pot tornar a producció.
Tracta el staging com una aplicació completa, no com una còpia inofensiva perquè estigui amagada dels cercadors.
Descobreix totes les còpies de proves
Inventa subdominis, dominis addicionals, directoris, bases de dades, registres DNS, certificats SSL i còpies de l’allotjament. Consulta les arrels documentals del panell, no només els enllaços visibles.
Busca noms a més de staging: dev, test, old, backup, carpetes amb dates i hosts temporals de migració. Contrasta l’inventari amb els instal·ladors del panell i les tasques de còpia.
No examinis dominis ni servidors aliens. Confirma amb el proveïdor el límit exacte del compte autoritzat.
Conserva i restringeix l’accés
Si la còpia abandonada està infectada, crea una instantània dels fitxers i la base i restringeix immediatament l’accés al servidor o a l’allotjament. Una etiqueta noindex no és seguretat i no atura els bots.
Evita iniciar sessió al seu panell WordPress des d’un navegador habitual. Treballa mitjançant accés de recuperació o sobre una còpia aïllada.
Mantén una resposta estàtica neta perquè la monitorització i l’equip no confonguin el bloqueig amb una caiguda accidental.
Compara els indicadors de l’atac
Calcula hashes dels fitxers sospitosos i compara rutes, cadenes del payload i hores de modificació amb producció. Revisa els logs d’accés per localitzar l’endpoint vulnerable i les escriptures posteriors.
Un payload coincident dona suport a una relació, però no demostra la direcció del moviment. Tots dos webs podrien haver estat compromesos des del mateix compte del panell.
Correlaciona les dades amb sessions SFTP o del panell, tasques cron i propietat dels fitxers. Normalitza les zones horàries abans d’ordenar els esdeveniments.
Identifica la confiança compartida
Comprova si staging i producció comparteixen:
- contrasenyes d’administradors de WordPress;
- usuari o base de dades;
- salts i claus d’autenticació;
- credencials SFTP o de desplegament;
- un directori pare amb permisos d’escriptura;
- memòria cau d’objectes o prefix de taules;
- secrets de webhooks o API.
Separa cada entorn. Rotar secrets de producció mentre staging conserva els mateixos valors compromesos pot invalidar tota la reparació.
Decideix si cal reconstruir o retirar
Si staging ja no és necessari, conserva l’evidència i les dades requerides i elimina el DNS públic, l’amfitrió virtual i els fitxers mitjançant un procés controlat i recuperable.
Si encara es necessita, reconstrueix-lo des de codi de producció revisat i una base sanejada. Actualitza els components, restringeix l’accés, bloqueja efectes secundaris de correu i pagaments i assigna-hi un responsable.
No clonïs sense control dades reals de clients o comandes. Aplica els requisits de privacitat i conservació.
Evita que staging afecti clients reals
Substitueix les claus de pagament de producció per credencials sandbox, redirigeix el correu sortint a una bústia de proves autoritzada i desactiva webhooks, logística i analítica reals. Utilitza configuració específica per entorn en comptes de corregir valors manualment després de cada clonació.
Fes que els cercadors rebin autenticació o una resposta restringida no indexable, no només una indicació a robots.txt. Una còpia pública pot exposar dades personals i contingut duplicat encara que no sigui l’origen del malware.
Neteja el límit complet del compte
Inspecciona els webs veïns, el cron de l’allotjament, la configuració PHP, els usuaris i els artefactes de desplegament. Substitueix paquets de confiança compromesos i elimina portes del darrere i persistència a la base.
Corregeix el component vulnerable original i rota els accessos afectats després d’assegurar els dispositius d’administració. Ajusta els permisos perquè staging no pugui escriure a producció.
Verifica l’aïllament i l’estabilitat
Comprova que el web retirat ja no resol o que el reconstruït exigeix accés autoritzat. Confirma que no pot enviar correus reals, processar pagaments ni indexar-se.
Monitoritza hashes de producció i logs del compte durant més temps que l’interval anterior de reinfecció. Executa els desplegaments i les còpies normals per demostrar que no restauren la versió antiga, i repeteix la prova després del desplegament següent.
Quan convé una neteja especialitzada
Demana una avaluació si staging comparteix bases, permisos o automatització amb producció. Envia els noms de subdomini i la cronologia, mai les credencials.
Una reparació duradora elimina l’entrada oblidada, separa els entorns i demostra que producció es manté estable després de l’activitat programada.