April 25, 2017 | 10 minute read
Cybereason has discovered another member in the xxmm family of backdoors---ShadowWali. Like the Wali backdoor, ShadowWali also targets Japanese businesses and was built by the xxmm malware toolkit. In fact, the same author can be attributed to both backdoors. ShadowWali is likely an earlier version of Wali, making it Wali's "older brother."
Check out the ServHelper backdoor for more research on backdoors.
In this blog, we'll review the xxmm backdoor family and show the similarities between Wali and ShadowWali. In addition, we will provide new insights regarding the backdoor's post-infection phases.
Wali is a backdoor used for targeted attacks. It gathers information about the compromised machines and their networks, in addition to stealing sensitive information and credentials. Wali’s operators use this information to move laterally in an organization and compromise more machines. There are many similarities between the Wali and ShadowWali:
Evidence suggests that Wali’s author has been developing these backdoors and possibly other malware since 2015.
Same builder: Wali and its sibling backdoor were built using the xxmm builder. (see the section The xxmm builder dissected)
Large inflated executables: Both backdoors have unusually large inflated binaries (ranging between 50,000KB and 200,000KB). This is a tactic used to evade inspection by traditional antivirus software and other security products.
Process injection: Most samples were observed injecting malicious payloads to Internet Explorer. However, ShadowWali was also observed injecting to LSASS.exe process and to explorer.exe.
A main differentiator between Wali and its sibling backdoor is that Wali’s loader comes with both a 32-bit and 64-bit payload, while ShadowWali tends to deliver 32-bit payloads. Another key difference is the style of the process injection technique. Both backdoors use different process injection techniques.
The Wali backdoor emerged in Japan in early 2016. It’s dubbed Wali because of the indicative strings found inside its binaries, as seen in the screenshot of the strings from a decrypted Wali binary (SHA-1: 3603163413A8E4E03758C9FB7673E1866FF29CB5):
One of the consistent characteristics of Wali is the injection of the malicious payloads (either 32-bit or 64-bit) into a host process. As seen in our analysis of the xxmm builder (See the section The xxmm builder dissected), the default host process of choice is Internet Explorer (iexplore.exe). The screenshot below, taken from a real attack attempt on one of our Japanese customers, shows Wali’s loader (srvhost.exe) injecting code into Internet Explorer. Let’s have a look at the injection detected by Cybereason:
Srvhost.exe loader injecting to Internet Explorer. Visual taken from the Cybereason Platform.
Wali injection routine combines implementations of "Reflective DLL injection" along with another injection technique. Wali’s author clearly borrowed code from Stephen Fewer’s famous ReflectiveDLLInjection project found on Github.
Stephen Fewer’s Reflective DLL Injection code on Github:
Excerpt taken from Wali's process injection routine:
However, a few alterations were made to the code to accommodate the 32-bit and 64-bit payload delivery. Following is a simplified flow of the injection routine, with main differences marked in red:
CreateProcessA → OpenProcess → VirtualAllocEx → WriteProcessMemory → GetVersionEx → CreateRemoteThread/NtCreateThreadEx
Since Wali’s author chose to inject to Internet Explorer---a host process that doesn’t necessarily run all the time---Wali first needs to make sure the browser runs, and launches it in a suspended mode (creation flag = CREATE_SUSPENDED):
Next, the loader will allocate two RWX regions in the target process and write the 32-bit and 64-bit payload respectively.
It's interesting to notice the size of the actual injected payloads---At 120KB to 144KB, the actual payloads are tiny compared to the 100MB to 200MB loader that’s inflated with junk code.
During the final step of the injection routine, Wali's loader determines the OS version of the compromised host. If the value of dwMajorVersion is lower than 6 (older than Vista), the loader will call CreateRemoteThread to execute the injected payload:
Otherwise, it will use the rare and undocumented NtCreateThreadEX API to execute the injected code. The motivation behind the version check is most likely to overcome Windows “Session Separation” mitigation introduced in Windows Vista:
Wali uses GET requests over HTTP port 80 to communicate with its C&C servers, which are mostly compromised websites. Most samples have a set of three hard-coded URLs that are decrypted at runtime. Wali will try to reach all three URLs, one after the other, until it receives a response from the server:
After communicating with the C&C server, Wali attempts do the following:
1. Download a payload from the server using the URLDownloadToFileW API:
2. Decrypt the payload:
3. Parse the payload and execute it.
Wali can support different types of payloads from the C&C servers, including: PowerShell commands and additional plugins. Even ShadowWali was delivered by some of compromised C&C servers.
This screenshot was taken from one of subroutines in charge of parsing and executing the payloads, in this case PowerShell commands:
The Wali backdoor was observed downloading two different types of post-infection payloads:
During an investigation, Cybereason analysts noticed that Wali attempted to download the following payload after reaching one of its hard-coded URLs:
Once the payload is downloaded and decrypted in-memory, Wali writes its content to a temporary file:
Sep9808.tmp - 2CE05CD6AF79B10F9EE8CBEBAE8D439FF0F30F60
The temporary file is a binary file in 101MB size:
The file’s timestamp indicates that it was compiled in August 2016:
The downloaded payload performs a similar process injection routine as Wali, namely injecting a malicious code to a new instance of iexplore.exe (memory address 0x140000000):
The plugin executable size is considerably bigger than Wali’s payloads: 896KB as opposed to Wali’s 120KB to 140KB injected payloads.
0x140000000’s SHA-1: 1C822CB9B4AFA82099B8EF2B909204D9D8F4626D
The payload launches a series of reconnaissance commands after it’s executed:
Reconnaissance commands found in the memory of the injected iexplore.exe
Last but not least, the injected code will execute an embedded Mimikatz binary in order to steal locally stored credentials and possibly perform lateral movement.
Our investigation led us to a compromised Japanese site where the attackers uploaded their malicious PHP code and the other xxmm payload (scommand.txt, SHA-1: 52921e7b488ee1a48ca098247a07d17ce610c235).
Similar to the previous C&C payload, the scommand.txt file also contains an encrypted payload:
Scommand.txt SHA-1: 52921e7b488ee1a48ca098247a07d17ce610c235
After Wali uses the hard-coded decryption key to decrypt the payload in memory, it writes the decrypted contents to a .tmp file in %temp% folder. Once the .tmp file is written to disk and executed, it will also create a batch file that will be used for self-deletion:
This self-deletion mechanism is consistent to both backdoors of the "xxmm" family, and is found in the code of its "loadsetup" component:
C:\Users\123\Documents\Visual Studio 2010\Projects\xxmm2\Release\loadSetup.pdb
Downloaded payload details:
File name: rr2E9E.tmp (original name: test.exe)
PDB Path: C:\Users\123\Documents\Visual Studio 2010\Projects\shadowWalker\x64\Release\BypassUacDll.pdb
rr2E9E.tmp binary’s file timestamp is from May 2016:
The resources section of the PE file contains two additional PE files:
102 (32bit payload)- 8123534DDE8AC4AF983DB302A06427AAB00EDD55
105 (64bit payload) - BC725B8FF4446A72539F5C5B0532CC0264A51D9C
ShadowWali is also a member of the xxmm backdoor family, written by the 123 author and can be considered Wali’s older brother. The timestamp of most of the observed backdoor sample dates back to 2015 and continues until mid-2016. Wali’s timestamps, meanwhile, run between 2016 and 2017. This could be viewed as either an older version of Wali or as a separate, older project the 123 author developed.
Although there are many similarities between the two siblings, they are also clear differences:
Strings indicative of the xxmm backdoor family:
Strings indicating the usage of stdapi functions, which are also found in Metasploit's Meterpreter:
|ShadowWali simplified injection routine||Wali’s simplified injection routine|
|CreateProcessA → VirtualAlloc → GetThreadContext → VirtualAllocEx → WriteProcessMemory → SetThreadContext → ResumeThread||CreateProcessA → OpenProcess→ VirtualAllocEx→ WriteProcessMemory→ GetVersionEx → CreateRemoteThread / NtCreateThreadEx|
Example of the last stage of ShadowWali’s process injection, showing SetThreadContext/ResumeThread APIs which are used in that style of "evasive process hollowing:"
Variation in injected host processes
As opposed to Wali’s tendency of injecting to iexplore.exe, ShadowWali seems to exhibit more variation, and we observed it injecting code to explorer.exe and LSASS.exe, as can be seen in the following example:
File Name: SMSvcHost.exe, SHA-1: 168524E2292E376B2036C41E691A434BAC3A89E
In addition to the previously documented persistence mechanism using the classic registry autorun (currentversion\run), some samples showed a different persistence mechanism that is based on Windows Service as autorun, as can be seen below:
File: C:\Program Files\Common Files\System\reginie.exe
While analyzing the C&C communication of ShadowWali, it was noticed that some of the compromised sites served image files with hidden code inside them:
The image files all had one thing in common; at the end of the file, there was an appended section containing the encrypted payload. The section begins with “###RRRR” and ends with “ZZZZ###:"
When the image is downloaded, ShadowWali will search for those start-end markers , and once found, it will decrypt the payload between them. The decrypted payload results in a new URL, leading to another domain:
This is consistent with the built-in “changeURL” functionality found in the sample’s binary:
Cybereason managed to obtain a copy of the xxmm builder, the tool with which the malware author "123" generated the xxmm family backdoors:
File Name: xxmm2_build.exe
Fun fact: The icon of the “xxmm builder” was taken from “Batman: The Dark Knight Rises.”
The builder is written in C++ and was compiled in January 2015, which is consistent with the appearance of ShadowWali and the timestamps found in the samples’ executables.
The builder is part of the xxmm2 project and was also generated on user 123's machine, as indicated in the PDB path:
As seen in the builder’s main menu dialog, the builder consists of three steps to generate the backdoors:
Although the word "kernel" suggests rootkit capabilities, the xxmm backdoor family operates in user-mode and was not observed implementing kernel-related rootkit capabilities.
This step is mainly used for:
This explains the previous observations of steganography using “.jpg” images. In addition, it clarifies another observation Cybereason made regarding the compromised websites which are written in PHP. Looking at the PHP Tunnel feature, this makes perfect sense:
This step handles the following components of the malware:
The final step in the trojan generation handles configuration of both 32-bit and 64-bit payloads, as well as the auto-deletion code (loadSetup).
The name “ShadowWalker1.0” appears at the third step of the builder, and populates the “Destination File Path” field. The same name is found in the PDB path of some of ShadowWali's samples. For example:
rr2E9E.tmp - 133C7B74E35D9DCC3BD43764CB18E59C1B74190F
The ShadowWalker1.0 rootkit was a proof-of-concept rootkit introduced by Sparks and Butler at Black Hat Japan in 2005. The code is now open source and can be found on Github. ShadowWalker1.0's rootkit functionality was not observed in any of the xxmm family backdoors.
It is not completely clear why the xxmm builder references the ShadowWalker rootkit. However, the builder's menu clearly indicates that it can support rootkit modules (probably optional). These indications are found in step 1 and 2 of the builder, with indicative names such as: "kernel module" and "Kernel template".
The xxmm backdoor family has been attacking Japanese targets since 2015. The backdoor family consists of two main backdoors and additional post-infection plugins used for reconnaissance, credential dumping and possibly lateral movement. In this research, we have presented the similarities and differences between Wali and ShadowWali and proven that they have one father, the 123 author. Whether it’s a case of two different backdoors or an evolution of one malware over two years is a matter of interpretation. To date, Wali and ShadowWali are still actively targeting Japanese organizations.
The identity of the 123 author remains unknown. However, there are indications that suggest that the threat actor behind Wali resides in Asia. From profiling perspective, the evidence show that the 123 author has a penchant for adapting and customizing previously introduced techniques and tools, such as the reflective loader, Metasploit modules and even the builder itself could be adapted from other builders.
Compared to other modern backdoors, the xxmm backdoor family doesn’t stand out or seem very sophisticated. However, the backdoors are proven to be effective as they successfully infected dozens of endpoints over two years, while evading traditional security products. The backdoors’ strongest feature is the inflated file sizes that can reach 200MB. The motivation behind the inflated files probably stems from the author's perception that certain security solutions might not inspect large files, which will then allow the inflated files to evade detection.
*Domains and IPs will be discussed in part two of the blog.
Assaf Dahan is Director of Advanced Security Services at Cybereason Japan.