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.

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

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

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

13. Create top level exception handler and trigger by popping a divide by 0 exception as an anti-debugging technique
14. Check the OS Version to determine if the sample should run. (No XP support)
15. 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.

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

17. Check that the filename does not include a blacklisted term
18. Check that the username doesn’t contain a blacklisted term
19. 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:

• Opening a suspended Process calling CreateProcess() with the CREATE_SUSPENDED flag
• Call NtUnmapViewOfSection to unmap the virtual address space
• Call VirtualAlloc to re-allocate memory in the launched process
• Call NtWriteVirtualMemory to write the embedded data
• Call SetThreadContext and ResumeThread to execute the injected code

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 HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun 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