01Embutido em Ativos WebPayload oculto em arquivos legítimos
Como funciona: O arquivo malicioso é fragmentado ou codificado e escondido dentro de um ativo que parece legítimo — imagem, script, folha de estilo, módulo compilado. O browser reconstrói o payload no cliente após o download. O gateway precisa ir além do Content-Type e inspecionar o conteúdo real de cada recurso para detectar esse vetor.
Esteganografia em ImagemPNG / LSB
Payload ocultado nos bits menos significativos dos pixels de um PNG válido.
TécnicaLSB Steganography — o bit menos significativo de cada pixel é substituído por um bit do payload. A imagem continua visualmente idêntica, mas carrega os bytes do arquivo malicioso.
Risco realUsado em campanhas APT para exfiltração de dados e entrega de stagers C2 embutidos em imagens de perfil e banners de sites.
Payload armazenado em um data segment de um módulo WebAssembly válido.
TécnicaO binário WASM é um formato compilado com seções específicas. O payload é inserido na seção de dados (data segment) do módulo. O JavaScript instancia o módulo e lê a memória linear para extrair os bytes.
Risco realCrescente uso em mineradores de criptomoedas e loaders de malware distribuídos via CDNs de terceiros embutidos em sites legítimos.
Payload em base64 dentro de uma tag <script> inline, reconstruído via atob().
TécnicaO arquivo malicioso é convertido para base64 e injetado como string literal em um <script> inline. Ao carregar a página, o JS decodifica com atob() e dispara o download via Blob URL.
Risco realVetor central em ataques de supply chain via scripts de terceiros comprometidos — analytics, chatbots e pixels de rastreamento.
Payload em um arquivo JS autônomo como string base64 dentro de uma IIFE auto-executável.
TécnicaUma IIFE (Immediately Invoked Function Expression) contém o payload em base64 como constante. Na execução, a função decodifica e cria um Blob para download. O arquivo é servido como application/javascript normal.
Risco realTécnica preferida em ataques Magecart: scripts de skimming em e-commerces ativam o payload apenas na página de pagamento.
Payload como data URI dentro da propriedade content de uma regra CSS.
TécnicaO payload é embutido como data URI (data:application/octet-stream;base64,...) dentro de uma propriedade CSS. O JavaScript lê o valor computado via getComputedStyle() e decodifica.
Risco realUsada para esconder configurações de C2 ou chaves de criptografia em arquivos de estilo, evitando análises focadas em JavaScript.
Payload dentro de um bloco <script> CDATA de um SVG válido.
TécnicaSVG é XML que suporta elementos <script> nativamente. O payload é inserido em um bloco <![CDATA[...]]> dentro de <script>. Quando o SVG é renderizado como <img> ou <object>, o script pode não executar, mas como resposta direta ou inline, executa normalmente.
Risco realFrequente em phishing com SVG como anexo de email — contorna filtros de extensão e é aberto diretamente pelo browser.
02Ataques por FragmentaçãoPayload dividido — cada fragmento é inofensivo isolado
Como funciona: O arquivo malicioso é dividido em partes que, individualmente, não contêm assinatura detectável. O browser recebe todos os fragmentos, remonta o arquivo original em memória e aciona o download. Para detectar, o gateway precisa rastrear estado entre requisições e remontar os fragmentos antes de escanear — capacidade que a maioria dos gateways não possui por padrão.
Divisão Sequencial4 fragmentos
Arquivo dividido em 4 partes iguais entregues como JSON sequencial.
TécnicaO payload é dividido em N partes de tamanho igual. Cada parte é codificada em base64 e entregue como elemento de um array JSON. O cliente concatena as partes na ordem recebida e reconstrói o arquivo.
Risco realDocumentado em distribuição de malware via APIs públicas e JSON feeds — cada requisição parece tráfego legítimo de dados.
Divisão Invertidaordem reversa
Fragmentos entregues em ordem inversa. O cliente inverte o array antes de remontar.
TécnicaIdêntico ao split sequencial, mas os fragmentos chegam em ordem invertida (último primeiro). O JavaScript no cliente inverte o array com .reverse() antes de concatenar, produzindo o arquivo original.
Risco realVariante que frustra tentativas simples de reassembly baseadas na ordem de chegada dos pacotes.
Tamanhos Aleatóriosembaralhado
Fragmentos de tamanho variável e aleatório, embaralhados com metadados de índice.
TécnicaO payload é dividido em partes de tamanho aleatório. Cada parte recebe um campo index. As partes são embaralhadas antes de serem enviadas. O cliente ordena por index e concatena.
Risco realAdotado em loaders que buscam configuração em múltiplos endpoints, variando tamanho e ordem a cada execução.
Fragmentos Misturadosintercalado
Fragmentos reais intercalados com padding nulo. O cliente filtra pelo campo real==true.
TécnicaO payload é dividido em partes reais, que são intercaladas com fragmentos de bytes nulos (chaff). Cada objeto JSON tem um campo booleano real. O cliente filtra apenas os verdadeiros e remonta.
Risco realCombina fragmentação com ruído para invalidar qualquer reassembly ingênuo pelo gateway.
03Canais AlternativosProtocolos frequentemente fora do escopo de inspeção
Como funciona: Gateways são otimizados para inspecionar tráfego HTTP/HTTPS convencional. Protocolos como WebSocket, SSE, WebRTC e gRPC usam o mesmo transporte mas têm semântica diferente — o payload chega fragmentado, bidirecional ou em formato binário proprietário. Muitos gateways simplesmente não fazem reassembly desses fluxos para inspeção.
Server-Sent EventsSSE
Payload transmitido em fragmentos base64 via conexão SSE de longa duração.
TécnicaUma conexão HTTP de longa duração com Content-Type: text/event-stream transmite o payload como série de eventos data: <chunk_b64>. O cliente acumula os chunks e remonta quando recebe o evento [END].
Risco realUsado para exfiltração em tempo real e delivery de configurações de malware via conexões que parecem telemetria legítima.
WebSocketWS
Payload transmitido via WebSocket em frames binários bidirecionais.
TécnicaApós o handshake HTTP (upgrade), a conexão WebSocket é um canal full-duplex. O servidor envia o payload fragmentado como mensagens binárias. O gateway inspecionou o handshake mas raramente analisa o conteúdo das mensagens subsequentes.
Risco realCanal preferido de C2 moderno — o tráfego se mistura com aplicações SaaS corporativas que usam WebSocket nativamente.
HTTP Streamingchunked
Payload entregue byte a byte via chunked transfer encoding.
TécnicaEm vez de entregar o arquivo de uma vez, o servidor usa Transfer-Encoding: chunked para enviar o conteúdo em pedaços minúsculos com atrasos entre eles. O browser reconstrói o arquivo automaticamente.
Risco realExplorado por servidores de malware que enviam payloads de forma lenta para ultrapassar janelas de buffering do gateway.
Entrega via WebTransport sobre HTTP/3 + QUIC — requer HTTPS.
TécnicaWebTransport usa HTTP/3 (QUIC sobre UDP) para criar streams bidirecionais de baixa latência. O payload pode ser enviado por streams unidirecionais ou datagramas sem o overhead do TCP, dificultando inspeção baseada em reassembly TCP.
Risco realAdotado por pesquisadores de red team como canal de C2 em ambientes que não bloqueiam QUIC/UDP.
WebRTC DataChannelP2P
Payload transferido P2P via RTCDataChannel — o gateway está completamente fora do caminho.
TécnicaWebRTC estabelece uma conexão peer-to-peer direta entre dois browsers. Os DataChannels permitem troca de dados binários arbitrários. O sinal de estabelecimento usa HTTPS (passa pelo gateway), mas os dados em si trafegam diretamente entre os peers via DTLS/SRTP.
Risco realPesquisadores demonstraram C2 completamente indetectável via WebRTC DataChannel — o tráfego de sinalização parece uma videochamada normal.
Payload dentro de um frame gRPC-Web em protobuf — formato binário raramente inspecionado.
TécnicagRPC-Web encapsula mensagens protobuf em frames binários com um header de 5 bytes (flag + tamanho). O payload é serializado como campo protobuf (tag + varint + bytes) dentro do frame. O Content-Type é application/grpc-web+proto.
Risco realPotencial crescente em ambientes que autorizam gRPC entre microsserviços — o formato binário protobuf não aciona assinaturas convencionais.
Firebase Cloud Messagingpush notification
Payload via notificação push FCM — tráfego para Google frequentemente em lista de permissão.
TécnicaO atacante registra um Service Worker na página maliciosa. O SW se inscreve no FCM (Firebase Cloud Messaging). O backend envia uma notificação push com o payload no campo data. O SW recebe, decodifica e cria um download.
Risco realDocumentado em 2023: entrega garantida a qualquer usuário que visitou a página maliciosa, independente do gateway corporativo.
WebTorrentP2P / BitTorrent
Payload via WebTorrent sobre WebRTC — sem tráfego HTTP, gateway completamente fora do caminho.
TécnicaWebTorrent implementa o protocolo BitTorrent inteiramente no browser usando WebRTC DataChannels para comunicação entre peers. Um magnet link ou arquivo .torrent referencia o payload. O browser faz download P2P diretamente de outros seeds, sem servidores intermediários.
Risco realWebTorrent.js é carregado de CDNs legítimas; qualquer página pode instanciar um cliente torrent sem instalação.
04Codificação de ArquivoPayload codificado — decodificado no cliente via JavaScript
Como funciona: O arquivo malicioso é representado em um formato de texto inofensivo — base64, hexadecimal ou binário. Nenhuma dessas representações contém a assinatura original do arquivo. O JavaScript no browser decodifica e reconstrói o arquivo em memória. Para detectar, o gateway precisa decodificar e escanear o conteúdo — o que eleva significativamente o custo computacional por requisição.
Base64atob()
Payload codificado em base64 dentro de uma resposta JSON.
TécnicaBase64 é uma codificação 1:1 — cada 3 bytes do payload viram 4 caracteres ASCII. O resultado é uma string legível que não contém bytes fora do intervalo imprimível. O browser decodifica com atob() (nativo) ou Buffer.from(str,'base64').
Risco realString base64 em JSON é o vetor de ofuscação mais comum — presente em praticamente todas as famílias de malware web moderno.
HexadecimalparseInt(h,16)
Cada byte do payload representado como string hexadecimal de 2 caracteres.
TécnicaCada byte é convertido para dois dígitos hexadecimais (ex: 0x58 vira "58"). O resultado é uma string de caracteres 0-9a-f. O JavaScript reconstrói usando .match(/../g).map(h => parseInt(h, 16)).
Risco realFrequente em exploit kits que armazenam shellcode como string hex, decodificado apenas no momento da execução.
BinárioparseInt(b,2)
Cada byte representado como string de 8 dígitos binários.
TécnicaCada byte é expandido para 8 caracteres 0 ou 1 (ex: byte 0x58 vira "01011000"). O payload original de 70 bytes vira uma string de 560 caracteres. Decodificado com .match(/.{8}/g).map(b => parseInt(b, 2)).
Risco realTécnica de nicho usada para evadir soluções com alta sensibilidade para base64 e hex, apostando na raridade do formato.
05Criptografia de ArquivoPayload criptografado — chave entregue separadamente
Como funciona: O arquivo malicioso é criptografado antes de ser entregue. A chave de descriptografia chega por outro canal — embutida no JavaScript da página, em um campo JSON separado, ou derivada de informações do ambiente do cliente. O gateway vê apenas ciphertext, que por definição não contém assinaturas detectáveis. Este é o vetor mais difícil de mitigar sem execução em sandbox.
AES-256-GCMWeb Crypto API
Payload criptografado com AES-GCM, descriptografado no browser via crypto.subtle.
TécnicaO servidor criptografa o payload com AES-256-GCM. O JavaScript da página contém a chave (ou deriva via PBKDF2 a partir de um segredo embutido). A Web Crypto API nativa do browser descriptografa sem dependências externas — o resultado em memória nunca passa pelo gateway.
Risco realDocumentado em malvertising: payload criptografado servido por CDNs legítimas, tornando detecção por reputação de URL ineficaz.
TécnicaO arquivo malicioso é comprimido em um ZIP padrão (deflate). A compressão altera a representação binária do arquivo — o EICAR comprimido não contém a string EICAR em texto claro. O gateway precisa descompactar para encontrar o conteúdo real.
Risco realZIPs aninhados são usados para esgotar recursos de sandbox que tentam descompactar recursivamente sem limite de profundidade.
Payload em ZIP criptografado com AES-256. O gateway não consegue inspecionar sem a senha.
TécnicaO formato WinZip AES criptografa cada arquivo interno com AES-256 antes de comprimir. O header ZIP está visível, mas o conteúdo é ciphertext puro. A senha é entregue ao usuário por canal alternativo (e-mail, mensagem, página web).
Risco realTécnica número um em phishing com anexo — a senha é enviada no próprio email, bloqueando qualquer sandbox sem a chave.
06Ataques de PhishingPáginas maliciosas entregues em formatos que o gateway não inspeciona
Como funciona: Em vez de depender de uma URL maliciosa (bloqueável por reputação), o atacante entrega a página de phishing como conteúdo — em formatos que o gateway não associa a "site malicioso". O domínio de entrega pode ser completamente legítimo (GitHub Pages, Cloudflare Workers, googleapis.com), invalidando qualquer proteção baseada em reputação de URL.
Raw HTML — GitHubtext/html
Réplica fiel da página de login do GitHub, entregue como resposta HTML direta.
TécnicaPágina HTML completa replicando o design do GitHub Sign In — campos de usuário, senha, botão de passkey e links de rodapé. Entregue via resposta HTTP direta. O JavaScript captura as credenciais ao submeter o formulário.
Risco realGitHub Pages e similares hospedam conteúdo estático em domínios *.github.io — reputação elevada, conteúdo malicioso invisível para filtros de URL.
Réplica fiel da página de login do LinkedIn com SSO Google, entregue como HTML.
TécnicaPágina completa replicando o layout do LinkedIn — nav, hero, formulário de login e botões de SSO Google. O atacante hospeda em qualquer domínio com boa reputação e distribui o link via mensagem no próprio LinkedIn ou por email.
Risco realLinkedIn é o vetor mais explorado em spear phishing corporativo — usuários esperam receber links de "visualizar perfil" ou "conexão pendente" e clicam sem verificar o domínio.
Réplica da tela de senha do Gmail empacotada como arquivo MHTML único.
TécnicaA página de inserção de senha do Gmail (step 2 do login) é replicada e empacotada em MHTML. O arquivo chega por email ou chat como anexo. Quando aberto no Edge ou Chrome, executa o JavaScript normalmente — sem URL rastreável pelo gateway.
Risco realCampanha documentada em 2024: arquivos .mhtml anexados em emails de "documento compartilhado" — gateways de email classificam como arquivo de dados, não como executável.
Réplica da página de login do Miro (com SSO Google/LinkedIn) em arquivo MHTML.
TécnicaO arquivo MHTML replica o design do Miro com layout de split-screen, botões de SSO Google e LinkedIn, e campos de email/senha. Distribuído como "quadro compartilhado" — o pretexto é natural para usuários da ferramenta.
Risco realFerramentas de colaboração (Miro, Notion, Figma) são vetores crescentes — notificações de "alguém compartilhou um quadro com você" têm altíssima taxa de clique.
Login do LinkedIn renderizado inteiramente via Canvas 2D — sem texto no DOM, botões interativos funcionais.
TécnicaToda a página — nav, campos, botões, logotipo — é desenhada pixel a pixel via Canvas 2D API. O JavaScript detecta cliques por coordenadas e simula interatividade (mostrar/ocultar senha, submit). Para o gateway, o HTML da página é praticamente vazio.
Risco realAdotado por kits avançados (EvilProxy, Modlishka) — invalida toda uma classe de soluções anti-phishing baseadas em análise de DOM, OCR de texto HTML e detecção de campos de formulário.
Arquivo SVG que replica a tela de login do Figma e executa JavaScript quando aberto no browser.
TécnicaSVG suporta elementos <script> nativamente. O arquivo replica visualmente a interface do Figma — dialog de "sessão expirada", campos de email/senha e botão de login. Elementos SVG com onclick capturam cliques. Distribuído como "exportação de design" em Slack, email ou Jira.
Risco realDesigners trocam arquivos SVG rotineiramente. O gateway vê Content-Type: image/svg+xml e libera. Quando o usuário abre o arquivo, o browser executa o JavaScript embutido sem nenhuma interação adicional.
Página HTML que imita o viewer de protótipos do Figma com modal de "sessão expirada".
TécnicaA página replica o layout do Figma prototype viewer — topbar, canvas de fundo, e um modal central pedindo login por "sessão expirada". O link é distribuído como "clique para ver o protótipo" em Slack, Jira ou email. O domínio de hospedagem é legítimo (GitHub Pages, Vercel, Netlify).
Risco realFigma share links são enviados dezenas de vezes por dia em times de produto. A expectativa de receber um link de protótipo é alta — a taxa de clique e preenchimento de credenciais é proporcional.
07Upload e DLP OutboundArquivo transformado localmente antes de trafegar pela rede
Como funciona: Em vez de enviar o arquivo sensível diretamente, o JavaScript o transforma no browser antes de fazer upload — fragmentando, codificando ou criptografando. O DLP vê apenas os dados transformados, não o conteúdo original. Para detectar, o DLP precisa desfazer a transformação e inspecionar o conteúdo real — ou monitorar no endpoint o acesso ao arquivo antes da transformação.
Endpoint de Uploadmultipart/form-data
Envie qualquer arquivo transformado. O servidor reporta o que chegou — use para validar se o DLP inspeciona o conteúdo real ou apenas os metadados.
DiretoEICAR enviado como application/octet-stream — o DLP deve detectar a assinatura no corpo da requisição.
Base64EICAR codificado em base64 antes do upload — o DLP vê um arquivo .txt com string base64, não um binário. Deve decodificar e escanear.
FragmentadoEICAR dividido em 2 partes enviadas como campos separados no multipart. O DLP deve remontar todos os campos e escanear o conteúdo combinado.
📂
Clique ou arraste um arquivo para testar o endpoint de upload
Risco realDLP que opera apenas como proxy HTTP é contornado por qualquer transformação client-side antes do upload.
Upload via Canal Alternativoframes binários
Arquivo enviado via WebSocket binário — DLP focado em HTTP não inspeciona este canal.
TécnicaEm vez de usar fetch() ou XMLHttpRequest (inspecionados pelo DLP), o arquivo é lido como ArrayBuffer e enviado como mensagem binária via WebSocket. O servidor recebe os frames e reconstrói o arquivo.
Risco realDocumentado em red team: dados exfiltrados via canal alternativo enquanto o DLP registra apenas tráfego genérico.