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

Persistence Reinfection

Una cuenta administradora oculta reaparece después de borrarla

Rastrea un administrador recurrente mediante código de base, tareas, sesiones comprometidas, plugins e integraciones externas.

Eliminas un administrador desconocido y vuelve con el mismo nombre u otro. Algo todavía puede crear usuarios: código malicioso, tarea programada, acceso directo a la base, sesión administrativa comprometida o integración externa.

Borrarlo de nuevo solo contiene. Conserva la creación e identifica al responsable.

Registra la cuenta con seguridad

Captura ID, login, dominio del email, fecha de registro, roles y metadatos relevantes. No pruebes su contraseña ni envíes un restablecimiento.

Registra sesiones activas y contraseñas de aplicación mediante herramientas autorizadas. Conserva base y logs antes de revocar.

No publiques usuarios o direcciones; pueden ser robados o pertenecer a una persona suplantada.

Retira el acceso inmediato

Termina sesiones, revoca contraseñas de aplicación y elimina capacidades administrativas de forma controlada. No reasignes contenido hasta saber si se creó maliciosamente.

Si la web cambia activamente, restringe administración o usa mantenimiento. Conserva al menos una cuenta propietaria verificada por una vía segura.

No crees un administrador de emergencia compartido.

Identifica el evento de creación

Busca en logs de seguridad, auditoría de base y accesos próximos a la fecha. Revisa acciones administrativas, REST, XML-RPC, endpoints de plugins y cambios directos.

Los hooks de WordPress pueden registrar futuras creaciones con actor y contexto, sin guardar contraseñas o cookies.

Si aparece a intervalos fijos, inspecciona cron y Action Scheduler.

Correlaciona siempre las horas en una misma zona y contempla el desfase entre WordPress, PHP y el panel del hosting. Una petición POST correcta justo antes del alta puede señalar el punto de entrada, pero la dirección IP por sí sola no atribuye al atacante: podría pertenecer a un proxy, Cloudflare o una sesión legítima robada. Conserva URL, método, código de respuesta, agente y cuenta autenticada para reconstruir la secuencia.

Busca persistencia en código y base

Revisa plugins, mu-plugins, temas, snippets y wp-config.php buscando creación de usuarios, cambios de rol y los datos recurrentes. Analiza sin conexión.

Inspecciona opciones y eventos codificados. Revisa triggers de base solo si estás autorizado; WordPress normalmente no los necesita para crear usuarios.

No ejecutes PHP sospechoso para comprobar su efecto.

Comprueba si solo está oculto en la interfaz

Compara el panel con WP-CLI autorizado o inventario de base de solo lectura. El malware puede filtrar pre_user_query, alterar recuentos u ocultar una fila.

Revisa la relación users y usermeta con el prefijo real y confirma que cada rol administrador pertenece a un ID conocido. No edites capacidades serializadas directamente en producción.

Conserva la fila oculta, elimina primero el filtro y revoca después mediante controles normales.

Revisa integraciones legítimas

SSO, membresía, sincronización de staging o herramientas del hosting pueden aprovisionar administradores. Confirma propietario y mapeo de roles.

Una integración legítima también puede estar comprometida. Revisa sesiones, claves y logs.

Desactiva en staging para comparar en lugar de desconectar producción sin recuperación.

Rota accesos relevantes

Audita todos los administradores, contraseñas de aplicación, hosting, SFTP, base y tokens de despliegue. Rota después de asegurar dispositivos.

Genera salts nuevos para invalidar sesiones y coordina integraciones externas.

Elimina cuentas abandonadas y usa acceso individual de privilegio mínimo.

Verifica que no reaparece

Monitoriza usuarios y roles más allá del intervalo anterior. Ejecuta cron, copias y sincronización normal.

Busca entradas, opciones y archivos asociados. Confirma que administradores válidos entran y que reset y correo funcionan.

Revisa diariamente el número de roles durante la observación.

Configura una alerta ante nuevas altas, cambios de rol y creación de contraseñas de aplicación. La alerta debe incluir el ID y la hora, pero nunca cookies ni credenciales. Repite la comprobación después de una actualización, un despliegue y una restauración programada: cualquiera de esas rutas puede reintroducir una copia contaminada. Cierra el incidente solo cuando haya transcurrido más que el periodo de recurrencia observado.

Solicita ayuda urgente

Pide limpieza si vuelve, cambian roles sin actor o no se entiende el aprovisionamiento. Envía horas y detalles censurados, nunca contraseñas.

La reparación debe atribuir la creación, revocar cada persistencia y documentar quién controla la administración.

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