# T1132.002 - Codificação Não-Padrão
## Técnica Pai
Esta é uma sub-técnica de [[t1132-data-encoding|T1132 - T1132 - Data Encoding]].
## Descrição
Codificação Não-Padrão é uma subtécnica de evasão utilizada por adversários para disfarçar o tráfego de comando e controle (C2) de forma que ferramentas de inspeção de rede tenham dificuldade em identificar padrões maliciosos. Em vez de usar esquemas de codificação bem conhecidos como Base64 puro ou hex convencional, os atacantes implementam variações modificadas - por exemplo, um Base64 com alfabeto reordenado, substituição de caracteres ou padding customizado - que fazem o tráfego parecer ilegível ou arbitrário para analisadores automáticos.
Essa abordagem é especialmente eficaz contra soluções de DLP e IDS que dependem de assinaturas baseadas em padrões de bytes conhecidos. Um malware que usa Base64 padrão é facilmente identificável porque as ferramentas conhecem o alfabeto e podem decodificar automaticamente o conteúdo. Quando o mesmo dado é codificado com um alfabeto alterado ou uma transformação proprietária, a detecção por assinatura falha e é necessária análise comportamental ou de entropia.
Famílias como [[s0346-oceansalt|OceanSalt]], [[s0260-invisimole|InvisiMole]] e [[s0022-uroburos|Uroburos]] foram documentadas usando esquemas de codificação não-padrão em seus canais C2. O [[s1239-toneshell|TONESHELL]], associado a campanhas contra organizações governamentais no Sudeste Asiático, implementa uma variação de XOR combinada com deslocamento de bits para ofuscar comandos trafegados via HTTP. Já o [[s0495-rdat|RDAT]] usa um esquema de codificação baseado em tabelas customizadas embutidas no binário.
**Contexto Brasil/LATAM:** Grupos de crime cibernético focados em Brasil utilizam codificações não-padrão frequentemente em trojans bancários e RATs distribuídos via phishing. A técnica é particularmente observada em malware que utiliza canais HTTP/HTTPS para C2, onde os dados são embutidos em parâmetros de URL ou cookies com codificação proprietária, dificultando a detecção por proxies corporativos comuns. Ferramentas como [[s0385-njrat|njRAT]] e variantes do [[s1149-chimneysweep|CHIMNEYSWEEP]] circulantes na região apresentam esse padrão.
## Attack Flow
```mermaid
graph TB
A[Malware Instalado] --> B[Canal C2 Estabelecido]
B --> C[Codificação Não-Padrão]
C --> D[Tráfego Ofuscado]
D --> E[Comando Executado]
```
## Como Funciona
**1. Preparação**
O desenvolvedor do malware cria ou escolhe um esquema de codificação personalizado - frequentemente uma variação de Base64 com alfabeto embaralhado, XOR com chave dinâmica, ou combinação de múltiplos esquemas. Esse algoritmo é embutido tanto no cliente (implant) quanto no servidor C2 para garantir comunicação bidirecional.
**2. Execução**
Quando o implant precisa enviar dados ao C2 (resultados de comandos, informações coletadas, heartbeat), ele codifica o payload usando o algoritmo proprietário. O dado codificado é então transmitido dentro de protocolos legítimos - corpo de requisição HTTP, parâmetros GET, headers ou cookies - fazendo o tráfego parecer tráfego web normal para inspeção superficial.
**3. Pós-execução**
O servidor C2 decodifica o tráfego recebido usando o mesmo algoritmo. Do lado da vítima, as respostas com comandos chegam igualmente codificadas. Como o esquema é não-padrão, ferramentas de análise automática não conseguem decodificar o conteúdo sem conhecer o algoritmo específico, tornando a análise forense mais demorada.
**Exemplo:**
```python
# Padrão de Base64 com alfabeto customizado - indicador de T1132.002
# Alfabeto padrão: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
# Alfabeto modificado (exemplo observado em malware): ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba9876543210-_
# Dados transmitidos via HTTP POST com aparência de string aleatória mas comprimento múltiplo de 4
# Artefato de detecção: alta entropia em parâmetros de formulário + comprimento de string suspeito
```
## Detecção
**Fontes de dados:** Network traffic logs, proxy logs, Zeek/Bro network analysis, PCAP analysis, Sysmon (EventID 3 - network connection)
```yaml
title: Non-Standard Encoding in C2 Traffic
id: 3b8e5a2f-1c74-4d9a-b631-ae5027f9c456
status: experimental
description: Detecta transmissão de dados com alta entropia em campos HTTP que normalmente contêm dados de baixa entropia, sugerindo codificação não-padrão no canal C2
logsource:
category: proxy
product: zeek
detection:
selection:
uri_query|re: '[A-Za-z0-9]{64,}'
filter_legitimate:
resp_mime_types: 'image/*'
condition: selection and not filter_legitimate
falsepositives:
- Uploads de arquivos legítimos com conteúdo codificado
- APIs que utilizam tokens longos em parâmetros de URL
- Serviços de autenticação com JWTs em query strings
level: medium
tags:
- attack.command_and_control
- attack.t1132.002
```
## Mitigação
| Mitigação | Recomendação Prática |
|-----------|---------------------|
| [[m1031-network-intrusion-prevention\|M1031 - Network Intrusion Prevention]] | Configurar inspeção de conteúdo profunda (DPI) com análise de entropia em tráfego HTTP/HTTPS; alertar em payloads com entropia Shannon > 4.5 em campos que normalmente contêm texto legível |
## Referências
*Fonte: [MITRE ATT&CK - T1132.002](https://attack.mitre.org/techniques/T1132/002)*