Internet Archive hackeado (~31M cuentas filtradas): lecciones de almacenamiento, backups y comunicación

A mediados de octubre Internet Archive, la organización que opera la Wayback Machine y archivos abiertos de cultura digital, sufrió un incidente combinado: defacement de su página principal, exfiltración de aproximadamente 31 millones de cuentas (correos electrónicos, screen names y hashes de contraseñas en bcrypt), y una serie de ataques de denegación de servicio (DDoS) que dejaron al sitio caído por días. Have I Been Pwned confirmó la filtración; los hashes están circulando en foros.

Para empresas mexicanas medianas no es noticia exótica: es el tipo de incidente que cualquiera puede vivir si descuida tres áreas básicas. En ALCA hicimos el ejercicio de revisar la cronología y sacar las lecciones operativas. Aquí van.

Cronología, en orden

Lo que se sabe públicamente, sintetizado:

1. 9 de octubre. Visitantes ven un mensaje de defacement en archive.org acusando al sitio de estar "a punto de sufrir un breach". Casi en simultáneo, el sitio empieza a sufrir DDoS y se vuelve intermitente.
2. 10 de octubre. Have I Been Pwned recibe y verifica el dump: 31M registros con email, screen name y hash bcrypt de contraseña, fechados al 28 de septiembre.
3. Días siguientes. Caída prolongada del sitio. Reportes de que su sistema de tickets de soporte (Zendesk) también fue accedido, exponiendo correos privados con archivos adjuntos.
4. Mediados de octubre. Restauración parcial en modo solo lectura. Comunicación oficial moderada por parte del fundador Brewster Kahle vía X.

Tres vectores en un mismo evento: defacement (perdida de integridad), exfiltración (perdida de confidencialidad), DDoS (perdida de disponibilidad). Los tres pilares clásicos comprometidos al mismo tiempo. Es el escenario que ningún CISO quiere narrar a su consejo.

Lección 1: bcrypt salvó a millones de usuarios (pero no del todo)

Lo que evitó que esto fuera catastrófico fue que las contraseñas estaban almacenadas con bcrypt, no en texto plano ni con hashes débiles tipo MD5 o SHA1 sin salt. bcrypt está diseñado para ser lento, lo que hace que romper contraseñas por fuerza bruta sea costoso aunque no imposible.

Aún así, hay matices que importan:

• Contraseñas débiles igual caen. Una contraseña tipo "verano2024" o "password1" se rompe en horas incluso con bcrypt. La calidad del hash no compensa contraseña pobre.
• Reuso de contraseñas es la verdadera bomba. Si un usuario usa la misma contraseña en archive.org y en su correo corporativo, el atacante intenta credential stuffing en bancos, M365, Gmail. Es así como un breach de un sitio cultural se convierte en breach de empresas no relacionadas.

Para empresas mexicanas: si su login propio aún usa MD5, SHA1 sin salt o cualquier hash que no sea Argon2, bcrypt o scrypt con cost adecuado, es deuda crítica que se paga este trimestre, no el próximo.

Lección 2: backups inmutables y separación de credenciales

Los detalles técnicos del vector inicial no se han confirmado, pero se especula que un token de API o credencial de desarrollador filtrada en GitHub fue el punto de entrada. Sea cual sea el vector, dos prácticas habrían contenido el daño:

• Backups inmutables y offline. Tener al menos una copia de la base de datos en un bucket WORM (write-once read-many) o en almacenamiento físicamente separado, con credenciales independientes del sistema productivo. Si el atacante entró con credenciales del sistema vivo, no puede borrar lo que no puede tocar.
• Separación de credenciales por capa. Las llaves que usa la app productiva no deben servir para acceder al pipeline de backups. Esto suena obvio y casi nadie lo cumple.

En ALCA cuando hacemos assessment, la pregunta uno es: ¿si un atacante tiene credenciales root de tu base productiva, puede borrar también los respaldos? Si la respuesta es sí, el respaldo no es respaldo, es ilusión.

Lección 3: la página de status y el plan de comunicación

Internet Archive no tenía una página de status pública robusta y la comunicación inicial fue improvisada por X. Para una organización querida globalmente eso pasó factura en confusión: rumores, especulación, presión.

Para una empresa mediana mexicana, este es el checklist mínimo de comunicación de crisis que debe estar listo antes del incidente:

1. Página de status pública en dominio separado (status.tuempresa.mx en otro proveedor).
2. Plantillas de comunicación pre-aprobadas por jurídico y dirección general para tres escenarios: caída no relacionada con seguridad, breach confirmado, breach en investigación.
3. Lista de contactos clave (clientes top 20, proveedores críticos, autoridad regulatoria, prensa) lista para activarse en menos de 4 horas.
4. Vocero designado y suplente, con guion básico y prohibición clara para que nadie más hable a nombre de la empresa.

Quien improvisa comunicación durante un incidente paga el costo dos veces: una por el incidente, otra por el daño reputacional adicional.

Lección 4: DDoS no es solo problema de gigantes

El ataque de denegación de servicio prolongó la caída y amplificó el daño. Para una empresa mediana mexicana, la pregunta es: ¿qué pasa si tu sitio recibe 10x el tráfico habitual durante 48 horas?

Las medidas razonables hoy son baratas:

• Cloudflare, Akamai o el WAF/CDN del proveedor cloud, configurado y probado (no solo encendido).
• Rate limiting por IP y por endpoint sensible (login, registro, búsqueda).
• Capacidad de aislar e identificar tráfico legítimo vs. abusivo en menos de 30 minutos.
• Plan de "modo degradado": qué partes del sitio puedes apagar para mantener lo crítico vivo (checkout, login, status).

Lección 5: assessment de exposición de credenciales propias

Hacemos esto como ejercicio recurrente con clientes y se los recomendamos: una vez al trimestre, revisar a qué servicios externos están expuestos los correos corporativos del equipo, usando Have I Been Pwned con dominio verificado, y forzar reset de contraseñas y revisión de MFA en cuentas señaladas.

Después del breach de Internet Archive, conviene asumir que al menos una persona del equipo tenía cuenta ahí y reusaba contraseña. Es un buen disparador para correr el assessment esta semana.

Qué llevarse a la oficina mañana

Sin sobre-reaccionar, cinco acciones concretas para Q4:

1. Verificar que todos los almacenes de contraseñas usen bcrypt/scrypt/Argon2 con cost adecuado.
2. Confirmar que existen backups inmutables con credenciales separadas y restaurarlos como prueba al menos una vez al trimestre.
3. Tener página de status y plantillas de comunicación listas, aprobadas y ensayadas.
4. Activar WAF/anti-DDoS y probarlo, no solo dejarlo prendido.
5. Correr assessment de exposición de credenciales corporativas este mes.

Internet Archive es un servicio público de altísimo valor. Su incidente es triste y nos recuerda que ningún equipo, por bien intencionado que sea, está libre. Aprender de cabeza ajena es más barato que aprender de la propia.

---

¿Quieres un assessment de exposición de credenciales en tu empresa? En ALCA lo corremos en una semana y te entregamos un plan de remediación priorizado. Solicítalo aquí.