Active Directory – Privilégios e contas privilégiadas

É um enorme desafio determinar qual acesso cada usuário ou grupo realmente possui privilégios. Muitas vezes, o impacto total do acesso que um grupo tem realmente não é totalmente compreendido pela organização. Os atacantes aproveitam essas contas para comprometer o Active Directory de diversas formas.

A obtenção de acesso com menos privilégios não é um projeto, mas uma mudança na cultura de uma organização. Ao mudar a cultura e envolver todas as pessoas da sua empresa, a postura de segurança da sua organização começará a se fortalecer.

Existem alguns pontos de atenção que temos nos preocupar, pois o acesso privilegiado nem sempre é concedido explicitamente.

  • Associação ao grupo do Active Directory.
  • Grupos do AD com direitos privilegiados em computadores
  • Direitos delegados a objetos do AD, modificando as permissões padrão (Semelhante às permissões do sistema de arquivos, os objetos do Active Directory também têm permissões.)
  • Direitos de objetos migrados com SIDHistory .
  • Direitos delegados para objetos de GPO. (As permissões nas GPOs podem ser configuradas para delegar direitos de modificação da GPO a qualquer entidade de segurança).
  • Atribuições de direitos de usuário via GPO  (ou Diretiva Local) .
  • Associação de grupo local em um computador ou computadores (semelhante às configurações atribuídas pelo GPO).
  • Direitos delegados para pastas compartilhadas.

Enumerar membros do grupo é a maneira mais fácil de descobrir contas privilegiadas no Active Directory

  • Account Operators
  • Administrators
  • Allowed RODC Password Replication Group
  • Backup Operators
  • Certificate Service DCOM Access
  • Cert Publishers
  • Distributed COM Users
  • DnsAdmins
  • Domain Admins
  • Enterprise Admin
  • Event Log Readers
  • Group Policy Creators Owners
  • Hyper-V Administrators
  • Pre–Windows 2000 Compatible Access
  • Print Operators
  • Protected Users
  • Remote Desktop Users
  • Schema Admins
  • Server Operators
  • WinRMRemoteWMIUsers_

Os poderes dessas contas são diversos e podem ser consultados no “Active Directory Security Grupo”

Grupos do AD com direitos privilegiados em computadores

A maioria das organizações usa GPO para adicionar um grupo do Active Directory a um grupo local em computadores geralmente o grupo Administradores. (Quem nunca ?) .

Essa pode ser uma porta de acesso ao domínio, uma vez que é fácil identificar se existem GPOs desse tipo, quais grupos e em quais computadores se aplicam, apenas utilizando o PowerShell com os módulos do https://github.com/PowerShellMafia/PowerSploit 

Dois comandos podemos nos ajudar a identificar as grupos em GPOs

  • Get-NetGPOGroup – Exibe todas as GPOS que contem o  “Restricted Groups” definido
  • Find-GPOComputerAdmin – Pega um computador e determina quem tem direitos de admin através de enumeração de GPO
  • Get-NetComputer – Lista os computadores do domínio ou de uma OU

Local Administrator Password Solution (LAPS)

Se o intuito de criar esse tipo de GPO é a administração local, é recomendável a utilização do LAPS, onde eu explico nesse vídeo.

 

🔒 Este vídeo mostra como pode ser perigoso utilizar a mesma senha de adm local em várias maquinas. Utilizo o mimikatz para fazer o Dump de Hash e descobrir a senha do ADM. Depois demonstro como utilizar o LAPS da Microsoft.

🌎Local Administrator Password Solution” (LAPS)
http://aka.ms/LAPS

🌎Mimikatz
https://github.com/gentilkiwi/mimikatz

🌎 CrackStation
https://crackstation.net

 

Fonte de pesquisa : https://adsecurity.org

Sobre Daniel Donda 262 Artigos
Olá, meu nome é Daniel Donda e sou Strategic Systems Consultant para soluções de segurança e compliance. Saiba mais

5 Comentário

    • Oi Israel, desculpe a demora na resposta. Olha. Por padrão os users tem apenas leitura e não podem excluir a pasta sysvol. Vou tentar refazer isso no meu ambiente, mas acredito que não possam.

  1. Muito bom!! Gostei muito de conhecer o LAPS e já apliquei em um LAB com o Windows Server 2008 R2 SP1 (Na documentação do LAPS diz que tem que ter o powershell 2.0 como minimo suportado, mais em meu LAB só funcionou atualizando o WMF para 4.5)

    P.S No video a um momento em que é aplica o comando Set-AdmPwdComputerSelfPermission, para setar em qual OU vai ser aplicada o LAPS. Mais em vez de mencionar OU, vc menciona “grupo do AD”. Isso não é uma critica ao vídeo e sim para que os leitores, que vão realizar os seus testes, não se confundam.

    “UMA DUVIDA MINHA DONDA, E COM RELAÇÃO A REPLICAÇÃO ENTRE SITES DO AD PARA SERVIDORES RODC´S. É PRECISO ALGUMA CONFIGURAÇÃO A MAIS?

  2. Muito bom, parabéns pelo conteúdo.
    Estou procurando a alguns dias materiais como esse, sobre segurança na infraestrutura.

    Caso tenho outros para indicar, fico MT agradecido.

Faça um comentário

Seu e-mail não será divulgado.


*