Active Directory Backup Operators, Print Operators, Server Operators Escalonamento de Privilegios: Os Grupos que Ninguem Audita

Active Directory Backup Operators, Print Operators, Server Operators Escalonamento de Privilegios Explicado

Active Directory Backup Operators, Print Operators, Server Operators Escalonamento de Privilegios e uma classe de risco que a maioria das revisoes focadas em Domain Admins nunca verifica, porque nenhum desses quatro grupos nativos — Backup Operators, Print Operators, Server Operators ou Account Operators — fica aninhado dentro de Domain Admins ou Enterprise Admins por padrao. Ainda assim, a documentacao da propria Microsoft lista os quatro como grupos de seguranca do Active Directory, e a Microsoft os classifica separadamente como contas e grupos protegidos — o mesmo nivel de protecao de Domain Admins e Schema Admins.

Essa classificacao e o sinal. A associacao a qualquer um desses quatro grupos basta para obter acesso total de leitura/escrita a todos os arquivos de um controlador de dominio, execucao de codigo em kernel, execucao de comandos em nivel de servico ou manipulacao de contas em todo o dominio. Nenhum desses casos e uma ma configuracao ou um patch ausente — sao o comportamento projetado dos direitos de usuario do Windows, aplicado por padrao a um grupo ao qual um atacante so precisa conseguir adicionar uma conta.

Como cada grupo concede direitos proximos de Domain Admin

O mecanismo e a GPO Default Domain Controllers Policy, que atribui direitos especificos de usuario do Windows a esses grupos em todos os DCs do dominio:

Esses padroes estao documentados diretamente pela Microsoft: a pagina da politica "Back up files and directories" lista Administrators, Backup Operators e Server Operators como titulares padrao em controladores de dominio, e a pagina da politica "Load and unload device drivers" lista Administrators e Print Operators. O escopo do Account Operators e descrito na mesma referencia de grupos de seguranca: os membros podem criar e modificar a maioria dos tipos de conta, mas o grupo em si nao tem membros por padrao, e a orientacao da Microsoft e manter assim.

A cadeia de ataque: quatro caminhos separados

Passo 1 — De Backup Operators ao ntds.dit

SeBackupPrivilege ignora completamente as ACLs NTFS, o que significa que pode ser usado para extrair o banco de dados do AD diretamente de um DC em producao sem nunca tocar no grupo de domain admin. O padrao documentado em varios write-ups publicos — Semperis, Hacking Articles e nhimg.org — usa o diskshadow.exe para criar uma copia de sombra de volume, permitindo copiar o arquivo bloqueado ntds.dit, e depois o robocopy (que respeita o SeBackupPrivilege) para extrair a copia e um export do hive de registro SYSTEM da maquina:

# diskshadow script (run from an account holding SeBackupPrivilege)
set context persistent nowriters
add volume c: alias cvol
create
expose %cvol% z:
exec "cmd.exe" /c robocopy /b z:\windows\ntds . ntds.dit
exec "cmd.exe" /c reg save hklm\system c:\temp\system.hive

Offline, o ntds.dit mais o hive SYSTEM entregam todos os hashes de senha do dominio — um caminho direto para um login pass-the-hash como Domain Admin, sem exploit e sem CVE necessarios. Isso chega aos mesmos segredos que nosso artigo Abuso de ACL e DCSync cobre para caminhos baseados em ACL — so que atraves de um bypass no sistema de arquivos em vez de um direito de replicacao.

Passo 2 — De Print Operators a SYSTEM via um driver carregado

SeLoadDriverPrivilege permite que um Print Operator carregue um driver em modo kernel em um controlador de dominio. Como descrevem a pesquisa da Tarlogic sobre esse privilegio e varias colecoes de notas de seguranca ofensiva (por exemplo, o HackTricks), esse privilegio costuma ser abusado carregando um driver legitimamente assinado, mas exploravel — a tecnica Capcom.sys e o exemplo publico mais documentado — para executar codigo arbitrario em espaco de kernel como NT AUTHORITY\SYSTEM. A partir dai, adicionar a conta atual aos Domain Admins ou extrair o ntds.dit diretamente e trivial. Essa classe de abuso de privilegios faz parte de uma categoria maior de direitos de usuario perigosos no Windows, que nosso artigo sobre direitos de usuario perigosos no Active Directory cobre ao lado de SeDebugPrivilege e SeTcbPrivilege.

Passo 3 — De Server Operators ao sequestro de servico

Server Operators herdam os mesmos direitos de backup/restore que Backup Operators, mas tambem recebem SERVICE_ALL_ACCESS sobre a maioria dos servicos de um DC. O write-up da Hacking Articles sobre o grupo mostra passo a passo como redirecionar o caminho binario de um servico legitimo para um executavel controlado pelo atacante e reiniciar o servico — que passa entao a rodar o payload como SYSTEM. Pesquisas publicadas sobre o abuso de SeRestorePrivilege (geralmente alcancado via associacao a Server Operators) mostram ainda que ele permite sobrescrever binarios protegidos do sistema e sequestrar DLLs de servico, dando pelo menos tres caminhos independentes de uma unica associacao de grupo ate o SYSTEM em um DC.

Passo 4 — De Account Operators a persistencia silenciosa

Account Operators nao carrega nenhum privilegio de sistema operacional, mas seus direitos nativos do AD sao amplos: criar novos usuarios, redefinir a senha da maioria dos usuarios e adicionar ou remover membros da maioria dos grupos em todo o dominio. O artigo da Cyber Advisors sobre Account Operators descreve o grupo como frequentemente "a um passo de Domain Administrator" — o grupo nao pode tocar diretamente em Domain Admins, Enterprise Admins ou nos outros grupos protegidos (eles sao blindados pela ACL do AdminSDHolder), mas pode criar contas livremente, adicionar a si mesmo a qualquer grupo nao protegido com direitos delegados, e redefinir a senha de qualquer conta que nao esteja em um grupo protegido. Isso e suficiente para persistencia duravel e de baixa visibilidade, mesmo sem nunca tocar em um grupo Tier 0.

🚨 Perigo: nenhuma dessas quatro tecnicas exige divulgacao de vulnerabilidade, CVE ou patch ausente. Sao o comportamento pretendido, por design, dos direitos de usuario do Windows — o unico "bug" e uma conta ser membro do grupo.

Deteccao

Mudancas de associacao a grupos e o uso de privilegios sao registrados nativamente — a lacuna quase sempre e que ninguem esta observando isso.

Correlacione tudo isso com logons interativos ou RDP (Event ID 4624, tipo de logon 2 ou 10) desses quatro grupos em um DC — em qualquer modelo de tiering razoavel, nenhum deles deveria precisar disso. Nosso guia de Monitoramento do Active Directory sobre os Event IDs que importam cobre os pre-requisitos de politica de auditoria para todos os eventos acima. Ferramentas de enumeracao continua como etc-collector, PingCastle e Purple Knight tambem podem sinalizar associacao nao vazia a esses grupos diretamente, sem esperar que um evento de log dispare.

Remediacao

1. Mantenha os quatro grupos vazios. Esse e o estado padrao documentado; trate qualquer adicao como uma mudanca digna de incidente, nao como delegacao rotineira.
2. Delegue de forma restrita em vez de aninhar em grupos nativos. Se uma equipe realmente precisa criar contas de usuario, conceda esse direito via uma delegacao de ACL limitada a uma OU, em vez de associacao a Account Operators, que e valida em todo o dominio por design.
3. Tire os jobs de backup do privilegio valido em todo o dominio. Onde o produto de backup permitir, use uma conta de servico dedicada, limitada ao alvo especifico de backup, em vez de uma conta humana ou compartilhada com SeBackupPrivilege/SeRestorePrivilege em todo o dominio via Server/Backup Operators.
4. Aplique um modelo de tiering. Nenhuma conta admin, de helpdesk ou de servico de Tier 1 ou Tier 2 deveria estar aninhada em um grupo Tier 0 — esses quatro incluidos. Nosso artigo Desvio de Acesso Privilegiado mostra como a associacao aninhada volta a aparecer mesmo depois de uma auditoria limpa, e nosso guia Endurecimento do Active Directory mostra onde isso se encaixa em uma sequencia mais ampla de bloqueio.
5. Ative a politica de auditoria e alerte sobre ela. Ative "Audit Sensitive Privilege Use" e "Audit Security Group Management", encaminhe os Event IDs 4728/4732/4756/4673 para seu SIEM, e alerte sobre qualquer ocorrencia envolvendo os SIDs desses quatro grupos.
6. Reverifique regularmente, nao apenas uma vez. Esses quatro grupos sao exatamente o tipo de achado que uma revisao mais ampla das configuracoes incorretas de seguranca do Active Directory mais comuns costuma revelar junto — execute a verificacao como parte de todo ciclo de auditoria recorrente, nao como uma limpeza pontual.

Como o EtcSec detecta isso

Os checks ACCOUNT_OPERATORS_MEMBER, BACKUP_OPERATORS_MEMBER, PRINT_OPERATORS_MEMBER e SERVER_OPERATORS_MEMBER do EtcSec sinalizam qualquer associacao nao vazia a esses quatro grupos em toda auditoria de AD — a mesma linha de base de tolerancia quase zero que a Microsoft documenta. PRIVILEGE_SEBACKUP_ABUSE e PRIVILEGE_SERESTORE_ABUSE capturam separadamente os casos em que SeBackupPrivilege ou SeRestorePrivilege foram atribuidos via GPO alem dos padroes nativos — a outra forma como esses direitos acabam nas maos erradas.