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:
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”.
O sistema de permissões do Active Directory é composto de três partes:
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.
Para ver o ACL de um objeto, basta acessar a aba “Segurança”:
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).
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”:
Criamos uma conta chamada “ThisIsMySID” e ela assumiu o SID:
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.
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.
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.
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.