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)--------------------
Unobfuscated script:
Some background on “Houdini” guy, who seem to be behind this H-worm / NjRAT:
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:
The URL:
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
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:
The enumdriver basically iterates through all drives and gets and concatenates the drive path with a splitter in between.
Exit-process:
-------------------------------------------------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
Copying the script to temp file
IOCs:
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
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
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 ;)
Comments
Post a Comment