by Amir Khashayar Mohammadi
In the first part of this mini-series, we examined which methods have been applied so far to break local browser and app sandboxes. Now let’s look at how attackers gain an advantage with sandbox evasion techniques.
Sandbox escapes allow attacking local machines with exploit kits that are usually hosted on compromised web servers.
Such exploit kits then scan the “inside” of the browser to identify more weak spots and deliver a payload, like ransomware or spyware.
Once the sandbox is broken, nothing can prevent a malicious payload from being transferred. The privileges that were once given to the browser are now being used to render malware directly to your machine.
How attackers gain time with sandbox evasion techniques
No matter how sturdy the sandboxed environment turns out to be in the end, initially it creates an additional hurdle for web-borne attacks.
But the presence of sandboxing technology can also be read as a warning sign: “IT security researchers at work – possible malware analysis ahead.”
That’s exactly what happens when “Angler” encounters the sandboxing hurdle. This exploit kit doesn’t bother with breaking the sandbox. Instead, it takes advantage of its presence to prioritize the attack.
Prioritizing attacks through sandbox detection
Angler contains “anti-sandbox” code. The goal is to make sure that Angler does not try to exploit any machine that is being sandboxed.
This slick move has catapulted Angler to the top of the exploit kit charts as a ransomware “dropper”, mainly for two reasons:
The first is speed – when encountering a sandboxed environment, Angler doesn’t waste any time and quickly moves on to softer targets.
The second reason is detection and analysis avoidance during the course of a malware distribution campaign.
So if an IT security researcher decided to use a virtual machine to analyze Angler’s construct, the exploit kit can identify the sandbox trap and will not execute, preventing further analysis.
Let’s examine why this approach has been so successful in the wild.
*Infographic Source: Heimdal Security
Angler uses IP and UserAgent fingerprinting, which is applied solely to evade malware researchers/technicians. This means that the only type of analysis that can be conducted is on machines that have already been exploited, thus making sandbox technology useless (in terms of analysis).
Two specific vulnerabilities are exploited here, both present in Firefox (33.1.1) and Flash (126.96.36.1995). This exploit kit (like many others) uses components like HTML to exploit a vulnerable browser. You can embed code inside HTML with tags like
<param> for vulnerable browsers (mostly IE falls under this particular assertion).
Sometimes it’s not a vulnerable/outdated browser, it can also be vulnerable Java, Flash, or even Microsoft Silverlight. In the latter case, the exploit is sent as a file and not directly like with embedded code in HTML.
Angler delivers the malware to the machines in a stealthy manner, and all the computer must do is visit a site that has the malicious code configured.
On the screenshot/logs above, you can see Angler looking for vulnerable Flash and Firefox versions and then exploiting them once the version numbers match. Other information is also logged – such as cookies, server information, GET requests. This will help Angler find suitable vulnerabilities for exploitation.
Remember what I wrote before, that not everyone updates their software? Angler comes prepared for that. Because it’s perfectly normal to see different versions of software being used in the wild, this exploit kits is packing heat for many components and not just one particular vulnerability.
Not all sandboxes reside on the browser itself. Some sandboxes are designed for specific components that browsers use, like Java, Flash, etc. all of which users decide to add in the form of plugins.
Do I need to stress that adding such plugins/components is opening the gateway for potential exploitation?
Chrome actually has its own sandbox for Flash. Many exploit kits utilize the presence of outdated Flash plugins. Java has its own sandbox for when it’s applied inside web pages.
I mentioned how some sandboxes reside on the browser component itself. Java for instance has its own sandbox. If your browser is using Java, a vulnerability does not need to have an effect on your browser’s sandbox, but on the actual component like Java.
This means an attacker does not necessarily need to break out of your browser’s sandbox, it can just break out of the component:
Meet the g01pack exploit kit, a multi-staged based style attack. This exploit kit does just what I previously pointed out: it breaks out of the Java sandbox. This vulnerability (CVE-2012-1723) is present on all Java runtime environments prior to 1.7
Yes, that’s quite old. But it doesn’t matter, because here’s the sad part: Everyone hates Java updates. Why? They have one every other day. Do you really think everyone applies Java updates every single day, right when they come out? Of course not.
So attacking the Java sandbox itself will get the job done. Most people automatically update browsers, but make the mistake of not updating components that the browsers use like Java and Flash (unless the browser does it for them). This is just as bad as NOT updating the browser itself.
This exploit kit contains an explosive mix. Many researchers and malware analysts have found admin panels belonging to g01pack. What they don’t realize? This is a trap.
G01pack supplies an admin panel designed strictly for curious minds that are skimming through its inside components. When researchers are presented with a login panel, their (predictable) first thought is to enter default credentials like admin:admin. Surprise! It works.
After breaking out the champagne, the researcher then continues to browse through the statistics and what not, witnessed in the screenshot provided above. Now let’s see what’s really happening.
No, the researcher did not gain access to g01pack admin panel. Instead, he or she has been lured into a honeypot. Upon visiting the fake statistic page, the true owners of the server get to fingerprint what nosey researcher they’re dealing with – an interesting of gathering counterintelligence on security researchers.
Macro-driven sandbox evasion
Did you know that Microsoft Word can be used to detect and avoid a sandboxed environment? That’s exactly what Ursnif does, a very powerful banking trojan that’s deployed using macros.
Source: The Hacker News
Malware developers tend to sometimes embed their payloads inside widely used document file formats. Common file types usually like Word documents, Excel spreadsheets, etc. are very common. This is commonly referred to as a Macro malware/virus.
Macro malware is often found inside emails as attachments. People tend to open them, enable editing, and the payload executes usually with no interruptions. These types of malware are hard to detect, hence why it’s important to only open documents from sources you know.
So far, the Ursnif malware has been observed in the wild with the following extensions: *.PDF, *.MSI, *.EXE, *.PPT, *.PPTX, *.DOC, *.DOCX, *.XLS, *.XLSX.
Once the victim closes out of the document, Ursnif executes powershell scripts using the AutoClose function. This tactic is effective because it reduces the chances of being detected, since it only executes after closing the application and not while it’s open. What does this have to do with sandboxes?
Ursnif: Sandbox evasion through document macros
One of Ursnif’s sandbox evasion techniques includes checking to see the number of Word documents that have been accessed inside a machine to determine if the machine in question is a sandboxed environment.
Ursnif also checks to see if the machine is running Office 2007. It does this because many sandboxes that are used strictly for malware analysis are using that specific version. If the machine is running Office 2007, the payload is not executed.
Newer versions of Ursnif also check to see if any running process has specific sandbox-related keywords, such as “vmware” (virtual machine software) or “wireshark” (used for network analysis). All these tactics ensure that each infection is a real candidate and not a sandbox.
Reportedly, the Angler exploit kit has also been used to spread Ursnif. Both of these malwares excel in sandbox evasion techniques, making them a powerful duo. Each one brings forth high infection rates on those machines prone to the vulnerabilities it targets.
Equal opportunity sandbox exploits
It is important to note that vulnerabilities that allow attackers to break or evade local sandboxing environment are not limited to operating systems. MacOS, Windows, Linux/Unix all are dealing with their own unique problems.
When you access the web, will sandboxing the local browsers and individual plugins keep you secure? How much protection can you realistically expect?
The answer depends on many factors, some of which I have previously mentioned: Are you still suffering from the common misconception that all malware comes from emails and download initiations? Is your software up to date? Are you sure you’d never click on a popup, especially if it looks perfectly legitimate?
Regardless of how well supported, popular, secure and tightly “sandboxed” your local browser and its components are in the end, they are as imperfect as any man-made software.
So why take the risk and expose your computer to their vulnerabilities? Local sandboxing won’t protect you against inventive adversaries, as I hope I have demonstrated in my two posts.
Amir Khashayar Mohammadi is a Computer Science and Engineering major who focuses on malware analysis, cryptanalysis, web exploitation, and other cyber attack vectors.
*** This is a Security Bloggers Network syndicated blog from Authentic8 Blog authored by Guest Contributor. Read the original post at: https://authentic8.blog/breaking-and-evading-the-local-browser-sandbox-2/