Contas Obsoletas e Superprivilegiadas no AD

Contas privilegiadas obsoletas não são apenas ruído de higiene de diretório. No Active Directory, uma conta adormecida que ainda pertence a um grupo privilegiado, ainda tem uma senha antiga ou ainda possui uma dependência de serviço pode se tornar um caminho pouco visível de volta ao domínio.

O que são contas obsoletas e superprivilegiadas?

Contas privilegiadas obsoletas são identidades antigas ou pouco visíveis que ainda resultam em acesso administrativo relevante no Active Directory. Elas costumam se sobrepor a contas superprivilegiadas: identidades que mantiveram mais acesso do que a função atual exige.

Ambientes de Active Directory acumulam contas ao longo do tempo. Funcionários saem, contratados encerram seus contratos, contas de serviço sobrevivem a projetos e identidades administrativas de emergência continuam ativadas muito depois de o motivo original desaparecer.

Do ponto de vista do atacante, essas duas condições se reforçam mutuamente. O melhor alvo não é apenas uma conta antiga. É uma conta antiga que ainda está em um caminho privilegiado, é pouco monitorada e não tem um dono claro que perceberia atividade incomum.

Como funciona

As contas do AD permanecem ativas até que alguém as desative ou exclua. Se o offboarding, a revisão de contas de serviço ou a revisão de privilégios forem ignorados, o ambiente se enche de contas que:

não se autenticam há meses ou anos
ainda pertencem a grupos privilegiados
têm senhas definidas há muito tempo e nunca revisadas
ficam fora de qualquer revisão de ciclo de vida disciplinada

Uma conta privilegiada obsoleta é atraente porque combina alto valor com pouco escrutínio. A conta pode não aparecer no trabalho administrativo diário, mas continua resultando nas mesmas permissões quando a senha é apresentada.

A orientação da Microsoft sobre remediação de contas obsoletas destaca especificamente contas inativas como um risco de segurança e recomenda verificações regulares. A mesma orientação também alerta que contas de serviço podem não fazer login por longos períodos, então a limpeza precisa de salvaguardas em vez de exclusão às cegas.

Contas privilegiadas obsoletas: limites de escopo na busca

Uma revisão de contas obsoletas deve ser precisa sobre o que os timestamps realmente significam.

LastLogonDate e os dados replicados de login subjacentes são úteis para encontrar candidatos à limpeza, mas não são o mesmo que o uso forense exato em cada controlador de domínio. Eles são suficientes para identificar contas que precisam de revisão humana. Não são o único sinal em que você deve confiar antes de remover uma identidade de serviço sensível.

É por isso que revisões maduras separam pelo menos três casos:

contas de usuário que claramente deveriam ter sido desativadas após o offboarding
identidades de serviço ou de tarefa agendada que ainda podem ser usadas de forma não interativa
identidades privilegiadas de emergência ou compartilhadas que sobreviveram porque ninguém quis testar as dependências

O objetivo não é manter toda conta antiga porque um aplicativo pode quebrar. O objetivo é parar de tratar a propriedade pouco clara como motivo para preservar privilégio adormecido para sempre.

Uma distinção operacional útil é entre inatividade e irrelevância. Uma conta pode estar quieta porque foi abandonada, ou quieta porque só é acionada mensalmente por um backup, uma tarefa agendada ou um processo de recuperação raramente usado. A revisão precisa separar esses casos explicitamente.

Limitações de timestamp que importam

Para triagem de contas obsoletas, use múltiplos sinais. A Microsoft observa que PasswordLastSet é replicado e que lastLogonTimeStamp existe para ajudar a identificar contas potencialmente obsoletas. Isso torna esses atributos úteis para limpeza em todo o domínio. Não significa que eles provem que uma conta não tem dependência.

Uma revisão segura combina:

dados replicados de inatividade, como idade da senha ou lastLogonTimeStamp
dados de eventos do controlador de domínio para autenticação recente
análise de associação a grupos e direitos delegados
verificações de dependência de serviços, tarefas agendadas e aplicativos
atestado do proprietário para contas que devem permanecer ativadas

Quanto maior o privilégio, menos aceitável é confiar em um único timestamp. Um membro adormecido do Domain Admins e um usuário adormecido de baixo privilégio não representam o mesmo risco.

A cadeia de ataque

Etapa 1 - Enumerar contas obsoletas e de alto valor

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -Properties LastLogonDate, PasswordLastSet, MemberOf |
  Select-Object SamAccountName, LastLogonDate, PasswordLastSet |
  Sort-Object LastLogonDate

$groups = @('Domain Admins','Enterprise Admins','Schema Admins','Backup Operators','Account Operators')
foreach ($group in $groups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Get-ADUser -Properties LastLogonDate, PasswordLastSet |
    Select-Object @{N='Group';E={$group}}, SamAccountName, LastLogonDate, PasswordLastSet
}

A Microsoft também documenta Search-ADAccount -AccountInactive -UsersOnly como uma forma prática de encontrar contas de usuário inativas. Use-o como ferramenta de descoberta e depois adicione contexto de privilégio e dependência antes de agir.

Etapa 2 - Priorizar contas com senhas antigas e privilégios altos

Contas com senhas muito antigas, associação permanente a grupos e sem proprietário atual são as primeiras que um atacante tentará validar, pulverizar ou reutilizar.

Priorize contas que atendam a mais de uma condição:

dados de login obsoletos
PasswordLastSet antigo
associação a grupo privilegiado
associação via grupos aninhados
flags de conta como senha nunca expira
nenhum proprietário de negócio ou técnico nomeado

Etapa 3 - Transformar acesso adormecido em acesso privilegiado

Uma conta obsoleta que ainda resulta em Domain Admins, direitos administrativos delegados, privilégios de backup ou amplo acesso a servidores não precisa de um exploit inédito. O privilégio já existe.

Etapa 4 - Persistir por meio de identidades pouco visíveis

Contas adormecidas costumam estar ausentes dos fluxos de trabalho diários, então atividade incomum pode passar despercebida por mais tempo do que deveria. Isso é especialmente verdadeiro para contas administrativas compartilhadas e identidades de serviço que ninguém revisou recentemente.

Detecção

IDs de eventos do Windows

ID do evento	Origem	O que procurar
4624	DC ou estação de trabalho	Login bem-sucedido de uma conta sem atividade recente esperada
4768	DC	Solicitações de TGT para contas que deveriam estar adormecidas
4728 / 4732 / 4756	DC	Alterações em grupos privilegiados envolvendo identidades obsoletas ou pouco claras
4720	DC	Criação de nova conta que se assemelha a um caminho administrativo reciclado ou substituto

A Microsoft documenta o Audit Security Group Management como a subcategoria de auditoria que gera eventos para alterações de associação a grupos de segurança, incluindo eventos de associação a grupos globais, locais e universais. Essa distinção importa quando o caminho privilegiado usa grupos aninhados ou não globais.

Sinais comportamentais

primeiro uso bem-sucedido de uma conta após um longo período de inatividade
associação a grupo privilegiado combinada com idade de senha muito antiga
contas de serviço fazendo login interativo ou a partir de hosts inesperados
contas compartilhadas usadas em vários sistemas sem motivo operacional claro

Consulta de detecção SIEM (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.TargetUserName: (* AND NOT '*$')

Essa consulta precisa de enriquecimento com idade da conta, contexto de privilégio e propriedade esperada. Inatividade sem contexto é apenas uma lista. Inatividade mais privilégio é o achado real.

Enriquecimento de detecção que torna o alerta útil

Um alerta de conta obsoleta deve trazer contexto suficiente para o respondente decidir se desativa, investiga ou escala:

estado atual de ativação/desativação
data da última definição de senha
contexto do último login interativo e de rede conhecido
grupos privilegiados diretos e aninhados
se a conta está marcada como sensível ou protegida
se a conta possui serviços, tarefas agendadas ou credenciais de aplicativo
se a conta tem atividade recente de Kerberos ou NTLM

Sem esse enriquecimento, as equipes normalmente criam uma planilha e adiam as decisões difíceis.

Remediação

Vitória rápida: desative primeiro as contas de usuário obviamente obsoletas e depois trabalhe nas identidades de serviço e compartilhadas com uma revisão baseada em proprietário, em vez de deixá-las ativas indefinidamente.

1. Desativar contas obsoletas

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -SearchBase 'OU=Users,DC=corp,DC=local' `
  -Properties LastLogonDate | ForEach-Object {
    Disable-ADAccount -Identity $_
    Write-Host "Disabled: $($_.SamAccountName) - Last login: $($_.LastLogonDate)"
  }

Para contas de usuário que claramente não deveriam mais existir, desative primeiro, monitore o impacto e exclua depois do período de retenção aceito pela sua equipe de operações. Não exclua objetos privilegiados ou vinculados a serviços como primeira ação, a menos que a dependência já esteja comprovadamente ausente.

2. Reduzir associação a grupos privilegiados

$groups = @('Domain Admins','Enterprise Admins','Schema Admins')
$groups | ForEach-Object {
  Get-ADGroupMember -Identity $_ -Recursive |
    Select-Object @{N='Group';E={$_}}, SamAccountName, distinguishedName
} | Export-Csv privileged_members.csv -NoTypeInformation

Remova o privilégio permanente antes de discutir a exclusão da conta. Uma conta obsoleta sem Domain Admins ou direitos delegados equivalentes ainda é trabalho de limpeza, mas já não é a mesma exposição imediata de Tier-0.

3. Aplicar política mais rígida às identidades privilegiadas

New-ADFineGrainedPasswordPolicy -Name 'PrivilegedAccountsPSO' `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -ComplexityEnabled $true `
  -PasswordHistoryCount 24 `
  -MaxPasswordAge (New-TimeSpan -Days 60) `
  -LockoutThreshold 3

Add-ADFineGrainedPasswordPolicySubject -Identity 'PrivilegedAccountsPSO' `
  -Subjects 'Domain Admins'

A Microsoft documenta as políticas de senha refinadas (fine-grained) como uma forma de aplicar configurações diferentes de senha e bloqueio a diferentes conjuntos de usuários, incluindo configurações mais rígidas para contas privilegiadas. Isso é útil quando contas privilegiadas ainda existem, mas não substitui a remoção de associações desnecessárias.

4. Corrigir o processo de ciclo de vida, não apenas as contas

As causas recorrentes costumam ser operacionais:

offboarding que desativa o acesso ao e-mail mas esquece os grupos do AD
contas de serviço sem proprietário após uma mudança de equipe
contas administrativas de emergência que nunca voltaram a ser revisadas
contas compartilhadas mantidas ativas porque ninguém quer testar a dependência

Uma remediação confiável fecha essas lacunas de processo enquanto a limpeza de contas acontece.

5. Colocar exceções em quarentena em vez de esquecê-las

Se uma conta de baixa atividade precisar permanecer ativada, documente-a como exceção com data de revisão e proprietário nomeado. A exceção deve incluir:

por que a conta precisa permanecer ativada
quais sistemas dependem dela
quais grupos ou direitos delegados ela possui
o que quebraria se ela fosse desativada
qual monitoramento comprova que ela é usada apenas como pretendido

Exceções sem data de expiração são a razão pela qual contas privilegiadas obsoletas retornam.

Validar antes de encerrar o achado

Uma limpeza de contas obsoletas não está concluída quando a planilha parece mais curta. Valide o resultado real do controle.

execute novamente a exportação de contas inativas e confirme que as mesmas identidades de alto risco não estão mais ativadas
confirme que a associação a grupo privilegiado foi removida, e não apenas deixada em um objeto desativado que poderia ser reativado sem alterações mais tarde
revise a atividade recente de 4624 e 4768 para identificar contas usadas novamente após a decisão de limpeza
documente o proprietário, a dependência e a próxima data de revisão de qualquer conta que precise permanecer ativada apesar da baixa atividade
verifique o escopo da política de senha refinada para contas privilegiadas que permanecem ativadas
revise os caminhos de grupos aninhados para garantir que o privilégio não foi preservado indiretamente

Para contas de serviço, a verificação final também deve confirmar que a dependência é real e ainda atual. Se ninguém conseguir provar por que a conta existe, isso é evidência para a desativação definitiva, não para outra exceção.

Como o EtcSec detecta isso

O EtcSec torna esse achado mais útil ao correlacionar inatividade, nível de privilégio, idade da senha e falta de cobertura de política. Isso importa porque uma conta adormecida de baixo valor e uma conta privilegiada adormecida não são o mesmo problema operacional.