Prelude to Ransomware: SystemBC

In late February 2021, WithSecure’s Managed Detection and Response (MDR) service identified the execution of SystemBC malware as part of a hands on keyboard crimeware intrusion. The intrusion was stopped before the threat actor could reach their objective, but in recent reporting the use of this malware has been tied to Ransomware activity. WithSecure was also able to identify another recent intrusion conducted by the threat actor where they had deployed Ryuk ransomware.

WithSecure’s analysis of the SystemBC sample identified that this was a new variant of the malware, with several notable differences from previous versions. The sample was executed by a previously undocumented “wrapper”, which WithSecure’s research suggests has been used in combination with multiple malware families common in crimeware intrusions.

This blog shall provide insight in to both the intrusion and the malware sample, so that organizations can be informed to protect themselves from this evolving threat. A detection section is included, which contains actionable takeaways so that organizations can improve their own defenses against this, and similar, threats.

The intrusion began in a third-party IT service provider, which had an un-patched VPN appliance that was vulnerable to remote exploitation. The threat actor was able to extract credentials from this device and then access a host with connectivity to the victim network. The threat actor entered the victim network via a Remote Desktop Protocol (RDP) connection using stolen credentials of an administrator account belonging to that third-party IT service provider.

Figure 1: Initial Access Attack Path

Once the RDP session had connected the threat actor immediately began to enumerate the victim domain and network. With an interactive PowerShell session they used the Windows utilities like net.exe, ping.exe and nltest.exe.

 Figure 2: Enumeration Command Lines

Shortly after this they scanned the network using a portable version of Advanced IP Scanner, a tool popular in crimeware circles. The scanner was used to sweep multiple sub-networks for normal service ports and dynamic ranges.

Figure 3: Advanced IP Scanner Path

The scanner was downloaded from the software provider’s website via internet explorer and executed with explorer.exe. WithSecure’s investigation uncovered a forensic artifact that suggests the threat actor was watching a YouTube video on how to use this tool prior to execution.

After initial reconnaissance, the adversary executed a Base64 encoded PowerShell command. The decoded command is included below.

Figure 4: Decoded PowerShell Command

The command is associated with the PowerShell Empire framework and disables ScriptBlock logging and AMSI before connecting out to an external Command and Control (C2) server. The threat actor was using the default version of PowerShell Empire with the following C2 and UserAgent:

Figure 5: PSE C2 & User Agent

After establishing C2 communication through PowerShell Empire and conducting additional reconnaissance, the actor disabled Windows Defender with multiple registry changes using reg.exe.

Figure 6: "reg.exe" Command Lines

Immediately after Windows Defender was disabled the actor downloaded an archive from “sendspace[.]com” – an online file sharing platform.

Figure 7: Malicious Archive URL

Once extracted from the archive then the file “Svchost.exe” (2dc93817039e6fa4fae014e1386cffa7ac35b89feac59d8abe7f51be1c089580) was executed. WithSecure’s analysis shows this file is a new variant of the SystemBC malware family. Full analysis of the malware is included later in this post.  

 Figure 8: SystemBC Download

With multiple routes of access established to the network the threat actor then downloaded another archive, from the same domain, containing four additional files.

Figure 9: Additional Malicious Archive URL

The files downloaded were stored on a share that was mapped for all hosts on the victim network.

Figure 10: Archive Contents

The first file of interest, servers0.bat, was a batch file that contained a long list of commands to execute the “1.ps1” PowerShell script on multiple hosts using PsExec.exe.

Figure 11: Truncated Contents of "servers0.bat"

The PowerShell script “1.ps1” would attempt to create a dump of the LSASS process using rundll32.exe in combination with comsvcs.dll. If successful the threat actor would look to extract any credentials stored in the memory of this process using tools such as Mimiktaz.

Figure 12: Contents of "1.ps1"

In addition, the threat actor deployed a PowerShell script named “a.ps1” that had the capability to further enumerate hosts across the network. Interestingly the file still had the hostname and domain from a previous intrusion of another victim by the group, which allowed WithSecure to notify that victim of the activity. WithSecure did not see any evidence of the execution of this script despite its creation on victim systems by the threat actor.

Figure 13: Contents of "a.ps1"

The actor was not able to execute any further malicious commands as containment was actioned by the WithSecure MDR service and the victim organization.

File Name: svchost.exe

SHA1: f8af1b293aecdb3d1fe038b4b638f283ee852287

MD5: fa93cfe0898c704551cefdfa193d406f

SHA256: 2dc93817039e6fa4fae014e1386cffa7ac35b89feac59d8abe7f51be1c089580

Path: C:\Users\Public\svchost.exe

Execution Command Line: C:\Users\Public\svchost.exe start

The “svchost.exe” binary is a wrapper that contains an encrypted SystemBC payload. When the wrapper executes, it decrypts the payload and injects it into the memory of a child process. The technique used is commonly known as process hollowing.

All the key APIs of wrapper are resolved at runtime. After the resolution routine, it creates a new process using its own command line. A new child process is then created out of the wrapper disk image.

Figure 14: Process Command Line

The child is launched as suspended, this is done to allow subsequent process injection into the new child process. The wrapper uses NtUnmapViewOfSection to empty the target process memory.

Figure 15: NtUnmapViewOfSection Code

0x7000 bytes of new memory is allocated into the child process with VirtualAllocEx at offset 0x400000 and the permissions of the section are set to PAGE_EXECUTE_READWRITE with flprotect = 0x40. The SystemBC backdoor is then decrypted and injected into the new memory space with WriteProcessMemory.

Figure 16: WriteProcessMemory Code

After the required code is injected, the wrapper finally sets the main thread context in the child to point to the correct entry point 0x1000 and calls ResumeThread on the child process. The use of process hollowing ensures the unpacked malicious code is only visible in the process memory and not the on-disk version of the file.

Figure 17: Wrapper Execution Flow

Pivoting from the debug string found in the wrapper “y:\test4\e93\Debug\e93.pdb” we can see multiple other samples, with other payloads such as Bazar Loader. The earliest observed malware sample in WithSecure's telemetry dates back to December 2019. There were over 300 samples in total that contain a similar PDB path and appear to be the same wrapper. The table below includes a selected few examples.

The PDB paths suggest a single environment is used to compile the malware. This is likely linked to a single malware developer or team. Artifacts within the binaries suggest that the author is Russian speaking, which aligns with WithSecure's knowledge of the wider crimeware actor who conducted the intrusion.

As reported by Sophos, SystemBC is known as an “off-the-shelf” piece of malware, which is bundled with a TOR client to phone home via the TOR network. In an even earlier version, found by Proofpoint in 2019, the malware was using a SOCKS5 proxy. The SystemBC payload analyzed by WithSecure shares a number of key capabilities with the previously reported samples.

At the first time executing it will create a scheduled task for persistence via a COM interface (CLSID: 148BD52A-A2AB-11CE-B11F-00AA00530503). The scheduled task is created from the wrapper image, named “wow64”, given the “start” argument and scheduled to run every two minutes after the first execution at current time. The CLSID is located in the .data section starting at 0x50C3.

The malware executes files received from the C2 after writing the files out to %TEMP%.  It supports execution of EXE, VBS, BAT, CMD and PS1 file types.

Figure 18: C2 Identification Routine

PS1 files will be executed with PowerShell using  the parameters “-WindowStyle Hidden -ep bypass –file” and the payload, which is identical to the other public samples analyzed by security researchers. Other file types will be executed via a scheduled task, the same COM interface that is used for its own persistence.

Figure 19: Execution Flow

When the SystemBC payload WithSecure analyzed is executed, it will search and create a mutex “wow64”. Then it calls sub_402985 to check if the passed command line argument equals to “start”. If the mutex was not found and the file was executed with “start”, it will continue to the sub_401549 to execute the C2 commands.

Figure 20: Initialization Function (New Version)

In the older version of SystemBC, the name of the process will be used as a mutex.  The initialization is fairly similar to the new sample with few differences. The old sample will attempt to find the a2guard.exe process, which is linked to an anti-virus product belonging to Emisoft. If the process is found the sample will exit without establishing a persistence. If start argument is missing, the file will be copied into a random directory under ProgramData.  

Figure 21: Initialization Function (Old Version)

In both samples, if the “start” argument is missing, a scheduled task will be created from the disk image with “start” argument.

Before SystemBC calls the C2 server, it will collect some basic information from the host.

• Username
• The Windows build number for the infected system
• A WOW process check (32-bit or 64-bit detection)
• The volume serial number

Figure 22: RtlGetVersion and IsWow64Process APIs Runtime Resolution (New Version)

In the older version, which has TOR capabilities, the sample is implementing a small TOR client that according to Sophos is likely a C implementation of the open source mini-tor written in C++. The C2 communications are then routed via TOR.

Figure 23: C2 Code (Old Version)

In the newer sample, it is lacking the TOR client code completely and the C2 communications are implemented with sockets over IPV4 TCP protocol and non-standard ports. The XOR routine is called to decrypt the required port number from the .data section inside the binary.

Figure 24: Call WSAStartup and Decrypt Port Number (New Version)

The malware then continues with the C2 connection, decrypting the IP-address with the same XOR function as well as building the required parameters to make a network connection.

Figure 25: C2 IP Decryption & Socket Creation (New Version)

Interestingly throughout the old and new samples, the XOR decryption function at offset 0x2C07 is called multiple times for different strings loaded from the memory of the process. The decryption function is looking at the boundaries of the start of the decryption key and the end of the encrypted data section to determine whether a passed string is located inside it and requires decryption or not.

Figure 26: Decryptor Function

This could suggest that there is support for further obfuscation in SystemBC by encrypting more of the plaintext strings. The XOR decryption key used is 40 bytes long and located at the beginning of a .data section at 0x5000. The C2 details are located immediately after the key.

This kind of XOR function and the configuration have been observed in even older samples from 2019.  The new sample analyzed is very similar to previously observed samples in terms of capability, but as discussed above has a different implementation for initialization and C2. The earliest sample of this SystemBC version was observed at the beginning of January 2021.

The below table contains the offensive techniques mentioned within this report mapped to open source detection framework Sigma. This framework allows the conversion of detection logic in to many formats for use across a wide range of industry detection tooling. A fidelity rating is included within the rules to provide guidance on how to implement these rules within internal scoring and alerting systems.

n.b. - The fidelity rating may vary dependant on the specifics of your environment