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.


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:


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: 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.

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.


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:


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

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}


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


AVG Modules

  • avghookx.dll
  • avghooka.dll

Blacklisted Debug Windows

  • 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
  • Directory Blacklist

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.