Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Confirmar Contener Incidente

Varias webs del mismo cPanel han sido hackeadas a la vez

Contén varias webs mapeando accesos compartidos, preservando evidencias, reconstruyendo y separando el riesgo.

Las webs bajo un usuario cPanel comparten permisos, cron, límites de correo y panel. Limpiar solo el dominio visible deja a otra web capaz de reinfectarlo o conservar la credencial robada.

Trata la cuenta cPanel como límite inicial hasta demostrar un alcance menor.

Inventaría la cuenta

Lista addon domains, subdominios, aparcados, document roots, WordPress, staging, bases, cron y buzones. Incluye webs abandonadas y carpetas de desarrollo.

Registra propietarios y criticidad. No navegues webs infectadas autenticado a cPanel u otro administrador. Conserva el mapa antes de mover directorios.

Añade versión PHP, propietario Unix, usuario MySQL, cuenta SFTP, email remitente y proveedor DNS por web. Una matriz revela credenciales y servicios compartidos que no se ven en la lista de dominios.

Contén exposición

Desactiva checkout, login o routing según riesgo. Sirve mantenimiento estático fuera de roots comprometidos.

Restringe correo si hay spam y ofrece canal alternativo para consultas/pedidos. No borres la cuenta antes de asegurar copias y logs.

Preserva evidencia de cuenta

Captura archivos, bases, logs cPanel/FTP/SFTP/SSH, cola, cron y cambios recientes. Registra usuarios, permisos y configuraciones comunes.

Guarda fuera de la cuenta; atacante o limpieza podrían modificarlo. Limita acceso y datos de clientes. Anota plazos de retención del host.

Calcula hashes de archivos y registra hora/zonas de cada fuente. Si el backup se toma después de contener una web pero antes de otra, anota ese orden para interpretar diferencias. No combines copias sin conservar el origen.

Encuentra accesos compartidos

Revisa usuarios cPanel/FTP, SSH keys, tokens API, file manager y email principal. Una credencial de panel explica cambios en todos los roots.

Audita usuarios MySQL reutilizados y deploy con escritura global. Rota desde equipo limpio tras preservar. No asumas que el plugin común es la única causa.

Comprueba si PHP de un root puede leer o escribir los demás mediante permisos o symlinks. Revisa tareas que recorren todo el home y claves almacenadas en scripts. Un cron legítimo de backup comprometido puede distribuir payloads a cada instalación.

Compara indicadores

Busca nombres, patrones de código, cron, administradores, dominios de redirect y horas idénticas. Los indicadores comunes ayudan a localizar movimiento lateral.

Busca también payloads distintos: spam en una web y redirects en otra. Usa checksums confiables. No ejecutes ni subas muestras a scanners públicos sin autorización.

Construye un conjunto de indicadores comunes y específicos. La ausencia de un filename concreto no limpia una web si comparte la credencial inicial. Define alcance por capacidad del atacante, no solo por la presencia de una firma.

Separa base y backups

Comprueba si todas usan un usuario MySQL o guardan copias de hermanas dentro de roots públicos. Rota y limita por aplicación.

Mueve backups a almacenamiento protegido fuera de cPanel web. Una web limpia puede ser reinfectada o exponer datos por un zip olvidado de otro dominio. Registra credenciales y claves de cifrado a rotar.

Reconstruye cada web

Crea roots limpios e instala WordPress/plugins/temas verificados. Valida custom code/base, importa uploads/contenido evaluados y crea secretos únicos.

Recupera primero la web crítica solo si las hermanas infectadas no pueden escribirla. Mantén roots antiguos no ejecutables y aislados. Prueba una completamente antes de repetir el proceso.

Asigna un manifiesto por web: componentes reinstalados, contenido importado, secretos rotados y pruebas. No clones una reconstrucción con salts, administradores o claves iguales. Mantén el tráfico cerrado hasta que el aislamiento impida reinfección lateral.

Separa el radio futuro

Mueve producciones no relacionadas a suscripciones/usuarios distintos cuando sea posible. Da a cada una base, SFTP/SSH, WordPress y SMTP propios.

Limita acceso de desarrolladores y usa deploy gestionado. Exige MFA en hosting, email, DNS/CDN y administradores.

Si el plan no permite usuarios aislados, migra por fases y aplica permisos mínimos provisionales. Documenta la limitación como riesgo abierto y no prometas separación que la arquitectura actual no ofrece.

La separación no sustituye parches, monitorización y copias, pero impide que una cuenta escribible posea todas las webs.

Verifica la cuenta completa

Tras recuperar, revisa todo cron, correo, cambios de archivos, administradores, DNS y backups. Prueba redirects, formularios, checkout y tareas por web.

Monitoriza indicadores compartidos y concilia leads/pedidos. Retira dominios y stagings sin uso.

Observa durante varios ciclos de cron y backup. Un payload puede reaparecer solo cuando se ejecuta una tarea semanal o se restaura una caché. Alerta sobre archivos nuevos en roots ya reconstruidos.

Solicita recuperación multisitio urgente cuando cruza document roots o credenciales globales. Comparte inventario y acceso gestionado, nunca una contraseña reutilizada, archivos completos o bases de clientes.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia