Detección efectiva de balizamiento C2

Se requiere un conjunto completo de señales y debe incluir características de origen, destino y tráfico, como certificados SSL/TLS utilizados tanto en el origen (malware dentro del entorno) como en el destino (servidor C2), dominio/IP/URL, características de origen como el agente de usuario/características del proceso, tamaño del tráfico/ráfaga/patrones, encabezados HTTP/carga útil/URI, por nombrar solo algunas.

Al observar varias señales a lo largo del tiempo, el volumen, las capas de red y el perfil de tráfico general, la detección de comportamiento puede proporcionar un mecanismo general y eficaz para detectar el malware más reciente a través de actividades de balizamiento C2 sospechosas y maliciosas.

Figura 6: Señales completas

Los tipos de señal tienen varias dimensiones:

• Flujo de red: atributos de origen y destino, así como patrones de tráfico
• Capas de red: diferentes señales de la capa 3 a la 7 (anomalías en los encabezados TCP/IP, huellas dactilares SSL/TLS, encabezados/cargas útiles HTTP y contenido a nivel de aplicación)
• Tiempo: frecuencia, patrones de temporización anómalos para detectar actividad poco frecuente y lenta
• Datos: contenido y volumen (tamaños de paquetes anómalos, ráfagas, estadísticas acumulativas)

Además, hay varios tipos de señal:

• Basado en patrones de tráfico (volumen, tiempo, contenido), incluido el balizamiento repetido junto con un agente de usuario o dominio inusual.
• Heurística (por ejemplo, registradores sospechosos o huellas dactilares SSL maliciosas conocidas)
• Anomalías (dominio inusual, agentes de usuario o huellas dactilares SSL)

Un punto importante es que algunas de las señales anteriores forman parte de los enfoques actuales y de las soluciones existentes. Esto refuerza el punto de que una señal en particular, como el pico de tráfico (gran volumen), no es ni buena ni mala, efectiva o ineficaz por sí misma. Más bien, el contexto y el procesamiento de la señal es el factor determinante. Cuando se utiliza en el perímetro de una red para bloquear/permitir el tráfico, una señal propensa a falsos positivos puede causar graves problemas operativos. Sin embargo, cuando se introduce en un sistema de detección de anomalías que incorpora esa señal en una métrica de riesgo granular (que se analiza a continuación) y en un modelo bien entrenado, puede ser extremadamente eficaz para detectar amenazas Nuevo de manera sólida con pocos falsos positivos.

La detección eficaz de balizamientos C2 a partir de los kits de herramientas del marco C2 requiere modelos de aprendizaje automático basados en una gama más completa de señales para identificar los kits de herramientas del marco C2 actuales y el comportamiento sospechoso futuro de la red que podría indicar actividad C2.

Figura 7: Detección de anomalías

La detección de anomalías debe basarse en modelos a nivel de usuario/dispositivo, rol y organización. Es decir, las anomalías suponen que tenemos una línea de base "normal" válida de actividad o comportamiento con la que comparar. La detección de actividades sospechosas puede ocurrir en diferentes circunstancias. Existen anomalías basadas en las acciones de un usuario frente a su línea de base "normal" histórica o frente a la línea de base "normal" de la Organización o frente a las personas con roles similares. Todos tienen su caso de uso válido que son exclusivos de los demás, y un buen enfoque incorporará múltiples modelos con diferentes alcances.

Los conjuntos de datos de entrenamiento deben incluir tráfico malicioso y benigno:

• El tráfico malicioso se puede simular utilizando herramientas de prueba generales de C2, pruebas específicas de balizamiento adversario de C2 basadas en configuraciones disponibles públicamente de las herramientas del marco de C2, así como configuraciones personalizadas desde la perspectiva de un equipo rojo y ejercicios oficiales de equipo rojo.
• El tráfico benigno o el tráfico válido se recopila mejor de un número significativo de usuarios reales en la organización real durante el tiempo suficiente para normalizarse contra los sesgos del usuario y la organización.

Los conjuntos de datos de entrenamiento son la otra cara de los conjuntos de datos de prueba, y se debe dedicar mucho tiempo a analizar y validar buenos datos de entrenamiento y pruebas. Algunos de los factores para crear buenos conjuntos de datos de prueba se analizan en una sección posterior.

La salida de la detección de anomalías es crítica. El mejor enfoque no realiza determinaciones simples de bloqueo/permiso o alerta/silencio basadas en una señal sin procesar, sino que rastrea y ajusta métricas de riesgo detalladas a nivel de usuario, rol y organización, que luego se pueden usar para acciones de Remediación como alertas, entrenamiento o bloqueo.

Este enfoque para rastrear y actuar sobre el riesgo es fundamentalmente diferente de lo que se usa normalmente en la actualidad. La mayoría de las defensas perimetrales que son preventivas y que suelen bloquear/alertar/permitir el tráfico suelen ser estáticas y propensas a altas tasas de falsos positivos. El resultado neto es que estas soluciones están habilitadas con una Política conservadora para bloquear ciertos riesgos conocidos, lo que a su vez abre un gran número de falsos negativos. Con los firewalls, vemos un problema de falsos positivos con acciones de bloqueo demasiado agresivas basadas en la inteligencia de amenazas IP. Con las soluciones IPS, hemos estado discutiendo los desafíos de los falsos positivos con las firmas estáticas que intentan detectar tráfico C2 altamente configurable y dinámico.

Pero los falsos positivos en una capa perimetral pueden ser muy útiles como señal para una capa más inteligente. En este escenario, no lo usaríamos para una evaluación binaria (permitir/bloquear, alertar/ignorar) sino como una métrica de riesgo detallada ajustada a lo largo del tiempo (p. ej. puntuación de riesgo del usuario) con un umbral ajustado antes de tomar medidas. Una métrica de riesgo granular, por ejemplo, una puntuación de riesgo de 1000 (sin riesgo) a 0 (riesgo extremo) en un usuario o dispositivo o incluso en una dirección IP, nos permite modelar el espectro de grises asociados a las amenazas del mundo real, donde rara vez hay evaluaciones claras 100% maliciosas o 100% benignas.

Conceptualmente, esto se captura en la siguiente ilustración, donde se podrían detectar tres señales diferentes, que por sí mismas serían propensas a falsos positivos. Sin embargo, cuando se asocian con un riesgo incremental y se evalúan mediante un modelo de Machine Learning ajustado, las mismas señales evalúan el riesgo acumulativo a lo largo del tiempo y, en última instancia, ofrecen una detección de anomalías de alta confianza.

Figura 8: Métricas de riesgo granulares

Tenga en cuenta que las señales de este ejemplo pueden no ser tan simples como las señales estáticas. Por ejemplo, un "agente de usuario no reconocido de dominio inusual y certificado SSL/TLS" podría ser una anomalía cuando se compara con la línea de base "normal" anterior de tráfico para ese usuario específico o con roles de trabajo similares de los usuarios o de toda la Organización. Un "registrador sospechoso" puede ser una amalgama de reputación de dominio correlacionada a lo largo del tiempo. Y el "balizamiento periódico" ya no es una simple coincidencia de una tasa o duración fija, sino que puede detectar actividad anormal pero regular y repetida dentro de una ventana de tiempo que es similar a la actividad relacionada con bots en lugar de llamadas de demonios de aplicaciones válidas.

En la práctica, esto nos permite ajustar una puntuación de riesgo de forma incremental y adecuada en función de una señal de baja fidelidad. No provoca ninguna acción de bloqueo o alerta hasta que la puntuación de riesgo acumulado supera un umbral alto y ajustado. Esto nos permite capturar Casos donde hay una gran cantidad de indicadores de baja fidelidad y ligeramente riesgosos, que cuando se combinan con un indicador de mayor fidelidad y mayor riesgo para un usuario o dispositivo en particular, genera acumulativamente una alerta y acción de riesgo crítico con una probabilidad drásticamente menor de falsos positivos.

En teoría, un enfoque Nuevo puede ser sólido y en la práctica fracasar estrepitosamente, y la prueba a menudo se reduce a datos o pruebas. Los proveedores que brindan soluciones y las organizaciones que buscan soluciones requieren un enfoque sólido para probar las amenazas y evaluar las soluciones. Para lograr resultados precisos, es esencial realizar pruebas con un conjunto de datos diverso que incluya tráfico malicioso y benigno.

Tráfico benigno
El tráfico benigno debe ser realista, completo y similar a la producción en términos de número de usuarios y actividad. El buen tráfico, a menudo dependiente del usuario, debe estudiarse en una gran muestra de usuarios y en un período de tiempo razonable. Este conjunto de datos de prueba medirá las tasas de falsos positivos (FP). La variación clave en los conjuntos de datos serán las señales del cliente, como las aplicaciones, los agentes de usuario y los certificados SSL/TLS del cliente que se utilizan, las señales de destino vistas en los dominios/direcciones IP de destino y las señales de patrón de tráfico en los encabezados, la carga útil, el tamaño y el tiempo.

La buena noticia es que el buen tráfico benigno se obtiene fácilmente de las operaciones diarias de los usuarios de la Organización, mientras que la mala noticia es que tiene que ser validado como benigno. El enfoque práctico consiste en muestrear estadísticamente el tráfico benigno hasta un determinado factor de confianza razonable y, a continuación, dedicar la mayor parte del tiempo a centrarse en las alertas de la solución de detección C2 que se está probando, verificando las alertas como verdaderos positivos o falsos positivos. En otras palabras, muestree y verifique por adelantado para formar una línea de base, asuma que el conjunto de datos benigno está limpio y, a continuación, proceda a identificar los falsos positivos en función de las pruebas.

Figura 9: Pruebas de tráfico benignas

Tráfico malicioso
El uso de perfiles públicos de herramientas populares del marco C2 proporciona una base sólida para probar el tráfico incorrecto. Estos perfiles representan configuraciones prácticas y de uso frecuente que evaden las defensas y ayudan a medir las tasas de falsos negativos (FN). Sin embargo, se debe prestar mucha atención a la creación de un conjunto de datos representativo de "tráfico malo", ya que potencialmente hay varios niveles en la cobertura y lo que prueban los conjuntos de datos, como se ilustra en el siguiente diagrama:

Figura 10: Pruebas de tráfico malicioso

1. Las herramientas de simulación de brechas y ataques , como SafeBreach, son excelentes para las pruebas de cobertura y las pruebas repetidas. Su caso de prueba C2 suele incluir al menos alguna simulación de la actividad de los marcos C2. La ventaja es que hay una gran variedad de funcionalidades disponibles, incluidos los ataques generales de malware, con GUI y arquitecturas bien diseñadas, y procedimientos de prueba repetibles e Informe. Estas herramientas pueden ofrecerle una amplia gama de escenarios, entre los que se incluyen: actividad baja-lenta, infraestructura IaaS/CSP, tráfico HTTP y no HTTP para tráfico SSL/HTTPS y suplantación de identidad de una variedad de agentes de usuario.
2. Herramientas del marco C2 (perfiles públicos). Las pruebas en profundidad de los marcos C2 requieren un trabajo enfocado. Un enfoque es crear un conjunto de datos de prueba basado en los perfiles públicos específicos de las herramientas del marco C2, por ejemplo, Cobalt Strike. Estos perfiles públicos maleables tienden a ser ampliamente compartidos y utilizados por muchos usuarios y actores maliciosos, ya que incluyen emulaciones útiles de aplicaciones benignas como Gmail. Este enfoque suele proporcionar pruebas más completas en torno a los marcos C2 específicos.
3. Herramientas del marco C2 (perfiles personalizados). La personalización interna de los perfiles maleables C2 puede proporcionar pruebas aún más realistas de los marcos C2. Estas configuraciones personalizadas se pueden realizar durante las operaciones internas del equipo rojo. Esto requiere más trabajo e inversión, ya que los operadores del equipo rojo deben dominar las herramientas del marco C2.
4. Ataques realistas. Las pruebas más realistas involucran pruebas de caja negra con pruebas de penetración externas o programas de recompensas por errores. En estos escenarios, los requisitos del ejercicio se construyen cuidadosamente para requerir o incentivar vulnerabilidades de POC reales que utilicen herramientas específicas del marco C2 o cualquier comportamiento de balizamiento C2, con advertencias para evitar la detección durante un período de tiempo. Los objetivos de los ejercicios no son solo probar los vectores de acceso inicial, que es la norma, sino centrarse en la actividad posterior a la violación al mostrar la capacidad de instalar una carga útil de puerta trasera con actividad C2 demostrada. Esto enriquece el conjunto de datos de prueba más allá de los marcos C2 y puede probar el código POC de puerta trasera con comunicaciones C2 personalizadas, y también es una excelente prueba de la resistencia de cualquier herramienta de detección a un "atacante" experto que utilice TTP diferente o personalizado.

Las pruebas pueden implicar algunos o varios enfoques, pero se deben tomar decisiones explícitas sobre cómo crear, recopilar y validar los conjuntos de datos de prueba y cómo medir los resultados esperados. La creación y recopilación de los conjuntos de datos de prueba es muy importante para que las pruebas puedan automatizarse y repetirse fácilmente.

También es crucial medir métricas completas durante las pruebas: verdaderos y falsos positivos, verdaderos y falsos negativos. Si bien la recopilación de todas las métricas parece obvia, ser preciso en la definición y claro y repetible en la metodología de medición es difícil, lo que lleva a resultados engañosos.

Objetivos de falsos positivos y falsos negativos
Con las amenazas evasivas de Nuevo creadas por los marcos C2, cualquier solución de detección de Nuevo carecerá de tasas de FP y FN ampliamente aceptadas. Sin embargo, es vital crear objetivos de FP y FN. Con conjuntos de datos de pruebas de calidad conocidos, se pueden crear líneas de base para el entorno actual y los usuarios/Dispositivo, lo que permite crear objetivos razonables, en relación con esas líneas de base.

Por ejemplo, supongamos que una organización con solo un IPS está comenzando una evaluación de las soluciones de detección de Nuevo C2 y no está claro qué tarifas de FP/FN son aceptables. La Organización aún puede llegar a objetivos razonables siguiendo una metodología de prueba como:

• Cree datos de prueba de calidad para el tráfico benigno en función de los datos de producción y el tráfico malicioso basado, por ejemplo, en perfiles públicos maleables C2 para Cobalt Strike, y validando muestras de esos conjuntos de datos manualmente.
• Cree una metodología de prueba clara y repetible mediante la definición de herramientas de prueba y medición.
• Mida todas las métricas (TP/TN/FP/FN) durante las pruebas
• Pruebe las soluciones de Nuevo y compare métricas. Por ejemplo, el IPS podría ajustarse específicamente para obtener mejores tasas de TP para el tráfico malicioso, pero asegúrese de que las tasas FP/TN/FN también se midan y validen. De esta manera, se puede evaluar adecuadamente la eficacia de las diferentes soluciones, especialmente en lo que se refiere al impacto total para la Organización, tal como se describe en la sección de Impacto a continuación.
• Pruebe los conjuntos de datos de Nuevo y compárelos. Busque personalizar los conjuntos de datos para reflejar los ajustes razonables de un atacante. Hay varias formas de hacerlo.
  • Por ejemplo, al probar Cobalt Strike, sus perfiles maleables C2 se pueden modificar fácilmente para emular aplicaciones benignas de manera un poco diferente o completamente nuevas aplicaciones benignas que se utilizan dentro de la organización específica. Esto se puede hacer olfateando el tráfico saliente HTTP/S a través de un proxy.
  • Pruebe no solo una, sino varias herramientas del marco C2, ya que difieren en capacidades y técnicas. El uso de una herramienta de marco C2 diferente también es un buen cambio, ya que su modelado de tráfico C2 será diferente.
  • La creación de una carga útil de prueba personalizada con sus propias comunicaciones C2 codificadas a mano es otra forma de cambiar los conjuntos de datos de prueba, pero requiere la mayor cantidad de tiempo e inversión.

Pruebas de resiliencia
Al realizar pruebas con conjuntos de datos Nuevo en diferentes soluciones, también obtenemos información valiosa sobre la rigidez frente a la resiliencia de las diferentes soluciones. En este artículo, hemos planteado la cuestión de que los enfoques codificados y basados en firmas no solo son menos efectivos para detectar marcos C2, sino que también son rígidos, lo que resulta en altas tasas de FP/FN y permiten una fácil omisión con cambios de ataque simples, como cambios de perfil maleables.

La resiliencia de cualquier solución se puede probar asegurándose de que los conjuntos de datos se modifiquen dentro de lo razonable (es decir, permanezcan dentro de la misma categoría TTP). En otras palabras, podemos realizar una prueba de resiliencia realista cambiando las comunicaciones C2 dentro del conjunto de datos de tráfico malicioso utilizando perfiles maleables C2 y monitoreando las tasas TP/TN/FP/FN. Vemos cómo varía la cobertura y también entendemos qué cambios en la solución de detección se deben realizar para mantener la cobertura de objetivos TP/TN/FP/FN particulares.

Volver a probar con conjuntos de datos modificados de esta manera es análogo a un atacante que cambia su TTP. Evalúa la resistencia y la eficacia de la solución de detección Nuevo, ya que podemos ver si todavía es capaz de detectar cambios dentro de la misma categoría de técnica de amenazas (comunicaciones C2 a través de HTTP/S).

Impacto de falsos positivos y falsos negativos
La medición de las tasas de FP/FN es buena y permite una mejora relativa, pero también necesitamos medir o al menos estimar el impacto de los FPS y FN, de lo contrario es imposible evaluar la verdadera utilidad de cualquier solución de detección. En otras palabras, una tasa de FP del 1% o una mejora del 5% en la tasa de FP no tiene contexto a menos que podamos medir el impacto de ese 1% o +5% de alguna manera que tenga sentido para los responsables de la toma de decisiones sobre el presupuesto de seguridad.

He aquí dos enfoques que pueden ayudar a traducir las tasas de TP/TN/FP/FN en un impacto más cuantificable:

1. Impacto en el usuario a lo largo del tiempo: observe el número absoluto de falsos positivos que son equivalentes a las tasas de FP y normalice como una tasa por usuario a lo largo del tiempo. Esta es una medida cualitativa, pero a menudo tiene más sentido que las tasas porcentuales o los números absolutos. Por ejemplo, en lugar de un 1% de FP o 2.437 falsos positivos, puede ser más fácil evaluar el impacto de 0,1 falsos positivos por usuario al día. Si se tratara de una puerta de enlace web segura, alguien en la Organización podría determinar si un determinado objetivo de FP es aceptable en función del impacto del usuario a lo largo del tiempo. En este caso, el malware habilitado para el marco C2 da lugar a infracciones, y el impacto en el usuario se caracteriza más como tiempo de inactividad o pérdida de datos por usuario durante un período de tiempo. Tenemos un N% de posibilidades de $X pérdida por usuario cada año. A menudo se trata de estimaciones aproximadas, pero cualquier comienzo es útil, ya que se puede revisar y mejorar con iteraciones regulares. Si el impacto se evalúa en términos de usuarios a lo largo del tiempo, entonces resulta fácil evaluar las soluciones de detección o protección, que a menudo tienen un precio basado en el número de usuarios por año.
2. El impacto de las operaciones de seguridad es en términos de tiempo, dinero y probabilidad de infracción. Además del impacto en el usuario final, se debe evaluar el impacto administrativo, en particular el personal de operaciones que a menudo dedica tiempo a manejar las alertas de detección. El tiempo dedicado a responder a las alertas ruidosas se puede traducir directamente en el coste salarial de los FTE. El factor adicional de la fatiga de alerta es un impacto real que se puede estimar en términos de eficacia (tiempo de respuesta) y, lo que es más importante, como la pérdida de tiempo y atención a amenazas de mayor impacto que se pierden o no se investigan. Este último impacto se convierte en un factor de impacto en las infracciones: es más probable que se produzcan infracciones cuando las operaciones de seguridad tienen demasiados falsos positivos para investigar y eliminar.

Una evaluación de impacto es a menudo la única forma de comprender información crucial, como el verdadero costo de la eficacia de la detección. Por ejemplo, una solución de detección demasiado agresiva con una configuración de FN bajos y FP altos es inútil y dañina porque las operaciones de seguridad pierden una cantidad excesiva de tiempo respondiendo a alertas de baja fidelidad en lugar de participar en actividades de mayor apalancamiento. Del mismo modo, una solución de detección excesivamente conservadora con FP bajos pero FN altos, expone a la Organización a un alto riesgo de una posible infracción, lo que puede ser inaceptable desde el punto de vista general de la evaluación de riesgos.

El impacto debe estimarse y evaluarse al mismo tiempo que las métricas básicas de TP/FP/TN/FN.

Pruebas realistas

Equipo rojo con humanos, no solo con herramientas automatizadas de violación o pruebas de penetración. Se recomienda encarecidamente utilizar no solo usuarios y entornos de producción para probar las soluciones de balizamiento C2, sino también utilizar escenarios adversos realistas, como pruebas de penetración o recompensas por errores. Al ajustar los montos de las recompensas y los requisitos para mostrar la implantación explícita y las acciones exitosas posteriores a la explotación de los kits de herramientas populares del marco C2, podemos hacer que el "tráfico malicioso" sea real y medible. Esto podría ampliarse a cualquier actividad de balizamiento C2, incluido el código personalizado para probar la resistencia de la solución de detección, y el requisito de prueba debería incluir la demostración de la actividad diaria exitosa de balizamiento y la ejecución de comandos durante una semana, sin detección.

Si se repite una prueba de penetración externa o un programa de recompensas por errores, las diferencias en las tasas de detección serán medibles y útiles para evaluar la eficacia y el retorno de la inversión.

Con un enfoque riguroso de las pruebas, no solo se medirá la eficacia de las pruebas de manera integral, sino que también se pueden crear objetivos y metas continuos en relación con una línea de base actual/histórica. Y, ciertamente, si se realizan las mismas pruebas y mediciones para varias soluciones, es trivial comparar el rendimiento y tomar decisiones de compra/implementación.

La investigación y el diseño que involucran estos conceptos y el enfoque general se discuten con más detalle en: Sistemas de seguridad y métodos para detectar comando y control maleables (Mulugeta).