Cómo sanear WordPress después de una intrusión: usuarios fraudulentos, API REST y web shells

Introducción

Una intrusión en WordPress puede ir mucho más allá de sustituir la portada por un mensaje del atacante. En algunos incidentes aparecen decenas o cientos de cuentas administrativas, entradas publicadas en ráfagas, páginas sin título, cambios inesperados en la base de datos y, en los casos más graves, archivos capaces de ejecutar órdenes en el servidor. Recuperar la imagen pública de la web es importante, pero no equivale a recuperar su seguridad.

El propósito de esta guía es explicar, de principio a fin, cómo responder a una intrusión en un WordPress autogestionado sobre Linux, Nginx y MariaDB, utilizando SSH y WP-CLI. El enfoque sirve especialmente cuando se sospecha de una explotación a través de la API REST o de la existencia de una web shell. No presupone que todo ataque por la API REST instale una shell: la creación fraudulenta de usuarios, la modificación de contenidos y la ejecución remota de código son hallazgos diferentes y deben acreditarse por separado.

La prioridad es doble: recuperar el control del sitio y preservar información suficiente para explicar qué ocurrió. Borrarlo todo precipitadamente puede destruir las únicas evidencias que permitirían localizar la vía de entrada. Por el contrario, permanecer días estudiando una instalación comprometida y accesible puede permitir que el problema siga creciendo. La respuesta adecuada combina contención temprana, copia forense, saneamiento controlado y observación posterior.

Índice de contenidos

Qué es un ataque mediante API REST y qué es una web shell

WordPress ofrece interfaces públicas y privadas más allá de su pantalla de inicio de sesión. La API REST, normalmente accesible bajo /wp-json/, proporciona funcionalidades que utilizan el editor, los temas, los plugins y numerosas integraciones. Su existencia no constituye una vulnerabilidad. El problema aparece cuando una versión concreta de WordPress o de alguna extensión permite realizar operaciones que deberían exigir permisos, debido, por ejemplo, a una comprobación insuficiente de autorización o a un fallo encadenable con otro defecto.

Por qué bloquear wp-login.php no siempre detiene un ataque

Una configuración Nginx que prohíbe el acceso exterior a wp-login.php y a /wp-admin/ reduce la superficie de exposición administrativa. Sin embargo, no transforma automáticamente el resto de endpoints en privados. Un atacante que explota una ruta vulnerable no necesita necesariamente cargar el formulario tradicional de inicio de sesión. Tampoco podemos deducir que hubo robo de contraseña porque las publicaciones maliciosas aparezcan asociadas en la base de datos a un usuario administrador: el autor almacenado y quien ejecutó materialmente una solicitud no son conceptos equivalentes.

Qué significa realmente «web shell»

Una web shell es un mecanismo que permite controlar funciones del servidor mediante una interfaz accesible desde la web, frecuentemente un script PHP oculto o camuflado. Puede facilitar operaciones adicionales incluso después de corregir la vulnerabilidad inicial. Pero la aparición masiva de administradores o artículos fraudulentos, por sí sola, no demuestra que exista una shell. Hace falta hallar el componente, su comportamiento o evidencia de su ejecución. En este artículo utilizamos «intrusión con posible web shell» para no confundir una hipótesis con un hecho acreditado.

Indicadores de compromiso y alcance del incidente

La primera inspección debe distinguir señales visibles de las evidencias técnicas que las explican. El inventario inicial ayuda a establecer qué hay que contener y qué archivos o registros deben protegerse antes de modificar la instalación.

• Identidades: cuentas desconocidas, especialmente con rol de administrador, patrones de nombres generados automáticamente o fechas de alta agrupadas en pocos minutos.
• Contenido: páginas de desfiguración, entradas promocionales ajenas a la temática, borradores vacíos y ediciones no reconocidas de páginas legítimas.
• Actividad HTTP: solicitudes inusuales a endpoints REST, admin-ajax.php, rutas de plugins o archivos PHP inesperados; conviene correlacionarlas con las horas de las modificaciones.
• Sistema de archivos: PHP dentro de uploads, modificaciones inesperadas de mu-plugins, tareas cron nuevas o archivos ocultos sin justificación.
• Infraestructura: modificaciones en Nginx, servicios, permisos, credenciales de bases de datos y configuraciones compartidas con otros dominios.

Documenta también la zona horaria de Linux, WordPress y los logs. Una fecha de WordPress puede referirse a la hora local configurada, mientras que otros registros utilizan UTC. Comparar marcas temporales sin normalizarlas conduce fácilmente a conclusiones erróneas.

En servidores con varias instalaciones alojadas, delimita el alcance: ¿se ha comprometido únicamente una base de datos?, ¿hay archivos compartidos?, ¿todas las webs utilizan el mismo usuario del sistema?, ¿se han expuesto secretos reutilizados? No supongas que las demás instalaciones están afectadas, pero tampoco las descartes sin revisar el límite real de aislamiento.

Contener el ataque sin afectar a otras webs

La contención busca impedir nuevas modificaciones mientras se preserva información sobre lo ocurrido. Si aparecen cuentas o publicaciones nuevas en tiempo real, conviene reducir temporalmente la superficie pública del sitio comprometido: por ejemplo, restringir el dominio afectado a direcciones administrativas de confianza o presentar una página de mantenimiento servida por Nginx. La medida exacta depende de la arquitectura y de los requisitos de disponibilidad.

En un servidor con varios virtual hosts, nunca conviene apagar Nginx indiscriminadamente cuando el problema se limita a uno de ellos. Localiza primero el bloque server correcto, documenta su configuración y valida toda modificación con nginx -t antes de una recarga controlada. Conservar los registros durante la contención es esencial.

Actuaciones prioritarias

1. Registrar el momento en que se descubre el incidente y los síntomas observados.
2. Preservar el estado actual antes de alterar usuarios, contenidos, plugins o archivos.
3. Restringir el punto de exposición implicado o aislar la instalación si el ataque continúa activo.
4. Corregir cuanto antes la vulnerabilidad confirmada utilizando una versión con parche de seguridad.
5. Revocar accesos y revisar mecanismos alternativos de persistencia.

Una lista negra de direcciones IP puede servir para disminuir ruido, pero raramente basta como respuesta definitiva: un mismo incidente puede utilizar múltiples orígenes, proxies y herramientas. Tampoco es aconsejable bloquear /wp-json/ íntegramente sin evaluar dependencias, porque el editor y algunas integraciones legítimas lo necesitan.

Preservar copias y evidencias forenses

Una copia operativa permite restaurar el servicio; una copia forense permite investigar el estado que existía antes del saneamiento. Ambas deben conservarse separadas. La rotación automática de backups puede eliminar las evidencias históricas más interesantes sin que nadie intervenga manualmente. Por ello, la carpeta forense debe quedar fuera del ámbito de borrado del script habitual de copias y, preferiblemente, en un almacenamiento adicional no expuesto a la propia instalación comprometida.

Elementos mínimos que deben copiarse

• Volcado SQL completo de la base de datos afectada, con su fecha de obtención.
• Archivos WordPress completos, incluidos wp-content, plugins MU, uploads y configuraciones específicas.
• Configuración efectiva de Nginx, PHP-FPM y tareas programadas relacionadas.
• Logs de acceso y error disponibles, además de registros de autenticación si aportan información.
• Inventario de versiones, cuentas, roles, extensiones activas y elementos de arranque.
• Una relación cronológica de los cambios que realiza el administrador durante la respuesta.

Huellas y verificación

Una vez completada la adquisición, calcula hashes y conserva el manifiesto junto a la documentación de la captura. Este ejemplo trabaja sobre archivos que ya se encuentran en una ruta privada:

cd /ruta/privada/de/evidencias
sha256sum *.sql *.zip > SHA256SUMS.txt
sha256sum -c SHA256SUMS.txt

Para comprobar que un ZIP es legible sin restaurarlo sobre producción:

unzip -tq archivo-web.zip

Un resultado de integridad correcto demuestra que la copia puede leerse y que sus bytes coinciden con el hash calculado; no demuestra que estuviera libre de malware cuando se obtuvo. Tampoco reemplaza un ensayo de restauración aislado. Considera restringir los permisos de evidencias que puedan incluir datos personales, claves, cookies o configuraciones sensibles.

Por qué son valiosos varios backups separados en el tiempo

Un único volcado refleja un instante; una serie permite distinguir qué registros ya existían y cuáles aparecieron entre dos capturas. Las comparaciones diferenciales de tablas como wp_users, wp_usermeta, wp_posts y wp_options ayudan a reducir la ventana temporal del ataque. Lo adecuado es comparar copias en un entorno de análisis, no restaurarlas secuencialmente sobre la web productiva.

Reconstruir una cronología fiable

La investigación debe separar hechos observables, indicios e hipótesis. Una secuencia plausible no es automáticamente una secuencia probada. Por ejemplo, la fecha de alta de una cuenta y la creación de una publicación pueden coincidir, pero esta coincidencia no acredita por sí sola el mecanismo de ejecución ni la identidad del autor.

Consultar los registros de contenido sin alterar la base de datos

Si el prefijo real es wp_, la siguiente consulta SQL de solo lectura muestra las publicaciones más recientes. Sustituye el prefijo si la instalación utiliza otro y evita divulgar datos personales de forma innecesaria.

SELECT ID, post_type, post_status, post_author,
       post_date, post_modified, post_title
FROM wp_posts
WHERE post_type IN ('post', 'page')
ORDER BY post_date DESC
LIMIT 100;

Para los usuarios, conviene exportar IDs, nombres, fechas de alta y roles. Los roles se almacenan habitualmente en metadatos con una clave dependiente del prefijo de tablas. WP-CLI simplifica esta primera revisión y evita construir consultas que interpreten incorrectamente las capacidades serializadas:

WP=/ruta/wordpress
wp user list \
  --fields=ID,user_login,roles,user_registered \
  --format=csv --path="$WP" > /ruta/privada/usuarios.csv

Correlaciona después las oleadas detectadas con los accesos HTTP pertinentes. Busca por ventanas temporales acotadas y conserva las líneas completas de los logs originales. La ausencia de una solicitud no descarta actividad si el registro ya rotó, si el tráfico pasó por otro proxy o si la operación se ejecutó localmente. Documenta esos límites expresamente.

Corregir la vulnerabilidad y verificar WordPress

Recuperar usuarios y borrar entradas no sirve de mucho si la vulnerabilidad original continúa abierta. Identifica el aviso de seguridad aplicable a la versión instalada y actualiza hacia una versión oficial que incorpore la corrección. Es conveniente separar un parche de seguridad urgente de una migración mayor del entorno cuando ello reduzca el riesgo operativo, siempre que la versión elegida efectivamente corrija el fallo.

Inventario previo mediante WP-CLI

WP=/ruta/wordpress
wp core version --path="$WP"
wp core check-update --path="$WP"
wp plugin list --path="$WP"
wp theme list --path="$WP"

Después de aplicar el parche, verifica los archivos oficiales:

wp core verify-checksums --path="$WP"
wp plugin verify-checksums --all --path="$WP"
wp core update-db --dry-run --path="$WP"

Los checksums son una herramienta útil, pero su alcance es limitado. Un núcleo verificado puede coexistir con una cuenta administrativa fraudulenta, una opción de base de datos alterada, un archivo PHP añadido fuera del núcleo o un plugin personalizado comprometido. Las extensiones comerciales y los plugins MU pueden requerir una comparación manual con sus fuentes conocidas. Un error de descarga tampoco debe resolverse desactivando TLS ni cambiando permisos del sitio a 777.

Por seguridad operativa, los ejemplos no añaden --allow-root. Si el entorno obliga a emplear WP-CLI como root, ese parámetro existe, pero es preferible ejecutar tareas de aplicación bajo una identidad autorizada con privilegios mínimos. Antes y después de cada cambio, prueba portada, páginas interiores, administración e integraciones importantes.

Sanear cientos de usuarios fraudulentos con WP-CLI

Una campaña automatizada puede registrar cientos de usuarios sin utilizar el formulario convencional de alta. El volumen no justifica borrar inmediatamente todo lo que tenga un nombre extraño: primero se establece una lista blanca de cuentas legítimas, confirmada por quien administra el proyecto, y se conserva el inventario anterior a cualquier intervención.

1. Identificar a los usuarios y sus permisos

WP=/ruta/wordpress
wp user list \
  --fields=ID,user_login,user_email,roles,user_registered \
  --format=table --path="$WP"

Revisa también las contraseñas de aplicación. El comando de listado muestra metadatos como nombre, creación o último uso; no revela la contraseña en texto claro:

wp user application-password list NOMBRE_LEGITIMO \
  --fields=uuid,name,created,last_used,last_ip \
  --path="$WP"

2. Preservar primero y retirar permisos después

Si hay administradores no autorizados, registra su ID y los contenidos asociados antes de intervenir. Como contención reversible, una cuenta intrusa confirmada puede perder inmediatamente el rol administrativo y sus sesiones:

wp user set-role ID_INTRUSO subscriber --path="$WP"
wp user session destroy ID_INTRUSO --all --path="$WP"

Convertir administradores en suscriptores no los elimina. Es una etapa para reducir su capacidad de actuación mientras se comprueba la lista de identidades. El borrado definitivo debe ejecutarse solamente después de revisar la selección y decidir qué sucederá con el contenido asociado a esas cuentas.

3. Borrar por lotes sin improvisar filtros destructivos

WP-CLI admite varios identificadores en una misma invocación de wp user delete, evitando cargar WordPress una vez por cada uno de cientos de usuarios. La lista de IDs debe prepararse y revisarse previamente fuera de producción. Una operación típica, ilustrativa y no lista para ejecutar sin esa revisión, tiene esta forma:

wp user delete ID_INTRUSO_1 ID_INTRUSO_2 ID_INTRUSO_3 \
  --reassign=ID_RECEPTOR --yes --path="$WP"

La opción --reassign conserva contenidos transfiriéndolos a la cuenta indicada; también puede atribuirle publicaciones maliciosas. Omitirla puede eliminar contenidos vinculados a los usuarios borrados. No existe una elección universal: debe decidirse con el inventario y la copia forense delante. Conviene revisar además las cuentas sin rol y las cuentas no administrativas, ya que no todas las intrusiones mantienen a sus usuarios con permisos elevados.

4. Renovar las credenciales de las cuentas legítimas

Una vez restablecido el control, utiliza contraseñas únicas y largas. Para evitar que una contraseña quede escrita en el historial del terminal, WP-CLI puede solicitarla interactivamente:

wp user update NOMBRE_LEGITIMO \
  --prompt=user_pass --path="$WP"

Invalida las sesiones anteriores y revisa, revocando cuando proceda, las contraseñas de aplicación:

wp user session destroy NOMBRE_LEGITIMO --all --path="$WP"
wp user application-password delete NOMBRE_LEGITIMO \
  --all --path="$WP"

Si alguna integración autorizada utiliza estas credenciales, habrá que reconfigurarla. La rotación de claves de autenticación y sales de WordPress puede formar parte de la respuesta y afecta a las cookies, por lo que debe coordinarse con la revocación de sesiones y mantenerse fuera de documentos públicos. La sustitución de contraseñas no reemplaza la búsqueda de una puerta trasera.

Identificar y retirar artículos y páginas piratas

La revisión de contenido debe abarcar entradas y páginas, tanto publicadas como en borrador. Los atacantes pueden crear registros sin título, repetir una misma publicación en grupos o modificar páginas antiguas para esconder enlaces. Por otra parte, no todas las modificaciones recientes son maliciosas: una revisión automática, un editor o una intervención legítima también pueden cambiar fechas.

Inventario de publicaciones recientes

wp post list \
  --post_type=post,page --post_status=any \
  --orderby=modified --order=DESC --posts_per_page=100 \
  --fields=ID,post_type,post_status,post_date,post_modified,post_title \
  --format=table --path="$WP"

Primero identifica los IDs y coteja las publicaciones dudosas con los backups previos. Después, para retirar un registro confirmado sin destruir de inmediato su contenido, envíalo a la papelera:

wp post update ID_CONFIRMADO \
  --post_status=trash --path="$WP"

Verifica después la lista de publicaciones activas y comprueba el comportamiento de enlaces, menús y sitemap. Evita las órdenes que borran todas las entradas de un tipo o todos los contenidos modificados después de una fecha. Un registro fraudulento puede compartir minuto de modificación con contenidos legítimos. Tampoco conviene vaciar la papelera antes de conservar el detalle de lo retirado.

Restaurar páginas legítimas alteradas

Cuando la intrusión afecta al texto de una página existente, el objetivo es recuperar únicamente el contenido dañado, no sustituir indiscriminadamente toda la base de datos por una versión antigua. Compara versiones, revisiones de WordPress y volcados SQL, documenta qué campos se restauran y comprueba que el diseño, los enlaces internos y los metadatos SEO siguen correctos. La restauración editorial y la eliminación de una vulnerabilidad son tareas distintas que deben coordinarse.

Buscar web shells y mecanismos de persistencia

Tras cerrar la vía de entrada conocida y retirar cuentas falsas, hay que comprobar si el atacante dejó otra forma de volver. Esta fase no puede resolverse únicamente con wp core verify-checksums: muchos elementos relevantes se encuentran fuera del núcleo y pueden no estar cubiertos por firmas oficiales.

Rutas que merecen especial atención

• wp-content/uploads/: normalmente almacena recursos subidos; archivos PHP inesperados requieren investigación.
• wp-content/mu-plugins/: sus componentes se cargan automáticamente y pueden no aparecer como un plugin normal activable.
• wp-content/plugins/ y el tema activo: comparar contra versiones originales, respetando modificaciones legítimas.
• La raíz web, configuraciones de PHP y archivos de inicio: buscar añadidos o cambios no autorizados.
• Las tareas programadas del sistema y de WordPress: detectar ejecuciones inesperadas y revisar qué usuario las controla.

Inventario no destructivo de archivos recientes

El siguiente ejemplo identifica archivos PHP modificados en un periodo reciente. Una fecha reciente es un criterio de búsqueda, no una sentencia de culpabilidad:

find /ruta/wordpress/wp-content -type f -name '*.php' \
  -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

Conviene comparar hashes y contenidos con una distribución confiable del plugin o tema. Inspecciona de manera estática cualquier archivo sospechoso: no lo abras a través del navegador ni ejecutes su código para «ver qué hace». Si se necesita análisis dinámico, debe realizarse en un entorno aislado por personal especializado.

Revisar las tareas programadas

crontab -l
ls -la /etc/cron.d/ /etc/cron.daily/
wp cron event list --path="$WP"

Los cron de Linux y los eventos programados de WordPress son mecanismos diferentes. Ambos pueden ser legítimos, pero un ejecutable inesperado o una tarea nueva que restaure usuarios fraudulentos puede explicar por qué el problema reaparece después de cada limpieza. Si se confirma un elemento malicioso, conserva una copia y su hash antes de desactivarlo o retirarlo.

¿Y si el sistema operativo también está comprometido?

Si existen evidencias fiables de ejecución arbitraria con permisos elevados, cambios en binarios del sistema o compromisos fuera del árbol WordPress, una simple limpieza de archivos deja de ser suficiente. Puede resultar más seguro reconstruir el entorno desde una imagen de sistema confiable, rotar secretos afectados y restaurar únicamente datos previamente revisados. La decisión debe tomarse a partir del alcance observado, no solo del mensaje que aparece en la portada.

Revisar las protecciones de Nginx y la API REST

Las reglas del proxy deben responder al modelo real de uso del sitio. Es perfectamente razonable limitar wp-login.php y /wp-admin/ a ubicaciones de confianza; sin embargo, un sitio puede seguir necesitando rutas públicas para lectura de contenido, recursos del editor o determinados plugins. La API REST no es sinónimo de acceso administrativo: lo importante es que cada operación sensible valide correctamente autenticación y permisos.

Qué comprobar sin debilitar una configuración existente

1. Identificar el archivo de configuración que corresponde al dominio afectado; no aplicar cambios globales a otros virtual hosts por comodidad.
2. Confirmar cómo se registran las peticiones y conservar la IP de origen real cuando intervienen proxies confiables.
3. Examinar las rutas utilizadas durante las oleadas de creación de cuentas o publicaciones.
4. Verificar si el componente vulnerable ya está parcheado y si quedan endpoints adicionales creados por extensiones.
5. Validar cualquier modificación de configuración con nginx -t antes de recargar el servicio.

Una restricción de acceso es una capa defensiva y no sustituye el mantenimiento. También debe evitarse publicar archivos de copias SQL, registros y manifiestos forenses en directorios accesibles mediante HTTP. La documentación oficial de endurecimiento de WordPress ofrece criterios generales para reducir privilegios y controlar los puntos de escritura.

Endurecimiento posterior de WordPress y Linux

Después de recuperar el servicio conviene aprovechar el incidente para reducir su exposición futura. El endurecimiento sostenible no consiste en añadir decenas de reglas incomprensibles, sino en implantar controles comprobables, documentados y compatibles con el funcionamiento del proyecto.

Mantenimiento y privilegios

• Mantener núcleo, PHP, sistema operativo y extensiones en versiones con soporte de seguridad, revisando compatibilidad antes de los cambios mayores.
• Eliminar extensiones sin uso y mantener inventario de plugins comerciales, personalizados y MU.
• Aplicar el principio de mínimos privilegios: no todos los usuarios editoriales necesitan ser administradores.
• Usar MFA cuando esté disponible y contraseñas diferentes para WordPress, SSH, base de datos y servicios externos.
• Revisar los permisos de escritura y evitar que el usuario del proceso web pueda modificar innecesariamente todo el código ejecutable.

Vigilancia, logs y copias

Una revisión periódica del número de usuarios, los cambios de rol, las publicaciones nuevas y los archivos ejecutables añadidos permite detectar anomalías antes de que se conviertan en centenares de registros. Los logs deben retenerse durante un plazo suficiente y las copias críticas deben existir fuera del mecanismo que las genera. Un backup en el mismo servidor puede ser útil, pero no constituye por sí solo una estrategia de recuperación frente al compromiso completo de la máquina.

Planifica pruebas de restauración en un entorno independiente, documenta la versión de cada componente y conserva un procedimiento de emergencia para restringir únicamente el sitio afectado. Para el uso y la sintaxis de los comandos, consulta la referencia oficial de WP-CLI.

Comprobaciones para dar por recuperado el servicio

Que desaparezcan las cuentas fraudulentas y los artículos piratas es un avance visible, pero no constituye una certificación de limpieza. El cierre del incidente exige verificar que la vulnerabilidad inicial ya no es explotable en el estado actualizado, que no se observan mecanismos de persistencia y que el funcionamiento legítimo se ha recuperado.

Lista de validación operativa

1. La relación actual de usuarios coincide con el inventario autorizado y los roles son los correctos.
2. Se han renovado las credenciales pertinentes, cerrado sesiones antiguas y revisado contraseñas de aplicación.
3. Las publicaciones fraudulentas se encuentran retiradas y las páginas originales están comprobadas.
4. El núcleo verifica sus checksums y los componentes no cubiertos por ellos se han revisado por separado.
5. No aparecen archivos, tareas programadas ni cambios nuevos que expliquen un mecanismo de persistencia.
6. Las rutas y solicitudes relacionadas con el incidente se han contrastado con los registros disponibles.
7. Funcionan portada, administración, buscador, formularios, sitemap, enlaces permanentes y componentes comerciales o de pago afectados.
8. Existe una copia nueva del estado recuperado, distinguible de las evidencias del estado comprometido.

Establece una línea base tras la limpieza y repite las comprobaciones durante los días siguientes. Si reaparecen usuarios o artículos, no te limites a borrarlos otra vez: la persistencia o una vía de entrada sigue activa. En ese caso vuelve a contener el servicio y amplía la investigación.

Errores frecuentes durante el saneamiento

Restaurar un SQL antiguo sobre producción sin compararlo

Puede hacer desaparecer cambios legítimos, pedidos, páginas o configuraciones, y no limpia los archivos del servidor. Es mejor delimitar los registros afectados y restaurarlos selectivamente cuando sea viable.

Confundir cambio de rol con eliminación de una cuenta

Un administrador convertido en suscriptor continúa existiendo. Es una medida de contención útil, pero el inventario final debe revisarse tras el borrado aprobado. No se deben dar por eliminadas cuentas que solo han perdido privilegios.

Borrar usuarios mediante SQL directo

Una eliminación directa en wp_users puede dejar metadatos huérfanos y saltarse comportamientos de limpieza del propio WordPress. Salvo necesidades forenses especializadas, se deben utilizar las API de la aplicación o WP-CLI, con selección revisada y backup.

Reasignar todo el contenido a un administrador sin revisarlo

Esta decisión conserva registros, pero puede atribuir al usuario legítimo publicaciones fraudulentas. La alternativa de eliminar contenidos asociados también tiene riesgos. Documenta explícitamente qué opción se adopta y por qué.

Concluir que la web está limpia solo porque los checksums son correctos

La verificación oficial no cubre todas las rutas ni la base de datos. Tampoco identifica necesariamente una web shell añadida como archivo nuevo. La revisión de persistencia es una fase separada.

Seguir investigando sin contener una intrusión activa

El análisis forense no debe convertirse en una excusa para dejar abierta una vía que continúa creando cuentas o alterando el contenido. Es legítimo realizar una contención documentada antes de completar todas las conclusiones, siempre preservando las evidencias esenciales.

Preguntas frecuentes