Asia Under Major RAT Attack

SentinelOne last week announced that it has detected a technique being used in Asia to infect systems with remote access Trojans that ensures that the payload remains in memory throughout its execution and doesn't touch the victim's computer disk in an unencrypted state.

http://www.technewsworld.com/story/83425.html?rss=1

 

Interesting, so it seems to be using both RMI and process hollowing, if I understood correctly.

 

Yes, this puppy is especially nasty in how it operates:

The main binary is a packed .NET DLL bearing the name "Benchmark."

When run, it copies itself to %APPDATA%\Microsoft\Blend\14.0\FeedCache\nvSCPAPISrv.exe and extracts a second binary named "PerfWatson.exe." It then executes both binaries from memory.

A registry key is created at HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load for persistence. That points to the PerfWatson.exe binary.

The main executable in the Benchmark .NET DLL contains an XOR-encrypted .NET DLL in its .NET managed resources, as well as the logic to unpack and inject the RAT and monitor the PerfWatson.exe.

The settings for Benchmark and the NanoCore remote administration tool contained in the malware are serialized, DES encrypted, spliced and stored across multiple PNG files as pixel data, SentinelOne found. The PNG files are concatenated and stored in the main executable's .NET managed resources.

Once the encrypted DLL is decrypted, it's linked into the process using System.Reflection.Assembly.Load(byte[]). That ensures that the DLL will be retained in memory and not written to the filesystem.

The set options are then executed, and the NanoCore payload is injected into a new child process.
​

The malware dropper is a .Net dll that runs the binaries directly from memory. It also stores a link to the to the binaries in a registry run key not normally protected by HIPS's.

What the article doesn't state is where the .Net "Benchmark" dll is being downloaded to and run from but appears to be .Net.

Here's a link to the detailed analysis of it by Sentinel One: https://www.sentinelone.com/blogs/teaching-an-old-rat-new-tricks/

 

Cisco did an analysis on NanoCore earlier this year: http://www.neutralizethreat.com/2016/01/nanocore-and-unpacking-autoit-cryptor.html. AutoIT was employed in that instance and I strongly suspect it was also used in this recent attack:

The binary is a compiled AutoIT script.

After decrypting the binary, the output is stored in the variable, $IYbCRVbDeUHJTTHJE

If we check the script further, we observe that in the function, IYbCRVbDeUHJTTHJEMdEYcJgQWLc() it checks the value of a preconfigured variable, $IYbCRVbDeUHJTTH. Based on the value of this variable, it performs the following operations:

1. Executes the code using wscript.exe
2. Injects the code into %windir%\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe
3. Injects the code into %windir%\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe
​

So monitoring of wscript.exe and RegAsm.exe execution might alert you to the Nanocore payload.

Ref.:http://www.codeproject.com/Articles/79314/How-to-call-a-NET-DLL-from-a-VBScript