วีดีโอ

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.

Unfortunately, the only way I know how to do that is by manually adding rules in the XML policy, which is error-prone. To create a publisher rule, you would need the TBS hash via the IssuerTBSHash field and the leaf certificate name via the PublisherName field. Experimentation will be required and you won't have a good way to test since you won't have the binary.

It's a good question and I honestly don't remember. I'd try experimenting a bit and refer to this documentation as a baseline: base policies union. It doesn't really answer your question but hopefully you'll have enough to experiment with. Sorry I couldn't offer a conclusive answer.

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

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

Hey, good question. A policy file will only have a PolicyID is it was built to support multiple policies. So you'd have to supply the -MultiplePolicyFormat switch with New-CIPolicy to generate that. Here's an example of that in MS docs: docs.microsoft.com/en-us/powershell/module/configci/new-cipolicy?view=windowsserver2022-ps#example-1-create-a-policy-in-multiple-policy-format I hope that helps!

@@mattifestation ​ Thanks so much for the reply! I will definitely try that. However currently, I seem to be stuck on the DenyAllAudit.xml policy part. After setting that policy, and rebooting, my Azure VM doesn't seem to boot anymore ("vm agent status not ready", but vm still running). From your video, it seems like your vm boot rather quickly, I'm thinking it might have something to do with the overload of telemetry for the Audit of all files. Did you ever run into this problem or did you just allocated more resources for your VM to be able to handle the reboot data? (if this is the issue)

@@chloeduan8301 Out of curiosity, are you running a Server 2019 VM? If so, deployment of the deny all policy is an unfortunate, known issue. github.com/mattifestation/WDACTools/issues/5#issuecomment-1078767703 Could you try to deploy C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml as a test? Does that allow the VM to boot and does it log events?

@@mattifestation Yes! That's exactly what I am using - the Windows Server 2019 Gen2 VM. Thanks for the thread, seems like that's what is causing the problem. Tried the DefaultWindows_Audit.xml and it does allow the VM to boot, and doesn't report any kernel events other than Windows\System32\drivers\mlx5.sys, even with the WHQL signers removed, which I am assuming is expected? After another look, the file is Authenticode-Signed and Microsoft-Signed, so I wonder why it caught it in the first place🤔

@@chloeduan8301 Great! I'm glad we're on the same page then. I can't speak for what might be expected to create audit events in Azure VMs but even with WHQL rules removed, I would expect very few drivers to be logged in a stock VM. Most of the built-in driver ought to be Windows-signed.

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!

At least, it would work in VBA. Haven't tried it in PowerShell.

Certainly! www.crowdstrike.com/blog/protected-processes-part-3-windows-pki-internals-signing-levels-scenarios-signers-root-keys/ And they're all defined in WDACTools here: github.com/mattifestation/WDACTools/blob/master/WDACAuditing.psm1#L23-L44

@@mattifestation , thank you so much for all the good knowledge! Enjoy life :-)!

@@mattifestation Thank you!

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!

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!

Really awesome dude

Oh thank you so much for bringing this to my attention! This is great!!!

@@mattifestation it would be great if you could help with that.

@mattifestation I found that ALLOW_ALL rule is presented in policy. For what purpose? It does not make any sense.

@@hippogambler Hey can you point me to the time in the video where I mention that? I haven't thought about this subject for a while so I could use some assistance to jog my memory. Thank you

@@mattifestation you did not mention that. I just saying that the new blocking portion of tules provided by ms, what i mention above, is not working, becase it has some allow_all rules. And i was asking you about some help, to underdtand, is this a bug or feature. 😄

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.

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.

Hey. All the instructions for this process are documented in my blog post: posts.specterops.io/code-signing-certificate-cloning-attacks-and-defenses-6f98657fc6ec

@@mattifestation Thank's nice blog, here in my W7 kernel32.DLL is not digitally signed

@@valleyview5417 It's probably catalog-signed. Run Get-AuthenticodeSignature on it in PowerShell and this post will offer some more info on catalog signing: www.exploit-monday.com/2017/08/application-of-authenticode-signatures.html

@@mattifestation Thank's for help