Risco do Windows Attachment Manager: verificar políticas de utilizador

O que significa o risco do Windows Attachment Manager?

O risco do Windows Attachment Manager diz respeito à política de tratamento de ficheiros: que anexo recebe um pedido de confirmação ou um bloqueio, para que utilizador e em que aplicação? Um inventário de GPO pode identificar definições que merecem análise, mas concluir a revisão exige provas do fluxo de trabalho previsto para o utilizador.

Duas situações exigem decisões diferentes. Um inventário que não contém DefaultFileTypeRisk nem LowRiskFileTypes levanta uma questão sobre a configuração explícita. Uma política que seleciona um risco predefinido baixo ou acrescenta extensões de scripts a uma lista de baixo risco levanta uma questão sobre uma exceção explícita. Tratar ambos os casos como prova de que todos os scripts descarregados são executados sem confirmação excederia o alcance das provas.

Este guia utiliza a documentação do Microsoft Learn e o código revisto do etc-collector. Os comandos Windows abaixo são exemplos de leitura baseados na documentação, não comandos executados num ambiente Windows para este artigo. O procedimento piloto é um método de verificação proposto; não se afirma que houve um teste bem-sucedido, um número de estações de trabalho afetadas ou um ataque.

Como funciona: valores predefinidos, listas e contexto da aplicação

A referência de políticas do Attachment Manager da Microsoft situa estas definições em Configuração do Utilizador > Modelos Administrativos > Componentes do Windows > Attachment Manager, com os mapeamentos de risco e listas em Software\Microsoft\Windows\CurrentVersion\Policies\Associations.

O comportamento documentado distingue três classes de risco:

Uma política de risco predefinido não configurada ou desativada mantém o risco moderado. Uma política de baixo risco não configurada mantém a lógica de confiança predefinida. As inclusões personalizadas de alto risco têm precedência sobre as inclusões de risco médio e baixo; as de risco médio precedem as de risco baixo. A inclusão de baixo risco sobrepõe-se à lista integrada de alto risco, pelo que as sobreposições entre listas personalizadas são relevantes. A lógica de confiança predefinida dá preferência ao componente que trata o ficheiro; a política separada de lógica de confiança pode alterar essa avaliação. Definições de políticas da Microsoft

O contexto da aplicação também faz parte do mecanismo. A referência de IAttachmentExecute da Microsoft descreve uma interface utilizada por aplicações cliente, incluindo verificações de políticas, pedidos de confirmação e operações de gravação e execução. SetSource fornece informações de origem e SetReferrer fornece o contexto de zona; o cliente também possui as suas próprias definições de anexos. Isto não demonstra que todas as aplicações utilizem a interface da mesma forma.

Para uma revisão, identifique a aplicação que recebe o ficheiro, a ação realizada pelo utilizador e a informação de proveniência disponível nesse momento. Um resultado não pode preencher essas lacunas. Não passe de uma cadeia de política ao nível do domínio para uma afirmação sobre um navegador, cliente de correio, associação de ficheiros ou caminho de execução desconhecido.

Deteção: inventariar políticas de utilizador e comparar o piloto

Passo 1: Preservar a configuração das GPO

Inventarie as GPO relevantes antes de as editar. Registe a identidade de cada GPO, as ligações, o âmbito de utilizadores, a filtragem, o momento da recolha e os valores brutos da política. Inspecione a Configuração do Utilizador e o ficheiro User\Registry.pol descodificado, em vez de assumir que um relatório de políticas de computador contém as definições de anexos. Preserve configurações contraditórias para posterior reconciliação.

A folha de revisão deve incluir:

Distinga valores ausentes, vazios e não recolhidos de leituras falhadas. Em particular, o analisador utilizado pelas duas verificações EtcSec não conserva uma cadeia vazia de LowRiskFileTypes. Um campo analisado ausente é, portanto, insuficiente para reconstruir o estado original da política.

As nossas quatro verificações de segurança de GPO do Active Directory explicam a mesma disciplina para outras definições: conservar a configuração, identificar o âmbito que a recebe e verificar provas no cliente. Os controlos de LLMNR, WSUS, LSASS e UNC fornecem um método útil de revisão, enquanto esta investigação trata dos anexos dos utilizadores.

Passo 2: Obter o resultado das políticas do utilizador de destino

No computador piloto, utilize a sessão do utilizador previsto e obtenha o resumo do âmbito de utilizador:

gpresult /scope user /r

Para um registo mais detalhado, execute este comando separadamente:

gpresult /scope user /z

A referência de gpresult da Microsoft documenta o âmbito de utilizador, a saída resumida e a saída detalhada de políticas. Resolva divergências entre o inventário de GPO e o resultado apresentado antes de interpretar valores locais. Preserve os erros como erros; um relatório indisponível não substitui a prova de que a GPO prevista foi aplicada.

Passo 3: Ler os valores do registo do utilizador

Execute cada comando separadamente no contexto do utilizador previsto. Estes exemplos combinam a sintaxe de reg query documentada pela Microsoft com a chave Associations indicada acima:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v DefaultFileTypeRisk

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v LowRiskFileTypes

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v HighRiskFileTypes

HKCU identifica a estrutura do registo do utilizador atual. Executar a consulta como outro administrador altera o objeto da observação. Conserve o comando, a conta, a máquina, a hora, o tipo do valor e a saída; distinga um valor ausente de uma falha do comando. Compare essas leituras com a GPO responsável e com o resultado das políticas, em vez de substituir uma saída ausente por um valor presumido seguro ou inseguro.

Passo 4: Comparar a configuração com o tratamento observado

Defina um piloto autorizado com ficheiros representativos inofensivos e os responsáveis pelas aplicações. Registe a extensão, a proveniência, as informações de zona quando disponíveis, a aplicação que recebe o ficheiro, a ação selecionada e se o acesso foi bloqueado, sujeito a confirmação ou permitido. Conserve resultados inesperados para investigação; não introduza no registo um pedido de confirmação esperado como se tivesse sido observado.

Utilize uma matriz com uma linha por fluxo testado. Inclua uma referência à configuração antes e depois da alteração e o resultado real. Um resultado obtido através de uma ação de um cliente de correio sustenta essa observação específica; não demonstra todos os caminhos de execução local nem todas as populações de utilizadores. Estas fontes não estabelecem um ID de evento Windows universal para esta revisão de configuração.

Correção: rever exceções antes de alterar pedidos de confirmação (Remediation)

Passo 1: Atribuir responsabilidade pela configuração

Identifique o administrador responsável pela política de utilizador prevalecente e os responsáveis pelas aplicações que exigem exceções. Reúna o valor predefinido bruto e todas as listas de inclusão relevantes na mesma revisão. Conserve a exportação inicial para que a decisão possa ser associada a uma configuração real, em vez de uma descrição abreviada do resultado.

Classifique o caso como ausência de configuração explícita, enfraquecimento explícito, conflito de políticas ou provas incompletas. Não aplique a mesma ação corretiva aos quatro casos. Uma definição ausente exige uma decisão sobre o comportamento pretendido; uma exceção existente exige justificação e revisão de compatibilidade; uma falha de recolha exige uma medição bem-sucedida.

Passo 2: Remover enfraquecimentos injustificados numa política piloto

Para um piloto gerido por GPO, reveja o Nível de risco predefinido para anexos de ficheiros e as definições de inclusão no caminho do Attachment Manager indicado acima. Reveja DefaultFileTypeRisk = 6152, o valor testado pelo detetor de enfraquecimento, e cada entrada de script em LowRiskFileTypes. Remova exceções injustificadas através da política responsável e documente qualquer dependência mantida.

Escolha o valor predefinido pretendido e as listas depois de rever os requisitos da aplicação e da proveniência. Evite substituir uma decisão de compatibilidade específica de uma aplicação por um valor predefinido baixo generalizado. Verifique inclusões personalizadas de risco alto e moderado juntamente com entradas de baixo risco antes de prever o resultado. A presença de uma subcadeia de script na cadeia de baixo risco recolhida é um motivo para revisão, não uma avaliação completa de risco do Windows.

Passo 3: Recolher novamente provas do utilizador e testar o fluxo

Repita o gpresult do âmbito de utilizador e as leituras do registo após a aplicação da política, utilizando a mesma identidade piloto. Execute novamente os fluxos inofensivos acordados e registe os resultados reais com os responsáveis pelas aplicações. Se a configuração mudou mas o comportamento observado não correspondeu às expectativas, investigue o caminho da aplicação, a proveniência e o conflito de políticas antes de alargar a implementação.

Passo 4: Manter controlos complementares de execução

A política de risco de anexos, por si só, não demonstra um controlo abrangente de scripts. O nosso guia de regras ASR do Defender por GPO aborda regras de comportamento complementares, com identificadores de regras, ações e exclusões no endpoint verificados separadamente. Uma revisão bem-sucedida da política de anexos não valida ASR nem AppLocker.

Conclua a correção no âmbito definido apenas com a decisão de política, a configuração de utilizador resultante, o comportamento da aplicação revisto e a responsabilidade pelas exceções anexados. Mantenha a cobertura de uma implementação mais ampla como uma questão de prova separada. Uma edição de GPO concluída ou uma contagem alterada no collector não demonstra proteção de toda a frota.

Como o EtcSec deteta este problema

As duas implementações revistas do etc-collector são verificações GPO de gravidade Medium. Inspecionam campos do registo recolhidos, com estas condições exatas:

Na segunda verificação, as subcadeias testadas são .hta, .js, .vbs, .wsf, .wsh e .ps1. O código acrescenta um motivo para o risco predefinido 6152 e um motivo combinado quando ocorre qualquer uma dessas subcadeias. Várias extensões correspondentes continuam a contribuir com um único motivo de lista. Trata-se de correspondência de subcadeias, não de análise estrita de uma lista de extensões; um token mais longo que contenha .js, por exemplo, pode corresponder.

Cada campo é selecionado de forma independente. Os detetores procuram primeiro nas definições de registo de Machine e consultam as de User apenas se o resultado Machine desse campo for nil. A função auxiliar Machine dá prioridade à Default Domain Controllers Policy, depois à Default Domain Policy e depois a outra GPO disponível. A função auxiliar User devolve o primeiro valor não-nil encontrado num mapa Go. Esse percurso do mapa não fornece uma precedência estável de políticas Windows.

O analisador do registo mapeia um DWORD válido chamado defaultfiletyperisk sob uma chave que contém associations; mapeia lowriskfiletypes apenas quando a cadeia analisada não está vazia. As verificações revistas não avaliam as listas de inclusão de risco alto ou moderado, a lógica de confiança do cliente ou o comportamento da aplicação. Como os dois campos são selecionados separadamente, os seus valores também podem ter origem em GPO diferentes.

Qualquer valor não-nil em qualquer um dos campos selecionados suprime a contagem de ausência, sem validar a sua segurança. Da mesma forma, uma contagem de enfraquecimento igual a zero não demonstra recolha completa, aplicação correta de políticas ou tratamento seguro de anexos. Nenhuma verificação mede a execução universal sem avisos, valida AppLocker ou ASR ou demonstra a segurança da frota. Nenhum dos resultados demonstra um ataque.

Utilize o resultado para iniciar a revisão no âmbito definido acima. Mantenha juntos o inventário de políticas, as provas do resultado do utilizador e as observações reais do piloto, para que o editor ou administrador possa distinguir um sinal de configuração de um comportamento demonstrado.