Sempre defendemos a ameaça iminente de violações e propagamos a mensagem de que, independentemente do tamanho do seu negócio, do setor em que você atua ou da sua localização geográfica, você pode estar sujeito a uma violação de segurança. E, infelizmente, a história se repete com frequência.
Em 11 de maio de 2020, a Nippon Telegraph & Telephone (NTT), uma grande empresa de telecomunicações, revelou que os invasores podem ter roubado dados de seus sistemas internos, afetando mais de 600 clientes.
O hack ocorreu em 7 de maio de 2020, e a NTT detectou a intrusão somente no dia 11 de maio.
Como aconteceu
A empresa acredita que os hackers começaram a partir de uma base da NTT em Cingapura, usaram esse ponto de entrada para acessar um servidor em nuvem localizado no Japão (Servidor B), mudaram para um servidor na rede interna da NTT Communication (Servidor A) e, em seguida, acessaram o servidor do Active Directory ( AD).
O ataque foi em um ambiente híbrido (local e nuvem) que é semelhante à configuração de TI da maioria das empresas. A NTT afirma que várias “ferramentas de multi-ataque”, bem como inteligência artificial e táticas de machine learning, foram utilizadas para conduzir o ataque.
Embora o método real de ataque e as ferramentas usadas ainda não estejam claras, para entender melhor o caminho tomado, replicamos como os hackers poderiam ter passado de servidor para servidor em nosso laboratório. O objetivo deste post é cobrir as possíveis maneiras pelas quais o ataque poderia ter acontecido, te ajudando a construir uma estratégia de defesa eficaz e prevenir que um ataque do tipo aconteça.
Fase 1: Invasão
O ponto de entrada para a violação foi uma base da NTT em Cingapura. Os endpoints de uma organização, especialmente suas estações de trabalho, são frequentemente o principal ponto de entrada na maioria dos ataques. Eles têm controles de segurança mais baixos e geralmente não armazenam dados confidenciais, mas ainda fazem parte da rede, o que os torna um local ideal para invasões.
A invasão pode ter ocorrido de várias maneiras – pode ter sido um ataque onde a senha foi adivinhada por sistema externo, um trojan de acesso remoto injetado por meio de uma unidade removível ou um ataque de phishing clássico usando a pandemia como isca, onde o anexo baixado aloja um malware no sistema da vítima (por exemplo, o registro do Windows).
Para realizar a intrusão, reunir as informações do domínio de destino (como endereços de e-mail para um ataque de phishing) é crucial. Ferramentas do Windows como o PowerShell podem ajudar na coleta de informações e execução de ataques.
Fase 2: Escalada e movimento lateral
Após a infecção inicial, os invasores procuram escalar os privilégios para adquirir acesso a um sistema superior na hierarquia da rede, aproximando-se assim de seu objetivo de alcançar os dados confidenciais da empresa.
Esta é a fase em que os invasores pesquisam o domínio para obter informações valiosas sobre o alvo e planejam suas mudanças para escalar o acesso aos servidores de negócios que contêm dados confidenciais. Abaixo está uma ilustração que descreve o padrão de escalonamento na violação da NTT.
Como estamos tentando replicar o padrão de ataque da violação da NTT, tentaremos obter acesso ao servidor em nuvem (Servidor B), depois ao servidor interno (Servidor A) e, eventualmente, ao servidor AD. Assim como o ambiente da NTT, nosso laboratório tem um servidor AD local e um servidor em nuvem (Azure AD).
Acesso ao servidor em nuvem (Servidor B):
A primeira etapa é obter acesso ao servidor em nuvem. É importante observar que a estação de trabalho do usuário incluída durante a fase de intrusão pode ou não ter acesso ao servidor nuvem.
Utilizar ferramentas gratuitas da Internet ou pesquisar mídias sociais pode ajudar a encontrar os usuários que trabalham na organização e seus nomes de usuário em potencial, ou seja, seus e-mails. O script Python na imagem abaixo pode ajudar a determinar a validade dos endereços de e-mail.
Agora que temos uma lista de endereços de e-mail potencialmente válidos, vamos juntar isso a um clássico ataque de spray de senha.
A probabilidade de que nenhum usuário na organização use uma senha comum é muito baixa. Os ataques de senha podem ser reprojetados e conduzidos em vários tipos de serviços em nuvem, incluindo Azure AD e Google G Suite.
Acesso ao servidor interno de produção (Servidor A):
Com o acesso ao Servidor B, a próxima etapa é escalar de alguma forma os privilégios e obter acesso ao Servidor A, que está em contato próximo com o servidor AD.
A maioria das organizações que executam implantações em nuvem no local tem dois tipos de identidades de usuário na nuvem: identidades sincronizadas e apenas na nuvem. Tanto usando as ferramentas da GUI ou executando alguns comandos em um shell de linha de comando, é possível determinar as identidades que são sincronizadas com os ambientes locais, o que significa que alguns dos usuários na nuvem podem ter acesso ao Servidor A . Este é o resultado com um provedor de nuvem como o Azure AD.
O invasor pode usar os detalhes do usuário obtidos para conduzir um ataque de força bruta de senha automatizado e obter acesso ao Servidor A, de onde eles podem tentar obter acesso ao servidor AD.
Ataque de força bruta em identidades de usuário sincronizadas
Extraindo as chaves do reino (servidor AD):
Como o Servidor A é um servidor de produção (o que significa que é privilegiado), existem muitas maneiras de obter acesso ao servidor AD a partir dele:
-
Há uma boa chance de que a conta do administrador usada para configurar o Servidor A também tenha sido usada para configurar o servidor AD. Ou, pelo menos, as senhas das contas de administrador em ambos os servidores podem ser as mesmas. Um invasor pode simplesmente tentar várias combinações de senha na conta do administrador e reproduzir a senha no servidor AD se for considerada válida.
-
O invasor também pode optar por uma abordagem mais furtiva, extraindo senhas de um despejo de memória (LSASS) do Servidor A.
-
O invasor pode ler o registro para encontrar informações salvas de sessões remotas (RDP, FileZilla, SuperPuTTy) e extrair as senhas de usuários que podem ter acessado remotamente o servidor AD do Servidor A.
Extraindo senhas do LSASS:
É possível gerar um arquivo de despejo do LSASS usando o Gerenciador de Tarefas ou outras ferramentas do sistema Windows. O arquivo pode então ser copiado e extraído do sistema do invasor para obter as senhas do usuário.
Extraindo senhas de ferramentas remotas:
Os invasores podem aproveitar os scripts do PowerShell disponíveis publicamente para localizar e descriptografar informações de sessão salvas de ferramentas de acesso remoto. O registro HKEY_USERS é consultado para todos os usuários que fizeram logon em uma caixa associada a um domínio em algum ponto. Por exemplo, se os usuários do Servidor B acessaram remotamente o Servidor A, a consulta à chave de registro do Servidor B pode nos fornecer as informações confidenciais salvas da sessão remota (como nomes de contas de usuários e senhas em texto não criptografado).
Adicionar entradas de backdoor ao servidor AD:
Se a conta do usuário comprometida pelo ataque de força bruta no Servidor A for um usuário privilegiado, o privilégio pode ser explorado para adicionar entradas de backdoor no servidor AD usando um aplicativo de instalação do Windows.
Depois que as credenciais são descobertas ou uma entrada de backdoor é injetada no AD, basicamente recebemos as chaves do reino – o jogo acabou. Podemos transferir os dados confidenciais do domínio para um servidor remoto.
Embora a NTT tenha interrompido seus servidores e bloqueado a comunicação com o servidor AD assim que o ataque foi descoberto, já era tarde demais. A NTT descobriu em 11 de maio que outro servidor, o Servidor C, foi comprometido por meio do Servidor B, e a empresa percebeu que os dados pessoais de 621 clientes haviam sido vazados.
O padrão de ataque acima pode não ser uma réplica exata do que aconteceu durante a violação, mas ainda esclarece o fato de que cada organização, seja executando AD local, serviços em nuvem ou mesmo uma fusão de ambos, está em risco significativo.
Infelizmente, as ferramentas de auditoria nativas são muito limitadas em seus recursos e não possuem monitoramento avançados o suficiente para detectar tais ataques sofisticados. E o fato de que os invasores passam rapidamente entre vários servidores, estações de trabalho e outros endpoints torna a auditoria de AD híbrido uma tarefa extremamente desafiadora.
Com o ManageEngine Log360, você pode monitorar seus servidores membros, serviços em nuvem, estações de trabalho e servidores AD, 24 horas por dia, em busca de atividades maliciosas ou confidenciais. Seus relatórios ajudam a monitorar:
- Padrões de logon (por exemplo, os servidores acessados durante o ataque, o tipo de logon e quais usuários se conectaram e de onde).
- Novas criações de processos em servidores.
- Padrões anômalos, como logons em horários incomuns ou um usuário acessando um servidor pela primeira vez.
- Alterações avançadas de AD (por exemplo, scripts maliciosos usados, modificações de arquivos e pastas e alterações de registro).
- Mudanças em serviços de nuvem como Azure, AWS e Google Cloud.
Além disso, com a capacidade de configurar alertas personalizados e mitigar danos instantaneamente desligando dispositivos, encerrando sessões de usuário ou realizando mais ações com base nos scripts configurados, você pode ter certeza de que todas as alterações sensíveis são notificadas e executadas.
Baixe uma versão de teste do Log360 agora e certifique-se de que a história não se repita novamente.
Nota : Esse conteúdo foi traduzido do nosso site em inglês e está replicado nos sites dos nossos parceiros também.
