jconwell/secret_handshakeUn canal C2 prototipo de malware que utiliza certificados x509 sobre mTLS
En primer lugar, ¿por qué liberaría esto como código abierto?
MITRE ATT&CK solo habla de certificados robados o autofirmados, y los NDR (por lo que sé) prestan muy poca atención al contenido de los certificados x509 más allá de quién es la CA emisora. En general, los certificados x509 son de confianza y se les permite atravesar nuestros firewalls con impunidad. Pero en esencia son solo archivos que pueden contener payloads maliciosos con la misma facilidad que cualquier otro. Confiamos en ellos y los ignoramos porque son un componente central de un proceso de cifrado que damos por sentado. El objetivo principal de este proyecto es generar una mayor conciencia sobre una clase de indicador de seguridad en la que hemos llegado a confiar, y resaltar métodos que se pueden utilizar para detectar usos maliciosos de esta.
Siempre me pregunté si los actores de amenazas han utilizado alguna vez certificados x509 como parte de su comunicación C2, no para cifrar el tráfico de red, sino para incrustar realmente la comunicación C2 en el certificado x509. Después de buscar algo así en la naturaleza durante 5 años, finalmente decidí programarlo yo mismo para ver si es posible... y lo es.
Cada mensaje cifrado enviado a través de HTTPS/TLS es posible gracias a la transferencia de un certificado x509. Cuando se establece un handshake TLS (figura siguiente), durante el cuarto paso el servidor envía su certificado x509 al cliente. El cliente verifica el certificado, compara los algoritmos de cifrado que soporta el servidor y elige qué algoritmo utilizar para toda la comunicación posterior.
Como muestra este diagrama, esto es solo una transferencia unidireccional del certificado x509 del servidor al cliente. Esto no se presta bien para la comunicación C2 porque no hay forma de que el cliente responda al servidor. En el mejor de los casos, solo podría utilizarse como un mecanismo de transferencia de datos unidireccional (consulta la sección de trabajos previos más abajo).
Pero existe otro tipo de sesión TLS llamada autenticación TLS mutua (mTLS), en la que tanto el cliente como el servidor intercambian certificados x509 como forma de autenticarse mutuamente.
Como muestra la figura anterior, durante la autenticación mutua el certificado x509 del servidor se envía al cliente para su autenticación, y luego el certificado x509 del cliente se envía al servidor para su autenticación. Este intercambio de artefactos representa una oportunidad para crear un canal de comunicación bidireccional para servidores C2.
Dado que la biblioteca SSL subyacente intercambia los certificados del servidor y del cliente, no existe la oportunidad de que el cliente extraiga el mensaje del certificado del servidor, ejecute el comando y genere un certificado de respuesta, todo dentro de una sola conexión mTLS. Esto significa que el canal C2 debe diseñarse de modo que el intercambio de solicitud-respuesta se realice a través de dos conexiones TLS mutuas diferentes, algo así como un modo de transmisión semidúplex.
El proceso de solicitud/respuesta sigue los siguientes pasos:
Después de que esto funcionara, me sentí bastante orgulloso de mí mismo por ser tan creativo y todo eso.
Luego me topé con esta charla de BSides de 2018 de Jason Reaves, quien escribió un dropper de binarios de malware utilizando certificados x509 sobre TLS. Un año después, Jason publicó este artículo en el que detalla un canal de comunicación bidireccional completo mediante mTLS.
mTLS requiere que tanto los certificados del cliente como los del servidor estén firmados por el mismo certificado CA, por lo que el primer paso es generar tu propio par de clave privada / certificado de CA.
Crea la clave privada de la CA raíz:
openssl genrsa -des3 -out hmCA.key 2048
nota: la frase de contraseña evitará que cualquiera que obtenga tu clave privada genere su propio certificado raíz.
Crea el certificado de la CA raíz:
openssl req -x509 -new -nodes -key hmCA.key -sha256 -days 1825 -out hmCA.pem
Copia los archivos de clave y certificado generados en la carpeta certs/ca_certs. El proyecto incluye un par de clave/certificado de demostración, por lo que puedes omitir este paso si quieres.
Inicia el cliente:
python client.py
Inicia el servidor:
python server.py
Nunca quiero publicar algo potencialmente malicioso sin detallar también cómo detectarlo en los registros de tu red.
Uno pensaría que detectar este tipo de patrón TLS sería fácil, pero no es tan simple. Una de las principales señales de este canal C2 es su estilo de comunicación semidúplex; se necesitan dos flujos de autenticación mutua para completar una solicitud/respuesta completa entre el servidor y el cliente. Esto sucederá varias veces, ya que el servidor envía diferentes comandos al cliente.
Esto significa que debes buscar:
Esto parece un conjunto de reglas de detección infalible, pero como dije antes, no es tan fácil. Resulta que hay un conjunto de servicios empresariales que también tienen un patrón de tráfico mTLS similar, entre ellos:
Varios de estos parecen ser servicios de gestión de activos/dispositivos, por lo que en teoría deberían enviar el mismo conjunto de certificados cada vez que recorren todos sus dispositivos. Podrías ver si hay conjuntos de múltiples sesiones mTLS que se repiten cada N horas, y luego comprobar si los hash de los certificados entre dos conjuntos diferentes de sesiones mTLS coinciden, o coinciden en su mayoría. También podrías buscar que los certificados del cliente sean diferentes en cada sesión mTLS, pero el mismo certificado del servidor en todas las sesiones.
La inspección SSL es una forma de bloquear potencialmente este tipo de canal de comunicación C2, ya que el servidor de inspección SSL no tendría el certificado CA malicioso necesario para autenticar el certificado del cliente.
