Sempre falamos sobre a ameaça iminente de violações e propagamos a mensagem de que, independentemente do tamanho da sua empresa, do setor em que você atua ou da sua regiã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), a grande empresa de telecomunicações japonesa, 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 invasão em 11 de maio.
A empresa acredita que os hackers começaram a partir da base da NTT em Cingapura e 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 acessaram o Active Directory (AD).
O ataque ocorreu em um ambiente híbrido (local e na nuvem), semelhante à configuração da TI da maioria das empresas. A NTT alega que várias “ferramentas multi-ataque”, bem como inteligência artificial e táticas de aprendizado de máquina foram aproveitadas para conduzir o ataque.
Embora o método real de ataque e as ferramentas usadas ainda não sejam claros, para entender melhor o caminho do ataque, replicamos como os hackers poderiam ter passado de servidor para servidor no ambiente da NTT em nosso laboratório. Nosso objetivo nesse post, é cobrir as possíveis maneiras pelas quais o ataque poderia ter acontecido, ajudando você a criar uma estratégia de defesa eficaz.
Etapa 1: Intrusão
O ponto de entrada para a violação foi uma base da NTT em Cingapura. Os endpoints de uma organização, especialmente suas workstations, costumam ser 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 dos negócios, mas ainda fazem parte da rede, o que os torna um ponto ideal para invasões.
A invasão pode ter ocorrido de várias maneiras – pode ter sido um ataque de adivinhação de senha de um sistema externo, um cavalo de Troia de acesso remoto injetado por uma unidade removível ou um ataque de phishing clássico usando a pandemia de coronavírus como isca, onde com anexo baixado é hospedado malware no sistema da vítima (por exemplo, o registro do Windows).
Para realizar a invasão, é crucial reunir as informações do domínio de destino (como endereços de e-mail para um ataque de phishing). Ferramentas do Windows como o PowerShell podem ajudar na coleta de informações e na execução de ataques.
Etapa 2: Escalada e movimento lateral
Após a infecção inicial, os invasores procuram escalar privilégios para obter acesso a um sistema mais alto na hierarquia da rede, aproximando-se assim do objetivo de alcançar os dados confidenciais da empresa.
Essa é a fase em que os invasores pesquisam o domínio para obter informações ricas em destinos e planejam suas ações para aumentar o acesso aos servidores de negócios que mantêm dados confidenciais. Abaixo está uma ilustração que mostra o padrão de escalação 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 possui um servidor AD local e um servidor em nuvem (Azure AD).
Acesso ao servidor de nuvem (servidor B):
A primeira etapa é obter acesso ao servidor em nuvem. É importante observar que a workstation do usuário composta durante a fase de intrusão pode ou não ter acesso ao servidor em nuvem.
A utilização de ferramentas gratuitas da Internet ou a pesquisa nas mídias sociais pode ajudar a encontrar os usuários que trabalham na organização e seus nomes de usuário em potencial, como também seus e-mails. O script Python na captura de tela abaixo pode ajudar a determinar a validade dos endereços de e-mails.
Agora que temos uma lista de endereços de e-mails potencialmente válidos, vamos associá-los a um ataque clássico de pulverização de senha.
A probabilidade de nenhum usuário da organização usar uma senha trivial é bastante baixa. Os ataques de senha podem ser reprojetados e conduzidos em vários tipos de serviços em nuvem, incluindo o Azure AD e o Google G Suite.
Acesso ao servidor de produção interno (Servidor A):
Com o acesso ao Servidor B, a próxima etapa é, de alguma forma, escalar 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 de nuvem ao lado do local possui dois tipos de identidades de usuário na nuvem: identidades sincronizadas e somente na nuvem. Usando as ferramentas da GUI (Graphical User Interface) 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 .
Veja a aparência da saída com um provedor de nuvem como o Azure AD.
O invasor pode usar os detalhes do usuário obtidos para realizar um ataque automatizado de força bruta por senha e obter acesso ao Servidor A, de onde eles podem tentar obter acesso ao servidor AD.
Extraindo as chaves (servidor AD):
Como o Servidor A é um servidor de produção (o que significa que é privilegiado), há muitas maneiras de obter acesso ao servidor AD e a partir dele:
- Há uma boa chance de que a conta de administrador usada para configurar o Servidor A também tenha sido usada para configurar o servidor AD. Ou, no mínimo, as senhas das contas de administrador nos dois servidores podem ser as mesmas. Um invasor pode simplesmente tentar várias combinações de senhas na conta de administrador e repetir 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 dump de memória (LSASS) do Servidor A.
- O invasor pode ler o registro para encontrar informações salvas das sessões remotas (RDP, FileZilla, SuperPuTTy) e extrair as senhas dos 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 de despejo pode ser copiado e extraído do sistema do invasor para obter senhas de usuário.
Extraindo senhas de ferramentas remotas:
Os invasores podem aproveitar os scripts do PowerShell disponíveis ao público para localizar e descriptografar as informações salvas da sessão nas ferramentas de acesso remoto. O registro HKEY_USERS é consultado para todos os usuários que fizeram logon em uma caixa ingressada no domínio em algum momento. Por exemplo, se os usuários do Servidor B acessaram remotamente o Servidor A, a consulta da chave do Registro do Servidor B pode fornecer informações confidenciais salvas da sessão remota (como nomes de contas de usuário e senhas em texto não criptografado).
Adicionando entradas de backdoor ao servidor AD:
Se a conta de usuário comprometida pelo ataque de força bruta no servidor A for um usuário privilegiado, o privilégio poderá ser explorado para adicionar entradas backdoor ao servidor AD usando um aplicativo instalador do Windows.
Depois que as credenciais são descobertas ou uma entrada backdoor é injetada no AD, o jogo acabou. É possível transferir os dados confidenciais do domínio para um servidor remoto.
Embora a NTT tenha parado seus servidores e bloqueado a comunicação com o servidor AD assim que o ataque foi descoberto, era tarde demais. Mais tarde, a NTT descobriu em 11 de maio que outro servidor, o Servidor C, estava comprometido por meio do Servidor B, e a empresa percebeu que os dados pessoais de 621 clientes haviam vazado.
O padrão de ataque acima pode não ser uma réplica exata do que aconteceu durante a violação da NTT, mas ainda esclarece o fato de que toda 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 recursos de monitoramento avançados o suficiente para detectar ataques sofisticados. E o fato de os invasores atravessarem rapidamente entre vários servidores, workstations e outros endpoints torna a auditoria do AD híbrido uma tarefa extremamente desafiadora.
Com o Log360 da ManageEngine, você pode monitorar seus servidores membros, serviços em nuvem, workstations e servidores AD o tempo todo quanto a atividades maliciosas ou sensíveis. 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 efetuaram login e de onde).
- Novas criações de processos nos 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 do AD (por exemplo, scripts maliciosos usados, modificações de arquivos e pastas e alterações no registro).
- Alterações nos serviços de nuvem, como Azure, AWS e Google Cloud.
Além disso, com a capacidade de configurar alertas personalizados e reduzir instantaneamente os danos, desligando dispositivos, encerrando sessões do usuário ou executando mais ações com base nos scripts configurados, você pode ter certeza de que todas as alterações confidenciais são notadas e acionadas.
Saiba mais sobre o Log360 da ManageEngine e solicite agora mesmo seu teste gratuito.
Conheça na prática e na realidade de sua empresa o que nossas soluções ACSoftware|ManageEngine podem fazer por você. Contamos com um portfólio extenso para gerenciamento de TI.
Com soluções para segurança de TI, gerenciamento de acesso e identidade (Active Directory), gerenciamento de endpoints, IT help desk e gerenciamento de serviços de TI (monitoramento de rede, banda e análise de tráfego), gerenciamento de operações de TI (Network e Server), gerenciamento de aplicativos e muito mais.
Conte sempre com o apoio da equipe ACSoftware, sua revenda e suporte ManageEngine no Brasil.
Participe agora mesmo do grupo TIMEBRA dedicado aos usuários ManageEngine no Brasil, que tem a intenção de criar uma comunidade para troca de experiências, esclarecer dúvidas, bem como ficar por dentro de dicas e novidades.
ACSoftware revenda e distribuidora ManageEngine no Brasil. – Fone / WhatsApp (11) 4063 9639.
PodCafé da TI – Podcast, Tecnologia e Cafeína.
