Triagem de badPwdCount no AD: qualificar contadores antes de concluir ataque

O que a triagem de badPwdCount no AD pode estabelecer

A triagem de badPwdCount no AD começa com uma pergunta sobre as evidências: que controlador de domínio forneceu o contador desta conta, em que momento e a recolha foi realmente bem-sucedida? Uma captura do diretório pode identificar contas que merecem investigação. Por si só, não pode estabelecer um ataque de dicionário, identificar a origem das falhas nem demonstrar que uma palavra-passe é fraca.

O resultado prático é um registo de análise que relaciona o estado do diretório com a atividade de autenticação. Preserve o achado original, recolha visões comparáveis dos controladores de domínio relevantes, verifique o estado de bloqueio calculado e investigue os registos do percurso de autenticação envolvido. Depois, documente se as evidências sustentam um erro do utilizador, uma aplicação que repete tentativas com um segredo desatualizado, atividade suspeita ou um caso por esclarecer.

Este guia utiliza consultas defensivas ao diretório e um exemplo documentado de desbloqueio direcionado. Os comandos são adaptações ilustrativas para um administrador autorizado com o módulo PowerShell ActiveDirectory e as permissões adequadas. Não foram executados contra um domínio. Não foi realizado qualquer password spraying nem teste de bloqueio deliberado.

O que o contador LDAP realmente mede

A referência da Microsoft sobre atributos de segurança dos utilizadores descreve badPwdCount como um atributo não replicado, mantido separadamente em cada controlador de domínio. Conta tentativas de início de sessão com palavra-passe incorreta na visão desse controlador; a referência também indica que zero pode significar um valor desconhecido. Recomenda consultar todos os DCs para obter uma visão de todo o domínio, em vez de tratar uma única consulta como o total do domínio.

A referência do esquema Bad-Pwd-Count acrescenta que o atributo é reposto num DC específico quando o utilizador inicia sessão com sucesso nesse DC. Por conseguinte, um contador não é um histórico permanente. Um valor inferior numa captura posterior não estabelece que todas as falhas anteriores tenham sido investigadas.

Na triagem, preserve as observações separadas de cada DC antes de criar qualquer resumo. Um número sem o servidor e a hora da recolha perde o contexto necessário para o comparar com outra observação. Um resumo dos contadores também não identifica tentativas distintas num intervalo de tempo escolhido; utilize registos de eventos para construir essa cronologia.

O bloqueio é uma questão separada. A Microsoft documenta UF_LOCKOUT, com o valor 0x0010, em msDS-User-Account-Control-Computed. Solicite explicitamente esse atributo calculado ao analisar o estado atual do AD DS. Não assuma que um booleano do coletor chamado LockedOut deriva necessariamente dele.

Deteção: Recolher visões comparáveis de cada DC

Identificar a conta e o âmbito da recolha

Comece pelo identificador de conta do achado e pelo endpoint original do coletor. Registe o domínio, o DN ou GUID da conta, a versão do coletor, a hora da recolha, os atributos solicitados e quaisquer erros de recolha. Confirme a lista de DCs com o inventário do domínio; o exemplo abaixo com dois servidores não é uma instrução para omitir DCs adicionais.

A documentação de Get-ADUser permite selecionar um utilizador por DN, solicitar propriedades adicionais e especificar um servidor de diretório. Estas consultas adaptadas utilizam um nome de anfitrião de DC explícito, em vez de dependerem da seleção automática do servidor:

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc02.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Substitua o DN e os nomes de anfitrião ilustrativos por valores verificados. Solicitar lockoutTime preserva outro atributo bruto para análise; não utilize apenas um valor diferente de zero como conclusão sobre o bloqueio atual. Interprete o bit de bloqueio calculado apenas quando o respetivo valor tiver sido devolvido com sucesso. Um valor ausente é desconhecido, não falso.

Para um inventário autorizado mais amplo, Get-ADUser também aceita um filtro LDAP. Este exemplo obtém objetos de utilizador ativos e os atributos relevantes de um servidor explicitamente selecionado. Deliberadamente, não restringe a população às contas que já ultrapassam o limiar do produto:

Get-ADUser -LDAPFilter '(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Repita a consulta nos outros DCs verificados dentro do âmbito aprovado. Evite construir um filtro LDAP concatenando um nome de conta sem escape. Para um caso individual, as consultas baseadas na identidade evitam inteiramente essa interpolação.

Preservar a qualidade da recolha juntamente com os valores

Utilize um registo com uma linha por conta e DC. Os campos seguintes são uma recomendação operacional, não uma saída que o detetor fornece automaticamente:

Se um DC estiver indisponível, comunique a lacuna e preserve as consultas bem-sucedidas. Não substitua a linha ausente por zero nem reduza silenciosamente o âmbito declarado. Se as observações diferirem, preserve ambas e investigue os seus momentos e proveniência antes de escolher um resumo. O objetivo é uma comparação auditável, não fazer com que todas as células pareçam idênticas.

Deteção: Associar os eventos ao percurso de autenticação

A captura LDAP seleciona um alvo de investigação; a cronologia de eventos fornece o contexto da atividade. Verifique a cobertura de auditoria, o encaminhamento, a retenção e os sistemas pesquisados antes de interpretar um resultado vazio. Escolha o intervalo de análise com base na cronologia do caso e nas evidências disponíveis. O próprio contador não fornece esse intervalo.

A Microsoft associa estes eventos a Audit Logon/Account Lockout, Audit Kerberos Authentication Service e Audit Credential Validation, respetivamente. Uma pesquisa apenas nos DCs não cobre todos os locais de 4625. O evento 4771 está ausente para contas configuradas para não exigir pré-autenticação Kerberos. O evento 4776 cobre validações bem-sucedidas e falhadas e identifica a estação de trabalho de origem, em vez do servidor de destino ou de um endereço IP.

Leia os códigos adequados a cada evento. Para 4625, preserve ambos os campos de estado, em vez de os reduzir a uma designação genérica de falha. Em 4771, 0x18 significa informação de pré-autenticação inválida, estando uma palavra-passe incorreta documentada como causa. Em 4776, 0xC000006A indica uma palavra-passe incorreta ou mal introduzida, 0xC0000064 um nome de utilizador desconhecido e 0xC0000234 uma conta bloqueada. Uma falha causada por bloqueio é uma evidência diferente da atividade com palavra-passe incorreta que a precedeu.

Construa uma cronologia agrupada por conta, origem, percurso de autenticação e sistema emissor. Preserve referências aos registos originais para que outro analista possa verificar a conclusão. Não some todas as linhas de diferentes tipos de eventos para apresentar uma contagem de tentativas independentes de adivinhação: primeiro determine quais os registos que descrevem o mesmo fluxo de autenticação.

Investigue para além da conta selecionada quando as origens ou os momentos o justificarem. O contexto de correlação entre várias contas e tentativas lentas e espaçadas do nosso guia de password spraying explica essa investigação mais ampla. Aqui, a primeira tarefa continua a ser qualificar a observação do diretório que deu origem ao caso.

Correção: Resolver a causa antes de encerrar o achado (Remediation)

Preservar evidências e testar explicações concorrentes

Preserve os valores LDAP iniciais e os registos de eventos relevantes antes de alterar credenciais ou o estado da conta. Identifique o responsável pela conta e as aplicações que a utilizam. Pergunte sobre alterações recentes de palavra-passe, alterações na configuração de serviços, tarefas agendadas, acesso remoto e a experiência relatada pelo utilizador. Utilize essas respostas para selecionar os sistemas a inspecionar, não como substituto dos respetivos registos.

A matriz de decisão seguinte é um método de triagem proposto. Nenhuma destas explicações é calculada apenas a partir de badPwdCount:

Para uma carga de trabalho que utiliza uma credencial desatualizada, coordene a alteração da credencial com todos os consumidores conhecidos. Atualizar apenas uma tarefa agendada, deixando por resolver outro cliente que repete tentativas, não é uma correção completa. Verifique a própria configuração da carga de trabalho e os registos de autenticação subsequentes antes de lhe atribuir conclusivamente as falhas.

Trate nomes invulgares como um sinal diferente. A nossa análise de nomes de contas distingue um indicador estático de nomenclatura da atividade de início de sessão. Um nome de conta genérico não estabelece que palavra-passe foi tentada, quem a submeteu ou se este caso é malicioso.

Desbloquear apenas a conta analisada quando adequado

Se o estado calculado confirmar o bloqueio e o administrador responsável tiver aprovado a reposição do acesso após analisar a causa, utilize uma operação direcionada. Este exemplo adapta os parâmetros de identidade e servidor documentados para Unlock-ADAccount:

Unlock-ADAccount -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Este é um exemplo que altera o estado, não um comando executado para este artigo. Confirme a identidade e o servidor antes de o utilizar. Não encaminhe todo o inventário para um desbloqueio em massa. Um desbloqueio não corrige um segredo de aplicação desatualizado nem resolve atividade suspeita; utilize as evidências para escolher a resposta adequada.

Quando a investigação estabelecer um comprometimento ou uma ameaça contínua, siga o procedimento de resposta a incidentes da organização para contenção, alterações de credenciais e sistemas afetados. Um contador do diretório não é suficiente para selecionar automaticamente essas ações. Do mesmo modo, não flexibilize os controlos de bloqueio apenas para reduzir os achados sem analisar as consequências para a segurança e a disponibilidade.

Verificar a correção e documentar a conclusão

Repita as mesmas consultas ao diretório, com a mesma identidade de conta e DCs explícitos, após a alteração aprovada. Preserve novamente os carimbos de data/hora e a qualidade da recolha. Analise os registos relevantes durante um período de observação declarado e peça ao responsável que confirme que a aplicação ou o fluxo de trabalho do utilizador afetado funciona como esperado.

Encerre o caso com uma declaração sustentada: uma aplicação identificada que repetia tentativas foi corrigida; um problema de acesso do utilizador foi resolvido; a atividade foi escalada como suspeita; ou a cobertura continua incompleta. Registe as referências de eventos que sustentam a conclusão, as explicações excluídas, as evidências em falta, as ações, o responsável e a data de acompanhamento. Deixar de ultrapassar o limiar do produto é um contexto útil, mas o encerramento deve explicar a causa e as evidências da decisão.

Como a EtcSec deteta isto

A verificação do etc-collector é PASSWORD_DICT_ATTACK_RISK, categoria Password, gravidade Medium. O Detect() analisado encontra-se em public/internal/audit/detectors/ad/password/dict-attack-risk.go:24. Exclui utilizadores com Disabled=true e seleciona cada utilizador restante quando BadPasswordCount > 3 ou LockedOut=true.

Count é o número de utilizadores selecionados, não a soma de tentativas falhadas, o número de sistemas de origem nem o número de ataques. Cada utilizador contribui uma vez, mesmo quando ambas as condições correspondem. A implementação devolve o achado mesmo a zero; as entidades afetadas são incluídas quando são solicitados detalhes e existe pelo menos um utilizador selecionado.

O provider determina o que a verificação pode realmente observar:

• parser.go:164 lê badPwdCount através de getIntAttr; essa função auxiliar, na linha 290, devolve zero para um valor ausente e ignora erros de strconv.Atoi.
• client.go:460 obtém utilizadores do contexto LDAP escolhido. Este percurso não agrega observações de todos os DCs.
• parser.go:189 deriva LockedOut do bit 0x0010 em userAccountControl. A lista predefinida de atributos de utilizador não solicita msDS-User-Account-Control-Computed. Embora lockoutTime seja recolhido, não é utilizado para calcular este booleano.

Por conseguinte, este ramo de bloqueio não deve ser apresentado como uma avaliação calculada fiável do bloqueio atual no AD DS moderno. Solicite independentemente o atributo calculado ao fazer a triagem do achado. Preserve uma divergência entre o booleano do coletor e essa consulta, em vez de tratar a designação do coletor como autoritativa.

A verificação não dispõe de uma janela temporal, origem de autenticação, correlação de eventos, avaliação da política de bloqueio efetiva nem medição da qualidade da palavra-passe. O limiar é um predicado do produto, não um valor de política do AD DS. Três ou menos falhas registadas não estabelecem segurança, e uma contagem positiva não estabelece um ataque.

Existe uma razão concreta para investigar contadores sem assumir a sua causa. O repositório público SafeSpray e o seu código-fonte main.go utilizam um filtro LDAP que contém badPwdCount=0 para selecionar utilizadores antes de tentativas de autenticação SMB. Isto demonstra como uma ferramenta pública utiliza contadores, não prova que tenha sido executada no seu ambiente nem que a sua alegação de evitar bloqueios seja fiável. O código foi lido; a ferramenta não foi executada.