# T1496.002 - Bandwidth Hijacking ## Descrição **T1496.002 - Bandwidth Hijacking** é uma sub-técnica da família [[t1496-resource-hijacking|T1496 - Resource Hijacking]] onde adversários se apropriam da **largura de banda de rede** de sistemas comprometidos para fins não autorizados, sem o conhecimento ou consentimento do proprietário. Diferentemente do [[t1496-001-compute-hijacking|T1496.001 - Compute Hijacking]] (que foca em CPU/GPU), esta sub-técnica visa específicamente o recurso de conectividade - o pipe de rede da vítima. O sequestro de largura de banda pode ser explorado de três formas principais: **1. Botnets para DDoS:** Sistemas comprometidos são recrutados para compor redes de bots (botnets) que direcionam seus recursos de banda para ataques volumétricos de [[t1498-network-denial-of-service|Negação de Serviço de Rede (T1498)]]. A vítima, sem saber, torna-se co-autora involuntária de ataques a terceiros. Botnets como Mirai, Mēris e Mantis utilizaram dispositivos IoT e servidores comprometidos com largura de banda elevada para gerar tráfego de ataque na escala de terabits por segundo. **2. Proxyjacking:** Um modelo emergente e lucrativo onde o adversário vende o uso da conexão de internet da vítima para serviços de proxy residencial ou de datacenter (como Honeygain, IPRoyal Pawns, Peer2Profit). A conexão da vítima aparece como um nó legítimo em redes de proxy pagas, mascarando o tráfego real do comprador. O malware [[socks5systemz|Socks5Systemz]], descoberto em 2023, é um exemplo documentado de malware específicamente projetado para proxyjacking. **3. Varredura em Larga Escala (Internet-Wide Scanning):** Adversários usam a largura de banda de sistemas comprometidos para realizar varreduras massivas da internet (port scans, vulnerability scans) em busca de novas vítimas ou para coletar inteligência sobre alvos. Isso distribui o tráfego de reconhecimento por múltiplos IPs, dificultando a identificação da origem real. Esta técnica está na tática [[_impact|Impact]] porque causa degradação de performance de rede, aumento de custos de conectividade (especialmente em ambientes cloud onde bandwidth tem custo variável) e pode resultar em **dano reputacional severo** se o IP da vítima for associado a ataques ou atividades ilegais. --- ## Como Funciona O ciclo de vida de um ataque de Bandwidth Hijacking segue um padrão bem definido: **1. Comprometimento Inicial** O sistema da vítima é comprometido por qualquer vetor: exploit de vulnerabilidade, malware distribuído via phishing, supply chain attack, ou brute force de credenciais. Em ambientes cloud e containers, configurações incorretas (buckets S3 públicos, containers Docker sem autenticação, Kubernetes APIs expostas) são vetores frequentes. **2. Instalação do Agente de Hijacking** Após o comprometimento, o adversário instala um agente persistente que gerencia o uso da largura de banda. Este agente pode ser: - Um cliente de botnet que aguarda comandos do C2 (Command & Control) - Um daemon de proxy SOCKS4/SOCKS5 que aceita conexões de revendedores - Um scanner automatizado que executa varreduras contínuas conforme instruções do operador **3. Comúnicação com Infraestrutura C2** O agente se conecta periodicamente a servidores de comando e controle para receber instruções. Comúnicações C2 modernas usam protocolos encriptados (HTTPS, WebSockets, DNS-over-HTTPS) para evitar detecção por inspeção de tráfego. Técnicas de [[t1568-dynamic-resolution|Dynamic Resolution (T1568)]] como fast flux DNS são usadas para dificultar o bloqueio da infraestrutura C2. **4. Uso Ativo da Largura de Banda** Dependendo do objetivo: - **DDoS:** O agente recebe o alvo e a intensidade do ataque. Gera tráfego volumétrico (UDP floods, TCP SYN floods, HTTP floods) em direção ao alvo - **Proxyjacking:** O agente aceita conexões de clientes proxy e roteias o tráfego deles através da conexão da vítima - **Scanning:** O agente executa varreduras de portas e vulnerabilidades contra endereços IP designados **5. Evasão e Persistência** Para manter o acesso e evitar remoção, o agente usa técnicas de persistência como serviços do sistema, tarefas agendadas (cron, Task Scheduler), modificação de scripts de inicialização ou - em ambientes Linux - rootkits que escondem o processo. --- ## Attack Flow ```mermaid graph TB A[Comprometimento inicial do sistema] --> B[Instalação do agente de hijacking] B --> C[Estabelecimento de canal C2 encriptado] C --> D[Recebimento de instruções do operador] D --> E{Finalidade do hijacking} E --> F[Botnet para DDoS - T1498] E --> G[Proxyjacking - revenda de banda] E --> H[Internet scanning - reconhecimento] F --> I[Geração de tráfego volumétrico contra alvos] G --> J[Roteamento de tráfego de terceiros via IP da vítima] H --> K[Varredura massiva de IPs e portas] I --> L[Impacto direto] J --> L K --> L L --> M[Degradação de performance de rede] L --> N[Aumento de custos de conectividade cloud] L --> O[Dano reputacional - IP bloqueado em blacklists] L --> P[Responsabilidade legal por tráfego gerado] ``` --- ## Exemplos de Uso ### Mirai Botnet - IoT DDoS em Larga Escala O Mirai é o exemplo mais emblemático de bandwidth hijacking para DDoS. Em 2016, comprometeu centenas de milhares de dispositivos IoT (câmeras IP, roteadores domésticos, DVRs) com credenciais padrão e os usou para gerar ataques volumétricos recordes. O ataque contra a Dyn (provedor DNS) em outubro de 2016 atingiu 1.2 Tbps e derrubou serviços como Twitter, Reddit, Netflix e GitHub. Variantes do Mirai continuam ativas em 2025 e são rotineiramente usadas em ataques contra infraestrutura brasileira. ### Socks5Systemz - Proxyjacking em Escala Industrial Descoberto em 2023, o malware [[socks5systemz|Socks5Systemz]] comprometeu mais de 10.000 sistemas em todo o mundo para construir uma rede de proxy SOCKS5. A largura de banda das vítimas era vendida para clientes anônimos que precisavam de IPs "limpos" para atividades como scraping, bypass de geobloqueio e anonimização de operações maliciosas. A monetização via proxyjacking tornou-se uma alternativa ao cryptojacking, pois consome menos CPU (mais difícil de detectar) e gera receita recorrente. ### Botnets de Varredura Massiva Grupos APT e operadores de ransomware frequentemente usam botnets de sistemas comprometidos para realizar varreduras de internet em busca de novos alvos vulneráveis. O grupo TA505, por exemplo, utilizou sistemas comprometidos para varre IPs em busca de instâncias vulneráveis do Exchange, NetScaler e Fortinet antes de lançar campanhas de ransomware. ### Abuso de Ambientes Cloud e Containers Em ambientes cloud (AWS, GCP, Azure), bandwidth hijacking tem implicação financeira direta: transferências de dados saem do orçamento da vítima. Containers Docker mal configurados e clusters Kubernetes expostos são frequentemente comprometidos para montar proxies ou nós de botnet, com o custo sendo transferido para a conta cloud da organização vítima. --- ## Detecção ### Indicadores Comportamentais - Consumo anormalmente elevado de largura de banda de saída sem justificativa operacional - Conexões de rede de longa duração para IPs externos incomuns - Processos desconhecidos estabelecendo múltiplas conexões TCP/UDP simultâneas - Picos de tráfego em horários atípicos (madrugada, fins de semana) - Presença de processos escutando em portas de proxy (SOCKS: 1080, 4145; HTTP proxy: 8080, 3128) - IP da organização aparecendo em blacklists de DDoS ou spam - Faturas de cloud com custos de egress (transferência de dados) significativamente acima do normal ### Sigma Rule - Tráfego de Saída Excessivo ```yaml title: Excessive Outbound Network Traffic Indicating Bandwidth Hijacking status: experimental logsource: category: network_traffic product: zeek detection: selection: bytes_sent|gte: 1000000000 duration|lte: 3600 direction: 'outbound' filter_known_backups: dest_ip|cidr: - '10.0.0.0/8' - '172.16.0.0/12' - '192.168.0.0/16' condition: selection and not filter_known_backups level: high tags: - attack.impact - attack.t1496.002 falsepositives: - Backup para cloud programado - Transferências legítimas de grandes volumes de dados - CDN ou serviços de streaming legítimos ``` ### Sigma Rule - Processo Escutando em Porta de Proxy ```yaml title: Unknown Process Listening on SOCKS Proxy Port status: experimental logsource: category: network_connection product: windows detection: selection: DestinationPort: - 1080 - 4145 - 9050 Initiated: 'false' filter_known: Image|endswith: - '\tor.exe' - '\proxifier.exe' condition: selection and not filter_known level: high tags: - attack.impact - attack.t1496.002 - attack.t1090 ``` ### Fontes de Dados e Controles de Detecção - **NetFlow / IPFIX:** Análise de fluxos para identificar volumes anômalos e destinos incomuns - **DNS Logging:** Detecção de consultas para domínios C2 usando threat intelligence feeds - **EDR (Endpoint Detection and Response):** Identificação de processos com comportamento anômalo de rede - **Cloud Cost Monitoring:** Alertas em AWS Cost Explorer, Azure Cost Management para picos de egress - **Blacklist Monitoring:** Serviços como AbuseIPDB, Spamhaus, Shodan para monitorar reputação do IP - **Network Behavior Analytics:** Detecção baseada em anomalias usando ML (Darktrace, ExtraHop, Vectra) --- ## Mitigação Embora o MITRE ATT&CK não liste mitigações específicas para T1496.002, as seguintes práticas são recomendadas: | Controle | Descrição | |----------|-----------| | Monitoramento de largura de banda | Implementar baselines de uso de rede e alertas para desvios. Ferramentas como PRTG, Zabbix, Grafana com dados de NetFlow. | | Firewall de egress | Restringir conexões de saída apenas para destinos necessários. Bloquear portas associadas a proxies (1080, 4145, 9050) por padrão. | | Gestão de patches | Manter sistemas atualizados para evitar comprometimentos iniciais que levam ao hijacking. | | Segmentação de rede | Isolar sistemas críticos e de alta largura de banda em segmentos monitorados com controles de egress rigorosos. | | Monitoramento de reputação de IP | Subscrever a serviços que alertam quando IPs da organização aparecem em blacklists. | | Controles de acesso a containers | Autenticar APIs Docker e Kubernetes. Usar políticas de rede (NetworkPolicies) para limitar egress de pods. | | Cloud Security Posture Management (CSPM) | Detectar configurações incorretas em ambientes cloud que facilitam o comprometimento. | --- ## Contexto Brasil / LATAM O Brasil é particularmente relevante no contexto de Bandwidth Hijacking por múltiplos fatores: **Infraestrutura de Internet:** O Brasil possui uma das maiores infraestruturas de internet da América Latina, com operadoras de grande porte (Claro, Vivo, TIM, Oi) e milhões de conexões residenciais e corporativas. A grande quantidade de dispositivos IoT com credenciais padrão (câmeras IP, roteadores banda larga, DVRs) cria uma superfície de ataque enorme para recrutamento de botnets - o mesmo perfil que alimentou o Mirai. **Proxyjacking e Cibercrime:** Grupos de cibercrime brasileiros têm adotado o proxyjacking como fonte de renda complementar. A monetização é atraente: diferentemente de ransomware (alto risco, alta visibilidade), o proxyjacking opera silenciosamente por meses. Operações policiais brasileiras (como as conduzidas pela Polícia Federal em parceria com o FBI) têm identificado atores locais envolvidos em infraestrutura de proxy. **Botnets Regionais:** Variantes do Mirai continuamente atacam dispositivos IoT no Brasil. Pesquisas da Netscout e CERT.br identificam o Brasil consistentemente entre os países com maior número de dispositivos infectados em botnets ativos. Esses dispositivos são frequentemente utilizados para ataques DDoS contra alvos no próprio Brasil (bancos, provedores ISP, órgãos governamentais) e internacionalmente. **Custo Cloud:** Empresas brasileiras que migraram para cloud (AWS São Paulo, Azure Brasil Sul, Google Cloud São Paulo) enfrentam custos de egress específicos da região. Um ataque de bandwidth hijacking em um ambiente cloud can gerar custos de dezenas de milhares de reais em poucos dias, dependendo do volume de tráfego gerado. **ANPD e Incidentes:** Sob a [[lgpd|LGPD]], organizações têm obrigação de reportar incidentes que possam resultar em riscos aos titulares de dados. Se o bandwidth hijacking resultar em vazamento de informações (por exemplo, se tráfego da organização for interceptado pelo proxy malicioso), podem existir obrigações de notificação à ANPD. **Resposta a Incidentes:** O [[certbr|CERT.br]] (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil) mantém o honeypot SpamPots e o projeto AbuseHUB, que monitoram botnets e proxies maliciosos com IPs brasileiros. Organizações que detectam bandwidth hijacking devem reportar ao CERT.br para colaborar com a resposta nacional. --- ## Referências - [MITRE ATT&CK - T1496.002](https://attack.mitre.org/techniques/T1496/002) - [Netscout Threat Intelligence - Mirai Variants](https://www.netscout.com/blog/asert/mirai-is-still-a-major-threat) - [Socks5Systemz - Bitsight Research](https://www.bitsight.com/blog/socks5systemz-the-botnet-that-converts-infected-devices-into-proxy-servers) - [CERT.br - Atividade Maliciosa](https://www.cert.br/stats/) - [[t1496-resource-hijacking|T1496 - Resource Hijacking]] (técnica pai) - [[t1498-network-denial-of-service|T1498 - Network Denial of Service]] (técnica relacionada) - [[t1496-001-compute-hijacking|T1496.001 - Compute Hijacking]] (sub-técnica irmã) - [[t1568-dynamic-resolution|T1568 - Dynamic Resolution]] (técnica auxiliar para C2) - [[socks5systemz|Socks5Systemz]] (malware de proxyjacking) - [[_impact|Tática: Impact]] --- *Fonte: [MITRE ATT&CK - T1496.002](https://attack.mitre.org/techniques/T1496/002)*