Skip to content

App Control for Business / WDAC

Windows'un policy-driven code-integrity enforcement'ı (eskiden Windows Defender Application Control / Device Guard configurable code integrity); hangi driver ve application'ların load olmasına izin verileceğine karar veren, kernel'ın Code Integrity engine'i tarafından zorlanan machine-wide bir allowlist.

Mechanism

Invariant

Default Windows, bir administrator'ın diske koyabildiği herhangi bir code'a güvenir. App Control bunu tersine çevirir: code default olarak reddedilir ve yalnızca açık bir policy rule'una uyarsa çalışabilir. Enforcement noktası kernel'ın Code Integrity (CI) engine'idir; bu engine her image'ı — kernel-mode driver'ları ve user-mode binary'leri — load zamanında, derlenmiş bir policy'ye göre değerlendirir. Check, image-loading path'inde oturduğu için, policy'yi geçemeyen bir binary asla executable olarak map'lenmez; dolayısıyla diske zararlı bir DLL/EXE/driver yazabilen bir attacker yine de onu çalıştıramaz. App Control policy'leri bilgisayarın tamamına uygulanır ve tüm kullanıcıları etkiler; per-user değildir. Code Integrity check'leri boot'un çok erken aşamasında çalışır, böylece kernel, boot driver'lar ve policy'nin kendisi, untrusted code çalışmadan önce doğrulanır.

Rule'lar, izin verilen code'u şu yollarla tanımlayabilir:

  • code-signing certificate'in attribute'ları (publisher / signer);
  • dosyanın signed metadata'sından gelen attribute'lar (Original Filename, version) ya da file hash;
  • Microsoft'un Intelligent Security Graph (ISG)'i üzerinden app'in reputation'ı;
  • yükleyen process'in kimliği (managed installer);
  • diskteki file path (Windows 10 1903+);
  • binary'yi başlatan process.

Signed bir App Control policy en güçlü formdur: administrative tampering'i (örn. admin olarak çalışan malware'in policy'yi takas etmeye çalışması) tespit etmek üzere tasarlanmıştır ve sessiz bir bypass yerine bir boot failure / bugcheck ile sonuçlanır.

Walkthrough

Policy'ler XML olarak yazılır, binary bir .cip/.p7b'ye derlenir ve deploy edilir. ConfigCI PowerShell modülü oluşturmayı yürütür:

# 1. Generate a policy from a known-good "golden" reference machine
New-CIPolicy -Level Publisher -FilePath .\AppControl.xml `
             -ScanPath C:\ -UserPEs

# 2. Start in AUDIT mode — nothing is blocked, violations are only logged
Set-RuleOption -FilePath .\AppControl.xml -Option 3   # "Audit Mode"

# 3. Compile XML -> binary policy
ConvertFrom-CIPolicy -XmlFilePath .\AppControl.xml `
                     -BinaryFilePath .\AppControl.cip

Audit-mode violation'ları event log'da görünür ve enforce edilen bir policy'nin neyi block edeceğini, sen commit etmeden önce bulmanı sağlar:

Event Viewer:
  Applications and Services Logs >
    Microsoft > Windows > CodeIntegrity > Operational
  Event ID 3076  (audit)   — would have been blocked
  Event ID 3077  (enforce) — blocked from loading

Enforcement'a geçmek option 3'ü kaldırır ve yeniden deploy eder. Modern Windows'ta policy, CI policy store'una bırakılır ve refresh edilir:

Set-RuleOption -FilePath .\AppControl.xml -Option 3 -Delete   # leave Audit
ConvertFrom-CIPolicy .\AppControl.xml .\AppControl.cip
# deploy to: C:\Windows\System32\CodeIntegrity\CiPolicies\Active\<GUID>.cip
CiTool --update-policy .\AppControl.cip                        # Win11
Runtime'da block edilmiş load 
Log: CodeIntegrity/Operational  Event ID 3077
Code Integrity determined that a process (\Device\...\evil.exe)
attempted to load \??\C:\tools\evil.dll that did not meet the
Enterprise signing level requirements or violated code integrity policy.

Detection

  • CodeIntegrity/Operational log: Event ID 3076 (audit, block edilecekti) ve 3077 (enforce edilmiş block), sorunlu image'ı ve ihlal ettiği rule'u adlandırır.
  • Tampering yapılmış bir signed policy, sessiz bir allow yerine bir boot failure / bugcheck olarak kendini gösterir; bu da başlı başına bir tamper sinyalidir.

Mitigation

App Control kendisi bir mitigation'dır, ama dokümante edilmiş bir attack surface'i vardır:

Bypass sınıfları

  • Allowlist'lenmiş ama istismar edilebilir signed binary'ler (LOLBins) — Microsoft, signed executable'ların bir recommended block list'ini tutar (örn. bazı script host'lar, msbuild, eski vulnerable driver'lar); çünkü bunlar bir publisher rule'unu karşılarken keyfi logic çalıştırmaya zorlanabilir.
  • Path rule'ları, path user-writable ise signer/hash rule'larından daha zayıftır.
  • Policy, hardware/boot trust tarafından desteklenmelidir (Secure Boot ve ideal olarak hypervisor-protected code integrity) ki kernel-level bir attacker'a direnebilsin; hypervisor-protected-code-integrity, code-integrity-guard, arbitrary-code-guard ve secure-boot-bypass'a bak.

References