Desativação acidental de um botnet
Resumo executivo
Os pesquisadores da Akamai continuaram suas pesquisas sobre o KmsdBot, um botnet de cryptomining, e testemunharam os agentes o desativarem acidentalmente.
Em nosso ambiente controlado, nós conseguimos enviar comandos ao bot para testar suas funcionalidades e suas assinaturas de ataque.
Como parte dessa análise, um erro de sintaxe fez com que o bot parasse de enviar comandos, o que desativou o botnet efetivamente.
Como esse botnet específico não busca obter persistência em um sistema, ele só pode continuar sua missão se infectar o sistema novamente.
Introdução
No início deste mês, a Akamai Security Research fez uma publicação no blog sobre o KmsdBot, um botnet de cryptomining que infectou vítimas por meio de SSH e credenciais fracas. Analisamos esse botnet e geramos relatórios imediatamente depois de ele infectar uma de nossas armadilhas virtuais (honeypots).
No entanto, depois dessa publicação, continuamos monitorando o botnet e, agora, temos algumas atualizações para compartilhar nesta publicação do blog, como o fato de que conseguimos desativá-lo. Nesta publicação, descreveremos as etapas que seguimos para inspecionar o KmsdBot e que resultaram em nossa capacidade de executar comandos e, por fim, em sua desativação.
Execução de C2 no próprio C2
O elemento mais letal de qualquer entidade mal-intencionada é a capacidade de obter C2 (comando e controle). Como o KmsdBot tinha a funcionalidade de C2, queríamos testar vários cenários relacionados a isso. Parte desses testes incluía a modificação de uma amostra recente do KmsdBot para se comunicar com um endereço IP no espaço de endereços RFC 1918.
Com isso, conseguimos ter um ambiente controlado para fazer experimentos e, como resultado, conseguimos enviar nossos próprios comandos ao bot para testar suas funcionalidades e suas assinaturas de ataque. Curiosamente, depois de um só comando formatado incorretamente, o bot parou de enviar comandos. Naturalmente, iniciamos uma investigação. Não é todos os dias que nos deparamos com um botnet cujos agentes de ameaça derrubam seu próprio produto.
Como descobrimos isso
Fig. 1: desmontagem da função sys.main.connect()
Veja que o recorte da cadeia de caracteres está armazenado no local de memória 0x00632f19. Podemos avançar para esse endereço no binário e modificar o conteúdo dele para apontar para um endereço de rede do espaço RFC 1918, ou seja, em algum lugar próximo a 192.168.0.0/24, que nós controlamos.
Dessa forma, podemos atuar como o C2 e enviar exemplos de comandos de ataque para direcionar o tráfego de ataque a um destino onde podemos registrar o tráfego da rede.
Fig. 2: escrita do endereço em formato hexadecimal .861.291 inverso devido à ordenação de bits
Portanto, nosso novo C2 é 192.168.0.31 na porta 57388 (Figura 2). Sabemos que o C2 se comunica em texto não criptografado; portanto, é possível enviar os comandos de malware usando Netcat. Em seguida, configuramos duas máquinas virtuais: uma na qual acionamos o malware e outra para usar como nosso C2.
Durante os testes, notamos que o botnet parou de enviar comandos de ataque depois de observar um só comando malformado que foi executado. O comando:
!bigdata www.bitcoin.com443 / 30 3 3 100
Um observador atento perceberá a falta de espaço entre o website de destino e a porta. O bot não tem verificação de erros integrada ao código para verificar se os comandos estão formatados corretamente.
Por isso, um comando formatado incorretamente fará com que o binário Go apresente falha com um rastreamento de pilha que informa um erro de "índice fora do intervalo". Isso ocorre porque um número incorreto de argumentos foi informado. Nós testamos essa teoria com nossa configuração de C2 e bot (Figura 3).
Fig. 3: emulação do C2 e reprodução do comando malformado que foi enviado
Fig. 4: o bot foi desativado porque um número incorreto de argumentos foi informado
Provavelmente, esse comando malformado gerou uma falha em todo o código do botnet que estava em execução nas máquinas infectadas e se comunicando com o C2. Basicamente, isso desativou o botnet. Como o bot não tem qualquer funcionalidade de persistência em uma máquina infectada, a única maneira de se recuperar é causar uma nova infecção e recriar o botnet do zero.
Conclusão
Na área de segurança, essas histórias não acontecem com frequência. Em nosso mundo de dias zero e esgotamento, é muito bom ver que é possível mitigar uma ameaça com uma codificação equivalente a um erro de digitação. Esse botnet persegue grandes marcas de luxo e empresas de jogos e, no entanto, é desativado após um comando com falha. Este é um exemplo importante da natureza instável da tecnologia e de como até mesmo o explorador pode ser explorado por ela.
O objetivo da Akamai Security Research é rastrear, detectar, documentar e publicar novas descobertas para proteger a segurança e a estabilidade da Akamai, dos clientes da Akamai e da Internet como um todo. Continuaremos monitorando esses ataques e atualizando este blog. Para obter atualizações em tempo real sobre as pesquisas de segurança, siga-nos no Twitter.
