Malware mira Android Debug Bridge na porta 5555, mede largura de banda das vítimas e usa dispositivos Android e IoT para tráfego DDoS sob comando de painel remoto.
| Componente | Botnet xlabs_v1, derivada de Mirai, com APK Android boot.apk e builds para ARM, MIPS, x86-64 e ARC. |
| Vetor | Comprometimento de dispositivos com Android Debug Bridge exposto na porta TCP 5555, com execução por comandos via shell e entrega em /data/local/tmp. |
| Impacto | Alistamento de Android TVs, set-top boxes, smart TVs, roteadores residenciais e outros equipamentos IoT em ataques DDoS com 21 variantes de flood em TCP, UDP e protocolos raw. |
| Prioridade | Remover ADB da exposição à internet, bloquear 5555/TCP na borda, revisar dispositivos Android embarcados e procurar execução temporária de binários em /data/local/tmp. |
| Artefatos | xlabs_v1, boot.apk, xlabslover[.]lol, 176.65.139[.]44, 176.65.139[.]42, 103.177.110[.]202, /data/local/tmp, 5555/TCP. |
| IoCs | Servidor com diretório aberto em 176.65.139[.]44, painel de comando xlabslover[.]lol, host com toolkit VLTRig Monero em 176.65.139[.]42 e servidor remoto 103.177.110[.]202 associado a outro botnet DDoS observado em Jenkins. |
A botnet xlabs_v1 é uma variante derivada de Mirai voltada ao comprometimento de dispositivos IoT e Android embarcado que mantêm Android Debug Bridge acessível pela internet. O alvo operacional é claro: equipamentos com ADB exposto em 5555/TCP, incluindo Android TV boxes, set-top boxes, smart TVs, roteadores residenciais e hardware IoT baseado em ARM. A presença de um APK Android chamado boot.apk e de builds para ARM, MIPS, x86-64 e ARC indica uma campanha preparada para múltiplas arquiteturas, não apenas para um único modelo de dispositivo. O malware recebe comandos de um painel remoto identificado como xlabslover[.]lol e transforma os equipamentos comprometidos em nós de geração de tráfego para ataques distribuídos de negação de serviço.
A capacidade DDoS inclui 21 variantes de flood distribuídas entre TCP, UDP e protocolos raw, com formatos que imitam ou exploram padrões de tráfego ligados a RakNet e OpenVPN sobre UDP. Esse desenho aponta para abuso contra serviços de jogos, especialmente servidores de Minecraft e hospedagens de jogos expostas a tráfego volumétrico ou sem mitigação especializada. O operador também implementou uma rotina de medição de largura de banda que abre 8.192 conexões TCP paralelas contra o servidor Speedtest geograficamente mais próximo, mantém saturação por 10 segundos e envia ao painel a taxa medida em Mbps. O objetivo prático é classificar cada vítima por capacidade de tráfego, o que permite vender ou alocar bots conforme largura de banda disponível.
O malware não apresenta persistência tradicional no dispositivo após a fase de perfilamento de banda. Ele não grava componentes em locais persistentes, não altera scripts de inicialização, não cria unidades systemd e não registra tarefas em cron. Depois de reportar a largura de banda, o processo encerra, exigindo nova infecção pelo mesmo canal ADB para uso posterior. Essa escolha reduz alguns indicadores persistentes no sistema de arquivos, mas mantém o risco operacional quando ADB permanece exposto. Em redes com dispositivos Android embarcados, a ausência de persistência não deve ser interpretada como baixo impacto: basta a porta 5555/TCP continuar acessível para que o operador reinfecte o equipamento e use a conectividade residencial ou corporativa em ataques sob demanda.
O fluxo de comprometimento começa com a descoberta de dispositivos acessíveis pela internet que executam Android Debug Bridge sem controle adequado. Em muitos equipamentos Android embarcados, ADB é usado para depuração, manutenção ou instalação de aplicativos, mas não deve ficar exposto em interfaces públicas. Quando a porta 5555/TCP está aberta e aceita comandos, o atacante consegue interagir com o shell do dispositivo e colar comandos para baixar ou executar payloads. No caso de xlabs_v1, a entrega observada envolve comandos via ADB shell para posicionar o binário em /data/local/tmp, diretório comum para execução temporária em Android. Essa localização favorece execução rápida sem depender de instalação persistente ou modificação profunda do firmware.
A amostra ARMv7 foi descrita como estaticamente vinculada, característica que aumenta a chance de execução em firmwares Android reduzidos, sem bibliotecas completas de usuário. A abordagem é compatível com dispositivos de consumo que usam imagens enxutas, pouca instrumentação de segurança e ciclos irregulares de atualização. Após a execução, o bot comunica-se com o painel do operador e pode receber comandos para disparar tráfego. As variantes de flood cobrem diferentes superfícies de rede: TCP para conexões e estados, UDP para tráfego sem estabelecimento e protocolos raw para pacotes mais flexíveis. As formas voltadas a RakNet e OpenVPN-shaped UDP indicam tentativa de contornar proteções simples ou filtros genéricos, principalmente em provedores de hospedagem de jogos e ambientes que aplicam mitigação limitada.
A rotina de perfilamento de banda é um componente central da operação. Ao abrir 8.192 sockets TCP contra um servidor Speedtest próximo e saturar a transferência por 10 segundos, o malware obtém uma estimativa de capacidade real do enlace usado pelo dispositivo. Em vez de apenas contar bots, o operador passa a ter uma métrica de throughput por vítima, o que melhora a seleção de nós para ataques volumétricos. O comportamento também gera sinais de rede distintos: rajadas curtas, paralelismo muito alto de conexões TCP e tráfego concentrado para infraestrutura de medição de velocidade. Como o bot encerra após enviar a taxa em Mbps, uma análise baseada apenas em processos residentes pode perder a atividade se o endpoint for examinado tardiamente.
O subsistema de eliminação de concorrentes reforça o objetivo de monopolizar a capacidade de upload do equipamento. Variantes Mirai historicamente encerram processos de outros bots, bloqueiam portas usadas por competidores ou removem artefatos rivais para preservar controle sobre o dispositivo. Em xlabs_v1, o comportamento é orientado a liberar largura de banda para o próprio operador, reduzindo ruído de outras infecções e aumentando previsibilidade durante ataques DDoS. A atribuição permanece limitada: um identificador associado a Tadashi aparece em string criptografada com ChaCha20 nos builds, mas esse tipo de marcador não comprova identidade, localização, filiação ou controle exclusivo da infraestrutura.
A superfície mais exposta é formada por dispositivos Android e IoT com ADB habilitado em interfaces acessíveis pela internet. Isso inclui Android TV boxes vendidos com configurações inseguras, set-top boxes reaproveitados, smart TVs com modo de depuração ativo, firmwares customizados e roteadores residenciais com componentes Linux ou Android embarcado. O risco aumenta quando o equipamento está atrás de redirecionamento de porta, conectado diretamente ao modem do provedor ou publicado por regras permissivas de firewall. Em ambientes domésticos, pequenos escritórios, provedores regionais e redes de hospedagem de jogos, esses equipamentos podem passar anos sem revisão de configuração, criando estoque estável de alvos reinfectáveis.
A campanha também demonstra interesse por arquiteturas além de Android puro. Builds para MIPS, x86-64 e ARC ampliam a cobertura para roteadores, appliances pequenos, dispositivos industriais leves e hardwares IoT que compartilham o padrão de exposição indevida. Embora o vetor destacado seja ADB, a preparação multi-arquitetura indica que o operador espera encontrar ambientes heterogêneos e maximizar reaproveitamento de payloads. A presença de um diretório aberto em 176.65.139[.]44 e de um painel remoto em xlabslover[.]lol sugere operação com infraestrutura simples, suficiente para hospedar payloads, distribuir comandos e classificar vítimas por banda.
Outro elemento de atenção é a coexistência de infraestrutura maliciosa próxima a um toolkit VLTRig de mineração de Monero em 176.65.139[.]42. Não há confirmação de que a mineração e a botnet DDoS sejam controladas pelo mesmo ator, mas a proximidade operacional justifica monitoramento de tráfego e correlação por janela temporal, ASN, hospedagem e padrões de acesso. Separadamente, uma instância Jenkins intencionalmente mal configurada em ambiente de honeypot foi alvo de implantação de outro botnet DDoS baixado de 103.177.110[.]202, com tentativa de evasão. Esse caso reforça o mesmo padrão de abuso: serviços administrativos expostos, credenciais ou configurações fracas e execução remota de binários para transformar infraestrutura em capacidade de ataque.
- Dispositivos com Android Debug Bridge acessível em
5555/TCPa partir da internet. - Android TV boxes, set-top boxes, smart TVs, roteadores residenciais e equipamentos IoT com firmware enxuto.
- Sistemas em ARM, MIPS, x86-64 e ARC capazes de executar builds compatíveis do malware.
- Servidores de jogos e Minecraft como alvos prováveis dos floods DDoS gerados pela botnet.
A investigação deve começar pela borda de rede e por inventário de ativos. Procure qualquer exposição pública de 5555/TCP, inclusive em endereços residenciais, filiais, redes de laboratório, Wi-Fi de visitantes, NATs de provedores e ambientes usados por equipes de suporte. Em logs de firewall, roteadores e sensores de rede, a presença de conexões entrantes para ADB a partir de endereços desconhecidos deve ser tratada como incidente, não apenas como varredura. Em dispositivos Android acessíveis, verifique histórico de comandos, arquivos recentes em /data/local/tmp, execução de binários não reconhecidos, APKs inesperados como boot.apk e conexões de saída para domínios ou IPs associados ao painel.
A fase de medição de banda oferece sinais particularmente úteis para detecção. Um dispositivo IoT raramente abre milhares de sockets TCP paralelos para Speedtest e sustenta saturação por 10 segundos. Esse padrão pode ser observado em NetFlow, registros de proxy, telemetria de roteadores, soluções EDR para Android corporativo ou sensores posicionados na saída da rede. Como a rotina encerra após o reporte, eventos de curta duração são importantes: aumentos abruptos de conexões, picos de upload, múltiplas sessões simultâneas e resolução de servidores Speedtest em janela estreita. A caça deve correlacionar esses sinais com exposição prévia de ADB e com qualquer execução temporária no dispositivo.
Durante ataques ativos, a telemetria muda de perfil. Em vez de conexões para Speedtest, o equipamento passa a emitir floods TCP, UDP ou raw em direção a vítimas externas, frequentemente com foco em portas e protocolos associados a jogos. Operadores de SOC devem diferenciar esse comportamento de uso legítimo de streaming ou jogos domésticos: o volume de pacotes, a regularidade, a diversidade de destinos e a ausência de sessão de usuário real ajudam na classificação. Também é útil observar tentativas do malware de encerrar processos concorrentes, embora essa visibilidade dependa do nível de acesso ao dispositivo. Quando não houver agente no endpoint, a rede se torna a principal fonte de evidência.
Para ambientes com Jenkins, a atenção deve incluir builds inesperados, downloads de binários por jobs não autorizados, execução de comandos shell, tráfego para 103.177.110[.]202 e mudanças que tentem reduzir visibilidade. Embora o caso Jenkins citado seja distinto de xlabs_v1, ambos exploram a mesma fragilidade operacional: interfaces administrativas expostas ou mal configuradas que permitem transformar ativos legítimos em nós de botnet. A investigação deve registrar horários, endereços de origem, comandos executados, arquivos transferidos, arquitetura do binário e destino do tráfego gerado, preservando evidência antes de reiniciar ou restaurar o equipamento.
- Exposição de
5555/TCPem varreduras externas ou inventário de portas públicas. - Arquivos ou execução temporária em
/data/local/tmp, incluindoboot.apkou binários sem origem administrativa. - Conexões para
xlabslover[.]lol,176.65.139[.]44,176.65.139[.]42ou103.177.110[.]202. - Rajadas com 8.192 conexões TCP paralelas e saturação curta para servidores Speedtest próximos.
- Tráfego UDP, TCP ou raw em volume anormal, especialmente com padrões ligados a servidores de jogos, Minecraft,
RakNetou OpenVPN.
A primeira ação defensiva é eliminar a pré-condição de exploração. ADB não deve ficar acessível pela internet. Desative Android Debug Bridge em dispositivos que não precisam de depuração, restrinja 5555/TCP a redes administrativas isoladas e aplique bloqueio na borda para qualquer tráfego externo destinado a essa porta. Quando o recurso for indispensável, use túnel autenticado, rede privada, lista de controle de acesso e registro de sessões administrativas. Em dispositivos de consumo, revise configurações de fábrica, firmware de terceiros e imagens fornecidas por integradores, pois alguns equipamentos chegam ao ambiente com depuração habilitada ou com serviços reativados após atualização.
A contenção de dispositivos suspeitos deve considerar que a botnet pode não persistir após a fase de medição, mas a reinfecção continua possível. Isole o equipamento da internet, colete logs e artefatos voláteis quando possível, verifique /data/local/tmp, liste processos ativos, revise conexões abertas e remova arquivos desconhecidos. Em seguida, reinicie somente após preservar o mínimo de evidência necessária para entender o vetor. Atualize o firmware, restaure a configuração segura, desabilite serviços administrativos desnecessários e altere credenciais locais. Se o dispositivo não permite controle adequado de ADB, segmentação ou atualização, a substituição deve ser considerada, especialmente em redes que hospedam serviços sensíveis.
Na rede, aplique detecções para exposição e abuso. Bloqueie saída para IoCs conhecidos quando compatível com a operação, mas não dependa apenas de lista de indicadores, porque domínios e servidores podem mudar. Crie regras comportamentais para milhares de conexões TCP paralelas em curta janela, picos de upload para Speedtest partindo de IoT, execução de floods UDP para portas de jogos e comunicação de dispositivos de TV ou set-top box com infraestrutura incomum. Provedores, operadores de jogos e empresas com muitos dispositivos embarcados devem combinar filtragem de borda, rate limiting, segmentação por VLAN e monitoramento de egress para reduzir a chance de seus próprios ativos participarem de DDoS contra terceiros.
Para Jenkins e outros serviços administrativos, a mitigação segue o mesmo princípio: remover exposição indevida, exigir autenticação forte, atualizar plugins e núcleo da aplicação, restringir execução de comandos, revisar jobs e proteger credenciais usadas em pipelines. Qualquer ambiente que permita baixar e executar binários a partir da internet pode virar ponto de implantação de botnet. Após correção, valide com varredura externa independente, confirme que 5555/TCP e painéis administrativos não estão publicados, revise logs históricos para identificar possível uso anterior e mantenha alertas para retorno do serviço exposto. A eficácia da resposta depende menos de remover um binário específico e mais de fechar o caminho de execução que permite reinfecção.
- Desativar
ADBem dispositivos de produção e bloquear acesso externo a5555/TCP. - Isolar equipamentos suspeitos, revisar
/data/local/tmp, remover artefatos desconhecidos e atualizar firmware. - Criar alertas para picos de conexões TCP paralelas, tráfego Speedtest anômalo e floods UDP/TCP/raw vindos de IoT.
- Bloquear ou monitorar comunicação com
xlabslover[.]lol,176.65.139[.]44,176.65.139[.]42e103.177.110[.]202conforme política de rede. - Revisar Jenkins e serviços administrativos expostos, com autenticação forte, restrição de comandos e validação externa após mudanças.
0 Comentários