Malware using AppCompat for automatic UAC elevation, continued

By | February 12, 2015

As noted last time, a blog from last month already documented how the dropper for the Dridex banking trojan uses the UAC auto-elevation feature introduced with Windows 7 along with an Application Compatibility (AppCompat) “shim” to invisibly elevate to full admin on the local machine:
http://www.confer.net/kill-chain-the-confer-blog/80-firewall-rule-changes-and-compatibility-trickery

Dridex is currently being delivered via a separate “wave” of workday/weekday spam emails that attach Office files with VB macros. (Those macros then go off and download the Dridex dropper/installer.) The Dynamoo blog analyzes a lot of these; for example, here’s one from today:
http://blog.dynamoo.com/2015/02/malware-spam-minuteman-press-west-loop.html

The Dridex dropper uses the same auto-elevate bypass technique as Upatre with a different implementation. The main difference between the two is that the Dridex dropper is a little more sophiscated: it builds the AppCompat SDB file dynamically (Upatre uses a static, pre-built one) and it handles errors by retrying (Upatre only tries once).

This is more easily seen by changing the UAC setting to the maximum/highest “Always notify”, forcing the UAC prompts on-screen. In this setting, when the malware launches both the sdbinst.exe and iscsicli.exe files, one sees the UAC prompts in Figure 1 and Figure 2.

Figure 1

Figure 2

If one clicks on the “No” button, then the sequence fails and Upatre quits; however, Dridex starts over again. One would then typically see an endless number of prompts by clicking “No” over and over.

With this technique for installing malware now in the mainstream, what are few of the mitigation options are there and how effective are they? (As usual, it’s complicated.)

1. “Disable” auto-elevation by changing the UAC setting to the maximum “Always notify”

This gives users a chance to stop the malware by declining the UAC prompt…which isn’t typically realistic. UAC prompts mostly annoy users, which is largely why Microsoft added auto-elevate to Windows 7 in the first place.

As noted above, while this defeats Upatre’s current approach, the Dridex dropper will prompt again and again (and again). The malware is usually going to win this battle of will, especially with a large(r) scale of users; however, even with Upatre using a “one-shot” approach, it is effective enough that they haven’t had to change it for months (if at all). If necessary, it’s a very good bet they will.

2. “Disable” auto-elevation for the Application Compatibility program, sdbinst.exe

Ironically (or maybe just coincidentally) this uses another AppCompat setting, RunAsInvoker. There are different ways to try this, but they are inconsistent across versions or unprotected.

On Windows 7 one can set an environment variable, or a per-machine Registry value, but those don’t work on Windows 8.1.

On Windows 8.1 one can set the per-user Registry value variation something like this:

reg.exe add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /f /v "c:\windows\system32\sdbinst.exe" /t REG_SZ /d "RunAsInvoker"

BUT: just about any application can overwrite it or delete it (malware obviously included).

Or one can create an AppCompat shim (I think this qualifies as ironic) for sdbinst.exe to force RunAsInvoker; this option has a crossing the streams feel to it, but that’s what sacrificial VMs are for. It does seem to break this attack on test Windows 7 and Windows 8.1 installs.

Unfortunately, I would guess that Microsoft whitelisted sdbinst.exe because it broke a lot of scripts when Vista came out. So this also has a Catch-22 feel to it, even if it is effective in a proverbial vacuum.

3. Windows 10

OK, not yet. As of Build 9926 of the Technical Preview, it does “break” this attack — more ground covered by the KernelMode thread referenced last time:
http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3643&start=10#p24724

It would be a very expensive option just to deal with this one issue, though, and the law of unintended consequences may be invoked.

148. Don’t run as admin

Ideally yes, but easier said than done. And this doesn’t protect the user, necessarily — just Windows. The benefit is keeping the infection isolated, which should help minimize cleanup, and hopefully your antivirus signatures trigger within a few hours. It should also give you more time to catch this before it transforms from a PC infection to an APT.

Of course, this is an ongoing “pick your poison” debate — if your users demand, require, and/or are allowed full admin rights, then this is just another one of those things in the huge pile of ways that the bad guys will exploit that vulnerability.