Padroes de senha nomes de contas Active Directory

O que os nomes de contas comuns realmente indicam

A expressão padroes de senha nomes de contas Active Directory descreve uma heurística de nomes, não um teste de senhas. Uma conta habilitada chamada admin, test ou temp merece uma revisão de responsabilidade e exposição. O nome não revela a senha, não prova que ela é fraca nem demonstra que alguém atacou a conta. Essa distinção decorre diretamente da implementação de PASSWORD_COMMON_PATTERNS em public/internal/audit/detectors/ad/password/common-patterns.go:26.

Um nome genérico pode facilitar a inclusão de uma identidade numa lista de alvos construída por suposição. Isso é uma inferência sobre a seleção de candidatos, não uma classificação medida das primeiras escolhas dos atacantes. A antiga referência da Microsoft sobre renomear Administrator descreve um benefício modesto de alterar esse nome de conta conhecido, juntamente com a limitação do seu SID conhecido. Ela não valida uma classificação universal de admin, test e temp nem os quinze padrões do coletor.

Portanto, a pergunta útil é: o que essa identidade faz, quem é responsável por ela e quais controles protegem os seus caminhos reais de autenticação? Trate o achado como uma fila de revisão. Um nome de serviço descritivo pode apoiar operações legítimas; um nome que parece pessoal ainda pode ocultar um tratamento inadequado das credenciais. O detector não consegue distinguir esses casos porque examina nomes, não segredos nem atividade.

Como funciona o password spraying

O guia da Microsoft para classificar password spraying descreve um pequeno conjunto de senhas frequentemente usadas, testadas em muitas contas. Isso difere de tentar repetidamente muitas senhas contra uma única identidade. A nomenclatura das contas diz respeito à lista de alvos; o password spraying diz respeito às tentativas de autenticação. Um inventário de nomes correspondentes estabelece o primeiro aspecto, não o segundo.

O playbook de investigação de password spraying também distingue o comprometimento de senha do comprometimento de conta. Um atacante pode descobrir a senha correta enquanto a MFA impede o acesso. Os investigadores devem examinar autenticações bem-sucedidas e interrompidas, resultados de MFA e atividade posterior, em vez de tratar toda falha na conclusão de uma entrada como prova de que a senha continuou desconhecida.

A cadeia de ataque a investigar

Uma investigação defensável segue a progressão documentada nesses playbooks da Microsoft: identificar possíveis contas-alvo e caminhos de autenticação, correlacionar tentativas suspeitas, determinar se uma senha foi aceita e examinar qualquer acesso resultante. Nomes genéricos podem orientar a primeira etapa. Eles não fornecem evidências para as demais. Uma atividade lenta e discreta pode permanecer abaixo dos limiares de bloqueio; portanto, a ausência de bloqueio não descarta automaticamente a suspeita.

Para o mecanismo mais amplo, a enumeração de nomes de usuário, a detecção e os controles nos dois ambientes, consulte o nosso guia de password spraying para Active Directory e Entra ID. Este artigo concentra-se no predicado exato de nomes, nas suposições equivocadas sobre ele e nas evidências necessárias para resolver um achado de nomenclatura.

Nenhuma lista de nomes é uma lista completa de alvos de spraying. Revise identidades fora desses padrões quando a telemetria de autenticação justificar isso. Por outro lado, não classifique toda conta correspondente como comprometida: o processo de classificação da Microsoft exige explicitamente separar atividade maliciosa de falsos positivos.

Medir as contas e a política efetiva

1. Criar um inventário sem coletar segredos

Os comandos seguintes são exemplos documentados ou adaptações de parâmetros para um administrador autorizado. Eles não foram executados contra um domínio para este artigo. Use o módulo ActiveDirectory, as permissões de diretório adequadas e o contexto de domínio ou servidor pretendido. contoso.com e os nomes das contas são ilustrativos; verifique o alvo antes de usar um comando que altere o ambiente.

Get-ADUser documenta a filtragem, a recuperação de contas habilitadas e a solicitação de propriedades adicionais. Este filtro defensivo adapta essas capacidades aos treze nomes completos, a uma substring e a um sufixo do coletor. A lista vem do detector, não de um exemplo da Microsoft que reconheça esses nomes como evidência de senhas fracas.

Get-ADUser -Filter 'Enabled -eq $true -and (SamAccountName -eq "admin" -or SamAccountName -eq "administrator" -or SamAccountName -eq "test" -or SamAccountName -eq "user" -or SamAccountName -eq "guest" -or SamAccountName -eq "temp" -or SamAccountName -eq "default" -or SamAccountName -eq "support" -or SamAccountName -eq "service" -or SamAccountName -eq "backup" -or SamAccountName -eq "demo" -or SamAccountName -eq "sa" -or SamAccountName -eq "dba" -or SamAccountName -like "*password*" -or SamAccountName -like "*123")' -Properties DisplayName,Enabled

DisplayName apoia aqui a revisão humana. Ele não participa do detector. Uma conta cujo nome de exibição é Test, mas cujo sAMAccountName é alex.smith, não é selecionada pelo padrão test. Por outro lado, User123 corresponde ao sufixo, embora não corresponda à expressão de nome completo user. Esses exemplos seguem as regras de correspondência do código.

Registre responsável, finalidade da conta, dependências e decisão de revisão junto com o inventário. Antes de comparar uma contagem de resultados local com um resultado do coletor, concilie o escopo do diretório, o momento da coleta, o estado de habilitação e o comportamento de correspondência. Não suponha que a lista curta de nomes de um achado represente toda a população afetada.

2. Ler a política do domínio

Isto adapta o exemplo 3 de Get-ADDefaultDomainPasswordPolicy a um domínio ilustrativo:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com

Revise MinPasswordLength, ComplexityEnabled, PasswordHistoryCount, LockoutThreshold, LockoutDuration e LockoutObservationWindow. Esses são dados de política. O nome da conta não fornece um valor para nenhum deles. Uma leitura da política de todo o domínio também não estabelece se um usuário selecionado tem um Password Settings Object resultante diferente.

3. Inventariar políticas de senha refinadas

Use a capacidade de filtragem documentada por Get-ADFineGrainedPasswordPolicy para recuperar os objetos de política:

Get-ADFineGrainedPasswordPolicy -Filter *

Inspecione AppliesTo e Precedence, além das configurações efetivas. O guia da Microsoft sobre políticas de senha refinadas informa que essas políticas se aplicam a objetos de usuário e grupos de segurança globais. Elas não se aplicam diretamente a uma OU. Portanto, colocar uma conta genérica numa OU administrativa não estabelece, por si só, uma política de senha efetiva mais forte.

4. Verificar a política resultante do usuário selecionado

Isto adapta o exemplo de identidade em Get-ADUserResultantPasswordPolicy:

Get-ADUserResultantPasswordPolicy -Identity test

Esse cmdlet recupera o PSO resultante do usuário. Um PSO atribuído diretamente ao usuário tem prioridade sobre PSOs herdados por grupos de segurança globais. Se vários PSOs se aplicarem diretamente, vence o menor valor de precedência entre eles; os PSOs vinculados a grupos só são comparados quando nenhum se aplica diretamente. Se nenhum PSO se aplicar, avalie o padrão do domínio. Um resultado de PSO vazio não é uma medição da força da senha.

O nosso guia de segurança de senhas no Active Directory examina seis outras dimensões: indicadores de expiração, fraqueza de política, indicadores de senha não obrigatória, segredos expostos na descrição, WDigest e NTLMv1, além de FGPP e tratamento de contas de serviço. Elas são distintas deste predicado de nomes. Não substitua a revisão desses controles por um achado de nomenclatura resolvido nem copie valores de política de demonstração como baseline de segurança.

Detecção: correlacionar 4625, 4740 e 4771

Coletar os sistemas e campos corretos

Construa as evidências em torno do caminho de autenticação. O evento 4625 é registrado no computador onde ocorre a falha de logon; pode ser um controlador de domínio, servidor membro ou estação de trabalho. Coletar apenas um DC não garante cobertura de todos os logons malsucedidos. Verifique a cobertura de Audit Logon e Audit Account Lockout conforme as subcategorias documentadas do evento.

Para contas de domínio, inclua os logs Security dos DCs para o evento 4740, em Audit User Account Management, e o evento 4771, em Audit Kerberos Authentication Service. A Microsoft documenta que 4771 ocorre apenas em DCs e não aparece quando a conta não exige pré-autenticação Kerberos.

Interpretar os códigos de falha com precisão

A referência de monitoramento de 4625 identifica 0xC000006A como senha incorreta ou digitada incorretamente, 0xC0000064 como nome de conta incorreto ou com erro de grafia e 0xC000006D como nome de usuário ou informação de autenticação incorretos. A documentação do evento identifica 0xC0000234 como conta bloqueada. Preserve Status e SubStatus; não reduza a investigação a um único rótulo genérico de falha.

Para 4771, 0x18 é KDC_ERR_PREAUTH_FAILED: informação de pré-autenticação inválida, com senha incorreta documentada como uma causa. 0x6 é KDC_ERR_C_PRINCIPAL_UNKNOWN, indicando que o cliente não foi encontrado na base de dados Kerberos. 0x12 é KDC_ERR_CLIENT_REVOKED, indicando que as credenciais do cliente foram revogadas. Não equipare automaticamente 0x12 apenas a bloqueio de conta nem trate esses códigos como intercambiáveis com os campos de status de 4625.

Essas distinções ajudam a separar tentativas com nomes desconhecidos, tentativas com senhas incorretas e consequências de bloqueio. Mesmo assim, não revelam a senha candidata. Uma regra de correlação construída a partir desses eventos não pode provar que um mesmo segredo foi enviado a todas as contas.

Correlacionar o comportamento e testar a explicação

Uma proposta editorial de detecção é agrupar falhas por janela de tempo e origem, contar contas-alvo distintas e associar essas identidades ao inventário de nomes. Estabeleça uma baseline local antes de escolher uma janela ou um limiar de alerta. Essa é uma proposta a implementar e validar, não uma consulta copiada da Microsoft nem um limiar medido para o seu ambiente.

Compare o padrão com erros esperados dos usuários e serviços que tentam novamente uma credencial antiga. Amplie a busca quando as origens variarem e examine então entradas bem-sucedidas ou interrompidas e atividade posterior incomum. Os playbooks de spraying da Microsoft apoiam a correlação de cronologia, origem, conta e atividades subsequentes. Uma campanha pode permanecer abaixo do limiar de bloqueio; exigir 4740 deixaria, portanto, uma lacuna de detecção.

Num ambiente híbrido, inclua os registros de entrada e MFA do Entra e os logs do provedor de identidade federado, quando aplicável. O playbook de investigação explica que a localização dos logs depende de autenticação gerenciada ou federada. Uma senha aceita seguida de MFA malsucedida merece investigação mesmo quando não houve acesso final à aplicação. Um relatório de nomes de contas sem achados não pode resolver esse incidente.

Correção: esclarecer finalidade, exposição e controles (Remediation)

1. Revisar cada identidade com o seu responsável

Use um registro de revisão para distinguir identidades humanas, compartilhadas, de teste, de serviço, internas e de recuperação. Essa classificação é uma recomendação operacional, não algo calculado pela regex. Pergunte o que ainda exige a conta, quem pode usá-la, quais caminhos de autenticação a aceitam e o que depende do seu nome ou das suas credenciais atuais.

Prefira acesso humano atribuível a indivíduos e documente exceções, responsáveis e datas de expiração para necessidades temporárias. Revise os privilégios separadamente: support não estabelece permissões de suporte técnico, e backup não estabelece a quais recursos a conta pode acessar. O código de nomes não tem predicado de participação em grupos nem de privilégios.

Para testes, o guia da Microsoft sobre ambientes de teste Entra aborda tenants dedicados ou recursos e registros de aplicações devidamente isolados. É um procedimento para aplicações Entra, não uma receita de implantação nativa de AD. Aplicar o seu princípio de isolamento a identidades de teste AD é uma recomendação de governança: defina um limite de teste e um ciclo de vida adequados ao seu domínio.

2. Desativar contas desnecessárias após revisar dependências

Para uma conta comum confirmada como desnecessária, primeiro verifique com o responsável os serviços dependentes, tarefas agendadas, aplicações e mecanismos de recuperação. Depois planeje uma ação de desabilitação direcionada. Isto adapta o exemplo 1 de Disable-ADAccount a uma identidade de teste ilustrativa já revisada:

Disable-ADAccount -Identity test

Não use o inventário de nomes como entrada para uma operação de desabilitação em massa. O filtro não consegue informar se uma identidade é operacionalmente essencial. Uma renomeação planejada é outra possível ação administrativa, após verificar os consumidores do nome atual. O exemplo seguinte usa os parâmetros documentados de identidade e SamAccountName de Set-ADUser:

Set-ADUser -Identity test -SamAccountName app-validation

Isso altera o nome da conta SAM. Não altera a senha, não reduz permissões, não exige MFA nem prova que a conta deixou de ser descobrível. Escolha nomes que favoreçam clareza operacional e responsabilização; uma contagem menor de correspondências de regex não é justificativa suficiente para renomear.

3. Preservar o papel de recuperação do Administrator interno

Um Administrator habilitado corresponde ao detector porque não há exceção para SID nem para conta interna. Determine qual conta está sendo revisada antes de aplicar qualquer decisão de desativação. Não desabilite indiscriminadamente o Administrator interno do domínio porque ele aparece na lista de nomes.

O guia da Microsoft sobre o Administrator interno reserva o seu uso à construção inicial e à possível recuperação de desastre. A página removeu explicitamente a recomendação anterior de desabilitação porque a recuperação da floresta usa essa conta, inclusive para logon sem um servidor de Catálogo Global. Em vez disso, descreve restrições e auditoria do uso, de redefinições de senha e de alterações na conta.

Aplique restrições por meio de um plano de recuperação revisado e dentro do escopo documentado. A página alerta contra vincular a GPO de restrições no nível do domínio, pois isso pode tornar Administrator inutilizável durante a recuperação. Não transforme as afirmações históricas sobre bloqueio da antiga página de renomeação de Administrator numa alegação não verificada sobre todas as versões e configurações de Windows.

4. Usar gMSAs para serviços AD e identidades gerenciadas para Azure

Para serviços Windows que usam usuários de domínio comuns, avalie uma migração para gMSA quando houver suporte. A documentação da Microsoft sobre contas de serviço do Windows Server descreve gerenciamento automático de senhas e uma identidade de serviço compartilhada entre vários servidores. Antes da migração, revise a compatibilidade do serviço, os hosts autorizados a recuperar credenciais, as permissões de recursos e os SPNs. Essa recomendação trata do gerenciamento de credenciais de serviço, não de toda conta humana com um nome correspondente.

Para cargas de trabalho Azure, o guia da Microsoft sobre contas de serviço na nuvem favorece identidades gerenciadas sempre que possível e entidades de serviço quando necessário, em vez de contas de serviço Entra baseadas em usuários. Mantenha essa escolha de identidade na nuvem distinta de uma implantação de gMSA no AD.

Quando uma aplicação realmente exige credenciais compartilhadas, o guia do Entra sobre compartilhamento de contas descreve SSO baseado em senha que intermedeia o acesso por identidades individuais. Os usuários não precisam receber a senha compartilhada; os administradores podem revogar acesso, exigir MFA e revisar registros de entrada. A rotação de senha depende do suporte da aplicação. Essa é uma opção específica de acesso a aplicações, não uma solução universal para logons AD compartilhados.

5. Verificar FGPP, bloqueio e MFA nos caminhos reais

Selecione as configurações de senha e bloqueio para a população de contas e o risco, e depois verifique a política resultante com os comandos de inventário acima. FGPP pode diferenciar políticas para usuários e grupos de segurança globais. Não implante o exemplo LockoutThreshold=0 da Microsoft apenas porque aparece numa demonstração: sintaxe de política e recomendações de segurança têm finalidades distintas.

A referência sobre o limiar de bloqueio de conta descreve o equilíbrio entre resistência a tentativas de adivinhar senhas e negação de serviço por bloqueios deliberados. A discussão sobre a baseline de Windows usa dez tentativas inválidas como possível ponto de partida, explicitamente sem um limiar universal. Revise em conjunto limiar, duração, janela de redefinição, operações de desbloqueio e monitoramento.

O bloqueio inteligente do Entra é um controle separado do bloqueio AD DS. Ele distingue locais conhecidos e desconhecidos e acompanha hashes recentes de senhas incorretas; esse acompanhamento de hashes não está disponível com autenticação de passagem. Para PTA, a Microsoft orienta um limiar Entra menor, um limiar AD DS pelo menos duas ou três vezes maior e uma duração Entra mais longa. Verifique o modo de autenticação e as configurações reais, em vez de copiar um exemplo como regra universal.

Exija MFA nos caminhos expostos compatíveis e revise a autenticação legada conforme recomenda o playbook de investigação de spraying. Uma política de MFA Entra não faz com que caminhos tradicionais de autenticação AD passem automaticamente a exigir MFA. Quando a telemetria estabelecer comprometimento de senha ou conta, siga a resposta a incidentes, incluindo alterações de credenciais e revogação apropriada de sessões/tokens, em vez de encerrar o caso após renomear uma conta.

Como a EtcSec detecta isso

A verificação do etc-collector é PASSWORD_COMMON_PATTERNS, categoria Password, severidade High. O seu Detect() começa em public/internal/audit/detectors/ad/password/common-patterns.go:26; as quinze expressões exatas são declaradas nas linhas 28–44:

(?i)^admin$
(?i)^administrator$
(?i)^test$
(?i)^user$
(?i)^guest$
(?i)^temp$
(?i)^default$
(?i)^support$
(?i)^service$
(?i)^backup$
(?i)^demo$
(?i)password
123$
(?i)^sa$
(?i)^dba$

A implementação percorre os usuários coletados e exclui apenas contas Disabled. Ela converte SAMAccountName em minúsculas e verifica essas expressões. Treze são correspondências de nome completo; password corresponde em qualquer posição, e 123$ corresponde ao final. Assim, admin01, test1, temp-user e svc-sql não são selecionados apenas por esses nomes; resetPasswordHelp e User123 são selecionados.

Ela adiciona uma conta na primeira expressão correspondente e interrompe o laço interno. Uma conta que corresponde a mais de uma expressão contribui apenas uma vez. Não há exceção baseada em SID/RID, OU, grupo privilegiado, finalidade de serviço ou lista de permissões nessa implementação.

Count inclui todos os usuários habilitados correspondentes. Details.affectedAccountNames contém no máximo dez nomes, mesmo sem IncludeDetails. Portanto, dez nomes exibidos não significam que existam apenas dez contas correspondentes. AffectedEntities é adicionado quando detalhes são solicitados e a contagem é positiva; o próprio achado é retornado mesmo com zero.

O detector não lê displayName, nenhuma senha nem nenhum hash de senha. Ele não mede entropia de senhas, não realiza autenticação, não avalia política de bloqueio nem MFA e não inspeciona atividade para provar uma tentativa ou sucesso de spraying. O seu texto descritivo sugere risco de senhas padrão, mas essas sugestões não são predicados no código.

Validar o resultado

Repita as mesmas leituras de inventário e de política efetiva após alterações aprovadas. Documente as exceções mantidas e os requisitos de recuperação e confirme com os responsáveis que serviços e aplicações continuam funcionando. Revise os registros de autenticação relevantes em busca de atividade suspeita remanescente, usando as orientações de investigação da Microsoft.

Encerre cada revisão com o resultado que ela realmente estabelece: identidade desnecessária desativada, dependência migrada, política efetiva verificada ou exceção mantida com justificativa. Nomenclatura, política de senha, aplicação de controles de acesso e evidências de ataque respondem a perguntas diferentes. Uma revisão de nomes concluída deve tornar essas respostas mais claras sem alegar que uma regex testou um segredo.