Sitio o SaaS hackeado: qué hacer en las primeras 24 horas

Si estás leyendo esto porque está pasando ahora mismo: respira. Los próximos pasos importan más que el pánico. Este texto es una guía cronológica (minutos, primeras horas, primeras 24 horas) pensada para quien está descubriendo que sufrió (o está sufriendo) un ataque en la plataforma de su empresa.

Si lo estás leyendo antes de cualquier incidente: mucho mejor. Guarda este enlace en algún lugar accesible (el Notion de la empresa, un Google Drive compartido, el README de GitHub). El día que lo necesites, no vas a tener cabeza para buscarlo.

Antes que nada: ¿de verdad te hackearon?

Síntomas comunes que por lo general indican un ataque real:

• El contenido del sitio cambió solo (mensajes extraños, defacement)
• Clientes quejándose de que recibieron emails que ustedes no enviaron
• Cargos en la tarjeta de la empresa que ustedes no hicieron
• Exigencia de rescate por email (ransomware)
• El banco avisando de movimientos sospechosos en la cuenta corporativa
• El hosting (Vercel, AWS, Hostinger) avisando de un uso anormal de recursos
• Servidor lentísimo sin motivo aparente
• Logs extraños que nadie del equipo supo explicar

Síntomas que pueden ser otras cosas:

• Sitio caído (por lo general es DNS, hosting o un bug; no todo apagón es un hacker)
• Error 500 aislado (por lo general es un mal deploy)
• Un cliente reportando que vio un dato equivocado (puede ser un bug)

Importante: aunque tengas dudas, trata los primeros pasos como si fuera un ataque real. Costo de atender un incidente que no existe = pequeño. Costo de ignorar un incidente real durante horas = enorme.

🚨 Primeros 15 minutos: no metas la pata

Qué NO hacer (importante)

• No apagues el servidor. Borras rastros y dificultas la investigación posterior. Aislar es distinto de apagar.
• No borres archivos sospechosos. Son evidencia. Los vas a necesitar para entender cómo entraron.
• No cambies contraseñas en el panel atacado. Si el atacante todavía tiene acceso, ve la contraseña nueva. Cámbialas por canales independientes (lo verás en el paso 5).
• No hables con clientes ni con la prensa antes de entender el alcance. Una comunicación equivocada al principio genera demandas, pánico innecesario y pérdida de credibilidad.
• No pagues el rescate (ransomware). Pagar no garantiza la recuperación: informes de Sophos y Veeam muestran que cerca de 1 de cada 3 organizaciones que pagan no logran recuperar todos sus datos. Y pagar marca a tu empresa como blanco dócil: una víctima que paga suele ser atacada de nuevo en los meses siguientes.
• No intentes “corregir el bug” sin entender qué pasó. Podrías estar cerrando la puerta 1 mientras el atacante entra por la 2.

Qué hacer ahora (en orden)

Paso 1 — Activar una respuesta organizada (5 min)

Avisa por un canal seguro (WhatsApp/Signal personal, NO el email de la empresa) a las 3 a 5 personas clave:

• Socio/CEO
• Líder técnico (CTO o dev senior)
• Responsable de finanzas
• Área legal (interna o abogado externo)
• Encargado de datos (DPO), si lo hay

Activa una war room virtual (Discord, un canal privado de Slack o una llamada en conferencia). Define a UNA persona como coordinadora: sin coordinador, todo el mundo hace todo mal en paralelo.

Paso 2 — Documentarlo todo (5 min, en paralelo)

Crea un Google Doc o un Notion con marcas de tiempo. A partir de ahora, anota:

• Cuándo lo notaron (fecha y hora exactas, con zona horaria)
• Cómo lo notaron (cliente, log, alerta automática)
• Qué vieron exactamente (capturas de pantalla, mensajes copiados)
• Cada decisión tomada y quién la tomó

Este documento vale oro para: la notificación a la autoridad de protección de datos (en Brasil, la ANPD, que aplica la LGPD, la ley brasileña de protección de datos), la investigación posterior, la defensa en un proceso judicial y el informe a los clientes. Sin una línea de tiempo documentada, el post-incidente se vuelve una pesadilla de versiones contradictorias.

Paso 3 — Aislar (sin apagar): 15 min

“Aislar” significa cerrarle el acceso al atacante sin destruir sus rastros. En orden:

• Cloudflare: activa el “Under Attack Mode” (Security → Under Attack Mode). Esto agrega un challenge de JavaScript a cada solicitud y dificulta los ataques automatizados.
• Bloquea las IP sospechosas identificadas en los logs (Cloudflare → Security → Tools → IP Access Rules).
• Desactiva los paneles administrativos temporalmente (haz que la ruta /admin devuelva 503 manualmente).
• Revoca los tokens de API emitidos (Stripe, OpenAI, Resend, etc.: todas las claves deben rotarse).
• No borres logs ni archivos sospechosos. Cópialos fuera del servidor, pero conserva los originales.

Paso 4 — Snapshot de todo (30 min)

Antes de cualquier otro cambio, toma una fotografía digital del estado actual:

• Snapshot del servidor (AWS, Google Cloud, hash del deployment actual en Vercel)
• Backup de la base de datos en un S3 / Drive separado
• Copia de los logs del hosting (últimos 30 días, si es posible)
• Copia de los logs de Cloudflare (últimos 7 días)
• Historial de commits de Git (¿rebase, force-push?)
• Lista actual de usuarios con permisos de admin

Estos archivos van a ser críticos para la investigación. Sin ellos, no descubres cómo entraron y quedas expuesto a que vuelvan a entrar.

Paso 5 — Cambiar credenciales (1 h)

Por orden de prioridad:

1. Email principal de la empresa (por lo general es el “rey”: quien tiene acceso al email restablece la contraseña de todo)
2. Panel del hosting (Vercel, AWS, Hostinger)
3. Panel de Cloudflare
4. Panel del registrador de dominios (GoDaddy, el NIC de tu país, Registro.br)
5. Banco / finanzas (separar de inmediato)
6. Stripe / Mercado Pago / PayPal
7. GitHub / GitLab / Bitbucket
8. SaaS críticos (Slack, Discord, Notion, Google Workspace)
9. Base de datos (rotar la contraseña del usuario admin)
10. Tokens de integración (OpenAI, OAuth secrets, JWT signing keys)

Importante: las contraseñas nuevas deben estar en un gestor (1Password, Bitwarden), y cada cuenta crítica debe tener 2FA con app autenticadora (Authy, Google Authenticator), no por SMS (el SMS es vulnerable al SIM swap).

Paso 6 — Evaluar los datos expuestos (2–4 h)

Pregunta crítica: ¿a qué tuvo acceso el atacante?

Clasifica:

• Datos personales de clientes (documento de identidad, email, teléfono, dirección, datos bancarios): activan la ley de protección de datos (la LGPD, en Brasil)
• Datos financieros (transacciones, saldos, datos de tarjetas): activan obligaciones ante el BACEN (Banco Central de Brasil) y de PCI DSS
• Datos sensibles (salud, jurídicos, escolares): activan la LGPD + multa agravada
• Credenciales de clientes (contraseñas hasheadas, tokens): atención máxima
• Contenido propietario (código fuente, documentos internos)
• Datos públicos (ya eran accesibles): gravedad baja

Si hubo acceso a datos personales, el reloj de la ley de protección de datos ya empezó a correr: hay que comunicarlo a la autoridad en el plazo que fije la ley aplicable (por ejemplo, 72 horas en el GDPR europeo). En Brasil, el art. 48 de la LGPD exige comunicar en un plazo razonable a la ANPD y a los titulares afectados cuando el incidente pueda causar “riesgo o daño relevante”. La ley no fija el plazo, pero la Resolución CD/ANPD n.º 15/2024 lo establece en 3 días hábiles.

Paso 7 — Comunicar a las partes obligatorias (4–24 h)

Autoridad de protección de datos (si hay datos personales expuestos)

En Brasil, la notificación va a la ANPD, con el formulario oficial en gov.br/anpd; en otros países, a la autoridad de la ley aplicable. Tienes que informar:

• Naturaleza de los datos afectados
• Número aproximado de titulares
• Riesgos probables
• Medidas adoptadas
• Cronograma de comunicación a los titulares

Clientes afectados

Un comunicado directo, en lenguaje claro, que incluya:

• Qué pasó, en 2 frases
• Qué datos pueden haber quedado expuestos
• Qué están haciendo ustedes
• Qué debe hacer el cliente (cambiar su contraseña, activar 2FA, vigilar su cuenta)
• Un canal directo para dudas

No mientas, no minimices, no uses jerga. El cliente que descubre que le ocultaste información te demanda.

Banco / BACEN (si eres una institución financiera)

En Brasil, la Resolución BACEN 4.893 (CMN 4.893) y la Resolución BCB 85 exigen comunicación inmediata en caso de incidente cibernético en instituciones financieras y de pago. Plazo corto y multa fuerte si te atrasas.

Paso 8 — Investigación técnica (24–72 h)

Aquí, por lo general, entra una empresa especializada (forense + pentest). Objetivo: responder con certeza:

• Por dónde entró el atacante
• Cuánto tiempo estuvo adentro
• Qué hizo
• Si todavía tiene algún acceso
• Si hay otras vulnerabilidades explotables (para cerrarlas antes de volver a levantar el sistema)

Sin esta investigación, pueden corregir el síntoma y dejar la causa intacta. El atacante vuelve en 30 días por otra puerta.

Paso 9 — Remediación + regreso seguro (3–14 días)

Antes de volver a levantar el sistema:

• La vulnerabilidad explotada tiene que estar corregida
• Las otras vulnerabilidades graves identificadas tienen que estar corregidas
• Todas las credenciales comprometidas, rotadas
• Backups validados (no basta con tenerlos: hay que probar la restauración)
• Monitoreo adicional activado (alertas para patrones similares)
• Retest hecho por un tercero independiente

Qué esperar del mes siguiente

Estimación realista, basada en incidentes públicos en Brasil:

Total típico de un incidente mediano en un SaaS brasileño: R$ 200.000 a R$ 1.500.000. Un pentest preventivo anual cuesta una fracción de eso.

El mejor momento para leer esto era ayer

Si estás descubriendo este texto en modo emergencia, habla con nosotros: No Vuln tiene capacidad de pentest de emergencia + forense para responder en 24 h. Envía un mensaje con “EMERGENCIA” en el asunto a [email protected] o por WhatsApp.

Si estás descubriendo este texto de forma preventiva: buena señal. Agenda una llamada y evaluamos qué hay que blindar antes de que se convierta en una emergencia.