Na semana passada, o grupo de ransomware BlackCat (também conhecido como ALPHV) atacou as operações do MGM Resorts e forçou-os a desligar os seus sistemas de TI. O que diferencia esse ataque dos ataques de ransomware mais tradicionais é que, em determinado momento, os invasores conseguiram aproveitar o domínio de seu domínio no ambiente local para comprometer a nuvem. infraestrutura de identidade, coletando senhas em texto não criptografado de usuários do Okta.
O ataque agora se junta a outros – inclusive contra Octa, Uber e Cisco – ao marcar um novo padrão que explora a interconectividade dos ambientes locais e SaaS para comprometer o SaaS através do local. Isto introduz um risco significativo para todas as organizações que hoje possuem um ambiente híbrido (ou seja, empregando um diretório local e um diretório na nuvem) e enfatiza a necessidade de um ambiente unificado. Proteção de identidade abordagem.
Violação MGM: percorrendo as etapas do ataque
A partir de dados disponíveis publicamente, podemos construir o seguinte fluxo:
- Os invasores obtiveram informações no LinkedIn sobre um funcionário, ligaram para o suporte técnico e usaram engenharia social para obter acesso à rede.
- Em seguida, eles realizaram movimento lateral até que obtiveram acesso a um controlador de domínio (os detalhes sobre as técnicas exatas usadas nesta fase permanecem obscuros) e roubaram senhas de usuários armazenadas lá.
- Neste momento, os atacantes pediram o resgate e, quando este foi recusado, instalaram posteriormente ransomware nos servidores ESXi da MGM, depois persistiram em seu movimento lateral até obter acesso ao servidor Okta.
- Uma vez lá, os invasores extraíram senhas em texto não criptografado dos servidores, o que lhes deu a capacidade de fazer login no Okta e acessar qualquer um dos aplicativos SaaS que ele gerencia.
Domínio de domínio local usado como trampolim para o ambiente SaaS
O que é interessante sobre esse ataque é que, embora os hackers tivessem acesso a Active Directory (AD), eles não tinham acesso às senhas. Os invasores usaram o AD para migrar para o Okta e conseguiram roubar senhas em texto simples. Essencialmente, Active Directory serviu como porta de entrada para Okta. Isto destaca a necessidade das organizações identificarem e resolverem quaisquer pontos fracos e configurações incorretas na sua infraestrutura de identidade. Muitas organizações se conectam Active Directory ao Okta, mas muitas vezes ignoram a segurança dessa conexão, o que, neste caso, proporcionou aos invasores uma oportunidade de explorar a fraqueza.
A lacuna crítica da infraestrutura de identidade híbrida: conectada, mas não protegida
Esta violação destaca uma fraqueza inerente que é frequentemente ignorada – a natureza fragmentada e isolada da infraestrutura de identidade no ambiente híbrido. Vamos agora mergulhar nisso com mais detalhes.
A maioria das organizações gerencia seus usuários locais em Active Directory. Paralelamente, eles gerenciam os mesmos usuários em um diretório na nuvem de um servidor de federação (por exemplo, Entra ID, Okta, Ping, etc.). Para permitir que os usuários tenham uma experiência de login perfeita, esses dois provedores de identidade diferentes são sincronizados – o que significa que a mesma combinação de nome de usuário e senha é usada para acessar os recursos locais e SaaS. Além disso, o diretório usado para os aplicativos SaaS geralmente tem alguma presença no ambiente local (por exemplo, o servidor Okta no caso desta violação).
Esta conexão implica que se um invasor conseguir usuário comprometido credenciais no ambiente local, eles podem usá-las para fazer login diretamente em aplicativos SaaS, bem como mover-se lateralmente e comprometer os componentes da infraestrutura de identidade em nuvem no ambiente local.
A exposição do local a ameaças de identidade torna-o o vetor de ataque definitivo para comprometer o SaaS
O recente white paper publicado pela Pesquisa Osterman, “O Estado da Superfície de Ataque de Identidade: Insights sobre Lacunas Críticas de Segurança,” mostra claramente que o ambiente local é criticamente vulnerável ao uso de credenciais comprometidas para acesso malicioso.
Como detalha o relatório, os tradicionais Autenticação multifatorial (MFA) e as soluções Privileged Access Management (PAM) não fornecem proteção suficiente em tempo real contra ameaças de identidade para a grande maioria das organizações.
Os atores da ameaça estão dolorosamente conscientes desses pontos cegos e os aproveitam para realizar movimentos laterais no ambiente local, encontrando pouca ou nenhuma resistência. E o movimento lateral é o fator X que transforma um evento local (como uma única máquina comprometida) num incidente de nível empresarial, como ilustra a violação do MGM.
Conclusão: Proteção de identidade no local é igual à proteção de identidade na nuvem
Qualquer corrente é tão forte quanto o seu elo mais fraco. E o ambiente híbrido é uma cadeia onde o local e a nuvem estão intimamente interligados. Assim, fortalecer o ambiente on-premise significa fortalecer toda a cadeia. Independentemente de quão longe você tenha chegado em sua migração para a nuvem, se você ainda tiver uma parte local, esta é uma exposição séria que você precisa resolver.
Mas como exatamente as organizações podem resolver esta lacuna? Afinal, mesmo antes de existir a nuvem, não existia uma solução de segurança que pudesse mitigar o risco de movimento lateral e preveni-lo em tempo real.
Silverfort Plataforma unificada de proteção de identidade: bloqueando movimentos laterais em tempo real
Silverfort foi pioneira no primeiro Proteção de identidade unificada plataforma desenvolvida especificamente para evitar ameaças de identidade em tempo real em qualquer usuário, sistema e ambiente. Silverfort integra-se à infraestrutura de identidade local e na nuvem para fornecer monitoramento contínuo, análise de risco e controles, como MFA ou bloqueio de acesso em cada autenticação e tentativa de acesso.
Desta forma, Silverfort pode trazer proteção de identidade a recursos que nunca poderiam ter sido protegidos antes. Um exemplo é o acesso a estações de trabalho e servidores por linha de comando por meio de ferramentas como PsExec ou PowerShell remoto. Este tipo de acesso é a forma padrão pela qual os invasores realizam movimentos laterais e está além da cobertura do tradicional Soluções de AMF. Silverfort é a primeira solução capaz de exigir MFA para detectar e bloquear acessos maliciosos deste tipo.
Como funciona o dobrador de carta de canal Silverfort Poderia ter evitado um cenário de ataque semelhante ao MGM
Conforme afirmado anteriormente, não está claro exatamente como os invasores realizaram o ataque de movimento lateral na rede. Mas é provável que Silverfort poderia ter evitado essa violação de duas maneiras:
- Silverfort provavelmente teria detectado o movimento lateral para Active Directory, parando os invasores antes que eles pudessem comprometê-lo.
- Alternativamente, Silverfort provavelmente teria detectado os invasores migrando do AD para o Okta, evitando assim o comprometimento do servidor Okta.
O diagrama abaixo ilustra como Silverforta proteção de teria interrompido o ataque em seus estágios iniciais:
Sua organização possui um ambiente híbrido? Saiba mais sobre como Silverfort pode ajudar a reduzir seu risco. Programar uma chamada com um de nossos especialistas.