LMNTRIX researchers recently discovered files containing what is believed to be a remote backdoor trojan with .NET API functionalities. Dubbed “Special Ear” by LMNTRIX, the executable was disguised to represent a purchase order, a now common ploy used to trick people into opening malicious files.
The weaponised attachments were sent out in a spam campaign, primarily targeting organisations in India, Saudi Arabia and nations throughout South-East Asia. The IP address (80.209.253.2) from which the campaign was launched is clearly categorized as spam and appears to have a Dutch origin (see below). Despite this, LMNTRIX researchers are confident the campaign originates from China – more information on this is further below.
Below we see one of the spam emails accompanying the malicious attachment – this was sent to a Saudi organisation from an email address with the “.com.sa” Top Level Domain:
Another spam email from the campaign is below – in this example, an Indian firm was targeted from an email address with a “.co.in” Top Level Domain. This customisation shows a level of sophistication as the attackers are attempting to give the emails a sense of legitimacy:
The malware itself is a generic Trojan:MSIL variant, a class which dates back to around 2010. As such, 51 of 66 antivirus engines were able to detect the malware in the file.
While the majority of engines detected them as Win32:Malware-gen, several identified them as Gen:Variant.Razy.229008, an alias for Trojan/MSIL-KSS.
MSIL payloads are often used to log keystrokes to steal personal credentials for online banking, social media and email. The trojan then sends this information to a remote machine.
In this case, a cluster of samples were found to use the .NET API to obfuscate the control flow of the malware. The use of Chinese characters makes it harder to analyze the malware code, and they appear to be random phrases. One of them translates to “special ear”, while others translate to “boom”, “squat” and more random words and phrases.
On analysis, the first call was to an oddly named class function, and the functions themselves appear to be randomly generated, most likely as hash busters to change the data’s hash sum.
Further analysis reveals more interesting functions. For example, this one:
We can assume the use of this function by looking at the parameters. The first call uses the System.Threading.Thread and Sleep arguments, followed by the System.Reflection.Assembly and GetExecutingAssembly arguments. We found that both System.Threading and System.Reflection are .NET framework classes found in the MSDN database.
Since this warrants a deeper look, we step into the function itself to find out more.
The function clearly takes four arguments, so we wanted to find out what it used them for. Once again, these arguments seem to be randomly generated in order to obfuscate the malware code. The first one, which was the .NET framework class name, is used to populate the type variable, which returns its type. This type variable is then used to populate all the methods in the class.
The next is a loop that loops through its method list and checks if that’s the one it wants to invoke. That is, the Sleep and GetExecutingAssembly arguments. Now we went back to the MSDN library to see if both these functions belonged to the classes mentioned and, not surprisingly, they were.
That means the function is used to obfuscate API calls using a simple method:
Create Class objects for .Net framework classes –> Get Type –> Populate all the methods –> Iterate through them –> match the function to be used –> call the function using Invoke().
This same method was also found in other files, with some differences.
Mitigation and prevention:
Excessive function calls to Type and Getmethod functions seem odd, and should be flagged at runtime. However, this should not be the lone detection strategy; it can be clubbed with an entropy check for the files.
On 2018-07-07
