Cisco atacada através da conta Google pessoal de um funcionário: a centralização acidental que ninguém vê

San José, Em agosto de 2022, a Cisco confirmou uma intrusão na sua rede depois de o grupo de ransomware Yanluowang publicar uma lista de ficheiros alegadamente roubados. A análise da equipa de threat intelligence da própria empresa revelou um ponto de partida que devia fazer soar alarmes em qualquer organização: o ataque não começou em nenhum sistema da Cisco.

O ponto de entrada: uma conta pessoal

O comprometimento inicial foi a conta Google pessoal de um funcionário. Essa conta tinha credenciais guardadas e sincronizadas a partir do browser, incluindo credenciais de acesso a sistemas da empresa. Ao controlar a conta pessoal, o atacante, que se acredita ser um initial access broker ligado a um grupo de ransomware, herdou as chaves de entrada no mundo profissional da vítima.

Faltava o segundo fator. Para o contornar, o atacante combinou duas técnicas: MFA fatigue, inundando o dispositivo do funcionário com pedidos de aprovação na esperança de que aceitasse um para fazer parar o ruído; e chamadas de vishing, em que interlocutores se faziam passar por organizações de suporte de confiança para pressionar a aprovação. A tática funcionou, e o atacante ganhou acesso à VPN da empresa.

A «centralização acidental»: o cofre que ninguém decidiu criar

O caso Cisco ilustra um fenómeno que raramente aparece nas políticas de segurança das empresas: a centralização acidental de credenciais. Ninguém decidiu «vamos guardar os acessos da empresa na conta Google pessoal do colaborador». Aconteceu sozinho, o browser ofereceu-se para guardar a password, a sincronização estava ativa, e a partir daí as credenciais corporativas passaram a viver num sítio que a empresa não vê, não gere e não consegue proteger.

É o mesmo padrão do caso Retool (onde o Google Authenticator sincronizou os seeds TOTP para a nuvem) e o mesmo padrão de milhares de equipas pequenas: códigos 2FA em apps pessoais, screenshots em pastas privadas de Drive, seeds no telemóvel de quem configurou a conta há dois anos e entretanto saiu. O perímetro de segurança da empresa passa a incluir, sem ninguém saber, as contas pessoais de cada colaborador, e a segurança do todo desce ao nível da conta pessoal menos protegida.

A lição: saber onde vivem as credenciais é metade da segurança

Três conclusões práticas para equipas:

1. Faz um inventário honesto. Onde estão, hoje, os seeds TOTP das contas partilhadas da tua equipa? Se a resposta é «no telemóvel do João» ou «não sei ao certo», tens o mesmo perfil de risco da Cisco, sem a equipa de resposta a incidentes da Cisco.
2. Separa o pessoal do profissional por arquitetura, não por boa vontade. Credenciais e códigos de trabalho devem viver num sistema da organização, com acessos individuais, registo e revogação, nunca em contas pessoais que a empresa não controla.
3. Trata pedidos de aprovação MFA inesperados como incidentes. Uma enxurrada de notificações não é um bug: é alguém com a tua password a tentar entrar. A regra de equipa deve ser recusar, reportar e trocar a credencial, nunca aprovar «para parar».

Quando as chaves da empresa vivem em sítios que a empresa não conhece, não é uma questão de se alguém as encontra primeiro. É uma questão de quando.