KB5025885: Dealing with CVE-2023-24932 via Proactive Remediation & Configuration Items

Required Reading: KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 – Microsoft Support

Related: KB5025885: Dealing with CVE-2023-24932 for your ConfigMgr boot images.

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

Proactive Remediation

Then assign to your Windows Devices.

Configuration Baseline

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)


27 thoughts on “KB5025885: Dealing with CVE-2023-24932 via Proactive Remediation & Configuration Items”

    • I’ve never used Ivanti. But whatever mechanism Ivanti has for deploying PowerShell scripts, you could pretend you’re using Intune.
      Ensure May patches are already installed, then deploy script
      Set the variables.
      – UseCase = “Intune”
      – Remediate = $true

      If you have a Baseline type feature in Ivanti, then use that instead, and use the Detection / Remediation process
      If you need more help, contact Ivanti support.

  1. We’re not currently utilizing licensing that allows us to deploy as a PR. Will the script still work if pushed as a policy script, using the variables you recommended to the Ivanti user?

    • Yes… just make sure the May Patches are completely installed before sending the script.

      You might be better off making this into an Intune App, where the detection method is the Event Log showing a successful update …
      $DBXUpdateSuccess = Get-EventLog -LogName System -Source “Microsoft-Windows-TPM-WMI” -InstanceId 1035 -ErrorAction SilentlyContinue

      That way if will continue to retry until you get the event log saying it has been applied.

      • Just wanted to say that this was the way to go, I was also able to use the section of your script to detect if SKUSiPolicy.P7b was present as a requirement prior to running the remediation script itself to help stop premature installs. Testing it on my lab VM now!

  2. Hi, Many thanks for this. Unfortunately I’m getting a 0X87D00327 Script Not Signed Error. I’ve already got a custom client pointing to a collection that my test devices are in set to with the Enable Powershell Policy set to bypass, is this sufficient or does it need to be set to signed?

    • you should be able to set it to Bypass..
      But feel free to sign it with your own enterprise signing certificate.

  3. Very good script
    In the case of Intune, it’s probably not the best idea to restart users after 8 hours.
    I will try to remake this script as an application in conjunction with psadt.

  4. Running this manully and the fix is applied however I see this error.
    And when using it as an ProActive remediation it fails due to to error i belive.

    Copy-Item : Illegal characters in path.
    At line:86 char:13
    + Copy-Item -Path $SKUSiPolicyPath -Destination “$($SystemV …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Copy-Item], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Commands.CopyItemCommand

  5. Hi gwblok,
    Thanks a lot of the script, it was really helpfull!

    One quick question:
    Would be possible to Trigger the reboot for a specif time (17:00 for example) instead of using the 8h timer?

    I guess I would need to change or add something at this piece of code
    #Restart to Trigger Remediation
    $Process = “C:\windows\system32\shutdown.exe”
    $ShutdownArgs = ‘/r /f /t 28800 /c “Apply fix for CVE-2023-24932″‘
    Start-Process $Process -ArgumentList $ShutdownArgs -NoNewWindow

    Thanks in Advance!
    Greets for Brazil

    • Yeah, if you want to schedule the reboot for a specific time, you’d have to add some powershell logic to do it.
      Get Current Time, then find the difference between current time & 1700, write that value to a variable.
      and then change the 28800 to that variable.

      Perhaps there is another way to do it, but that’s how I’d do it (unless I found a better way via Google)

  6. So I think this may be what I need to fix issues with users who just recently (last few weeks) had an in-place Windows 11 update done. After the upgrade about a day or two later they get the Recovery boot BSOD and the only way to fix it for them is to disable secure boot. I guess setting this up is the way to go?

    • I don’t think this is your issue. If it was, your devices would have BSOD during the upgrade itself and never made it to Win11.
      After a device upgrades, it typically reaches out to WU to pull down additional drivers, etc. Perhaps these devices are pulling down something after the upgrade that causes it.
      Perhaps other deployments you have for Win11 only devices that just take a couple days to evaluate and be deployed?

      • I will dig more into it however it is just something that started to occur for our in-place upgrade devices after the May 2023 update was released. I am also thinking maybe something with the stock Lenovo recovery drive could be a culprit.

      • Fyi after rolling out these mitigations to a few hundred HP laptops running win 10 22H2 we started testing win 11 22H2 feature updates via wufb and got a similar result as Joe — they all bsod’d after the upgrade reboot with 0xc4000028. Only disabling secure boot gets them to boot into windows 11. The fixes in the ms kb for for that mitigation and bsod don’t work, and no amount of playing with the bios secure boot settings work either. I was sure HP sure start was the culprit, particularly “boot key protection”, but since Joe mentioned Lenovo I now think something else. Not sure how the oem recovery partition could be the cause, but it’s a possibility.

  7. Hi,

    Is there a up to date script for this for July 2023?

    The UEFI Forbidden List (DBX) is used to block untrusted modules from loading. The Code Integrity Boot Policy (SKUSiPolicy.p7b) uses the Code Integrity feature of Windows to prevent untrusted Windows boot managers from loading when Secure Boot is enabled.

    After installing the Windows updates released on or after July 11, 2023, open a Command Prompt window running as an Administrator, type the following command and then press Enter:

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x30 /f

    • You don’t really need to change it, the script will set that registry value every time the event logs rolls over.

      So as long as you keep running the remediation, it will eventually trigger again.

    • I’ve updated the blog post with additional information, and published a new proactive remediation that is slimmed down for people who have applied the July Patch.

      • Great post!!
        FYI. Im getting eventId1034 instead of 1035 for the same “Secure Boot DBX update applied successfully” message

  8. What a nightmare. Tested this mitigation out for weeks before rollout without issue, then decided to try and put a few patched win 10 22h2 machines in a windows 11 22h2 feature update wufb rollout group, and they both bsod’d upon reboot with 0xc4000028 “digital signature” error. Tried the recovery instructions regarding disabling secure boot and recopying the efi files, and re-enabling secure boot, but no dice. I suspect something regarding HP sure boot but not sure what exactly.

    • we had same error code after restarting the system. It looks the boot file (Bootmgfw.efi) version on C drive and EFI partition are different. we are working on a script to match the boot file versions as per the suggestion from MS.

  9. Well the script is wonderful and THANKS for it.
    The main question here is why the remediation should be executed all the time. Windows Events are overridden in time. So the best way will be to create dummy registry key when remediation is successful. For the detection part to check if event viewer have the logs and/or this dummy registry key is created.

    • Valid Question. Here was my thought process. It doesn’t hurt anything to re-run remediation. It will happen randomly, but fairly infrequently. And in a few months, MS will have pushed the remediations to everything anyway, and the Remediation script will be no longer needed and can be removed. So for something that you only needed for 6-8 months, I figured I’d like to keep it simple, and not write other things that should be cleaned up later.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.