Reducing your attack surface

En Garde

Creating a Default WDAC Policy

Now you can create a new WDAC policy in which you check the system for installed applications. Once the policy is ready, its format is converted to binary so that Windows can use its contents. All installed applications need to be considered trusted before you start defining a policy, so I recommend that you check the reference PC for software that can load any DLL and run code or scripts; then, initialize the variables to be used. The following examples use InitialScan.xml and WDACPolicy.bin as names of the files to be created:

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"
$CIPolicyBin=$CIPolicyPath+"WDACPolicy.bin"

Next, define the storage location for WDAC policies and create a WDAC policy:

$CIPolicyPath="C:\CIPolicyStore"
New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy -UserPEs 3> CIPolicyLog.txt

The PcaCertificate parameter adds the highest available certificate in the specified certificate chain to the list of signature providers and is usually located directly below the root certificate, because verification does not extend beyond the certificates contained in the signature provided. The UserPEs parameter specifies that the PowerShell cmdlet should also scan files in user mode. You need to convert a new WDAC policy to binary format,

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

before you can distribute it by means of a group policy.

Creating a Path Rule

As of Windows 10 v1903, policies for WDAC can contain path-based rules. For this to happen, a new FilePath parameter has been added to the New-CIPolicy cmdlet. The command

New-CIPolicy -f .\IT-Admin-Policy.xml -l FilePath -s C:\<MyApplication> -u

generates a WDAC policy that can act as a permit-or-deny policy for everything to which the user does not have write access. If your users do not explicitly require certain applications, Microsoft recommends blocking them. Table 1 lists the applications or files that can be used by attackers to circumvent whitelisting policies, including WDAC.

Table 1

WDAC Dangers

Attack Files
`addinprocess.exe`	`fsiAnyCpu.exe`
`addinprocess32.exe`	`kd.exe`
`addinutil.exe`	`lxssmanager.dll`
`bash.exe`	`msbuild.exe`
`bginfo.exe`	`mshta.exe`
`cdb.exe`	`ntkd.exe`
`csi.exe`	`ntsd.exe`
`dbghost.exe`	`rcsi.exe`
`dbgsvc.exe`	`system.management.automation.dll`
`dnx.exe`	`windbg.exe`
`fsi.exe`	`wmic.exe`

WDAC and Group Policy

The easiest way to assign a WDAC policy to managed clients is with a group policy, for which you can use the WDAC file created earlier. Start the Group Policy Management Editor, create a new group policy, and navigate to Computer Configuration | Administrative Templates | System | Device Guard . When you get there, enable the Deploy Windows Defender Application Control configuration and enter the path to the WDAC policy (Figure 2).

Figure 2: Group policy lets you assign WDAC policies to users.

You do not need to copy the policy file to each computer; instead, copy it to a file share that all computer accounts can access. Each computer account needs access permissions for the file. If you have problems with the policy, it's usually helpful to check the Windows Event Viewer. You will find WDAC logging in Applications and Services Logs | Microsoft | Windows | CodeIntegrity | Operational .

« Previous 1 2 3 Next »