« Previous 1 2 3 Next »
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).
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 »
Buy this article as PDF
(incl. VAT)