Sitio hackeado o caído: qué hacer en las primeras horas

Abres el sitio de tu empresa y aparece una página de casino. O Google muestra un aviso rojo que dice que el sitio es peligroso. O el sitio simplemente no carga y el teléfono empieza a sonar. La primera reacción es borrar lo que parece raro y esperar que no vuelva. Casi siempre vuelve.

Que hackeen un sitio es más común de lo que parece, y el error más caro ocurre en las primeras horas. En el informe de sitios hackeados de Sucuri, publicado en 2024 con datos de 39.594 sitios limpiados por su equipo en 2023, el 49,21% de los sitios tenía al menos una puerta trasera instalada. Una puerta trasera (backdoor) es un archivo oculto que permite al atacante volver cuando quiera. Borrar solo lo que aparece en pantalla no elimina ese archivo. Esta guía muestra el orden correcto.

Hora 1: frena el daño antes de investigar

El objetivo de la primera hora no es arreglar. Es evitar que la cosa empeore.

• Pon el sitio en mantenimiento o desconéctalo. Una página simple de “volvemos pronto” protege a quien visita y evita que Google siga indexando contenido del atacante.
• Cambia todas las contraseñas. Panel del sitio, hosting, base de datos, FTP, correo del dominio y cuenta del registrador del dominio. Usa contraseñas nuevas y activa la verificación en dos pasos donde se pueda.
• Revoca los accesos que no reconoces. Usuarios administradores creados en los últimos días, claves de acceso antiguas, exproveedores que todavía entran al panel.
• Avisa a quien necesita saberlo. Atención al cliente, ventas y quien gestiona el correo. Si llaman clientes, todos dicen lo mismo.

Si no tienes acceso a nada de esto porque todo está a nombre de un proveedor anterior, ese es el primer problema que resolver. Ya escribimos sobre cómo recuperar el código y los accesos cuando el freelancer desaparece, y la lógica es la misma.

Hora 2: guarda pruebas antes de limpiar

Parece contraintuitivo, pero antes de borrar nada, haz una copia del estado actual. Archivos, base de datos y registros de acceso del servidor (los logs).

Esa copia sirve para tres cosas:

1. Descubrir por dónde entró el atacante.
2. Saber si llegó a datos de clientes.
3. Tener un registro, por si debes notificar a la ANPD o responder a un cliente.

Guarda la copia fuera del servidor hackeado. Y no la confundas con un backup: esa copia está contaminada y no debe usarse para restaurar nada.

Por dónde entró el atacante

Limpiar sin descubrir la puerta de entrada es cambiar la alfombra con la ventana abierta. Las entradas más comunes en sitios de empresa son:

• Sistema desactualizado. Según Sucuri, el 39,1% de los sitios hackeados usaba un gestor de contenidos (CMS) desactualizado al momento de la infección.
• Plugins y temas abandonados. Un plugin que nadie actualiza hace años es una puerta que los atacantes ya conocen.
• Contraseña débil o filtrada. Sobre todo en el panel de administración y en el hosting.
• Acceso olvidado. Un exproveedor, un usuario de prueba, una clave de API que nunca se revocó.

El mismo informe muestra lo que suele hacer el atacante una vez dentro. El 20,3% de los sitios limpiados tenía spam de SEO: páginas falsas de medicamentos, casino o texto en japonés creadas dentro de tu dominio para aprovechar su reputación en Google. Por eso a veces el sitio se ve normal para ti y extraño para quien llega desde la búsqueda.

Un detalle del informe: el 95,5% de los sitios infectados que limpió Sucuri eran WordPress. La propia empresa aclara que eso refleja su base de clientes y no prueba que una plataforma sea más insegura que otra. Lo que pesa es el mantenimiento, no la marca del sistema.

Limpia todo el sitio, no solo la página visible

Con la puerta de entrada identificada, la limpieza tiene cuatro partes:

1. Cerrar la falla. Actualizar el sistema, quitar plugins abandonados, corregir la configuración que dejó la puerta abierta.
2. Eliminar todo lo que puso el atacante. Archivos alterados, puertas traseras, usuarios falsos, páginas de spam y redirecciones.
3. Revisar la base de datos. El spam y los scripts maliciosos también quedan guardados ahí, no solo en los archivos.
4. Restaurar solo lo que esté comprobadamente limpio. El backup sirve si es anterior al ataque. Si no sabes cuándo empezó, el backup también puede estar contaminado.

La ayuda de Google Search Console es clara en un punto: corregir solo algunas páginas no devuelve el sitio a la búsqueda. El problema tiene que desaparecer de todas.

El aviso de Google: cómo quitarlo

Si Google marcó el sitio como peligroso, quien busca ve una alerta antes de entrar, y mucha gente desiste ahí. Para quitar el aviso:

• Abre el informe de problemas de seguridad en Search Console. Muestra el tipo de problema, cuándo se detectó y ejemplos de páginas afectadas.
• Corrige todos los problemas listados, en todas las páginas.
• Haz clic en solicitar revisión y explica el problema, lo que hiciste y el resultado.

Según el propio Google, la revisión puede tardar de unos días a unas semanas. Y Google pide no reenviar la solicitud antes de recibir respuesta. La guía de revisión de web.dev lo refuerza: pedir revisión con el problema todavía activo solo alarga el tiempo que el sitio queda marcado.

Es decir, una limpieza mal hecha no cuesta solo el retrabajo. Cuesta más semanas con el aviso rojo delante de quien busca tu empresa.

Si hubo datos personales, el plazo de la LGPD ya corre

Formulario de contacto, registro de clientes, área privada, pedidos. Si el sitio guarda datos personales y el atacante pudo llegar a ellos, la LGPD (ley brasileña de protección de datos) fija un plazo.

Según la página de incidentes de seguridad de la ANPD, la Resolución CD/ANPD n.º 15/2024 exige que el controlador notifique a la ANPD y a los titulares afectados en un plazo de 3 días hábiles cuando el incidente pueda causar un riesgo o daño relevante. La copia que guardaste en la hora 2 es lo que permite decir con precisión qué se filtró y qué no.

En esta parte, involucra a tu abogado o al encargado de datos de la empresa. La decisión de notificar es jurídica. El papel del equipo técnico es dar la respuesta correcta sobre lo que se accedió.

Limpiar o rehacer el sitio

Después de la emergencia llega la pregunta que nadie quiere hacerse: ¿vale la pena mantener este sitio?

Limpiar y actualizar funciona cuando:

• El sitio es reciente y la base está al día.
• La falla fue puntual, como una contraseña filtrada.
• Hay alguien a cargo de las actualizaciones de aquí en adelante.

Rehacerlo tiene más sentido cuando:

• El sistema y los plugins llevan años de atraso.
• Nadie sabe quién hizo el sitio ni cómo se armó.
• Es el segundo o el tercer ataque.

Si el sitio ya mostraba otras señales de vejez, lee las señales de que llegó la hora de rehacer el sitio de la empresa antes de pagar por una limpieza que se va a repetir.

Cómo no pasar por esto otra vez

La mayoría de los ataques empieza por algo que alguien dejó de hacer. Lo mínimo:

• Actualizaciones aplicadas con frecuencia, no solo cuando algo se rompe.
• Backups automáticos, guardados fuera del servidor y probados.
• Cuentas, dominio y hosting a nombre de la empresa, con verificación en dos pasos.
• Alguien revisando el sitio todos los días. Es la idea detrás de monitorear el sistema para saber del error antes que el cliente.

Cómo lo hacemos en el Studio

En un rescate, empezamos por los accesos: código, archivos y cuentas pasan a estar a nombre del cliente. Después hacemos el diagnóstico, que separa lo que se puede limpiar de lo que hay que rehacer. Solo entonces cerramos precio y plazo, con el plazo por escrito en el contrato. Lo hace nuestro equipo de desarrollo.

Y todo sistema que entregamos sale con un agente de IA que corre todos los días, señala fallas, sugiere mejoras y verifica que los datos tengan sentido. Es el tipo de mirada diaria que hace que un ataque se detecte en horas, y no por la llamada de un cliente.

Si hackearon o se cayó el sitio de tu empresa y necesitas volver a ponerlo en línea con seguridad, el rescate de proyectos del Studio empieza por el diagnóstico.