Awesome, This video is worth the time ! Just to add we can also use Internet Security Graph (ISG) to block the applications with Bad or No reputation data and that can be added as a rule in XML policy (Using Intune as well)
Hi Matt! To create a base policy, I've come to a process where I: 1. run BasePolicy (originally DefaultWindows_Audit) on new machine (w/ all necessary files) 2. run New-CIPolicy -Audit -UserPEs -Level Hash to get (A) all audited hits (no duplicates) 3. run New-CIPolicy -Audit -UserPEs -Level Publisher -Fallback Hash to get (B) list of signers, (C) unsigned files = leftover allowed hashes in the .xml and (D) the list of signed files = diff of audit hits(A) and unsigned files (C); note that (D) should be signed by one of (B) 4. Add list of signers (B) to BasePolicy and repeat. An issue is that after multiple iterations of this, there are still "new signers" that pop up despite that is was already added in a previous iteration. For example, cert X showed in iteration2 therefore added to BasePolicy. In iteration3, Cert X still shows up (with diff thumbprint) even though it was already added. I've looked through the list of signed files (D) in iteration2 for their thumbprints and if they matched to the thumbprint of Cert X in iteration2 and 3. But neither match. Perhaps this thumbprint is different somehow? Or perhaps this is a case of an EKU value I'm lacking? Would love to get your thoughts on if this is a viable process to follow. Bonus question: is there a process for adding EKUs to the BasePolicy? Thanks so much
Hey! Thanks for writing this all up. Unfortunately, I'd have a hard time offering any advice without seeing the policies and the corresponding CodeIntegrity events. The only certificate hashes you'll see in 3089 events are TBS hashes which aren't the same as thumbprint (which is a SHA1 hash and a different hashing algorithm). Perhaps you're talking about the same thing but calling it thumbprint? So IDK if that might be a source of trouble in troubleshooting the logs. Also as a sanity check, confirm that the policy was updated properly and that the PolicyHash in 3076/3077 events matches the expected policy file hash. Also, does the PolictGUID in the 3076/3077 event make sense? I can't say I've ever explicitly added EKUs to a policy. If I were to do that, I'd probably do it manually. This is the code I'd use to convert an OID into the value the EKU rule would expect: $EKUBytes = [Security.Cryptography.CryptoConfig]::EncodeOID('1.3.6.1.4.1.311.76.11.1') $EKUBytes[0] = 1 ($EKUBytes | % { $_.ToString('X2') }) -join '' Sorry I can't be of more assistance.
@@mattifestation Yeah, I used' thumbprint" wrongly here. What I meant to say was that the Signer CertRoot Values are the same. My understanding was that the CertRoot Value in the policies correspond to the thumbprints of the certificate. I see now that's false. It's still not clear to me what that Value is -- is it the "TBS" hash of ... something that relates to the actual cert thumbprint? My naive assumption was that I could 1. see Allowed CertRoot Value and 2. match it to the thumbprint of the cert signing a file. I will definitely check on the events again to see if the update worked -- I am redeploying my machine each time so I am expecting an update. Currently not using the Policy GUID yet because on 1809 :/ Cool, awesome to get the confirmation from you on the EKUs. And thanks so much for the code, will definitely be using it to try it out. As a clarification though, the EKUs Allowed only scope on the Allowed signers in the Policy file, correct? So if I have a cert NOT allowed in the policy with an EKU allowed in the policy, the file signed by the cert will still not be allowed to run in Enforce mode? Thanks so much for spending the time. Greatly appreciated.
@@chloeduan8301 My pleasure. Correct. Any deny rule will always take precedence over an allow rule. Thumbprint vs. TBS hash is certainly confusing. I don't know the difference between how those hashes are calculated, I just know that they are both hashes of the certificate. I've had to troubleshoot TBS hashes enough that I wrote Get-TbsHash which will display the TBS hash of a certificate. gist.github.com/mattifestation/660d7e17e43e8f32c38d820115274d2e Take care. -Matt
Note: a policy will only put PowerShell into Constrained Language mode if it is in Enforced mode. In Audit mode, PowerShell remains in Full Language mode. 1:19:15
Hi Matt, great video. However, I have a question or I'd rather say a confusion as this is my first time implementing WDAC. I followed your tutorials and everything worked for me but that is an app we installed and performed a trace for. How can I go about apps already installed? I want to write a policy for tens of hundreds of software installed on my VM (for test purposes), how can I gather a trace of all these software and output them into a file? Or better still, how can I scan the entirety of my system for installed software and file so that U can create an allow list for some and then restrict some? Thanks in advance
Hey, Joshua. To scan the entirety of a system, you'd start by calling `Get-SystemDriver -ScanPath C:\` and letting that run for a while. Then, to get at least an initial sense of the 3rd party signers available, consider doing a first run of `New-CIPolicy -DriverFiles $FilesFromGetSystemDriver -Level Publisher`. Because the output will likely be large and unruly, you're going to have to go through this process a few times in considering what you want or do not want in your final policy.
Thank you so much for another great video! I do have another question if you don’t mind: Do you know a good way to gather a list of all files authorized by Microsoft ISG? When a file is not authorized by ISG we get the 3091 or 3092 events on event viewer. In order to check if a file was authorized, we need to use the “fsutil” tool and we need to have the Ea Name with the value: KERNEL SMARTLOCKER ORIGINCLAIM So, would it be possible to create a list of all files with EA Name equals KERNEL SMARTLOCKER ORIGINCLAIM? Any idea is very welcome and appreciated. Thanks in advance!
Hey! Using James Forshaw's NtObjectManager module (www.powershellgallery.com/packages/NtObjectManager/1.1.33), you can retrieve extended attributes. Here's something you could play with to attempt to generate such a list (I haven't tested this on a WDAC system so your mileage may vary): ls C:\ -Recurse -ErrorAction SilentlyContinue | Where-Object { $File = Get-NtFile -Path $_.FullName -Win32Path -Access ReadEa -ErrorAction SilentlyContinue if ($File) { $ExtendedAttributes = $File.GetEa() $ExtendedAttributes.Entries | Where-Object { $_.Name -eq '$Kernel.Smartlocker.OriginClaim' } } }
Great guide but seriously Ivanti Application Control or Carbon Black can do this from a central location and push the config to all machines without the need for any commands, everything you done here can be done in a few minutes with either product.
Thank you for kind words, Pete. I would definitely encourage you to seize this opportunity to make similar videos or blogs posts if you haven't already highlighting just how easy it is, perhaps convincing your audience that the cost incurred is worth it over free.
There is no kernel mode application control and HVCI protection in Ivanti. So if attacker will have admin rights on target machine he will easily override blocking rules. And also native software mostly is better then 3rd party. WDAC can also be managed from central location - AD GPO. Of course the administration is worse without centralized GUI where you can easily apply changes.
@@hippogambler while it is missing those features with the product configured in the correct manner you can still lock out admins from making changes and go as far and restricting the change in services. You cant have WDAC is your only level of security on a system, e.g use LAPS change the admin password, in some environments, they are completely air-gapped But each to their own. every time we demo the different products WDAC always looses out due to admin overhead.
@@PeteAUS1983 i agree that WDAC in most cases will be admin overhead because it did not have cenrolized gui management. but in some cases where we have for example Windows server withe some roles installed and ther is no 3rd party software excluding AV or some EDR, then it can be used without pain in the ass. i suppose.
Just one commend rules are merged as well only and it was merged in your video as well :-). Compare 44:50 with 1:06:00 result 1:08:37. You will see that Rules are merged as well. I believe only settings like name and Id will stay from the first one.
Any idea why my Enforce Allow All policy is still causing issues with a script related to a COM object? The script contains an ActiveXObject declaration. I know ActiveX is out of development etc, I've messed with IE11 settings but can't get it to work. Completely unable to get this working even though the policy is Allow All (any enforce policy causes this). It just seems weird that something still seems to either be blocked or at least inhibited by the allow all policy? Any ideas?
There's a fixed set of COM CLSIDs that are supported when a policy is in enforcement mode. Here is a list of them. gist.github.com/bohops/26c706bed7116d111d0fe38e4197b5f8 Those CLSIDs are validated in the WldpIsClassInApprovedList function (docs.microsoft.com/en-us/windows/win32/devnotes/wldpisclassinapprovedlist). There is documentation that covers COM class allowlist in a WDAC policy. It can be found here: docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy I don't have experience with COM class configuration in WDAC policies so your mileage may vary. Good luck!
Hi. I woneder, if the path to the driver file in CI policy is not important? File name either? So the only parameters that is checked is the file vsrsion an signer?
Hey. Validating against file version and signer is an effective check but file name and path rules are possible, just at decreased security. This article covers all the configuration options: docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-file-rule-levels
@@mattifestation thanks for the fast answer. But i mean the paths in your example. You have puted the vmware files in some test directory and then scan it. And then the file paths are reflected in the policy. But when the windows starts the drivers are laded from the system32 directory. So the path in the policy is not conidered.
@@hippogambler Ah are you referring to the FriendlyName attribute in the policy XML? If so, that is just a human-readable note to annotate where the file originated from but that attribute is discarded when converted to binary form (.p7b). You can change/remove FriendlyName attributes with no affect on the policy.
@@mattifestation Yes, exactly, FriendlyName. I did not pay attention to name of this attribute. Just spotted a file path in the xml and thought that it should be important.
Awesome, This video is worth the time !
Just to add we can also use Internet Security Graph (ISG) to block the applications with Bad or No reputation data and that can be added as a rule in XML policy (Using Intune as well)
Really awesome dude
Hi Matt! To create a base policy, I've come to a process where I:
1. run BasePolicy (originally DefaultWindows_Audit) on new machine (w/ all necessary files)
2. run New-CIPolicy -Audit -UserPEs -Level Hash to get (A) all audited hits (no duplicates)
3. run New-CIPolicy -Audit -UserPEs -Level Publisher -Fallback Hash to get (B) list of signers, (C) unsigned files = leftover allowed hashes in the .xml and (D) the list of signed files = diff of audit hits(A) and unsigned files (C); note that (D) should be signed by one of (B)
4. Add list of signers (B) to BasePolicy
and repeat.
An issue is that after multiple iterations of this, there are still "new signers" that pop up despite that is was already added in a previous iteration. For example, cert X showed in iteration2 therefore added to BasePolicy. In iteration3, Cert X still shows up (with diff thumbprint) even though it was already added. I've looked through the list of signed files (D) in iteration2 for their thumbprints and if they matched to the thumbprint of Cert X in iteration2 and 3. But neither match. Perhaps this thumbprint is different somehow? Or perhaps this is a case of an EKU value I'm lacking?
Would love to get your thoughts on if this is a viable process to follow.
Bonus question: is there a process for adding EKUs to the BasePolicy?
Thanks so much
Hey! Thanks for writing this all up. Unfortunately, I'd have a hard time offering any advice without seeing the policies and the corresponding CodeIntegrity events.
The only certificate hashes you'll see in 3089 events are TBS hashes which aren't the same as thumbprint (which is a SHA1 hash and a different hashing algorithm). Perhaps you're talking about the same thing but calling it thumbprint? So IDK if that might be a source of trouble in troubleshooting the logs.
Also as a sanity check, confirm that the policy was updated properly and that the PolicyHash in 3076/3077 events matches the expected policy file hash. Also, does the PolictGUID in the 3076/3077 event make sense?
I can't say I've ever explicitly added EKUs to a policy. If I were to do that, I'd probably do it manually. This is the code I'd use to convert an OID into the value the EKU rule would expect:
$EKUBytes = [Security.Cryptography.CryptoConfig]::EncodeOID('1.3.6.1.4.1.311.76.11.1')
$EKUBytes[0] = 1
($EKUBytes | % { $_.ToString('X2') }) -join ''
Sorry I can't be of more assistance.
@@mattifestation Yeah, I used' thumbprint" wrongly here. What I meant to say was that the Signer CertRoot Values are the same. My understanding was that the CertRoot Value in the policies correspond to the thumbprints of the certificate. I see now that's false. It's still not clear to me what that Value is -- is it the "TBS" hash of ... something that relates to the actual cert thumbprint? My naive assumption was that I could 1. see Allowed CertRoot Value and 2. match it to the thumbprint of the cert signing a file.
I will definitely check on the events again to see if the update worked -- I am redeploying my machine each time so I am expecting an update. Currently not using the Policy GUID yet because on 1809 :/
Cool, awesome to get the confirmation from you on the EKUs. And thanks so much for the code, will definitely be using it to try it out. As a clarification though, the EKUs Allowed only scope on the Allowed signers in the Policy file, correct? So if I have a cert NOT allowed in the policy with an EKU allowed in the policy, the file signed by the cert will still not be allowed to run in Enforce mode?
Thanks so much for spending the time. Greatly appreciated.
@@chloeduan8301 My pleasure. Correct. Any deny rule will always take precedence over an allow rule.
Thumbprint vs. TBS hash is certainly confusing. I don't know the difference between how those hashes are calculated, I just know that they are both hashes of the certificate. I've had to troubleshoot TBS hashes enough that I wrote Get-TbsHash which will display the TBS hash of a certificate. gist.github.com/mattifestation/660d7e17e43e8f32c38d820115274d2e
Take care.
-Matt
Note: a policy will only put PowerShell into Constrained Language mode if it is in Enforced mode. In Audit mode, PowerShell remains in Full Language mode. 1:19:15
Thanks for detailed video. Could you please through some lights on blocking batch files using WDAC.
Lots of info, but very good. Thanks!
Hi Matt, great video.
However, I have a question or I'd rather say a confusion as this is my first time implementing WDAC.
I followed your tutorials and everything worked for me but that is an app we installed and performed a trace for.
How can I go about apps already installed?
I want to write a policy for tens of hundreds of software installed on my VM (for test purposes), how can I gather a trace of all these software and output them into a file?
Or better still, how can I scan the entirety of my system for installed software and file so that U can create an allow list for some and then restrict some?
Thanks in advance
Hey, Joshua. To scan the entirety of a system, you'd start by calling `Get-SystemDriver -ScanPath C:\` and letting that run for a while. Then, to get at least an initial sense of the 3rd party signers available, consider doing a first run of `New-CIPolicy -DriverFiles $FilesFromGetSystemDriver -Level Publisher`. Because the output will likely be large and unruly, you're going to have to go through this process a few times in considering what you want or do not want in your final policy.
Hello Matt, could you please provide a link of the previous video that you are mentioning at the start? Thank you
Ah yes, of course! th-cam.com/video/fWPoWVN5yh4/w-d-xo.html
Here's the full playlist: th-cam.com/play/PL2Xx-q-W5pKUNaNkakjZkLmfsNvMWPdNB.html
Thank you so much for another great video!
I do have another question if you don’t mind: Do you know a good way to gather a list of all files authorized by Microsoft ISG?
When a file is not authorized by ISG we get the 3091 or 3092 events on event viewer.
In order to check if a file was authorized, we need to use the “fsutil” tool and we need to have the Ea Name with the value: KERNEL SMARTLOCKER ORIGINCLAIM
So, would it be possible to create a list of all files with EA Name equals KERNEL SMARTLOCKER ORIGINCLAIM?
Any idea is very welcome and appreciated. Thanks in advance!
Hey! Using James Forshaw's NtObjectManager module (www.powershellgallery.com/packages/NtObjectManager/1.1.33), you can retrieve extended attributes. Here's something you could play with to attempt to generate such a list (I haven't tested this on a WDAC system so your mileage may vary):
ls C:\ -Recurse -ErrorAction SilentlyContinue | Where-Object {
$File = Get-NtFile -Path $_.FullName -Win32Path -Access ReadEa -ErrorAction SilentlyContinue
if ($File) {
$ExtendedAttributes = $File.GetEa()
$ExtendedAttributes.Entries | Where-Object { $_.Name -eq '$Kernel.Smartlocker.OriginClaim' }
}
}
Run that from elevated PowerShell, BTW.
@@mattifestation , Awesome! Thank you so much!
Great guide but seriously Ivanti Application Control or Carbon Black can do this from a central location and push the config to all machines without the need for any commands, everything you done here can be done in a few minutes with either product.
Thank you for kind words, Pete. I would definitely encourage you to seize this opportunity to make similar videos or blogs posts if you haven't already highlighting just how easy it is, perhaps convincing your audience that the cost incurred is worth it over free.
There is no kernel mode application control and HVCI protection in Ivanti. So if attacker will have admin rights on target machine he will easily override blocking rules. And also native software mostly is better then 3rd party. WDAC can also be managed from central location - AD GPO. Of course the administration is worse without centralized GUI where you can easily apply changes.
@@hippogambler while it is missing those features with the product configured in the correct manner you can still lock out admins from making changes and go as far and restricting the change in services.
You cant have WDAC is your only level of security on a system, e.g use LAPS change the admin password, in some environments, they are completely air-gapped
But each to their own. every time we demo the different products WDAC always looses out due to admin overhead.
@@PeteAUS1983 i agree that WDAC in most cases will be admin overhead because it did not have cenrolized gui management. but in some cases where we have for example Windows server withe some roles installed and ther is no 3rd party software excluding AV or some EDR, then it can be used without pain in the ass. i suppose.
Does Package Inspector work with MSI installers? If not, what do you do if the installer is an MSI instead of an EXE?
It does work with MSI installers. Give it a try and if it doesn't work, feel free to post a response with details describing the issue. Thanks!
Just one commend rules are merged as well only and it was merged in your video as well :-). Compare 44:50 with 1:06:00 result 1:08:37. You will see that Rules are merged as well. I believe only settings like name and Id will stay from the first one.
Any idea why my Enforce Allow All policy is still causing issues with a script related to a COM object? The script contains an ActiveXObject declaration.
I know ActiveX is out of development etc, I've messed with IE11 settings but can't get it to work. Completely unable to get this working even though the policy is Allow All (any enforce policy causes this). It just seems weird that something still seems to either be blocked or at least inhibited by the allow all policy?
Any ideas?
There's a fixed set of COM CLSIDs that are supported when a policy is in enforcement mode. Here is a list of them. gist.github.com/bohops/26c706bed7116d111d0fe38e4197b5f8 Those CLSIDs are validated in the WldpIsClassInApprovedList function (docs.microsoft.com/en-us/windows/win32/devnotes/wldpisclassinapprovedlist). There is documentation that covers COM class allowlist in a WDAC policy. It can be found here: docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy
I don't have experience with COM class configuration in WDAC policies so your mileage may vary. Good luck!
Hi. I woneder, if the path to the driver file in CI policy is not important? File name either? So the only parameters that is checked is the file vsrsion an signer?
Hey. Validating against file version and signer is an effective check but file name and path rules are possible, just at decreased security. This article covers all the configuration options: docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-file-rule-levels
@@mattifestation thanks for the fast answer. But i mean the paths in your example. You have puted the vmware files in some test directory and then scan it. And then the file paths are reflected in the policy. But when the windows starts the drivers are laded from the system32 directory. So the path in the policy is not conidered.
@@hippogambler Ah are you referring to the FriendlyName attribute in the policy XML? If so, that is just a human-readable note to annotate where the file originated from but that attribute is discarded when converted to binary form (.p7b). You can change/remove FriendlyName attributes with no affect on the policy.
@@mattifestation Yes, exactly, FriendlyName. I did not pay attention to name of this attribute. Just spotted a file path in the xml and thought that it should be important.