Revenge Of The Baskerville

O que é e como funciona na prática

A técnica de revenge of the baskerville é um vetor de phishing que depende inteiramente de confiança prévia. O atacante não vende nada, não pede dinheiro direto, não usa login falso de banco. O ataque se resume a um email aparentemente inocente vindo de alguém que você já conhece — um colega, um parceiro comercial, um fornecedor que você lida há anos. O conteúdo geralmente cita um projeto em comum, um arquivo que foi "esquecido" sendo enviado, ou uma dúvida que soa perfeitamente contextual. O link ou anexo leva a um payload malicioso, seja RaaS, RAT, ou um documento com macros habilitadas. O nome vem de uma referência ao caso canônico de Sir Arthur Conan Doyle, mas a analogia não é acidental. Assim como o cão dos Baskerville era um dispositivo de terror que explorava crenças estabelecidas, esse ataque explora a confiança institucional que você já construiu. A mensagem não precisa ser convincente do zero. Ela precisa apenas continuar uma conversa que já existia.

Revenge of the Baskerville no ambiente corporativo

Na prática, o fluxo mais comum que eu vejo acontecendo é este: o atacante compromete uma conta de email de baixo valor, talvez de um fornecedor menor ou de um funcionário com pouca higiene digital. Depois, varre a lista de contatos, identifica quem fala frequentemente com seus alvos e envia mensagens personalizadas usando contexto real puxado de emails anteriores. O alvo recebe algo como "Oi, segue o relatório que combinamos na reunião semana passada" com um link para um PDF hospedado em domínio recém-registrado. A URL pode até passar nos filtros iniciais se o domínio tiver DNS limpo e certificado TLS válido. O que mata a defesa é o fator humano, não a tecnologia. Uma coisa que poucos analistas iniciantes percebem é que o timing do envio frequentemente corresponde a horários em que o destinatário está mais propenso a agir por impulso. Segunda de manhã, quinta à tarde, momentos de transição entre reuniões. Isso não é coincidência. O atacante estuda o padrão de comunicação da vítima.

Já me deparei com um caso em que o domain do email remetente era correto, o SPF estava passível, DKIM e DMARC estavam todos verdes. A única anomalia era um anexo .doc que apontava para um servidor de CDN russo com latência de 340ms. O arquivo em si parecia um contrato comum. Mas o remetente, que normalmente escrevia em inglês, tinha usado português coloquial com gírias regionais que ele jamais usava. Eu desconfiei exatamente porque o contexto parecia "muito bom" — um contrato urgente que precisava de assinatura imediata, algo que gera pressa e elimina o pensamento crítico. O workload foi descartado e a conta do fornecedor foi isolada. Dois dias depois, descobriu-se que a credencial dele tinha sido vendida num fórum de credential stuffing. Outro ponto contra-intuitivo: ataques desse tipo raramente tentam fazer ransomware pesado no primeiro movimento. Eles quase sempre instalam um loader ou um agent de exfiltração primeiro. O ransomware vem apenas se o objetivo for prejuízo direto. Se o objetivo for espionagem ou acesso persistente, o malware ficaquieto, coleta dados e espera. Conheço equipes que derrubaram o host achando que tinham contido uma infecção, quando na verdade acabaram de eliminar a evidência de um acesso que já durava meses.

O principal gargalo dessa técnica é que ela depende de reconnaissance. Sem acesso prévio à correspondência entre o atacante e a vítima, o ataque perde a armadura da naturalidade. Por isso, ferramentas de análise de tráfego de email, logging de sessões ativas de colaboradores, e monitoramento de padrões de envio — não apenas de conteúdo, mas de horário, frequência, e estilo linguístico — são mais úteis do que simplesmente melhorar os filtros de spam. Um sistema de detecção baseado em anomalia de comportamento do remetente, treinado nos últimos seis meses de comunicação real, consegue identificar desvios muito antes de um filtro heurístico convencional. Se você precisa avaliar se o seu ambiente está exposto, comece mapeando quantos fornecedores externos têm permissão para enviar emails diretamente para diretórios inteiros sem passar por gateways secundários. Em minha experiência, essa configuração sola aparece em 70% dos incidentes que envolvem essa técnica. A correção mais simples, que custa nada e leva quinze minutos para implementar, é exigir verificação manual de qualquer remetente externo que ainda não tenha histórico de envio consolidado nos últimos 90 dias. Funciona.