Skip to content

Blog

Block Mounting of ISO Images with Microsoft Intune (Endpoint Manager)

Today’s malware-loader-du-jour, Bumblebee, has been seen achieving initial access through phishing sites that convince a user to mount a downloaded ISO image. This may be a reaction to Microsoft’s recent improvements to macro-enabled document security.

Adversaries push ISO files through compromised email (reply) chains, known as thread hijacked emails, to deploy the Bumblebee loader. ISO files contain a byte-to-byte copy of low-level data stored on a disk. The malicious ISO files are delivered through Google Cloud links or password protected zip folders. The ISO files contain a hidden DLL with random names and an LNK file. DLL (Dynamic Link Library) is a library that contains codes and data which can be used by more than one program at a time. LNK is a filename extension in Microsoft Windows for shortcuts to local files.

https://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/

One of the things that we can do to help our users avoid this new initial execution foothold is by blocking the mounting of ISO images, as long as you can be confident this will not break anything they actually need to do! I am fortunate enough to be able to do this.

(Djordje Atlialp shows us how to achieve this with classic GPOs, and also a more comprehensive neutering of ISO files.)

Here is what I have rolled out as an Intune PowerShell Script to block the mounting of ISOs. No reboot is required. Users will see the Mount option disappear from the context menu of an ISO file within File Explorer and will be unable to double-click to mount a malicious ISO. Or, indeed, any ISO. 😉

We will head to Microsoft Endpoint Manager admin center, go to Devices > Scripts and create a new Windows 10 and later PowerShell script.

Restrict mounting of ISOs in File Explorer

The Intune Script

UPDATE: I have made some improvements — namely, the previous one liner will cause failures to be reported in Intune on subsequent runs. We will now only add the value where it does not exist, and we will add support for Windows.VhdFile as well. It’s no longer a one-liner!

$items = @(
    @{
        path = "HKLM:\SOFTWARE\Classes\Windows.IsoFile\shell\mount"
        valueName = "ProgrammaticAccessOnly"   
    }
    @{
        path = "HKLM:\SOFTWARE\Classes\Windows.VhdFile\shell\mount"
        valueName = "ProgrammaticAccessOnly"
    }
)

foreach($item in $items) {
    if ($null -eq (Get-Item -Path $item.path).GetValue($item.valueName)) {
        New-ItemProperty -Path $item.path -Name $item.valueName -Value ""
    }
}

The body of the script can be as follows:

New-ItemProperty -Path "HKLM:\SOFTWARE\Classes\Windows.IsoFile\shell\mount" -Name ProgrammaticAccessOnly -Value ""

(This REG_SZ value need only exist, with a blank string as its Data, for this to work.)

Assign it to the device group and you are all set.

Removal

To undo this change, we can reverse what we’re doing and Remove-ItemProperty on the items we added:

$items = @(
    @{
        path = "HKLM:\SOFTWARE\Classes\Windows.IsoFile\shell\mount"
        valueName = "ProgrammaticAccessOnly"   
    }
    @{
        path = "HKLM:\SOFTWARE\Classes\Windows.VhdFile\shell\mount"
        valueName = "ProgrammaticAccessOnly"
    }
)

foreach($item in $items) {
    if ($null -ne (Get-Item -Path $item.path).GetValue($item.valueName)) {
        Remove-ItemProperty -Path $item.path -Name $item.valueName
    }
}

Conclusion

This doesn’t make you bulletproof, but will, if tolerated by your users, provide a substantial degree of protection, at the time of writing, from any number of current malware loaders that are using the ISO image technique to achieve initial code execution. The nature of the separate filesystem within the ISO presently prevents it from being marked as being from the Wild Wild West World Wide Web.

The Windows 10 Experience

New Windows logo

I haven’t said much about Windows 10 here on this blog, but my day job brings me into contact with it quite extensively.

There is a huge amount about the Windows experience that this release improves, but also there are elements of Microsoft’s new approach to developing and releasing it that are problematic.

The Good

Installing Windows 10 across a variety of devices, it is striking just how much less effort is required to source and install drivers. In fact, in most cases no effort is required at all! Aside from the occasional minor frustration of bloated drivers that are desperate to add startup applications, this makes such a positive difference. Unlike in the past, you can typically just install Windows, connect to a network, and everything will work.

This is particularly notable in any environment where you have a large number of devices with anything more than a little bit of hardware diversity. Previously in an enterprise environment, hunting for drivers, extracting the actual driver files, removing unwanted ‘helper application’ bits and building clean driver packages for deployment was tedious and wasteful of time. Now, much of the time, you let Windows Update take care of the drivers for you over the network, all running in parallel to the actual provisioning process that you have configured!

There are numerous other pockets of the operating system where there really feels like there has been a commitment to improve the user experience, but from my “world of work” experience of the OS, this is the most significant. It’s true as well that many of the criticisms you could make about past versions of Windows no longer apply.

The Bad

I guess that the coalescing of monthly Windows Updates into a single cumulative update helps significantly with the ‘236 updates’ problem with (and atrocious performance of) Windows Update in 7. However, Microsoft’s recent history of updates causing issues (the recent issues with KB3163622 and Group Policy, for example) combined with the inability to apply updates piecemeal leaves some IT departments reluctant to apply the monthly patch. The result, if Microsoft continues to experience these kind of issues, or doesn’t communicate clearly about backwards-incompatible changes, is more insecure systems, which hurts everybody.

This leads me to my other main complaint. There have been reports about the new approach Microsoft is taking with software testing. An army of ‘Insiders’ seem to be providing the bulk of the telemetry and feedback now, but my concern is that this testing feedback doesn’t necessarily end up being representative of the all of the very diverse groups of Windows users. Particularly when deploying Windows 10 in an Enterprise environment, it has felt at times like we are the beta testers! When one update is a problem, you then have to put people at risk by rejecting them all. 🙁

(Yes, there is LTSB, but it hangs back a very long way on features!)

The Ugly

Windows 10 'Hero' image

At least you can turn it off on the login screen officially now. 🙂

Reverse Proxying ADFS with Nginx

In my recent trials and tribulations with ADFS 3.0, I came up against an issue where we were unable to host ADFS 3.0 with Nginx as one of the layers of reverse proxy (the closest layer to ADFS).

When a direct connection, or a cURL request, was made to the ADFS 3.0 endpoints from the machine running Nginx, all seemed well, but as soon as you actually tried to ferry requests through a proxy_pass statement, users were greeted with HTTP 502 or 503 errors.

The machine running ADFS was offering up no other web services — there was no IIS instance running, or anything like that. It had been configured correctly with a valid TLS certificate for the domain that was trusted by the certificate store on the Nginx machine.

It turns out that despite being the only HTTPS service offered on that machine through HTTP.sys, you need to explicitly configure which certificate to present by default. Apparently, requests that come via Nginx proxy_pass are missing something (the SNI negotiation?) that allows HTTP.sys to choose the correct certificate to present.

So, if and only if you are sure that ADFS is the only HTTPS service you are serving up on the inner machine, you can force the correct certificate to be presented by default, which resolves this issue and allows the Nginx reverse proxied requests to get through.

With that warning given, let’s jump in to what we need to do:

Retrieve the correct certificate hash and Application ID

netsh http show sslcert

You’ll need to note the appid and the certificate hash for your ADFS 3.0 service.

Set the certificate as the default for HTTP.sys

We’ll use netsh‘s interactive mode, as I wasn’t in the mood to figure out how to escape curly brackets on Windows’ command line!

You want the curly brackets literally around the appid, but not the certhash.

netsh
netsh> http
netsh http> add sslcert ipport=0.0.0.0:443 appid={appid-from-earlier} certhash=certhash-from-earlier

Verify the proxy_pass settings

Among other configuration parameters, we have the following in our Nginx server stanza for this service:

proxy_redirect off;
proxy_http_version 1.1;
proxy_request_buffering off;
proxy_set_header X-MS-Proxy the-nginx-machine;
proxy_set_header Host the-hostname-in-question

And, with that, we were successfully reverse proxying ADFS 3.0 with Nginx. 🙂

Restoring a Windows 8 Bootloader

Screenshot of the Hyper-V Manager on Windows 8

Microsoft’s Hyper-V is a really cool virtualisation technology I have been having fun exploring. You cannot run a Hyper-V Server on a Windows 7 host, however, so in order to run it, I installed Windows 7 and Windows Server 2008 R2 side-by-side, and used it in the latter.

All that has changed in the era of Windows 8, however, and you can run a Hyper-V Server on the client version of Windows 8, if it is Windows 8 Pro. Hooray!

So, to cut a long story short, post-upgrade, I felt I didn’t really need my separate Windows Server 2008 R2 partition for Hyper-V, so I deleted it and expanded the Windows 8 partition to fill the space. Only to find that Windows now wouldn’t boot. Oops.

I originally installed Windows 7 first, followed by Windows Server 2008 R2, following best practice to install newer operating systems after earlier ones. What had happened now, though, was that I had just wiped out the bootloader that was sitting happily on the Windows Server 2008 R2 partition.

» Read the rest of this post…