Security · 08/06/2026
Social Engineering Continua Funcionando Porque Identidade Não Cobre o Elo Mais Fraco: O Humano
Ataques direcionados a law firms via fake IT support exploram falhas na autenticação de identidade para contatos externos. O problema não é técnico — é arquitetural: perimetros de identidade foram desenhados para máquinas, não para validar legitimidade de comunicação com atores humanos.
O que está acontecendo
O Silent Ransom Group, grupo de extorsão ativo, utiliza uma tática elementar mas devastadora contra law firms e organizações de serviços profissionais: chamadas telefônicas de "IT support" que levam a roubo de dados em horas. Conforme documentado pela Mandiant, esses ataques conseguem não apenas ganhar acesso inicial, mas também estabelecer foothold suficiente para movimentação lateral rápida.
O padrão observado é consistente:
- Contato inicial por telefone ou email impersonando suporte técnico
- Solicitação de acesso remoto ou credenciais através de pretexto técnico
- Validação do acesso por mecanismo social (conversa com funcionário que "confirma")
- Comprometimento de credenciais privilegiadas dentro de horas
A falta de exposição pública de tanques de combustível é o ponto de comparação: enquanto atacantes exploram dispositivos IoT que nunca deveriam estar expostos, o ataque via social engineering explora um espaço que é, por definição, aberto — o contato humano direto.
Insights e Riscos
Validação de identidade unidirecional: Infraestruturas modernas verificam se o usuário é quem diz ser (MFA, certificados), mas não validam se a pessoa que está chamando você é realmente de IT. O fluxo é assimétrico por design arquitetural.
Velocidade de exploração após primeiro contato: Uma vez que o atacante consegue uma credencial válida (não necessariamente privilegiada), a movimentação lateral em ambientes de law firms é rápida. Sem segmentação de rede forte, o dano acontece em janela de tempo que supera SIEM tradicional em detecção.
Confiança baseada em channel, não em identity: A ilusão de segurança vem do fato de a pessoa ligar para um número "conhecido" (spoofing de caller ID) ou usar domínios falsificados. A validação de origem é visual/auditiva, não criptográfica.
Redução de tempo de resposta para exposição de dados: Não é roubo de backup. Esses grupos conseguem acessar sistemas de arquivo compartilhado e iniciar exfiltração enquanto ainda falam com o usuário comprometido. Detecção reativa após 24 horas é inútil.
Trade-off entre acessibilidade e controle: Law firms precisam que suporte técnico seja acessível (chamadas diretas, contato rápido). Toda camada adicional de validação burocrática reduz a capacidade de resposta real a problemas legítimos.
O que muda na prática
Para Arquiteto de Segurança: Implementar validação de origem criptográfica para contatos de suporte técnico não é trivial. Alguns paths:
- Out-of-band verification: Toda solicitação de acesso remoto exige confirmação através de segundo canal verificado (token na conta corporativa, app autenticado). Limita o impacto de social engineering, mas aumenta fricção operacional.
- Zero-trust para support channels: Suporte técnico não pode ser "trusted by default". Mesmo credenciais de suporte entram em sandbox, com movimentação lateral bloqueada até validação adicional.
- Segmentação não-contornável: Dados sensíveis em law firms (client files) devem estar em zona de rede que não pode ser acessada por conta de suporte padrão, mesmo se comprometida.
Para DevOps/SRE:
- Assumir que qualquer conta com acesso remoto será compromised. Tooling de SRE precisa de trail de auditoria que identifique a diferença entre ações de suporte legítimas e movimentação lateral anomalista em minutos, não horas.
- Implementar "session replay" obrigatório para acessos via RDP/SSH de contas de suporte, com retenção de 30 dias mínimo. Reduz dano em comparação com "descoberta post-facto".
Para Líder de Operações/CISO:
- O investimento em "people training" anti-phishing é necessário mas insuficiente. Ataques via social engineering bem executados exploram confiança, não ignorância. Funcionários de law firms sabem o que é segurança; o problema é que um atacante competente consegue contornar isso via manipulação social.
- Políticas de "no remote access from IT" são extremas mas demonstram o trade-off real: se suporte técnico realmente precisa de acesso remoto, então a expectativa de compromisso deve estar embutida no design de resposta a incidentes, não negada.
Conclusão direta
Social engineering contra law firms expõe um gap não resolvido: infraestruturas de identidade moderna validam machines, mas não conseguem validar legitimidade de um human making contact. Enquanto defesas se focarem em bloquear acesso técnico (MFA, condicional access), o atacante simplesmente pula para um channel que ainda depende de confiança humana.
O risco não diminui com mais ferramentas de "threat intelligence". Diminui apenas com mudança arquitetural: assumir comprometimento de qualquer conta com suporte técnico e desenhar segmentação de dados que não dependa de controle de acesso como linha de defesa final.
Pergunta para sua organização: Se uma conta de suporte técnico for comprometida hoje, quantos minutos passam antes que dados sensíveis começam a sair do perímetro? Sua resposta real (não teórica) é quanto tempo você tem para responder.
Fontes
[Fonte: BleepingComputer] Silent Ransom Group targets law firms with fake IT support calls — Mandiant Report [Fonte: darkreading] Exposed Fuel Tank Gauges Under Attack in the US — Tank Gauge Compromise Patterns