Ambush – A New Capability for Advanced Defense

At BSides Las Vegas, I just released Ambush, an open-source Host Intrusion Prevention System that I have been developing for the past few months. See my talk at for the full motivation, description, and demonstration.

In summary, after all of my offensive research, Ambush is my effort to arm the defense. I wrote Ambush to help change a fallacy of defensive thinking (the wall mentality) and to provide the tools for the most effective defensive strategy: to understand attacks end-to-end, create and employ detections for those attacks at as many points as possible, and catch the attacker by doing something unexpected. If you have ever complained that the attacker only needs to win once or find one vulnerability to exploit, your strategy will fail.

Part of this is a reliance on intrusion detection and prevention systems built to monitor a point or set of points such as a network connection. In response, malware authors have become adept at obfuscating traffic through these points with encryption, encoding, and obfuscation. Ambush uses a different strategy, based not on another point but on the flexibility to add almost any point dynamically. This capability employs a function call hooking system that can intercept virtually any exported function or set of functions system-wide. This is in contrast to other HIPS's, which are limited to functions chosen during design and only monitor certain actions, such as file and registry edits.

For example, given the shellcode for the Eleanore Exploit Pack below, a common payload of exploit packs, we can see five different functions called. Ambush provides the ability to configure signatures alerting or blocking on any of these functions being called from outside a mapped module, or from read/write/execute memory, or by arguments, or by process, or from lower-layer functions.*

Attackers will be unable to perform almost any action without the possibility of getting caught, as any action can get caught in just about every conceivable way. Defenders now have far greater ability to do something unexpected and catch malicious activity.

In many exploits, attackers cannot evade hooks at all (e.g. command injection or chrome-privileged javascript execution) and in shellcode and malware, hooks seem to be very difficult to evade. In a recent survey of over 4 million malware samples, only about 1 out of every 1000 malware samples was found to be capable of bypassing any hooks at all. (See specifically the Anti-RE Categories and Anti-Debugging Techniques figures showing that < 0.12% evade hooks) This becomes even more difficult when the attacker does not know where the hooks are in the first place. I designed Ambush to be centrally managed and ready to use, and I would love to see it in action. So please get into contact with me (scriptjunkie at scriptjunkie {nospam} us) if you would be interested in getting it set up or tested in your organization, or if you would like to contribute ideas or development. I know it requires a lot of knowledge to be effectively used, so I am considering ways of easing the burden on those who are not malware reverse engineers or exploit developers. See all the details and download from

Eleanore Exploit Pack Shellcode:

* Examples:
By arguments - WinExec's argument matching a temporary path regular expression
By process - URLDownloadToFileA should only be used by a particular process or not by Internet Explorer
From lower-layer functions - CreateProcess rather than WinExec or if InternetOpen is called from urlmon.dll, that means URLDownloadToFileA or an equivalent was called

, ,

  1. No comments yet.
(will not be published)