.jpeg){kind=logo}
Los atacantes suelen establecer sus propias reglas en lugar de modificar las que ya tenía el usuario. El equipo de MDR de Vectra ha investigado este fenómeno en los entornos de nuestros clientes, y esto es lo que se desprende del conjunto de las decisiones cotidianas de nuestros analistas, así como lo que un SOC puede hacer al respecto.
Como equipo de MDR, clasificamos a diario las detecciones procedentes de numerosos entornos de clientes. Una de ellas, nuestra detección de «Reglas sospechosas del buzón de Microsoft 365», señala las reglas de la bandeja de entrada que merecen una revisión más detallada. La mayoría de estas detecciones se resuelven de una de estas dos formas: un analista las cierra por considerarlas inofensivas o las remite al cliente para que las valide. Tomadas individualmente, se trata de incidencias rutinarias. Sin embargo, en su conjunto —al proceder de entornos de clientes de distintas regiones y sectores, y basándose en lo que los clientes confirman cuando se les remiten los casos—, resultan contener información valiosa: una visión precisa y compartida de cómo utilizan realmente los atacantes las reglas de la bandeja de entrada.
Por qué merece la pena prestar atención a las reglas del buzón
Las reglas de la bandeja de entrada son una función habitual para mejorar la productividad: reenvían, mueven, marcan o eliminan los mensajes de forma automática.
Esta misma función es una de las preferidas de los atacantes tras la apropiación de una cuenta, ya que les permite controlar un buzón de correo de forma silenciosa, sin malware procesos en ningún dispositivo. Destacan dos tipos de uso indebido: reenviar el correo a una dirección externa (exfiltración, MITRE ATT&CK .003) y mover o eliminar el correo entrante para ocultar avisos de seguridad y respuestas (evasión, MITRE ATT&CK .008).
¿Por qué no nos limitamos a estudiar los ataques?
Una pregunta lógica: si quieres entender a los atacantes, ¿por qué no te limitas a estudiar los ataques confirmados? Estudiar los ataques de forma aislada te muestra lo que hacen los atacantes, pero no con qué frecuencia esa misma acción aparece en un uso habitual y benigno, y ese contraste es precisamente lo que hace que valga la pena actuar ante un comportamiento. Una regla que elimina el correo entrante parece alarmante en medio de un montón de ataques; solo al compararla con la actividad cotidiana te das cuenta de que es realmente poco frecuente y, por lo tanto, una señal. Entender qué es normal para reconocer lo que no lo es es una idea habitual en la detección. La aplicamos a un tipo diferente de «normal»: las decisiones cotidianas que toman los analistas sobre una detección. Esa mayoría benigna no es ruido que se pueda descartar. Cada cierre benigno es un juicio sobre lo que no es un ataque y, en conjunto, esos juicios constituyen un conocimiento que se desperdiciaría si solo se estudiaran los ataques.
El perfil que se desprende de nuestros datos
En conjunto, las decisiones de los analistas clasifican cada comportamiento en un punto intermedio entre «rutinario» y «merece un análisis más detallado». Mover el correo a una carpeta es lo que más vemos que hacen los atacantes con una regla, seguido del reenvío y la eliminación; sin embargo, resulta que la frecuencia con la que se da un comportamiento dice poco sobre hasta qué punto debería preocuparte. Esto es lo que más llamó la atención.
Crean; no reescriben. En todos los ataques que hemos confirmado, las reglas maliciosas son propias del atacante, creadas y modificadas posteriormente —a menudo en una sola oleada— en lugar de ser reglas antiguas del cliente reutilizadas. El patrón es constante: los atacantes traen sus propias reglas. Donde podemos evaluar con mayor claridad la parte rutinaria es en el caso del correo trasladado a una carpeta: modificar una regla de traslado a una carpeta que lleva mucho tiempo en vigor, en los casos en que los analistas pudieron ver exactamente qué supuso el cambio, casi nunca merece la pena escalarlo. Las tareas de mantenimiento cotidianas y una configuración nueva de un atacante no se parecen en nada.
La eliminación es poco frecuente y llama mucho la atención. Son muy pocas las reglas de buzón que eliminan el correo entrante, pero cuando un analista detecta una, se eleva a un nivel superior con mucha más frecuencia de lo habitual, y nuestros casos confirmados indican que ese instinto es acertado. La eliminación para ocultar respuestas y avisos de seguridad es una maniobra de encubrimiento, y así se refleja en los datos. Mientras que modificar una antigua regla de «mover a carpeta» es ruido, la eliminación es una señal.
El reenvío es la zona gris. El reenvío se sitúa en un término medio: ni es algo excepcional ni rutinario, y cuenta con un porcentaje real de casos de malicia confirmada a sus espaldas. No todo se puede diferenciar con claridad, y el reenvío es precisamente el ámbito en el que más importa actuar con cautela, en lugar de donde se pueda bajar la guardia. Decirlo con franqueza es parte del asunto.
Cómo se delatan los atacantes. En nuestros casos confirmados se repitieron dos indicios. Las reglas creadas por los atacantes suelen tener, de forma desproporcionada, nombres extraños y minimalistas, como una sola letra o uno o dos puntos sueltos, el tipo de etiqueta improvisada que una persona normal no elegiría. Y cuando los atacantes mueven mensajes de correo, recurren a carpetas predeterminadas estándar en lugar de a carpetas personalizadas. Ninguno de estos indicios es una prueba por sí solo, pero juntos permiten perfilar mejor el panorama.
Qué puede hacer un SOC con esto
Un perfil como este puede utilizarse de dos maneras a la vez: para atenuar la rutina y para acentuar lo real. El funcionamiento de la puntuación en la Vectra AI permite hacerlo de forma segura: cada detección lleva asociada una gravedad basada en lo que establece la regla, y esa gravedad se integra, junto con otros factores, en una única puntuación a nivel de cuenta que refleja toda la actividad de dicha cuenta. Así, la gravedad que aporta un patrón rutinario puede reducirse sin crear un punto ciego: una cuenta que también muestre un inicio de sesión inusual, o cualquier otra señal independiente, seguirá destacándose. La rutina pasa más desapercibida; la combinación genuinamente sospechosa sigue llamando la atención.
Es fundamental señalar que nada de esto es automático. Un patrón que parece habitual en nuestro historial es solo una hipótesis, por lo que validamos cada elemento del perfil comparándolo con nuestros propios casos de ataque confirmados antes de que sirva de base para nada, y cualquier cambio en la puntuación de una detección se sometería a una revisión de seguridad, sin pasar directamente a producción.
En qué mejora esto
El objetivo de un perfil como este no es el perfil en sí mismo, sino lo que permite que la detección y el servicio que lo rodea lleguen a ser. Los instintos que antes solo existían en la mente de un analista experimentado se convierten en algo explícito y reutilizable, de modo que no es necesario volver a descubrir el mismo criterio caso por caso. Se puede restar importancia a los comportamientos rutinarios, mientras que las combinaciones realmente sospechosas siguen llamando la atención, lo que se traduce en menos tiempo perdido en falsas alarmas y más atención dedicada a lo que realmente lo justifica. Y el trabajo diario de clasificación deja de ser un coste que se pierde en una lista de tareas pendientes y empieza a convertirse en un ciclo de retroalimentación, en el que cada patrón validado hace que la siguiente ronda de detección sea un poco más precisa. El resultado es un servicio que se vuelve más discreto donde debe y más llamativo donde es necesario, y que mejora en su capacidad para distinguir entre ambos a medida que va funcionando.
El perfil específico es útil, pero el método en el que se basa es aún más importante. Cada SOC se sustenta en un historial de decisiones de los analistas que, de forma implícita, recoge conocimientos adquiridos con gran esfuerzo sobre el comportamiento de los atacantes, y casi nada de ello está documentado por escrito. Considerar ese historial como una fuente de información, en lugar de solo como un trabajo atrasado, convierte la clasificación diaria de incidencias en un ciclo de retroalimentación que mejora las detecciones y libera tiempo a los analistas.
Vectra AI de Vectra AI
El perfil de reglas del buzón de correo que aquí se describe es solo un ejemplo de cómo Vectra AI mejora Vectra AI la detección basada en el comportamiento. Cada detección se basa en investigaciones de seguridad en curso, observaciones de atacantes en el mundo real y los comentarios de nuestro equipo de MDR. Esta combinación de IA, análisis de comportamiento y experiencia humana ayuda a los equipos de seguridad a dedicar menos tiempo a investigar falsas alertas y más tiempo a responder a las amenazas que realmente importan.
Descubre cómo la Vectra AI utiliza la detección de comportamientos basada en la inteligencia artificial para detener los ataques híbridos en identidades, cloud, el SaaS, los terminales y las redes.