Darren Mar-Elia | VP de Produtos

Vista de 10.000 pés:

Muitos de nós estão familiarizados com a variedade de ferramentas, ataques e adversários que se concentram em violar o Active Directory. Com o lançamento em 2018 do DCShadow, outro vector altamente eficaz foi adicionado a essa lista cada vez maior. Para crédito da equipa de investigação, juntamente com a exploração, discutiram como compreender e potencialmente mitigar o ataque com uma maior monitorização e gestão do Active Directory. No entanto, como acontece com muitos dos ataques, não se trata apenas de entender COMO foi atingido... mas de onde. Foi neste ponto que a equipa de investigação da Semperis concentrou alguns esforços recentes. Agora podemos fornecer uma imagem muito mais precisa do cenário empresarial e identificar de forma clara e precisa as máquinas do lado do cliente que foram ou estão a utilizar a ferramenta de ataque contra o Active Directory da sua organização.

Antecedentes:

Mimikatz, a ferramenta de exploração de credenciais, fornece um recurso chamado "DCShadow". Pode pensar-se no DCShadow como fazendo o oposto do comando DCSync. Enquanto que o DCSync pode forçar o Active Directory (AD) a sincronizar as contas de utilizador e os seus hashes de palavra-passe para um atacante, o DCShadow permite a um atacante injectar alterações no AD. Isto é feito através da simulação do comportamento de um controlador de domínio, que é essencialmente qualquer máquina comprometida dentro de um domínio do Active Directory. Vale a pena notar que o DCShadow é uma ferramenta de persistência de domínio. Requer que o atacante já tenha acesso de Administrador de Domínio, ou equivalente, num domínio AD antes de poder ser utilizado. No entanto, uma vez atingido esse nível de acesso, é uma ferramenta poderosa e silenciosa para criar e actualizar objectos no AD com o objectivo de criar backdoors, elevar o acesso a contas regulares e estabelecer uma base de apoio e controlo de execução no ambiente visado.

Detectabilidade

A parte difícil do DCShadow é que, uma vez que contorna os mecanismos normais através dos quais as alterações ao AD são auditadas (ou seja, normalmente feitas através do registo de eventos de segurança do Windows nos controladores de domínio), não é possível detectar facilmente quando está a ser utilizado. Além disso, se o atacante estiver a efectuar alterações furtivas que não estejam a ser procuradas (por exemplo, injectar o SID dos administradores da empresa no atributo sidHistory de um utilizador sem privilégios), pode ser muito difícil detectar estas backdoors. É possível ver pistas que podem apontar para a sua utilização - por exemplo, quando o DCShadow é executado, um objecto da classe server é temporariamente adicionado ao contexto de nomeação da configuração numa determinada floresta, para fazer com que outros controladores de domínio pensem que o servidor falso é um DC real. Mas esse objecto é rapidamente removido quando o DCShadow termina a sua execução. Felizmente para o defensor, acontece que o DCShadow deixa algumas impressões digitais para trás quando é executado num anfitrião.

Descobrindo o uso do DCShadow

Em primeiro lugar, um pouco de história. Um controlador de domínio "normal" regista uma série de SPNs (Service Principal Names) Kerberos quando é promovido a um DC. Um deles é um SPN baseado em GUID, como mostrado aqui:

Esse SPN baseado em GUID tem uma característica interessante. Se olharmos para ele com atenção, vemos que existem de facto dois GUIDs no SPN. O primeiro, nomeadamente, E3514235-4B06-11D1-AB

04-00C04FC2DCD2, é o que é conhecido como um GUID conhecido (WKGUID) e é registado por todos os controladores de domínio em todas as florestas AD da mesma forma. O segundo GUID, no nosso exemplo aqui: 8b699bb0-d35e-4199-8dd4-6a296c5fc7db, é exclusivo de um determinado DC.

[semperis-mid-scroll-cta]

Então, como é que isto nos ajuda na detecção do DCShadow? Bem, acontece que quando o DCShadow é executado em um determinado host, ele adiciona alguns SPNs a essa máquina para fazer com que outros DCs pensem que é um DC. Um deles é o SPN baseado em WKGUID. Infelizmente, o que ele não faz é limpar-se a si próprio quando termina a execução (felizmente, um DCShadow confuso). O resultado é que qualquer anfitrião que tenha executado o DCShadow continua a armazenar o WKGUID SPN no atributo servicePrincipalName na sua conta de máquina.

Pode ver um exemplo disso na segunda imagem de ecrã abaixo. Neste exemplo, executámos o DCShadow repetidamente a partir deste anfitrião - repare na quantidade de SPNs WKGUID que aparecem na lista:

A boa notícia aqui é que podemos usar essas informações para distinguir hosts no AD que executaram o DCShadow. Primeiro, sabemos que apenas os DCs *legítimos* devem ter este SPN WKGUID na sua conta de máquina. Isso é bastante fácil de procurar, mas podemos restringir ainda mais a nossa pesquisa procurando também outro SPN que sabemos que NÃO DEVERIA estar em qualquer máquina que não seja um DC legítimo. O resultado que obtivemos é a seguinte Consulta LDAP:

"(&(objectClass=computer)(servicePrincipalName=E3514235-4B06-11D1-AB04-00C04FC2DCD2*)(!(servicePrincipalName=ldap*)))"

Esta consulta procura todos os objectos de computador, cujo atributo SPN contém o SPN WKGUID (estamos a utilizar um wildcard aqui para excluir a parte GUID exclusiva desse SPN) E não inclui o SPN LDAP, que todos os DC legítimos contêm.

De acordo com a natureza furtiva do DCShadow, o acto de adicionar este WKGUID SPN à conta de máquina do DC falso não é registado no registo de eventos de segurança no DC real que recebe o pedido de replicação do DC falso.

Resumo

Partindo do princípio de que o DCShadow não vai "limpar o seu acto" tão cedo, esta detecção permite-nos chegar rapidamente a quaisquer máquinas que estejam a ser utilizadas para alojar injecções DCShadow, colocá-las em quarentena de forma adequada e executar processos forenses e de IR completos ANTES de poderem causar mais danos.

Demonstração do ataque DCShadow

O DCShadow explora um interruptor no utilitário Mimikatz que permite que utilizadores privilegiados injectem alterações maliciosas no Active Directory sem serem detectados. Assista a esta apresentação em vídeo para saber como detectar controladores de domínio desonestos, reverter rapidamente alterações indesejadas e restaurar a visão do seu SIEM. Se tiver alguma dúvida, não hesite em contactar o pessoal da Semperis.