Analistas de vírus e pesquisadores de segurança cibernética estão sempre em busca de coletar o máximo de amostras possíveis de novas botnets. Para isso, eles utilizam honeypots... Mas e se você quiser observar o malware em condições reais? Colocar seu servidor ou roteador em risco? E se você não tiver o dispositivo apropriado? Essas questões me levaram a criar o bhunter — uma ferramenta para acessar nós de redes bot.

A ideia principal

Existem muitos métodos de propagação de malware para expandir botnets: desde phishing até a exploração de vulnerabilidades 0-day. No entanto, o método mais comum ainda continua sendo a força bruta de senhas SSH.

A ideia é muito simples. Se um nó da botnet estiver tentando fazer repetidamente força bruta em sua senha de servidor, é provável que esse nó tenha sido capturado por meio de força bruta de senhas simples. Portanto, para acessá-lo, basta responder com "mútua reciprocidade".

É assim que o bhunter funciona. Ele escuta a porta 22 (serviço SSH) e coleta todos os logins e senhas que tentam se conectar a ele. Em seguida, usando as senhas coletadas, tenta se conectar aos nós atacantes.

Algoritmo de operação

O programa pode ser dividido em 2 partes principais que funcionam em threads separadas. A primeira — honeypot. Ela processa tentativas de login, coleta logins e senhas únicas (neste caso, o par login+senha é tratado como um todo), além de adicionar à fila para ataque futuro os endereços IP que tentaram se conectar.

A segunda parte é responsável diretamente pelo ataque. O ataque é realizado em dois modos: BurstAttack (ataque em fila) — força bruta de logins e senhas de uma lista geral e SingleShotAttack (ataque de disparos únicos) — força bruta de senhas que foram usadas pelo nó atacado, mas ainda não adicionadas à lista geral.

Para ter uma base mínima de logins e senhas logo após a inicialização, o bhunter é inicializado com uma lista fornecida pelo arquivo /etc/bhunter/defaultLoginPairs.

Interface

Há várias maneiras de iniciar o bhunter:

Simplesmente com o comando

sudo bhunter

Com essa inicialização, é possível gerenciar o bhunter através de seu menu de texto: adicionar logins e senhas para ataque, exportar a base de logins e senhas, especificar um alvo para ataque. Todos os nós comprometidos podem ser vistos no arquivo /var/log/bhunter/hacked.log.

Usando tmux

sudo bhunter-ts # comando para iniciar bhunter através do tmux  
sudo tmux attach -t bhunter # conectando-se à sessão onde o bhunter está em execução

Tmux é um multiplexador de terminal, uma ferramenta extremamente útil. Permite criar várias janelas dentro de um único terminal e dividir as janelas em painéis. Usando-o, você pode sair do terminal e depois voltar sem interromper os processos em execução.

O script bhunter-ts cria uma sessão tmux e divide a janela em três painéis. No primeiro — o maior, fica o menu de texto. O painel superior direito contém os logs do honeypot, onde você pode ver mensagens sobre tentativas de acesso ao honeypot. No painel inferior direito, é exibida a informação sobre o progresso dos ataques às máquinas botnet e sobre os sucessos nos hacks.

A vantagem desse método em relação ao primeiro é que podemos fechar o terminal com segurança e voltar a ele mais tarde, enquanto o bhunter continuará a funcionar. Para aqueles que não estão familiarizados com o tmux, recomendo este guia.

Como serviço

systemctl enable bhunter
systemctl start bhunter

Neste caso, estamos ativando o início automático do bhunter ao iniciar o sistema. Neste método, a interação com o bhunter não é prevista, e a lista de nós comprometidos pode ser obtida de /var/log/bhunter/hacked.log

Eficiência

Durante o tempo em que trabalhei no bhunter, consegui encontrar e acessar dispositivos diferentes, como raspberry pi, roteadores (especialmente mikrotik), servidores web, e uma vez, uma fazenda de mineração (infelizmente, o acesso foi apenas durante um dia, então não tive uma história interessante para contar). Aqui está uma captura de tela do programa, mostrando a lista de nós hackeados após alguns dias de operação:

Infelizmente, a eficácia desta ferramenta não atendeu às minhas expectativas: o bhunter pode tentar várias senhas em nós por dias sem sucesso, ou pode hackear várias alvos em poucas horas. Mas para um fluxo regular de novas amostras de botnets, isso é suficiente.

Fatores como: o país onde o servidor com bhunter está localizado, o provedor de hospedagem, e o intervalo do qual o endereço IP é alocado influenciam a eficácia. Na minha experiência, houve um caso em que aluguei dois servidores virtuais de um mesmo provedor, e um deles foi alvo de ataques de botnets duas vezes mais frequente.

Bugs que ainda não corrigi

Ao atacar nós comprometidos, em algumas situações, não é possível determinar com precisão se a senha estava correta ou não. O registro de tais casos é feito no arquivo /var/log/debug.log.

O módulo Paramiko, que é usado para trabalhar com SSH, às vezes se comporta de maneira irregular: ele entra em um estado de espera infinita por uma resposta do nó quando tenta se conectar a ele. Experimentei com timers, mas não obtive o resultado desejado.

Em que mais precisamos trabalhar?

Nome do serviço

De acordo com o RFC-4253, o cliente e o servidor trocam nomes de serviços que implementam o protocolo SSH antes de estabelecer a conexão. Esse nome é encontrado no campo "SERVICE NAME", que está presente tanto na solicitação do cliente quanto na resposta do servidor. O campo é uma string, e seu valor pode ser obtido usando wireshark ou nmap. Aqui está um exemplo para OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Iniciando o Nmap ...
PORTA ESTADO SERVIÇO VERSÃO
22/tcp aberto  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protocolo 2.0)
Nmap concluído: 1 endereço IP (1 host ativo) escaneado em 0,47 segundos

No entanto, no caso do Paramiko, esse campo contém uma string do tipo "Paramiko Python sshd 2.4.2", o que pode afastar botnets que têm a capacidade de "evitar" armadilhas. Portanto, considero necessário substituir essa string por algo mais neutro.