Deploy Sysmon with PowerShell Desired State Configuration

The technet page of sysmon 2.0 provided the following advanced configuration sample:

@'
<Sysmon schemaversion="1.0">
    <Configuration>
        <!-- Capture all hashes -->
        <Hashing>*</Hashing>
        <!-- Enable network logging -->
        <Network />
    </Configuration>
    <Rules>
        <!-- Log all drivers except if the signature -->
        <!-- contains Microsoft or Windows -->
        <DriverLoad default="include">
        <Signature condition="contains">microsoft</Signature>
        <Signature condition="contains">windows</Signature>
        </DriverLoad>
        <!-- Do not log process termination -->
        <ProcessTerminate />
        <!-- Log network connection if the destination port equal 443 -->
        <NetworkConnect>
        <DestinationPort>443</DestinationPort>
        </NetworkConnect>
    </Rules>
</Sysmon>
'@


If you want to do more advanced stuff, my fellow Windows PowerSell MVP Carlos Perez wrote an awesome module named Posh-Sysmon that would help you create XML configuration for Sysmon.

April 20, 2015, Sysmon 3.0 was published 🙂
It delivers a version 2.0 of the XML schema which looks like this:

@'
<Sysmon schemaversion="2.0">
 <!-- Capture all hashes -->
 <HashAlgorithms>*</HashAlgorithms>
 <EventFiltering>
  <!-- Log all drivers except if the signature -->
  <!-- contains Microsoft or Windows -->
  <DriverLoad onmatch="include">
   <Signature condition="contains">microsoft</Signature>
   <Signature condition="contains">windows</Signature>
  </DriverLoad>
  <!-- Do not log process termination -->
  <ProcessTerminate onmatch="include"/>
  <!-- Log network connection if the destination port equal 443 -->
  <NetworkConnect onmatch="include">
   <DestinationPort>443</DestinationPort>
  </NetworkConnect>
 </EventFiltering>
</Sysmon>
'@

sysmon.v3.sample.config

In March 2015, I’ve asked the following question to Thomas Garnier who co-authored this awesome sysmon tool with Mark Russinovich.

Unfortunately, there’s no way currently in version 2.0 or 3.0 to dump the configuration directly to XML 😐
But, that’s not a huge problem for PowerShell 😉
The only trick that made the reverse engineering experience consistent was to read the dumped rules from the bottom up 😎

Let’s see a capture of the DSC configuration that deploys sysmon when it runs for the first time:
deploy-sysmon.1
If I run the same configuration a 2nd time, all the TEST phases performed are skipped (which is a good thing):
deploy-sysmon.2

Quick and dirty!
But Sysmon got deployed and configured through Desired State Configuration on a Windows Server 2012 R2 and its built-in PowerShell version 4.0

PS: If you check the different revisions of the gist file, you can get a DSC configuration that works against sysmon version 2.0 😀

Advertisements

Deploy and configure EMET 5.2 with PSDSC

I’ve been using EMET (The Enhanced Mitigation Experience Toolkit) and advocating for it since 2010…

Now with DSC (Desired State Configuration) and PowerShell, it can be fairly easy to deploy and configure it compared to my previous post about Applocker.

I’ve created two scripts, one to install EMET and one to remove it (because of continuous delivery of every product, right?) that can be run as of Windows 8.1 and Windows 2012 R2. Yes, DSC is built-in PowerShell version 4.0 that was released along with Windows 8.1 in August 2013.

The configuration of EMET 5.2 is based on XML files although EMET 5.2 can also get its configuration by GPO in a domain environment.
The XML configuration that you’ll find below is an export made with the EMET_Conf.exe after an import from the “Recommended Software.xml” profile provided under “C:\Program Files (x86)\EMET 5.2\Deployment\Protection Profiles\”.
Although I probably could, I chose to not handle Certificate Pinning rules because a new GUID for each rule is generated by the XML export made with EMET_conf.exe. If I did, it would have complicated the comparison made by the Test-TargetResource and probably slow it down.
I know that the built-in package DSC resource can download the file from the web if I specify a URL as a package source but I preferred to rely on my own custom script to download the file as it performs some additional steps such as checking the integrity of the file (is it the hash we expect) and whether the file is digitally signed (and recognized as such for the time being).


The initial download takes around 9 seconds.
DSC-Install-EMET52.download
Let’s see what output we get when I first push the configuration:
DSC-Install-EMET52.run1.Package
DSC-Install-EMET52.run1.Config

If I push the configuration as 2nd time, all TEST steps for each resource return false because they are in their expected state and all the SET operations are skipped:
DSC-Install-EMET52.run2

Here’s what happens when I remove EMET 5.2 for the first time if it’s present:
DSC-remove-EMET-1
If I run the removal a 2nd time, I get:
DSC-remove-EMET-2

About MS15-034

This month there was CVE-2015-1635 on the menu for the Patch Tuesday. Microsoft released the security bulletin MS15-034 (KB3042553) to address the vulnerability in HTTP.sys.
On the main TechNet page for April 2015, there’s the risk assessment for this vulnerability:

Bulletin ID: Vulnerability Title: CVE ID: Exploitability Assessment for
Latest Software Release:
Exploitability Assessment for
Older Software Release:
Denial of Service
Exploitability Assessment:
Key Notes:
MS15-034 HTTP.sys Remote Code Execution Vulnerability CVE-2015-1635 1 - Exploitation More Likely 1 - Exploitation More Likely Permanent (None)

Microsoft has its own Exploitability index and 1 means:

This rating means our analysis has shown that exploit code could be created in such a way that an attacker could consistently exploit this vulnerability. Moreover, Microsoft is aware of past instances of this type of vulnerability being exploited. This would make it an attractive target for attackers, and therefore more likely that exploits could be created. As such, customers who have reviewed the security bulletin and determined its applicability within their environment could treat this with a higher priority.

One of the key task when doing patch management is to review what the editor officially says, assess the risk of your assets in your own environment and monitor both the good and the bad guys on the Internet to prioritize your deployment and assess how easy and how fast the vulnerability is exploited, weaponized…

There’s a formula to assess the risk on Wikipedia

R (the Risk) can be function of four factors:
A = Value of the assets
T = the likelihood of the threat
V = the nature of vulnerability i.e. the likelihood that can be exploited (proportional to the potential benefit for the attacker and inversely proportional to the cost of exploitation)
I = the likely impact, the extent of the harm

That said, let’s dive into CVE-2015-1635.

The MS15-034 only mentions IIS in the workaround section of the bulletin and quickly states that disabling IIS kernel caching is a workaround. That was a very short statement.

The bulletin makes it clear that this is not a vulnerability of IIS, it’s a vulnerability of HTTP.sys. Let’s see the link between IIS and HTTP.sys:

Source: http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture

It’s not the first time HTTP.sys is vulnerable. We had formerly MS13-039, MS10-040
There’s even an obsolete knowledge base article that listed the hotfixes available for HTTP.sys but it wasn’t reviewed since November 9, 2011!

There are other components that are built on top of HTTP.sys like the WSMan protocol, so I posted the following message on twitter yesterday.
There was a buzz or panic about it. My tweet may have been misinterpreted and many probably wondered whether PSRemoting and WSMan were impacted by this vulnerability.

My goal with this tweet was:
Let’s pay attention to MS15-034 this month.
It will for sure require all your attention.
IIS and other components depend on http.sys. That’s why I joined the above image, I’ve got from this page about troubleshooting WinRM.
I didn’t say that PSRemoting or WSMan are proven to be vulnerable to the specific CVE-2015-1635 vulnerability.
Based on my tweet, if you thought that PSRemoting is vulnerable because of CVE-2015-1635, you’re wrong.
Lee Holmes from the Microsoft Windows PowerShell Team clearly said later on that:

This means that the vulnerable portion of code in https.sys that got fixed is directly linked to services that use the kernel mode caching feature.
WinRM and WSMan don’t rely/depend on this portion of code.

I was right about paying attention to MS15-034.
It’s actually easy to trigger a denial of service (DoS) against IIS computers that have kernel mode caching enabled.
Things are moving fast. In less than 48 hours after MS15-034 was published, there are already active exploits in the wild.
See https://isc.sans.edu/forums/diary/MS15034+HTTPsys+IIS+DoS+And+Possible+Remote+Code+Execution+PATCH+NOW/19583/ for more information.

List all cultures by extending the native Get-Culture cmdlet

I recently needed to list all possible cultures available on a Windows box.
I’ve looked for a native cmdlet that you’d do it by typing:

Get-command *culture*


After using the Get-Member cmdlet on the output of the Get-Culture cmdlet, I found a .Net way of achieving this by doing:

[System.Globalization.CultureInfo]::GetCultures(
[System.Globalization.CultureTypes]::AllCultures
)

It’s nice and I thought that it would be great to have a -All switch on the native Get-Culture cmdlet.
Lee Holmes from the Windows PowerShell Team at Microsoft recently demonstrated a mind-blowing way of extending cmdlets with a few lines of code on his blog.

After playing with what Lee Holmes presented and how that would apply for extending the native Get-Culture cmdlet, I came up with this:

I’ve tested the above code on PowerShell version 2.0. Guess what! It works 😎

To get a sorted list of cultures that match the following pattern “en-US” for example, you can do (on PowerShell version 3.0):

Get-Culture -All | 
? Name -match "^[a-z]{2}-[A-Z]{2}$"  | 
Sort Parent

Configure Applocker with Desired State Configuration

I was working with Desired State Configuration and wondered why a custom DSC resources hasn’t been published yet for Applocker.
Bitlocker has already its experimental DSC resource. Why Applocker doesn’t have one?

I also wondered what it really takes to configure Applocker with PowerShell Desired State Configuration.

First a quick disclaimer is required:

  • Do not apply this on your servers/workstations if you don’t understand what Applocker does.
  • The deny rules are just examples. I don’t have anything against these software editors.
  • Yes, I know that’s not the most secure Applocker configuration as the example below mixes both a very permissive (default) whitelist and a very specific blacklist.

Let’s also quickly examine the Applocker requirements:

  • Applocker rules can be imported from/exported to a XML file using the GUI or using the cmdlets of the built-in Applocker module (it exists since PowerShell version 2.0 on Windows 7).
    XML seems to better way to go although the Applocker policy can be found in the registry under the HKLM\SOFTWARE\Policies\Microsoft\Windows\SrpV2 key.
  • The applocker policy depends on the ‘Application Identity’ service to be enforced.

Based on the above light requirements, it seems that built-in DSC resources would actually make it and allow to deploy an Applocker policy locally.

To configure Applocker, I need first to export the Applocker policy to XML and dump its indented representation to a file.
To solve the indentation issue, I’ve used the Format-XML function written by Jeffrey Snover that you can find on this page.

# http://blogs.msdn.com/b/powershell/archive/2008/01/18/format-xml.aspx
function Format-XML ([xml]$xml, $indent=2)
{
    $StringWriter = New-Object System.IO.StringWriter
    $XmlWriter = New-Object System.XMl.XmlTextWriter $StringWriter
    $xmlWriter.Formatting = "indented"
    $xmlWriter.Indentation = $Indent
    $xml.WriteContentTo($XmlWriter)
    $XmlWriter.Flush()
    $StringWriter.Flush()
    Write-Output $StringWriter.ToString()
}
Format-XML ([xml](Get-AppLockerPolicy -Effective -Xml)) -indent 2 | 
Out-File -FilePath ~/Documents\Applocker-pol.xml -Encoding ascii

The second step consists in creating the file locally with the XML content thanks to the built-in File DSC resource.
To decide whether to apply the policy, I’ll export the current effective Applocker policy and compare it to the XML file.
Once the Applocker policy is applied, I’ll start the required service.

Here is what the DSC configuration looks like to deploy locally an Applocker policy.

It only takes a service, a file, a script resource and less than 5 seconds to deploy an Applocker policy locally. 😎


If I apply it one more time, we can see that all the tests performed are skipped as my system is already in the desired state.


If I open the local group policy editor, we can see the following:

The above configuration was just for testing purposes, right 😉
Here’s how to achieve the exact opposite, i.e., clear the local Applocker policy and stop the required service.

Let’s remove the existing Applocker local policy for the 1rst time:

Again, applied one more time, we can see that all the tests performed are skipped as my system is already in the desired state.


Nice, isn’t it? DSC and PowerShell bring more than just automation! I love it 😀

Troubleshooting Windows Store and PC Settings not accessible

We offered a Surface RT to my mother for her birthday but after more than 18 months, she brought the tablet back to me because all her apps have disappeared and she couldn’t launch the Windows Store or PC settings.

I’ve created another account and I noticed that this account could launch the Windows Store and PC settings.
I’ve also queried the main Windows components store health state with the following DSIM cmdlet:

Repair-WindowsImage -Online -ScanHealth -Verbose


It was Ok. In other words, only her user profile had a problem.

I ran the Apps troubleshooter. It found 3 problems but was able to fix only 2 of them.

I’ve also checked the ACLs on various parts of the filesystem and registry using the following support article: KB2798317.
I added back manually the “All Application Packages” group (“tous les packages d’application” in French) full control NTFS permission onto the user profile.
The Windows store and PC settings still didn’t launch.

Then I reset the Windows Store cache.

& "c:\windows\system32\WSReset.exe"
Add-AppxPackage -DisableDevelopmentMode `
-Register C:\Windows\ImmersiveControlPanel\AppxManifest.xml

Now, I was able to launch the Windows Store but not the PC Settings.

And I had still events ID 5973 in the Application log

The latest command made me realize that all the other modern apps not working might only need to be registered.
So, I ended up doing:

dir C:\ -include AppxManifest.xml -ea 0 -rec -for | 
select -expand FullName | 
? { $_ -notmatch "C:\\Windows\\WinSxS\\" } |
% {
 $p=$_
 try {
  Add-AppxPackage -DisableDevelopmentMode -Register $_ -ErrorAction Stop
  Write-Verbose "Successfully registered $_"
 } catch {
  Write-Warning "Failed to registered $p because $($_.Exception.Message)"
 }
}

Boom! After 8 minutes about 50 modern apps where registered and appeared back in the Start menu.
I was able to launch the PC settings and Windows Store as well 😀
I added back the Microsoft Account in the Windows Store.
When I switched to the “my applications” view in the Store, it reported that “all the available applications are installed on this PC”.