Uma operação conjunta entre Microsoft, Google e autoridades internacionais derrubou o RedVDS, marketplace que comercializava máquinas virtuais pré-configuradas para cibercrime. Segundo o Olhardigital.com.br, o serviço cobrava a partir de US$ 24/mês (R$ 127) por infraestrutura pronta para phishing e invasão de contas — e atingiu mais de 130 mil organizações em poucos meses. O caso é um termômetro de como o crime-as-a-service evoluiu e do que devs precisam entender sobre threat intelligence na prática.
O que era o RedVDS e por que ele importa
O RedVDS não vendia malware nem exploits zero-day. Vendia algo mais perigoso pela sua simplicidade: máquinas virtuais Windows com software não licenciado e ferramentas de ataque pré-instaladas, prontas para o comprador sair phishando em minutos.
Na minha experiência investigando incidentes, percebo que esse modelo é o que mais cresce. Antes, montar uma operação de phishing exigia conhecimento técnico, compra de infraestrutura limpa, configuração de SMTP e gestão de domínios. Hoje, o criminoso aluga tudo isso por menos do que custa uma assinatura de streaming.
O preço de US$ 24/mês é o detalhe mais revelador. Quando a barreira de entrada fica abaixo de R$ 150, o cibercrime deixa de ser negócio de especialista e vira commodity. Qualquer um com cartão de crédito e um tutorial no YouTube consegue operar.
A escala real do estrago
Os números publicados pela Microsoft assustam, e não é pra menos:
- 130 mil organizações atacadas entre setembro e dezembro de 2025
- 191 mil contas de e-mail Microsoft comprometidas ou acessadas fraudulentamente
- 2,6 mil máquinas virtuais distintas enviando cerca de 1 milhão de e-mails de phishing por dia
Quando leio “1 milhão de mensagens de phishing por dia”, penso imediatamente em três coisas: taxa de bypass de filtros, qualidade da engenharia social e ROI do atacante. Se 0,1% das mensagens converterem em credenciais roubadas, são mil contas capturadas por dia. A 10 dólares por conta no mercado secundário, a operação paga o aluguel das VMs em escala industrial.
Como funcionou a derrubada — e o que devs podem aprender com isso
A peça-chave da operação foi o Global Signal Exchange (GSE), organização sem fins lucrativos que permite o compartilhamento seguro de indicadores de ameaça entre empresas. A Microsoft identificou o RedVDS via sua Digital Crimes Unit (DCU), correlacionou dados com Google e demais membros do GSE, e entrou com ações judiciais nos EUA e Reino Unido para obter controle dos domínios.
Do ponto de vista de engenharia, o GSE é fascinante. É essencialmente uma API federada onde empresas publicam IoCs (Indicators of Compromise) — hashes, domínios, IPs, padrões de e-mail — e consomem os IoCs de outras empresas. Funciona como um sistema imunológico distribuído: cada empresa contribui com anticorpos e se beneficia dos anticorpos dos outros.
O fluxo técnico da operação
- Detecção: a DCU da Microsoft identificou padrões de uso anômalo vindo de um conjunto de IPs e domínios.
- Correlação: consultas ao GSE revelaram que outros membros já tinham visto atividade semelhante.
- Atribuição: a infraestrutura foi mapeada até a operação RedVDS.
- Ação legal: petições judiciais nos EUA e Reino Unido resultaram na transferência dos domínios.
- Neutralização: domínios redirecionados para sinkholes da Microsoft.
O detalhe que pouca gente comenta: o sinkhole é onde o trabalho forense realmente acontece. Quando você controla o DNS de um domínio criminoso, consegue ver quem continua tentando resolver aquele domínio — e esses são os hosts infectados ou em operação.
Na Prática: detectando phishing em headers de e-mail
Quando rodo análise de phishing no meu próprio pipeline, a primeira coisa que faço é inspecionar os cabeçalhos. SPF, DKIM e DMARC são seus três amigos, e qualquer falha neles é red flag imediata. Abaixo, um exemplo funcional em Python que eu uso como base em projetos de análise:
import re
from email import policy
from email.parser import BytesParser
SUSPICIOUS_TLDS = {'.zip', '.mov', '.top', '.xyz', '.click', '.country', '.kim'}
URL_REGEX = re.compile(r'https?://[^\s<>"\']+', re.IGNORECASE)
BRANDS = ['microsoft', 'outlook', 'office365', 'google', 'apple', 'nubank', 'itau']
def analyze_email(raw_bytes: bytes) -> dict:
msg = BytesParser(policy=policy.default).parsebytes(raw_bytes)
signals = []
risk_score = 0
# 1. Checagem de autenticação
auth = (msg.get('Authentication-Results') or '').lower()
if 'spf=fail' in auth: signals.append('SPF fail'); risk_score += 25
if 'dkim=fail' in auth: signals.append('DKIM fail'); risk_score += 30
if 'dmarc=fail' in auth: signals.append('DMARC fail'); risk_score += 35
# 2. Discrepância entre display name e domínio real
from_hdr = msg.get('From', '')
if '<' in from_hdr and '>' in from_hdr:
display, real = from_hdr.split('<', 1)
real = real.rstrip('>').lower()
for brand in BRANDS:
if brand in display.lower() and brand not in real:
signals.append(f'Brand spoofing: display={display!r} real={real!r}')
risk_score += 40
break
# 3. URLs com TLDs suspeitos
body = msg.get_body(preferencelist=('plain', 'html'))
if body:
content = body.get_content()
if isinstance(content, bytes):
content = content.decode('utf-8', errors='ignore')
for url in URL_REGEX.findall(content):
for tld in SUSPICIOUS_TLDS:
if url.lower().rstrip('/').endswith(tld):
signals.append(f'Suspicious TLD: {url}')
risk_score += 15
break
# 4. Reply-To divergente do From
reply_to = msg.get('Reply-To', '').lower()
if reply_to and reply_to.split('@')[-1].strip('>') not in from_hdr.lower():
signals.append('Reply-To domain differs from From domain')
risk_score += 20
return {'risk_score': risk_score, 'signals': signals, 'verdict': 'phishing_likely' if risk_score >= 50 else 'review'}Esse script não substitui um Microsoft Defender nem um Proofpoint, mas é a base que uso pra filtrar 90% do lixo antes de escalar análise humana. Em produção, normalmente adiciono integração com APIs de reputação como VirusTotal, urlscan.io e abuseIPDB.
Erros comuns que devs cometem (e que alimentam esse tipo de mercado)
Quando investigo vazamentos, percebo que a maioria dos devs comete os mesmos erros. E são exatamente esses erros que fazem o RedVDS ser lucrativo.
1. Confiar no SPF/DKIM como bala de prata
SPF e DKIM validam o caminho técnico do e-mail, não a intenção do remetente. Um atacante com controle de um domínio válido passa SPF e DKIM sem problemas. Você precisa de DMARC com política p=quarantine ou p=reject alinhada.
2. Armazenar segredos em variáveis de ambiente “seguros”
Eu vejo isso toda semana: AWS_ACCESS_KEY_ID commitado no GitHub, tokens do OpenAI em .env versionado, API keys em comentários. Um único vazamento desses vira matéria-prima para o próximo RedVDS.
3. Ignorar log de autenticação falho
Em produção, você precisa monitorar tentativas de login com falha. Um pico de falhas em um único usuário seguido de sucesso vindo de IP diferente é o sinal clássico de credential stuffing. Não espere o incident response acordar às 3h da manhã — coloque alerta automatizado.
4. Usar MFA só com TOTP “fraco”
TOTP é bom. Mas push notification sem number matching é burlável via fatigue attack. WebAuthn (chave física ou passkey) é o que deveria ser padrão em qualquer sistema novo hoje.
5. Não rotacionar credenciais de máquina
O RedVDS vendia VMs com software pirateado, mas a parte perigosa era o que o cliente instalava em cima — incluindo credenciais roubadas em outros vazamentos. Se você ainda roda com a mesma senha de root há 3 anos, está no mercado alvo.
O que devs deveriam implementar amanhã no trabalho
- Threat intel no pipeline: integre feeds como AbuseIPDB, URLhaus e AlienVault OTX no seu WAF ou API gateway. Bloquear IP malicioso no edge é mais barato que limpar incidente.
- Monitoramento de domínio sombra: use serviços como domain shadowing detection ou internamente monitore registros DNS similares ao seu (ex.:
suaempresa-login.com). - Rate limiting agressivo em endpoints de auth: limite tentativas por IP, ASN e fingerprint de dispositivo.
- Logs centralizados com retenção de 90+ dias: o incident response vive de timeline, e timeline vive de logs preservados.
Comparativo: RedVDS vs outros marketplaces do mesmo tipo
O RedVDS não é o primeiro nem será o último. A categoria de “infraestrutura como serviço para crime” tem precedentes:
- Genesis Market (2023, derrubado pelo FBI): vendia fingerprints de navegador roubados. Fechado em operação Operation Cookie Monster.
- Russian Market: focado em logs de stealer e credenciais bancárias.
- 2easy Marketplace: dados roubados via malware-as-a-service.
- RedVDS (2025): aluguel de VMs Windows pré-configuradas com ferramentas de ataque.
O padrão é claro: cada derrubada empurra o mercado para um nível acima de abstração. Quando fecham um marketplace de credenciais, surgem os de fingerprints. Quando fecham os de fingerprints, surgem os de VMs. A commoditização continua.
FAQ — perguntas que devs realmente fazem
1. Como saber se minha empresa já foi vítima de phishing via RedVDS?
Verifique nos logs do Microsoft 365 Defender por logins vindos de ranges de IP associados à operação. A Microsoft publicou indicadores de comprometimento (IoCs) no portal do Defender e no centro de mensagens do M365. Procure por tentativas de autenticação em contas que normalmente não acessam de geografias suspeitas.
2. O Global Signal Exchange (GSE) é aberto para qualquer empresa participar?
Não é totalmente aberto. O GSE foi fundado por Google, Microsoft e outras grandes do setor, e a adesão passa por validação. Mas existem feeds públicos equivalentes, como AlienVault OTX, AbuseIPDB e URLhaus, que cobrem 80% dos casos para a maioria das empresas.
3. Vale a pena implementar análise de e-mail em código próprio?
Para produtos que processam e-mail como feature central, sim — eu recomendaria como camada adicional ao provedor antispam. Mas não tente reinventar a roda do SPF/DKIM/DMARC: use bibliotecas como dkimpy e email-validator e foque seu código na lógica de negócio.
4. Como o sinkhole da Microsoft continua capturando atacantes?
Quando o domínio vai para o sinkhole, o DNS resolve para um IP controlado pela Microsoft. Toda requisição feita para aquele domínio é logada. Atacantes que continuam usando a infraestrutura comprometida — incluindo novas VMs do RedVDS configuradas com o domínio antigo — entregam IP, user-agent e timestamp de graça.
5. Quais linguagens e stacks têm melhor suporte a threat intelligence hoje?
Python domina pela quantidade de bibliotecas (OTXv2, abuseipdb, virustotal-python). Em Go, o projeto Community Threat Intel tem boa performance para correlação em alto volume. Para quem roda em cloud, integração nativa com Sentinel, Chronicle e Splunk é o caminho mais rápido para produção.
Casos como o RedVDS mostram que segurança não é mais feature opcional de produto — é a feature. E quando eu vejo que 1 milhão de mensagens de phishing por dia saíam de VMs alugadas a R$ 127/mês, a lição é direta. A próxima onda de ataques não será mais sofisticada que a anterior. Será mais barata, mais acessível e mais distribuída. Quem desenvolve precisa entender threat intelligence com a mesma naturalidade com que entende versionamento de código.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Quer que eu monte um repositório com o analisador de e-mail acima pronto pra rodar com feeds reais? Comenta aí.