Bitlocker Analysis not reporting on some computers

I am new to bigfix and I am working on a custom analysis that scans machines in our environment looking for drives that were bitlocker enabled and reporting back the following:

Encrypt-able Volumes - Tells what drive is encrypted
Protection Status - Tells whether encryption is off or on
Encryption Method - Tells the encryption type Example: AES 256
Encryption status- Tells whether the drive is fully encrypted or not

The issue is that some computers are reporting everything BUT the encryption method. We have a standard image on our machines, Win 10 64 bit. I have compared the registry entries, on two different machines, that are scanned during the analysis. From what I can see they are exactly the same but one reports the encryption method and the other does not.

Analysis details:

tuple string items (integer values of selects ("* from win32_EncryptableVolume") whose(name of it = “EncryptionMethod”) of WMIs “root\CIMv2\Security\MicrosoftVolumeEncryption”) of “N/A, AES 128 With Diffuser, AES 256 With Diffuser, AES 128, AES 256”

Any advice would be much appreciated.

I’d start by pulling the raw integer values and see whether it returns anything at all…

integer values of selects ("* from win32_EncryptableVolume") whose(name of it = “EncryptionMethod”) of WMIs “root\CIMv2\Security\MicrosoftVolumeEncryption”

2 Likes

Just create a new analysis with only this string in the details correct? (sorry, new to the BF environment)

I would use the Fixlet Debugger, or the qna tool in the BES Client folder, or the Query app in WebUI to run the query on some of those machines that aren’t giving a result. You vould do the same in an Analysis, but this is just a diagnostic to see what, if anything, WMI is returning on those clients.

The original relevance takes an integer result from WMI, and maps return values 0 through 4 to a specific string; there is a big difference between the WMI query returning nothing at all (we can’t do much with that), or WMI returning something like 5 or 6, which is just a value the relevance doesn’t recognize but should be easy to add.

In fact, a reference at https://docs.microsoft.com/en-us/windows/win32/secprov/getencryptionmethod-win32-encryptablevolume indicates there are at least seven defined encryption methods, not just the five listed in the relevance query…

Once I ran the integer check I found that some were reporting an unexpected integer . So after a bit of googling I found information on those integers and added the relevant encryption method. So far many devices that were previously reporting as the encryption method are now reporting their encryption method. Thank you for pointing me the right direction! Once I knew the right question to ask I got everything squared away.

Thanks again!

1 Like

Interesting detail though. I had devices reporting an integer of 6 but were reporting XTS_AES_256 which has a value of 7 according to what I found.

When I changed the string to this:
tuple string items (integer values of selects ("* from win32_EncryptableVolume") whose(name of it = “EncryptionMethod”) of WMIs “root\CIMv2\Security\MicrosoftVolumeEncryption”) of “N/A, AES 128 With Diffuser, AES 256 With Diffuser, AES 128, AES 256, XTS-AES 256-bit, XTS-AES 128-bit”

They then reported the correct encryption method.

1 Like

Thanks for the update, and happy sleuthing!

Thanks again for your help my friend!