¿Es operativamente eficaz o eficiente descifrar las cargas útiles de los paquetes para ayudar a los defensores a encontrar en una red indicios de ataques avanzados de estados-nación o de ataques ejecutados manualmente como RansomOps?
La respuesta corta es no.
- El descifrado pasivo de un cifrado estándar como TLS es caro desde el punto de vista operativo (con TLS 1.3, requiere la instalación de un agente en todos y cada uno de los puntos finales conectados).
- El descifrado proporciona pocos beneficios al defensor que el descifrado activo con cortafuegos o proxies no proporcione ya.
- Y ninguno de ellos ayuda realmente a los defensores a rastrear el canal C2 de un atacante avanzado o la exfiltración de datos.
Consideramos el tráfico en los límites de la red de una organización, donde prevalece el cifrado, y buscamos indicios de comando y control y exfiltración de datos. Lo que descubrimos es que el descifrado ofrece muy pocos beneficios, si es que ofrece alguno, a los defensores cuando se trata de detectar ataques avanzados de estados nación o ataques criminales ejecutados manualmente como RansomOps. He aquí por qué.
Las herramientas de ataque al Estado-nación están personalizadas
Los actores estatales suelen crear cadenas de herramientas para uso de sus equipos de ataque. Estas cadenas de herramientas a menudo incluyen herramientas desarrolladas internamente y herramientas más comerciales. Las herramientas comerciales están altamente personalizadas para evitar su detección mediante métodos sencillos que buscan su mera presencia.
Y los actores nacionales más capaces añadirán más entropía: configurarán las herramientas personalizadas y comerciales que utilicen de forma diferente para cada objetivo que persigan, y no reutilizarán ninguna de las infraestructuras (para C2 y Exfil) utilizadas para llevar a cabo ataques contra objetivos diferentes. Por lo tanto, descifrar las cargas útiles para ejecutar firmas no tiene ninguna ventaja significativa para la detección.
Se modifican las herramientas de los atacantes criminales (RansomOps)
Los ataques ejecutados manualmente, como los utilizados para llevar a cabo la mayoría de los ataques de RansomOps, están al servicio de un modelo de negocio con ánimo de lucro. No tiene mucho sentido invertir en I+D para crear herramientas desde cero, ya que eso simplemente reduce los beneficios potenciales.
En su lugar, casi todos los ataques criminales hacen un uso intensivo de herramientas estándar, pero estos actores saben lo suficiente como para no utilizar estas herramientas con la configuración predeterminada, que la mayoría de los productos de firma detectarían.
En su lugar, anularán la configuración estándar con la que se entregan las herramientas estándar, lo que hará que las firmas sean inútiles. La infraestructura se reutiliza con más frecuencia, pero puede identificarse a través de dominios y/o IP sin necesidad de descifrarla. Al igual que en el caso del Estado-nación, descifrar las cargas útiles para ejecutar las firmas no aporta ninguna ventaja significativa a la detección.
El funcionamiento interno de Cobalt Strike
Veamos lo que significa anular la configuración estándar de Cobalt Strike, que es uno de los frameworks de pen testing más conocidos. Este ejemplo es ilustrativo - el mismo grado de configurabilidad existe en cualquier herramienta de pen testing madura, por lo que es trivial anular la configuración predeterminada para evadir firmas.
La guía del usuario de Cobalt Strike puede consultarse aquí. Veamos la capacidad de Command and Control Maleable que forma parte de este paquete. Para utilizar la función C2 maleable, debes componer todas las opciones que quieras utilizar en un perfil.
En el perfil, cada elemento de la solicitud y respuesta HTTPS utilizado para la comunicación C2 es (como el título indica) maleable. Esto incluye el certificado que se utiliza para asegurar el canal TLS que transporta el tráfico HTTP, la URI codificada en la petición HTTP, el User-Agent especificado, la presencia o ausencia de una etiqueta referrer, y cualquier otra cosa que el atacante quiera poner en la petición ya sea para hacerla parecer normal o para hacerla parecer ininteligible.
Cualquier dato real que necesite ser transferido a través del canal C2 puede ser codificado en una variedad de formatos (Base64, NetBIOS, etc.) y puede ser fácilmente enmascarado mediante XOR en una clave aleatoria conocida sólo por el atacante (piense en esto como una forma ligera pero efectiva de encriptación "interna").
Resumen
Tanto si se enfrenta a un Estado-nación como a un atacante de RansomOps (que aplica una buena higiene de seguridad al no reutilizar las mismas etiquetas/valores y claves para diferentes objetivos), romper el cifrado TLS externo para acceder a la solicitud HTTP interna no ayuda al defensor. No existe un patrón fijo para una firma que sirva de objetivo y la carga útil real (comandos enviados, resultados de comandos devueltos, software descargado, etc.) queda oculta por un cifrado ligero que utiliza la clave generada aleatoriamente por el atacante.
Por lo tanto, a menos que una organización esté dispuesta a aplicar una política de acceso a Internet muy restrictiva (creando una lista blanca de la parte de Internet en la que confía), los canales C2 no pueden detectarse buscando patrones de bytes en las cargas útiles HTTP descifradas. La detección de la exfiltración sigue prácticamente la misma lógica. Las cargas útiles internas cifradas son impermeables a los enfoques DLP estándar. Los únicos otros medios de detección de C2 o exfiltración se basan en el análisis de información de series temporales de transferencias de datos o en la observación de simples anomalías de volumen, ninguno de los cuales requiere descifrar la envoltura externa.