TLDR: GitHub: garytown/ConfigMgr/Baselines/CVE-2023-24932
Disclaimer: Before continuing, I've created all of this in a very short time with VERY LITTLE testing, so please, as with anything you're pulling from the internet, inspect and test before deployment. - Feedback Welcome!!
23.07.17 - July patches have been released which now automatically applied the revocation files, which greatly simplified the process. Now, after the July update, you only need to apply the registry setting to trigger the installation of the remediation, which will then create the event id for success after the reboot. At this point, you have a couple of options:
- Push a registry update to all machines, using the event log as your detection method. Run this for a couple months. Note, every time the event log clears, it will reapply this registry value to trigger the remediation, which doesn't hurt anything.
- Updated PR Detect Script | Remediate Script on GitHub (look for July in name)
- During OSD, make sure the July patches are installed, then apply the registry value and reboot.
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot -Name AvailableUpdates -Type DWord -Value 48 -Force | Out-Null
23.05.24 - Updated the Proactive Remediation scripts to mount the sysvol to c:\windows\temp\sysvol instead of S:\, which was launching explorer at detecting a new volume on some systems.
23.05.16 - Updated the Proactive Remediation versions of the script (include "v2" in name), trying to resolve reported bug. | Confirmed the v2 proactive remediation scripts resolved issue.
23.05.15 - Modified the script to do a HASH check of SKUSiPolicy.P7b file, if the one in boot partition matches the one in windir, it marks the device as compliant. Otherwise, the way the script was written, if the log entry in the system log ages out, the device would report as non-compliant and run the remediation again (which isn't a big deal, but it would trigger a restart). Knowing this, you can either: Remove the restart from the script and have it reapply the remediation each time the eventlog roles over and the entry goes missing or use this updated method to detect remediation based on the file hash.
------ Original Post:
I've created a script that can be used for Configuration Manager Configuration Items & Intune's Proactive Remediation. The script will:
- Check System Event Log for ID 1035 [More Info]
- Test if 'System32\SecureBootUpdates\SKUSiPolicy.P7b' exist
- If Yes, Continue, if NOT, exit reminding you to apply May Patches
- Test if SKUSiPolicy.P7b has already been copied to the EFI partition (EFI\Microsoft\Boot)
- If Yes, skip the copy, if No, copy the file to the EFI Partition
- Update the Registry Key (Which resets after reboot)
- Trigger Reboot if Fix Event Log ID 1035 not exist after May Patches have been applied
- Feel free to remove this... just know it might take longer for fix to apply
Then assign to your Windows Devices.
Add information from the MS Website
Check the Boxes for Windows 10 & 11
Set the CI Setting to Script / String, then add the scripts from GitHub
Create Compliance Rule, where Operator: Equals & value: "Compliant", Check the box for "Run the specified remediation script when this setting is noncompliant.
Add the CI to your Security Basline
Test & Deploy
The Script (on Github)