Caminhos de scripts de logon AD: reveja destinos scriptPath antes de alterar ACLs

O que significam os caminhos de scripts de logon AD

Os caminhos de scripts de logon AD exigem um inventário e uma revisão das responsabilidades antes de alguém alterar permissões. Um atributo de utilizador preenchido indica onde um script de logon está configurado; não indica se o destino existe, se ainda é utilizado ou quem pode alterar o seu conteúdo. Trate o caminho como o ponto de partida para recolher evidências.

A referência do esquema Script-Path da Microsoft identifica scriptPath como o caminho do script de logon do utilizador e permite uma cadeia de caracteres nula. O parâmetro ScriptPath de New-ADUser aceita um caminho absoluto local ou um caminho Universal Naming Convention (UNC). Um valor UNC é, portanto, uma opção de configuração documentada. A sua presença, por si só, não demonstra um controlo de acesso fraco.

As perguntas úteis são concretas: que utilizador aponta para que destino, quem é responsável pela função de negócio, que clientes o utilizam e que principais de segurança podem modificar esse destino? O responsável pela conta, o responsável pela manutenção do script e o administrador do servidor de ficheiros podem ser pessoas diferentes. Registe cada responsabilidade em vez de assumir que o proprietário no sistema de ficheiros também aprova a utilização no negócio.

Como funciona: distinguir atribuição, conteúdo e utilização

A revisão tem três camadas. O atributo do diretório atribui um caminho. O ficheiro referenciado e as suas dependências contêm as instruções. O comportamento real de logon do cliente determina se essas instruções são utilizadas. As evidências de uma camada não podem substituir as das restantes.

A técnica Network Logon Script do MITRE ATT&CK descreve o abuso de scripts atribuídos através do Active Directory ou da Política de Grupo e recomenda limitar os responsáveis pela escrita aos administradores designados. Descreve a execução com os privilégios do utilizador ao qual o script foi atribuído. Não deduza execução como SYSTEM a partir de um resultado sobre um caminho de rede. Para investigar um possível abuso, confirme uma capacidade não autorizada de alterar o script ou redirecionar a sua atribuição e, depois, confirme que um cliente relevante utiliza o conteúdo alterado. Este artigo não afirma que qualquer um desses eventos tenha ocorrido.

Separe o scriptPath do utilizador dos scripts configurados dentro de uma GPO. Se estiver envolvida a implementação por política, utilize a revisão separada de Read, Apply e âmbito de GPO. As suas questões sobre Read para computadores e Apply direcionado dizem respeito à obtenção e aplicação da política; não estabelecem quem pode reescrever o ficheiro referenciado pelo atributo de um utilizador.

Inspecione também o conteúdo quanto a dependências e credenciais expostas através do processo de revisão adequado. A revisão existente de credenciais em ficheiros SYSVOL, incluindo scripts aborda essa questão. Um inventário de caminhos não permite estabelecer se um script contém um segredo, e este fluxo não repete a investigação separada de cPassword.

Deteção: inventariar utilizadores, resolver destinos, inspecionar ambas as ACLs

1. Inventariar caminhos configurados sem excluir utilizadores desativados

Execute os exemplos seguintes num ambiente administrativo Windows autorizado, com os módulos relevantes. São exemplos baseados na documentação, não comandos executados no domínio de um cliente. Substitua o servidor, a base de pesquisa, as identidades e os caminhos de exemplo por valores aprovados.

A referência de Get-ADUser documenta -LDAPFilter, -SearchBase, -Server e a obtenção de atributos adicionais com -Properties. Esta consulta inventaria utilizadores com scriptPath presente, incluindo contas desativadas:

Get-ADUser -LDAPFilter '(scriptPath=*)' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

Uma alternativa que utiliza a sintaxe de filtro do módulo é:

Get-ADUser -Filter 'scriptPath -like "*"' -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,SamAccountName,Enabled,scriptPath

O padrão de presença do atributo adapta os exemplos de filtros do Active Directory da Microsoft. Format-List apresenta propriedades nomeadas; conserve também o inventário subjacente no seu sistema de evidências aprovado. Registe o controlador de domínio consultado, a base de pesquisa, a hora da recolha e quaisquer erros. Uma consulta parcial ou falhada não constitui um inventário completo.

Associe cada utilizador ao caminho e a um responsável. Mantenha as contas desativadas visíveis como casos de ciclo de vida: pergunte se a atribuição é conservada para um regresso planeado, copiada de um modelo ou obsoleta. Não ative uma conta para testar o seu script. A atribuição de um utilizador desativado não demonstra utilização atual; ainda assim, pode identificar um destino partilhado com outros utilizadores.

2. Resolver o destino no contexto real do cliente

Preserve o atributo literal antes de o interpretar. Para uma cadeia relativa, identifique a sua base de resolução no cliente relevante e no fluxo de logon; não a resolva relativamente ao diretório de trabalho da sua shell administrativa. Para um caminho absoluto local, identifique o cliente no qual esse ficheiro deverá existir. Para um caminho de rede, identifique o servidor, a partilha e o ficheiro efetivamente alcançados pelo cliente de teste. Registe explicitamente os casos por resolver.

Pergunte ao responsável pela manutenção de que scripts, executáveis, ficheiros de configuração ou outros recursos depende o ponto de entrada. Reveja também esses destinos. Alterar apenas a ACL do ponto de entrada é insuficiente se uma dependência não revista fornecer as instruções que o script utiliza.

Depois de resolver um possível ficheiro de destino, este exemplo utiliza os parâmetros documentados de Test-Path:

Test-Path -LiteralPath '\\files01.example.com\LogonScripts\onboarding.cmd' -PathType Leaf

Leaf testa a existência de um destino do tipo ficheiro; -LiteralPath evita a interpretação de caracteres universais. Registe a identidade, o cliente e os erros juntamente com o resultado. Este teste de existência não prova a execução bem-sucedida durante o logon, a correção do script ou a permissão para modificar o ficheiro. Confirme a utilização real através de um piloto aprovado com o responsável pelo script.

3. Inspecionar separadamente as permissões da partilha e do sistema de ficheiros

No servidor de ficheiros identificado, utilize Get-SmbShare para mapear o nome da partilha para o seu caminho local. Em seguida, utilize Get-SmbShareAccess para obter a ACL da partilha. Estes exemplos adaptam as consultas documentadas com -Name:

Get-SmbShare -Name 'LogonScripts' | Format-List -Property Name,ScopeName,Path

Get-SmbShareAccess -Name 'LogonScripts'

Execute estes comandos no servidor que realmente aloja a partilha. Se estiver envolvida uma partilha com âmbito específico, identifique esse âmbito e utilize o parâmetro documentado -ScopeName. Uma partilha com nome semelhante noutro servidor não constitui evidência para este destino. Preserve cada entidade de segurança, entrada Allow ou Deny e nível de acesso.

Para NTFS, Get-Acl obtém o descritor de segurança do recurso no Windows. Depois de confirmar o caminho local real, inspecione o ficheiro e o diretório que o contém:

Get-Acl -LiteralPath 'D:\LogonScripts\onboarding.cmd' | Format-List -Property *

Get-Acl -LiteralPath 'D:\LogonScripts' | Format-List -Property *

Estes são exemplos, não uma afirmação de que esta partilha corresponde a D:\LogonScripts. Recolha o proprietário, as entradas de acesso e a herança. Resolva os grupos associados a cada entidade de segurança antes de concluir que utilizadores podem alterar o conteúdo. A listagem da ACL é uma evidência para essa revisão, não uma simulação do acesso efetivo de todas as identidades.

O modelo de segurança de ficheiros da Microsoft avalia os direitos pedidos face ao token do chamador e ao descritor do objeto. As suas constantes de direitos de acesso a ficheiros distinguem a escrita de dados num ficheiro, a criação de ficheiros num diretório e a eliminação de elementos subordinados. Reveja a capacidade de alterar ou substituir conteúdo, bem como a administração de permissões; ler o script é uma questão diferente. Inspecione em conjunto as evidências da partilha e do NTFS para o percurso de acesso específico.

Correção: rever primeiro, depois corrigir de forma direcionada (Remediation)

1. Acordar o comportamento pretendido e quem pode escrever

Para cada atribuição, registe o responsável de negócio, a população de clientes esperada, os responsáveis pela manutenção aprovados e o acesso de leitura necessário. Classifique-a como necessária, obsoleta ou por resolver. Mantenha a incerteza visível em vez de a tratar como permissão para eliminar. Um destino partilhado pode ter vários consumidores, pelo que a sua alteração deve ser coordenada com todos os responsáveis afetados.

2. Preservar um estado de reversão e testar a alteração num piloto

Preserve o atributo atual, o conteúdo do destino, as dependências e ambos os conjuntos de permissões através do processo de cópia de segurança aprovado. Escolha um utilizador de teste ativado e um cliente representativos. Defina o resultado esperado e as condições de falha antes do piloto. Para contas desativadas, tome uma decisão de ciclo de vida em vez de forçar um teste de logon.

3. Corrigir o problema confirmado na sua origem

Se o destino for necessário, mas um principal de segurança não previsto o puder alterar, peça ao responsável pelo servidor de ficheiros que corrija a concessão específica da partilha ou do NTFS através do procedimento de alteração aprovado. Reveja as concessões herdadas e as dependências antes de escolher a alteração. A mitigação do MITRE apoia a restrição de quem pode escrever nos scripts; não prescreve uma ACL universal para todos os ambientes.

Se a atribuição apontar para um destino errado, altere o atributo desse utilizador apenas depois de validar o substituto. A pré-visualização seguinte utiliza os parâmetros ScriptPath e WhatIf documentados de Set-ADUser:

Set-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -ScriptPath '\\files01.example.com\LogonScripts\approved.cmd' -WhatIf

-WhatIf pré-visualiza a operação sem a aplicar. Este comando é uma opção para corrigir uma atribuição aprovada, não uma recomendação para migrar todos os utilizadores para caminhos UNC. Se uma atribuição for obsoleta, retire-a através do procedimento de gestão de contas acordado depois de verificar as dependências partilhadas. Não elimine um ficheiro referenciado apenas porque um utilizador já não precisa dele.

4. Reler a configuração e verificar o comportamento autorizado

Volte a consultar o utilizador exato após a alteração aprovada:

Get-ADUser -Identity 'CN=PilotUser,OU=Users,DC=example,DC=com' -Server 'dc01.example.com' -Properties scriptPath | Format-List -Property DistinguishedName,Enabled,scriptPath

Releia ambas as ACLs se as permissões tiverem sido alteradas. Repita o teste de cliente aprovado pelo responsável e valide a obtenção necessária e o comportamento esperado. Quando adequado, verifique que alguém não previsto como autor não tem acesso efetivo de modificação, usando o procedimento de teste de acesso autorizado da organização. Conserve o contexto do teste, os resultados, as exceções e a decisão de reversão juntamente com o inventário. A releitura do atributo, por si só, não permite validar os efeitos do script.

Como o EtcSec deteta esta situação

A verificação DANGEROUS_LOGON_SCRIPTS do EtcSec fornece uma lista para revisão. No commit 15fc6399c215eabc415c370b762303cfcd7a353a do etc-collector, dangerous-logon-scripts.go:46 percorre os utilizadores fornecidos e seleciona um ScriptPath não vazio quando contém duas barras invertidas consecutivas em qualquer posição ou começa com //. Não exige um prefixo UNC estrito no ramo das barras invertidas. O resultado tem gravidade Medium, e Count é o número de utilizadores correspondentes, não de ficheiros distintos ou partilhas vulneráveis.

Não existe um filtro Disabled neste Detect(). Assim, os utilizadores desativados podem aparecer quando são fornecidos nos dados da auditoria. Um caminho vazio não corresponde ao critério; caminhos relativos e outras cadeias fora do predicado podem escapar a esta lista de revisão. Por outro lado, uma cadeia correspondente não demonstra um destino UNC válido e acessível.

O fornecedor LDAP pede scriptPath em parser.go:49, copia-o para ScriptPath em parser.go:171 e obtém utilizadores através de client.go:460. Esta verificação não lê o ficheiro de destino, a ACL da partilha, a ACL do NTFS ou a execução efetiva. O seu resultado não pode confirmar acesso de escrita não autorizado, persistência bem-sucedida ou execução como SYSTEM. O âmbito e a completude da recolha também limitam o que a lista representa.