Um relatório do Google divulgado nesta semana trouxe à tona uma técnica que parecia coisa de filme, mas que já causou prejuízos milionários em empresas de private equity nos Estados Unidos: hackers ligando para funcionários, fingindo ser do TI da própria empresa, e convencendo as vítimas a digitar credenciais em páginas falsas. O que me chamou atenção não foi a criatividade do golpe, mas o quão simples ele continua sendo — e como a engenharia social escapa de quase todas as defesas técnicas que gastamos fortunas para implementar. Segundo o Olhardigital.com.br, quatro grupos identificados como Falcon, Helix, Pink e Redact estão por trás dessas operações, possivelmente ligados a uma estrutura maior rastreada como UNC6671.
O que é vishing e por que devs não podem ignorar
Vishing é a união de “voice” com “phishing”. O atacante liga, constrói rapport, explora urgência — “tem um problema crítico na sua conta, preciso validar agora” — e induz a vítima a digitar credenciais em uma página clonada. O detalhe técnico que pouca gente comenta: essas páginas clonadas quase sempre são réplicas pixel-perfect feitas em horas, usando ferramentas como wget -mk para espelhar sites legítimos ou frameworks como o evilginx2, que operam como proxy reverso entre a vítima e o servidor real.
O problema para quem programa é duplo. Primeiro, a superfície de ataque está no humano, não no código — então toda a segurança que implementamos (CSP, CORS, headers rígidos, WAF) não protege contra um usuário entregando a senha voluntariamente. Segundo, se a sua aplicação usa MFA baseado em push notification simples (o famoso “aprovou no app?”), ela é completamente vulnerável a essa técnica. O atacante liga, pede a senha E o código que chegou no celular, e pronto: MFA bypassed.
Como os grupos Falcon, Helix, Pink e Redact operam na prática
O relatório do Google descreve um padrão operacional consistente entre os quatro grupos. Eles ligam para celulares pessoais dos funcionários — não para ramais corporativos. Se apresentam como “Carlos do time de infraestrutura” ou “Mariana do suporte”, nomes reais coletados via LinkedIn. O tom é profissional, urgente e específico. Em muitos casos, eles já sabem em qual sistema a vítima trabalha (Salesforce, Okta, Workday, Azure AD), porque pesquisaram antes.
Depois de ganhar confiança, conduzem a vítima para uma página de login falsa. Aqui entra o ponto que devs precisam entender: a página falsa não precisa explorar nenhuma vulnerabilidade técnica. Ela só precisa parecer legítima e capturar o que a vítima digita. O Google identificou que alguns desses grupos mantêm sites próprios onde divulgam invasões bem-sucedidas e chantageiam as vítimas com vazamento de dados — o que tecnicamente se chama “double extortion” e é o mesmo modelo usado por grupos de ransomware como LockBit e BlackCat.
A anatomia técnica de uma página de captura
Quando eu analiso amostras desses ataques em ambientes controlados, vejo três padrões recorrentes. O primeiro é o proxy reverso: a página fake fica no meio da conversa entre a vítima e o servidor legítimo, então a senha digitada é encaminhada ao servidor real — o login funciona, a vítima não desconfia, e o atacante captura tanto a senha quanto o cookie de sessão.
O segundo é o clone estático: uma cópia em HTML/CSS do site original, hospedada em domínio parecido (okta-secure-login.com em vez de okta.com). A vítima digita, recebe um erro genérico, e o atacante usa as credenciais em outro lugar, com mais calma.
O terceiro, mais sofisticado, é a integração com API legítima: o atacante hospeda um pequeno formulário que valida a credencial em tempo real contra a API do provedor real (como Azure AD ou Google Workspace), retornando erros convincentes. Isso é o que o evilginx2 automatiza nativamente e é o motivo pelo qual ele virou item obrigatório em kits de phishing.
Na Prática: o que devs podem fazer para defender aplicações e equipes
- Implementar MFA resistente a phishing (FIDO2/WebAuthn). Chaves físicas como YubiKey ou passkeys绑adas ao dispositivo simplesmente não funcionam em páginas falsas — o desafio criptográfico está atrelado ao domínio real via Origin binding. Se a sua empresa ainda usa TOTP ou push notification como padrão, vocês estão vulneráveis.
- Configurar Conditional Access no Azure AD / Entra ID para bloquear logins vindos de países, redes ou dispositivos incompatíveis com o perfil do usuário. Isso não substitui MFA, mas dificulta bastante o uso de credenciais roubadas.
- Criar cultura de verificação por canal secundário. Se alguém liga dizendo ser do TI e pede credencial, a política deve ser: “desligo, ligo de volta no ramal oficial”. Isso quebra 90% dos ataques de vishing e custa zero em tecnologia.
Para devs que constroem sistemas internos sensíveis, vale implementar telemetria no front-end que colete sinais de possível contexto malicioso. Um exemplo funcional em JavaScript que detecta indícios de iframe malicioso ou proxy reverso:
// Detecção básica de possível phishing via iframe ou proxy reverso
(function detectPhishingContext() {
const signals = [];
// Janela principal controlada por outro frame?
if (window.top !== window.self) {
signals.push('iframe-nesting');
}
// Referrer veio de domínio não confiável?
const referrer = document.referrer;
const allowedDomains = ['minhaempresa.com', 'login.minhaempresa.com'];
const isAllowedReferrer = allowedDomains.some(d => referrer.endsWith(d));
if (referrer && !isAllowedReferrer) {
signals.push('unexpected-referrer');
}
// Verifica se o host atual está em allowlist
const currentHost = window.location.hostname;
const isAllowedHost = allowedDomains.some(d =>
currentHost === d || currentHost.endsWith('.' + d)
);
if (!isAllowedHost) {
signals.push('invalid-host');
}
if (signals.length > 0) {
// Telemetria para o SOC — não bloqueia usuário (UX ruim),
// mas alimenta o pipeline de detecção
navigator.sendBeacon('/api/security/telemetry', JSON.stringify({
signals,
url: window.location.href,
ua: navigator.userAgent,
ts: Date.now()
}));
}
})();
Esse snippet não vai parar um atacante determinado, mas alimenta o SOC com sinais passiveis de correlação com outros eventos. Em produção, eu adicionaria checagem contra listas de domínios maliciosos conhecidos via API (Cloudflare, PhishTank, urlscan.io) e fingerprinting de TLS via JA3 no backend.
Erros Comuns que devs cometem (e que facilitam vishing)
1. Confiar que MFA por SMS é seguro. Não é. SIM swapping, interceptação via SS7 e phishing em tempo real quebram SMS MFA. Em 2026, SMS MFA deveria ser considerado legado. Se o seu IdP ainda usa como fallback, force upgrade para TOTP em app ou, melhor, FIDO2.
2. Não registrar domínios com typosquatting. É comum empresas terem empresa.okta.com legítimo e empresa-okta.com malicioso passando despercebidos. Compre o domínio com typo óbvio e mais 5 a 10 variantes. Custa menos de R$ 500/ano e elimina a maioria das páginas falsas.
3. Expor o organograma no LinkedIn sem filtro. Eu vejo devs colocando “Engenheiro Sênior @ Empresa X” com foto e city. Para um atacante preparando vishing, isso é pesquisa de OSINT pronta. Use pseudônimos em perfis públicos quando possível, ou pelo menos não facilite o trabalho do adversário.
4. Achar que “não sou alvo”. Empresas de private equity pensaram a mesma coisa. Os quatro grupos identificados pelo Google miraram justamente empresas que acreditavam estar “fora do radar”. Qualquer organização com caixa, dados de clientes ou poder de negociação em M&A é alvo válido.
5. Não treinar o time com simulações realistas. Treinamentos genéricos de “não clique em links” não preparam ninguém para uma ligação convincente do “TI”. Plataformas como KnowBe4, Cofense e Hoxhunt oferecem campanhas de vishing simuladas que reduzem drasticamente a taxa de sucesso do ataque real.
O impacto real para devs brasileiros
Mesmo que os ataques reportados tenham sido nos EUA, a técnica não conhece fronteira. Eu já atendi clientes em São Paulo e Recife com tentativas de vishing idênticas — uma delas mirava um time de fintech que usava Okta com push notification. O funcionário quase entregou o código. A diferença entre o “quase” e o “entregou” foi uma política simples: o time tinha combinado que qualquer ligação pedindo credencial deveria ser desligada e o caso reportado.
Se você trabalha com autenticação, SSO, gestão de identidade, ou simplesmente está construindo a próxima aplicação que vai armazenar dados sensíveis, esse cenário é seu. Não é problema do “time de segurança” — é problema de produto. E produto ruim nesse quesito custa caro: a média de resgate pedida por grupos do tipo UNC6671 fica na casa dos milhões de dólares, segundo o relatório do Google.
FAQ — Perguntas que devs realmente fazem
Vishing funciona mesmo com MFA ativo?
Depende do tipo de MFA. Push notification simples e SMS são completamente vulneráveis — o atacante pede o código em tempo real durante a ligação. TOTP resiste melhor porque o código expira em 30 segundos, mas ainda pode ser capturado se a vítima repetir a ação. FIDO2/WebAuthn com chave física ou passkey é o único MFA realmente resistente a phishing, porque o desafio criptográfico está vinculado ao domínio via Origin binding e não pode ser retransmitido.
Como diferenciar uma ligação legítima do TI de um ataque?
Política mais segura: o TI nunca pede credencial por telefone, ponto final. Qualquer ligação pedindo senha, código MFA ou instalação de software deve ser encerrada e o caso reportado imediatamente. O funcionário liga de volta no ramal oficial (nunca no número que o “TI” fornecer durante a ligação). Essa única regra quebra a maioria dos ataques de vishing.
Vale a pena investir em chaves físicas FIDO2 para toda a empresa?
Na minha experiência, sim — especialmente para times com acesso a dados sensíveis ou financeiros. YubiKeys custam em torno de R$ 250-400 cada, muito menos que o custo de uma invasão. Para usuários finais, passkeys sincronizadas via Apple/Google/Microsoft são mais práticas e têm resistência equivalente quando bem implementadas, embora tenham a desvantagem teórica de ficarem acessíveis ao provedor da nuvem.
Como identificar uma página de login falsa se ela é visualmente perfeita?
Sempre olhe a barra de endereço com atenção. Se o domínio não bater 100% com o oficial (incluindo subdomínios), feche. Ative o Enhanced Safe Browsing do Chrome e use um password manager — ele só preenche credenciais no domínio correto, então se não autopreencheu, desconfie. E se algo parecer urgente demais (“sua conta será bloqueada em 5 minutos”), provavelmente é golpe.
Esse tipo de ataque está crescendo no Brasil?
Pelos casos que tenho visto em clientes e pelo que pesquisadores brasileiros publicam em eventos como a BSides Latam e a Roadsec, sim — principalmente contra empresas de médio porte que cresceram rápido e não investiram em identidade na mesma proporção. O relatório do Google focou nos EUA, mas a metodologia é totalmente replicável em qualquer lugar com telefone e internet.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se você lidera um time e quer uma conversa mais aprofundada sobre implementação de FIDO2 ou arquitetura de identidade resistente a phishing, posso ajudar.