In this week’s Triage Thursday blog, we’ll cover a number of minor updates to family classification introduced in the past week, and @Casperinous goes under-the-hood with recent changes observed in SmokeLoader samples.
Over the past few days we have released another batch of smaller detection updates, affecting several families. The main focus has been on ransomware and stealers, adding family-specific detection for samples recently seen in the wild.
- Improved LockBit ransomware detection and note dumping
- Added support for BigLock, DarkSide, Conti, JackPot, and DeathRansom ransomware
- Added support for 404Keylogger, Kutaki, and XPertRAT infostealers
Read on below for more information on each of these topics.
Not signed up yet? Head over to https://tria.ge/ and register right away!
SmokeLoader Analysis
Smokeloader is a downloader/backdoor which has been active since 2011. Over the years it has evolved both its capabilities and the variety of malware it downloads to the infected host. In this post we will have a look at what’s changed since the most recent analysis by Checkpoint and present the new features introduced in 2020.
Smokeloader Analyses:
New Anti-VM methods
Detection of unsigned drivers
Smokeloader introduced 2 new anti-VM checks closely associated with the gaming community.
The first one checks if the executable’s path contains the string [A-F0-9]{4}.vmt. Also, if the architecure of the system is 64-bit, NtQuerySystemInformation is called with the first argument set to 0x67 (SystemCodeIntegrityInformation). After the call, ESI points to the SYSTEM_CODEINTEGRITY_INFORMATION. The check [ESI+4] confirms if the struct’s CodeIntegrityOptions member is equal to 0x2. Based on some public information it is assumed that this check is intended to detect the Driver Signing Policy of the infected host - if the value is indeed equal with 0x2 an unsigned kernel driver can be installed, a common configuration for sandboxes.
The check is not well implemented - instead of comparing if the variable is equal with 0x2, it should be using a TEST instruction to figure out if the 0x2 flag is used.
Detection of loaded DLLs
Smokeloader also extended the list of loaded DLLs that it checks for. Going by previous analyses Smokeloader was only checking for sbiedll, but it was observed that in 2020 it is also looking for:
- aswhook
- snxhw
Detection of processes associated with virtualization software
Something that is common in various packers/loaders is checking the running processes against an array of predefined strings, in order to check virtualized environments. Smokeloader has implemented the same check, by calling NtQuerySystemInformation with the first parameter set to 0x5 (SystemProcessInformation) in order to get all the running processes. Then there is a loop where every process is converted to lowercase and is checked with wcsstr to see if it contains the following strings:
- L"qemu-ga.exe"
- L"qga.exe"
- L"windanr.exe"
- L"vboxservice.exe"
- L"vboxtray.exe"
- L"vmtoolsd.exe"
- L"prl_tools.exe"
Detection of files associated with virtualization software
Another technique employed by Smokeloader is checking the System32 folder for files that are associated with virtualization software. This is again done by calling NtQuerySystemInformation with the first argument 0xB (SystemModuleInformation). Then, following the previous logic, there is a loop where every file in the aforementioned location is converted to lowercase and checked by calling strstr if it contains the following strings:
- “vmci.s”
- “vmusbm”
- “vmmous”
- “vm3dmp”
- “vmrawd”
- “vmmemc”
- “vboxgu”
- “vboxsf”
- “vboxmo”
- “vboxvi”
- “vboxdi”
- “vioser”
After successfully passing the aforementioned checks, Smokeloader must determine the system’s architecture. This is done by using the gs register and a test instruction. For our own convenience, we patched the check in order for Smokeloader to decompress the 32-bit payload and continue the analysis. While it was common for Smokeloader to utilize Propagate to inject the payload in explorer.exe, in the 2020 version it is still injecting into this process but it using a more typical combination of NtCreateSection, NtMapViewOfSection and RtlCreateUserThread to start the execution.
Changes in the payload
Increased size of random data buffer
Smokeloader introduced the usage of randomly generated data in 2019, possibly in order to fool IDS/IPS systems. The size of the buffer is calculated randomly but is set to be at most 0x104. Then, the number is used to allocate heap space and fill it with randomly generated lowercase letters. The generated string is appended at the end of the packet structure.
Change in communication traffic
As was discovered in early March, the communication packet structure of Smokeloader has been extended by 0x10 bytes. In the new struct, after the bot_id member, there is a new field allocated to hold the name of the infected host. There is also now a check to either append the random data or the additional data at the end of the pkc struct. The new struct is now defined like this:
struct pkc {
WORD magic
BYTE[40] bot_id
BYTE[16] comp_name
BYTE[6] botnet_id
BYTE os_ver
BYTE sec_flag_1
BYTE sec_flag_2
WORD comm_id
DWORD task_idx
DWORD tmp_path_run
BYTE[n] extra_data
}
In some cases SmokeLoader was observed to be using decoy C2 to put off analysts. In these instances the sample stored a fake value using its standard encryption technique which would be dumped by static extractors, and the actual C2 was simply stored as a plaintext string. Triage can now distinguish between the fake and real C2 strings and only reports the legitimate ones in the report. This analysis is a good example of this behaviour.
Ransomware Support
Ransomware is extremely active these days and new variants and families are constantly being released, with even relatively basic ones sometimes managing to achieve infections in the wild. This week we’ve added support for a number of these which have gained attention over recent weeks.
LockBit and BigLock Analysis:
The sample referenced above came to our attention recently as a slightly unusual case. It drops multiple families, including 2 different ransomware - Lockbit and BigLock. Lockbit is run first, encrypting files with it’s distinctive .lockbit extension, then another re-encrypts the files with a second layer.
For Lockbit, ransom note extraction has been improved to now also dump details like Telegram contacts, and we have fixed an issue that was preventing some URLs being dumped from certain variants of the note.
We have also added support for BigLock, a family we previously did not have family classification for. The note and family tag should now be correctly displayed in the report.
Along with this, we have improved/added detection and ransom note support for:
Infostealers
We have added a number of yara rules and other detections for a few infostealer families. Where possible we have also used behaviour to identify them, but often one infostealer’s actions look much like another, so our focus has generally been on static techniques.
404Keylogger
Infostealer which has been exploiting COVID-19 related lures to gain infections. First appeared around August 2019.
Analyses:
Kutaki
Keylogger with some other basic infostealer functionality like taking screenshots and harvesting data on the clipboard. Includes a range of anti-VM and anti-analysis techniques, although mostly a bit dated.
Analyses:
XpertRAT
Backdoor/stealer which can carry out a wide range of operations on an infected machine depending on the instructions received. Can also act as a dropper for other families.
Analyses: