Nos hackearon: por qué no bastaba con limpiar el malware

Durante años hemos ayudado a empresas a recuperar sitios WordPress comprometidos. Hemos limpiado malware, eliminado puertas traseras y reconstruido webs que habían perdido el control de su instalación.

Esta vez, el ataque fue contra nuestra propia web.

El pasado 1 de agosto, nuestra página fue comprometida. WordPress estaba actualizado, Wordfence correctamente configurado y el servidor contaba con varias capas de protección. Aun así, el atacante consiguió acceder utilizando credenciales válidas.

Durante aproximadamente cinco horas investigamos el incidente, analizamos los registros, limpiamos la instalación, aseguramos el servidor y aplicamos bloqueos para dificultar nuevos ataques similares.

Podríamos habernos limitado a restaurar una copia de seguridad. En cambio, decidimos entender exactamente qué había ocurrido antes de eliminar las pruebas.

Qué ocurrió

El análisis de los registros permitió reconstruir la secuencia general del ataque. Por motivos de seguridad, omitimos indicadores concretos y detalles que pudieran facilitar una intrusión similar.

Acceso al panel de administración

El atacante accedió a WordPress utilizando credenciales válidas.

No encontramos evidencias de una explotación directa del núcleo ni de un ataque de fuerza bruta. Todo apuntaba a que disponía de acceso legítimo a una cuenta con privilegios administrativos.

Desde el punto de vista de WordPress, el inicio de sesión parecía normal.

Instalación de un plugin malicioso

Una vez dentro del panel, utilizó el instalador oficial de plugins.

No necesitó subir los archivos mediante FTP ni acceder inicialmente al panel del servidor. Siguió el mismo flujo que emplearía cualquier administrador para instalar una extensión.

En pocos segundos, el código malicioso empezó a ejecutarse.

Creación de una puerta trasera

El plugin instalado añadió un mecanismo que permitía ejecutar acciones sin volver a autenticarse normalmente en WordPress.

Eso permitió al atacante continuar trabajando aunque el plugin inicial desapareciera. Por ese motivo, eliminarlo sin revisar el resto de la instalación habría dejado el incidente sin resolver.

Modificaciones y persistencia

Horas después aparecieron cambios en otros archivos del sitio. El objetivo era conservar el acceso y dificultar la detección.

Las modificaciones no eran numerosas ni especialmente llamativas. Estaban repartidas en ubicaciones estratégicas, lo que hacía difícil encontrarlas durante una revisión superficial.

Cómo investigamos el WordPress hackeado

Toda la investigación se realizó directamente sobre el VPS mediante SSH.

Trabajar desde la consola nos permitió revisar tanto WordPress como el servidor y comparar los cambios encontrados con la cronología de los accesos.

Utilizamos herramientas como:

• WP-CLI para revisar la integridad del núcleo, usuarios, plugins y tareas programadas;
• grep para localizar patrones sospechosos en archivos PHP y registros;
• find para identificar archivos modificados en intervalos concretos;
• stat para comprobar las fechas de modificación;
• las herramientas del sistema para aplicar bloqueos;
• Nginx para restringir el acceso al área de administración;
• Plesk para revisar el alojamiento y el estado de los servicios.

Los logs permitieron reconstruir el ataque

Los registros del servidor fueron determinantes. En ellos pudimos relacionar:

• el inicio de sesión;
• el acceso al área de administración;
• la instalación del plugin;
• la primera ejecución del código malicioso;
• las modificaciones posteriores;
• las conexiones realizadas durante la fase de persistencia.

Sin esos datos solo habríamos visto el resultado final: una instalación con archivos alterados. Los logs permitieron entender cómo se había desarrollado el incidente.

Qué revisamos durante las cinco horas de trabajo

La investigación y recuperación incluyeron:

• integridad del núcleo de WordPress;
• plugins oficiales y plugins modificados;
• usuarios con permisos de administración;
• sesiones activas;
• tareas cron;
• archivos PHP fuera de las ubicaciones habituales;
• plugins obligatorios o MU Plugins;
• registros HTTP;
• registros del panel del servidor;
• reglas del firewall;
• direcciones IP relacionadas con el ataque;
• mecanismos de persistencia;
• permisos de archivos y directorios.

No revisamos únicamente la web. También comprobamos el entorno que la alojaba y las posibles vías de reentrada.

Cómo recuperamos y aseguramos la instalación

Después de reconstruir el incidente, aplicamos varias medidas:

• reinstalamos el núcleo oficial de WordPress;
• sustituimos los plugins modificados;
• eliminamos las puertas traseras;
• revisamos los usuarios administradores;
• cerramos las sesiones activas;
• cambiamos las credenciales;
• bloqueamos las direcciones IP implicadas;
• restringimos el acceso al panel de administración;
• revisamos la configuración del servidor;
• reforzamos el firewall;
• comprobamos que no quedaran archivos modificados ni mecanismos de persistencia.

El objetivo no era solo volver a poner la web en funcionamiento. También queríamos cerrar las vías utilizadas durante el ataque y reducir el riesgo de que se repitiera.

Lo que aprendimos

La investigación confirmó algo que vemos con frecuencia al trabajar en webs de clientes: un incidente de seguridad no termina necesariamente cuando desaparece el archivo más visible.

La diferencia está en saber responder a preguntas concretas:

• ¿Cómo consiguió entrar el atacante?
• ¿Qué permisos tenía?
• ¿Qué archivos modificó?
• ¿Existían otras puertas traseras?
• ¿Seguía teniendo acceso?
• ¿Qué parte de la infraestructura debía reforzarse?

En nuestro caso, el análisis nos permitió incorporar nuevas medidas a los protocolos de seguridad que aplicamos en los sitios que gestionamos.

Cada incidente que resolvemos para un cliente nos enseña algo. Este nos enseñó todavía más porque el cliente éramos nosotros mismos.

¿Nos avergüenza haber sufrido un ataque?

No.

Nos preocuparía mucho más haber sufrido un ataque y no haber sido capaces de entender qué ocurrió.

La seguridad absoluta no existe. Incluso una instalación actualizada y protegida puede verse comprometida si un atacante obtiene credenciales válidas.

Lo importante es disponer de un procedimiento para detectar el incidente, conservar las evidencias, contenerlo y recuperar el control.

Hoy nuestra infraestructura es más robusta porque este ataque nos obligó a revisar cada capa: autenticación, WordPress, servidor, firewall, accesos y procedimientos internos.

Por eso hemos decidido contar lo ocurrido.

No para demostrar que somos inmunes, sino para mostrar cómo respondemos cuando un incidente sucede de verdad.

¿Crees que tu WordPress ha sido hackeado?

Si tu web redirige a páginas extrañas, muestra avisos de seguridad, carga código desconocido o ha creado usuarios que no reconoces, no esperes a que el problema empeore.

En Ibero Studio investigamos webs WordPress comprometidas, analizamos los registros del servidor, eliminamos el malware, cerramos las puertas traseras y reforzamos la instalación para reducir el riesgo de nuevos ataques.

No nos limitamos a borrar archivos sospechosos: buscamos cómo entró el atacante y qué hay que corregir para recuperar realmente el control de la web.

Llámanos o escríbenos y revisaremos tu caso. Te ayudaremos a recuperar tu WordPress y a protegerlo frente a futuras intrusiones.

Necesito recuperar mi WordPress hackeado