L’execució de codi a WordPress acostuma a escriure com el seu usuari PHP, mentre que un cPanel, Plesk o SFTP robat pot canviar diverses arrels, bases, correu i DNS. La diferència decideix què reconstruir i quines credencials prioritzar.
Comença considerant tot el compte i redueix l’abast només amb evidència.
Mapeja permisos i propietaris
Documenta usuari del sistema, handler PHP, arrel WordPress, webs germanes, usuaris MySQL i directoris escrivibles. Anota si diverses webs comparteixen usuari del sistema.
En cPanel compartit, un PHP compromès pot creuar arrels si ho permeten els permisos. En subscripcions Plesk separades, els canvis creuats apunten a accés més ampli. No alteris propietaris abans de conservar-los.
Revisa accessos del panell
Inspecciona logins cPanel/Plesk, gestor de fitxers, tokens API, usuaris d’equip o client i canvis del correu de recuperació. Correlaciona’ls amb fitxers i base.
Una sessió desconeguda correcta és evidència forta de hosting. L’absència no prova abast WordPress si la retenció és curta. Conserva IDs abans de revocar.
Inspecciona SFTP, SSH i desplegaments
Revisa usuaris i claus FTP/SFTP/SSH, desplegaments i restauracions. Compara ordres o rutes pujades amb els canvis maliciosos.
Una credencial de desenvolupador robada pot semblar activitat normal. Confirma amb el propietari en lloc de confiar en el nom. Rota claus des d’un dispositiu net després de capturar.
Compara webs germanes
Busca payloads, administradors, hooks cron, dominis de redirecció i hores iguals a tot el compte. Un patró simultani entre arrels suggereix accés compartit o permisos insegurs.
Dates diferents també poden indicar propagació lateral. Examina staging abandonat i backups. No netegis només el domini principal visible.
Examina indicadors de WordPress
Busca als logs endpoints vulnerables de plugins o temes, accions autenticades i pujades. Revisa usuaris, contrasenyes d’aplicació, mu-plugins, cron i opcions.
Si els canvis queden en una instal·lació i coincideixen amb un exploit públic, l’entrada WordPress és més probable; tot i així, després es podien llegir secrets del hosting. Registra escalada i primera persistència.
Interpreta propietaris amb cautela
Els fitxers de l’usuari PHP o del sistema poden procedir de WordPress, actualitzacions legítimes o gestor del panell segons el hosting. Propietari i data donen suport, però no atribueixen.
Compara amb desplegaments i auditoria. Conserva metadades abans de canviar permisos o copiar. En hosting gestionat, pregunta com representen escriptures web i del panell.
Revisa elements externs a WordPress
Cron de servidor desconegut, reenviaments alterats, DNS canviat, configuració PHP o fitxers fora de qualsevol arrel apunten més enllà de l’aplicació.
Revisa eines MySQL i auto_prepend_file del servidor sense executar fitxers sospitosos. Eleva canvis root o de paquets al responsable d’infraestructura.
Considera secrets llegibles per PHP
Fins i tot un atac només a l’aplicació pot exposar MySQL, salts i claus SMTP/API de configuració. Després podria comprometre base, correu o tercers sense robar el panell.
Inventaria secrets accessibles al procés PHP i rota’ls ordenadament. Limita en el futur cada credencial al servei i web necessaris.
Tria l’abast de recuperació
Amb evidència només WordPress, reconstrueix aquella web i rota secrets que podia llegir. Amb evidència de compte, protegeix correu, panell, tots els usuaris i claus, bases, correu, còpies i DNS.
Si hi ha dubtes, contén amb l’abast ampli mentre analitzes. La comoditat no ha de deixar accessos compartits actius. Separa webs i usuaris quan sigui viable.
Verifica el límit després
Monitoritza logins del panell, fitxers entre arrels, accions privilegiades, cron i correu sortint. Prova les funcions comercials de cada web afectada.
Documenta evidència, incertesa i per què l’abast és suficient. Conserva captures i logs segons la política. Si van canviar webs germanes o configuració del servidor, demana recuperació multicapa compartint topologia i esdeveniments censurats, mai claus mestres o backups complets.