On 6 May 2019, Symantec published reporting on a series of tools possibly used by APT3 (or a broader China-based espionage apparatus), including a previously publicly unreported backdoor dubbed “Filesnfer.”* Several hashes were made available for this malware, including one for a variant written in C++, one for a variant written in Python (compiled via Py2Exe), and one purportedly written in PowerShell.
The hash for the PowerShell file is unavailable on VirusTotal; however, analysis of the Python code can be used to identify a different file uploaded to the Hybrid Analysis platform that is delivered via a PowerShell loader, written in C#, and contains significant code-level and unique-string overlaps with the Python variant. This file was also not made available for download on the platform, but the strings for the loaded C# code in this sandbox run are enough to find an additional sample of the entire decompiled code on VirusTotal.
This blog contains a brief technical overview of each of these variants, and the pivoting method described. If you’re just here for the C# (“PowerShell”) hash: 8de3b2eac3fa25e2cf9042d1b952f0d9. For analysis of these files, keep reading.
* (Symantec notes that the connection between this backdoor and APT3 was provided to them through collaboration with another vendor).
As Symantec notes, this file is a compiled Python executable built using Py2Exe. The python-exe-unpacker available on Github can be used to partially decompile the code, although it did encounter an error during this analysis that prevented a full dump from being created:
Despite this limitation, it’s still possible to infer some of the functionality and, as described above, identify a complete dump of the C# version through additional pivoting. The Python code defines several classes including:
In addition, the following functions are defined:
– print_log(xtype, pstr, btime=True)
– Recv(sock, size, timeout=3, bLoop=True)
– SendPacket(sock, buf)
– RecvPacket(sock, size=0)
– PutFileData(pSocket, sourceFile, Length, types=0, lLen=0, Speeds=10485760, bZip=True)
– GetFileData(gSocket, destFile, Length, types, lLen, bZip=True)
– SendDirList(sock, filepath)
– ServerX(host, port)
– handler(signum, frame)
Of these, ServerLoopPro failed to decompile. The rest of the available code can be used to determine the intent and functionality of this section, however. On execution, the “main” block of the code defines variables that call the Monitor, Timer, and LoadCert classes, which set a backconnect Boolean to “True,” initiates a “timer” interval, and defines a certificate and key respectively.
The malware then performs a series of checks on any supplied parameters to make sure that they are properly formatted. The code then calls the “ServerX” function if a host and port have been specified.
ServerX and ServerLoopPro
The ServerX function operates as the second “parent” routine within the decompiled code. ServerX will read a specified host and port and attempt to open a socket connection to this location (using the certificate and key defined earlier). From here, it creates a thread for the ServerLoopPro function.
ServerLoopPro did not properly decompile during this analysis, but the code provided offers insight into the functionality. The code references several “orders” that are compared to integer constants. If these conditions are not met, the code jumps to a different location, often performing a similar comparison against a different value. In addition, there are several references to the functions defined above, such as PutFileData and GetFileData:
A likely inferences is that these functions are part of a command structure contained within the ServerLoopPro routine. Thus, analyzing these functions lends insight into the likely commands available to the attackers. PutFileData and GetFileData read and write content to and from the infected device. SendDirList enumerates the contents of a specified directory back to the attacker:
As noted above, the hash Symantec provided for the “PowerShell” version of this tool is not available on VirusTotal; however, searching for the unique function strings ServerLoopPro and ServerX leads to a Hybrid Analysis sandbox report containing a likely variant.
Although the file is not available for download, analysis of the strings in memory suggests an encrypted payload delivered via a PowerShell file (that also opens a firewall exception). In addition, the malware launches “csc.exe,” the legitimate Microsoft C# compiler, and appears to compile and run a file with this tool. Analysis of the C# code in the sandbox report reveals the similar function names as well as the suspected “order” commands:
A VirusTotal content search on these unique strings reveals a nearly identical C# file (8de3b2eac3fa25e2cf9042d1b952f0d9). Much like the Python variant, the C# variant defines several similar structures and classes at the start:
In some cases, the code overlaps are almost identical:
As a whole, the C# variant functions in largely the same fashion, with some slight differences. The “Main” routine only requires a listening port (in this case, port 47000) to pass to ServerX (interestingly, the entire file is also held within a class named “xserver”). ServerX can allow the malware to act as a proxy in addition to calling ServerLoopPro; in turn, ServerLoopPro can receive “order” (just as inferred in the Python sample). Several of these orders are commented by the malware author, and include the following (largely self-explanatory) options:
– read interval
– set interval
– change dir
– process list
Symantec’s article notes that the Filesnfer backdoor was observed by a undisclosed additional vendor, and that corroborating analysis tying it to the APT3 threat actor is unavailable at this time; as such, this blog post is only intended to highlight the functionality of this backdoor (and identify a publicly available variant of the C#/PowerShell version). Regardless of the operator, the backdoor is capable of providing several basic but important capabilities, including file transfers, command execution, and basic reconnaissance.