Follow-up on Microsoft Advisory ADV170012

If you are lucky and have System Center Configuration Manager, aka ConfigMgr, in you environment, you can get the inventory of the TPM embedded in you workstations or laptops.

You need to enable the Win32_TPM WMI class in the Hardware Inventory settings of your clients.

If you’ve only laptops, you can filter the query with the chassis types.
Then the problem is that the Manufacturer Id is returned as int32 and it doesn’t tell you what’s the manufacturer name and when the TPM manufacturer actually is Infineon whether its vulnerable or not.

Luckily, there’s a way to get the Manufacturer name from the int32 that is described on the the Win32_TPM WMI class on msdn.

Using the example provided, we can do

('{0:X0}' -f 1414548736) -split "(?<=\G.{2})",4 | 
ForEach-Object { 

If I combine the ConfigMgr query, test if the TPM is vulnerable and get its manufacturer name from its id, I’ve the following code:

And if you use the 2nd example provided in the help, you can quickly have relevant results (IFX is Infineon)

If you cannot get results and have a WMI quota violation instead, see this post

Happy TPM madness scoping using #ConfigMgr and #PowerShell 😎

About Microsoft Advisory ADV170012

After this year Intel AMT fiasco, we’ve got not a new TPM madness. I ❤ IT

If you don’t know what it’s about, please take the time to read first the Microsoft Advisory ADV170012

Now, let’s quickly jump into the only question we care about: How do I find out whether I’m affected or not?

The PowerShell script provided on this page is supposed to help IT achieve this task.

Unfortunately, it doesn’t scale very well and Microsoft doesn’t give you too much details and just tells us to use PSRemoting to scale and query multiple computers.

The script has other major issues like:

  • it doesn’t send an object through the pipeline and just uses Write-Host to paint/color my console
  • it doesn’t handle gracefully the fact that you must be running the script with elevated user rights (Run as Administrator).
    (please note that there’s a warning about administrative privileges in bold in the forewords)
  • it uses aliases which is not a best practice
  • it doesn’t respect the Verb-Noun format for function names
  • worse, it uses Get-TPM that is cmdlet that was introduced as of Windows 8 and that isn’t available on Windows 7

Don’t get me wrong, the script is good enough for my home computer and the code exposes very well the core logic to determine if my device is affected.
I especially love the way the return statement is used in the switch block.
Anyway, I rewrote the script to ease the scoping of this TPM madness 😀

Let’s see how to use it:

# Example 1:
$c = Get-Credential
$targets = @(
Invoke-Command -ComputerName $targets -ScriptBlock ${Function:\Test-InfineonTPMVulnerability} -ErrorAction SilentlyContinue -Credential $c |
Select -Property ComputerName,TPMVersion,Vulnerable,Unknown,ClearRequired,Reason |
Format-Table -AutoSize

# Example 2:
Invoke-Command -ComputerName $targets -ScriptBlock ${Function:\Test-InfineonTPMVulnerability} -ErrorAction SilentlyContinue -AsJob -Credential $c |
Wait-Job -Any | Receive-Job | Out-GridView

Bonus 1:
In Windows 7, you cannot use the new Suspend-Bitlocker cmdlet introduced as of Windows 8.
You can use manage-bde.exe

Manage-bde.exe –protectors –disable c:

or you can use WMI

$HT = @{
 Namespace = 'root/cimv2/Security/MicrosoftVolumeEncryption'
 Class = 'Win32_EncryptableVolume'
(Get-WmiObject @HT -Filter 'DriveLetter="C:"').DisableKeyProtectors()

Bonus 2: On Windows 10, if you want to use the detection option 1 and query events from the Event Source TPM-WMI, the fastest way to achieve this is by using an XML query that only targets the microsoft-windows-tpm-wmi provider like this:

$xml = @'
<QueryList><Query Id="0" Path="system"><Select Path="system">*[System/Provider[@Name='microsoft-windows-tpm-wmi']]</Select></Query></QueryList>
Get-Winevent -FilterXml $xml -ErrorAction SilentlyContinue

Happy TPM madness scoping 😎

Service Control Manager ACL module

When I saw this trick from John Lambert being retweeted after the Petya malware campaign (remember, the one after the Wannacry campaign that exploited SMBv1 protocol and vulnerability called EternalBlue), it was clear it can be used to stop other ways used by Petya to propagate over the wire. Of course, you could block wmic.exe and psexec.exe if you’ve Applocker and an Enterprise version of Windows. But the above trick blocks the remote use of psexec and is a hardening measure with a broader scope. I thought, it would be nice to have a PowerShell module that would help playing with this defensive configuration of the Service Controller Manager.

I wanted to use the same approach I used for the NetCease module, where I’d just set the hardened configuration in the registry.
It appeared to be a bad idea because the registry value doesn’t exist by default

It’s also a very bad idea because you can have a different configuration based on the roles and features installed on your computer.

This is what you’d typically find on a Windows 7 computer

And this is what you’d find on Windows 2012 R2 with Hyper-V

These limits explain how and why the Set-SCManagerPermission function in the Service Control Manager ACL module (SCManager) adds a Deny to the network service (NT AUTHORITY\NETWORK, S-1-5-2).

I’ve also chosen to rely on sc.exe and the functions are most of the time of wrapper around sc.exe mainly because sc.exe is required when the registry key and value don’t exist and using sc.exe apply changes immediately without a reboot.

You can find the SCManager module in this Github repository

I’ve also published a digitally signed version on the PowerShell Gallery.

Set-SCManagerPermission -Verbose -Confirm:$false
Get-SCManagerPermission |
Select Transl*,Secu*,AccessMask,AceType | 
ft -AutoSize

If sc.exe is used to access any service remotely, it will end with an Access Denied error.

This module and the hardened configuration it sets will for sure block the remote use of psexec.exe or sc.exe.

But, it could also break some Microsoft or third party products or services.

It has the capability to undo the change made using the Restore-SCManagerPermission function without a reboot.

Restore-SCManagerPermission -Verbose -Confirm:$false

Please use it first in a testing environment and report any broken service/product you may encounter.