Tuesday, December 5, 2017

Threading based Sleep Evasion



Recently we came across an interesting sample: MD5: 52540f430c060a7e5753c999891514a1. A first look at the analysis revealed the following characteristics:




Besides a small spike in the classification chart towards Evader, the sample does not show any interesting behavior. It becomes more intriguing when we look at the slideshow, there we can see that the executable crashes on launch.

If we dig in further and look at the process we find some interesting sleeps:



The sample sleeps twelve times 0.1 seconds and one time 30 seconds. Thanks to Hybrid Decompilation we can easily understand the goal of the two delays:


This is the entry point of the sample. It first initializes a variable named _v8 and then creates a thread and passes _v8 by reference. Right after it sleeps for 30 seconds (0x4e20 >> 1 + 0x4e20 = 30'000). Finally, it uses the variable _v8 to calculate a function address which is added to 0x40b917. This function address is also called (passing _v12 as an argument).

Let us now have a look at the thread entry point, function 408B56:


The function is very simple. It is an endless loop that increases _a4, which is the address of _v8. For each increase, it sleeps for 0.1 seconds. When Sleep in the main function ends, _v8 is equal to 300 because the Sleep was for 30 seconds and the thread function increases _v8 by one for every 0.1 seconds.

As we saw at the beginning, the sample crashes, so the calculation of function address and _v8 must be wrong. But why?

Sleep evasions are a common trick to evade sandboxes. The simplest trick is just a sleep which delays execution of the payload. The delay usually is greater then the time the sandbox executes the sample. As a result, the payload is never executed during analysis.

To tackle this evasion, sandboxes automatically modify sleep values. In Joe Sandbox this can be defined by the user:


Let us assume we used the command _JBShortenSleepsGreaterThan(20000, 100) in the analysis above. With this setting, all sleeps greater than 20 seconds are shortened to 0.1s.

What is the effect on the code above? Well, the sleep in line 11 does not take 30 seconds anymore but rather 0.1s:


Due to that, the thread function 408B56 only runs for 0.1 seconds and _v8 is equal to 1. Therefore the function address called in line 12 is wrong and the sample crashes.

To summarize, the sample exploits the fact that sandboxes shorten sleeps/delays based on a threshold.

Full Joe Sandbox Report (with evasion working) below:


By changing _JBShortenSleepsGreaterThan we can easily bypass the evasion and see that sample is a ransomware:






Interested in trying Joe Sandbox? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!


Monday, November 27, 2017

Retefe loaded with new MUILanguage Sandbox Evasion


Lately, we came across a new Retefe version which uses some nice trick to bypass sandboxes (Retefe is a well know and sophisticated e-banking trojan). The initial analysis looks quite normal, there is no suspicious behavior, no dropped files, domains requests etc.





One interesting fact though is the WMI query:



If we extract the memory strings (strings taken from memory dumps) we detect a fully VBA script:




The interesting function performing the WMI query is called "CheckTest":



The function enumerates the MUI languages, which basically is a list of all installed languages for the Windows interface (MUI stands for Multiple User Interface). If only one language is installed, and this language is en-US then Retefe will not execute any payload.

Within 2 working days we added a new VM to Joe Sandbox Cloud which has several language packs installed:


Executing Retefe on that multi MUI language machine reveals all the IOCS & payloads:







Have a look at the full Retefe analysis report:




Interested in Joe Sandbox? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!

Thursday, November 23, 2017

Detecting Phishing Pages with Template Matching



Password Fishing (Phishing) has become the Number One vector of cybersecurity incidents and data breaches. According to a recent SANS Institute report, 95% of all incidents start with phishing attacks targeting any size of companies, from small family-owned businesses to large multinational corporations.

Generating Phishing pages is very easy and can be automated easily. Detecting the attack is the difficult part. Under these circumstances, security professionals have to rely on advanced sandbox solutions to detect the attack, but many dynamic analysis products don't even offer Phishing detection.

A standard Phishing attack starts with an email, designed to trick users by making them believe it is legitimate and contains very urgent/good news:


Or that something is wrong and their action is needed:



When the victim clicks on the embedded link, the web browser will be redirected to a page similar to Google, Amazon etc. On that page they will be asked to divulge sensitive personal information like passwords, usernames, credit card numbers, etc:


In v19 of Joe Sandbox we added a powerful new feature, the Phishing detection. When you submit a URL to Joe Sandbox, the analysis engine will automatically open Internet Explorer and navigate to the link. Even more, all links on the page are clicked upon in order to get the full behavioral picture. On each page Joe Sandbox checks for various artifacts:

  • Is there a password login and no HTTPS?
  • Are there non-working links?
  • Does the page header match the URL?
  • How many links are on the page?
  • Where is the password sent to?
  • etc...
Adopting this methodology, Joe Sandbox is able to do a first good classification. However, it is more and more common that Phishing pages do not show any bad or suspicious characteristics. They use HTTPS, have working links and everything looks legit. To detect those tough cases we have developed a new technology, called template matching. 

Template matching is a known image problem where the challenge is to find a smaller image in a bigger one. A good example is detecting a person on an image when we only have the pass photo of that person:

Template

The same problem & solution can be applied to the Phishing detection case:

  • Given a web page which has a password login
  • Check if a known logo is present on the page
  • If a match is found, check if the URL is correct
Let's take as an example the Yahoo Phishing sample above. In this case, we start with checking the existence of the Yahoo logo or various other logos on the webpage:

Template



If there is a match, we could then check if the URL belongs to Yahoo or not. By default, this works very well. But what if the scale, color, and size of the image vary? Well, we can change the picture to grayscale, detect edges and compare the images with various scales. 

In Joe Sandbox v21, we implemented a full-blown logo template matching engine to detect Phishing:


The full analysis report is available here:



Interested in Joe Sandbox? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!


Wednesday, October 25, 2017

NotPetya reappears as BadRabbit and keeps the Semi Kill Switch



Yesterday, Russia and Ukraine have been targeted by the Bad Rabbit Ransomware, distributed via drive by.

The sample named install_flash_player.exe, sha256 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da has some very strong similarities to NotPetya, the ransomware spreading via EternalBlue SMB exploit in June.

There are many behaviors based similarities, such as started processes:

NotPetya

Bad Rabbit

But there are also many code based similarities. Multiple companies already blogged about the differences (1,2), however, what we found very interesting is also that the ransomware kept the kill switch. Not the one which was domain based and activated by @Malwaretech for NotPetya but rather the local machine based, which once set prevents infection. If one looks at function 807E8E we can see that Bad Rabbit checks for the file C:\Windows\cscc.dat. If it exists the process will exit:







So, to get protected just create the file C:\Windows\cscc.dat and you are good!

Full analysis + sample available at Joe Sandbox Cloud Basic.

Thursday, October 19, 2017

Bare Metal - Golden Hardware


Joe Sandbox enables analysts to execute and analyze malware on Bare Metal machines. What is Bare Metal and why does it matter? No, it is not the cool Bare Metal hot rod above, but it has a similar performance!

Dynamic malware analysis systems (so-called sandboxes) execute malware samples on a segregated machine and capture the runtime of the behavior. Sandbox vendors use different types of analysis machines:

Virtual Machines

Virtual Machines (VMs) are the most common. They run inside VirtualBox, VMware, KVM or Xen - the top four virtualization solutions. VMs typically run on hardware with hardware virtualization. Hardware virtualization helps to run multiple operating systems efficient and secure on the same physical machine. Although a VM can run hardware virtualized it is not equal to Bare Metal.



Qemu (Full System Emulation)

Qemu is a machine emulator. The hardware has been fully implemented in software, including the CPU, disk, video card etc.


Bare Metal 

Bare Metal is referring to using a physical device for analysis, e.g. a laptop or PC directly purchased from the local hardware store.



Bare Metal is King

So does it matter if a malware is executed on a VM, Qemu or Bare Metal? It does a lot! The "normal" execution environment of malware is always on Bare Metal. Your employee laptop does not run on a VM or Qemu. Malware exploits that fact by checking if it is running on Bare Metal. If it is not running on Bare Metal it simply does not show any malicious behavior. As a result, the sandbox will not detect any malicious activities, plus will wrongly classify the file as clean:


How difficult is it for malware to detect a VM or Qemu? Very simple. How hard is it to make a VM or Qemu look like a Bare Metal machine? Practically not feasible. There are scripts around to remove some of the vendor brands and strings, however, that is just the tip of the iceberg.

To prove that let us execute the tool HWInfo (displays the hardware configuration of the machine) both on a KVM virtual machine, and a Bare Metal machine:

KVM



The full HWInfo report on KVM is available here.

Bare Metal




We have summarized some of the outliers below:



As you see there are many differences. The table just lists some outliers for hardware devices. However, malware could also check and compare the performance of the machines, e.g. the GPU.

KVM



Bare Metal




Again, there are big differences. And again, making the KVM VM equal to Bare Metal is practically not feasible.

Joe Sandbox, no restriction for Bare Metal analysis

Joe Sandbox does not restrict you to analyze malware on a particular virtualization solution or device. You are free to choose on which kind of machine to analyze:

  • Modern Bare Metal Laptop
  • Modern Bare Metal PC
  • Mac Mini
  • Mac Book Pro
  • Bare Metal Android Phone (e.g. Motorola G3)
  • iPhone
If you use Bare Metal machines you leave malware no chance for detection. Detection techniques which are successful for KVM, VirtualBox, VMware, Xen and Qemu will fail since the malware is executed on a real device. So if you already have a sandbox or are looking to get one, then ask yourself: is Bare Metal analysis supported? Or is the sandbox solely based on KVM, VirtualBox, Qemu or Xen?

Golden Image - Golden Hardware


With Joe Sandbox you are not only free to choose the target analysis machine but also the operating system, its configuration and installed applications. Again there is no restriction, you can install any software. 


With Joe Sandbox you get the ability to analyze malware on a Golden Image on Golden Hardware!

Interested in Joe Sandbox? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!