Menu
Triage Thursday

Backend Updates and Family Detection Improvements

Blog.

Written by
Pete Cowman

Welcome back to another entry in our Triage Thursday update blog series!

This week we’ve got a couple of backend changes to mention, as well as our usual selection of detection and extractor updates:

As always if you have any feedback on Triage or particular samples please do get in touch! You can reach us directly through the website, on Twitter, or using the Feedback option on an analysis report page.

Not signed up yet? Head over to tria.ge to register for a free account, or reach out to us using the contact form on our website to find out more about our commercial options.

Hypervisor updates to improve packer handling

As with most sandboxing solutions, under the hood of Triage is a hypervisor which hosts the virtual machines we use for analysis. The one we use has been heavily modified by our team to harden it against detection and anti-VM techniques, but this is a huge topic and there can always be room for something to sneak in the door.

We recently came across some packers which were utilising CPU instructions not supported by our hypervisor, which was preventing some samples from running in our environment. We do not believe this was an intentional anti-VM technique, more just a quirk of their use of advanced features to evade unrelated detections and reverse engineering techniques.

The packers in question were being utilised by some of the largest families in distribution currently, including Emotet, IcedID and Gozi.

We have now deployed an update to resolve this, adding support for the instruction (and some other fixes and improvements) to ensure that they are correctly unpacked and executed during analysis. Some examples are provided below for reference.

Analyses:

Spoofing LOGONSERVER results

In the last few months we have seen a few samples checking the LOGONSERVER environment variable as a way to target their attacks, and prevent execution in unsuitable systems. Unfortunately as our VMs are currently isolated machines connected ‘directly’ to the internet, Triage squarely qualifies as one of these unsuitable systems.

The approach is fairly simple, but means that only machines connected to a Windows domain/workgroup would allow execution to continue and the malware to perform its actions. Just replacing the value of the variable had the potential to cause other issues with the standard operation of the system, but we also wanted to find a way to ensure that these files could run in our sandbox.

The current solution is to spoof the results of the API call(s) being used to check the variable from the malware samples. By returning false values to specific queries, we can ensure that the rest of the system runs smoothly while also preventing detection by the malware. After testing internally, we have today deployed this to the public cloud.

This is only a stop-gap measure to resolve the issue while we work on other features that will render it obsolete (yes, Active Directory is coming to Triage!). However, it should mean that for now you will not come across problems with these kinds of samples.

Some examples of the files making these checks are available below. It has so far mainly been observed in droppers for the Dridex malware family.

Analyses:

Updated Bazar emulation

A couple of weeks ago we introduced our new emulation functionality for BazarLoader. To see some more information on that check out the blogpost from the time.

We have been continuing to work on the family since, and this week sees a few more improvements to our handling being deployed to the public cloud. This basically adds support for additional CPU instructions to our emulator, enabling a more complete analysis than was initially possible.

TargetCompany ransomware

TargetCompany is a fairly straightforward ransomware family which has been around since about the middle of 2021.

When encrypting files, it appends a extension to their names which is based on the name of the company that is being attacked. This information appears to be hardcoded into samples suggesting that it is highly targeted in its deployment.

We have now implemented dedicated family rules, and our ransomnote parser is able to detect and dump the instructions file during analysis.

Analyses:

Updated SnakeKeylogger detection

SnakeKeylogger is a simple stealer which is sold through cybercrime forums to any user willing to pay to run their own campaigns. As such it is a common sight, but generally operated by separate groups rather than a single actor.

As is common for modern keyloggers, it also includes some functionality of a stealer. It is able to gather stored credentials from web browsers, take screenshots, and dump the contents of the clipboard in search of passwords etc.

We added detection for the family back in January and revisited it in March to add a full configuration extractor to better support the large number of samples we were receiving on Triage.

This week we’ve gone back to it again to make some tweaks to account for recent variants and changes in the executables. We have updated our triggers for the configuration extractor and static detection, which should provide better results for the latest samples. As usual we’ll continue to monitor the family for changes and will revisit it as needed.

Analyses:

Updated Cryptbot rules

Cryptbot has made a few appearances on this blog in 2021, as we have applied changes to adapt to its new variations as they have been observed. Today is no different, and we have made some more tweaks to our static detection and configuration extractor triggers to ensure that we maintain thorough coverage for the family.

The family is an infostealer which was first reported back in early 2019. It has been fairly active consistently since then, often being distributed bundled with cracked software which acts as the lure.

Analyses:

You may also like: