Consider the scenario, you have a couple of servers in this example in a failover cluster It’s a good idea for compatibility to use the same hardware answer, on the software front I mean the operating system.
Let’s consider for a moment the operating system is Windows server 2019 - however, one of the service you can run majority of applications and the management team Whereas on the other, you are unable to run many of these tools.
This will include simple things like looking at the event viewer, trying to start management console, trying to view the defender GUI - They seem to work perfectly well on one of the servers But those same tools completely fail to work on the other server.
Blocked actions error
You are presented with this dialogue on the server that does not work and application "do not run"
Error is: “ An administrator has blocked you from running this app. For more information, contact the administrator”
Obviously this is the proper executable, so why is it untrusted, this is an official Microsoft management tool.
Don’t go down the wrong rabbit hole
There are a couple of things that can send you down a rabbit holes here the first is it says publisher unknown And then towards the bottom, you get the option to show the publishers certificate.
If you choose this option, nothing happens, Which would lead you down the path that there’s something wrong with the certificate unfortunately you’re unable to get to the certificate management console because it’s been blocked?
Unfortunately this has nothing to do with an actual certificate that you’d find in the certificate management console - this is the code integrity certificate that can be found.
Integrity compromised?
Code. Integrity is the problem in this example because it affects multiple applications because the signature be verified - save this as a signature with a certificate rather than just a plain certificate.
Code integrity what’s that?
Code Integrity is a security feature in Windows that verifies the integrity of a code (e.g., drivers or system files) before it is allowed to run. Its main purpose is to prevent unsigned, untrusted, or tampered code from being executed, thereby protecting the system from malware and unauthorized changes.
Check the CaRoot Folder
The coating integrity functions with a folder in the following location:
C:\Windows\System32\CatRoot
In the folder you will see 2x folder as below:
The folder we are interested in is the folder starting F750E as highlighted above in the image when you enter this folder you should see all the "cat" files that is required by Code Integrity:
These are essential for Code Integrity to work, however on the affect system this is what that folder look like, we have an empty folder, this explains the issue as the "code publisher" is in those "cat" files:
These "cat" files contain the certificate that Windows needs to verify the integrity for Code Integrity:
If you do not have these files Windows will not function very well at all.
Why is this folder empty?
In this instance the files were deleted to save space (which was a little foolish as that folder on equates to 690MB) but that will render Windows useless.
This issue was caused by administrator action, but this can also occur with malware and ransomware as well.
Catroot and CatRoot2
Catroot2 folder in Windows can be safely deleted, but it must be done with caution. This folder is used by Windows Update to store temporary files necessary for the update process, particularly for cryptographic operations related to verifying update packages.
However, you should not delete the Catroot folder in Windows.
Check Event Log
Windows will also log these events to this following event log:
Microsoft-Windows-CodeIntegrity/Operational
That will then look like this and as you can see I have a problem with a vmware executable that is "not" signed but this log is limited to a single application not the whole of Windows:
How can I fix this?
Well, the security files have been deleted, however you do have a working server that runs the same OS version as this "offline" server so you can fix this with Robocopy with this command:
robocopy \\bearwrk1.bear.local\C$\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
Microsoft-Windows-CodeIntegrity/Operational
That will then look like this and as you can see I have a problem with a vmware executable that is "not" signed but this log is limited to a single application not the whole of Windows:
How can I fix this?
Well, the security files have been deleted, however you do have a working server that runs the same OS version as this "offline" server so you can fix this with Robocopy with this command:
robocopy \\bearwrk1.bear.local\C$\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
You will need the update the source workstation to a valid name for your domain, this will take a moment to copy.
WARNING : Please ensure this is the same OS version with roughly the same hotfixes installed to make this work, you cannot copy files from Server 2012 R2 if you are using Server 2019 as an example!
When the files are copied, Windows will take a couple moments to catchup with those files not being back online, then you need to run this commands to check the consistency, if error are found this will attempt to repair them:
sfc /scannow
DISM /Online /Cleanup-Image /StartComponentCleanup
sfc /scannow
DISM /Online /Cleanup-Image /StartComponentCleanup
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth