Tuesday, November 22, 2016

On the Effectiveness of Device Guard User Mode Code Integrity

Is a security feature with known bypasses pointless?

I felt compelled to answer to this question after seeing several tweets recently claiming that Device Guard User Mode Code Integrity (UMCI) is a pointless security mechanism considering all of the recently reported bypasses. Before specifically diving into UMCI and its merits (or lack thereof), let’s use an analogy in the physical world to put things into perspective - a door.

Consider the door at the front of your home or business. This door helps serve as the primary mechanism to prevent intruders from breaking, entering, and stealing your assets. Let's say it's a solid wood door for the sake of the analogy. How might an attacker go about bypassing it?

  • They could pick the lock
  • They could compromise the latch with a shimming device
  • They could chop the door down with an ax
  • They could compromise the door and the hinges with a battering ram

Now, there are certainly better doors out there. You could purchase a blast door and have it be monitored with a 24/7 armed guard. Is that measure realistic? Maybe. It depends on the value of the assets you want to protect. Realistically, it's probably not worth your money since you suspect that a full frontal assault of enemy tanks is not a part of your threat model.

Does a determined attacker ultimately view the door as a means of preventing them from gaining access to your valuable assets? Of course not. Does the attacker even need to bypass the door? Probably not. They could also:

  • Go through the window
  • Break through a wall
  • Hide in the store during business hours and wait for everyone to leave
  • Submit their resume, get a job, develop trust, and slowly, surreptitiously steal your assets

So, will a door prevent breaches in all cases? Absolutely not. Will it prevent or deter an attacker lacking a certain amount of skill from breaking and entering? Sure. Other than preventing the elements from entering your store, does the locked door serve a purpose? Of course. It is a preventative mechanism suitable for the threat model that you choose to accept or mitigate against. The door is a baseline preventative mechanism employed in conjunction with a layered defense consisting of other preventative (reinforced, locked windows) and detective (motion sensors, video cameras, etc.) measures.

Now let's get back to the comfortable world of computers. Is a preventative security technology completely pointless if there are known bypasses? Specifically, let’s focus on Device Guard user mode code integrity (UMCI) as it’s received a fair amount of attention as of late. Considering all of the public bypasses posted, does it still serve a purpose? I won't answer that question using absolutes. Let me make a few proposals and let you, the reader decide. Consider the following:

1) A bypass that applies to Device Guard UMCI is extremely likely to apply to all application whitelisting solutions. I would argue that Device Guard UMCI goes above and beyond other offerings. For example, UMCI places PowerShell (one of the largest user-mode attack surfaces) into constrained language mode, preventing PowerShell from being used to execute arbitrary, unsigned code. Other whitelisting solutions don’t even consider the attack surface posed by PowerShell. Device Guard UMCI also applies code integrity rules to DLLs. There is no way around this. Other solutions allow for DLL whitelisting but not by default.

2) Device Guard UMCI, as with any whitelisting solution, is extremely effective against post-exploitation activities that are not aware of UMCI bypasses. The sheer amount of attacks that app-whitelisting prevents without any fancy machine learning is astonishing. I can say first hand that every piece of “APT” malware I reversed in a previous gig would almost always drop an unsigned binary to disk. Even in the cases where PowerShell was used, .NET methods were used heavily - something that constrained language mode would have outright prevented.

3) The majority of the "misplaced trust" binaries (e.g. MSBuild.exe, cdb.exe, dnx.exe, rcsi.exe, etc.) can be blocked with Device Guard code integrity policy updates. Will there be more bypass binaries? Of course. Again, these binaries will also likely circumvent all app-whitelisting solutions as well. Does it require an active effort to stay on top of all the bypasses as a defender? Yes. Deal with it.

Now, I along with awesome people like Casey Smith (@subtee) and Matt Nelson (@enigma0x3) have reported our share of UMCI bypasses to Microsoft for which there is no code integrity policy mitigation. We have been in the trenches and have seen first hand just how bad some of the bypasses are. We are desperately holding out hope that Microsoft will come through, issue CVEs, and apply fixes for all of the issues we’ve reported. If they do, that will set a precedent and serve as proof that they are taking UMCI seriously. If not, I will start to empathize a bit more with those who claim that Device Guard is pointless. After all, we’re starting to see more attackers “live off the land” and leverage built-in tools to host their malware. Vendors need to be taking that seriously.

Ultimately, Device Guard UMCI is just another security feature that a defender should consider from a cost/benefit analysis based on threats faced and the assets they need to defend. It will always be vulnerable to bypasses, but raises the baseline bar of security. Going back to the analogy above, a door can always be bypassed but you should be able to detect an attacker breaking in and laying their hands on your valuable assets. So obviously, you would want to use additional security solutions along with Device Guard - e.g. Windows Event Forwarding, an anti-malware solution, and to perform periodic compromise/hunt assessments.

What I’m about to say might be scandalous but I sincerely think that application whitelisting should the new norm. You probably won’t encounter any organizations that don’t employ an anti-malware solution despite the innumerable bypasses. These days, anti-malware solutions are assumed to be a security baseline as I think whitelisting should be despite the innumerable bypasses that will surface over time. Personally, I would ask any defender to seriously consider it and I would encourage all defenders to hold whitelisting solution vendors' feet to the fire and hold them accountable when there are bypasses for which there is no obvious mitigation.

I look forward to your comments here or in a lively debate on Twitter!


  1. Hey Matt,

    Thanks for all your work and putting it out there for us to benefit from. Much appreciated!

    We tested Device Guard and the overhead was just too much for our client to handle. In the end we suggested that Applocker with DLL enforcement enabled along with a few applications being blacklisted and/or monitored (powershell, regsvr32, etc.) was a more reasonable approach that their IT staff could stomach and would get them 80%+ of the protection with ~40% of the work (can't believe how many MS binaries are still not signed).

    Just curious if you thought that was a fair assessment.


    A fellow app whitelisting evangelist

    1. Thanks for your feedback, Josh! Would you be able to elaborate on what is was that made the customer feel as though Device Guard was too much of a burden? I have my ideas on why that was likely the case but I'd love to hear some "in the field" feedback.


  2. Hey Matt,

    I saw you post something on Twitter saying that it would take a lot "before we get to a world in which DG is commonplace" and realized I hadn't come back to reply to this, my apologies.

    So, before I reply: would you agree, disagree, or tweak my initial comment that "Applocker with DLL enforcement enabled along with a few applications being blacklisted and/or monitored (powershell, regsvr32, etc.) was a more reasonable approach that their IT staff could stomach and would get them 80%+ of the protection with ~40% of the work"?

    To your question, here are the reasons we didn't think DG was palatable for our customer (please keep in mind we tested this ~9 months ago):
    1. At the end of the day, if (when?) we actually got code to run with DG enabled (exploit, trusted process bypass, etc.) we could still do all the things we normally do in memory.
    2. There was (is?) a ton of overhead getting the policy setup. As I mentioned, a bunch of MS stuff wasn't even signed, and troubleshooting 3rd party apps to allow them to properly execute is a nightmare, via app whitelisting or DG.
    3. When we tested (and I have to think this was a bug), the policy was tattooed on that machine so that when you went to change the DG policy you couldn't do it unless you disabled secure boot which required putting a manual hand on each machine. Again, that has to be a bug I would believe, I can't imagine that being the way MS wants to handle it.

    Also, you mentioned "in the field" feedback:
    1. I know very, very few companies that actually even do app whitelisting (poorly or well). DG doesn't even enter my mind when talking to companies because I know the odds of them actually doing whitelisting is really, really low (sorry if that sounds cynical, just what I have seen).
    2. Honest question here: do you actually know of any real world networks running DG? I would be interested to hear what that looks like and how it works in prod. Heck, I am impressed when most companies aren't running as admin and have app whitelisting enabled, I would be (pleasantly) shocked to see DG in production.

    One last point, would love to hear your thoughts on this. I have spent some time thinking why security is so bad at so many places (no, I am not a thought leader ;): While there are some technically lacking solutions out there (looking at you AV), I don't think it is much a technology problem as a people problem. And not just the "why, yes I will run your macro" kind of problem. People have NO IDEA how we break into networks. CISOs, Directors of IT Security, security admins, programmers, etc., generally have no clue how a modern day attack works. And it's not because they are dumb, they just have never seen it. When we walk a customer through how we exploited their network and have all their information, that is the only time I see the light come on in their minds of "maybe we aren't as secure as we thought we were".

    At the end of the day I always come back to two truths that I hold to about security:
    1. Defense is the daughter of offense, or, put differently, you don't know what to defend against if you don't know how they are going to attack.
    2. Detection, detection, detection. If you give us enough time we will get past DG, whitelisting, etc. However, if you are doing a good job of detection you will raise the bar so high it makes it very, very hard to compromise and get any data off of your network (the real object of an true adversary).

    I have three motto's that have roots in system administration, offense and defense that I share with customers:
    1. Have you tried turning it off and on again?
    2. Don't trust the user.
    3. If you want users to do/not do something you can't ask them. Force them (see saying #2).

    Number 3 is hard and most people don't understand or see the need for it until it is way too late.

    Hope you had a Merry Christmas and have a Happy New Year!