O blog da segurança de dentro para fora Blog   /  

Este SID está disponível? O Varonis Threat Labs descobre ataque de injeção de SID sintético

Este SID está disponível? O Varonis Threat Labs descobre ataque de injeção de SID sintético

Os pesquisadores do Varonis Threat Labs descobriram uma técnica em que agentes de ameaças com privilégios elevados podem injetar SIDs sintéticos em uma ACL (Lista de Controle de Acesso) do Active Directory. Isso cria um cenário em que backdoors aparecem e permissões são concedidas de maneira oculta quando uma nova conta é criada com um SID legítimo correspondente.

Esse ataque é possível pelas seguintes razões:

  • Os SIDs são fáceis de adivinhar, pois são atribuídos em grande parte de forma consecutiva
  • O Active Directory não verifica se o SID aplicado a uma ACL é válido ou não

Chamamos os SIDs que seguem as regras de formatação de SIDs legítimos, mas que ainda não fazem referência a um objeto, de “sintéticos”.

Background

O sistema de permissões do Active Directory é composto de três partes:

  1. Curadores: objetos que têm permissões aplicadas. Geralmente, são contas de usuário, grupos e contas de computador.
  2. Identificador de segurança (SID): no Active Directory, as entidades de segurança são identificadas por um identificador de segurança (SID). O SID é um identificador exclusivo que representa qualquer entidade que possa ser autenticada pelo sistema operacional. Pode ser comparado com um número de previdência social ou um número de identidade de cidadão, mas dentro do escopo de um objeto de domínio. O SID é emitido por um controlador de domínio e atribuído a um objeto quando ele é criado. Não pode ser reutilizado ou usado para identificar outra entidade.
  3. Lista de Controle de Acesso (ACL): é o mapeamento entre um objeto (SID) e permissões no Active Directory.

Sem verificação do SID

Ao criar uma ACL, não verificamos se o SID dos curadores existe no domínio. Devido a essa falta de verificação, alguém com permissões suficientes poderia adicionar um SID sintético inexistente a uma ACL.

Esses SIDs inexistentes (sintéticos) com permissões de ACL persistem inofensivamente nos ACLs até que uma nova conta de usuário ou computador seja criada e atribuída ao SID sintético anterior. Essas novas contas herdam no mesmo instante as permissões de ACL concedidas anteriormente.

Como examinar uma ACL

Para ver o ACL de um objeto, basta acessar a aba “Segurança”:

img1

O Windows resolve o SID da entrada e apresenta o nome de usuário para facilitar a leitura. No entanto, em segundo plano, a ACL identifica o usuário por meio de seu SID definido pelo formato SDDL (mais informações sobre SDDLs aqui https://docs.microsoft.com/pt-br/windows/win32/secauthz/security-descriptor-string-format).

Injetar um SID sintético em uma ACL

Como o Windows não verifica se existem SIDs no domínio ao criar uma ACL, é possível inserir nosso SID sintético na ACL de qualquer objeto sobre a qual temos privilégios:
img2
Observação: a seção de domínio do SID é editável, mas a parte “S-1-5-21” não é.
O SID sintético desta captura de tela:
  • Não pode ser resolvido (“Conta desconhecida”) porque não foi atribuído
  • É válido para entrada ACL
Obter controle sobre um SID existente não é fácil, pois os SIDs não podem ser retirados de outros usuários ou reutilizados. No entanto, ao mapear a lista de SIDs atualmente existentes no domínio, é possível saber sob quais SIDs novos usuários serão criados. Isso nos permite criar um cenário em que uma conta recém-criada herda nossas permissões injetadas.

Podemos mapear os SIDs existentes com o PowerShell:

(([adsisearcher]"(objectSid=*)").FindAll()).Properties.objectsid | ForEach-Object {(New-Object System.Security.Principal.SecurityIdentifier($_,0)).Value}

O SID na imagem a seguir não está vinculado a nenhuma conta e é o próximo SID disponível no domínio. Foi concedido “Controle Total” sobre o objeto “Usuários de Gerenciamento Remoto”:
img3
Criamos uma conta chamada “ThisIsMySID” e ela assumiu o SID:
img4
O usuário “ThisIsMySID” agora tem controle total sobre o objeto de grupo.

É importante notar que esse truque também funciona para atribuir privilégios e direitos do Windows, como SeDebugPrivilege, SeRemoteInteractiveLogonRight ou outras constantes de privilégio.

 

EXPLORAÇÃO

Blog_SyntheticSIDAttack_Diagram_202203_V2

Aqui, o principal vetor de exploração é a persistência. Os agentes de ameaças com controle sobre o domínio podem adicionar permissões e privilégios a SIDs futuros e reaparecer criando uma nova conta de usuário ou computador.

Criar uma conta não é realmente um problema se você já tiver controle sobre uma conta de usuário comum. Como padrão, os usuários autenticados podem criar até 10 contas de computador, que também recebem SIDs, da mesma forma que os usuários-padrão, o que torna essa exploração possível.

Cenário de exploração do DCSync

Ao adicionar um SID ao objeto de domínio e conceder privilégios de sincronização (necessários em um ataque DCSync), o agente da ameaça planta um backdoor. Obviamente, você pode adicionar vários SIDs para garantir que um único SID não seja substituído pelas atividades diárias.


Para recuperar a posição, o agente da ameaça teria que conseguir controlar uma conta de usuário padrão (possível via phishing) e usar essa conta para criar uma conta de computador:

 


A conta recém-criada substituirá um dos SIDs disponíveis e terá permissões DCSync.

replacing-sid

Remediação e monitoramento

A Microsoft não considera isso um problema de segurança. No entanto, o monitoramento ainda é recomendado, pois atribuir SIDs sintéticos é um comportamento incomum.

Recomenda-se monitorar os comportamentos a seguir para mitigar esse risco.

  • Alertas sobre alterações incomuns de privilégios, atribuições de direitos e permissões concedidas em ambientes do Active Directory, sejam elas executadas automaticamente por meio de scripts ou malware ou manualmente por uma ameaça ativa.
  • Modelagem baseada em comportamento (como a oferecida pela Varonis) em objetos sensíveis e focada em alterações de ACL.
  • Alterações nos objetos dos serviços de diretório na sua organização (evento 5136 do Windows)
  • Modelos baseados em comportamento (como os oferecidos pela Varonis) para alertar quando um usuário recebe permissões sobre um objeto sensível ou para monitorar um curador adicionado ao objeto e receber um alerta se ele não existir.permissions-on-sensitive-object

  • As atribuições de privilégios diretos (evento 4704 do Windows) podem indicar a presença de injeção de SID sintético.4704-redacted

    varonis-log-activity

Remover SIDs não atribuídos

Ter um processo para localizar e remover SIDs não atribuídos pode impedir que o invasor recupere controle sobre os SIDs sintéticos.
Considere usar o PowerShell, ICACLS ou ferramentas dedicadas para localizar SIDs não atribuídos e removê-los.

Fontes