Did you know that you can completely neutralize Doppelganging, Herpaderping, and some other Process Buzzwording techniques by applying literally any WDAC (Device Guard) policy? Even an AllowAll one?

Those things will simply be unable to run with WDAC enabled.

The root cause for this is again NtCreateProcessEx. A fan favorite amongst evasive process creation enthusiasts, and a dependency of the above techniques.

It looks that if CI policy is in place, this particular syscall will simply always fail.

The reason why it's so useful is two ways in which it's different from NtCreateUserProcess, the modern process creation syscall:

1. Instead of a path it takes a handle to a (SEC_IMAGE) section
2. No threads are created in the new process

This could be abused, as kernel notifications for process creation are only invoked when the initial thread is inserted into the new process, giving an attacker a lot of time to play around with the related section and file, before AV products get a look at the process.

The flow is generally just -
1. Create a process using NtCreateProcessEx
2. Do some weird stuff to either hide your tracks, or change the content of the process
3. Create the initial thread
4. Only now do the kernel callbacks run

My theory as to why the syscall is disabled given an active CI policy:

Image section signing levels are calculated at creation, and not during mapping. This is probably a TOCTOU bug in WDAC (and PPL?) just waiting to happen.

Instead of trying to mitigate all of the ways this could go wrong, people have probably just decided that the intersection of environments using WDAC and environments running weird old low-level software using legacy syscalls is the empty set, and just disabled it altogether.

But that's just my wild guess ;)

So apparently, my awesome coworker @AmirKutcher, with whom I discovered this together is on Twitter.
He deserves as much credit as I do for this discovery, and I hope I can eventually annoy him into publishing things as well.