We recently deployed the latest EMET to our client machines utilizing SCCM. Our machines never had EMET before, but the deployment was installing the software without issue. Shortly after the install, our clients started to receive new policies they never had before.
One of these new policies changes DEP. When DEP is configured, it changes a setting in the BIOS. This is bad, at least for us as we utilize BitLocker heavily. Changes to a machine’s hardware, OS, or BIOS baseline will cause BitLocker to prompt for a recovery key. The general fix for these kind of situations is to grab the machines recovery key and unlock the machine, then suspend and re-enable BitLocker. This causes BitLocker to acknowledge the new baseline. Unfortunately, that is a very manual process that we must now perform on all the machines. There is no real work around for this.
During all the turmoil this setting caused, we discovered a few of our users do not have BitLocker recovery passwords backed up anywhere. These users were unable to get into the machine, and the service desk couldn’t assist due to the keys not being backed up. We believed these users would loose their data.
I started to think about how to get back into these machines and it hit me. When you insert a CD into a BitLockered machine, it causes the BitLocker to prompt for a recovery password. However you don’t have to provide one if you remove the CD and reboot. By removing the CD, you effectively bring the machine back to it’s expected baseline. Since it is a BIOS change, I thought, what if we just change it back. I booted one of the affected machines into PXE, opened up the debug command prompt (If enabled in SCCM, press “F8”) and entered the following command to try and change the DEP setting back:
BCDEdit /Set nx
I then rebooted the machine and *poof* Windows loading logo appeared. We were able to save a few of our users from having an unfortunate week thanks to this trick.
So I was playing around with custom services in C# a couple years back. I never created a service before so I was going off of Microsoft’s MSDN articles and a few blogs that Google searches turned up. They all followed the same pattern.
This solution works fine, but I don’t really like it much.
Fast forward to about a month ago. We had some issues with one of our servers. One of the steps in troubleshooting the issue was to manually check what the machine and resources looked like from Local System’s perspective. To do this, I opened an instance of cmd.exe under the Local System account interactively using the built-in tool SC. (More on how to do that here) I did not know about that tool until then. Turns out, all it does is register the application specified, cmd.exe in this case, as a service. I decided to test it for use in installing a custom service created in C#. I created a quick service that answered a single incoming TCP connection with “Hello World”. Installed it with SC, and it worked! I did not have to create an install class within the service, nor did it rely on InstallUtil.exe. For more information on SC for installing services, check out the “SC Create” TechNet article
I wanted to sign a PowerShell script to make it easier and more secure to use in our environment. PowerShell signing was not in great use in the environment. To make signing the scripts easier I created a simple script to help with the signing process. There was an issue however. We have generic, fully trusted, all purposes certificates. Despite being fully trusted and all purpose, they did not show up as valid certificates in PowerShell. I tried manually running:
Get-ChildItem cert:\CurrentUser\My -codesigning
It returned nothing. The certificates should work, but they weren’t showing up. I checked the certificate inside of the Certificate Store. Inside the certificate’s properties on the “General” tab, there is a “Certificate purposes” group box. Inside of this “Enable all purposes for this certificate” was selected.
Since that was not working, I selected “Enable only for the following purposes”.
By default, all purposes were already checked. I clicked “Ok” and ran the Get-ChildItem command again and the certificate was finally listed. I ran through the signing process successfully. The signature on the PowerShell file was trusted and valid.