Bypass Application White-listing/Control Notes

In summary, whitelisted apps & OS components that are

(1) programmable (eg. powershell, OS scripting, WMI, Office Macros, Java, Javascripting and other allowed Active Contents)

(2) able to load another piece of code in the form of Assembly/DLL/executable-binary (eg. rundll32, msiexec, browser extensions/plug-ins) from a non-whitelisted writable path.

can be abused….

Another way to look at it: ‘It’s a feature, not a bug’ (eg. process hallowing is not really a bug i.e. more of a design &/or configuration issue). By ‘bugs’, I am referring to implementation errors that leads to memory (Heap & Stack) corruption and ultimately hijack of CPU control/execution flow. There’s no need for fancy techniques like buffer-overflow, Return-Orient-Programming blah blah blah.

Of course the attack can start off with such exploit techniques (eg. through the whitelisted browser), run some shell-code that calls such OS or app components. Alternatively, send you an Excel sheet laced with macros (some users are really ‘clever’ to set trust the entire C:\ & subfolders just to get rid of the irritating macro prompt) or a CHM file that auto-runs when opened (both are Active Contents), installs persistence using these whitelisted components techniques so as to establish remote control of the machine or perform whatever objectives.

The challenge is to identify (re-evaluate even if we think that the endpoint is already ‘hardened’) and minimize impact to business if we remove such components. If the component cannot be removed, at least limit the usage or implement controls to apply restrictive policies against these whitelisted apps & OS components that uses isolation/containment, like Windows 10 with Device Guard, Bromium, Bufferzone, Invincea…. ShadeSandbox (freeware) or the hardcore techies Qubes OS (opensource).

The following evasion techniques are most likely applicable to most Application Whitelisting/Controls regardless OS native (AppLocker, SRP) or 3rd party (Bit9 now CarbonBlack, SCSP…). Linux is my favorite OS because there’s no native App Control… #JustKidding



SEC Consult found a couple of vulnerabilities for SCDS & SCSP. In short, abuse msiexec & Windows Management Instrumentation.



Abuse command line tool for iSCSI initiator to bypass UAC (privilege escalation) highlighted by JPCERT

This technique can be ‘repackaged’ into a ‘rubber ducky’ style type from CMD console attack to evade app control and gain privilege assuming the iscsicli.exe was not locked-down/removed.


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.