Colocamos 5 honeypots, doravante simplesmente "servidores", para coletar estatísticas sobre força bruta RDP em nossas redes.
Um servidor estava localizado em Londres, outro em Zurique, um em uma rede segura em M9, dois outros no data center Rucloud em uma rede segura e não segura. Os endereços IP de cada um dos servidores estão em sub-redes diferentes, cada endereço IP é distinguido pelo primeiro octeto. Se você tentar medir a "distância" de varredura entre os endereços IP usando a fórmula:
((Primeiro octeto da sub-rede # 1) - (Primeiro octeto da sub-rede # 2)) * (2 ^ 24),
Se você fizer a varredura para 0.0.0.0/0, um invasor terá que percorrer pelo menos 771751936 endereços IP para encontrar os dois servidores mais próximos um do outro. Além disso, nenhum dos servidores respondeu ao ICMP e cada endereço IP não foi usado por ninguém por 3 meses, todos os 5 servidores abriram portas ao mesmo tempo. Todos os servidores foram conectados ao AD.
Gráficos multicoloridos
Começamos com o interessante e terminamos com o significativo.
O começo foi bom. O primeiro bruteforcer entrou no servidor em Rucloud na primeira hora em que a porta foi aberta. Em todos os outros data centers, o servidor foi descoberto apenas na segunda hora.
Como você pode ver nos gráficos, a força bruta não mudou muito de um dia para o outro. E se você olhar a hora do dia? Aqui estão os gráficos. Cores diferentes são dias diferentes.
Programação de hora do dia dc ZUR1.
Gráfico da hora do dia na sub-rede protegida M9.
Gráfico de hora do dia em DC LD8.
Gráfico de hora do dia na sub-rede protegida Rucloud.
Gráfico de hora do dia em Rucloud.
Imagem um tanto chata, podemos dizer que a imagem não muda dependendo da hora do dia.
Vamos olhar os mesmos gráficos por hora do dia, mas no total para todos os data centers.
Gráfico de hora do dia empilhado.
Gráfico de hora do dia.
O padrão de força bruta não muda dependendo da hora do dia. Ou seja, os dispositivos que participaram do ataque de força bruta provavelmente estão sempre ligados.
Estatísticas de tentativas de login malsucedidas para cada endereço em uma sub-rede Rucloud desprotegida.
No total, 89 endereços IP participaram da busca por uma semana inteira em uma das sub-redes Rucloud desprotegidas. 10 endereços IP preencheram 50% de 114.809 tentativas.
Estatísticas de tentativas de login malsucedidas para cada endereço de todos os centros de dados.
A mesma coisa, mas apenas com estatísticas para todos os data centers. 50% de todas as estatísticas preencheram 15 endereços IP. Houve mais de meio milhão de tentativas em todos os cinco servidores. Quão diferentes eram os atacantes?
143 endereços IP foram vistos em todas as redes e apenas 29 endereços IP foram vistos em todos os 5 servidores. Menos da metade de todos os invasores estavam atacando 2 ou mais servidores. Isso significa que a distância de varredura entre os endereços IP é importante. Isso significa que os invasores obtiveram informações sobre portas abertas usando o nmap, verificando os endereços IP um por um.
Contando botnets
Olhando para os relatórios e nomes de usuário que foram usados para a pesquisa, fiquei impressionado com os dicionários que usavam endereços IP diferentes, o número de logins nos dicionários.
Suponha que sejam todos botnets diferentes com vocabulários diferentes, então contei N botnets. Aqui estão os dicionários para cada um deles:
admin, administrador, administrador, administrateur, admin, administrador, administrador, administrateur, ADMIN, USER, USER1, TEST, TEST1, ADMINISTRATOR, USER1, USER2, USER3, USER4, USER5, USER6, USER7, USER8, USER9, HP, ADMIN, USER, PC, DENTAL
Este botnet era o maior e usava o maior dicionário. Houve muitos logins em diferentes idiomas, incl. Russo, francês e inglês:
1, 12, 123, 1234, 12345, 13, 14, 15, 19, 1C, CÂMERA, CÂMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADM, ALYSSA, ADMINISTRATOR, CÂMERA, AT CÂMERA, ADMIN, USERL8, GVC, ADMINISTRATEUR, USR_TERMINAL, JEREMY, IPAD3, USR_TERMINAL, JEREMY, ADMINISTRATOR, ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA, SYSTEM, ADISORIS, GVC, USREMINAL ADMIN, ADM, SERGEY, OLEG, IRINA, NATASHA e assim por diante, incluindo até logins chineses.
Havia dicionários que usavam apenas palavras em chinês e inglês. Não consegui extrair caracteres chineses do banco de dados usando o Powershell. Aqui está apenas uma parte do vocabulário dos camaradas chineses:
SHENZHEN, TIANJIN, MANDARIN, CHONGQING, SHENYANG, XIAN, CONTRAS, CHINA, TECNOLOGIA, ISPADMIN, BEIJING, SHANGHAI
Também havia endereços IP únicos tentando iterar nesses logins. Provavelmente, apenas crianças estão brincando:
USR1CV8, ADMINISTRADOR
ADMI, NIMDA, ADMS, ADMINS
Há apenas um estúpido ataque de força bruta às senhas, uma pesquisa de dicionário por senhas, mas há uma pesquisa mais ou menos interessante. Os invasores têm a capacidade de obter nomes de usuário, compartilhamentos SMB, às vezes até hashes de senha, nomes de computador, AD ou nomes de domínio do grupo de trabalho.
Os especialistas em segurança conhecem o BloodHound e os hackers sabem disso. Se deixarmos o AD em seu estado padrão, podemos roubar o nome de domínio, o nome do computador e até mesmo hashes de senhas de usuários. Habré já escreveu sobre vetores de ataque no AD e sobre esta ferramenta. Eu recomendo a leitura deste material brilhante .
A propósito, o primeiro ataque usando o nome do servidor e domínio começou 13 horas após as portas serem abertas, mas o invasor rapidamente ficou para trás, tentando invadir apenas 138 vezes. O segundo ataque com o mesmo dicionário foi repetido 3 dias depois, mas também não durou muito.
Um total de 5 botnets com diferentes dicionários. Será necessário coletar estatísticas mais detalhadas sobre os logins usados para entender quais são usados com mais frequência e em que proporções. É muito provável que a primeira vista seja borrada por uma coleta não muito precisa de todas as estatísticas e a imagem real seja um pouco mais interessante.
Isso é um problema?
Desde o início do auto-isolamento, começamos a registrar uma indisponibilidade de servidor muito estranha. No início, atribuímos tudo à sobrecarga da rede de provedores domésticos de Internet, Netflix e torrents, às vezes a infraestrutura não estava pronta.
As suspeitas sobre a infraestrutura desapareceram rapidamente quando nossos poucos clientes no Windows Server 2008, eles não puderam ir para o RDP em princípio. Após consultar o log de segurança, registramos taxas recordes de ataques, mais de 36 mil tentativas em 24 horas.
Como se viu, força bruta de intensidade suficiente é capaz de matar completamente o RDP ou causar interrupções permanentes.
A gênese do problema não é totalmente compreendida. O RDP é colocado por todo o pacote ou por algum invasor. O script e o mstsc.exe não conseguiram reproduzir desconexões e congelamentos de imagem.
A força bruta se transforma em DDoS ou alguns dos atacantes têm uma implementação de força bruta de alguma forma especial, o que também causa problemas. A única coisa que está clara é que o momento da desconexão coincide com as tentativas de login malsucedidas.
Os ataques mais brutais ocorreram neste verão em junho, quando nosso suporte registrou o maior número de atrasos e quebras de RDP. Infelizmente, ainda não coletamos estatísticas.
Fonte: Kaspersky
Decisão?
Sim.
Tudo que você precisa fazer para se proteger é se proteger com um firewall. Mas sinto a mesma preguiça que você, por isso fiz esses módulos.
Os módulos funcionam no Windows Powershell 5.1 e Powershell Core 7. O link para o github do projeto está aqui . Agora vamos dar uma olhada nas funções.
Protect-Bruteforce
Até agora, o módulo é chamado assim. Modifica a regra de firewall adicionando à regra todos os endereços IP registrados com êxito. Conveniente para uso em conjunto com um endereço IP estático, simplifica a implantação de servidores de desktop remotos em conjunto com um gateway VPN.
Desproteger-Força Bruta
Redefine RemoteAddress para regras de firewall padrão.
Stop-Bruteforce
Verifica o log de eventos em busca de logins com falha e bloqueia endereços IP da lista com uma regra "Stop-Bruteforce" separada.
Get-Bruteforce
Retorna uma matriz de objetos de estatísticas para cada endereço IP. Esta função foi usada para coletar estatísticas para os gráficos acima.
Entrevista
Nós da RUVDS acreditamos que o sistema operacional deve ser entregue ao usuário em um estado extremamente inalterado. Achamos que, em um mundo ideal, o sistema operacional deveria ser apresentado como estava em seu estado original quando foi lançado pela primeira vez. Afinal, funções como a geração de senhas da conta pessoal não só simplificam a vida, como são necessárias para muitos de nossos clientes. Gostaríamos de saber a sua opinião sobre este tipo de peças de qualidade de vida. Vote e comente.
