Uma chamada de 10 minutos parou os casinos de Las Vegas: o ataque de 100 milhões à MGM
Os atacantes não exploraram nenhuma vulnerabilidade técnica: pesquisaram um funcionário no LinkedIn, ligaram ao help desk da MGM e pediram um reset de password e de MFA. Funcionou, e custou cerca de 100 milhões de dólares.
Las Vegas, Em setembro de 2023, os hóspedes dos hotéis da MGM Resorts fizeram check-in com papel e caneta. As slot machines estavam desligadas, as chaves digitais dos quartos não funcionavam e os sistemas de restauração estavam em baixo. Durante quase duas semanas, um dos maiores grupos hoteleiros do mundo operou como nos anos 80, com um prejuízo estimado em cerca de 100 milhões de dólares.
A causa não foi um exploit sofisticado nem uma vulnerabilidade por corrigir. Foi uma chamada telefónica.
O ataque: LinkedIn + uma chamada ao help desk
O grupo Scattered Spider, associado ao ransomware ALPHV/BlackCat, começou por fazer o trabalho de casa: recolheu informação sobre funcionários da MGM em perfis públicos do LinkedIn e em bases de dados de fugas anteriores. Com esses dados, escolheu um funcionário para personificar.
Depois, ligou ao help desk de TI da MGM a fazer-se passar por esse funcionário. Respondeu às perguntas de verificação, construídas sobre informação que qualquer pessoa consegue encontrar online, e convenceu o agente a redefinir a password e os fatores de MFA da conta. Segundo a Okta, o padrão destes atacantes era pedir explicitamente o reset de todos os fatores de autenticação da conta-alvo; quando confrontados com o pedido de aprovação MFA, alegavam ter perdido o acesso à app de autenticação.
Com credenciais legítimas e MFA acabado de configurar pelos próprios atacantes, o grupo entrou no ambiente Okta da MGM, o fornecedor de identidade que dava acesso, por single sign-on, a praticamente toda a infraestrutura da empresa. A partir daí: movimento lateral, exfiltração de dados e ransomware.
Porque funcionou
O processo de reset do help desk existia por uma razão legítima: ajudar utilizadores que perderam a password ou o telemóvel. Mas assentava em verificação por conhecimento, perguntas cuja resposta estava no LinkedIn. E, por configuração, o help desk podia redefinir MFA até de contas altamente privilegiadas.
O resultado: o fator "algo que tens" podia ser anulado por alguém que apenas sabia coisas. Todo o investimento em MFA valia o que valia a chamada mais convincente da semana.
A lição para equipas de qualquer dimensão
É tentador ler este caso como um problema de grandes empresas com help desks anónimos. Mas o mecanismo é universal, e nas equipas pequenas é ainda mais informal:
- Quem pode "resetar" o 2FA na tua equipa? Se a resposta é «qualquer pessoa a quem se peça no Slack», o teu help desk é toda a equipa, sem guião, sem verificação, sem registo.
- A recuperação de acesso é a porta traseira do MFA. De nada serve um segundo fator forte se um pedido bem contado consegue substituí-lo. Os processos de recuperação devem exigir verificação mais forte do que o login normal, não mais fraca, callback para números registados, aprovação de segunda pessoa para contas privilegiadas.
- Regista tudo. A MGM demorou a perceber o alcance do ataque. Num sistema com registo individual de acessos e alterações de MFA, um reset inesperado numa conta privilegiada é um alerta imediato, não uma descoberta forense.
Uma chamada de dez minutos contra 100 milhões de dólares de prejuízo. A pergunta que este caso deixa a qualquer gestor é simples: se alguém ligar hoje à tua equipa a pedir «acesso à conta partilhada porque perdi o telemóvel», o que é que acontece?
Partilhe 2FA na equipa sem repetir estes erros.
Códigos por SMS (número SIM real) e de apps (TOTP) num só painel, com acesso por serviço, expiração e auditoria.
Reservar o meu lugar