La mayoría de organizaciones tiene plan B si cae el correo durante una crisis de seguridad, pero casi ninguna sabe qué hacer cuando el sistema sigue funcionando y el atacante está adentro leyendo cada mensaje del equipo de respuesta.
Los primeros minutos después de detectar un incidente grave siguen siempre el mismo patrón: seguridad investiga, IT contiene, legal evalúa obligaciones regulatorias, ejecutivos piden actualizaciones. La coordinación ocurre en las mismas herramientas de siempre — correo corporativo, Slack, Teams, documentos compartidos, videollamadas. El problema aparece cuando esas herramientas son parte del incidente. El correo sigue funcionando, los empleados pueden unirse a reuniones, nada en la superficie sugiere pérdida de control. Mientras tanto, un atacante con acceso a las cuentas del equipo de respuesta lee cada mensaje, monitorea los planes de contención o suplanta a alguien involucrado en la crisis. La organización enfrenta entonces una segunda crisis dentro de la primera: los sistemas que usa para gestionar el incidente ya no son confiables.
El escenario que la mayoría de planes no cubre
La mayoría de planes de respuesta a incidentes contemplan que el correo electrónico o herramientas de colaboración queden no disponibles. Los equipos tienen árboles telefónicos, información de contacto personal, líneas de conferencia de respaldo. Saben a quién llamar cuando todo cae. Lo que pocos planes abordan sistemáticamente es el escenario más ambiguo: cuando esos sistemas permanecen funcionales pero la organización no puede estar segura de quién lee, envía o altera mensajes dentro de ellos. Ese caso requiere una forma preplanificada de mover la respuesta fuera de banda mientras los investigadores determinan qué fue comprometido.
La diferencia con un ataque de ransomware es evidente. Cuando los sistemas caen y los empleados pierden acceso, la necesidad de comunicaciones alternativas se vuelve obvia. Las comunicaciones comprometidas hacen el juicio más difícil porque el entorno afectado puede parecer completamente normal. Si el equipo de seguridad descubre que un atacante ganó acceso a cuentas de correo y colaboración usadas por miembros del equipo de respuesta, necesita determinar el alcance de ese acceso, remover al atacante y contener la intrusión — pero discutir esas acciones en el canal regular de incidentes podría revelar al atacante exactamente qué viene. Legal necesita los últimos hechos para evaluar requisitos de notificación, el equipo de comunicaciones prepara respuestas para clientes, liderazgo espera actualizaciones regulares. Cada una de esas conversaciones puede revelar algo valioso a la persona que la compañía intenta remover.
Casos documentados de atacantes dentro de las reuniones de crisis
Los equipos de respuesta a incidentes comúnmente utilizan Teams o Slack como canales de coordinación durante crisis porque son los sistemas que sus empleados ya usan. El costo de esa conveniencia es que la respuesta permanece dentro de un entorno al que el atacante puede ya tener acceso y tiene todo incentivo para monitorear. Se han documentado casos donde atacantes se unieron o grabaron puentes de Zoom y Teams utilizados en reuniones de incidentes. Si el atacante estuvo leyendo el canal, cada plan de contención, cada evaluación franca de cómo ocurrió la intrusión y cada borrador de declaración para clientes publicado ahí está ahora fuera de la compañía. Parte de eso puede aparecer en una demanda de extorsión. Todo puede aparecer en descubrimiento legal.
La presencia de un abogado en un canal de incidentes grande no hace que todas las conversaciones sean privilegiadas. Los hechos operacionales y el consejo legal sirven propósitos diferentes, y una crisis no elimina la necesidad de controlar quién participa en discusiones sensibles. El canal fuera de banda debería dar a los equipos un lugar para separar coordinación operacional de análisis legal, limitar participación y comenzar a construir el registro que reguladores y demandantes pueden examinar después: qué se decidió, por quién, sobre qué hechos y por qué. Legal debería diseñar esa estructura antes del incidente. Intentar crearla durante uno, en un canal que el atacante puede estar leyendo, agrava el problema.
Dependencias compartidas que anulan el plan de respaldo
El error común es empezar eligiendo una aplicación de respaldo. El punto de partida correcto es el escenario de falla: mapear cada dependencia compartida por los entornos de comunicación primario y de emergencia, incluyendo servicios de identidad, dispositivos administrados, gestión de dispositivos móviles, credenciales administrativas y directorios de empleados. Si ambos canales dependen del mismo componente subyacente, ese componente sigue siendo un punto único de falla. Después viene decidir cómo los participantes probarán quiénes son. Un atacante con acceso a correo o calendarios puede saber que una reunión de emergencia está ocurriendo y tener suficiente contexto para suplantar a un ejecutivo o respondedor. El proceso de verificación no puede depender de las cuentas bajo investigación.
La misma preparación debería cubrir abogados externos, investigadores forenses, aseguradoras y asesores de comunicaciones. Mantener información de contacto actualizada, definir quién puede autorizar su participación y establecer cómo el equipo los verificará antes de que comience un incidente. Los dispositivos también importan. Un canal alternativo provee poco valor si los respondedores pueden alcanzarlo solo a través de laptops corporativas que se les instruyó desconectar. El plan debería especificar qué dispositivos pueden usar los respondedores y qué información pueden acceder a través de ellos.
El impacto estructural en organizaciones latinoamericanas
La dependencia de plataformas de colaboración corporativas globales (Microsoft 365, Google Workspace, Slack) es particularmente alta en organizaciones medianas y grandes de México, Brasil, Colombia y Argentina que adoptaron esas herramientas durante la pandemia sin desarrollar protocolos de comunicación de crisis independientes. Un profesional con más de dos décadas de experiencia en privacidad y respuesta a brechas observa que el patrón se repite en conversaciones semanales con equipos de seguridad y legal: la mayoría tiene plan para caída total de sistemas, casi ninguno para compromiso silencioso de canales de coordinación. En jurisdicciones con requisitos de notificación estrictos como Brasil (LGPD) o Argentina (Ley de Protección de Datos Personales), la falta de un canal verificable para coordinar análisis legal durante un incidente puede complicar el cumplimiento de plazos regulatorios si el equipo descubre tarde que sus discusiones internas estuvieron expuestas.
Nuestro análisis
Este escenario revela una brecha conceptual en cómo la mayoría de organizaciones piensa sobre continuidad de respuesta a incidentes. Los planes tradicionales asumen falla binaria — el sistema funciona o no funciona — pero el compromiso de canales de comunicación es un estado intermedio donde la funcionalidad técnica persiste mientras la confianza operacional colapsa. La diferencia entre tener un plan de respaldo y saber cuándo activarlo es el juicio bajo presión: reconocer que el entorno de coordinación está comprometido requiere que alguien en el equipo de respuesta tome esa decisión explícita, comunique el cambio de canal de forma verificable y mantenga la continuidad operacional mientras se mueve la respuesta fuera de banda. Pocas organizaciones practican ese juicio en ejercicios de simulación.
Lo que todavía no se sabe es qué proporción de incidentes graves involucra compromiso de canales de coordinación que nunca se detecta o se detecta demasiado tarde para cambiar de canal sin que el atacante ya haya leído planes de contención completos. La ausencia de datos públicos sobre ese escenario específico no significa que sea raro — más probablemente significa que las organizaciones afectadas no tienen incentivo para reportar que su respuesta al incidente fue monitoreada por el atacante que intentaban remover. ¿Cuántas crisis de seguridad se manejaron en canales que el adversario leía en tiempo real sin que el equipo de respuesta lo supiera hasta revisar logs forenses semanas después?