Friday, May 12, 2017

Revisiting HWorm and NjRAT

Recently I came across the two vbs based RATs found together on the same USB device. Plus I was able to extract IOCs linked to these RATs from analysis of a binary masquerading as a word file, which I will discuss later.

While I know the original threat actors behind the RATs are not active. However, it would be trivial to use their code base by any other threat actor to achieve their objectives of getting an initial foothold in the network and to use this HTTP based backdoor to gather info and pivot further into the network. It is just replacing the host and/or port combo in the code and understanding how the C2 protocol works and there you have the RAT working for you.



--------------------------------------------------G.T.R.vbs Analysis (H-worm aka Jenxcus)--------------------

Obfuscated Script, so I put a BP on ExecuteGlobal. https://www.gwmicro.com/Support/Knowledge_Base/?kbnumber=GWKB2035
ExecuteGlobal is nothing more than a VBScript statement saying, "Do the stuff inside this string,"



Unobfuscated script:



Some background on “Houdini” guy, who seem to be behind this H-worm / NjRAT:

The guy seemed to be based in Algeria and was linked to njq8 (NjRAT through shared code base) (maybe same person…). An article dated June 2014 by Gary Warner sheds some more light on the TAs behind these two RATs:


Interesting chain of events in the saga following these RATs being discovered hosted on no-ip dynamic DNS hosting service:



IOCs:
host = "ody.no-ip.biz"
port = 88
The domain is no more registered and VT tells us a pretty old passive DNS entry dated 2014 for this domain:


Commodity RAT



We can see where the persistence will be created in the startup folder and a copy will be dropped in the temp folder:


Following is a very interesting way to find if the g.t.r.vbs is running from root of drive (e.g H:\g.t.r.vbs or I:\g.t.r.vbs etc..) or from some other folders. If it is running from root of USB then it sets the “usbspreading” as true and store it along with current date in the registry. This is to keep record of whether the infection happened from USB or not:


The reg key created:


Proceeding to create persistence but without copying the script in the temp folder (bad coding practice for RAT authors ;))



While the script executes, it also tries to open itself as a text file to append something to it. If this fails, the script execution stops. This is to check whether


Next it checks whether any USB is connected and it enumerates information like drive letter, free space etc and eventually  copying the file to root level of the drive and setting file attributes as hidden and system files:





The following code then iterates through all the files in the root of the drive path and if they are not lnk files then hides them by changing their attributes to hidden and system and proceeds to create shortcut (lnk) files with the same name as file which is hidden. For e.g if a.doc exists on the root of the drive path then a.doc will be made hidden and system file and instead a.lnk file will be created. We can also see that the targetpath is set to cmd.exe, indicating that when someone clicks on the lnk file thinking of it as their original file, then they will execute cmd.exe with the following parameters:

"/c start G.T.R.2.vbs&start a.doc&exit


The URL:

When the HTTP request is being created, following user-agent is formulated, where a unique id, computer name, OS version, AV information and current date is sent across as “user-agent” header.


Next it gets the volume serial number of the disks:



Concatenating some more info like the disk volumeserialnumber, computername, username, osinfo.caption, “plus” string, security and usbspreading.. we have seen usbspreading where it shows whether the infection is through a USB or not.
Let us look at what security information is retrieved:

Getting OS version and AV info:


Once the request is sent to the C2 server, the responsetext from the C2 is stored in “post”


Next, when the response comes, the response is parsed and the RAT looks for following commands


Let us look at each command one by one:
The response is splitted by a delimeter “<|>” the first item cmd(0) is the command (one of the above) and the second item after splitter is supposed to be the payload for the command namely: cmd(1)
Execute:
This command seems to call a function call “execute” and possibly run that command. However, strangely this function/sub was nowhere to be found in the decrypted vbs body.
Update:
This commands seem to put the text contained in cmd(1) into a textfile (script) and run it with wscript.exe //B. The sent payload of the script is the mechanism for updating the RAT

Uninstall:
We can see the script uninstall itself by removing the persistence mechanism in registry, deleting its presence in %appdata% and %startup%, changing back the attributes of files and folders to visible, deleting itself and quitting the process:


Send:
Here we can see cmd(1) and cmd(2) passed on by C2 server, which are parameters passed on to download sub. Here we can see that a POST request is sent to the C2 with URI containing /is-sending concatenated by the splitter and the url of the file, which needs to be downloaded. This means that any other malicious files/tools/utilities can be downloaded by the RAT as instructed by C2 and save it in the installdir. At the end it checks if the file exists (has been downloaded), it is executed using shellobj.run


Site-send:
This command also parses two parameters cmd(1) and cmd(2) for sub call “sitedownloader”. Here we see it is the same functionality as above. Downloading a file from a url and executing it:


Recv:

Here we see a fileurl is passed on in cmd(1) and passed as a parameter to upload function. This fileurl might have the path to the file which contains data to be exfiltrated. In this function we can see that the .type=1 means there is a binary file which is involved. Secondly we see that the fileurl is being loaded into the stream object.


Thirdly we see that the .read method is used to read the binary file (fileurl passed from C2 server) in a buffer variable. Then we see POST request is sent to the host with URI containing “/is-recving” along with splitter and filename with path (fileurl) and the binary data in buffer variable is sent across.



Enum-driver:

In this command the result of function call “enumdriver” is posted to the C2 server.


The enumdriver basically iterates through all drives and gets and concatenates the drive path with a splitter in between.

Enum-faf:
Cmd(1) is parsed and following is POSTED to the C2:

“is-enum-faf” concatenated with output of function call enumfaf(cmd(1)). This function just enumerates fnf (files and sub folders) in the path sent across by the C2 server


Enum-process:
In this command we see that string “is-enum-process” is concatenated with output of function call enumprocess and POSTED to the C2 server. We can see WMI query called and passing back list of running processes (name, process id and executable path) to the C2 server:


Cmd-shell:
In this command the string “is-cmd-shell” is concatenated with output of function call cmdshell(cmd(1)), whereby cmd1 is coming from C2 server. This is then POSTED to the C2 server. We can see the environment variable %compspec% is used to get hold of cmd.exe and running that with /c switch and “cmd” (the command to run sent from C2). The output stdout or stderr or null is passed back to the function. So C2 can run and get output of any shell command:


Delete:

This command simply calls the function deletefaf(cmd(1)). Whatever file/folder name is sent from C2 it is simply deleted. This could be used by RAT to remove its footprints or to cause havoc by deleting important files/folders:


Exit-process:
This command is used to kill a particular process using its process id, which is sent across from C2, most probably after enumerating running processes and trying to kill something which C2 doesn’t like:


Sleep:

Straightforward will put the scripting engine running the script to sleep for given amount of time sent by C2



-------------------------------------------------NjRAT (Servieca.vbs)----------------------------------------------

Ref: https://www.fireeye.com/blog/threat-research/2013/08/njw0rm-brother-from-the-same-mother.html

The profiling info exfiltrated as User-Agent header, including drive volume ID, Domain/Hostname, Username, OS version, "0.3" is static, y/n depending upon if the infection happened from a USB or not, processID.
We can see HTTP POST to C2 jn(dot)redirectme(dot)net:7777



What I see on top of the script (non-obfuscated) is linked to the Hworm script as both threat actors seemed to have collaborated. With a few minor difference, the code is not same but similar. And both are proud to put their signature on top of their code:


Coded by njq8, who is the Kuwaiti friend of the Algerian guy (see references above). So what this means is that both of them could have collaborated in the past to deliver the malicious their RATs and once they infect an endpoint the endpoint is infecting the USBs for spreading. The possibility of finding both RATs on the same USB indicates this and shows the proximity of the two threat actors.
Immediately we see some IOCs.

Host: jn(dot)redirectme(dot)net  and port=7777




The code then checks whether it has been installed previously by looking for HKCU\njq8. If it is not there then it checks whether the script is running from the root of a drive (USB) or not and accordingly set the registry key to “y” or “n” at HKCU\njq8 in registry.


Copying the script to temp file


Next it maintains persistence by adding itself to run registry keys and getting handle to startup folder (0x7h) is startup folder.



Next it iterates through drives and like the Hworm the njRAT also infects the USB and creates lnk files in the USB and change attributes of original files/folders to hidden/system file.


Then it tries to enumerate domain, username, computername, drive volumne no to be sent across as part of the POST request to the malicious C2 on 7777. The URI will be http://<host>:7777/ready

However I see something different from the HWORM:


This is actually a strange way to get the processID of the running wscript.exe or cscript.exe process and this processID is concatenated along with other profiling info and sent across as User-Agent header. The way it find its processed is spawning a child process namely: mshta.exe and then using WMI to emulate parentprocess ID of the mshta.exe, which is the process id of the parent wscript.exe or cscript.exe.


We can see the User-Agent is being used for exfiltration of profiling info:


We can see two the RAT expects two commands “exc” or “uns” coming from C2 server and what the RAT will do in both cases


Execute sa will run a command sent by C2 server and uns will uninstall the RAT. Seem that this is a cut-down version of HWorm with only two C2 command responses:


IOCs:

jn(dot)redirectme(dot)net:7777
ody(dot)no-ip(dot)biz:88
b957911d7d5865e91851ab402189ae86 (g.t.r.vbs)

0ab40f5c7d9151742ec29d53fb224ad8 (servieca.vbs)

Ofcourse MD5s can vary ;)

No comments:

Post a Comment