Spectre/Meltdown Vulnerability Registry Keys

Microsoft has released guidance for patching endpoints against the CPU (mainly Intel) set of vulnerabilities known as Spectre, Meltdown, F’WIT, Kaiser, KPTI, among other names.

Microsoft Guidance CERT Information Bleeping Computer page

Endpoint patching is not likely to be the extent of the mitigation required, there may be firmware patches, server patching, application patching, hypervisor (Azure, AWS, Hyper-V, VMWare, among others.) patching, etc., depending on your environment.

These Microsoft patch(es) will not be applied to an endpoint unless the following registry key exists, which should be set by Anti-Virus vendors to confirm compatibility with the mitigation presented by the patch(es), or set manually by an administrator after confirming compatibility with your Antivirus vendor.

DO NOT SET THIS KEY MANUALLY WITHOUT CHECKING WITH YOUR AV VENDOR IF THEY ARE COMPATIBLE OR YOU MAY BREAK STUFF.

HKLM\Software\Microsoft\Windows\CurrentVersion\QualityCompat

Dword value of: cadca5fe-87d3-4b96-b7fb-a231484277cc

Rename to .reg to be able to double-click or deploy to set this registry key. No warranties implied or expressed.

Kevin Beaumont @Gossithedog is graciously maintaining this spreadsheet of AV vendors’ compatibility with these Microsoft patches.

I will show how I am monitoring endpoints for the creation of this key using an SCCM Configuration Item and Configuration Baseline.

  • Open the SCCM Console, navigate to Assets and Compliance>Overview>Compliance Settings, right-click Configuration Items and select “Create Configuration Item”.
  • Give this configuration item a name, a description, select appropriate device types, click Next.
  • Select the appropriate versions of Windows for your environment, then click Next again.
  • On the settings screen, click New to bring up the Create Setting window.
  • Give the setting a name, and a description. The setting type can remain as “Registry value”, the Data type can be set to “String”. Click browse to find the registry key above on your own workstation, or enter it in manually. The compliance rule should be set as “Must exist” by default. Change the severity and remediation as you deem fit for your environment. Click OK once satisfied with these settings.
  • Click Next at the settings window.
  • Click Next again at the Compliance Rules window.
  • Review the settings in the summary window, and click Next once satisfied with these settings.
  • Hopefully, this succeeds and you see the window detailing what was done. Click close.

We now have a Configuration Item, which is useless until we create a Configuration Baseline and deploy it. To do this:

  • Right-click Configuration Baselines, Create Configuration Baseline.
  • Give this baseline a name and a description.
  • Click the “Add” button in the Configuration Data section, and select the Configuration Item we created in the last section. Select/create a category if you desire, then click OK.
  • To deploy this Configuration Baseline, right-click on it and select Deploy.
  • I chose to not remediate noncompliant assets. (Untested, use at your own peril.)
  • I did not set alerting.
  • I chose to deploy this Configuration Baseline to my own device for testing purposes. (Since this is a registry key, deploy to device collections.)
  • Set a schedule of your choosing that best suits your environment.
  • Click OK.

Monitor in the Configuration Baseline window.

Now we have a deployed Configuration Item and Configuration Baseline. SCCM is not a “right-now” piece of management software, but to speed up the deployment and evaluation of this baseline, you can right-click on the Configuration Baseline and select “Run Summarization”. If you’re super impatient, this can be run manually on the endpoint by going to Control Panel, Configuration Manager, Actions Tab, and executing the various actions by left-clicking them, and selecting Run Now. These can also be run remotely from the command line if you’re super-duper impatient.

Using Powershell and SCCM to audit local administrators.

In the past, I have used Powershell and SCCM to determine if assets have local administrators that deviate from what is set via Group Policy.
This requires the creation of a Configuration Item and a Configuration Baseline, and a deployment but the below Powershell script can be adapted for other uses.

A value of ‘True’ will be returned if the local administrators of the machine on which the script is run match the values supplied for $users (supply your own environment appropriate values, below are merely examples).

Script is here, rename to PS1 to edit or execute, no warranties expressed or implied.

$useraffinity = gwmi -Namespace root\ccm\policy\machine -Class ccm_useraffinity
$users = “administrator”,”DOMAIN\Domain Admins”,”DOMAIN\Workstation Admins”
foreach ($useraff in $useraffinity)
{ $users += $useraff.ConsoleUser }

$members = net localgroup administrators | where {$_ -AND $_ -notmatch “command completed successfully”} | select -skip 4
New-Object PSObject -Property @{
Computername = $env:COMPUTERNAME
Group = “Administrators”
Members=$members
} | out-null

$adminusers = $true
foreach ($useradm in $users)
{
if (!($members -contains $useradm))
{
$adminusers = $false
break;
}
}

foreach ($useradm in $members)
{
if (!($users -contains $useradm))
{
$adminusers = $false
break;
}
}
write-host $adminusers

Scripting Powershell for Exchange E-Discovery

Note: this is not legal advice, and no warranty is implied or expressed. Your legal department should provide specific guidance as to search terms and derivatives/variations, mailboxes/persons in question, start dates, end dates, etc.

In the past, I was tasked with performing E-Discovery in Microsoft Exchange for many search terms in many mailboxes. I decided Powershell would be the right tool for this job. However, I encountered errors with performing the searches for as many terms as I was looking for. Searches of a multiple gigabyte mailboxes would end in seconds and produce no results, for terms I knew were present. Instead of fighting with the errors and limitations of the cmdlet, I decided to make a script with a foreach loop.

Firstly, if required or deemed appropriate by management or legal, place a retention/legal hold on the mailboxes in question, which seeks to prevent Outlook and Exchange purge and cleanup processes from potentially damaging or destroying items. The basic usage would be:

Set-Mailbox -Identity ‘mailboxalias’ -RetentionHoldEnabled $true

(https://blogs.technet.microsoft.com/ediscovery/2008/07/14/hold-me-now-how-to-quickly-put-a-retention-hold-on-1400-employees-using-microsoft-exchange-2007/)

This script expects a file named terms.txt in the same directory as it is run, with a list of terms on their own line, single quoted, with punctuation marks escaped with a backtick. For example:

‘Acme Corporation, LLC.’

‘Contoso’

This script will prompt the script runner for input such as:

mailbox name – this is the mailbox alias (hint: get-mailbox)

start date – the date from which to start looking for matching terms, this is in MM/DD/YYYY format.

end date – see above

export mailbox – the mailbox to which you would like to export the items, I generally chose my own or a dedicated mailbox for this purpose. This is in address@domain.tld format.

Bad Item Limit – There is nothing worse than a scripted search aborting after 12 hours because a few corrupted items were encountered. I recommend setting this to 100.

Matched items will be placed in a subfolder named after the date and the mailbox alias of the account being searched, and items including the terms will all be merged in this folder.

This script was tested on a computer with the Exchange Admin Console installed, with an account that was an Exchange Organization Administrator, with local administrator rights on all Exchange servers, and with full permissions to the mailboxes in question.

It’s not perfect, and there is plenty of room for improvement, but it did the job.

20170224-Export-TermsList-Prompts