WDAC & AppLocker

Bypassing WDAC

Reading and writing custom policies

1. Use Syslifters/wdacparse to decode .cip binaries under C:\Windows\System32\CodeIntegrity\CIPolicies\Active\ into XML.
2. Review <Allow> rules (paths, publishers, hashes), e.g. <FileRules><Allow ID="ID_ALLOW_A_0001" FilePath="C:\Data\test\*" /></FileRules>.

If we have a signing cert or if the policies are unsigned, we can write our own ones.

1. Modify the rule you want to update to contain an exclusion.
2. From XML, generate a new binary with PowerShell ConvertFrom-CIPolicy (module ConfigCI) and copy the .cip to C:\Windows\System32\CodeIntegrity\CIPolicies\Active\.
3. Run CiTool --update-policy "{GUID}.cip" from that path. Confirm with CiTool.exe -lp.

Concept for restricting PowerShell capabilities

Goal: restrict Microsoft PowerShell functionality on Windows clients and servers to reduce risk in case a Windows device is compromised.

Feasibility and practicality must be validated in a real rollout test before broad deployment.

Measures

Apply the following measures on all Windows clients and servers:

• Enable Constrained Language Mode via a WDAC policy.
  • This restricts sensitive PowerShell features, making post-compromise privilege escalation harder from within a PowerShell session.
• Set Script Execution Policy to AllSigned.
  • All scripts intended for execution must be signed.
  • Note: this policy is easy to bypass and mainly prevents accidental execution of unsanctioned scripts.
• Enable Script Block Logging and Protected Event Logging.
  • PowerShell commands are logged and protected via encrypted logging (requires decryption on a central log collector; if that doesn’t exist, Protected Event Logging can be skipped).
• Updates
  • Ensure PowerShell version (>= 5) is installed.
• Disable PowerShell version 2
  • PowerShell v2 lacks key security features such as Constrained Language Mode and can be used to bypass controls.
  • PowerShell v3 and v4 can’t be started if PowerShell (>= 5) is installed, so no extra action is required for those versions.
• Antivirus
  • Ensure scripts executed via PowerShell (including in-memory) are detected and blocked by AV.

Implementation notes

More information regarding Constrained Language Mode.

• Roll out WDAC (system requirement: Windows 10/11, Windows Server 2016+)
  • Prepare a WDAC policy (e.g. "AllowAll.xml") in Audit Mode.
    • Keep "Disable Script Enforcement" disabled so Constrained Language Mode is enabled on endpoints.
    • Create/edit policies with the WDAC Policy Wizard: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-wizard
    • Convert XML policy to binary per WDAC deployment docs.
    • Deploy via script (GPO rollout has known issues and supports only single-policy formats).
    • Deployment reference: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/deployment/deploy-wdac-policies-with-script#deploying-policies-for-windows-11-windows-10-version-1903-and-above-and-windows-server-2022-and-above
    • Audit Mode initially does not enforce; it logs what would have been blocked. After rollout, analyze which scripts/apps would break.
  • Sign scripts to allow execution in Full Language Mode
    • Signed scripts can still run in Full Language Mode.
    • Sign with a timestamp server so signatures remain trustworthy after the code signing cert expires (avoid availability risk).
    • Deploy the CA certificate and code signing certificate to all clients and servers.
• Roll out PowerShell v5 and disable PowerShell v2 (if not already done).
• Enable antivirus (if not already done).
• Use GPO settings for:
  • Script Block Logging (to analyze PowerShell usage).
  • Execution policy AllSigned (ensure necessary scripts are signed; remember signed scripts run in Full Language Mode).
  • Protected Event Logging (optional; roll out a public key for log encryption; do this last to simplify troubleshooting).

Regular effectiveness reviews

• Perform an effectiveness review after implementation (e.g., by an external assessor).
• Evaluate improvement opportunities annually and reassess settings (e.g., as part of a pentest or a dedicated review).