B for Bitlocker

B for Bitlocker

This blog will be about the Bitlocker recovery key and some proactive remediation (and some background information about how it works)

Bitlocker is one of the many security measures you will need to implement to make sure the data is safe when a device is stolen.

One of the downsides are the support tickets that could be created when a user simply does not remember their password anymore and tried it too many times.

Luckily in a normal situation, you have made sure there is a backup of the recovery key in Azure. An admin could query the device to get the recovery key.

 But wait, what if there is no backup in Azure ad? How are you going to monitor this?

This week we had a customer who entered the wrong password too many times. The device ended up booting into the Bitlocker screen. So as the good admin’s we are, we opened the azure active directory to look up the recovery key but no single recovery key was available!!!

At that point, I was very glad we are also using Solarwinds to monitor the devices. One of the scripts we made sure was implemented, was to show the recovery key in Solarwinds. The end-user was very grateful to get the recovery key so he could get back to work. The problem is solved you might think but I was very curious why there wasn’t a backup recovery key available.

We started searching and the first place to look would be the Bitlocker event log.

As shown above, this is definitely the problem. Googling the error did not result in any useful hits.

You can also use PowerShell to query the event log:

Let’s try to reproduce the error and try to backup the recovery key again. We opened a PowerShell session and launched this script.

$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

And the backup of the recovery key was done?

That’s odd because when the device was enrolled the same script did not do its job.  To be sure, we checked all the other devices in the company but all the devices had their recovery key uploaded.

As stated before, for now, we are using Solarwinds. But what if you don’t have Solarwinds monitoring configured?

To make sure this thing would not happen again, we can create a proactive remediation script and schedule it to run each hour.

Detection script:

Try {
$Result = get-winevent -FilterHashTable @{LogName="Microsoft-Windows-BitLocker/BitLocker Management";StartTime=(get-date).Addseconds(-86400)}|Where-Object{($_.id -eq 846)} | ft message
$ID = $Result | measure-Object
If ($ID.Count -lt 5)
{
    Write-Output "Bitlocker backup to azure add succeeded"
    Exit 0
}
Else
{
    Write-Output $result
   Exit 1
}
}

catch

{
Write-Warning "Value Missing"
Exit 1
}

When looking at the detection script, you will notice the 86400 seconds.  When a device is enrolled and this error would occur, endpoint analytics will make sure it will try to resolve it.

Remediation script (very small)

$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

Let’s check if it’s working. Open pro active remediations and select all at the detection and remediation status to get a better overview and some more information when your remediations are failing.

As shown above, everything is fine and luckily the specific event log is not detected within the last 24 hours. With this remediation, you can be a little bit more sure the recovery key is uploaded.

This blog is not really about how Proactive remediations are launched, but why not?

When you have configured proactive remediations, the Powershell scripts are stored on the device itself.

They are handled by the Intune Management Extension (Sidecar agent) who invokes the Agent executor to trigger the execution of the PowerShell scripts. Let’s open the agentexecutor.log first to determine where the Powershell scripts are stored.  

It’s nice to see were the PowerShell scripts are stored (You will need admin rights to access this folders)

Conclusion:

Not monitoring your environment and just trusting everything would just work, is not that smart.

You need to monitor as much as possible! This is the way.

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  60  =  69