App Control for Business no Windows 11: Auditoria e Enforcement

Um antivírus decide se um ficheiro é malicioso. O App Control for Business decide se um ficheiro tem direito a correr, e a resposta vale para software assinado com certificado válido — a classe exacta de ataque em que o ransomware se esconde. A política inverte a lógica de confiança do Windows: nada corre sem autorização, e esta vem da política de integridade de código da organização, não da reputação momentânea de um serviço na nuvem.

O Windows 11 22H2 e posteriores trazem tudo o que é preciso: os cmdlets ConfigCI, o utilitário CiTool e o canal de eventos CodeIntegrity. O fluxo recomendado pela documentação oficial tem seis passos: criar a política com o Wizard, publicar em auditoria, ler os eventos, gerar regras a partir deles, activar o enforcement e assinar a política. O resultado é uma linha de defesa que nem um administrador comprometido consegue desligar sem rasto.

Neste artigo

1. 1. Preparar os dispositivos: requisitos e ferramentas
2. 2. Criar a política base com o App Control Wizard
3. 3. Publicar a política em modo auditoria
4. 4. Ler os eventos de auditoria
5. 5. Gerar regras a partir dos eventos com New-CIPolicy
6. 6. Passar a política de auditoria para enforcement
7. 7. Implementar pela Intune: política nativa ou OMA-URI
8. 8. Assinar a política contra adulteração
9. 9. Bloquear as aplicações que contornam o App Control
10. 10. Erros Comuns
11. 11. Checklist
12. Artigos Relacionados
13. Fontes Oficiais

1. Preparar os dispositivos: requisitos e ferramentas

As ferramentas vêm do próprio Windows ou do GitHub oficial da Microsoft: os cmdlets do módulo ConfigCI estão integrados, o CiTool faz parte do Windows 11 22H2 e do Windows Server 2025, e o Wizard distribui-se como pacote MSIX. Para políticas assinadas é preciso um certificado de code signing e o Secure Boot activo.

Confirmar o terreno no dispositivo de referência:

# Confirmar os cmdlets ConfigCI e as políticas activas no sistema
Get-Command -Module ConfigCI
CiTool --list-policies

O primeiro devolve os cmdlets usados nas secções seguintes — New-CIPolicy, ConvertFrom-CIPolicy, Set-RuleOption, Set-CIPolicyIdInfo, Add-SignerRule — e o segundo lista as políticas activas no sistema, o ponto de partida antes da política própria.

2. Criar a política base com o App Control Wizard

O Wizard é uma aplicação open-source da Microsoft, empacotada como MSIX e disponível no GitHub. Nos bastidores chama os cmdlets ConfigCI, pelo que o XML produzido é idêntico ao do PowerShell — a diferença é o assistente. Funciona no Windows 10 1909 e posteriores, ou na edição Enterprise em compilações anteriores.

O fluxo para uma política base: escolher um dos modelos incluídos, deixar o assistente recolher os binários do dispositivo de referência, acrescentar regras para as aplicações de negócio, activar a opção Enabled: Audit Mode e guardar o XML. O Wizard também edita e funde políticas existentes e constrói regras a partir dos registos de eventos.

3. Publicar a política em modo auditoria

Em auditoria, o Windows deixa tudo correr e regista o que teria sido bloqueado. A conversão e publicação ficam assim:

# Converter a política para o formato binário {GUID}.cip
$AuditPolicyXML = "$env:USERPROFILE\Desktop\Clientes_Geridos_Audit.xml"
$PolicyID = Set-CIPolicyIdInfo -FilePath $AuditPolicyXML -ResetPolicyID
$PolicyID = $PolicyID.Substring(11)
ConvertFrom-CIPolicy $AuditPolicyXML ".\$PolicyID.cip"

# Publicar no Windows 11 22H2 e posteriores
CiTool --update-policy ".\$PolicyID.cip" -json

O nome do binário tem de ser o PolicyId, sem chavetas. Em versões anteriores ao 22H2, copiar o .cip para System32\CodeIntegrity\CIPolicies\Active\ e correr a RefreshPolicy.exe.

A confirmação chega no registo CodeIntegrity\Operational: o evento 3099 indica que a política foi carregada, com as opções no detalhe. O 3095 significa que a política não pôde ser recolhida em quente e pede um reinício. Nas primeiras semanas, os 3076 acumulam-se — é esse o objectivo.

4. Ler os eventos de auditoria

O App Control só escreve eventos para o que seria ou foi bloqueado, nunca para ficheiros autorizados. Os dois registos: CodeIntegrity\Operational para executáveis, DLLs e activação de políticas, AppLocker\MSI and Script para MSI, scripts e objectos COM (sem existir no Windows Server Core).

Para rever os bloqueios em auditoria:

# Últimos bloqueios em modo auditoria
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'; Id=3076} `
  -MaxEvents 20 | Format-Table TimeCreated, Message -AutoSize

Cada evento 3076 vem acompanhado de eventos 3089 com as assinaturas do ficheiro, emparelháveis pelo Correlation ActivityID — é daí que saem as regras por editor da secção seguinte.

5. Gerar regras a partir dos eventos com New-CIPolicy

Com os programas a autorizar já executados no dispositivo de auditoria, o New-CIPolicy transforma os eventos em regras:

# Regras novas a partir dos eventos de auditoria recolhidos
New-CIPolicy -FilePath "$env:USERPROFILE\Desktop\EventsPolicy.xml" -Audit `
  -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash `
  -UserPEs -MultiplePolicyFormat 3> "$env:USERPROFILE\Desktop\AvisosNewCIPolicy.txt"

O nível FilePublisher confia no editor, no nome e na versão mínima de cada ficheiro, com hash como recurso para o que não couber nesse nível. A documentação pede cuidado na escolha do nível — os mais específicos enchem a política de entradas difíceis de manter. O ficheiro de avisos lista o que ficou sem regra, e o New-CIPolicy só cria regras para ficheiros que ainda estejam no disco: quem apagou o instalador cria a regra à mão no XML.

O passo seguinte é rever o EventsPolicy.xml (à mão ou no Wizard) e fundir as regras com a base, ou publicá-las como suplementar.

6. Passar a política de auditoria para enforcement

O enforcement é uma opção da política, não outra implementação: a versão final é uma cópia da de auditoria sem a opção 3.

# Copiar a política de auditoria e dar-lhe um novo ID e nome
$AuditPolicyXML = "$env:USERPROFILE\Desktop\Clientes_Geridos_Audit.xml"
$EnforcedPolicyXML = "$env:USERPROFILE\Desktop\Clientes_Geridos_Enforced.xml"
Copy-Item $AuditPolicyXML $EnforcedPolicyXML
$EnforcedPolicyID = Set-CIPolicyIdInfo -FilePath $EnforcedPolicyXML `
  -PolicyName 'Clientes_Geridos_Enforced' -ResetPolicyID
$EnforcedPolicyID = $EnforcedPolicyID.Substring(11)

# Redes de segurança recomendadas para o primeiro anel de implementação
Set-RuleOption -FilePath $EnforcedPolicyXML -Option 9
Set-RuleOption -FilePath $EnforcedPolicyXML -Option 10

# A linha que muda tudo: remover a opção 3 (Audit Mode)
Set-RuleOption -FilePath $EnforcedPolicyXML -Option 3 -Delete

ConvertFrom-CIPolicy $EnforcedPolicyXML ".\$EnforcedPolicyID.cip"

A opção 9 (Advanced Boot Options Menu) permite desactivar o App Control para uma sessão de arranque no menu pré-arranque, e a 10 (Boot Audit on Failure) converte a política em auditoria se um driver crítico for bloqueado no arranque. Ambas são recomendadas no primeiro anel e removíveis com Set-RuleOption -Delete quando o anel estiver validado. O ID novo permite correr as duas políticas lado a lado, ou substituir a de auditoria no próprio sítio sem novo ID.

Duas consequências: os eventos 3076 dão lugar a 3077, e as suplementares herdam o modo da base — com a base enforced a novo ID, cada suplementar precisa de uma cópia apontada à nova base. O evento 3033 (assinatura revogada ou expirada com EKU Lifetime Signing) resolve-se com a opção 20 Enabled: Revoked Expired As Unsigned e uma regra por hash.

7. Implementar pela Intune: política nativa ou OMA-URI

A Intune traz suporte nativo ao App Control no perfil de Endpoint Protection para Windows 10 e posteriores: componentes Windows, drivers de kernel de terceiros, aplicações assinadas pela Store e, em opcional, aplicações com boa reputação no Intelligent Security Graph. Dois limites documentados: as políticas nativas usam o formato de política única anterior a 1903 e passam pelo CSP do AppLocker, que pede sempre um reinício.

Para uma política própria, o caminho é o perfil personalizado com OMA-URI, publicado no Windows 10 1903 e posteriores através do CSP ApplicationControl:

O GUID vai sem chavetas e a Intune converte o .bin para Base64 ao carregá-lo. O limite por política é de 350 000 bytes, o que aconselha políticas enxutas: regras por assinatura, ISG e managed installers em vez de listas de hashes, e políticas múltiplas para granularidade fina. É a única via nativa que publica sem reinício.

Excepção importante: uma base assinada nova em sistemas com integridade da memória activa exige activação por reinício — o MDM fica fora, e o caminho é o script com cópia para o System32 e a partição EFI seguido de reinício. Para remover uma política da Intune, publicar primeiro uma versão que permita tudo (o AllowAll.xml vive em %windir%\schemas\CodeIntegrity\ExamplePolicies) e só depois apagá-la no portal — apagar sem substituir deixa a política em vigor até ao próximo reinício.

8. Assinar a política contra adulteração

Uma política assinada é o nível máximo de protecção do App Control: o Windows detecta tentativas de adulteração administrativa — inclusive por malware a correr como administrador — e o resultado é uma falha de arranque em vez de uma política alterada. A protecção exige Secure Boot e fica efectiva após o primeiro reinício. Regras do certificado, todas da documentação: assinatura PKCS 7, chaves RSA de 2K, 3K ou 4K (ECDSA não é suportado) e SHA-256 como digest no Windows 11 — os 384 e 512 também valem no Windows Server 2019 e posteriores após o cumulativo de Novembro de 2022.

# Regra UpdatePolicySigner com o certificado de assinatura (.cer)
Add-SignerRule -FilePath .\Clientes_Geridos_Enforced.xml `
  -CertificatePath .\AssinaturaKbase.cer -Update -Supplemental

# Remover a opção 6 (Unsigned System Policy)
Set-RuleOption -FilePath .\Clientes_Geridos_Enforced.xml -Option 6 -Delete

# Converter e assinar com o signtool
ConvertFrom-CIPolicy .\Clientes_Geridos_Enforced.xml ".\$EnforcedPolicyID.cip"
signtool.exe sign -v -n "AssinaturaKbase" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 ".\$EnforcedPolicyID.cip"

O resultado é um .p7 a renomear para {GUID}.cip (o GUID do PolicyId do XML), verificável com certutil.exe -asn. Falta a regra UpdatePolicySigner antes de converter é a receita documentada para uma política impossível de alterar ou desativar, com falha de arranque à chave. De assinada, a base arrasta as suplementares, autorizadas por uma regra SupplementalPolicySigner na base. Ao actualizar uma política assinada, o VersionEx novo tem de ser igual ou superior ao actual — uma versão mais baixa causa falha de arranque. O deploy assinado vai para a partição EFI, em EFI\Microsoft\Boot\CiPolicies\Active, com dois reinícios de teste antes da produção.

9. Bloquear as aplicações que contornam o App Control

A Microsoft mantém uma lista de aplicações que um atacante pode usar para contornar a política com o App Control activo: hosts de script e utilitários de desenvolvimento como mshta.exe, wmic.exe, wscript.exe, cscript.exe, bash.exe, wsl.exe, dotnet.exe, msbuild.exe e a biblioteca system.management.automation.dll. A recomendação é bloqueá-las salvo exigência de negócio — no msbuild.exe, permitido apenas em contextos de desenvolvimento. A lista tem datas: o bginfo.exe anterior à 4.22 é vulnerável, e versões antigas de uma aplicação corrigida merecem regras de negação próprias, porque o upgrade não apaga o binário vulnerável.

Módulos do PowerShell com bypass já corrigidos são bloqueáveis por hash, e bloquear as DLLs WebDAV exige desactivar também o serviço WebClient por política. A lista evolui com a comunidade de segurança, pelo que vale revisão periódica.

10. Erros Comuns

• Activar o enforcement antes de recolher eventos 3076. Sem uma rodada de auditoria, a primeira política bloqueia aplicações de negócio em produção.
• Esquecer a renomeação {GUID}.cip → {GUID}.bin no upload OMA-URI da Intune, ou incluir as chavetas no GUID do OMA-URI.
• Assinar sem acrescentar antes a regra UpdatePolicySigner — a política fica inalterável e o resultado documentado é falha de arranque.
• Publicar uma versão com VersionEx inferior ao actualizar uma política assinada, outra causa de falha de arranque.
• Publicar uma base assinada nova via MDM com integridade da memória activa — conhecido problema, o caminho é script com reinício.
• Ignorar o registo AppLocker\MSI and Script — scripts, MSI e COM só aparecem aí, e o Windows Server Core nem o tem.
• Deixar mshta.exe ou wmic.exe autorizados porque “o Windows precisa deles” — ambos estão na lista oficial de bypass.

11. Checklist

1. Círculo de confiança definido (componentes Windows, drivers de kernel, Store, ISG opcional)
2. Política base criada com o Wizard a partir do modelo adequado ao cenário
3. Opção 3 (Audit Mode) activa na primeira versão publicada
4. Opções 9 e 10 activas no primeiro anel de enforcement
5. XML convertido para {GUID}.cip com o nome do PolicyId, sem chavetas
6. Eventos 3076 e 8028 recolhidos nos dois registos de eventos
7. Ficheiro de avisos do New-CIPolicy lido e regras revistas antes do merge
8. Enforcement só depois do merge das regras geradas dos eventos
9. OMA-URI com GUID sem chavetas e ficheiro {GUID}.bin
10. Certificado PKCS 7 com RSA 2K-4K e SHA-256 confirmados antes de assinar
11. Política assinada testada com dois reinícios antes da implementação em massa

Artigos Relacionados

• AppLocker e WDAC: Bloquear Aplicações Não Autorizadas no Windows 11 em 2026
• BitLocker Enterprise com Intune em 2026: Implementação e Gestão para PME
• Zero Trust DNS: Controlo de Destinos por DNS no Windows 11
• Microsoft Defender for Endpoint: Guia de Implementação e Configuração para PME

Fontes Oficiais

• App Control for Business Wizard
• Deploy App Control policies with MDM
• Audit App Control policies
• Enforce App Control policies
• Use signed policies to protect App Control for Business against tampering
• Applications that can bypass App Control and how to block them
• Understanding App Control event IDs
• Deploy App Control policies with script