Entender Windows Defender regras de política e regras de arquivo do WDAC (Controle de Aplicativo)

Observação

Alguns recursos do Windows Defender Application Control só estão disponíveis em versões específicas do Windows. Saiba mais sobre a disponibilidade de recursos do WDAC.

Windows Defender O WDAC (Controle de Aplicativo) pode controlar o que é executado em seus dispositivos Windows definindo políticas que especificam se um driver ou aplicativo é confiável. Uma política inclui regras de política que controlam opções como modo de auditoria e regras de arquivo (ou níveis de regra de arquivo) que especificam como identificar aplicativos em que sua organização confia.

Implantar as regras de política do Windows Defender Application Control

Para modificar as opções de regra de política de um XML de política WDAC existente, use o Assistente de Política do WDAC ou o cmdlet Set-RuleOption PowerShell.

Você pode definir diversas opções de regra em uma política do WDAC. A Tabela 1 descreve cada opção de regra e se as políticas complementares podem defini-las. Algumas opções de regra são reservadas para trabalhos futuros ou não têm suporte.

Observação

Recomendamos que você use o Modo Habilitado:Auditoria inicialmente porque ele permite que você teste novas políticas do WDAC antes de aplicá-las. Com o modo de auditoria, os aplicativos são executados normalmente, mas o WDAC registra eventos sempre que um arquivo é executado que não é permitido pela política. Para permitir esses arquivos, você pode capturar as informações de política do log de eventos e, em seguida, mesclar essas informações na política existente. Quando o Modo Habilitado:Auditoria é excluído, a política é executada no modo imposto.

Alguns aplicativos podem se comportar de forma diferente mesmo quando sua política está no modo de auditoria. Quando uma opção pode alterar comportamentos no modo de auditoria, isso é observado na Tabela 1. Você sempre deve testar seus aplicativos minuciosamente ao implantar atualizações significativas em suas políticas do WDAC.

Tabela 1. Política do Windows Defender Application Control - opções de regra de política

Opção de regra Descrição Opção suplementar válida
0 Enabled:UMCI As políticas do WDAC restringem binários dos modos kernel e de usuário. Por padrão, somente binários do modo kernel são restritos. Habilitar essa opção de regra valida executáveis do modo de usuário e scripts. Não
1 Enabled:Boot Menu Protection No momento, essa opção não tem suporte. Não
2 Required:WHQL Por padrão, os drivers de kernel que não são assinados pelo WHQL (Laboratórios de Qualidade de Hardware do Windows) podem ser executados. Habilitar essa regra requer que cada driver seja assinado pelo WHQL e remova o suporte herdado do driver. Os drivers kernel criados para Windows 10 devem ter certificação WHQL. Não
3 Enabled:Audit Mode (padrão) Instrui o WDAC a registrar informações sobre aplicativos, binários e scripts que teriam sido bloqueados se a política fosse imposta. Você pode usar essa opção para identificar o impacto potencial da política do WDAC e usar os eventos de auditoria para refinar a política antes da aplicação. Para impor uma política WDAC, exclua essa opção. Não
4 Desabilitado: Versão de pré-lançamento Se habilitados, os binários de builds do Windows Insider não são confiáveis. Essa opção é útil para organizações que só querem executar binários lançados, não pré-lançamento de builds do Windows. Não
5 Enabled:Inherit Default Policy Essa opção é reservada para uso futuro e atualmente não tem efeito. Sim
6 Enabled:Unsigned System Integrity Policy (padrão) Permite que a política permaneça não assinada. Quando essa opção é removida, a política deve ser assinada e quaisquer políticas complementares também devem ser assinadas. Os certificados confiáveis para atualizações de política futuras devem ser identificados na seção UpdatePolicySigners. Certificados confiáveis para políticas suplementares devem ser identificados na seção SupplementalPolicySigners. Não
7 Allowed:Debug Policy Augmented No momento, essa opção não tem suporte. Sim
8 Required:EV Signers No momento, essa opção não tem suporte. Não
9 Enabled:Advanced Boot Options Menu O menu de pré-inicialização F8 permanece desabilitado por padrão para todas as políticas do WDAC. Definir essa opção de regra permite que o menu F8 seja exibido para usuários presentes fisicamente. Não
10 Enabled:Boot Audit on Failure Usada quando a política do WDAC está em modo de imposição. Quando um driver crítico de inicialização falha durante a inicialização, a política WDAC é colocada no modo de auditoria para que o Windows seja carregado. Os administradores podem validar o motivo da falha no log de eventos CodeIntegrity. Não
11 Disabled:Script Enforcement Essa opção desabilita as opções de imposição de script, abrangendo o PowerShell, o Host de Script Baseado no Windows (wscript.exe), o Host de Script Baseado no Console do Windows (cscript.exe), os arquivos HTA executados no Microsoft HTML Application Host (mshta.exe) e o MSXML. Alguns hosts de script podem se comportar de forma diferente mesmo quando sua política está no modo de auditoria. Para obter mais informações sobre a aplicação do script, consulte Execução de script com WDAC.
OBSERVAÇÃO: essa opção não tem suporte em Windows Server 2016 ou Windows 10 1607 LTSB e não deve ser usada nesses sistemas operacionais.		 Não
12 Required:Enforce Store Applications Se essa opção de regra estiver habilitada, as políticas do WDAC também se aplicarão a aplicativos Universais do Windows. Não
13 Enabled:Managed Installer Use essa opção para permitir automaticamente aplicativos instalados por um instalador gerenciado. Para obter mais informações, confira Autorizar aplicativos implantados com um instalador gerenciado do WDAC Sim
14 Enabled:Intelligent Security Graph Authorization Use essa opção para permitir automaticamente aplicativos com reputação "conhecida boa", conforme definido pelo ISG (Intelligent Security Graph) da Microsoft. Sim
15 Enabled:Invalidate EAs on Reboot Quando a opção de gráfico de segurança inteligente (14) é usada, o WDAC define um atributo de arquivo estendido que indica que o arquivo foi autorizado a ser executado. Essa opção faz com que o WDAC revalorize periodicamente a reputação dos arquivos autorizados anteriormente pelo ISG. Não
16 Enabled:Update Policy No Reboot Use essa opção para permitir a aplicação de futuras atualizações da política do WDAC sem exigir uma reinicialização do sistema.
OBSERVAÇÃO: essa opção só tem suporte em Windows 10, versão 1709 e posterior ou Windows Server 2019 e posterior.		 Não
17 Habilitado:permitir políticas suplementares Use essa opção em uma política base para permitir que políticas complementares a expandam.
OBSERVAÇÃO: essa opção só tem suporte em Windows 10, versão 1903 e posterior ou Windows Server 2022 e posterior.		 Não
18 Desabilitado:Proteção de Regra do FilePath do Runtime Essa opção desabilita o marcar de runtime padrão que só permite regras filepath para caminhos que só são graváveis por um administrador.
OBSERVAÇÃO: essa opção só tem suporte em Windows 10, versão 1903 e posterior ou Windows Server 2022 e posterior.		 Sim
19 Habilitado:Segurança de Código Dinâmico Habilita a aplicação da política para aplicativos .NET e bibliotecas carregadas dinamicamente.
OBSERVAÇÃO: essa opção só tem suporte em Windows 10, versão 1803 e posterior ou Windows Server 2019 e posterior.
OBSERVAÇÃO: essa opção sempre será imposta se qualquer política da UMCI WDAC a habilitar. Não há modo de auditoria para o endurecimento de segurança de código dinâmico do .NET.		 Não
20 Habilitado:Revogado expirado como sem sinal Use essa opção para tratar binários assinados com certificados revogados ou certificados expirados com o EKU de Assinatura vitalícia na assinatura, como "binários não assinados" para o processo/componentes do modo de usuário, em cenários de assinatura empresarial. Não
Enabled:Developer Mode Dynamic Code Trust Use essa opção para confiar em aplicativos UWP que são depurados no Visual Studio ou implantados por meio do portal do dispositivo quando o Modo de Desenvolvedor estiver habilitado no sistema. Não

Níveis de regra de arquivo do Windows Defender Application Control

Os níveis de regra de arquivo permitem que os administradores especifiquem o nível no qual desejam que os aplicativos sejam considerados confiáveis. Esse nível de confiança pode ser tão granular quanto o hash de cada binário ou tão geral quanto um certificado de AC. Especifique os níveis de regra de arquivo ao usar os cmdlets WDAC Wizard ou WDAC PowerShell para criar e modificar políticas.

Cada nível de regra de arquivo tem vantagens e desvantagens. Use a Tabela 2 para selecionar o nível de proteção apropriado para os recursos administrativos disponíveis e o cenário de implantação do WDAC.

Observação

As regras baseadas no signatário do WDAC só funcionam com criptografia RSA. Algoritmos ECC, como ECDSA, não têm suporte. Se você tentar permitir arquivos por assinatura com base em assinaturas do ECC, verá VerificationError = 23 nos eventos de informações de assinatura correspondentes de 3089. Em vez disso, os arquivos podem ser permitidos por regras de atributo de hash ou arquivo ou usando outras regras de signatário se o arquivo também for assinado com assinaturas usando RSA.

Tabela 2. Política do Windows Defender Application Control - níveis de regra de arquivo

Nível da regra Descrição
Hash Especifica valores individuais de hash de imagem Authenticode/PE para cada binário descoberto. Esse nível é o nível mais específico e requer mais esforço para manter os valores de hash das versões atuais do produto. Sempre que um binário é atualizado, o valor de hash muda, logo, exigindo uma atualização de política.
FileName Especifica o nome de arquivo original para cada binário. Embora os valores de hash de um aplicativo sejam modificados quando atualizados, os nomes de arquivo normalmente não são. Esse nível oferece menos segurança específica do que o nível de hash, mas normalmente não requer uma atualização de política quando qualquer binário é modificado. Por padrão, esse nível usa o atributo OriginalFileName do cabeçalho de recurso do arquivo. Use -SpecificFileNameLevel para escolher um atributo alternativo, como ProductName.
FilePath Começando com Windows 10 versão 1903, esse nível permite que binários sejam executados em locais específicos do caminho do arquivo. As regras filepath só se aplicam a binários do modo de usuário e não podem ser usadas para permitir drivers de modo kernel. Mais informações sobre as regras de nível filepath podem ser encontradas posteriormente neste artigo.
SignedVersion Esse nível combina a regra do editor com um número de versão. Ele permite que qualquer coisa seja executada do editor especificado com uma versão em ou acima do número de versão especificado.
Editor Esse nível combina o nível PcaCertificate (normalmente um certificado abaixo da raiz) e o CN (nome comum) do certificado folha. Você pode usar esse nível de regra para confiar em um certificado emitido por uma determinada AC e emitido para uma empresa específica em quem você confia (como Intel, para drivers de dispositivo).
FilePublisher Esse nível combina o atributo "FileName" do arquivo assinado, além de "Publisher" (certificado PCA com CN de folha), além de um número mínimo de versão. Essa opção confia em arquivos específicos do editor especificado, com uma versão igual ou superior à do número de versão especificado. Por padrão, esse nível usa o atributo OriginalFileName do cabeçalho de recurso do arquivo. Use -SpecificFileNameLevel para escolher um atributo alternativo, como ProductName.
LeafCertificate Adiciona signatários confiáveis no nível de certificado de assinatura individual. O benefício de usar esse nível versus o nível de hash individual é que as novas versões do produto têm valores de hash diferentes, mas normalmente o mesmo certificado de assinatura. Quando esse nível for usado, nenhuma atualização de política será necessária para executar a nova versão do aplicativo. No entanto, os certificados folha normalmente têm períodos de validade mais curtos do que outros níveis de certificado, portanto, a política WDAC deve ser atualizada sempre que esses certificados forem alterados.
PcaCertificate Adiciona o certificado mais alto disponível na cadeia de certificados fornecida aos signatários. Esse nível normalmente é um certificado abaixo da raiz porque a verificação não resolve a cadeia de certificados completa por meio dos repositórios raiz locais ou com um marcar online.
RootCertificate Sem suporte.
WHQL Só confia em binários que foram enviados à Microsoft e assinados pelo WHQL (Windows Hardware Qualification Lab). Esse nível é principalmente para binários de kernel.
WHQLPublisher Esse nível combina o nível WHQL e a CN no certificado folha e é principalmente para binários de kernel.
WHQLFilePublisher Esse nível combina o atributo "FileName" do arquivo assinado, além de "WHQLPublisher", além de um número mínimo de versão. Esse nível é principalmente para binários de kernel. Por padrão, esse nível usa o atributo OriginalFileName do cabeçalho de recurso do arquivo. Use -SpecificFileNameLevel para escolher um atributo alternativo, como ProductName.

Observação

Ao criar políticas WDAC com New-CIPolicy, você pode especificar um nível de regra de arquivo primário, incluindo o parâmetro -Level . Para binários descobertos que não possam ser confiáveis com base em critérios de regra de arquivo primário, use o parâmetro –Fallback. Por exemplo, se o nível de regra de arquivo primário for PCACertificate, mas você quiser confiar nos aplicativos não assinados também, usar o nível de regra hash como um fallback adicionará os valores de hash de binários que não tinham um certificado de assinatura.

Observação

  • O WDAC só dá suporte a regras de signatário para chaves de assinatura de certificado RSA com um máximo de 4.096 bits.
  • O código usa CN para os campos CertSubject e CertIssuer na política. Você pode usar o certutil de caixa de entrada para examinar o formato subjacente para garantir que o UTF-8 não esteja sendo usado para a CN. Por exemplo, você pode usar cadeia de caracteres imprimível, IA5 ou BMP.

Observação

Quando aplicável, números mínimos e máximos de versão em uma regra de arquivo são referenciados como MinimumFileVersion e MaximumFileVersion, respectivamente, na política XML.

  • MinimumFileVersion e MaximumFileVersion especificados: para permitir regras, o arquivo com versão maior ou igual a MinimumFileVersion e menor ou igual a MaximumFileVersion é permitido. Para negar regras, o arquivo com versão maior ou igual a MinimumFileVersion e menor ou igual a MaximumFileVersion é negado.
  • MinimumFileVersion especificado sem MaximumFileVersion: para permitir regras, o arquivo com versão maior ou igual à versão especificada pode ser executado. Para negar regras, o arquivo com versão menor ou igual à versão especificada está bloqueado.
  • MaximumFileVersion especificado sem MinimumFileVersion: para permitir regras, o arquivo com versão menor ou igual à versão especificada pode ser executado. Para negar regras, o arquivo com versão maior ou igual à versão especificada está bloqueado.

Exemplo de níveis de regra de arquivo em uso

Por exemplo, considere um profissional de TI em um departamento que executa muitos servidores. Eles só querem executar o software assinado pelas empresas que fornecem seu hardware, sistema operacional, antivírus e outros softwares importantes. Eles sabem que seus servidores também executam um aplicativo escrito internamente que não é assinado, mas é raramente atualizado. Eles desejam permitir que esse aplicativo seja executado.

Para criar a política do WDAC, eles criam um servidor de referência no respectivo hardware padrão e instalam todos os softwares que seus servidores devem executar. Em seguida, eles executam a New-CIPolicy com -Level Publisher (para permitir o software de seus fornecedores, os "Fornecedores") e -Fallback Hash (para permitir o aplicativo não assinado, interno). Eles implantam a política no modo de auditoria para determinar o impacto potencial da imposição da política. Com a ajuda dos dados de auditoria, eles atualizam suas políticas do WDAC para incluir qualquer outro software que desejam executar. Em seguida, eles habilitam a política do WDAC no modo imposto para seus servidores.

Como parte das operações normais, elas eventualmente instalarão atualizações de software ou talvez adicionarão software dos mesmos provedores de software. Como o "Publicador" permanece o mesmo nessas atualizações e software, eles não precisam atualizar a política do WDAC. Se o aplicativo interno não assinado for atualizado, ele também deverá atualizar a política WDAC para permitir a nova versão.

Ordem de precedência de regra de arquivo

O WDAC tem uma lógica de conflito de regra de arquivo interna que se traduz na ordem de precedência. Primeiro, processa todas as regras de negação explícitas encontradas. Em seguida, processa todas as regras de permissão explícitas. Se não houver nenhuma regra de negação ou permissão, o WDAC verificará uma declaração do Instalador Gerenciado , se permitido pela política. Por fim, o WDAC retornará ao ISG se permitido pela política.

Observação

Para facilitar o raciocínio sobre suas políticas do WDAC, recomendamos manter políticas separadas ALLOW e DENY em versões do Windows que dão suporte a várias políticas do WDAC.

Usar -SpecificFileNameLevel com regras de nível FileName, FilePublisher ou WHQLFilePublisher

Por padrão, os níveis de regra FileName, FilePublisher e WHQLFilePublisher usam o atributo OriginalFileName do cabeçalho de recurso do arquivo. Você pode usar um atributo de cabeçalho de recurso alternativo para suas regras definindo o -SpecificFileNameLevel. Por exemplo, um desenvolvedor de software pode usar o mesmo ProductName para todos os binários que fazem parte de um aplicativo. Usando -SpecificFileNameLevel, você pode criar uma única regra para cobrir todos esses binários em sua política, em vez de regras individuais para cada arquivo.

A Tabela 3 descreve as opções de atributo de cabeçalho de recurso disponíveis que você pode definir com -SpecificFileNameLevel.

Tabela 3. Opções -SpecificFileNameLevel

Valor SpecificFileNameLevel Descrição
Filedescription Especifica a descrição do arquivo fornecida pelo desenvolvedor do binário.
Internalname Especifica o nome interno do binário.
OriginalFileName Especifica o nome do arquivo original ou o nome com o qual o arquivo foi criado pela primeira vez, do binário.
PackageFamilyName Especifica o nome da família de pacotes do binário. O nome da família de pacotes consiste em duas partes: o nome do arquivo e a ID do editor.
Productname Especifica o nome do produto com o qual o binário é enviado.
Filepath Especifica o caminho do arquivo do binário.

Mais informações sobre regras de filepath

As regras de filepath não fornecem as mesmas garantias de segurança que as regras explícitas do signatário, uma vez que são baseadas em permissões de acesso mutáveis. As regras de filepath são mais adequadas para ambientes em que a maioria dos usuários está executando como padrão em vez de administrador. As regras de caminho são mais adequadas para permitir caminhos que você espera manter somente a gravação de administrador. Talvez você queira evitar regras de caminho para diretórios em que os usuários padrão possam modificar ACLs na pasta.

Caminhos de arquivo graváveis pelo usuário

Por padrão, o WDAC executa uma marcar de gravabilidade do usuário no runtime que garante que as permissões atuais no filepath especificado permitam apenas o acesso de gravação para usuários administradores.

Há uma lista definida de SIDs que o WDAC reconhece como administradores. Se um filepath permitir permissões de gravação para qualquer SID que não esteja nesta lista, o filepath será considerado gravável pelo usuário, mesmo que o SID esteja associado a um usuário de administrador personalizado. Para lidar com esses casos especiais, você pode substituir o marcar do administrador de runtime do WDAC com a opção Disabled:Runtime FilePath Rule Protection descrita anteriormente.

A lista de SIDs de administrador conhecidos do WDAC é:

S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-263929838-973813799-439329657-1197984847-4069167804-127792394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.

Quando as regras de filepath são geradas usando New-CIPolicy, uma regra de caminho exclusiva e totalmente qualificada é gerada para cada arquivo descoberto nos caminhos verificados. Para criar regras que, em vez disso, permitem todos os arquivos em um caminho de pasta especificado, use New-CIPolicyRule para definir regras que contêm curingas, usando a opção -FilePathRules .

Usando curingas nas regras de filepath do WDAC

Os seguintes curingas podem ser usados nas regras de filepath do WDAC:

Caractere curinga Significado Sistemas operacionais compatíveis
* Corresponde a zero ou mais caracteres. Windows 11, Windows 10 e Windows Server 2022
? Corresponde a um único caractere. Windows 11 somente

Você também pode usar as seguintes macros quando o volume exato pode variar: %OSDRIVE%, , %WINDIR%%SYSTEM32%. Essas macros podem ser usadas em combinação com os curingas acima.

Observação

Em Windows 11, você pode usar um ou mais curingas em qualquer lugar dentro de uma regra de filepath.

Em todas as outras versões do Windows e do Windows Server, apenas um curinga é permitido por regra de caminho e deve estar no início ou no final de uma regra de caminho.

Regras de filepath de exemplo com curingas

Exemplos Descrição Sistemas operacionais compatíveis
C:\windows\*
D:\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*		 Curingas colocados no final de um caminho autorizam todos os arquivos no caminho imediato e seus subdiretórios de forma recursiva. Windows 11, Windows 10 e Windows Server 2022
*\bar.exe Os curingas colocados no início de um caminho permitem o nome de arquivo especificado exato em qualquer local. Windows 11, Windows 10 e Windows Server 2022
C:\*\CCMCACHE\*\7z???? -x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe		 Os curingas usados no meio de um caminho permitem que todos os arquivos correspondam a esse padrão. Considere cuidadosamente todas as correspondências possíveis, especialmente se sua política desabilitar o marcar gravável de administrador com a opção Disabled:Runtime FilePath Rule Protection. Neste exemplo, ambos os caminhos hipotéticos corresponderiam:
C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe
C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe		 Windows 11 somente

Sem um curinga, a regra filepath permite apenas um arquivo específico (ex. C:\foo\bar.exe).

Observação

Ao criar políticas do WDAC com Configuration Manager, há uma opção para criar regras para arquivos e pastas especificados. Essas regras não são regras de filepath WDAC. Em vez disso, Configuration Manager executa uma verificação única dos arquivos e pastas especificados e cria regras para quaisquer binários encontrados nesses locais no momento da verificação. As alterações de arquivo nesses arquivos e pastas especificados após essa verificação não serão permitidas, a menos que a política de Configuration Manager seja reaplicada.

Mais informações sobre hashes

O WDAC usa o algoritmo de hash de imagem Authenticode/PE ao calcular o hash de um arquivo. Ao contrário do hash de arquivo simples mais conhecido, o cálculo de hash do Authenticode omite a soma de verificação do arquivo, a Tabela de Certificados e a Tabela de Certificado de Atributo. Portanto, o hash Authenticode de um arquivo não é alterado quando as assinaturas e carimbos de data/hora do arquivo são alterados ou quando uma assinatura digital é removida do arquivo. Com a ajuda do hash authenticode, o WDAC fornece segurança adicional e menos sobrecarga de gerenciamento para que os clientes não precisem revisar as regras de hash da política quando a assinatura digital no arquivo for atualizada.

O hash de imagem Authenticode/PE pode ser calculado para arquivos assinados digitalmente e sem sinal.

Por que a verificação cria quatro regras de hash por arquivo XML?

O cmdlet do PowerShell produz um Hash do Sha1 Authenticode, Hash Sha256, Hash de Página Sha1, Hash de Página Sha256. Durante a validação, o WDAC seleciona quais hashes são calculados com base em como o arquivo é assinado e no cenário em que o arquivo é usado. Por exemplo, se o arquivo for assinado por hash de página, o WDAC valida cada página do arquivo e evita carregar todo o arquivo na memória para calcular o hash completo do autenticado sha256.

Nos cmdlets, em vez de tentar prever qual hash será usado, precalculamos e usamos os quatro hashes (sha1/sha2 authenticode, e sha1/sha2 da primeira página). Esse método também é resiliente a alterações na forma como o arquivo é assinado, já que sua política do WDAC já tem mais de um hash disponível para o arquivo.

Por que a verificação cria oito regras de hash para determinados arquivos?

Regras separadas são criadas para UMCI e KMCI. Se os cmdlets não puderem determinar que um arquivo é executado apenas no modo de usuário ou no kernel, as regras serão criadas para ambos os cenários de assinatura por precaução. Se você souber que um arquivo específico carrega apenas no modo de usuário ou kernel, poderá remover com segurança as regras extras.

Quando o WDAC usa o valor de hash de arquivo simples?

Há alguns casos raros em que o formato de um arquivo não está em conformidade com a especificação Authenticode e, portanto, o WDAC recua para usar o hash de arquivo simples. Esse comportamento pode ocorrer por muitos motivos, como se as alterações forem feitas na versão na memória do arquivo em runtime. Nesses casos, você verá que o hash mostrado no evento de informações de assinatura correlacionados 3089 corresponde ao hash de arquivo simples do evento do bloco 3076/3077. Para criar regras para arquivos com um formato inválido, você pode adicionar regras de hash à política para o hash de arquivo simples usando o Assistente WDAC ou editando a política XML diretamente.