Varonis debuts trailblazing features for securing Salesforce. Learn More

Apresentamos a automação de privilégios mínimos para Microsoft 365, Google Drive e Box

Saiba Mais

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

Uma técnica em que agentes de ameaças com privilégios elevados existentes podem injetar SIDs sintéticos em um ACL, criando backdoors e permissões ocultas.
Eric Saraga
4 minuto de leitura
Publicado 12 de Março de 2022
Ultima atualização 30 de Março de 2022

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

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
Try Varonis free.
Get a detailed data risk report based on your company’s data.
Deploys in minutes.
Keep reading
síndrome-do-impostor:-bug-da-interface-do-usuário-no-visual-studio-permite-que-invasores-representem-editores
Síndrome do impostor: bug da interface do usuário no Visual Studio permite que invasores representem editores
Bug encontrado no instalador do Microsoft Visual Studio permite que um invasor se passe por um editor e emita uma extensão
sites-fantasmas:-roubo-de-dados-de-comunidades-salesforce-desativadas
Sites fantasmas: roubo de dados de comunidades Salesforce desativadas
Sites fantasmas são comunidades abandonadas no Salesforce sem atualizações ou medidas de segurança implementadas
neo4jection:-segredos,-dados-e-exploit-na-nuvem
Neo4jection: segredos, dados e exploit na nuvem
Com o aumento contínuo de bancos de dados gráficos, como o Neo4j, estamos vendo um aumento nos debates entre pesquisadores de segurança sobre os problemas encontrados nesses bancos de dados.
ransomware-hardbit-2.0
Ransomware Hardbit 2.0
Detectado pela primeira vez em outubro de 2022, o HardBit é uma ameaça de ransomware que tem como alvo as organizações para extorquir pagamentos e criptomoeda pela descriptografia de seus dados.