Validação de LAPS e Tiering em Active Directory

por União Geek · 17 de junho de 2026

Índice

1 Validação de LAPS e Tiering em Active Directory

Validação de LAPS e Tiering em Active Directory

Introdução: No contexto atual, Active Directory continua sendo o backbone de identidade em milhares de organizações ao redor do mundo. Falhas na gestão de contas locais e na implementação do modelo de tiering causam exposição massiva a escalonamento de privilégio, movimentação lateral e comprometimento de domínio, impactando continuidade do negócio, confidencialidade de dados e conformidade normativa. Neste artigo técnico e aprofundado você vai aprender a validar implementações de LAPS (Local Administrator Password Solution), avaliar a eficácia do modelo de tiering (Tiered Administration Model), detectar lacunas de controle e configurar provas práticas de mitigação e detecção. O conteúdo combina fundamentos, arquitetura, fluxos de ataque, estudos de caso, comandos reproduzíveis em PowerShell e Kali, regras de detecção para SIEM, playbooks operacionais para Blue Team e Red Team, métricas de auditoria e checklists práticos.

Contexto Atual e Relevância Estratégica

Subtópico: A superfície de ataque do Active Directory permanece crítica em 2024 e, pelas tendências observadas, seguirá sendo um vetor central em 2025 e 2026. A maioria das invasões bem-sucedidas começa com credenciais fracas, reutilizadas ou locais administradores com senhas estáticas. LAPS surgiu como resposta ao problema das senhas locais idênticas ou mal gerenciadas, oferecendo rotação automática e armazenamento seguro do segredo no atributo ms-Mcs-AdmPwd do objeto computador no AD. Entretanto, a simples adoção de LAPS não garante segurança se a gestão de delegação, ACLs e arquitetura de tiering estiverem incorretas.

Subtópico: Por que isso importa para o negócio – perdas diretas, interrupção e conformidade. Quando um atacante obtém credenciais de administrador local com direitos sobre múltiplos sistemas, ele pode estabelecer persistência e pivotar até controladores de domínio. O impacto financeiro e reputacional de um domínio AD comprometido é extremo: recuperação envolve horas de especialistas, contabilidade para incident response, provas forenses e, muitas vezes, reconstrução parcial da infraestrutura. Compliance frameworks como ISO-27001, NIST-CSF, ISA-62443 e controles CIS 4.x exigem gerenciamento de privilégios, controle de contas administrativas e logging robusto. Validar LAPS e o tiering model não é apenas uma medida técnica, é um requisito de risco e conformidade.

Subtópico: Evolução das operações ofensivas e o papel do LAPS. Ferramentas modernas como SharpHound, BloodHound, Mimikatz e as coleções de AD em Kali/Parrot demonstraram que senhas locais expostas ou delegações incorretas aceleram a escalada de privilégios. Técnicas recentes de ataques a AD incluem exploração de ACLs sobre atributos sensíveis (ms-Mcs-AdmPwd entre eles), abuso de DCSync, abusos de delegação de chave e contas de serviço mal configuradas. Em relatórios técnicos e advisories, pesquisadores mostram que a exposição do atributo de senha local via ACL permissiva resulta em extração de senhas e controle de mais endpoints. Portanto, a validação deve cobrir não apenas se LAPS está implantado, mas se o controle de acesso a esse atributo é adequado, e se o tiering efetivamente separa superfícies administrativas.

Subtópico: Tendências e previsões tangíveis. Observamos três vetores que tornam a validação urgente:

Integração de AD on-prem com Azure AD e soluções híbridas, aumentando a superfície de ataque e complexidade de políticas.
Adoção massiva de ferramentas de automação DevOps que, se mal configuradas, criam caminhos de privilégio transversais entre ambientes.
Maior sofisticação em abuso de ACLs e artefatos do AD por atacantes que visam obter ms-Mcs-AdmPwd e delegações erradas para persistência.

A consequência prática: equipes de segurança precisam validar configuração de LAPS, revisar ACLs com ferramentas automatizadas e testar o modelo de tiering com auditorias regulares, simulações e escaneamentos de permissões.

Subtópico: Escopo deste artigo. Vamos mapear desde a teoria do ms-Mcs-AdmPwd até scripts e playbooks, incluindo:

Comandos para verificação em PowerShell e Linux.
Coleta de evidências com SharpHound e PowerView.
Regras Sigma/EQL e queries para SIEM e OpenSearch.
Casos de estudo de invasões envolvendo falhas de segregação de privilégios (contextualizadas).
Planos de auditoria e KPIs mensuráveis para maturidade de controle.

Ao final, você terá um roteiro técnico prático para validar, reforçar e auditar LAPS e o tiering model no seu Active Directory.

Fundamentos Técnicos do Tema

Subtópico: O que é LAPS e como funciona tecnicamente. Microsoft LAPS é uma solução que provê gerenciamento de senhas de contas locais (local administrator) de forma automática. Ela escreve a senha gerada no atributo ms-Mcs-AdmPwd do objeto computador no Active Directory. Complementarmente, um atributo ms-Mcs-AdmPwdExpirationTime mantém a informação de validade. Para funcionar, um cliente Windows precisa do agente LAPS (LAPS.x64.msi) instalado, e a política de GPO com as configurações de LAPS aplicada – políticas que definem comprimento de senha, complexidade e frequência de rotação. A segurança do mecanismo depende essencialmente de dois pontos: (1) confidencialidade do atributo ms-Mcs-AdmPwd dentro do AD e (2) rotação correta das senhas nos endpoints.

Subtópico: ACLs, delegação e ms-Mcs-AdmPwd. O atributo ms-Mcs-AdmPwd não tem proteção automática; qualquer entidade com permissão para ler atributos do objeto computador e especificamente ao ms-Mcs-AdmPwd pode recuperar a senha. Por isso, a delegação de permissões via ACLs precisa ser minimalista – tipicamente apenas grupos de administração designados (por exemplo, “LAPS_Readers”) recebem read rights. A delegação é feita utilizando o atributo “Read ms-Mcs-AdmPwd”. Erros comuns incluem concessão de permissão a Domain Admins computador-level em vez de grupos de administração dedicados, heranças indevidas de OU e permissões excessivas a contas de serviço e grupos de sistema.

Subtópico: Tiering Model explicado tecnicamente. O modelo de tiered administration recomendado pela Microsoft organiza contas e recursos em camadas ou tiers, geralmente:

Tier 0 – Controladores de domínio, contas de administrador de domínio, AD, PKI e objetos com autoridade total sobre identidade. Compromisso aqui equivale a comprometimento do domínio.
Tier 1 – Servidores de aplicação e servidores críticos (ex: Exchange, file servers), serviced accounts com privilégios locais elevados em servidores que suportam negócio crítico.
Tier 2 – Workstations e dispositivos de usuários finais.

O objetivo é limitar a explosão de privilégios: uma conta de Tier 2 não deve ter acesso administrativo a Tier 0. Em arquitetura prática, isso envolve contas de administração separadas fisicamente e logicamente, bastion hosts para administração de Tier 0 (Privileged Access Workstations – PAW), e segregação de credenciais e fluxos de autenticação.

Subtópico: Como LAPS e tiering se inter-relacionam. Em teoria, LAPS reduz risco em Tier 2 ao rotacionar senhas locais, impedindo que um atacante capture uma senha local e reutilize por longos períodos. Porém, quando ACLs mal configuradas permitem leitura massiva do ms-Mcs-AdmPwd, um atacante pode extrair senhas em massa e mover-se horizontalmente de Tier 2 para Tier 1 ou para escalar até Tier 0 se houver contas cruzadas com mais privilégios. O tiering model ajuda a limitar o alcance desse movimento ao separar contas e reduzir credenciais com poderes transversais. Portanto, validar ambos é mandatário: LAPS sem tiering ou tiering sem controles de LAPS é insuficiente.

Subtópico: Objetos, atributos e eventos relevantes. Para auditoria técnica devemos monitorar:

Atributos: ms-Mcs-AdmPwd, ms-Mcs-AdmPwdExpirationTime.
Eventos de Segurança Windows: evento 4662 (quando há leitura/escrita em objeto AD), 5136 (modificação de objeto) e logs de AAD Connect se aplicável.
Logs dos servidores de domínio e logs do LAPS cliente, que ficam registrados no event log “Application” sob operações do agente de política LAPS durante rotação.

Essa correlação é essencial para detectar abusos de leitura de atributo ou extração massiva.

Subtópico: Ferramentas técnicas de avaliação. Ferramentas padrão do tradecraft:

PowerShell LAPS module (Get-AdmPwdPassword).
PowerView (Get-ObjectAcl, Get-DomainComputer -Properties ms-Mcs-AdmPwd).
SharpHound/BloodHound para mapear caminhos privilegiados e delegações perigosas.
Impacket (secretsdump.py, rpcclient) para verificações e simulações.
AD ACL Scanner scripts (eXtended) para checar permissões em massa.

Essas ferramentas permitem automatizar detecções e preparar evidências para governance e remediation.

Subtópico: Limitações e riscos. LAPS protege contas locais mas não gerencia senhas de contas de serviço ou grupos administradores locais que ainda existam. LAPS também não impede que um atacante extraia credenciais se ele já tem permissão para ler o atributo. Por isso, validação deve incluir: revisão de ACLs, segregação de grupos, fecho de heranças indevidas, análise de contas de serviço com privilégio implícito e revisão de GPOs aplicáveis que possam anular comportamentos esperados.

Arquitetura, Fluxos e Superfície de Ataque

Subtópico: Arquitetura típica com LAPS e tiering. Em um ambiente bem projetado:

Tier 0: Controladores de domínio localizados em subnets segregadas, acesso a partir de PAWs que são máquinas dedicadas sem conexão ao email de usuários, MFA forte e bastion centralizado.
Tier 1: Servidores críticos isolados, com contas de serviço dedicadas e rotação de senhas por ferramentas de PAM nas infraestruturas críticas.
Tier 2: Workstations com LAPS instalado, políticas GPO para rotação, grupos de leitura de ms-Mcs-AdmPwd restritos e logging robusto.

Diagrama lógico: PAWs administram Tier 0, admins de Tier 1 usam consoles separadas, LAPS gerencia senhas locais em Tier 2, e grupos dedicados recebem leitura seletiva.

ASCII DIAGRAMA ARQUITETURA - EXEMPLO SIMPLIFICADO
+------------------+        +------------------+       +-------------------+
|   Admin PAW(s)   | <----> |  Domain Control  | <-->  |  PAM / Vault Ops  |
|  (Tier 0 Admin)  |        |  (Tier 0)        |       |  (Tier 0/1)       |
+------------------+        +------------------+       +-------------------+
         |                           |                         |
         |                           |                         |
         |                           |                         |
   -----+---------------------------+-------------------------+---------
         |                           |                         |
+------------------+         +------------------+       +-------------------+
|  Servidores      |         |  Workstations    |       |  LAPS Read Group   |
|  (Tier 1)        |         |  (Tier 2)        |       |  (delegated)      |
+------------------+         +------------------+       +-------------------+
         |                            |
         |                            |
         +---> ms-Mcs-AdmPwd (atributo AD grava senha local)

ASCII DIAGRAMA ARQUITETURA - EXEMPLO SIMPLIFICADO

+------------------+ +------------------+ +-------------------+

+------------------+ +------------------+ +-------------------+

| | |

-----+---------------------------+-------------------------+---------

| | |

+------------------+ +------------------+ +-------------------+

+------------------+ +------------------+ +-------------------+

| |

+---> ms-Mcs-AdmPwd (atributo AD grava senha local)

Subtópico: Fluxo de ataque típico contra LAPS/Tiering. Fluxo simplificado de ataque:

Reconhecimento – o atacante mapeia AD com SharpHound para identificar delegações e objetos expostos.
Compromisso inicial – phishing, RCE em servidor ou uso de credenciais vazadas para obter acesso a Tier 2.
Extração de senhas locais – leitura do atributo ms-Mcs-AdmPwd quando as ACLs permitem.
Movimentação lateral – uso de senhas locais para pivotar para servidores com privilégios maiores.
Escalonamento – abuso de delegações ou DCSync para obter hashes e controle do domínio.

Cada etapa é vulnerável a controles de detecção: monitoramento de eventos 4662/5136, alertas de volume de leituras, anomalias de autenticação e uso de credenciais de serviço em contextos não usuais.

Subtópico: Superfície de ataque detalhada. Elementos que compõem a superfície:

Contas de serviço com SPNs e direitos de escrita em OUs.
Grupos com privilégios mal configurados (ex.: groups nested com direitos de leitura a ms-Mcs-AdmPwd).
Heranças de OU que concedem permissões a contas gerais.
Sistemas com LAPS não atualizados ou GPO mal aplicada.
Serviços de automação que rodam em contas com permissão para leitura do atributo.

A validação deve mapear cada vetor e priorizar mitigação com base em risco e exposição.

Subtópico: Integração com cloud e híbridos. Ambientes híbridos (Azure AD Connect) introduzem complexidade: sincronia de objetos, regras de filtragem e possíveis caminhos indiretos para extrair credenciais via API/Graph. Ainda que LAPS opere on-prem, a integração híbrida pode criar contas sincronizadas que, se mal protegidas, expandem o ataque para cloud. Validadores devem checar sincronizações, filter rules e objetos sincronizados, além de logs no Azure AD como sinais complementares a ataques a credenciais.

Subtópico: Casos de uso defensivo – mitigação arquitetural. Para reduzir superfície, considere:

PAW para Tier 0 com gestão de software controlada e sem e-mail ou web browsing.
Isolamento de OUs e GPOs para evitar herança indevida.
Separação de grupos de leitura de ms-Mcs-AdmPwd com revisão trimestral de membership.
Adotar PAM para contas de serviço em Tier 1 e 0, evitando armazenamento de segredos em atributos AD.

Esse conjunto reduz a probabilidade de movimento lateral e contaminação entre tiers.

Cenários Reais e Estudos de Caso

Subtópico: Observação geral sobre casos públicos. Embora existam poucos relatórios públicos que descrevam explicitamente “exploração de LAPS” com nomes e datas exatos, muitos incidentes de grande escala demonstram o custo de falhas de segregação de privilégios e gerenciamento inadequado de senhas. Abaixo apresento estudos de caso que ilustram padrões técnicos e lições aplicáveis à validação de LAPS e tiering.

Subtópico: Estudo de caso 1 – Comprometimento por credenciais locais reutilizadas (caso genérico composto a partir de incidentes públicos)

Contexto: Organização financeira média-grande, ambiente AD on-prem com 15k endpoints. LAPS foi implementado parcialmente, mas a delegação de leitura havia sido concedida a um grupo grande de suporte.
Incidente: Atacante obteve acesso inicial via spear-phishing a um workstation. Utilizando ferramentas de rede, extraiu ms-Mcs-AdmPwd para dezenas de máquinas cujos atributos estavam legíveis pelo grupo de suporte; obteve acesso a contas locais que eram iguais a administradores de servidor devido a inventário inconsistente.
Impacto: Movimento lateral para servidores de aplicação (Tier 1) e exfiltração de dados financeiros. A resposta exigiu isolamento de toda a OU, resset de senhas locais via GPO e revisão de delegações.
Lições aprendidas: Delegação ampla para leitura de LAPS é risco crítico; inventário e revisão de membership de grupos de leitura precisam ser automatizados; logs de leitura de atributo ausentes impediram detecção precoce.

Subtópico: Estudo de caso 2 – Abuso de ACLs em AD com BloodHound (análise técnica)

Contexto: Empresa de serviços com extensa delegação de grupos e heranças de OU. Red Team usou SharpHound para mapear caminhos que permitiam acessar objetos sensíveis e atributos ms-Mcs-AdmPwd.
Exploração: SharpHound coletou ACLs e, com queries do BloodHound, identificou “Object Control Rights” sobre computadores críticos que permitiam WriteProperty/ReadProperty no atributo de senha local. Esses caminhos não eram óbvios no inventário manual.
Resultado: O Red Team demonstrou que uma conta de helpdesk com delegação indevida poderia extrair senhas LAPS e comprometer servidores com credenciais locais reutilizadas.
Mitigação: Remoção de permissões, criação de grupos específicos de leitura, e implementação de monitoramento para cada leitura de ms-Mcs-AdmPwd via event forwarding.

Subtópico: Estudo de caso 3 – Auditoria em grande varejista (exemplo consolidado)

Contexto: Varejo com arquitetura híbrida e AAD Connect. Auditoria interna detectou que contas sincronizadas do AD tinham membros em grupos que tinham direito de leitura do atributo ms-Mcs-AdmPwd.
Problema: A integração criou um vetor onde credenciais locais podiam ser lidas por processos na cloud que, em cenários de abuso, poderiam facilitar persistência cross-platform.
Ação: Revisão de sincronização, separação de contas sincronizadas, e adoção de PAM para contas de aplicação.

Subtópico: Observações sobre publicações e relatórios. Pesquisas de segurança, whitepapers de vendors e advisories de 2022-2024 demonstram padrões de abuso de ACLs e delegações. Embora não possamos afirmar eventos públicos nomeados em 2025/2026 sem referência pública verificável, a tendência técnica indica aumento no interesse ofensivo por atributos AD sensíveis e por falhas no modelo de tiering – o que reforça urgência da validação preventiva e de auditorias contínuas.

Subtópico: Exemplo de evidência forense coletada durante incidentes. Em processos de IR, colecionar evidências típicas inclui:

Export do atributo ms-Mcs-AdmPwd com timestamp e pessoa/serviço que realizou a leitura.
Logs de Security Event com eventos 4662 correlacionados a leituras de atributo.
SharpHound zip files com ACLs e possíveis paths de escalada.
Snapshots de membership de grupos e GPOs aplicados.

Armazenar e reter esses artefatos com cadeia de custódia é crítico para análise pós-incidente e remediação.

Implementação Prática Step-by-Step

Subtópico: Objetivo do passo a passo. Fornecer uma sequência reproduzível para validar implantação LAPS, revisar delegações e testar eficácia do tiering model. Incluir comando, validação de saída, rollback e evidências esperadas.

Passo 1 – Inventário e verificação de instalação do LAPS

# PowerShell em controlador de domínio ou máquina administrativa com Módulo LAPS Import-Module AdmPwd.PS # Verifica se o módulo está disponível Get-Command -Module AdmPwd.PS
1
2
3
4
5
# PowerShell em controlador de domínio ou máquina administrativa com Módulo LAPS
Import-Module AdmPwd.PS
# Verifica se o módulo está disponível
Get-Command -Module AdmPwd.PS

Validação: saída lista Get-AdmPwdPassword, Set-AdmPwdPassword etc. Se módulo ausente, instalar pacote LAPS no portal Microsoft ou via MSU.
Passo 2 – Conferir GPO de LAPS aplicada

# Em uma máquina do domínio gpresult /r | findstr /i "AdmPwd" # Ou via PowerShell Get-GPOReport -All -ReportType XML -Path C:\temp\gpos.xml
1
2
3
4
5
# Em uma máquina do domínio
gpresult /r | findstr /i "AdmPwd"
# Ou via PowerShell
Get-GPOReport -All -ReportType XML -Path C:\temp\gpos.xml

Validação: GPO deve apresentar configurações de Password Settings e Policy para LAPS. Rollback: reverter GPO ou vinculação se impacto operacional.
Passo 3 – Teste de leitura controlada

# Ler a senha local de um computador de teste Get-AdmPwdPassword -ComputerName "CLIENTE-TESTE01"
1
2
3
# Ler a senha local de um computador de teste
Get-AdmPwdPassword -ComputerName "CLIENTE-TESTE01"

Validação: saída retorna AccountName, Password e ExpirationTimestamp. Se falhar, revisar instalação de cliente LAPS ou GPO aplicado.

Passo 4 – Auditoria de ACLs em massa (PowerView)

# Em máquina administrativa com PowerView
Import-Module .\PowerView.ps1
# Procura por objetos computador com acesso ao atributo ms-Mcs-AdmPwd
Get-DomainObject -Identity (Get-DomainOU -Name "OU=Computers,DC=domain,DC=com") -Properties ms-Mcs-AdmPwd -Verbose
# Ou
Get-ObjectAcl -SamAccountName "COMPUTERNAME$" | ?{ $_.ObjectDN -match "CN=COMPUTERNAME" } | Format-List

# Em máquina administrativa com PowerView

Import-Module .\PowerView.ps1

# Procura por objetos computador com acesso ao atributo ms-Mcs-AdmPwd

Get-DomainObject -Identity (Get-DomainOU -Name "OU=Computers,DC=domain,DC=com") -Properties ms-Mcs-AdmPwd -Verbose

# Ou

Get-ObjectAcl -SamAccountName "COMPUTERNAME$" | ?{ $_.ObjectDN -match "CN=COMPUTERNAME" } | Format-List

Validação: identificar quais contas/grupos têm ReadProperty sobre ms-Mcs-AdmPwd. Evidência: export CSV da lista. Rollback: remover delegações indevidas e registrar mudança em ticket ITSM.

Passo 5 – Coleta com SharpHound para mapa de paths

# No Kali ou Windows com SharpHound SharpHound.exe -c All # Em Linux com BloodHound Python collector: python3 bloodhound-python -u user -p 'password' -d domain -ns dc.domain.local -c All -v
1
2
3
4
5
# No Kali ou Windows com SharpHound
SharpHound.exe -c All
# Em Linux com BloodHound Python collector:
python3 bloodhound-python -u user -p 'password' -d domain -ns dc.domain.local -c All -v

Validação: gerar zip com coleções. Suba para BloodHound e execute queries: “Find Principals with DCSync”, “Find Objects with Read ms-Mcs-AdmPwd” etc. Evidência: screenshots e export das queries. Rollback: remover coleções e credenciais usadas para coleta.

Passo 6 – Teste de leitura via conta delegada

# Com credenciais da conta que teoricamente tem leitura
$creds = Get-Credential
Invoke-Command -ComputerName dc01 -Credential $creds -ScriptBlock { Get-AdmPwdPassword -ComputerName "CLIENTE-TESTE01" }

# Com credenciais da conta que teoricamente tem leitura

$creds = Get-Credential

Invoke-Command -ComputerName dc01 -Credential $creds -ScriptBlock { Get-AdmPwdPassword -ComputerName "CLIENTE-TESTE01" }

Validação: confirmar que apenas contas autorizadas conseguem ler. Falha indica excesso de delegação.

Passo 7 – Monitoramento e detecção

# Exemplo de forward para SIEM: auditpol configurar
auditpol /set /category:"DS Access" /success:enable /failure:enable
# Configurar event forwarding com subscription que capture evento 4662 para servers de domínio

# Exemplo de forward para SIEM: auditpol configurar

auditpol /set /category:"DS Access" /success:enable /failure:enable

# Configurar event forwarding com subscription que capture evento 4662 para servers de domínio

Validação: evento 4662 deve aparecer quando há leitura modificação em atributos. Ajuste filtros para detectar leituras de ms-Mcs-AdmPwd em volume anômalo.

Passo 8 – Teste de rollback e restauração

# Reverter remoção de delegação (exemplo com PowerShell)
# Capturar ACL original antes de alteração
Get-Acl -Path "AD:CN=COMPUTERNAME,OU=Computers,DC=domain,DC=com" | Export-CliXml C:\backup\computer_acl.xml
# Após mudança, restaurar
Import-CliXml C:\backup\computer_acl.xml | Set-Acl -Path "AD:CN=COMPUTERNAME,OU=Computers,DC=domain,DC=com"

# Reverter remoção de delegação (exemplo com PowerShell)

# Capturar ACL original antes de alteração

Get-Acl -Path "AD:CN=COMPUTERNAME,OU=Computers,DC=domain,DC=com" | Export-CliXml C:\backup\computer_acl.xml

# Após mudança, restaurar

Import-CliXml C:\backup\computer_acl.xml | Set-Acl -Path "AD:CN=COMPUTERNAME,OU=Computers,DC=domain,DC=com"

Validação: confirmar que ACL restaurada e testes funcionais realizados previamente recuperam comportamento pré-mudança.

Passo 9 – Automação da auditoria

# Exemplo de script para listar computadores cujo atributo ms-Mcs-AdmPwd é legível por mais de N grupos:
# PowerShell skeleton
$computers = Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd
foreach($c in $computers){
  $acls = Get-ObjectAcl -SamAccountName $c.SamAccountName
  # lógica para detectar ReadProperty em ms-Mcs-AdmPwd e contar membros
}
# Export CSV para dashboard

# Exemplo de script para listar computadores cujo atributo ms-Mcs-AdmPwd é legível por mais de N grupos:

# PowerShell skeleton

$computers = Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd

foreach($c in $computers){

$acls = Get-ObjectAcl -SamAccountName $c.SamAccountName

# lógica para detectar ReadProperty em ms-Mcs-AdmPwd e contar membros

}

# Export CSV para dashboard

Validação: pipeline automatiza checagem periódica e alimenta tickets quando condições definidas são violadas.

Subtópico: Evidências esperadas e como documentar. Para cada passo, registre: variáveis de ambiente, versão de tool, data/hora, outputs exportados, screenshots e hashes dos arquivos coletados. Isso garante audit trail para auditorias e IR.

Hardening, Controles e Melhores Práticas

Subtópico: Princípios de hardening para LAPS e tiering. Aplicar o princípio de menor privilégio, defesa em profundidade e segregação de deveres. Especificamente:

Delegar leitura de ms-Mcs-AdmPwd somente a grupos específicos, com membership controlado por PAM e checagem manual trimestral.
Restringir herança de ACLs em OUs críticas e aplicar explicit permissions quando necessário.
Utilizar PAWs para administração Tier 0 e Tier 1; bloquear acesso a e-mail e web nesses dispositivos.
Configurar rotação de senha LAPS com políticas robustas de complexidade e duração apropriada (e.g., 30-90 dias conforme risco).
Adotar PAM ou vault para contas de serviço críticas, evitando armazenar segredos no AD quando possível.

Essas práticas reduzem risco de leitura massiva e limitam impacto de compromissos iniciais.

Subtópico: Controles técnicos recomendados – lista prática

Ativar auditing de Directory Service Access (eventos 4662/5136) e encaminhar para SIEM.
Implementar alertas de volume anormal de leituras de ms-Mcs-AdmPwd e acessos a conta local via RDP fora de horário.
Bloquear delegação unconstrained e revisar uso de constrained delegation com base de necessidade.
Monitorar e alertar alteração de membros de grupos de leitura de LAPS.
Harden clients LAPS: manter agente atualizado e aplicar GPOs para logs e operação.

Implementar esses controles reduz janelas de detecção e acelera resposta.

Subtópico: Políticas e processos organizacionais. Além do hardening técnico:

Defina políticas de propriedade sobre OUs e revisão de ACLs com responsabilidade clara.
Processo change control para alterações em delegações e GPOs com approvers técnicos e de risco.
Treinamento para equipes de helpdesk sobre o uso controlado de leitura de senhas; auditorias aleatórias para compliance.
Processos de onboarding/offboarding que removam membership de grupos privilegiados automaticamente.

Processos bem desenhados evitam concessões de privilégio acidentais.

Subtópico: Hardening de SIEM e detecção. Regras práticas:

Regra Sigma básica: alerta para qualquer leitura de atributo ms-Mcs-AdmPwd por conta não pertencente ao grupo de leitura designado.
Correlacione eventos 4662 com autenticações de contexto (Logon Type, origem IP, hora) para detectar acessos suspeitos.
Crie baseline de volume de leituras por conta e gere alerta quando há aumento superior a X vezes na janela de 24 horas.
Regra para identificar ações de export de ACLs e execução de SharpHound/Invoke-BloodHound com heurística de comandos, processos e hashes conhecidos.

Essas regras aceleram investigação e contenção.

Subtópico: Tecnologias complementares. Ferramentas e soluções que aumentam a defesa:

PAM/Vault (CyberArk, BeyondTrust, HashiCorp Vault) para gerir senhas privilegiadas de contas de serviço e de Tier 0/1.
Soluções de EDR com bloqueio de execução de ferramentas de coleta em endpoints sensíveis.
Soluções de Identity Threat Detection and Response (ITDR) que correlacionam comportamentos no AD e no cloud.
BloodHound como ferramenta interna para mapear paths e validá-los após remediação.

Combinar essas tecnologias com processos e monitoramento fornece defesa robusta contra abuso de LAPS e falhas no tiering.

Playbooks Operacionais para Blue Team e Red Team

Subtópico: Playbook Blue Team – Detecção e Contenção

Fase 1 – Preparação: Garantir event forwarding de 4662/5136, manter baseline de leituras de ms-Mcs-AdmPwd e inventário de grupos de leitura.
Fase 2 – Detecção: Alertar quando conta fora do grupo designado lê atributo; alertar volumes anormais de leituras; detectar execução de SharpHound/PowerView.
Fase 3 – Contenção imediata: Desabilitar sessão e credenciais da conta suspeita, isolar hosts envolvidos, aplicar bloqueios de firewall e MFA forçado nas contas administrativas.
Fase 4 – Investigação: Coletar SharpHound zip, exports de ACLs, logs de domínio, EDR telemetry, e preservar imagens de memória se possível para análise de ferramentas utilizadas.
Fase 5 – Remediação: Remover delegações indevidas, rotacionar senhas locais (forçar set-AdmPwdPassword), revisar memberships e reconfigurar GPOs se necessário.
Fase 6 – Recuperação: Monitoramento intensivo por 30 dias, aumentar auditoria e realizar pentest de verificação após correções.

Subtópico: Playbook Red Team – Teste de Resiliência e Validação

Fase 1 – Escopo e autorização: Definir OUs, máquinas e contas em escopo. Obter critérios de aceitação, limites de blast radius e times de contato para rollback.
Fase 2 – Reconhecimento: Executar SharpHound com collectors permitidos, mapear ACLs, listar contas com ReadProperty em ms-Mcs-AdmPwd.
Fase 3 – Exploração controlada: Usar conta de baixa prioridade (com permissão mínima) para tentar leitura do atributo; se não possível, documentar e reportar. Se permitido, demonstrar extração de senha somente em máquina de teste e sem uso malicioso.
Fase 4 – Escalonamento simulado: Demonstrar caminho de escalada até Tier 1 com evidências técnicas e capturas, sem danificar produção.
Fase 5 – Reporte: Fornecer playbook detalhado de steps, evidências, risco e recomendações de correção priorizadas por impacto.

Subtópico: Exemplo de ordem de operações para Blue Team durante incidente

Recebe alerta Sigma de leitura anômala de ms-Mcs-AdmPwd.
Identifica conta que efetuou leitura com query no Active Directory.
Correla com logs EDR para encontrar processo que iniciou leitura (PowerShell, SharpHound, RPCtools).
Isola máquina do usuário com leitura via NAC ou firewall interno.
Rotaciona senha local do computador afetado e revoga permissões se necessário.
Executa varredura completa de ACLs e inicia plano de remediação para todos os objetos expostos.
Notifica stakeholders e registra ticket de IR com prioridades.

Subtópico: Instrumentação para playbooks – regras e scripts úteis

Script de auto-remediação que, ao detectar leitura anômala, desliga leitura do atributo e notifica por SIEM/Slack.
Runbooks no SOAR para isolar endpoints, coletar evidências e executar execução de rotated password via LAPS.
Checklists de comunicação para C-level em incidente de AD.

Esses artefatos reduzem tempo de contenção e aumentam eficácia operacional em crises.

Métricas, KPIs e Auditoria Técnica

Subtópico: Principais métricas para monitorar o estado de LAPS e tiering

Porcentagem de endpoints com LAPS instalado vs total de endpoints (Meta: 100%).
Tempo médio entre rotações de senhas LAPS (conforme política) – detectar falhas de rotação.
Número de contas/grupos com permissão de leitura do atributo ms-Mcs-AdmPwd – target mínimo e tendência decrescente.
Número de leituras do atributo ms-Mcs-AdmPwd por dia/semana por conta – baseline e alert threshold.
Tempo médio de resolução de alertas de leitura anômala (MTTR) – objetivo < 4 horas em ambiente maduro.
Contagem de paths privilegiados detectados via BloodHound – objetivo: 0 para paths que levam a Tier 0.

Essas métricas devem ser avaliadas por dashboards e reportadas trimestralmente para o board de segurança.

Subtópico: KPIs de maturidade operacional

Maturidade de inventário – % dos objetos AD com tag de owner e documentação.
Frequência de auditoria programada de ACLs – mínimo trimestral.
Taxa de correção de issues detectadas em auditoria – objetivo > 90% em 30 dias.
Porcentagem de contas administrativas executadas em PAWs – meta 100% para Tier 0.

KPIs devem refletir capacidade real de controle e resposta, não apenas presença da tecnologia.

Subtópico: Técnicas de auditoria técnica detalhada

Export de ACLs com scripts PowerShell e verificação de ReadProperty sobre ms-Mcs-AdmPwd para todos os objetos computador.
Comparação de GPOs aplicados e verificação de lacunas entre políticas desejadas e aplicadas via GPResult e GPOReport.
Execução de SharpHound e análise de paths com queries automatizadas para detectar potencial escalada até Tier 0.
Cross-check de contas de serviço com privilégio local em servidores (Get-LocalGroupMember) e verificação das senhas de serviço para reuse e gerenciamento por PAM.

Auditorias técnicas devem produzir artefatos exportáveis para compliance e evidência.

Erros Comuns, Armadilhas e Correções

Subtópico: Erros de configuração frequentes

Delegar leitura de ms-Mcs-AdmPwd a grupos amplos como “Domain Users” ou “HelpDesk”. Correção: restringir a grupos específicos e aplicar periodic review.
Não auditar leituras de atributo – sem logs não há detecção. Correção: configurar auditing de DS Access e event forwarding para SIEM.
LAPS instalado parcialmente ou em versões antigas sem atualização. Correção: atualizar agentes LAPS e aplicar GPOs uniformes.
Contas de serviço com privilégios excessivos ou reutilizadas entre tiers. Correção: mover contas de serviço para PAM com credenciais rotacionadas.

A correção exige plano coordenado entre infra, security e operações.

Subtópico: Armadilhas de testes e validação

Executar ferramentas como SharpHound em produção sem autorização pode disparar alertas e causar incidentes. Sempre agendar testes e obter autorização escrita.
Automação que remove delegações sem validação pode interromper serviços – sempre capturar ACLs originais e testar rollback.
Supor que LAPS elimina necessidade de PAM – LAPS gerencia contas locais, mas PAM é requerido para contas de serviço e Tier 0/1.

Planejar testes com janelas, snapshots e rollback é essencial.

Subtópico: Correções técnicas robustas

Automatizar remoção de delegações indevidas com scripts idempotentes que preservam backup das ACLs.
Implementar PAM para contas sensíveis e migrar controle de senhas para cofre centralizado.
Implementar controles de network segmentation e hardening de RDP/WinRM para limitar superfícies de uso de senhas locais.

Correções devem ser testadas em ambiente de validação antes de aplicar em produção.

FAQ Técnico para Busca Orgânica

Subtópico: Perguntas frequentes e respostas objetivas – foco em featured snippets

P1: O que é LAPS e por que usá-lo?

Resposta: LAPS é uma solução da Microsoft que automatiza rotação de senhas locais e grava a senha no atributo ms-Mcs-AdmPwd do objeto computador no Active Directory, reduzindo risco de credenciais locais estáticas e reutilizadas.

P2: Como validar se o atributo ms-Mcs-AdmPwd está protegido?

Resposta: Audite ACLs do objeto computador com ferramentas (PowerView/Get-ObjectAcl ou SharpHound) para garantir que somente grupos designados têm ReadProperty sobre ms-Mcs-AdmPwd; monitore event 4662 para leituras e configure alertas de volume anômalo.

P3: Quais eventos do Windows indicarão possível abuso de LAPS?

Resposta: Directory Service Access events (4662) indicando leitura de atributos, eventos 5136 para modificação de objetos AD e logs do LAPS client na Application log; correlacione com autenticações suspeitas e execução de ferramentas forenses.

P4: LAPS é suficiente para proteger Tier 2?

Resposta: LAPS reduz risco em Tier 2, mas sua eficácia depende de controles de ACL, rotação e separação de responsabilidades; complementos como EDR, SIEM e PAM são necessários para defesa robusta.

P5: Como o tiering model previne escalonamento de privilégios?

Resposta: Ao separar contas e recursos em tiers com políticas e dispositivos de administração distintos (PAW para Tier 0), reduz-se a possibilidade de uma conta de baixa privilégio ascender e controlar recursos críticos, limitando blast radius.

P6: Quais ferramentas usar para mapear caminhos privilegiados?

Resposta: SharpHound/BloodHound, PowerView, AD ACL Scanner e scripts PowerShell custom. Use essas ferramentas para detectar delegações perigosas e paths que permitam escalada.

P7: Como medir maturidade de LAPS na organização?

Resposta: KPIs incluem cobertura de instalação LAPS, número de contas com permissões de leitura do atributo, frequência de rotação, número de paths detectados até Tier 0 e tempo de resolução de incidentes relacionados.

P8: O que fazer se detectar leituras não autorizadas do ms-Mcs-AdmPwd?

Resposta: Contenção imediata – isolar conta e hosts, rotacionar senhas afetadas via LAPS, reverter delegações indevidas, coletar evidências e executar investigação forense; depois, implementar controles para evitar recorrência.

P9: Posso usar BloodHound em produção?

Resposta: Sim, mas com autorização e janela controlada. Coletas podem ser ruidosas; planeje com stakeholders, realize em horários com baixo impacto e documente rollback e evidências.

P10: Como evitar herança indevida de ACLs em OUs?

Resposta: Defina OUs separadas para recursos com requisitos de segurança diferentes, use permissions explicitamente configuradas (disable inheritance when necessary), e automatize revisão de ACLs com scripts periódicos.

P11: Qual a política ideal de rotação LAPS?

Resposta: Depende de risco e criticidade. Como referência, 30-90 dias pode ser adequado; ambientes de alto risco devem considerar intervalos mais curtos combinados com detecção e resposta rápida.

P12: Como auditar LAPS em ambientes híbridos com Azure AD?

Resposta: Verifique objetos sincronizados via Azure AD Connect, avalie filtros e atributos sincrônicos, monitore logs no Azure AD para anomalias e corrole eventos entre on-prem AD e Azure para detectar tentativas cross-platform.

Considerações Finais

Subtópico: Síntese estratégica. LAPS e o Tiering Model são componentes complementares na proteção de identidades e privilégios em Active Directory. A segurança verdadeira surge da integração entre tecnologia, processos e monitoramento contínuo: LAPS corrige um problema técnico (senhas locais estáticas), mas sem controle de delegação e arquitetura de tiers ele pode ser inútil ou até arriscado. Validar significa mais do que checar se o software está instalado; significa auditar ACLs, mapear paths privilegiados, automatizar detecção e treinar equipes para responder rapidamente.

Subtópico: Prioridades de implementação. Se você tem recursos limitados, priorize:

Inventário completo e cobertura de LAPS em endpoints.
Auditoria e restrição de grupos de leitura do atributo ms-Mcs-AdmPwd.
Implementação de PAWs para contas Tier 0 e PAM para contas de serviço.
Instrumentação de SIEM para detectar leituras anômalas e execução de coletores.

Essas ações entregam o maior retorno de redução de risco em curto prazo.

Subtópico: Recomendação final operacional. Execute auditorias regulares (mínimo trimestral), mantenha playbooks prontos, e trate cada leitura de atributo fora do padrão como um incidente potencial. Segurança em AD é manter a humildade diante do alcance de um atacante e agir com disciplina na gestão de privilégios.

Subtópico: Chamado à ação. Se sua organização ainda não faz auditoria automatizada de ACLs ou não tem KPIs para LAPS, comece esta semana: rode uma coleta SharpHound em ambiente de teste, gere relatório BloodHound e reveja membership de grupos de leitura. Pequenos passos, repetidos e medidos, reduzem de forma tangível o risco do domínio ser comprometido.

Recursos Visuais Sugeridos

Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.

MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
NIST Cybersecurity Framework – figuras oficiais e referências de controles.
ENISA – relatórios anuais com gráficos e mapas de ameaça.
Kali Linux – documentação oficial com fluxos práticos.
Parrot Security – documentação oficial com arquitetura modular.

Referências

Lista selecionada de recursos oficiais e técnicas para aprofundamento e verificação:

Microsoft Docs – LAPS: https://learn.microsoft.com/windows-server/identity/laps/overview
Microsoft Docs – Tiered Administration: https://learn.microsoft.com/windows-server/identity/solutions/privileged-access/privileged-access-workstations
BloodHound Project: https://github.com/BloodHoundAD/BloodHound
SharpHound Collector: https://github.com/BloodHoundAD/SharpHound
PowerView (PowerShell AD auditing): https://github.com/PowerShellMafia/PowerSploit/tree/master/Recon
Impacket: https://github.com/SecureAuthCorp/impacket
Mimikatz: https://github.com/gentilkiwi/mimikatz
MITRE ATT&CK – Enterprise: https://attack.mitre.org/
NIST – Guide to Enterprise Password Management (SP 800-63 etc.): https://www.nist.gov/
CIS Controls: https://www.cisecurity.org/controls/
Microsoft Security Blog – Identity protections: https://www.microsoft.com/security/blog/
Advisories e whitepapers sobre AD hardening – Microsoft Security Response Center: https://msrc.microsoft.com/
HashiCorp Vault – secrets management: https://www.vaultproject.io/
CyberArk – PAM solutions: https://www.cyberark.com/
BeyondTrust – Privileged Access Management: https://www.beyondtrust.com/
Azure AD Connect Documentation: https://learn.microsoft.com/azure/active-directory/hybrid/

Tabela comparativa – abordagens para gestão de senhas locais e privileged access

Abordagem	Risco Residual	Custo Operacional	Esforço de Implementação	Maturidade Requerida
LAPS (ms-Mcs-AdmPwd)	Baixo-médio se ACLs gerenciadas; alto se delegação excessiva	Baixo – ferramenta Microsoft gratuita	Moderado – deploy GPO + agente	Intermediária – exige revisão de ACLs
PAM/Vault (HashiCorp, CyberArk)	Baixo quando bem implementado	Alto – licença e operação	Alto – integração e migração	Alta – processos e governação necessárias
Contas locais manuais (sem automação)	Alto – senhas estáticas e reuse	Muito alto – gestão humana	Baixo técnico, alto operacional	Muito baixa – sujeita a erro humano
PAW + Tiering Model	Reduz fortemente risco de Tier 0 comprometimento	Moderado-alto – hardware e governança	Moderado – mudanças processuais e treino	Alta – exige disciplina operacional
EDR + SIEM + SOAR	Baixo se integrado para detecção e resposta	Alto – licenças e operações SOC	Alto – tuning e integração	Alta – requiere SOC maduro

Diagrama textual de fluxo de ataque/defesa


+-----------------+     initial access     +-----------------+     read ms-Mcs-AdmPwd     +------------------+
| Phishing / RCE  | ---------------------> |  Workstation    | -------------------------> |   AD Attribute   |
|  (Tier 2)       |                        |  (Tier 2)       |                             | ms-Mcs-AdmPwd    |
+-----------------+                         +-----------------+                             +------------------+
       |                                            |                                              |
       | EDR detects suspicious PowerShell          | SharpHound collects ACLs                       |
       |                                            |                                              |
       v                                            v                                              v
+-----------------+   SIEM Correlation/Alert   +-----------------+    Blue Team response     +------------------+
|  Red Team       | ------------------------>  |  SIEM / SOAR    |  -----------------------> |  Remediation     |
|  SharpHound     |                           |  Detects event  |                          |  Revoke ACLs,    |
+-----------------+                           +-----------------+                          |  Rotate LAPS PW  |
                                                                                          +------------------+

+-----------------+ initial access +-----------------+ read ms-Mcs-AdmPwd +------------------+

| Phishing / RCE | ---------------------> | Workstation | -------------------------> | AD Attribute |

+-----------------+ +-----------------+ +------------------+

| | |

| EDR detects suspicious PowerShell | SharpHound collects ACLs |

| | |

v v v

+-----------------+ SIEM Correlation/Alert +-----------------+ Blue Team response +------------------+

| Red Team | ------------------------> | SIEM / SOAR | -----------------------> | Remediation |

+-----------------+ +-----------------+ | Rotate LAPS PW |

+------------------+

Cenário prático obrigatório – passo a passo operacional completo

Pré-requisitos: acesso administrativo de auditoria, ferramenta SharpHound, módulo AdmPwd.PS e PowerView.

Coleta:

# Coleta com SharpHound em máquina de auditoria autorizada
SharpHound.exe -c All -Domain domain.local -ZipFileName audit_sharphound.zip
# Export com PowerView para verificar ACLs em massa
Import-Module .\PowerView.ps1
Get-ADComputer -Filter * | % {
  $cn = $_.Name
  Get-ObjectAcl -SamAccountName "$cn`$" | ?{ $_.ActiveDirectoryRights -match "ReadProperty" -and $_.ObjectDN -match $cn } | Export-Csv C:\temp\acl_$cn.csv -NoTypeInformation
}

# Coleta com SharpHound em máquina de auditoria autorizada

SharpHound.exe -c All -Domain domain.local -ZipFileName audit_sharphound.zip

# Export com PowerView para verificar ACLs em massa

Import-Module .\PowerView.ps1

Get-ADComputer -Filter * | % {

$cn = $_.Name

Get-ObjectAcl -SamAccountName "$cn`$" | ?{ $_.ActiveDirectoryRights -match "ReadProperty" -and $_.ObjectDN -match $cn } | Export-Csv C:\temp\acl_$cn.csv -NoTypeInformation

}

Validação: verificar no BloodHound queries como “Find Objects with Read ms-Mcs-AdmPwd” e documentar resultados.

Exploração controlada (Red Team autorizado):

# Simular leitura com conta delegada permitida
$creds = Get-Credential
Invoke-Command -ComputerName "CLIENTE-TESTE01" -Credential $creds -ScriptBlock { Get-AdmPwdPassword -ComputerName "CLIENTE-TESTE01" }

# Simular leitura com conta delegada permitida

$creds = Get-Credential

Invoke-Command -ComputerName "CLIENTE-TESTE01" -Credential $creds -ScriptBlock { Get-AdmPwdPassword -ComputerName "CLIENTE-TESTE01" }

Validação: saída com senha e expiration. Documente hash do processo e capture logs EDR.

Rollback:

# Restauração ACL backup Import-CliXml C:\backup\computer_acl.xml | Set-Acl -Path "AD:CN=COMPUTERNAME,OU=Computers,DC=domain,DC=com"
1
2
3
# Restauração ACL backup
Import-CliXml C:\backup\computer_acl.xml | Set-Acl -Path "AD:CN=COMPUTERNAME,OU=Computers,DC=domain,DC=com"
Evidências a coletar: SharpHound zip, CSVs de ACLs, outputs do Get-AdmPwdPassword, logs 4662/5136, screenshots do BloodHound queries e hashes de arquivos coletados.
Relatório final: incluir CVE relacionáveis (se aplicável), impacto business, plano de remediação e timeline para correções com owners responsáveis.

Checklist duplo – Blue Team / Red Team

Checklist Blue Team

Configurar auditing para Directory Service Access e event forwarding para SIEM.
Inventariar cobertura LAPS e identificar endpoints sem agente.
Executar auditoria de ACLs para ReadProperty em ms-Mcs-AdmPwd e restringir grupos de leitura.
Implementar alertas de volume de leitura anômala do atributo ms-Mcs-AdmPwd.
Garantir PAWs para contas Tier 0 e PAM para contas de serviço.
Testar playbooks de IR e SOAR para rotacionar senhas e isolar hosts.
Revisão trimestral de membership de grupos de leitura e logs.

Checklist Red Team

Obter autorização escrita e definir blast radius e rollback plan.
Executar SharpHound/PowerView em ambiente autorizado e coletar ACLs.
Identificar objetos com ReadProperty e demonstrar exploração apenas em máquinas de teste.
Documentar paths descobertos até Tier 0 e apresentar mitigação técnica.
Fornecer evidências reproduzíveis e riscos associados em formato técnico e executivo.
Respeitar regras de engajamento e não executar ações destrutivas em produção.

Recursos Visuais Sugeridos

Microsoft LAPS overview – diagrama e arquitetura: https://learn.microsoft.com/windows-server/identity/laps/overview
BloodHound project – visualização de paths: https://github.com/BloodHoundAD/BloodHound
SharpHound collection docs – exemplos de queries: https://github.com/BloodHoundAD/SharpHound
Azure AD Connect architecture diagrams: https://learn.microsoft.com/azure/active-directory/hybrid/
Microsoft privileged access workstations design: https://learn.microsoft.com/windows-server/identity/solutions/privileged-access/privileged-access-workstations
NIST guidance on identity and access: https://www.nist.gov/topics/identity-access-management
HashiCorp Vault architecture – diagrams: https://www.vaultproject.io/docs/architecture
CIS Controls mapping – identity-focused controls: https://www.cisecurity.org/controls/