# T1132 - Codificação de Dados em Canais C2 ## Descrição A técnica T1132 cobre o uso de esquemas de codificação de dados para dificultar a detecção do tráfego de comando e controle (C2). O princípio é simples: ao invés de transmitir comandos e respostas em texto puro, o malware aplica uma transformação de encoding ao payload antes de colocá-lo no canal de rede. Para uma ferramenta de inspeção ou analista que observa o tráfego sem contexto, o conteúdo parece dados binários, texto aleatório ou simplesmente ruído. Essa técnica se divide em duas variantes principais. A primeira, [[t1132-001-standard-encoding|T1132.001 - Codificação Padrão]], utiliza formatos amplamente reconhecidos como Base64, ASCII, Únicode ou MIME - esquemas que já aparecem com frequência em tráfego legítimo, tornando a detecção baseada apenas na presença de encoding ineficaz. A segunda, [[t1132-002-non-standard-encoding|T1132.002 - Codificação Não-Padrão]], emprega transformações customizadas ou combinadas (ex: XOR seguido de Base64 com alfabeto modificado) que não correspondem a nenhum padrão reconhecível, exigindo análise mais profunda para identificação. Malwares como [[s0386-ursnif|Ursnif]], amplamente usado em campanhas de fraude bancária global, e [[s0128-badnews|BADNEWS]], associado a operações de espionagem, implementam codificação de dados como camada fundamental do canal C2. O framework de simulação [[s0699-mythic|Mythic]] também suporta múltiplos perfis de codificação, o que evidência o quanto essa técnica está consolidada tanto em malware criminal quanto em ferramentas de red team. **Contexto Brasil/LATAM:** O setor financeiro brasileiro é um dos mais afetados por malwares bancários que empregam codificação de dados em seus canais C2. Trojans como [[s0386-ursnif|Ursnif]] e variantes locais de RATs usam Base64 e esquemas XOR para camuflar comúnicações com servidores de controle, dificultando a análise por SOCs que monitoram apenas payloads em texto claro. A presença crescente de grupos como [[g1047-velvet-ant|Velvet Ant]] - com foco em infraestrutura crítica - reforça que a técnica não é exclusividade de atores financeiros: espionagem e sabotagem industrial também se valem de T1132 para manter persistência longa sem acionar alertas de DLP. ## Attack Flow ```mermaid graph TB A[Implante Ativo] --> B[Coleta de Dados/Comandos] B --> C[**T1132 - Data Encoding**] C --> D[Transmissão via Protocolo C2] D --> E[Servidor do Atacante Decodifica] ``` ## Como Funciona 1. **Preparação** - O desenvolvedor do malware escolhe um esquema de codificação adequado ao perfil de detecção do ambiente alvo. Ambientes corporativos com inspeção TLS profunda podem exigir codificações não-padrão (T1132.002); ambientes sem inspeção podem usar Base64 simples (T1132.001). O servidor C2 precisa implementar o decodificador correspondente. 2. **Execução** - Durante a operação, quando o implante precisa enviar dados coletados (keystrokes, screenshots, credenciais) ou receber novos comandos, ele aplica a transformação de encoding ao payload antes de transmiti-lo via HTTP, DNS, ou outro protocolo. O conteúdo codificado é inserido em campos aparentemente normais da requisição (parâmetros de URL, corpo de POST, cookies, campos de User-Agent). 3. **Pós-execução** - O servidor do atacante recebe o tráfego, aplica o decodificador correspondente e processa os dados. Do ponto de vista de um sistema de detecção sem assinatura específica, a transação parece uma requisição web comum com conteúdo binário - um padrão presente em aplicações legítimas como upload de arquivos ou APIs REST. **Exemplo:** ```bash # Artefato detectável: tráfego HTTP com corpo em Base64 atípico # Um analisador de proxy/NGFW veria algo como: # POST /updaté HTTP/1.1 # Host: analytics-cdn[.]example[.]com # Content-Type: application/octet-stream # # dGhpcyBpcyBhIGM= [payload codificado, comprimento variável] # # Detecção: alta entropia em campos de requisição + ausência de Content-Type JSON/form ``` ## Detecção **Fontes de dados:** Proxy web com inspeção de payload, IDS/IPS com análise de entropia, EDR com captura de tráfego de rede por processo, SIEM correlacionando volume e frequência de chamadas HTTP por host. ```yaml title: High Entropy Content in HTTP Request Body (Possible Data Encoding C2) id: 3d9b2a7f-4c18-4e93-bf5a-8e2d1f0c7a44 status: experimental description: Detects HTTP POST requests with high-entropy body content that may indicaté encoded C2 data logsource: category: proxy product: windows detection: selection: cs-method: 'POST' cs-uri-stem|contains: - '/updaté' - '/upload' - '/report' - '/beacon' c-uri-query: '' filter_legit: cs-host|contains: - 'microsoft.com' - 'windows.com' - 'windowsupdaté.com' condition: selection and not filter_legit falsepositives: - Administrative activity - Legitimaté file upload services - Backup agents transmitting compressed data level: medium tags: - attack.command_and_control - attack.t1132 ``` ## Mitigação | Mitigação | Recomendação Prática | |-----------|---------------------| | [[m1031-network-intrusion-prevention\|M1031 - Network Intrusion Prevention]] | Configurar IPS com análise de entropia de payload para detectar conteúdo altamente codificado em protocolos que normalmente carregam texto. Inspecionar TLS em pontos de saída críticos. Bloquear domínios C2 conhecidos identificados via threat intel feeds como [[s0128-badnews\|BADNEWS]] e [[s0386-ursnif\|Ursnif]]. | ## Sub-técnicas - [[t1132-001-standard-encoding|T1132.001 - Standard Encoding]] - [[t1132-002-non-standard-encoding|T1132.002 - Non-Standard Encoding]] ## Referências *Fonte: [MITRE ATT&CK - T1132](https://attack.mitre.org/techniques/T1132)*