Por Threat Intelligence Team
Introdução
Desde seu surgimento, na década de 1990, os ataques de negação de serviço (DoS) e, mais especificamente, os ataques distribuídos de negação de serviço (DDoS), evoluíram de simples inundações de tráfego para sofisticadas campanhas de interrupção. Grandes ataques, como o que aconteceu contra o Yahoo!, em 2000, e a botnet Mirai, em 2016, que utilizou dispositivos IoT para afetar serviços essenciais, marcaram essa evolução. Temos visto que o DDoS se tornou comum em campanhas de ransomware e hacktivismo, com serviços de DDoS-as-a-service, tornando esses ataques mais acessíveis. O impacto inclui interrupções significativas, perda de receita e danos à reputação, enquanto empresas e governos buscam constantemente aprimorar suas defesas contra essa ameaça persistente e em constante evolução.
Em maio deste ano (2024), o time de Threat Intelligence da Tempest identificou uma série de ataques DDoS realizados por uma variante da botnet Mirai contra empresas brasileiras. Os ataques tiveram início em 1º de maio com origem em cerca de 26 servidores de comando e controle (C2), dos quais partiram mais de 9.000 comandos baseados em protocolos como GRE, DNS, UDP e TCP (ACK).
Para detalhar o funcionamento da botnet e fornecer insumos que possam ser usados numa defesa efetiva, reunimos novas informações neste artigo por meio das análises de artefatos, de fontes públicas (OSINT) e do comportamento da ameaça.
Identificação da variante TBOT.mirai
Nosso time monitora milhares de servidores relacionados à botnet Mirai e suas variantes. Dentre os mais de 300 mil ataques observados até o momento, 12 mil visavam empresas na América Latina, principalmente Brasil e Chile, além da Jamaica. Em geral, os ataques realizados por meio de variantes da Mirai visam provedores de internet e servidores de jogos. No entanto, os recentes ataques contra empresas brasileiras chamaram a atenção pelo comportamento incomum.
A partir da análise e investigação dos endereços IP de servidores C2 e das atividades maliciosas relativas à botnet, identificamos novas informações que nos levaram a inferir como moderada a alta confiança que a variante da botnet Mirai, chamada TBOT, seria o cluster[1] de servidores por trás dos ataques de DDoS contra as empresas alvo. Algumas das informações foram encontradas nos relatórios da Xlab, da Akamai e em publicações realizadas pelo usuário “Fox_threatintel” no X (antigo Twitter). No relatório da Xlab, observamos uma lista de domínios da OpenNic utilizados pela botnet. Nosso time desenvolveu uma ferramenta que possibilitou o rastreio das conexões realizadas através destes domínios, o que nos levou a identificar conexões com nove servidores C2 relacionados aos ataques contra empresas brasileiras.
[1] – Classificamos como “cluster” um grupo de servidores controlados por um único adversário (um grupo ou um indivíduo), que ataca uma mesma vítima em um curto período de tempo. Dessa forma, atribuímos que o cluster com a maior quantidade de ataques e de endereços IP pertence ou está relacionado a botnet “Mirai TBOT”.
Dissecando a botnet TBOT
De acordo com o relatório da XLab, a TBOT retém grande parte do código original da Mirai e visa principalmente roteadores e DVRs (Digital Video Recorders) em países como China, Venezuela, Brasil, Índia, Coreia do Sul e Japão. Durante o período em que analisamos a ameaça, identificamos a exploração de pelo menos 32 vulnerabilidades, incluindo dois zero-days.
A botnet registra mais de 30 mil endereços IP de bots diariamente, possuindo mais de 100 grupos de bots, que são conjuntos ou categorias de dispositivos IoT que operam de forma independente e possuem diferentes métodos de infecção. Esses grupos se diferenciam pelas informações de agrupamento quando se conectam ao servidor C2.
O agrupamento visa identificar e organizar os dispositivos infectados, possibilitando a realização de ataques personalizados, melhoria na gestão da botnet e facilidade na exploração de vulnerabilidades específicas nos dispositivos infectados.
Táticas, Técnicas e Procedimentos
Propagação
O método de propagação da botnet “Mirai TBOT” pode variar de acordo com o operador da ameaça, seja pelo uso de senhas fracas ou senhas padrão em serviços Telnet (como foi observado no grupo “selfrep“) ou pela exploração de vulnerabilidades, conforme foi relatado pela XLab, sendo elas:
| Vulnerabilidade | Dispositivo/Aplicação |
| CNVD-2022-91376 | BLINK Router |
| CVE-2014-8361 | Realtek SDK Miniigd SOAP |
| CVE-2014-9118 | Zhone Technologies Znid GPON |
| CVE-2015-2051 | D-Link DIR-645 |
| CVE-2016-10372 | Eir D1000 |
| CVE-2016-20016 | MV POWER CCTV DVR |
| CVE-2017-17215 | Huawei HG532 Router |
| CVE-2017-5259 | Cambium Networks cnPilot |
| CVE-2018-14558 | Tenda AC7, AC9, AC10 |
| CVE-2019-19356 | Netis WF2419 |
| CVE-2020-25499 | Totolink TOTOLINK A3002RU Router |
| CVE-2020-8515 | DrayTek Vigor2960, Vigor3900, Vigor300B Router |
| CVE-2020-8949 | Gocloud Router |
| CVE-2020-9054 | ZyXEL NAS |
| CVE-2021-22205 | GitLab |
| CVE-2013-3307 | Linksys X3000 Router |
| CVE-2021-28151 | Hongdian H8922 Router |
| CVE-2021-35394 | Realtek AP-Router SDK |
| CVE-2022-30525 | Zyxel Firewall |
| CVE-2023-26801 | LB-LINK BL-AC1900_2.0 v1.0.1, LB-LINK BL-WR9000 v2.4.9, LB-LINK BL-X26 v1.2.5, LB-LINK BL-LTE300 |
| CVE-2018-16752 | Linknet LW-N605R Router |
| CVE-2017-18368 | yxel P660HN-T1A Router |
| CVE-2018-10561 | Dasan GPON home routers |
| LILIN_DVR_RCE | LILIN DVR |
| Linksys_Router_unblock_RCE | Linksys E-series Router |
| OptiLink_ONT1GEW_GPON_Router_RCE | OptiLink ONT1GEW GPON |
| TVT_OEM_API_RCE | TVT DVR |
| YARN_API_RCE | Haddop Yarn API |
| DVR_HVR_RCE | DVRs Hitron |
| CVE-2023-47565 | QNAP VioStor |
Tipos de ataque
O malware “Mirai” é conhecido por implementar diferentes tipos de ataque, com suas variantes, modificando ou introduzindo novos métodos. A partir da análise de um código-fonte vazado em um grupo do Telegram, identificamos os tipos de ataque implementados pela “Mirai TBOT”, sendo eles:
| Ataque | Descrição |
| vse | Valve Source Engine Specific Flood: Um ataque específico voltado para servidores de jogos que utilizam o Valve Source Engine, sobrecarregando-os com pacotes de dados. |
| std | STD Flood: Um tipo de ataque de negação de serviço (DoS) padrão que inunda o alvo com pacotes de dados para interromper o serviço. |
| tcpfake | Fake TCP Flood: Envia pacotes TCP falsificados para o alvo, simulando uma conexão TCP para sobrecarregar o servidor. |
| udpplain | UDP Flood with Less Options: Um ataque que envia pacotes UDP ao alvo sem muitas opções de configuração, simplesmente visando a saturação da largura de banda. |
| udpbypass | UDP Flood with Less Options: Semelhante ao “udpplain”, envia pacotes UDP com menos opções de configuração para contornar algumas proteções. |
| syn | TCP SYN Flood: Envia múltiplos pacotes SYN para o alvo, tentando iniciar conexões TCP, mas sem completar o processo, sobrecarregando a capacidade de lidar com novas conexões. |
| ack | TCP ACK Flood: Envia pacotes ACK repetidamente para o alvo, sobrecarregando a capacidade de processamento de pacotes ACK. |
| ssh | SSH Socket Flood: Envia múltiplas solicitações de conexão SSH ao alvo, sobrecarregando o serviço SSH. |
| socket | TCP Socket Flood: Cria múltiplas conexões TCP sockets, esgotando os recursos disponíveis do servidor. |
| tcplegit | Legitimate TCP Flood: Realiza um ataque TCP que simula conexões legítimas para dificultar a detecção do ataque. |
| tcpbypass | TCP Bypass Socket Flood: Um ataque que tenta contornar as medidas de segurança usando conexões TCP sockets. |
| greeth | GRE ETH Flood: Inunda o alvo com pacotes GRE encapsulados sobre Ethernet, sobrecarregando a rede. |
| greip | GRE IP Flood: Envia pacotes GRE encapsulados sobre IP, visando sobrecarregar o processamento do tráfego IP. |
| icmp | ICMP Echo Flood: Conhecido como ataque Ping Flood, envia múltiplas requisições ICMP Echo (ping) ao alvo para sobrecarregar o servidor com respostas ping. |
As versões atuais da “Mirai TBOT” não necessariamente utilizam os mesmos ataques identificados em versões anteriores.
Domínios de C2
No início da execução do malware, o binário malicioso decifra uma lista de domínios que são usados na conexão do dispositivo infectado com o servidor C2 da botnet. Estes domínios são registrados na OpenNic e não podem ser resolvidos por meio de servidores DNS tradicionais (gerenciados pela ICANN). Isso dificulta pedidos de takedown e ações judiciais que possam ser realizadas contra a infraestrutura da botnet.
# nslookup infectedchink.pirate 162.xxx.xxx.47
Server: 162.xxx.xxx.47
Address: 162.xxx.xxx.47#53
Name: infectedchink.pirate
Address: 204.xxx.xxx.103
Name: infectedchink.pirate
Address: 204.xxx.xxx.5
Name: infectedchink.pirate
Address: 5.xxx.xxx.140
Name: infectedchink.pirate
Address: 5.xxx.xxx.61
Name: infectedchink.pirate
Address: 204.xxx.xxx.63
Name: infectedchink.pirate
Address: 204.xxx.xxx.223
Name: infectedchink.pirate
Address: 5.xxx.xxx.60
Name: infectedchink.pirate
Address: 204.xxx.xxx.101
Name: infectedchink.pirate
Address: 5.xxx.xxx.189
Name: infectedchink.pirate
Address: 5.xxx.xxx.130
Name: infectedchink.pirate
Address: 5.xxx.xxx.59
Consulta a domínio de C2 da botnet usando servidores da OpenNic. Fonte: Tempest
nslookup infectedchink.pirate 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can’t find infectedchink.pirate: NXDOMAIN
Consulta usando servidores de DNS da Google. Fonte: Tempest
O dispositivo infectado obtém a lista atualizada de servidores C2 da botnet, a partir de consultas a servidores da OpenNic para resolver os domínios — técnica similar a DeadDrop Resolver, comumente usada por infostealers e trojans. Nosso time analisou diversas amostras da ameaça, identificando mais de 150 domínios relacionados a TBOT, que foram usados para monitorar diariamente novos endereços IP usados como um “painel de controle” pela botnet.
Sinkhole
Dentre os domínios de C2 identificados pela Tempest, pelo menos 19 não estavam mais sendo registrados na OpenNic. Com isso, nosso time de especialistas viu uma oportunidade de registrar esses domínios de modo a aumentar nossa visibilidade sobre os dispositivos infectados pela TBOT.
Durante um período de aproximadamente 15 dias, monitoramos o comportamento dos dispositivos que tentaram se conectar ao nosso servidor de análise e, até o momento, registramos mais de 200 tentativas com origem em dispositivos localizados em diversos países. Os dispositivos que tentaram conexão estavam relacionados a 8 grupos de bots distintos, com mais de 60% pertencendo ao grupo “selfrep”. Boa parte deles correspondem a DVRs e roteadores, segundo dados do Shodan e do Censys e estão localizados em países como Taiwan (71 endereços IP), Estados Unidos (39), Coreia do Sul (15), Brasil (14) e Japão (12).
Essa distribuição revela que os alvos da ameaça se concentram principalmente na Ásia e nas Américas, com menor presença na Europa e em outras regiões. Acreditamos que isto esteja relacionado aos métodos de propagação da TBOT, como o abuso de senhas padrão usadas por provedores de internet nestas localidades.
Canal do Telegram
Ao longo das investigações, nosso time identificou um canal no Telegram relacionado ao suposto administrador da botnet TBOT.
O canal foi criado em 12 de agosto de 2022 e possuía apenas duas mensagens. A primeira delas se refere aos valores do serviço de aluguel da botnet que são oferecidos em um plano diário, semanal ou mensal, que varia de $100 até $2.000. A segunda mensagem exibe um histórico de ataques por usuário, de modo a determinar aqueles que mais utilizaram o serviço.
Suposta venda da botnet e Telegram
Em julho deste ano (2024), nosso time identificou mensagens não usuais no canal do Telegram da botnet, anunciando que o código-fonte, exploits e tal canal estariam à venda, junto de fotos de uma conversa do Discord e um suposto leak de uma técnica desenvolvida e utilizada pelo líder de outra botnet, conhecida como Meris.
No mesmo dia, identificamos uma mensagem no canal de Telegram da Meris botnet alegando que o administrador da TBOT havia vendido a botnet e sua conta do Telegram para dois scammers, mas sem divulgar oficialmente. Eles então entraram em contato com os líderes da Meris pedindo ajuda financeira, se passando pelo antigo administrador.
Acreditando se tratar do administrador da TBOT, os líderes da Meris concordaram em contribuir financeiramente com o pedido dos scammers, além de contribuir em ataques de DDoS em alvos aos quais havia sido requisitado, acordando que eles receberiam parte do dinheiro de volta como uma “comissão”. Eventualmente, os administradores da Meris descobriram que estavam sendo enganados e expuseram os dois usuários por trás da compra.
Contudo, até o momento da publicação deste artigo, com a quantidade limitada de informações e fontes sobre o ocorrido, não é possível chegar a uma conclusão sobre a veracidade dos eventos acima. Adicionalmente, as mensagens no canal da TBOT mencionadas não estão mais disponíveis e a botnet permanece online.
Mitigações, detecção e monitoramento
Como forma de proteção, nosso time recomenda manter todos os dispositivos IoT atualizados, garantir que esses dispositivos não estejam publicamente expostos e evitar o uso de senhas padrão, considerando os métodos de propagação mencionados neste artigo. Além disso, é importante monitorar o tráfego de rede para identificar qualquer tráfego incomum, sobretudo aqueles relacionados aos endereços IP de servidores C2 da ameaça.
Os ataques e os novos servidores C2 identificados em nosso monitoramento podem ser obtidos em tempo real através do Tempest Intel Feeds.
Considerações finais
De acordo com os comentários dos analistas que conduziram a investigação, com as novas informações sobre o comportamento da botnet TBOT e com o que já foi discutido neste artigo, podemos concluir que a ameaça se classifica como um DDoS-as-a-Service. Esse tipo de serviço geralmente é obtido em plataformas que oferecem ataques sob demanda. Neste caso, através de serviços de aluguel de botnets, como foi o caso do digitalstress[.]su, marketplace que oferecia estes serviços e que recentemente foi derrubado pela NCA (National Crime Agency).
Adversários recorrem a este recurso para extorquir empresas em ataques de Double Extortion, para competição desleal ou para prejudicar a reputação de um alvo, por exemplo. Também há casos relacionados a operações de hacktivismo e ransomware, como o ex-afiliado da operação de ransomware LockBit: Bassterlord, o qual foi observado usando e recomendando o serviço stresse[.]net.
Até o momento da publicação deste artigo, o adversário por trás da administração da botnet TBOT, não havia sido identificado e, consequentemente, não foi possível determinar a real motivação dos recentes ataques. Contudo, é possível que o atacante esteja agindo por motivações financeiras ou ideológicas, sem excluir a possibilidade de competição desleal ou extorsão.
Referências
AKAMAI SIRT. InfectedSlurs Botnet Spreads Mirai via Zero-Days. Akamai, 2023. Disponível em: <https://www.akamai.com/blog/security-research/new-rce-botnet-spreads-mirai-via-zero-days>. Acesso em 22 de jul. 2024.
FITZGERALD, Nick. Throwback Thursday: What DDoS it all Mean?. Virus Bulletin, 2000. Disponível em: <https://www.virusbulletin.com/virusbulletin/2015/11/throwback-thursday-what-ddos-it-all-mean-march-2000>. Acesso em 22 de jul. 2024.
GANTI, Vivek; YOACHIMIK, Omer. A Brief History of the Meris Botnet. Cloudflare, 2021. Disponível em: <https://blog.cloudflare.com/meris-botnet/>. Acesso em 24 de jul. 2024.
GUSSON, Rafael Soares. O que é DoS? Como se defender?. Tempest Security Intelligence, 2024. Disponível em: <https://sidechannel.blog/o-que-e-dos-como-se-defender/>. Acesso em 22 de jul. 2024.
HAO, Wang; ACEY9; ALEX.TURING. Mirai.TBOT Uncovered: Over 100 Groups and 30,000+ Infected Hosts in a big IoT Botnet. XLabs, 2024. Disponível em: <https://blog.xlab.qianxin.com/mirai-tbot-en/#overview>. Acesso em 21 de jul. 2024.
TEMPLE-RASTON, Dina; JARVIS, Will. The Hacker Bassterlord in his own words: Portrait of an access broker as a young man. The Record, 2023. Disponível em: <https://therecord.media/bassterlord-interview-hacker-initial-access-broker>. Acesso em 24 de jul. 2024.
