Windows 10 "Redstone3" and injection/hooking

c++ / delphi package - dll injection and api hooking
dgmax
Posts: 3
Joined: Wed Jul 12, 2017 6:49 pm

Windows 10 "Redstone3" and injection/hooking

Post by dgmax »

Hello,

I have a general question about the upcoming Windows "Redstone 3" (a pre-release is available, build 16232).
It introduces new features, especially "Windows Application Guard", which launches a sandboxed Edge browser.
Is Madcodehooks capable of injecting the sandboxed process, and if not, do you have plans to support this ?

Thanks.
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by madshi »

Edge already runs in some sort of protected mode right now. I haven't yet checked out the new RS3 features. Generally, with Chrome and other sandboxes, DLL injection doesn't work if you start Chrome first and then try to inject afterwards, when the sandboxes are already up and running. However, if you start the injection first and then Chrome afterwards, injection currently still works ok. The same *may* be true for Edge in RS3. But it's also quite possible that DLL injection won't work at all.

Microsoft has introduced some new process mitigation features in RS2 already. Two important one are A) one that only allows DLL to be loaded which is signed by a Microsoft certificate. I've been told by a customer that an EV signed hook dll which runs through the Microsoft EV-counter-signing process satisfies this condition, but I'm not sure if that's as intended and will stay that way. And B) one that prevents a process from doing any sort of dynamic code, which practically means you can't unprotect EXECUTABLE pages, you can't allocate EXECUTABLE pages etc. Which practically means, API hooking is made nearly impossible.

I think these new process mitigation features introduced in RS2 might already prove difficult enough to work with, if possible at all. So I'm not sure if RS3 can make it any more difficult. Already in RS2, if these new process mitigation features are enabled, madCodeHook is in trouble.

Of course I could try to workaround these new protections, but I'm not sure if I should. Should I try to weaken or workaround intentional protections invented by Microsoft? Well, if you're a security developer, working for an anti-virus company, obviously it's bad if you can't inject your hook dll into some processes, anymore. So maybe the answer to this question should be "yes". But for "normal" developers I'm wondering whether it's a good idea if madCodeHook tries to bypass OS protections. But this is really a difficult topic...
dgmax
Posts: 3
Joined: Wed Jul 12, 2017 6:49 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by dgmax »

Thank you Madshi, I appreciate you taking the time to answer my question.
I understand the concern about weakening protections put in place by the OS vendor.
I was just curious.
erick.engelke
Posts: 2
Joined: Mon Dec 21, 2015 9:53 am

Re: Windows 10 "Redstone3" and injection/hooking

Post by erick.engelke »

I see your point. There is the legitimate concern you might be viewed as a vigilante hacker and get our certs blacklisted.

On the other hands, I'm annoyed at MS to believe they are above the standards everyone else is to use.

In my case, I noticed that microsoftedge.exe does not attach to the injection DLL and I spent much of the morning digging. I found all internal hacks and avoiding standard calls.

It turns out my clients found Edge too buggy anyways and were happy to give it up.

My response was to prevent users from running Edge, which I do by attaching to and killing browser_broker, which is a process edge relies on. No browser_broker.. edge won't work.

Erick
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by madshi »

erick.engelke wrote:My response was to prevent users from running Edge, which I do by attaching to and killing browser_broker, which is a process edge relies on. No browser_broker.. edge won't work.
Haha! Quite brutal, but effective.

My fear is that Microsoft is going to enable these new process mitigations for many more processes in the near future... :(
choochy2003
Posts: 88
Joined: Fri Mar 21, 2008 4:52 am
Location: Adelaide, South Australia
Contact:

Re: Windows 10 "Redstone3" and injection/hooking

Post by choochy2003 »

We have done some research and found that WHQL signed DLLs seem to bypass this new security behaviour of Windows. We created a HLK package which included EV signed copies of our Injection DLLs and that fixed the problem in our tests.
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by madshi »

Yes, I've heard that from another source, too. However, this only works for the signature mitigation, but not for the "dynamic code" mitigation.
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Windows 10 "Redstone3" and injection/hooking

Post by iconic »

Dynamic code mitigation should allow an outside process to allocate or change protection to execute access on regions but it's a pain to rely on a helper process which does this work for you but it's definitely doable, just not ideal by far. You could also just have it allocate a sizable block and jump around like a rabbit (short to long if needed) but that's not much easier on you. Anyhow, the most intelligent thing to do imho is to just have your driver allocate or change page protection for you as opposed to doing this from Usermode. Lockdown the dispatch handler (security wise) and just use an IOCTL as you would normally do for Ring 3 -> Ring 0 communication through DeviceIoControl or Read/WriteFile.

Also, maybe inquire as to how Microsoft's own Detours library is doing this, assuming they are in newer versions (probably the $10,000 source edition LoL). I can't image that they'd kill off their own library when it's been used by everyone under the sun for as long as it's been around and licensed extensively. Who knows though anymore, they lost their minds with the SHA-1 phaseout over nothing more than theoretical nonsense that I've yet to see abused in a real world scenario ITW

--Iconic
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by madshi »

I've thought about letting the driver do the PAGE modifications, but that would almost classify as "malware like" behaviour. As in: Trying to undo OS security. I'm not sure if madCodeHook should do that... :(
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Windows 10 "Redstone3" and injection/hooking

Post by iconic »

You could possibly make it an optional flag that could be explicitly set, that way it's not the default behavior for dynamic code mitigated processes. Sadly, the same people (AV companies) who label it as such employ the same types of techniques, often times much worse even at the kernel level. The only difference is they feel their software is justified because the term "Anti-Virus" is part of the software title's name. The same companies that griped when MS forced driver signing on x64 and they couldn't "easily" hook kernel services anymore without relying on even dirtier and far more unstable as well as insecure practices. I don't think it would be much more difficult to hunt down any executable region through querying and overwriting it with your own payload, malware authors already do this and since MS still allows outside access changes it doesn't seem to be as effective as the mitigation name implies. The whole thing seems backwards to me anyhow, why lock the door on yourself from inside yet allow any stranger to open the door and enter without ever even needing a key, so to speak?

--Iconic
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by madshi »

Yeah, it seems very backwards to me, too. I've not decided yet if I want to try workaround the dynamic code stuff. Will depend on customer feedback, I suppose.
NobMiwa
Posts: 7
Joined: Tue Mar 28, 2017 10:00 am

Re: Windows 10 "Redstone3" and injection/hooking

Post by NobMiwa »

Hello,

I am developing an monitoring program that monitor the employ who attached file into Web Mail. So I have to monitor MS Edge when the employ attached file into Web Mail, too. I don't need to change values of APIs, but just monitor.

I hope you will add option to inject dll into MS Edge.

Regards
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by madshi »

If we're talking about employees, it's in the interest of the employer to make monitoring possible, so it should be possible for the employer (who probably owns the company's PCs) to disable the MS Edge extra protection that stops madCodeHook from working. I think you can turn these protections of in the group policies somewhere, or in the registry.
Baconzor
Posts: 17
Joined: Tue Dec 01, 2009 3:15 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by Baconzor »

I'm currently stuck in the same predicament, the sandbox rollout is slowly taking place (around 5% of my userbase are unable to inject into edge by now)

My entire app user base are employees, if I could easily disable edge's sandbox through GPs or registry, by already being in full access to the machine through services and drivers wouldn't that easily defeat the effectiveness of the sandbox against apps trying to bypass it? I've looked it up so far did not find an option to disable the sandbox

So the solutions that works so far are

1) Block Edge altogether and instruct clients to use other browsers
2) Go through WHQL signing process for the dlls (do they do dlls only or they gotta tag along with other cat/sys files?) now that microsoft embeds their signature into other files so edge gladly accepts it

Anything I missed?
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Windows 10 "Redstone3" and injection/hooking

Post by madshi »

I've done some searching and here's what I had in mind:

https://docs.microsoft.com/en-us/window ... y-policies

Unfortunately, this policy setting currently doesn't seem to allow overriding the "dynamic code" and "signed only" mitigations, so it doesn't seem to help us... :(

Your option 2. may help with getting your hook dll injected, but "thanks" to the dynamic code mitigation you'll probably not be able to install API hooks, so I'm not sure how far that would help you?
Post Reply