Categoria: Ataques

Vol. 1 No. 20251121-1039 (2025)

WhatsApp: a nova porta de entrada

Yuri Augusto | yuri@cylo.com.br | 21/11/2025

Nos últimos dias, foi identificado novamente um ataque veiculado via WhatsApp Web envolvendo o envio de um arquivo VBS (Visual Basic Script) altamente ofuscado. A ofuscação é feita por meio de códigos ASCII convertidos com a função Chr() e concatenados em tempo de execução, o que dificulta a análise estática do arquivo.

Após a desofuscação do script, foi possível recuperar os endereços de rede utilizados e toda a cadeia de ações executadas. O VBS cria pastas temporárias em C:\ (como C:\temp), gera arquivos .bat e realiza o download de múltiplos componentes, incluindo Python em modo “embedded”, ChromeDriver e um arquivo MSI. Esses artefatos são então utilizados para montar um ambiente capaz de executar scripts adicionais, automatizar o navegador e, potencialmente, interagir com sessões do WhatsApp Web ou outras aplicações sensíveis.

Um ponto relevante é que o arquivo VBS foi prontamente detectado pela solução XDR, pois o WhatsApp Web salva o anexo localmente em uma pasta temporária antes mesmo de o usuário clicar em “baixar” ou abrir o arquivo. Isso permite que mecanismos de segurança baseados em monitoramento de disco interceptem o artefato ainda no início da cadeia de ataque.

Principais IOCs:
Domínio: 193[.]36[.]109[.]208[.]host[.]secureserver[.]net
IP: 208[.]109[.]36[.]193

Domínio: empautlipa[.]com
IPs: 172[.]67[.]155[.]220, 104[.]21[.]50[.]29

Vol. 1 No. 20251120-1031 (2025)

A Botnet Aisuru e o Ataque Recorde à Microsoft: O Papel Estratégico do DNS

Kim Morgan | kim@acmesecurity.org | 20/11/2025

Kim Morgan (kim@acmesecurity.org) & Adriano Cansian (adriano.cansian@unesp.br)

Em 17 de novembro de 2025, a Microsoft anunciou ter mitigado o maior ataque de negação de serviço distribuído (DDoS) já registrado em sua nuvem [1]. O ataque, que atingiu um pico de 15,72 terabits por segundo (Tbps), foi direcionado a um único endpoint da plataforma Azure na Austrália no dia 24 de outubro de 2025. A operação massiva, que utilizou mais de 500.000 endereços IP comprometidos para gerar um dilúvio de tráfego UDP, foi atribuída à Aisuru, uma botnet que exemplifica a sofisticação das ameaças modernas e destaca o papel central e estratégico do Sistema de Nomes de Domínio (DNS) em seu funcionamento.

Tendências de Ataque e distribuição geográfica de vítimas de ataques DDoS da Aisuru
Figura 1: Tendências de Ataque e distribuição geográfica de vítimas de ataques DDoS da Aisuru. Fonte: (WANG et al., 2025)

Ascensão da Aisuru: De Botnet Comum a Ameaça Global

A Aisuru, inicialmente uma botnet de escala relativamente comum, teve uma ascensão meteórica em abril de 2025. O ponto de virada ocorreu quando os operadores da rede comprometeram um servidor de atualização de firmware da fabricante de roteadores Totolink. Ao modificar a URL de atualização, eles passaram a distribuir um script malicioso para qualquer dispositivo que buscasse o firmware oficial. Essa tática engenhosa resultou na infecção de milhares de roteadores, expandindo a botnet para mais de 100.000 dispositivos em um curto período e consolidando a Aisuru como uma das maiores redes de bots ativas atualmente, com uma contagem de nós estimada em 300.000 [2].

Para se propagar, a Aisuru explora uma gama diversificada de vulnerabilidades, desde falhas antigas até 0-days, demonstrando a capacidade de seus operadores de integrar rapidamente novos vetores de ataque. A tabela abaixo detalha algumas das vulnerabilidades notáveis exploradas pelo grupo.

Vulnerabilidades exploradas para o comprometimento de dispositivos utilizados pelo grupo da Aisuru
Figura 2: Vulnerabilidades exploradas para o comprometimento de dispositivos utilizados pelo grupo da Aisuru. Fonte: (WANG et al., 2025)

O DNS como Pilar da Operação

A infraestrutura de comando e controle (C2) da Aisuru depende criticamente do DNS. Para evitar a detecção e facilitar a rotação de seus servidores, a botnet utiliza registros de recurso TXT para comunicar os endereços IP dos servidores C2 aos dispositivos infectados. O malware consulta um domínio C2 e decodifica a informação contida no registro TXT para estabelecer a conexão. As técnicas de decodificação evoluíram, passando de uma combinação de base64 e ChaCha20 para base64 e XOR, numa tentativa contínua de evadir a detecção por ferramentas de segurança [2].

Hosts consultados pelos dispositivos comprometidos da botnet
Figura 3: Hosts consultados pelos dispositivos comprometidos da botnet. Fonte: (ALIENVAULT, 2025)

A escala da operação da Aisuru foi exposta de forma dramática em novembro de 2025. Após mudar o resolvedor DNS padrão de seus bots do serviço do Google (8.8.8.8) para o da Cloudflare (1.1.1.1), o volume massivo de consultas geradas fez com que dois de seus domínios de C2 alcançassem as posições de 1º e 3º lugar no ranking global de domínios mais consultados da Cloudflare [3].

O evento, embora tenha levado a Cloudflare a remover os domínios maliciosos de sua lista pública, revelou a imensa escala da botnet, superando em tráfego de DNS gigantes como Google e Apple por um breve período.

Domínios da botnet Aisuru redigidos no ranking global da Cloudflare
Figura 4: Domínios da botnet Aisuru redigidos no ranking global da Cloudflare. Fonte: (KREBS et al., 2025)

Monetização Além do DDoS

Embora seja conhecida por seus ataques DDoS de grande impacto, a Aisuru diversificou suas fontes de receita, operando também como um lucrativo serviço de proxy residencial. Os operadores da botnet alugam o acesso aos dispositivos infectados, permitindo que clientes pagantes roteiem seu tráfego de internet através dessas conexões residenciais.

Isso não apenas garante o anonimato do cliente, mas também faz com que o tráfego malicioso (como raspagem de conteúdo em larga escala, fraude de anúncios ou ataques de preenchimento de credenciais) pareça originar-se de um usuário legítimo, dificultando enormemente sua detecção e bloqueio [4].

Conclusão: A Defesa Começa no DNS

O caso da Aisuru é um poderoso lembrete de que o DNS, um dos protocolos fundamentais da internet, permanece como um pilar estratégico tanto para o funcionamento da rede quanto para as operações de cibercriminosos.

A capacidade de uma botnet de usar o DNS para comando e controle de forma resiliente e de expor sua escala através do volume de tráfego de consultas demonstra a criticidade deste vetor. Enquanto domínios maliciosos permanecerem ativos, a operação de ameaças como a Aisuru continuará.

A mitigação eficaz depende de uma defesa proativa do DNS, com o monitoramento e o bloqueio automático de domínios associados a atividades maliciosas, impedindo a comunicação e a propagação dessas redes em escala global.

Referências

[1] Whalen, S. “Defending the cloud: Azure neutralized a record-breaking 15 Tbps DDoS attack”. Azure Infrastructure Blog, Microsoft Tech Community, 17 Nov. 2025. Disponível em: `

[2] Wang, H., Alex.Turing, & Acey9. “The Most Powerful Ever? Inside the 11.5Tbps-Scale Mega Botnet AISURU”. 奇安信 XLab, 15 Set. 2025. Disponível em: `

[3] Krebs, B. “Cloudflare Scrubs Aisuru Botnet from Top Domains List”. Krebs on Security, 5 Nov. 2025. Disponível em: `

[4] Krebs, B. “Aisuru Botnet Shifts from DDoS to Residential Proxies”. Krebs on Security, 28 Out. 2025. Disponível em: `

[5] ALIENVAULT. “LevelBlue – Open Threat Exchange – Pulse 67ba293ff8ebb490de5f6761”. Disponível em: `

Vol. 1 No. 20251113-1013 (2025)

Cadeia de suprimentos monitorada?

João Fuzinelli | joao@cylo.com.br | 13/11/2025

Peguei um caso em que duas pessoas da equipe financeira receberam um e-mail que se passava pelo CEO da empresa. A mensagem autorizava um pagamento de R$ 28.900,00 pelos serviços prestados. A equipe rapidamente identificou que se tratava de uma fraude e reportou o incidente para a área de cibersegurança. Ainda bem!

O atacante criou uma conta @outlook.com utilizando o nome do CEO, tentando conferir legitimidade ao envio (ex.: abc.xyz@outlook.com).

Além disso, ele alterou o campo Display Name da mensagem para o nome completo do executivo e criou uma assinatura com o logo da empresa.

No corpo do e-mail, o fraudador enviava uma chave Pix para a realização do pagamento, sendo essa chave o próprio CNPJ da empresa recebedora.

Até aí tudo comum em um ataque de phishing…

Por curiosidade, busquei informações sobre a empresa fraudadora e, por meio do CNPJ, cheguei até o proprietário. A empresa estava localizada em Arapongas – PR.

Ao analisar o histórico profissional do dono da empresa, encontrei um dado relevante: em 2023, o fraudador havia trabalhado em uma empresa prestadora de serviços para a companhia que agora estava sendo alvo.

Como o ataque foi direcionado, com conhecimento dos e-mails e dos nomes específicos envolvidos no processo de pagamentos, é bem provável que o atacante tenha se apropriado de alguma base contendo dados dos clientes do seu emprego anterior e, agora, estivesse aplicando golpes.

Infelizmente, trata-se de mais um caso típico de falhas de controle em múltiplos processos. A superfície de risco só cresce quando a cadeia de suprimentos não é monitorada de ponta a ponta.

Vol. 1 No. 20251110-1004 (2025)

Novo Malware Bancário – “Herodotus”

João Paulo Gonsales | jgonsales@cylo.com.br | 10/11/2025

Recentemente tivemos uma rápida disseminação do malware “Sorvepotel”, e agora novamente, nos deparamos com a notícia que me deixou preocupado, noticia está sobre um novo malware bancário chamado “Herodotus” e que vem atacando muitos usuários Android.

O novo malware se utiliza como principal estratégica de propagação através de campanhas de phishing por SMS, onde usuários recebem links fraudulentos que levam a páginas maliciosas onde o malware é baixado e instalado no seu dispositivo mobile. Após instalado, o malware obtém permissões críticas do sistema e utilizando de táticas sofisticadas como sobreposição de tela para roubar credenciais e tornando as sessões legitimas, dificultando a ação dos antivírus tradicionais ou mesmo não detectando o comprometimento do dispositivo.

Precisamos ficar atentos e reforçar a vigilância no mundo digital e começar a nos precaver com medidas de segurança como, baixar aplicativos somente de lojas oficiais(apesar de não ser 100% a prova de falha, ainda é a opção mais segura), suspeitar de SMS com links e fontes desconhecidas, não validar informações pelo SMS, onde mensagens podem ser interceptadas e alteradas, utilizar se de aplicativos autenticadores como Google ou Microsoft Authenticator, não autorizar permissões críticas no seu dispositivos a aplicativos suspeitos .

Precisamos ficar constantemente atentos, pois a sofisticação dos atacantes está sempre um passo à frente. Segurança não é somente ferramental, mas sim um processo.

Mais informações nos links :

https://www[.]cybersecbrazil.com.br/post/novo-malware-para-android-imita-digita%C3%A7%C3%A3o-humana-para-evitar-detec%C3%A7%C3%A3o-e-roubar-dinheiro

https://www[.]cisoadvisor.com.br/novo-malware-bancario-ataca-usuarios-android/?utm_campaign=&utm_medium=email&utm_source=newsletter

Vol. 1 No. 20251022-1000 (2025)

Fique atento as configurações de BIOCs

Hector Carlos Frigo | hector@cylo.com.br | 22/10/2025

Recentemente, me deparei com um incidente gerado após a detecção de um BIOC, o qual possuía o seguinte título: “Windows LOLBIN executable connected to a rare external host”.

O incidente informava a detecção de uma conexão externa suspeita realizada por um processo nomeado como “sc.exe”. Isso me levou a pensar que o alerta estava fazendo referência ao software nativo e amplamente conhecido do Windows, responsável pelo gerenciamento de serviços, “Service Control” e que o mesmo estaria sendo utilizado para realizar conexões com servidores de “Command and Control“, uma vez que entendo não ser nada comum esse processo realizar conexões externas.

Bom… neste caso, a realidade era bem diferente. Ao aprofundar as investigações, identifiquei que o software nomeado como “sc.exe” e responsável por realizar a conexão externa nada tinha a ver com o processo nativo do Windows “Service Control”. Inclusive, era assinado por outro fabricante. Da mesma forma, realizei todas as verificações necessárias para me certificar de que a conexão detectada não apresentava qualquer risco para o ambiente.

Foi então que me veio a ideia: o fator que levou a essa detecção foi a existência de uma regra de BIOC configurada especificamente para detectar conexões realizadas por processos que possuem como fator de validação apenas “nomes conhecidos do sistema operacional Windows”. Porém, ao surgir um software de terceiros que possui o mesmo nome que um desses processos, a BIOC irá disparar sem qualquer validação prévia, aumentando a chance da geração de falsos positivos…

Ou seja, não seria mais prático e acertivo, adicionar também como um dos requisitos de validação para o disparo desta BIOC a verificação da “Assinatura Digital“? A fim de certificar que apenas processos do sistema Windows sejam responsáveis pela “Trigger” desta regra.

Vol. 1 No. 20251021-998 (2025)

Ataque ao time service chinês. Já pensou no impacto?

João Fuzinelli | joao@cylo.com.br | 21/10/2025

Acompanhando algumas notícias recentemente a China acusou a NSA de ter realizado um ataque ao serviço de tempo (National Time Service Center) responsável por manter e transmitir o horário de Pequim

Assim como alguns problemas geopolíticos recentes do Brasil com o Estados Unidos, em que surgiu rumores da possibilidade de bloquearem o serviço de GPS, o Time Service poderia ter causado um grande caos para os chineses, parando serviços como comunicação de rede e até sistemas financeiros.

O mais interessante é que tudo começou por um ataque de triangulação de celulares e em seguida o roubo de credenciais.

E várias vezes já pegamos de problemas de autenticação relacionados ao Active Directory em que a causa raiz era os relógios dessincronizados.

Reforço a atenção para um serviço negligenciado

Link da matéria:

hxxps[://]thehackernews[.]com/2025/10/mss-claims-nsa-used-42-cyber-tools-in[.]html?m=1