jconwell/secret_handshakeUm protótipo de canal C2 de malware usando certificados x509 sobre mTLS
Em primeiro lugar, por que eu disponibilizaria isso como código aberto?
A MITRE ATT&CK fala apenas sobre certificados roubados ou autoassinados, e os NDRs (até onde eu sei) prestam muito pouca atenção ao conteúdo dos certificados x509 fora de quem é a CA emissora. Em geral, os certificados x509 são confiáveis e têm permissão para passar pelos nossos firewalls impunemente. Mas, na essência, são apenas arquivos que podem facilmente conter payloads maliciosos como qualquer outro. Nós os confiamos e ignoramos porque são um componente central de um processo de criptografia que passamos a considerar natural. O principal objetivo deste projeto é trazer maior conscientização para uma classe de indicador de segurança em que passamos a confiar, e destacar métodos que podem ser usados para detectar usos maliciosos dela.
Sempre me perguntei se atores de ameaças já usaram certificados x509 como parte de sua comunicação C2, não para criptografar o tráfego de rede, mas para realmente embutir a comunicação C2 no certificado x509. Depois de procurar por algo assim no mundo real por 5 anos, finalmente decidi codificar eu mesmo para ver se é possível... e é.
Cada mensagem criptografada enviada por HTTPS/TLS é viabilizada pela transferência de um certificado x509. Ao estabelecer um handshake TLS (figura abaixo), durante o quarto passo o servidor envia seu certificado x509 ao cliente. O cliente verifica o certificado, compara os algoritmos de criptografia que o servidor suporta e escolhe qual algoritmo usar para toda comunicação posterior.
Como este diagrama mostra, esta é apenas uma transferência unidirecional do certificado x509 do servidor para o cliente. Isso não se presta bem à comunicação C2 porque não há como o cliente responder de volta ao servidor. Na melhor das hipóteses, só poderia ser usado como um mecanismo de transferência de dados unidirecional (veja a seção de trabalhos anteriores abaixo).
Mas existe outro tipo de sessão TLS chamado Autenticação TLS mútua (mTLS), em que tanto o cliente quanto o servidor trocam certificados x509 como forma de autenticar um ao outro.
Como a figura acima mostra, durante a autenticação mútua, o certificado x509 do servidor é enviado ao cliente para autenticação e, em seguida, o certificado x509 do cliente é enviado ao servidor para autenticação. Essa troca de artefatos representa uma oportunidade de criar um canal de comunicação bidirecional para servidores C2.
Como os certificados do servidor e do cliente são trocados pela biblioteca SSL subjacente, não há oportunidade para o cliente extrair a mensagem do certificado do servidor, executar o comando e gerar um certificado de resposta tudo dentro de uma única conexão mTLS. Isso significa que o canal C2 precisa ser projetado de forma que a troca de solicitação-resposta ocorra em duas conexões TLS mútuas diferentes, algo como um modo de transmissão pseudo-half duplex.
O processo de solicitação/resposta segue as seguintes etapas:
Depois que consegui fazer isso funcionar, fiquei muito orgulhoso de mim por ser todo criativo e tal.
Então me deparei com esta palestra da BSides em 2018 por Jason Reaves, que escreveu um dropper de binário de malware usando certificados x509 sobre TLS. Um ano depois, Jason publicou este artigo detalhando um canal de comunicação bidirecional completo usando mTLS.
O mTLS exige que tanto os certificados do cliente quanto os do servidor sejam assinados pelo mesmo certificado CA, então o primeiro passo é gerar seu próprio par de chave privada / certificado CA
Crie a chave privada da CA raiz:
openssl genrsa -des3 -out hmCA.key 2048
nota: A frase secreta impedirá que qualquer pessoa que obtenha sua chave privada gere um certificado raiz próprio.
Crie o certificado da CA raiz
openssl req -x509 -new -nodes -key hmCA.key -sha256 -days 1825 -out hmCA.pem
Copie os arquivos de chave e certificado gerados para a pasta certs/ca_certs. O projeto vem com um par
de chave/certificado de demonstração, então você pode pular esta etapa se quiser.
Inicie o cliente:
python client.py
Inicie o servidor:
python server.py
Nunca quero lançar algo potencialmente malicioso sem também detalhar como detectá-lo em seus logs de rede.
Você pensaria que detectar esse tipo de padrão TLS seria fácil, mas não é tão simples assim. Um dos principais indícios desse canal C2 é seu estilo de comunicação half-duplex; são necessários dois fluxos de autenticação mútua para completar uma solicitação/resposta completa entre o servidor e o cliente. Isso então acontecerá várias vezes, conforme o servidor envia diferentes comandos ao cliente.
Isso significa que você deve procurar por:
Isso parece um conjunto de regras de detecção infalíveis, mas como eu disse antes, não é tão fácil. Acontece que há um conjunto de serviços empresariais que também têm um padrão de tráfego mTLS semelhante, incluindo
Vários desses parecem ser serviços de gerenciamento de ativos/dispositivos, então, em teoria, eles deveriam enviar o mesmo conjunto de certificados toda vez que passam por todos os seus dispositivos. Você poderia verificar se há conjuntos de múltiplas sessões mTLS se repetindo a cada N horas e, em seguida, ver se os hashes dos certificados entre dois conjuntos diferentes de sessões mTLS correspondem, ou correspondem em sua maioria. Além disso, procure potencialmente por certificados de cliente diferentes para cada sessão mTLS, mas o mesmo certificado de servidor em todas as sessões.
A inspeção SSL é uma forma de potencialmente bloquear esse tipo de canal de comunicação C2, pois o servidor de inspeção SSL não teria o certificado CA malicioso necessário para autenticar o certificado do cliente.
