Angler EK – A Bromium Discussion

Author: No Comments Share:

Disruptive attacks against individuals and organizations are rapidly rising, as was noted in recent security reports (Mandiant, A Fireeye Company, 2016).  As an example, ransomware has been a big problem. As we look at customer security alerts we note that ransomware could have been a problem for our clients as well. Thus, we decided to compare a typical approach to stopping evolving threats, to the Bromium approach.

Tracking Angler

Many security vendors and enterprises, employee a good number of malware analysts to follow the latest attacker tends. Recently, there has been a rise of an exploit kit (EK) known as Angler (Fraser Howard, 2015 ). Angler leads in effectiveness and sophistication (Cisco, 2015). Angler has been quick to integrate the latest software attacks, such as the Hacking Team Flash exploit (Brooks Li, 2015).


All of that is interesting enough, but what makes modern EKs so versatile is their mode of operation. They often use ads or compromised domains to silently inject into a victims browsing session (John Mancuso, 2015). A typical Angler landing page (exploitation point after redirect) isn’t necessarily stealthy to a human, because text from Jane Austin’s novel Sense and Sensibility is often present (Boonen, 2015). While machine learning algorithms could perhaps find similar web pages (but Angler would change if they did), lets examine the typical approach to malware analysis:

  1. Find samples
    1. That can be hard. Angler uses many tricks to avoid analysts, like IP watching.
  2. Difference across them
  3. Find a common string, binary signature, or pattern
  4. Create a IPS/HIDS search rule (often a regular expression or REGEX)
  5. Search for instances of the attack with the newly created detection rule

That can work out ok. That’s how many enterprises are doing security. They either create the rules themselves, and/or get them from their security vendors. The problem: Angler has figured out DevOps. They can, and do, change characteristics about each phase of their delivery on a very regular basis.


As an example, see a recent Check Point blog: (Horowitz, 2015). They make the case that they can block exploits before zero-day. It seems to have worked in one case. They examined a sample of Angler. Found that it had a string “Jul 2039” or “Jul 2040” in the HTTP response Last-Modified field. They updated their IPS product to search for this future date, and apparently had a success with a customer. Great. The problem: that rule is pretty weak, and Angler changed it shortly thereafter. To prove this, I wrote the following YARA ( rule and tested against our samples.


Not one match was found. To me this is no surprise. EKs are agile. I sometimes even wonder if malware authors intentionally leave obvious strings, for malware analysts to key in on. The security folks waste their time, and the bad guys know all along, they will change them tomorrow? To illustrate my point, look at the comment on the Check Point blog I just mentioned, where they boast about their new IDS rule.  Last year, someone wrote:


Not confidence this message is really from the Angler EK team, but it certainly seems to help make my point. REGEX is hard. Following criminals around the Internet to make new ones everyday is hard. Rolling new rules out to a diverse set of enterprise tools in real-time is hard.

A Different Approach

We protect our customers differently. We do have detection, both on the host and in micro-VMs. But the protection is provided separately with VMs. Thus, our detection rules can be simpler. They focus on higher level system activates, such as new processes, files, registry modifications, and more. These types of rules are harder to fool. In order for malware to work, it must do some of these things. And when malware “works”, there is no real harm to our customers. Simply close that document or browsing tab, and that virtual computer is deleted. Instant remediation. But the threat intelligence from the event is kept. Lets look at the event data generated from such an attack.


Here’s a LAVA event, for what would have been an Angler/TeslaCrypt infection:


The data in the Bromium Enterprise Controller includes the following IOCs:

  1. URLs


  1. IP addresses
    1. 3 in US, 1 in EU, and 1 in RU in this case
  2. Hashes of dropped malware
    1. TeslaCrypt
      1. 7af44770bd8a7def59793ee95d26fcf6
    2. Notable persistence or cleanup actions
      1. Deletes dropped binaries

Of the URLs, a deeper inspection of the micro-VM event data shows that the ogromnuesosochki are the redirects, autodebone is the landing and exploit (Flash), and the dustywinslow is the C2.


Detection is great, and we use it as well. There will always be gaps. But protection that works, provides real threat data, and doesn’t require daily REGEXing, is a better approach to stopping high impact threats like the Angler EK.

Works Cited

Boonen, R. (2015). Angler EK JavaScript Deobfuscation: The Emperor Has No Clothes.

Brooks Li, T. M. (2015). Hacking Team Flash Zero-Day Integrated Into Exploit Kits.

Cisco. (2015). Midyear Report.

Fraser Howard, S. (2015 ). A closer look at the Angler exploit kit. Company Blog.

Horowitz, A. D. (2015). Angler Exploit Kit – Blocking Attacks Even Before Zero Day. Checkpoint.

John Mancuso, Z. (2015). Angler Exploit Kit Utilizing 302 Cushioning and Domain Shadowing.

Mandiant, A Fireeye Company. (2016). M-Trends 2016.

Previous Article

Macro-Malware Connecting to GitHub

Next Article

RSA Conference 2016: State of Security Survey

You may also like