Updated 19 July with Attribution Comments
Recently, Palo Alto’s Unit42 and Saudi NCSC detailed multiple intrusions against Middle Eastern government targets in which an attacker (purportedly Emissary Panda, a suspected Chinese state-sponsored adversary) compromised vulnerable Microsoft SharePoint servers and deployed a variety of intrusion tools, both public and custom.** Subsequent public reporting, however, attributed a portion of this activity to the Turla group. This post focuses on the details of the malware rather than the attribution itself.
This blog post briefly documents characteristics and capabilities of one such tool, an HTTP listener (first identified by NCSC-SA), deployed at several of these sites. There are multiple versions of this listener with different command names; however, the functionality of each command is the same in each file.
**Note: As noted in the original version of this post, Unit42 reporting did not definitively state that the activity belongs to a single threat actor given the use of publicly available tools but rather offered this as a possible assessment.
HTTP Listener Capabilities
MD5: 687d7ddb080fb769b26a0c054f4cd422
SHA1: 3227e0b8181f05e393be41d633b08da07fadf194
SHA256: 66893ab83a7d4e298720da28cd2ea4a860371ae938cdd86035ce920b933c9d85
(Note: This blog opted to analyze this file due to being the one with the closest static properties – including class names and the listening port – to the file described by NCSC-SA).
The file is designed to run as a service with the name WSMPRV and a display name of “WSMan Provider Service.” As described in the NCSC-SA report, the file accepts requests sent to localhost:80/WSMAN:
The primary functionality of the malware is held within a namespace named WSMProvider.WsmSvc.Commands. There are seven classes within this namespace that can be thought of as “commands:”
– GetAuthCookie (read the bytes of a file)
– GetAuthCookieResponse
– GetProviderConfig (execute cmd.exe command, with “c:\windows\temp” as the working directory)
– GetProviderConfigResponse
– ItemMarker (encrypt/decrypt data)
– ProviderData (write bytes to a file)
– ProviderDataResponse
With the exception of ItemMarker, which encrypts and decrypts data and parameters, these classes each operate in pairs. The “response” class in each pair is used as a structure for the return value of its calling class. For example, when reading the contents of a file, the malware:
1) Passes two parameter values, “downloadPath” and “password,” to the ItemMarker class
2) ItemMarker encrypts the “downloadPath” using the “password” as a key and converts this data to Base64
3) Creates a new “getAuthCookieResponse” class using this encrypted value
4) Decrypts these encrypted values into a byte array
5) Converts this byte array into a string
6) Treats the string as a file location and checks if a file exists at this location
7) Returns an error if the file does not exist
8) Reads the contents of the file into a byte array if the file does exist
9) Encrypts this byte array, converts this data to Base64, and places the contents into a string, “Cookie,” within the getAuthCookieReponse class
The contents of the getAuthCookieResponse are then returned at the end of the function. The code for this workflow can be seen below:
The workflows for executing arbitrary commands and uploading files are similar, with the “ItemMarker” class being used to encrypt/decrypt parameters and data. For commands, the console response of the command is encrypted and returned to the operator. For writing files to the victim’s device, the phrase “uploaded” or “not uploaded” is encrypted and returned.
Additional Thoughts
The backdoor in question is relatively lightweight- it only supports three basic functions (inbound file transfer, outbound file transfer, command execution) and contains no obfuscation. On the other hand, the authors took care to give the classes and functions plausible sounding names, and the backdoor could easily be mistaken for a legitimate application.
One possibility is that the file is intended to be used as a long-term entry point onto the network, with “noisier” files being used on other endpoints where detection is less of a concern. This would align with characteristics of the Unit42 and NCSC-SA reporting, although this is merely conjecture given the lack of publicly available specific incident response data at this time.