Posted by Felix Weyne, April 2016.
Author contact: Twitter | LinkedIn
Tags: remote access trojan, jRAT, honeypot, forensics
In my malware analysis lab I like to use a few virtual machines (VMs) as honeypots. On those machines I run a recent RAT too see what the scriptkiddies are up too. For the readers that are now thinking I like to put furry creatures that live in sewer lines next to a jar of honey, let me clarify myself 
.
RAT stands for Remote Access Trojan. A RAT is a piece of software that gives a cybercriminal the possibility to control a PC remotely, without the user noticing (or at least, that is the plan). A honeypot is a computer trap set to detect attempts to gain unauthorized use of an information system.
In layman’s terms, a honeypot can lure out a malicious actor that would otherwise may lay dormant and undetected. In this blog I’ll give an overview of what happened when I decided to run a RAT called jRAT in my honeypot.
The mail with the job offer
Recently, I received a suspicious mail with an even more suspicious file attachment in my SPAM folder. The mail attachment was a Java JAR file that, according to the sender of the mail, was a document that contained a job offer. Given the fact that the mail was sent from a Romanian domain, and the fact that I’m totally interested in a job offer letter that is executable, I eagerly opened the attachment .
Unfortunately for the sender, I did not open the attachment on my PC though. I decided to open it on my Windows 7 honeypot VM.
Shortly after executing the JAR file, I noticed that my machine started to make some network connections to a Russian IP. I didn’t really notice any clearly malicious behavior until the next day. Suddenly, I noticed an UAC popup to ask permission to run a command prompt as administrator. As generous as I am, I clicked yes on the UAC request .
Shortly after I gave the permission, I saw the following command prompt window:
Image 1: command prompt window as seen on the honeypot
I got intrigued by the command window that suggested something was started with administrator privileges, so I decided to investigate this further.
On my honeypot I had Sysmon (system monitor) installed. Sysmon is a Microsoft Windows Sysinternals tool that monitors and reports key system activity via the Windows event log. I also had a network tap on the VM, this way I was able to follow the network traffic from and to the VM. During my investigation, I quickly realized that the RAT I received could be categorized as a RAT of the jRAT family. Below I’ll briefly explain what jRAT is. I’ll end this blog with my findings on the Sysmon logs.
jRAT: malware as a service
jRAT is promoted as a cross-platform Remote Administration Tool written in Java. For only 40$, one can buy the tool. The tool enables a customer/administrator to generate custom JAR files that gives him the possibility to remotely control a PC via a graphical user interface (GUI). A malicious actor can of course also buy this tool and abuse it to generate a JAR Remote Access Trojan. Below a screenshot of jRAT’s website is shown.
Image 2: jRat's marketplace
Inspection of the Sysmon logs
As a security analyst, I really love Sysmon. One of its many great features is its ability to keep track of every process that is started on a machine. For each process, it also logs the calling process (the parent process). Since I noticed a command line window on my honeypot’s screen, I queried the Sysmon logs for occurrences of CMD.exe. After filtering out some uninteresting legitimate CMD calls, I was able to reduce the many log lines to the following entries:
Childimage Parent Image ---------- ------------------------------------------ whoami /all cmd cmd /c "%TEMP%\elev58...93.bat" javaw.exe -jar "*censored*.jar" NET FILE cmd /c "%TEMP%\elev58..93.bat" WScript.exe "%Temp%\OEgetPrivileges.vbs" cmd /c "%TEMP%\elev58..93.bat" consent.exe 960 426 0000000003610930 C:\Windows\system32\svchost.exe -k netsvcs cmd.exe /C "%TEMP%\elev58....bat" ELEV WScript.exe "%TEMP%\OEgetPrivileges.vbs" NET FILE cmd.exe /C "%TEMP%\elev58..93.bat" ELEV java -jar "*censored*.jar" cmd.exe /C "%TEMP%\elev58..93.bat" ELEV
These entries teach us the following:
*The attacker ran the “whoami” command. This probably because (s)he wanted to see which permissions the user on the VM had.
*Shortly after running the “whoami” command, the RAT JAR started a batch file
*The batch file executed the “net file” command and also called a Visual Basic script
*The Visual Basic script calls the original batch file, this time with administrator privileges (notice the consent.exe process. This process is responsible for popping up the UAC window)
*The original batch file executes the “net file” command again, then it runs the RAT as administrator.
These logs explain the command line window, but left me with a few questions:
*I get that the malicious actor wants to run the RAT with administrator privileges. I also get that the malicious actor was not the brightest, and that (s)he used a simple batch script that generates a permission request to run the RAT as administrator 
. A PC user that isn’t really tech savvy might randomly click “approve” when presented with a permission request to run a command line as administrator, but when you call the batch script with your RAT, why on earth wouldn’t you at least run it in the background?
A user might not find the elevation request suspicious, but a giant command line window on your screen with “getPrivileges” in it surely must raise a red flag?
*Even though I’m disappointed in my scriptkiddie, I still wondered: how does the batch script look like?
The batch and Visual Basic scripts
The first question I tried to answer, was how the scripts looked like. Given the level of sophistication of the attacker (notice the sarcasm), I wasn’t surprised to see that the scripts were still present in the TEMP folder. The contents of the batch and VBS scripts are displayed below.
:checkPrivileges NET FILE 1>NUL 2>NUL if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges ) :getPrivileges if '%1'=='ELEV' (shift & goto gotPrivileges) setlocal DisableDelayedExpansion set "batchPath=%~0" setlocal EnableDelayedExpansion ECHO Set UAC = CreateObject^("Shell.Application"^) > "%temp%\OEgetPrivileges.vbs" ECHO UAC.ShellExecute "!batchPath!", "ELEV", "", "runas", 1 >> "%temp%\OEgetPrivileges.vbs" "%temp%\OEgetPrivileges.vbs" exit /B :gotPrivileges setlocal & pushd . "C:\Program Files\Java\jre1.8.0_45\bin\java" -jar "*CENSORED*.jar"
Set UAC = CreateObject("Shell.Application") UAC.ShellExecute "%TEMP%\elev40..8.bat", "ELEV", "", "runas", 1
The batch script correlates well with the Sysmon logs. The batch script starts by executing the “net file” command. If the “net file” command is not run as administrator, it throws an error (access denied, error level 5). I tested this by executing the “net file” command as a regular and administrator user.
Image 3: net file command ran as user and as administrator
If the “net file” command returns error level one, it starts the JAR RAT. The RAT will run as administrator because the batch script runs with administrator privileges. If the “net file” command does not return error level one, the batch script creates a Visual Basic script that requests permissions to run itself with administrator privileges.
There is something funny about this situation. My “attacker” did not run the batch script in the background. This means that when I closed the command line window, the RAT was shut down. Oh boy, I did not know shutting down malware could be that easy! 
jRAT’s request elevation option
Analyzing the behavior of the RAT on my honeypot made me want to experiment with the jRAT tool myself. I ran the jRAT control panel in a Linux environment and generated a jRAT JAR instance. I executed this instance on a Windows 7 environment. After experimenting a bit with the control panel, I saw the ‘request elevation option’.
Image 4: jRat's request elevation option
I eagerly pushed the button, and sure enough, I saw the same command line window popping up as I saw on my honeypot. This is when I realized that the lame way of running the RAT as administrator is just default behavior built in by the jRAT tool 
. I’m wondering: when you build a malware-as-a-service kit, is it that hard to at least provide the possibility to be a little subtle with your malicious actions? .