Jeff Bruchado
Voltar para o Blog

Proxies Residenciais na Rede da Casa Branca em 2026: Como Saber se Sua Rede Virou Saída de Proxy

Olá HaWkers, no dia 4 de novembro de 2026 a Layer3 Intel, empresa que vende detecção de proxies residenciais, publicou um achado que subiu rápido no Hacker News (mais de 1.000 pontos): entre 5 de outubro e 3 de novembro, o tráfego de serviços de proxy residencial saiu 236 vezes por endereços do AS2650, o sistema autônomo registrado para o Gabinete Executivo do Presidente dos Estados Unidos, que hospeda a rede da Casa Branca.

Não foi invasão de filme. Muito provavelmente foi algo bem mais banal: um aparelho dentro da rede com um aplicativo que carrega um SDK de proxy, revendendo a conexão para quem paga alguns dólares. E é exatamente por ser banal que isso importa para você.

Se isso aconteceu na rede da Casa Branca, você sabe dizer se não está acontecendo na sua casa, no escritório ou na rede da empresa onde roda o seu servidor de staging? Neste artigo você vai entender como funciona o mercado de proxies residenciais, por que um SDK desses é um risco de rede interna e não só de banda, e vai sair com scripts para verificar seus dispositivos e para tratar esse tráfego na sua API.

O Que a Layer3 Intel Encontrou

A Layer3 opera um pipeline que compra acesso rotativo global em serviços públicos de proxy residencial e anota por onde cada requisição sai. A empresa diz que não mirou a Casa Branca: o endereço apareceu no meio da coleta, como qualquer outro que esses serviços oferecem.

Os números publicados para a janela de 5 de outubro a 3 de novembro de 2026:

Métrica Valor
Saídas observadas pela rede da Casa Branca 236
Endereços IP envolvidos 6
Dias com atividade 26 de 30
Serviços de proxy diferentes capazes de sair por ali 28

Os endereços foram conferidos nas bases públicas da Spur e da Synthient, que também os classificavam como saídas de proxy residencial. A Layer3 guardou os logs brutos e diz que vai entregá-los às agências que pedirem.

O detalhe mais revelador é o horário. Cerca de metade da atividade cai entre 17h e meia-noite no horário do leste dos EUA, e quase nada acontece de madrugada. Esse padrão combina com um aparelho pessoal, como um celular ou uma TV box, que entra na rede quando alguém está lá e fica ligado à noite. A própria Layer3 reconhece o limite do dado: ela enxerga só a saída, não o dispositivo nem a pessoa.

O relatório traz outros achados curiosos que mostram o alcance desses serviços: Santa Helena, Ascensão e Tristão da Cunha somaram 413 endereços e mais de 32.000 observações, e até a Antártida apareceu, com 3 observações saindo por um endereço do Cloudflare WARP ligado à estação McMurdo.

Como Funciona um Proxy Residencial

Um proxy comum sai de um data center, e qualquer sistema antifraude reconhece esses endereços. Um proxy residencial sai pela conexão de uma pessoa real, com IP de operadora doméstica. Para o site do outro lado, a requisição parece vir de um usuário normal em casa.

De onde vêm esses milhões de IPs residenciais? Principalmente de três lugares:

  1. SDKs embutidos em aplicativos gratuitos. O desenvolvedor do app recebe por usuário ativo, e o SDK usa parte da conexão do aparelho como nó de saída. Às vezes isso aparece em um termo de uso que ninguém lê, às vezes nem isso.
  2. Aplicativos de "ganhe dinheiro compartilhando internet". O usuário instala sabendo, em troca de centavos.
  3. Aparelhos que já vêm infectados. TV boxes baratas e sem certificação, vendidas com firmware modificado.

Do lado do comprador, o fluxo é simples: ele paga por gigabyte, recebe um host e uma credencial, e o serviço escolhe um aparelho da rede para entregar a requisição.

Comprador ──> Gateway do serviço de proxy ──> SDK no seu celular ──> Site de destino
                                                   │
                                                   └── Sua rede local (Wi-Fi da casa,
                                                       do escritório, da empresa)

O problema está naquela seta para baixo. O SDK roda dentro da sua rede. Se ele não bloquear endereços internos, quem compra o proxy pode pedir para acessar 192.168.0.1, a impressora, o NAS ou o painel de administração do roteador, e o seu aparelho vai obedecer.

Por Que Isso É Risco de Rede Interna, Não Só de Banda

Isso não é hipótese. No começo de 2026, a Synthient publicou a pesquisa sobre a botnet Kimwolf, apontada como variante Android da AISURU, a mesma família por trás dos ataques DDoS recordistas que já analisamos em o DDoS recorde de 31 Tbps contra a Cloudflare. Segundo a Synthient, a Kimwolf passou de 2 milhões de dispositivos Android infectados, ativa desde pelo menos agosto de 2025.

O caminho de entrada foi justamente o descrito acima:

  • os operadores alugavam acesso em serviços de proxy residencial, principalmente na IPIDEA, com sede na China;
  • usavam o proxy para alcançar a rede local do aparelho que servia de saída;
  • procuravam dispositivos Android com o ADB exposto na rede e instalavam o malware.

A Synthient estimou que cerca de 67% dos dispositivos Android analisados nas pools de proxy não tinham autenticação no ADB. A IPIDEA corrigiu a falha no fim de dezembro de 2025, bloqueando o acesso à rede local. Os países com mais infecções incluíam Vietnã, Brasil, Índia e Arábia Saudita, e a maioria dos alvos eram TV boxes baratas.

Em 28 de janeiro de 2026, o Google anunciou uma ação contra a IPIDEA: derrubou domínios, tirou do ar pelo menos 13 marcas de proxy ligadas a ela, identificou mais de 600 aplicativos Android e 3.075 arquivos de Windows ligados à infraestrutura de comando e controle, e passou a bloquear pelo Play Protect os apps que carregam os SDKs da IPIDEA. Segundo o Wall Street Journal, a ação tirou cerca de 9 milhões de dispositivos da rede.

Agora volte para a Casa Branca. A Layer3 levanta exatamente essa preocupação: se o SDK que está naquela rede tiver uma falha parecida, quem compra acesso de proxy pode chegar a sistemas internos. Banda roubada é o menor dos problemas.

Passo 1: Verifique Se o Seu IP Aparece Como Proxy

O jeito mais rápido de começar é descobrir se o IP público da sua rede já está em alguma base de proxies residenciais. A Layer3 oferece uma página gratuita, "Is my network a residential proxy?", que confere o endereço de onde você acessa contra uma base que ela diz ter mais de 70 milhões de IPs de proxy ativos. A Spur também tem páginas públicas de contexto por IP.

Dois cuidados para o resultado não enganar:

  • desligue VPN, iCloud Private Relay e Cloudflare WARP antes de testar, senão você confere o IP do serviço e não o da sua casa;
  • teste em cada rede que importa: casa, escritório e, se tiver acesso, a saída da empresa.

Um IP limpo hoje não garante nada para amanhã, porque os IPs residenciais mudam e os SDKs só ficam ativos em certos horários. Por isso o passo seguinte é olhar os aparelhos.

Passo 2: Procure ADB Exposto na Sua Rede Local

Se um SDK de proxy abrir caminho para a sua rede, o primeiro alvo que a Kimwolf procurava era o ADB escutando na porta 5555. Este script em Node.js varre a sua sub-rede /24 e lista quem responde nessa porta.

// scan-adb.mjs
// Varre a rede local procurando dispositivos com ADB por TCP (porta 5555).
// Uso: node scan-adb.mjs 192.168.0
import net from 'node:net';

const prefixo = process.argv[2] ?? '192.168.0';
const PORTA = 5555;
const TIMEOUT_MS = 400;

function testarPorta(host) {
  return new Promise(resolve => {
    const socket = new net.Socket();
    socket.setTimeout(TIMEOUT_MS);
    // Conectou: a porta está aberta
    socket.once('connect', () => {
      socket.destroy();
      resolve(true);
    });
    // Timeout ou recusa: porta fechada ou filtrada
    socket.once('timeout', () => {
      socket.destroy();
      resolve(false);
    });
    socket.once('error', () => resolve(false));
    socket.connect(PORTA, host);
  });
}

const hosts = Array.from({ length: 254 }, (_, i) => `${prefixo}.${i + 1}`);
// Testa em paralelo para terminar em poucos segundos
const resultados = await Promise.all(
  hosts.map(async host => ({ host, aberto: await testarPorta(host) }))
);

const expostos = resultados.filter(r => r.aberto);
if (expostos.length === 0) {
  console.log('Nenhum dispositivo com ADB na porta 5555.');
} else {
  console.log('ADB exposto encontrado em:');
  for (const { host } of expostos) console.log(`  - ${host}`);
  console.log('Desative a depuração por rede nesses aparelhos.');
}

Achou algum endereço? Quase sempre é TV box, projetor ou celular com depuração ativada. No aparelho, desative "Depuração por ADB" e "Depuração por rede" nas opções de desenvolvedor. Se for uma TV box sem marca conhecida que você não consegue limpar, a decisão mais segura é tirá-la da rede principal.

Passo 3: Audite os Aplicativos do Celular e da TV Box

O SDK de proxy precisa de três coisas para funcionar bem: acesso à internet, um serviço em primeiro plano que não morra e permissão para iniciar no boot. Muitos apps legítimos também pedem isso, então não é prova de nada, mas é um ótimo filtro para começar. Este script usa o adb com o aparelho conectado por USB.

#!/usr/bin/env bash
# audita-apps.sh
# Lista apps de terceiros com o combo de permissões típico de SDK de proxy.
# Requer: adb instalado e o aparelho conectado por USB com depuração ativa.
set -euo pipefail

for pkg in $(adb shell pm list packages -3 | cut -d: -f2 | tr -d '\r'); do
  perms=$(adb shell dumpsys package "$pkg" | tr -d '\r')
  # Conta quantas das permissões suspeitas o app tem concedidas
  hits=0
  for p in INTERNET FOREGROUND_SERVICE RECEIVE_BOOT_COMPLETED; do
    if echo "$perms" | grep -q "android.permission.$p: granted=true"; then
      hits=$((hits + 1))
    fi
  done
  # Só mostra quem tem as três
  if [ "$hits" -eq 3 ]; then
    echo "[revisar] $pkg"
  fi
done

Depois, veja quais serviços estão rodando agora. Um app de lanterna ou de papel de parede com serviço ativo em segundo plano merece explicação.

# Serviços em execução de apps de terceiros (filtra os do sistema)
adb shell dumpsys activity services \
  | grep -E 'ServiceRecord' \
  | grep -vE 'com\.android|com\.google' \
  | sort -u

Para uma auditoria mais completa, existem ferramentas open source que fazem esse trabalho de ponta a ponta, extraindo endpoints de rede dos APKs e classificando o risco. Se você quer ir além e checar spyware de verdade, vale ler também o guia do Zero Breach Toolkit para verificar spyware no celular e no PC.

Encontrou um app que você não lembra de ter instalado ou que não tem motivo para rodar em segundo plano? Desinstale. Na TV box, se o app suspeito for do sistema, o caminho é o mesmo que mostramos em como tirar os anúncios da Android TV com ADB: desativar para o usuário atual, de forma reversível.

Passo 4: Isole o Que Você Não Controla

Mesmo com tudo limpo, a lição da Casa Branca é de arquitetura: aparelho pessoal não deveria estar na mesma rede de sistema interno. Três medidas resolvem a maior parte do risco:

  • Rede de convidados ou VLAN de IoT para TV, TV box, câmera e celular de visita, sem acesso à rede principal.
  • Bloqueio de tráfego entre clientes (client isolation) no Wi-Fi de convidados, para um aparelho não enxergar o outro.
  • Regra de saída no firewall para servidores internos: um NAS não precisa falar com a internet inteira.

Na empresa, a conta é a mesma em escala maior. Rede corporativa com BYOD (traga seu próprio dispositivo) sem segmentação é exatamente o cenário em que um app gratuito instalado por um funcionário vira porta de entrada.

Passo 5: Trate o Tráfego de Proxy Residencial na Sua API

Do outro lado da moeda, se você mantém uma API ou um site, uma parte do tráfego que chega já vem de proxies residenciais: scraping, criação de contas em massa, teste de senhas vazadas. Bloquear por IP não funciona bem, porque aquele IP também é de um usuário real. O caminho mais sólido é limitar por comportamento e por identidade, não só por endereço.

// middleware/rate-limit-por-conta.js
// Limita tentativas de login por conta-alvo, não só por IP.
// Proxies residenciais trocam de IP a cada requisição, mas o alvo é o mesmo.
const JANELA_MS = 15 * 60 * 1000; // 15 minutos
const LIMITE_POR_CONTA = 5;
const tentativas = new Map(); // em produção, use Redis

export function limitarLoginPorConta(req, res, next) {
  const conta = String(req.body?.email ?? '').toLowerCase().trim();
  if (!conta) return next();

  const agora = Date.now();
  // Mantém só as tentativas dentro da janela
  const recentes = (tentativas.get(conta) ?? []).filter(t => agora - t < JANELA_MS);

  if (recentes.length >= LIMITE_POR_CONTA) {
    // Não diga se a conta existe; peça verificação extra
    return res.status(429).json({ erro: 'Muitas tentativas. Tente novamente mais tarde.' });
  }

  recentes.push(agora);
  tentativas.set(conta, recentes);
  next();
}

Combine isso com sinais que um proxy não esconde: o mesmo dispositivo (fingerprint de sessão) aparecendo em dezenas de IPs de países diferentes, fuso horário do navegador que não bate com a geolocalização do IP e um volume de cadastro que dispara de madrugada. Bases de reputação de IP, como as da Spur e da própria Layer3, ajudam como um sinal a mais no placar de risco, nunca como bloqueio cego, para não punir o usuário real que tem o azar de dividir a conexão com um SDK.

O Que Ainda Não Se Sabe

Vale separar o que é fato do que é interpretação:

  • Fato: 236 saídas, 6 IPs, 26 de 30 dias, 28 serviços, endereços confirmados em duas bases independentes.
  • Interpretação: que se trata de um aparelho pessoal com SDK. É a leitura mais provável pelo padrão de horário, mas a Layer3 não sabe qual dispositivo nem qual app.
  • Desconhecido: se o SDK em questão bloqueia endereços internos. É isso que separa um incidente de banda de um incidente de segurança.

Também é bom lembrar que a Layer3 vende detecção de proxies, então tem interesse em mostrar o tamanho do problema. Os dados conferem com Spur e Synthient, mas a análise é dela.

Perspectivas: O Mercado Que Vive da Sua Conexão

A ação do Google contra a IPIDEA mostrou que dá para encolher esse mercado, mas não acabar com ele. Enquanto existir quem pague por IP residencial e desenvolvedor de app gratuito precisando monetizar, vai existir SDK revendendo conexão. A tendência é a pressão aumentar pelas lojas de aplicativos, com o Play Protect já bloqueando SDKs conhecidos, e pelas próprias redes, com segmentação virando padrão até em casa.

Para quem desenvolve, ficam duas lições práticas. Primeiro, nunca coloque um SDK de monetização no seu app sem saber o que ele faz com a rede do usuário. Segundo, desenhe a sua rede e a sua API presumindo que parte dos aparelhos e do tráfego já está nas mãos de outra pessoa. Se a rede da Casa Branca virou saída de proxy, a sua também pode virar.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu os proxies residenciais encontrados na rede da Casa Branca e como verificar se a sua rede, seus aparelhos e sua API estão expostos, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso

Comentários (0)

Esse artigo ainda não possui comentários 😢. Seja o primeiro! 🚀🦅

Adicionar comentário