Cuando recibimos la web de una clínica dental, se abría y parecía funcionar con normalidad. Las páginas estaban disponibles y el acceso a WordPress funcionaba. Sin embargo, al revisar el servidor encontramos scripts maliciosos, código oculto en la carpeta de un plugin y siete administradores sospechosos.
A continuación explicamos cómo detectamos el ataque y limpiamos la web. También repasamos 12 señales que pueden ayudar al propietario o a un especialista a identificar un problema parecido.
Cómo una comprobación de accesos se convirtió en una investigación
Tras recibir el proyecto, comprobamos los accesos y después revisamos los archivos y la configuración del servidor.
Se encontraron archivos que no están en la distribución oficial en las carpetas del sistema de WordPress. Al lado había un archivo de configuración .htaccess: permitía al servidor ejecutar scripts con una extensión no estándar.
Examinamos su contenido. Los scripts recibían órdenes externas y las ejecutaban en el servidor. Eran puertas traseras: mecanismos ocultos de acceso a la web.
La revisión continuó. En una subcarpeta de un plugin encontramos otro archivo malicioso de unos 538 KB. Contenía un bloque codificado que se cargaba y ejecutaba como código PHP. Después revisamos los usuarios de WordPress y detectamos siete cuentas sospechosas con permisos de administrador.
Para estudiar el historial de la infección, comparamos los hallazgos con las fechas de los archivos y los registros de acceso. Los metadatos señalaban cambios a finales de junio; los registros de agosto contenían peticiones a direcciones características de las puertas traseras. Los archivos maliciosos habían sobrevivido a una actualización de WordPress.
Así confirmamos la presencia de puertas traseras y accesos administrativos ajenos. Los datos recopilados no permitieron establecer el punto de entrada inicial. Las fechas de los archivos tampoco demuestran el día exacto del ataque: pueden modificarse.
12 señales que ayudan a detectar el hackeo
Encontramos los primeros cuatro signos en este proyecto. El resto se incluyó en la lista de verificación para verificar otros sitios.
1. Aparecieron administradores desconocidos en el panel de administración.
Toda cuenta con plenos derechos debe tener un propietario claro. Un usuario desconocido puede resultar ser un antiguo contratista, por lo que primero debe averiguar quién lo creó y por qué.
Después de la comprobación eliminamos siete administradores sospechosos y conservamos los accesos necesarios para trabajar.
2. Hay archivos extraños en las carpetas del sistema.
Es necesario verificar los nuevos scripts y los directorios desconocidos dentro del núcleo de WordPress. Nuestros archivos estándar fueron verificados con el original, pero había archivos maliciosos junto a ellos.
Las sumas de comprobación de WordPress permiten comparar los archivos del núcleo con la distribución oficial. Los plugins, los temas, los archivos subidos y la base de datos deben revisarse por separado.
3. El código incomprensible está oculto en el complemento o en la carpeta del tema.
Razón para mirar más de cerca: un archivo PHP desconocido entre imágenes y estilos, bloques codificados largos, código que carga o ejecuta otro contenido.
Uno de nuestros hallazgos tenía ese aspecto. Sin embargo, un bloque codificado no demuestra por sí solo una infección: hay que analizar lo que hace el programa. Encontrar una puerta trasera en la carpeta de un plugin tampoco demuestra que el ataque se produjera a través de ese plugin.
4. La configuración del servidor cambió sin su conocimiento
Es posible que aparezcan redirecciones o reglas de otra persona en .htaccess que permitan ejecutar archivos con extensiones inusuales.
Estas reglas permitían ejecutar los scripts maliciosos. Por eso revisamos tanto las puertas traseras como las condiciones que permitían ejecutarlas.
5. Aparecen scripts ejecutables en la carpeta de archivos subidos
Conviene comprobar que el directorio de fotos y documentos no contenga programas desconocidos. Revisar las extensiones no basta: la posibilidad de ejecutar un archivo también depende de la configuración del servidor.
Durante la limpieza revisamos por separado los archivos subidos e impedimos la ejecución de tipos de archivo peligrosos en esa carpeta.
6. Aparecieron páginas en la búsqueda que nadie había publicado
Por ejemplo, el sitio web de la clínica se encuentra para consultas sobre casinos o productos de otras personas. La verificación comienza con direcciones específicas: qué se abre en ellas, de dónde proviene el contenido, si está en el panel de administración.
Una URL desconocida puede ser una página antigua o una duplicada. Una dirección larga y la terminación -2 no indican en sí mismas piratería.
7. Los visitantes son redirigidos a sitios de terceros.
El propietario ve la página habitual, pero alguien que llega desde un buscador termina en publicidad o en otra web. Conviene comparar las visitas desde búsquedas con el acceso directo y comprobar la web desde un móvil y sin iniciar sesión.
Estas redirecciones se describen en la ayuda de seguridad de Google.
8. El navegador, el motor de búsqueda o el alojamiento informan de una amenaza.
Es necesario comprobar la notificación: qué archivo o dirección la activó, qué se detectó exactamente.
Google Search Console tiene una sección «Problemas de seguridad» para esto. Puede mostrar ejemplos de páginas infectadas, pero la lista no es necesariamente completa. La ausencia de advertencias tampoco confirma la limpieza del servidor.
9. Aparecieron tareas programadas desconocidas.
Las tareas en segundo plano se utilizan para copias de seguridad, notificaciones y actualizaciones. Las sospechas surgen de tareas cuyo propósito nadie puede explicar, especialmente si ejecutan un archivo desconocido.
Debes verificar tanto las tareas de WordPress como el cronograma en el panel de alojamiento. Estas son listas diferentes.
10. El servidor crea una carga inexplicable o envía correos electrónicos no deseados.
La web se ralentiza sin que aumenten las visitas, el proveedor de alojamiento advierte de envíos de correo y el consumo de recursos crece de forma brusca.
La causa puede ser un programa malicioso, un fallo de un plugin o una copia de seguridad que consuma muchos recursos. Los registros y la revisión de procesos ayudan a identificar qué archivo se está ejecutando y qué hace.
11. Los registros contienen llamadas a scripts sospechosos.
En este proyecto encontramos esas peticiones. Antes de la limpieza también se podía acceder por HTTP a las puertas traseras detectadas.
Que un bot acceda a un archivo inexistente no demuestra que el ataque haya tenido éxito. Ni siquiera una respuesta 200 OK prueba que se haya ejecutado una instrucción. Hay que relacionar las peticiones con el contenido del archivo y con otros eventos del servidor.
12. Después de la eliminación, los archivos o páginas extraños vuelven a aparecer.
Hay que buscar un acceso que siga activo: otra puerta trasera, un administrador desconocido, una tarea en segundo plano o credenciales robadas.
Si elimina sólo el archivo que aparece, el problema puede volver a ocurrir. Necesitamos descubrir quién o qué lo está restaurando.
Con esta lista es conveniente recopilar preguntas para su verificación. El número de coincidencias no determina el diagnóstico: la piratería se confirma mediante archivos, acciones y cambios específicos.
Cómo limpiamos el sitio
Primero conservamos las pruebas de la investigación. Trasladamos los archivos maliciosos a una cuarentena de acceso restringido, fuera del directorio público. Allí guardamos también la configuración original y los datos de los archivos. Antes de eliminar usuarios hicimos una copia de la base de datos.
Este orden le permite no perder pruebas y comprobar los cambios si algo sale mal después de la restauración. Las instrucciones de WordPress después del hackeo también recomiendan guardar el estado del sitio antes de limpiarlo.
Después restauramos los archivos: reinstalamos el núcleo de WordPress desde el paquete oficial, sustituimos el plugin infectado mediante una actualización oficial y eliminamos el directorio antiguo y sin uso de otro plugin. Actualizamos los componentes para los que había paquetes disponibles. No dimos por actualizados los plugins comerciales que tenían restricciones de actualización.
Eliminamos los siete administradores sospechosos, cerramos las sesiones antiguas de los usuarios que conservamos y cambiamos las claves secretas de autenticación de WordPress. Cambiar estas claves no sustituye cambiar las contraseñas.
La protección de archivos se ha reforzado por separado:
- impedimos ejecutar scripts en la carpeta de archivos subidos;
- restringimos la subida de tipos de archivo peligrosos;
- desactivamos la edición de archivos desde el panel de administración;
- restringimos el acceso a archivos de configuración y del sistema;
- desactivamos el registro de usuarios que no era necesario.
Estas configuraciones reducen las posibilidades de reinfección. Funcionan junto con actualizaciones y control de acceso como se describe en las Mejores prácticas de seguridad de WordPress.
Lo que mostró la nueva verificación
Tras la limpieza, los archivos del núcleo coincidieron con las sumas de comprobación oficiales. Las direcciones conocidas de las puertas traseras devolvían 404; la página de inicio y el acceso a WordPress funcionaban. La nueva búsqueda no encontró los archivos maliciosos detectados anteriormente ni las señales de infección comprobadas.
La base de datos también superó la comprobación de su estructura. Esto acredita su funcionamiento técnico, pero no demuestra por sí solo que carezca de contenido malicioso.
Confirmamos que las puertas traseras detectadas se habían eliminado y que la web funcionaba tras los cambios. Para cerrar por completo el incidente hay que revisar por separado los accesos comprometidos, las tareas del alojamiento y todos los componentes. Una comprobación satisfactoria del núcleo no basta.
Por dónde empezar si notas signos similares
Para contactar con un especialista o con el servicio de hosting, resulta útil recopilar ejemplos concretos: la dirección de una página sospechosa, una captura de pantalla de un aviso, la hora de la redirección, el nombre de un usuario desconocido. Luego guarde los registros y una copia del estado actual del sitio por separado de las copias de seguridad limpias conocidas.
Si un sitio ya está redirigiendo visitantes o distribuyendo contenido malicioso, el acceso a páginas peligrosas debería limitarse rápidamente. La eliminación masiva de archivos al azar puede dañar el sitio y destruir rastros que podrían ayudar a solucionarlo.
En este caso, la web seguía abriéndose antes de la revisión. Detectamos las puertas traseras al comparar archivos, estudiar la configuración y comprobar los administradores. Por eso, al recibir un proyecto revisamos tanto la disponibilidad de las páginas como lo que hay en el servidor.