Preventing Shift-Restart into recovery mode?

[sp123]

Thanks Garacesh,

 

So I can make do with just those 3 and not all of the above. All I want to do is make the "Reset my PC" option is not available, be it via SHIFT-RESTART, or any of the other ways...

Wouldn't I need reagentc /disable as well?

 

Thanks for helping a non-techie!

 

sp

[Garacesh]

Honestly I've never even heard of reagentc /disable, and certainly haven't utilised it here. I guess that's up to you to image machines and test each one, figure out which is best for you.

(if reagentc /disable does produce different results, though, do please let us know!)

If I try and execute reagentc /disable as an admin on a standard W10 pupil machine, it returns REAGENTC.EXE: Windows RE is already disabled. I have no idea if this is related to the previous commands mentioned or if it's something else.

 

If it helps, I'll try and explain the outcome of the previous commands a bit:

A Windows 10 computer that is improperly shut down will not try to enter the recovery sequence, but will still disk check. Disk check is non-interactive though, so I don't really care.

You can still hold Shift and reboot into the recovery environment. The blue screen with 'Continue', 'Troubleshoot' and 'Turn off your PC'. If you click Troubleshoot, there's usually an option there to wipe the PC and reimage Windows, but that option is now not there thanks to the previous commands.

The option to change start-up settings is still available, though. I personally left that there to allow Safe Mode booting for troubleshooting.

[BOOT]

If you want to disable it completely...

Little bit of powershell:

New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\bootim.exe"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\bootim.exe" -Name "Debugger" -Type "String" -Value "taskill /F /IM bootim.exe" -Force

[mavhc]

1) Is there a difference between this: Reagentc /disable, and Reagentc.exe /disable?

 

They're the same

 

2) Would all the bcdedit command lines above be "knocked out" by simply typing: bcdedit /set {globalsettings} advancedoptions false ?

 

This command suggests no: bcdedit /? id

 

{globalsettings} Contains the collection of global settings that should be inherited by all boot application entries.

 

Inherit usually implies that other settings that are more specific will override these settings.

 

3) I've seen both bcdedit /set {current} recoveryenabled off, and instead of "off", then word "no". Would it matter? Above it says "no".

 

This command gives the answer: bcdedit /? formats

 

bool A boolean value. The following values correspond to TRUE:

 

1, ON, YES, TRUE

 

The following values correspond to FALSE:

 

0, OFF, NO, FALSE

 

So "off" and "no" are the same.

 

4) Must I enter each bcdedit cmd and press enter after each one?

 

Yes, or put the commands in a text file, rename it to .bat instead of .txt, right click, run-as-administrator

[sp123]

Thanks Garacesh, boot and Mavhc.

 

Boot, would what you wrote above mean you I would not even be able to access "start-up settings" as well? Meaning it would block safemode too? It just blocks it all....

 

 

Also, I read that it's also possible to enter not just with SHIFT- RESTART, but also by clicking the power button, then pressing SHIFT, then ENTER.

 

Is it the same?

 

Would bcdedit/deletevalue {current} recoverysequence block that too?

 

(I'd test, but I haven't installed Win 10 yet).

 

 

Thanks again for all the help!

Edited November 19, 2019 by sp123

[Garacesh]

Also, I read that it's also possible to enter not just with SHIFT- RESTART, but also by clicking the power button, then pressing SHIFT, then ENTER.

Yes. It's not so much the exact sequence that's the trigger, the point is you initiate a restart whilst holding Shift

[azc]

On 19/11/2019 at 09:19, BOOT3988 said:

If you want to disable it completely...

Little bit of powershell:

 

New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\bootim.exe"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\bootim.exe" -Name "Debugger" -Type "String" -Value "taskill /F /IM bootim.exe" -Force

 

 

 

Did you mean

taskkill

with two k's?

[CHiLL]

23 minutes ago, azc said:

 

Did you mean

taskkill

with two k's?

 

I believe they did mean two k's, though it shouldn't be necessary as "reagentc /disable" will disable Windows Recovery. That's all we did several years ago and haven't had issues since.

Edited April 10, 2025 by CHiLL

[azc]

@CHiLL I have reagentc /disable already pushed out but it doesn't prevent going into the recovery screen with shift+restart.

[azc]

I finally completely removed access to the Recovery Options menu with this domain-wide script. Now Shift+Restart does nothing!

 

@echo off

REM Check if bootim.exe exists
if not exist C:\Windows\System32\bootim.exe goto end

REM Take ownership of the file
takeown /f C:\Windows\System32\bootim.exe

REM Grant full control permissions
icacls C:\Windows\System32\bootim.exe /grant administrators:F

REM Rename bootim.exe to bootim.azc
rename C:\Windows\System32\bootim.exe bootim.azc

:end

 

I also removed the Recovery section from the Windows Settings app with this GPO.

[psydii]

we found the registry hack to launch taskkill as the debugger worked very well for us.  For those wondering, several entry points into the Recovery Environment, do not actually start WinRE initially, instead they tear down most of the current windows environment and launch a special shell "bootim.exe" that looks a lot like the WinRE gui, and has many of its functions. This is why simply disabling winre with reagent /disable, and/or changing options in the boot configuration database editor is not enough.

 

We use all three. That said, ensuring a device is bitlocker encrypted goes a long way to closing off many of the work-around that students find even with almost everything around the Windows Recovery environment locked down.

 

For those who might find this thread in the future, here is a list of other things we do to protect the integrity of the Windows OS and its security:

Bios/EUFI password - required to enter /edit settings

Bios/EUFI boot device options menu password: required to enter the boot device options menu

Boot order configured for HDD/SSD/NVMe with the windows partition on it, ONLY. USB/Network boot disabled.

The Windows 11 security defaults around Virtualisation/Boot/App/OS Integrity.

Bitlocker.

The WinRE disabling configurations with  REAGENT, BCDEDIT,  and the BOOTIM/TASKKILL trick.

Applocker rules restricting apps to launch from only locations that users do not have RW access (with exceptions, but these need to be carefully managed - don't do something silly like allow all apps signed by Microsoft to run from any folder, as this can be chained against other tricks to launch things you thought you'd restricted!)

 

Have I missed anything?

[CHiLL]

I've just checked my shift+restart action and it does bring up the "Choose an option" screen, though the options are limited:

• Continue
  • Exit and continue to Windows 11
• Use a device
  • Use a USB drive, network connection or Windows recovery DVD
• Troubleshoot
  • Reset your PC or see advanced options
• Turn off your PC

Within the Troubleshoot option, the only options are "Start-up Settings", which is basically just safe mode options, and "UEFI Firmware Settings", which won't work because the BIOS is password protected.

 

We just use "reagent /c" during the imaging process.

 

I've just quickly gone through my GPOs and the only related thing I can see is:

 

Key path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Value name: SafeModeBlockNonAdmins

Value type: REG_DWORD

Value: 1

[azc]

Only removing access to the Advanced Startup Menu entirely was sufficient.  Users were able to access it and choose to boot from a USB device even if those options are not enabled in the BIOS. We were alerted to this problem when a machine was found with Ubuntu installed on it. Luckily we were able to interrogate the Impero logs to identify the user and the actions they took.

[mavhc]

On 11/04/2025 at 11:23, psydii said:

Applocker rules restricting apps to launch from only locations that users do not have RW access (with exceptions, but these need to be carefully managed - don't do something silly like allow all apps signed by Microsoft to run from any folder, as this can be chained against other tricks to launch things you thought you'd restricted!)

 

Have I missed anything?

The 4000 user writable folders inside C:\Windows, probably something about C:\ProgramData and the ability to create folders in C:\ by default

[GeneMoody-Action1]

Does rename of bootim.exe not just repair on an SFC? That would be my first concern, if not I would not rename it I would simply remove ALL permissions, and make admin the owner.

bootim and WinRE are not the same thing, but they do look almost exactly the same.
WinRE is a WIM boot image, reagentc /disable deactivates WinRE, the recovery environment WIM and XML files can be located by reagentc /info (If enabled) you can delete them too, but if you ever change your mind, you will need to pull them form install media to get it back. You can also remove the recovery partition and just absorb it into the drives other partitions if at the end. But you can nuke it none the less.

IIRC bootim actually initiates as the computer is powering off, it is not "booting" to it, it only looks that way because or the similarities between it and WinRE.
I *believe* it is launching it in lieu of an actual shutdown.

So just keep in mind you are not tampering with one thing, you are actually tampering with two.

tinkering at that level can cause future update issues, so in reality the best way to handle this is with policy. Let an unauthorized tinkering individual explain to HR why they are corrupting company systems unauthorized. Make it a potential resume generating event, the message will get around, and make examples of the people that do it.

If that is simply not an option, I would go for a slightly different approach, disable WinRE (perfectly fine, not in any way essential to OS).
And then a simple app/script/service to check every 100ms and kill any instance of bootim.exe found in active processes.

In theory you could try applocker on it as well, or install sysmon from windows sysinternals, log process creation, tie a task to the event or a powershell||WMI event log monitor to the event.

Just to prove it works fast, I would try sysmon first. Install, then configure sysmon with the following XML
 

<Sysmon schemaversion="4.50">
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <Image condition="end with">bootim.exe</Image>
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

 

Subsequent event ID 1 in Microsoft-Windows-Sysmon/Operational should correspond to an instance of that binary being loaded. 
Right click that event and choose "Attach task to this event" have that task pop off "tskill bootim"

Albeit none of this is tested it is off the top of my head, but it should work.
You don't prevent them starting it, you immediately kill it when they do!

The sysmon install/configure and the task exported as XML, can easily be scripted across a large endpoint count.
Setup of the whole thing (including downloading sysmon) could be a single powershell script.

I do not own a windows system on HW, only in virtual labs. But I would be curious to know if it worked.

P.S. if I needed to do this non-hackish, a kernel driver would be best, because it could be intercepted pre-execution like an AV would, but I expect the "non-techie" implies not coding drivers any time soon. Good luck!

[CrootUK]

New ASR rule now out that does this

https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference#block-rebooting-machine-in-safe-mode

[GeneMoody-Action1]

2 minutes ago, CrootUK said:

New ASR rule now out that does this

https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference#block-rebooting-machine-in-safe-mode

Well that seems a heck of a lot easier, lol.