Hackearon mi aplicación: qué hacer ahora

Una intrusión rara vez aparece como un mensaje de error claro. La señal suele ser indirecta: el sitio muestra una página que no hiciste, el uso de CPU se queda en 100% sin tráfico, la factura de la API de IA llega alta, aparece un administrador que nadie creó o la base de datos desaparece y en su lugar queda una petición de rescate.

En ese momento, la tentación es borrar lo que parece raro y seguir adelante. Ese es el error más común: destruyes las pistas de cómo entró el atacante y le dejas la puerta abierta para que vuelva. El orden de abajo sigue las recomendaciones de respuesta a incidentes del NIST SP 800-61: contener primero y después investigar, recuperar y prevenir.

¿Cómo saber si de verdad hackearon tu aplicación?#

Busca estas señales, de la más a la menos común en aplicaciones pequeñas:

• Archivos modificados o nuevos que no están en tu repositorio, como scripts inyectados en el HTML o un archivo .php en una aplicación Node.js.
• CPU alta y constante sin aumento de visitas. Los mineros de criptomonedas son la carga típica después de una intrusión.
• Cuentas y cobros extraños: usuarios administradores nuevos, uso alto en APIs de pago, correos enviados en masa por tu proveedor.
• Datos borrados o cifrados, a veces con una tabla o colección nueva que contiene una petición de rescate.
• Solicitudes exitosas a archivos sensibles en los logs de acceso, como esta (ejemplo):

203.0.113.7 - - [12/Oct/2026:03:14:07 +0000] "GET /.env HTTP/1.1" 200 1532 "-" "Mozilla/5.0"

El 200 de esa línea significa que el servidor entregó el archivo .env con todos tus secretos. Prueba ahora si tu sitio expone archivos que nunca deberían ser públicos. La respuesta esperada es 404 o 403:

for path in .env .git/config; do
  printf '%s -> ' "$path"
  curl -s -o /dev/null -w "%{http_code}\n" "https://www.tusitio.com/$path"
done

Si tienes los logs de acceso en un archivo, busca las solicitudes que tuvieron éxito:

grep -E '"GET /\.(env|git)' access.log | grep -E '" 200 '

¿Qué hacer en la primera hora?#

Sigue este orden. No empieces por la limpieza.

1. Contén. Detén la aplicación o bloquea el acceso público. Una aplicación fuera de línea durante una hora cuesta menos que un atacante activo una hora más.
2. Conserva las evidencias. Antes de borrar nada, descarga los logs y una copia de los archivos que están en el servidor. Sin ese material, no descubrirás la causa.
3. Cambia todos los secretos. Contraseñas de la base de datos, tokens de bots, claves de API, claves de firma de sesión y JWT, credenciales de correo y de almacenamiento. Considera comprometido todo lo que la aplicación podía leer, incluidas las variables de entorno.
4. Protege las cuentas alrededor. Cambia la contraseña y activa la verificación en dos pasos en GitHub, en el registrador del dominio y en el panel del hosting. Cierra las sesiones abiertas.
5. Invalida las sesiones de los usuarios. Cambiar la clave de firma de sesión o JWT cierra todas las sesiones, incluida la del atacante.

Para tokens de bots y claves de API, los pasos detallados están en se filtró el token de tu bot y clave de API expuesta en GitHub.

¿Por dónde suele entrar el atacante?#

Estas son las causas más comunes en aplicaciones pequeñas, de la más a la menos frecuente.

Secretos filtrados#

Un .env subido a un repositorio público, servido por el propio sitio o incluido en un ZIP compartido. Revisa el historial de Git y haz la prueba con curl de arriba. Un secreto filtrado puede explicar toda la intrusión: quien tenía la contraseña de la base de datos no necesitó ninguna falla en el código.

Base de datos expuesta sin contraseña#

Una base de datos abierta a internet sin autenticación cae rápido ante robots que escanean direcciones. La documentación de administración de Redis advierte que, por defecto, no exige autenticación y escucha en todas las interfaces de red. MongoDB escucha solo en localhost por defecto, según su documentación de seguridad, pero mucha gente lo cambia a 0.0.0.0 para "hacer que funcione". Verifica que tu base de datos exija contraseña y solo acepte conexiones de tu aplicación.

Dependencia vulnerable#

Una biblioteca desactualizada con una falla conocida. Ejecuta la auditoría de tu lenguaje y compara la fecha de publicación de las fallas con la fecha de la intrusión:

npm audit --audit-level=high
pip-audit -r requirements.txt

npm audit consulta al registro las vulnerabilidades conocidas de tus dependencias y sale con error cuando encuentra algo del nivel indicado. pip-audit hace lo mismo para Python.

Falla en tu código#

Inyección SQL por concatenar texto en la consulta, una subida de archivos que acepta cualquier extensión y guarda en una carpeta pública, un comando del sistema armado con datos del usuario, una ruta de administración sin verificación de permisos. Busca en los logs de acceso las rutas que recibieron solicitudes extrañas poco antes de las primeras señales.

Contraseña débil o cuenta comprometida#

Un panel de administración con una contraseña corta y sin límite de intentos, o la cuenta de GitHub de alguien del equipo. Si el atacante hizo commits o deploys, el historial de Git y los logs de deploy muestran cuándo.

Para comparar lo que está corriendo con lo que está en el repositorio, usa una copia descargada del servidor:

git diff --no-index --stat ./mi-repo/src ./copia-del-servidor/src

Cualquier archivo que aparezca solo en la copia del servidor merece atención.

¿Cómo limpiar y volver a estar en línea?#

No intentes "arreglar" el servidor hackeado archivo por archivo. Reconstruye:

1. Corrige la causa en el código: actualiza la dependencia, cierra la base de datos, elimina el archivo expuesto, corrige la consulta.
2. Haz un deploy nuevo desde el repositorio, en lugar de reutilizar los archivos que estaban en el servidor.
3. Usa los secretos nuevos, nunca los antiguos.
4. Restaura los datos desde una copia hecha antes de la intrusión, si la base de datos fue alterada. Mira cómo hacer backup de una base de datos para armar una rutina que lo permita.
5. Vigila de cerca en los días siguientes: logs de acceso, uso de CPU y cuentas de servicios externos.

¿Tengo que avisar a alguien?#

Si los datos personales de los usuarios pueden haberse filtrado, probablemente sí. En la Unión Europea, incluida España, el RGPD exige que el responsable notifique a la autoridad de control en un plazo de 72 horas desde que tuvo conocimiento de la brecha, salvo que sea improbable que suponga un riesgo para las personas. En América Latina, cada país tiene su propia ley de protección de datos, y la evaluación del riesgo es tuya. Si dudas, busca asesoría legal.

Habla también directamente con los usuarios: cuéntales qué pasó, qué datos se vieron afectados y qué deben hacer, como cambiar la contraseña en otros servicios donde la reutilizaban.

¿Cómo evitar una nueva intrusión?#

• Secretos fuera del código y fuera de cualquier carpeta que sirva el sitio.
• Base de datos accesible solo desde la aplicación, siempre con contraseña y TLS.
• Dependencias auditadas en cada deploy.
• Verificación en dos pasos en todas las cuentas que pueden hacer deploy.
• Un WAF delante de la aplicación para bloquear patrones de ataque conocidos; mira qué es un WAF.
• Copias probadas de los datos, guardadas fuera del servidor.

El checklist de seguridad del deploy reúne estos puntos con ejemplos de código.

Cómo hacerlo en Square Cloud#

En Square Cloud, el orden de este artículo se convierte en pasos del panel. Para conservar las evidencias, copia los logs desde el panel o con el comando app logs de la CLI (los de antes de un reinicio siguen visibles) y toma un snapshot manual de la aplicación antes de tocar cualquier archivo; los snapshots manuales existen en todos los planes. El administrador de archivos en el navegador muestra el disco de la aplicación, lo que ayuda a encontrar lo que no está en tu repositorio. Para cambiar los secretos, edita las variables de entorno en el panel, la API, la CLI o la extensión de VS Code; el cambio se aplica en el siguiente reinicio, sin rebuild.

Al reconstruir, publica desde tu repositorio en una aplicación nueva, no encima de la antigua: el disco persiste entre deploys y un commit solo sobrescribe los archivos que van en el ZIP, así que lo que dejó el atacante seguiría ahí. Para los datos, las bases de datos tienen snapshot automático diario en todo plan que las incluye, y las aplicaciones, desde el plan Pro. Cada snapshot diario se guarda 7 días, así que elige uno de antes de la intrusión. Un snapshot de base de datos se restaura en la misma base, en otra del mismo motor o en una base nueva, y también se puede descargar como .zip.

Las aplicaciones corren en contenedores aislados, sin acceso root, y una no puede leer las variables ni los archivos de otra, aunque estén en la misma cuenta. Todos los planes incluyen WAF y protección DDoS L3/L4/L7. Esas capas limitan el daño, pero no corrigen una falla en tu código ni un secreto filtrado: la respuesta al incidente sigue siendo tuya. Mira cómo funcionan las variables de entorno y los snapshots.