Atribuir uso de conta partilhada AD: provas de logon

O que a atribuição de atividade de contas AD partilhadas deve estabelecer

Atribuir uso de conta partilhada AD começa com uma distinção: uma conta de diretório é uma entidade de segurança, enquanto o operador é a pessoa que a utiliza. Uma conta chamada shared-support pode merecer uma revisão, mas o nome não prova que várias pessoas conheçam as suas credenciais. Um logon com essa conta pode estabelecer a utilização da conta sem identificar a pessoa por trás dela.

Trate um resultado baseado no nome como uma fila de investigação. Para cada conta selecionada, estabeleça o responsável, a finalidade real, os utilizadores autorizados, os sistemas dependentes e as provas de logon disponíveis. Mantenha a observação do diretório, as provas de autenticação e a atribuição a uma pessoa como conclusões distintas. Uma dependência legítima de serviço e uma sessão humana sem atribuição exigem respostas diferentes, mesmo quando utilizam o mesmo nome de conta.

A nossa revisão de classificação, responsabilidade e expiração de contas explica como esclarecer nomes genéricos e a finalidade das contas. Este guia acrescenta os requisitos de prova para atribuir atividade: que identidade cada evento Windows descreve, onde a correlacionar e o que continua desconhecido antes da desativação definitiva.

Como funciona o processo de qualificação

1. Crie um registo de investigação para cada conta

Registe o domínio da conta, o nome SAM, o SID, o estado atual de ativação, o momento da recolha, o responsável e a utilização prevista. Liste serviços conhecidos, tarefas agendadas, aplicações, processos administrativos e requisitos de recuperação. O responsável deve resolver o caso; a responsabilidade, por si só, não estabelece quem efetuou um determinado logon.

Pergunte ao responsável que pessoas podem obter ou utilizar as credenciais e através de que vias de acesso. Separe a autorização documentada da utilização observada. Se o responsável afirmar que apenas uma pessoa utiliza a conta, guarde essa declaração como uma afirmação a verificar com provas. Se ninguém conseguir identificar o responsável, mantenha o caso aberto com uma pessoa identificada como responsável pelo próximo passo da investigação.

Reveja também as contas desativadas. O detetor inclui utilizadores desativados cujos nomes correspondem aos padrões, pelo que a sua contagem não representa o número de sessões partilhadas ativas. Preserve as provas históricas disponíveis e verifique as dependências antes de decidir se um objeto desativado pode ser retirado de serviço. O estado atual do diretório não estabelece o que aconteceu numa janela de investigação anterior.

2. Defina os limites das provas antes da pesquisa

Identifique as estações de trabalho ou os hosts de gestão que iniciam a atividade, os servidores de destino e o intervalo de tempo relevante. Verifique quais desses sistemas geram e encaminham os eventos Security necessários. Ambas as páginas de referência enquadram os eventos em Audit Logon. A recolha apenas nos controladores de domínio não estabelece a cobertura de todas as sessões de destino ou de todos os processos iniciadores.

Para um inventário mais amplo das políticas de auditoria e dos eventos, utilize o nosso guia de eventos de monitorização do Active Directory e respetiva recolha. Neste caso, a questão operacional é mais específica: a equipa consegue recuperar as provas relativas a esta conta, nestes hosts, durante este intervalo, preservando os campos de identidade?

Documente a retenção local, as lacunas de encaminhamento, o comportamento do parser, as limitações de acesso e a sincronização dos relógios antes de tirar uma conclusão negativa. Preserve o XML original do evento ou um registo equivalente sem perda de informação, juntamente com os campos normalizados. Uma coluna SIEM chamada Account pode ocultar se o parser selecionou Subject ou Target; valide esse mapeamento com o próprio evento.

Deteção: separar as identidades de 4624 e 4648

3. Leia a sessão bem-sucedida no destino

A referência da Microsoft para o evento 4624 define-o como a criação de uma sessão de logon no computador ao qual se acedeu. Subject descreve a conta que comunica ou invoca o logon; New Logon descreve a conta para a qual a sessão foi criada. Não atribua a sessão a uma pessoa lendo apenas Subject.

Mantenha estes campos de evento separados no registo de investigação:

Por exemplo, Logon Type 3 descreve um logon de rede, 4 um logon batch, 5 um logon de serviço e 10 um logon interativo remoto. Estas descrições ajudam a verificar se a utilização observada corresponde à finalidade declarada pelo responsável. Não são vereditos de atribuição humana: uma sessão de rede pode ser iniciada por automação e uma sessão de serviço não identifica a pessoa que a configurou.

A referência de 4624 também explica que a disponibilidade do endereço, da porta e da estação de trabalho depende do contexto e do protocolo de autenticação. Um campo de origem vazio deve continuar vazio no registo de provas; não o preencha a partir de outro evento apenas porque o nome da conta coincide. O SID da conta partilhada identifica essa entidade, não qual dos seus possíveis utilizadores atuou.

4. Leia as credenciais explícitas sem trocar as identidades

A referência da Microsoft para o evento 4648 descreve um processo que tenta um logon com credenciais explicitamente fornecidas. Isto também ocorre durante atividades de rotina, incluindo tarefas agendadas e RUNAS. Subject é a conta requerente; Account Whose Credentials Were Used é a identidade das credenciais. Podem ser contas diferentes.

Um registo 4648 com um Subject nominal e um Target partilhado é uma prova útil de que esse contexto de segurança nominal solicitou a utilização das credenciais partilhadas. Não estabelece, de forma independente, a pessoa que controla o contexto. Também descreve uma tentativa; não a transforme num logon bem-sucedido no destino sem provas de apoio. O XML do evento lista o nome de destino, o domínio e o GUID; não assuma que fornece um SID de destino apenas porque um esquema normalizado tem uma coluna para esse valor.

5. Correlacione dentro do host e da sessão corretos

Comece pelo host, pelo carimbo temporal e pela secção de identidade relevantes. As orientações da Microsoft sobre correlação de Logon ID limitam a unicidade a um computador entre reinícios. Mantenha as junções por Logon ID dentro desse host e desse intervalo entre arranques, não em todo o domínio. Para um 4648 iniciador, procure a sessão local 4624 correspondente utilizando o contexto de logon de Subject de 4648 e o contexto New Logon de 4624. Juntar Subject com Subject indiscriminadamente responde a uma questão diferente.

Preserve ambos os GUIDs de 4648. As referências da Microsoft descrevem a correlação 4624/4648 no mesmo computador quando o GUID relevante está disponível. Não selecione automaticamente um GUID de Subject nem um GUID de credenciais apenas porque um parser renomeou ambos para um único campo genérico. Estabeleça que sessão a correspondência proposta representa e guarde a base dessa decisão.

Um GUID composto apenas por zeros representa uma prova indisponível, não uma sessão comum a todos os registos com zeros. Entre hosts iniciadores e de destino, construa uma cronologia a partir da conta/domínio, do host de destino, do contexto de origem disponível e dos carimbos temporais. Classifique essa associação como contextual quando não existir uma ligação de sessão fiável. Nunca equipare Logon IDs hexadecimais idênticos em duas máquinas.

6. Registe a confiança e as explicações contraditórias

Utilize categorias explícitas de confiança como convenção de revisão, não como sistema de pontuação da Microsoft. A utilização da conta pode estar confirmada enquanto a atribuição humana continua por resolver. Mantenha colunas separadas para essas conclusões, em vez de atribuir uma única pontuação tranquilizadora a todo o caso.

As provas independentes podem consistir num gateway de acesso com autenticação individual ou num registo de levantamento de credenciais, se a organização dispuser destes mecanismos e os seus carimbos temporais e identidades puderem ser verificados. Uma lista de pessoas, um endereço IP ou a recordação do responsável, por si só, são provas mais fracas. Registe alternativas como automação agendada ou outra pessoa a controlar a sessão iniciadora; documente por que razão a explicação retida tem melhor sustentação.

Este é um processo de investigação, não uma consulta apresentada como executada. Não foi realizado qualquer teste num host ou SIEM para este guia. Valide os mapeamentos de campos e as correlações com atividade controlada e autorizada antes de confiar neles operacionalmente.

Correção: restabelecer a responsabilização antes da retirada de serviço (Remediation)

7. Substitua o acesso humano partilhado por acesso nominal

Para processos humanos, planeie o acesso através de identidades individuais de operadores e verifique se os registos preservam a identidade individual até à ação privilegiada. Mudar shared-support para um nome com aparência pessoal não cria responsabilização. Confirme quem pode obter credenciais, como o acesso é aprovado e como pode ser removido quando a função de uma pessoa muda.

Para automação, documente a carga de trabalho e o seu responsável separadamente dos operadores humanos. Reveja as opções de migração com a equipa da aplicação, em vez de impor a um serviço um modelo de identidade concebido para utilização interativa. O objetivo é remover a partilha desnecessária de credenciais, preservando dependências legítimas e um rasto de acesso que possa ser revisto.

Se uma substituição imediata for impossível, documente uma exceção temporária com responsável, finalidade aprovada, utilizadores autorizados, hosts permitidos, provas compensatórias, expiração e marco de migração. Uma exceção sem um rasto de atribuição utilizável deve dizê-lo explicitamente. Uma expiração futura não torna atribuível a sessão ambígua de hoje.

8. Desative apenas uma identidade revista

Antes de retirar a conta de serviço, obtenha a avaliação de dependências do responsável, verifique os mecanismos de recuperação, preserve os registos da investigação e acorde as responsabilidades de validação e reversão. Decida separadamente se as provas sustentam uma resposta a comprometimento. Um resultado baseado apenas no nome não estabelece comprometimento nem justifica uma operação sobre credenciais em todo o ambiente.

Para uma conta comum cuja retirada de serviço foi aprovada, o exemplo seguinte é uma adaptação dos parâmetros documentados de Disable-ADAccount. O DN e o controlador de domínio com capacidade de escrita são ilustrativos; verifique ambos antes de os utilizar. Estes exemplos exigem o módulo ActiveDirectory e permissões de diretório e não foram executados para este artigo.

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -WhatIf

-WhatIf apresenta uma pré-visualização da operação; não testa se uma aplicação deixará de funcionar. Após a revisão das dependências e na janela de alteração aprovada, a ação direcionada correspondente é:

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Não encaminhe todas as correspondências de nome por um pipeline para uma operação de desativação. Verifique o estado resultante do diretório e os processos dependentes após a alteração aprovada. A eliminação exige uma decisão separada sobre retenção e recuperação; nem uma contagem baixa do detetor nem um intervalo sem eventos fornecem essa autorização.

9. Encerre com a decisão que as provas sustentam

Responda a três perguntas para cada conta: que hosts e políticas de auditoria forneceram as provas necessárias; se existe uma identidade de operador nominal e independente; e que dependências exigem uma exceção temporária antes da remoção. Se faltar uma resposta, mantenha a pergunta por resolver, o responsável e a próxima data de revisão.

Encerre com um resultado concreto: acesso humano substituído, dependência da carga de trabalho migrada, identidade desnecessária desativada ou exceção temporária mantida. Anexe a justificação da confiança e as lacunas de prova. Uma revisão concluída deve explicar tanto a decisão operacional como os limites de qualquer alegação de atribuição histórica.

Como o EtcSec deteta este problema

A verificação SHARED_ACCOUNT do etc-collector é um resultado da categoria Accounts com gravidade Medium. No commit do collector 0423094759d50002457031317098417993e19510, Detect() em public/internal/audit/detectors/ad/accounts/patterns/shared-account.go:45 verifica o SAMAccountName dos utilizadores recolhidos em relação a quatro prefixos, sem distinguir maiúsculas de minúsculas:

(?i)^shared
(?i)^common
(?i)^generic
(?i)^guest-

Estas são heurísticas de nomes do produto. shared-support e CommonDesk correspondem; my-shared-support não corresponde a ^shared porque o prefixo está ancorado no início. A verificação não inclui prefixos service/svc, não examina quem conhece a palavra-passe nem determina quantas pessoas utilizam uma conta.

Cada utilizador correspondente é adicionado uma vez e, em seguida, o ciclo interno de padrões termina. Count é o número de utilizadores recolhidos que correspondem aos padrões, incluindo contas desativadas: não existe filtro por estado de ativação. Quando são solicitados detalhes e existem correspondências, o resultado inclui entidades dos utilizadores afetados. A função devolve um resultado mesmo quando Count é zero.

O fornecedor LDAP disponibiliza utilizadores e atributos do diretório, não o histórico de eventos 4624/4648 nem uma identidade de operador. Este Detect não correlaciona sessões, não prova partilha de credenciais, não avalia registos independentes de atribuição nem verifica uma retirada de serviço aprovada. Um resultado positivo inicia o processo de qualificação acima; uma contagem de zero estabelece apenas que nenhum nome recolhido correspondeu a estas expressões, não que toda a utilização de contas possa ser atribuída.