Macro Based Anti-Analysis

Over the past several months PhishMe research has noticed an increase with Anti-Analysis techniques being included within Office macro and script files. This is the first post in a series where we look at the inclusion and effectiveness of these methods. Although the use of Anti-Analysis techniques is not new, they are generally observed within the packed payload in an effort to avoid detection by endpoint security solutions.

Most recently we came across a campaign of emails which included a malicious Microsoft Word document. The document contains a standard lure using an image instructing the user to enable active content as it was authored with a newer version of Microsoft Office.

figure 1

Once macros are enabled during analysis we generally see activity as the execution is triggered when the document is opened or an object is initialized and the script begins extracting or downloading a malicious payload, but we noticed with samples from this campaign that there was no activity when the macro was enabled.

Using oletools to quickly scan the document we see that the hook to trigger the macro code is using the Document_Close event instead of an event triggered using document open or object initialization. Running the sample in a sandbox further confirmed that dynamic analysis results were not available as the session timed out and the macro code was never executed.

figure 2

Visualizing the call-graph shows that the macro is composed of one main function and a de-obfuscation routine which allows us to quickly focus on the calls within the ijPql function. Analysis led us to find additional anti-analysis checks within the Macro before the payload was downloaded and executed.

figure 3

The macro first checks that the current username is not ‘USER’ and then checks that the RecentFiles count is > 3

figure 4

The macro then makes a HTTP GET request to with the following custom headers:

  • Referer: ‘’
  • User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)

A successful request returns a JSON object which includes a traits structure containing information about the ISP, Orgainization and ASN.

figure 5

The result is then checked if any of the following strings exist within the JSON string.


If any of the checks fail, the macro will exit and not download the configured payload.


We see another example of attackers migrating anti-analysis techniques that are traditionally seen included within a packed payload, up the stack into the initial infection script. The use of a finalization event (on_close) to trigger execution, demonstrates that attackers understand the default capabilities of sandboxes and are implementing techniques to bypass automated analysis. Additionally, the inclusion of network source checks focusing on security and hosting infrastructure further indicates awareness of cloud based services being leveraged by researchers and security companies.

Although the checks are easily bypassed by researchers and analysts because they are implemented in a scripting language. They have been observed to be effective in circumventing dynamic analysis in common sandbox deployments.

Document Samples  

  • 683154fa03f494bd368042b3546f7b04
  • 3bb6807d88a7ee359d7d813e01700001
  • 4c59ccbc0c524069e46ad8d92e65a14c

2016 Q1 Malware Review – Available Now

Today, our research team released our 2016 Q1 Malware Review, detailing more than 600 Active Threat Reports and the waves of phishing emails that delivered malware to victims across the globe each day last quarter. Among the sea of threats reported, the proliferation of ransomware stood out as one of the most common types of malware used through soft targeting and massively distributed attacks.

Awareness isn’t the goal, it’s just the beginning

When people refer to PhishMe as the awareness company, we smile and nod. I want to correct them, but the label ‘security awareness’ is comfortable and relatable. One of the activities that organizations commonly believe will help reduce risk is mandatory security awareness computer-based training (CBT) lessons.  The hope is that if we enroll our humans in online courses about how the bad guys hack us, they will walk away with a wealth of new-found awareness and avoid being victimized.  (Try to visualize how far in the back of my head my eyes are rolling…)

PhishMe Celebrates National Cyber Security Awareness Month 2015 and UK Based Security Serious Week

It’s that time of year again. No, it’s not the arrival of the pumpkin spiced latte at your local coffee shop. It’s National Cyber Security Awareness month (NCSAM) as proclaimed by President Barack Obama last year. “National Cyber Security Awareness Month — celebrated every October — was created as a collaborative effort between government and industry to ensure every American has the resources they need to stay safer and more secure online,” as stated by the National Cyber Security Alliance located on their website. At PhishMe, we are proud to once again play a lead role in the cyber security community as a 2015 NCSAM “Champion” sponsor.

Upatre Malware Anti-Sandboxing Mechanism Uncovered

Researchers have been studying the Upatre malware anti-sandboxing mechanism over the course of the past few days, after capturing a number of samples of the malware.

The Upatre malware anti-sandboxing mechanism involves a delay in activity. A 12-minute delay to be precise. That is how long it takes before the malware downloads its malicious payload. The delay is an anti-sandboxing tactic to ensure that the malware is not being executed in a sandbox environment where its actions can be analyzed and studied by security researchers. An early example of this technique can be found in any of the binaries delivered by the spam messages profiled in PhishMe Intelligence database (Threat 4301) using spam email content like that shown in the image below:

Sandbox and analysis evasion is not a new technique for malware. Many of the mechanisms utilized by malware to detect that they are under analysis are exceedingly complex. Those anti-sandboxing mechanisms look for evidence of a sandbox hidden deep in the environment.

This often takes two forms—searching for traces that would indicate that the malware is being run on a virtual machine or searching for tools used by malware researchers to analyze the sample. These tasks require comparison of registry entries, device names, and running processes against known values that would reflect that the environment in which the malware is being run is not a real computer. However, as a result of the ongoing arms race between researchers and threat actors, analysis techniques have been developed that allow for researchers to avoid giving away their presence to the malware’s runtime. In fact, many of these analysis techniques have been implemented in automated and inline sandboxing tools, where advanced and sophisticated virtual machines are used to screen content for malware.

However, the Upatre malware anti-sandboxing mechanism is somewhat different to highly technical anti-sandboxing and analysis techniques. Instead, Upatre malware exploits characteristics of researcher behavior in creating and utilizing analysis environments. A similar tactic is employed by the Dyre Trojan, in that the malware interrogates the number of cores in the computer’s processor, refusing to execute in cases where there is only one. The Dyre Trojan makes the assumption that many analysis sandboxes will utilize a virtualized processor with only one core while nearly all real, consumer-grade computers will have at least two cores in their processors.

A similar line of thinking is employed in the Upatre malware anti-sandboxing mechanism. The assumption made by the threat actor is that no real computer in use by a human being will be booted immediately before executing the malware binary. Instead, this behavior would be characteristic of a sandbox being started immediately before the introduction and execution of a malware binary.

Upatre malware utilizes the Windows GetTickCount function, used to enumerate the number of milliseconds that have passed since the Windows system was started. This is an effective means of tracking the system’s uptime, providing the malware binary an insight into the duration for which the system has been running. This anti-sandboxing mechanism is a simple branch in the malware’s execution logic. If the GetTickCount function returns a value that is too small—less than approximately 720 seconds or twelve minutes—the malware takes a branch that leads directly to a process exit. However, if GetTickCount returns a value greater than the twelve-minute uptime the malware will proceed to download and deobfuscate its Dyre malware payload.

Figure 2 shows the assembly code passed to the processor by an Upatre sample utilizing this uptime constraint. The red-highlighted breakpoint is the beginning of the code section where the value returned by GetTickCount is handled, while the black-highlighted line shows this value stored in the processor’s eax register as the hexadecimal value 0x001EA5E. That corresponds to a decimal value of 125,534 representing the approximately 125,000 milliseconds of uptime for the analysis system. After the return, immediately below the black-highlighted entry, the malware branches to either terminate the process or continue with the download and execution of a Dyre sample.

By denying researchers or sandboxing tools the ability to observe the malware’s runtime behavior, except under certain specific circumstances, the threat actor preserves an element of secrecy for his or her operations. The indicators by which an Upatre sample can be identified are not revealed, thereby preventing those resources from being shared widely among researchers. Furthermore, since the malware’s hostile behavior lies beyond the crucial uptime-dependent branch, many sandbox tools would not provide visibility into the malware’s fully completed runtime, thereby missing crucial intelligence on this rapidly evolving threat.

PhishMe customers have access to the special report on this topic in their documents folder on PhishMe Intelligence. If you are not currently a PhishMe Intelligence customer and would like further information, please contact the PhishMe team today.

Updated Dyre, Dropped by Office Macros

Whenever attackers make a shift in tactics, techniques, and protocol (TTP), we like to make note of it to help both customers and the rest of the Internet community. We recently analyzed a sample that started out appearing to be Dridex, but quickly turned into a headache leading to Dyre that featured some notable differences to past Dyre samples. One PhishMe user was targeted to their personal account, and here’s a copy of the phishing email:

Figure 1 -- Phishing email

Figure 1 — Phishing email

Once opened, we’re presented with the very familiar story of “please enable this macro so you can get infected”. This time, they do give a few more instructions to the user, saying that the data is “encoded” and macros need to be enabled to read the text.

Detecting a Dridex Variant that Evades Anti-virus

Attackers constantly tweak their malware to avoid detection. The latest iteration of Dridex we’ve analyzed provides a great example of malware designed to evade anti-virus, sandboxing, and other detection technologies.

How did we get our hands on malware that went undetected by A/V? Since this malware (like the majority of malware) was delivered via a phishing email, we received the sample from a user reporting the phishing email using Reporter.

Dridex Code Breaking – Modify the Malware to Bypass the VM Bypass

Post Updated on March 25

The arrival of spring brings many good things, but it’s also prime season for tax-themed phishing emails. A partner of ours recently reported an email with the subject “Your Tax rebate” that contained an attachment with Dridex and password-protected macros to hinder analysis. If you read this blog, this story should sound familiar, but this particular strain took new precautions, such as adding a longer password and using VM detection inside of the code.

Decoding ZeuS Disguised as an .RTF File

While going through emails that were reported by our internal users using Reporter, I came across a particularly nasty looking phishing email that had a .doc attachment. At first when I detonated the sample in my VM, it seemed that the attackers weaponized the attachment incorrectly. After extracting and decoding the shellcode, I discovered a familiar piece of malware that has been used for some time.

Dridex – Password Bypass, Extracting Macros, and Rot13

When attackers decide to password protect something, it can be very frustrating as an analyst, because we are often left with few options to find out what they are protecting. If this happens, we can always try to straight up brute force the password, but unless the attackers use something like 1q2w3e4r, we’re up a creek without an oar. If it’s an MD5 hash of a password, we have many more options to crack it. In the case of xls files, we have the option to essentially “wipe out” the password and give it our own password. In a recent wave of Dridex phishing emails, this is what we saw. Here’s the phishing email sent to one PhishMe employee: