Dridex Threat Actors Reinvigorate Attacks with Sizable, Concurrent Campaigns

One of the most historically effective techniques for gaining new infections for the powerful Dridex botnet malware has been sizable sets of widely-distributed phishing email. While these large campaigns have been intermittent for several months, the past week’s Dridex distributions have shown a renewed vigor with several larger campaigns being launched both concurrently and repeatedly. Many of these campaigns return to well-used and previously-successful email templates and malware delivery tools that had seen earlier utilization in conjunction with both Dridex deliveries and the delivery of other malware tools.

On March 30, 2017 three distinct sets of phishing emails were identified as delivering the Dridex malware. Each was a rehashing of a previously-used phishing narrative. The emails analyzed for Threat ID 8692 pretended to represent communication from a travel agency based in the United Kingdom confirming the recipient’s vacation travel has been booked. Other emails, delivered concurrently, purposed to deliver a vaguely- described “confirmation” as analyzed in Threat ID 8693. Furthermore, Threat ID 8700 documents a set of messages purporting to deliver a notice that an image attachment was ready for sending in yet another vague phishing narrative. Examples of these messages can be seen in Figure 1.

Figure 1 – Examples of Dridex phishing emails from March 30, 2017

The message narrative used in these campaigns should be familiar to information security professionals following Dridex as they represent similar themes to earlier Dridex campaigns. The impersonation of small- and medium-sized firms based in the United Kingdom was previously a common theme among Dridex delivery emails. This preference in content may serve to indicate a preference for a population with which those emails are meant to have disproportionate appeal. However, it appears that these emails were still delivered globally. The other repeated narrative seen once again today is a vague informational message about the status of an image attachment that has been readied for sending. Similar narratives have been used a half-dozen times in the delivery of Dridex since July 2015.

While the Dridex botnet malware’s users are launching phishing campaigns with renewed vigor, their stories and tools have stayed the same. This provides a distinct advantage to threat intelligence users who have access to repositories of information on the tactics, techniques, and procedures related to earlier attacks. It also provides an advantage to organizations whose email users are prepared and empowered to identify and report suspicious emails. Empowered recipients of messages like these are able to recognize the lure and instead of becoming victims, can make a difference for their organization by reporting the email.

Emails based on the threats shown in this blog post are also available as templates in PhishMe Simulator.

For further information on the Threat ID’s mentioned in this post, PhishMe Intelligence customers can log into https://www.threathq.com.

For more information on PhishMe’s human vetted, phishing-specific threat intelligence request a demo today.

The Rise of RaaS: Satan

RaaS, or Ransomware as a Service, enables threat actors that lack the skillset to write their own malware the capacity to infect people’s computers with ransomware through a service, holding the victims’ files hostage for Bitcoin payments. One of the latest RaaS offerings is Satan, a ransomware variant that is easily accessible on a hidden website when browsing with the TOR browser. The website allows anyone to create a ransomware sample which in turn takes a cut of the ransom proceeds from its victims’ payments.

Builder

The TOR hidden service website allows for anyone to create a Satan loader sample after registering for a free account. The front page encourages visitors to register accounts, create a new virus and download it. Although the site handles the building of the initial ransomware loader, it is up for the RaaS user to distribute the malware. Bitcoin payments made by victims are then credited to the RaaS user’s account and the service takes a thirty percent cut for facilitating this cybercrime. The website requires the user to correctly solve CAPTCHAs for any form submitted as a precaution against automated web vulnerability scanners. Below is a screenshot of the front that explains how the service functions:

Dropper

Although the RaaS requires its users to distribute the malware themselves, it also provides a dropper service to assist the user in the initial infection process. By utilizing a dropper, malware actors are able to bypass antivirus email scanners by creating malicious CHM or Office documents that download the ransomware loader once these files are opened by a duped victim who perceived these email attachments to be legit. This dropper service contains helper scripts, pictured below, that encrypt the ransomware loaders with a static XOR key, further bypassing virus detection if the system is solely looking for executables in network traffic. The RaaS user is also able to enter a URL where they host the encrypted ransomware loader that the generated droppers will download, decrypt, and execute the ransomware loader.

Once this information is entered, the user is then able to copy & paste either a CHM (Windows executable help file) or a malicious DOC macro. Although these malicious scripts are not obfuscated, they still have relatively low AV detection.

Per the instructions provided by the dropper service, the CHM generator creates an HTML file which can then be compiled to the Windows executable CHM file using the chmProcessor application, pictured below. The generated HTML file spawns a command shell and executes PowerShell to download, decrypt and execute the ransomware payload.

The generated, executable CHM file only had a detection with one of the fifty-four scanning engines in Virus Total when we tested this dropper method in lab. It would appear that script obfuscation is not required to bypass antivirus defenses for these initial, malicious droppers.

Loader Analysis

The Satan RaaS malware employs a number of anti-analysis techniques in order to prevent automated or manual analysis of a sample. A review of the malware Hash:  b70622bf5192b5a254932451814cc4a1 Version:  1.0.0.13 shows ~20 different checks which are done in order for the malware to continue running and unpack the payload.

Cylance has already done  a great analysis which covers the majority of these techniques, so this report doesn’t review all of them in detail won’t review all of them in detail.

  1. Calls BlockInput to block user interaction with the system
  2. Checks for known AVG modules
  3. Checks for a known Debugger windows using FindWindow
  4. Checks for KernelDebugger

The malware uses an interesting trick where it loads the KdDebuggerEnabled field directly and compare the value.

  1. Check for attached debuggers calling Checks for a debugger calling isDebuggerPresent and CheckRemoteDebuggerPresent
  2. Check for a blacklisted analysis modules by calling the GetModuleHandle
  3. Check for blacklisted analysis Processes by calling FindWindow
  4. Check if the method wine_get_unix_file_name is exported by kernel32.dll to detect the presence of wine
  5. Call NTClose and CloseHandle with Invalid handles as an anti-debugging method.
  6. Create a VEH handler and calls int 3 as an anti-debugging method.
  7. Hooking Check

It checks for possible Jump hooks (0xff, 0x25) or (0xe9) in CreateProcess, DeleteFile, ldrLoadDll & NTQueryInformationProcess functions.

  1. Debugger Check with csrss handle

The process attempts to open a handle to csrss.exe to detect the presence of a debugger. If the request succeeds and a valid handle is opened this can indicate that a debugger is actively running on the system or that the user has sufficient access to debug a system process.

  1. Create top level exception handler and trigger by popping a divide by 0 exception as an anti-debugging technique
  2. Check the OS Version to determine if the sample should run. (No XP support)
  3. Call NTQueryInformationProcess

The sample makes a number of calls to determine if the process is being debugged, by checking the ProcessDebugPort, ProcessDebugObjectHandle & ProcessDebugFlags.

And an additional check for the process devenv.exe the name commonly associated with Visual Studio.

  1. Check for HW BreakPoints

The Process will check for hardware breakpoints by getting the thread context by calling GetThreadContext and then checking the context debug registers.

  1. Check that the filename does not include a blacklisted term
  2. Check that the username doesn’t contain a blacklisted term
  3. Check that the path does not contain a blacklisted term.

Although the loader includes so many anti-analysis techniques they are all contained within a single function call, which makes it easy to bypass all of the techniques with a single hop.


The number of implemented checks and techniques indicate that many of these may have been copied from OSS projects and added to the list of anti-analysis checks. The two main projects with either similar or identical checks are:

  • al-khaser – “PoC malware with good intentions that aims to stress your anti-malware system..”
  • Pafish – “A demonstration tool that employs several techniques to detect sandboxes and virtualization environments..”

For example pulling the list of blacklisted processes, we find the same list within the al-kahser source file process.cpp.

Or the blacklisted user and directory names as found in the pafish project file gensandbox.c:

Additionally, the inclusion of checking for the “devenv.exe” process in relation to checking the ProcessDebug flags can be found to within sample code on anti-debugging and protection techniques. https://www.codeproject.com/Articles/1090943/Anti-Debug-Protection-Techniques-Implementation-an.

Looking at a previous version of the ransomware (v1.0.0.1) we see that the anti-analysis checks have been evolving. Within this older sample (hash) we find several checks for virtualization artifacts that no longer exist within the newer version of the loader.

For example the registry and process checks for virtualization artifacts.


Or the inspection of the physical drive to ensure that the user can obtain an valid handle and that the disk size is > 50G.


The removal of some of these checks could indicate that the author(s) have found some issues with the checks or found them to be ineffective. Since many these anti-analysis checks appear to be copied from OSS projects we can assume that new techniques are likely to be added as the ransomware evolves.

Payload

After the anti-analysis checks are passed, the sample spawns a child process of itself and uses Process Hollowing to write the unpacked executable into the spawned process.

This follows the standard Process Holllowing technique of:

Once the injected process is launched the parent loader process exits.

The injected process then melts a modified version of the loader into the directory:

%appdata%/<generated_dir_name>/<generated_file_name>.exe

and creates an entry within the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run for persistence. In previous versions of the loader this would also include the –t switch, but this option is no long available within the new analyzed version 1.0.0.13.

The malware then executes the melted version which drops and runs a batch script in %temp% to delete the initial loader executable and script files.

Target Files

An initial analysis of the payload shows that over 375 file types are targeted for encryption. Once the file is encrypted it is renamed and the extension is replaced with ‘.stn’

One interesting feature of the payload observed during the initial analysis was the support of a couple of command line switches (-i and -r)

Analyzing the -i path produces a debug window which includes what appears to be the payload version (1.00.13) and the uinque id assigned at the time of download. This Id can be seen within the download ULR of a generated sample satan6dll23napb5[.]onion/malwares/{uniquie_id}

Conclusion

We can see that the Custom Loader used by the ransomware continues to evolve as the author(s) add and remove functionality. As the ransomware uses a custom loader it can be used to identify and cluster samples. This is uncommon with most malware so we would expect that another stage would be added to the execution chain by actors using this:

  • Stage_1 (generic packer) à Stage_2 (custom loader à Stage 3 (payload)

This would make it much more difficult to statically cluster samples as the initial executable file wouldn’t exhibit any identifying characteristics. Searching for both artifacts of the dropper scripts a user can generate on the panel and for other loaders, we have been unable to find evidence that this is being used as a payload within any large scale e-mail campaigns. This may be due to any number of factors:

  • The method being used within the infection vector are using obfuscated versions of the provided .chm and macro droppers or writing custom scripts to be used for infection.
  • This is being used in low volume campaigns targeting primarily home users.
  • Potential operators need to share profits (30%) with the original author(s) and also trust that they would get their cut of ransom for targets.
  • Potential operators need to trust the site operators

Reference

AVG Modules

  • avghookx.dll
  • avghooka.dll

Blacklisted Debug Windows

  • OLLYDBG
  • WinDbgFrameClass
  • Zeta Debugger
  • Rock Debugger
  • ObsidianGUI
  • Blacklisted Modules
  • SbieDll.dll
  • dbghelp.dll
  • snxhk.dll
  • api_log.dll
  • dir_watch.dll
  • vmcheck.dll
  • wpespy.dll
  • pstorec.dll

Blacklisted Process Names

  • ollydbg.exe
  • ProcessHacker.exe
  • tcpview.exe
  • autoruns.exe
  • autorunsc.exe
  • filemon.exe
  • Procmon.exe
  • Procexp.exe
  • idaq.exe
  • idaq64.exe
  • ImmunityDebugger.exe
  • WireShark.exe
  • dumpcap.exe
  • HookExplorer.exe
  • ImportRec.exe
  • PeTools.exe
  • LordPE.exe
  • SysInspector.exe
  • Proc_analyzer.exe
  • sysAnalyzer.exe
  • sniff_hit.exe
  • windbg.exe
  • joeboxcontrol.exe
  • joeboxserver.exe

Name Blacklist

  • sample.exe
  • c:\InsideTM
  • Username Blacklist
  • SANDBOX
  • VIRUS
  • MALWARE
  • MALTEST
  • TEQUILABOOMBOOM
  • Directory Blacklist
  • SAMPLE
  • VIRUS
  • SANDBOX

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 https://www.maxmind.com/geoip/v2.1/city/me with the following custom headers:

  • Referer: ‘https://www.maxmind.com/en/locate-my-ip-address’
  • 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.

“AMAZON”, “ANONYMOUS”, “BITDEFENDER”, “BLUE COAT”, “CISCO SYSTEMS”, “CLOUD”, “DATA CENTER”, “DATACENTER”, “DATACENTRE”, “DEDICATED”, “ESET, SPOL”, “FIREEYE, “FORCEPOINT”, “FORTINET”, “HETZNER”, “HOSTED”, “HOSTING”, “LEASEWEB”, “MICROSOFT”, “NFORCE”, “OVH SAS”, “PROOFPOINT”, “SECURITY”,”SERVER”, “STRONG TECHNOLOGIES”, “TREND MICRO”, “TRUSTWAVE”, “NORTH AMERICA”, “BLACKOAKCOMPUTERS”, “MIMECAST”, “TRENDMICRO”

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

Conclusion

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 StaySafeOnline.org 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.