Bypassing Windows Information Protection, Lamely

Disclosure: I was unprepared to document anything and violated my own rules of documentation. Because I’m lame.

What is Windows Information Protection?

It protects against potential leakage by malicious and accidental insiders, controls which apps can access and use the data, and helps control where the data can go at rest (encrypted). And it works, until it doesn’t.

With just one weird tip, you can just get around it. Powershell.

But what does it look like normally? We start with creating the document using one of the apps defined as “Trusted.”

Snapshot of a couple of the apps allowed to use protected data
This is a protected document. That briefcase means it’s protected.

But what happens when you attempt to transfer the data to an app that is not allowed to access work content?

Oh snap. I guess I’ll give up and move on with my life.

I’ll try one more time. Maybe I can just open it normally with an unapproved app.

Foiled again…

Now let’s move jarringly from one set of screenshots to another, while pretending it all happened naturally.

Here’s the word document we were talking about earlier. If only I could exfiltrate this protected document. That briefcase on the image means it’s protected.

But I’m lame and don’t use application whitelisting so I run in Powershell in FullLanguage and can lazily dig into the document. Now, docx files are just fancy containers with xml data inside so you can change the extension to .zip and muck around with the files.

Let’s rename this treasure. See that briefcase? It’s still protected.
Let’s expand that archive and dance like fools.

Now you just enter the freshly created directory and look around. Note: I reset the computer I was working on and no longer had these documents. So this picture is all I have.

I’m so sorry for the quality here.

Now the data can be copied off and it no longer protected. On the bright side, this was exceptionally noisy and powershell logging would easily catch me fumbling around and running commands normal people don’t run. Constrained Language Mode also makes it slightly more difficult to script, being that Expand-Archive cannot execute without full language.

Now let’s see how safe this is from Evil Hackers. Same setup as before, but this time I’m a click-happy user who clicks on every link because I believe good security should insulate me from easily making bad decisions. I have AppLocker running with whitelisted directories, full UAC, and Constrained Language Mode. So let’s start with Empire and the hta stager.

Just to confirm execution out downloads is denied, I try running nice1.exe and it fails as expected.
Ignore the bottom message.
Well that isn’t good.

It would appear that despite explicitly denying execution out of Downloads, .hta doesn’t let that stop its magic. At least we still have defense in depth, and don’t need to worry about this exposure.


Let’s pretend that I was able to deliver a malicious payload that bypassed everything and executed on the box. What happens now?

That’s right! Access denied! You got nothing toda… oh.

Now we’ll just assume I abused an unquoted service path or something.

I download things. They’re still protected.
Still readable.

Despite quickly getting around it, WIP is still a great step in classifying and containing data. Everything I was doing here was so noisy that any endpoint behavior monitoring would have picked me up through abnormal behavior. WIP logging is robust enough to identify me trying to dump data through the GUI, AppLocker logging saw me execute all the binaries noted above (except hta). I bet if you use the Linux Bash Shell on Win10 it would bypass all that logging…