# Smokeloader Analysis and More Family Detections **hatching.io/blog/tt-2020-08-27/** 2020-08-27 triage Written by Pete Cowman 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](https://twitter.com/Casperinous) 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. ----- 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!](https://tria.ge/) ## 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:** [200827-m1jren2nas](https://tria.ge/200827-m1jren2nas/behavioral1) [200827-6x7fdlj8y2](https://tria.ge/200827-6x7fdlj8y2/behavioral1) [200827-v6tcrvw9es](https://tria.ge/200827-v6tcrvw9es/behavioral1) ### 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](https://research.checkpoint.com/2019/2019-resurgence-of-smokeloader/) 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](https://twitter.com/ESETresearch/status/1236925773778489344?s=20) 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.](https://tria.ge/200814-2lq9gr85q2/behavioral1) ----- ## 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:** [200827-dmry7lp4cs](https://tria.ge/200827-dmry7lp4cs/behavioral1) 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: [DarkSide ransomware](https://www.bleepingcomputer.com/news/security/darkside-new-targeted-ransomware-demands-million-dollar-ransoms/) [Conti ransomware](https://www.zdnet.com/article/conti-ryuk-joins-the-ranks-of-ransomware-gangs-operating-data-leak-sites/) [200826-jdzf5d33aa](https://tria.ge/reports/200826-jdzf5d33aa/) [200826-k8ykljftvn](https://tria.ge/reports/200826-k8ykljftvn/) [JackPot Ransomware](https://twitter.com/GrujaRS/status/1298510932340072449) [200826-3jfzxsp9yx](https://tria.ge/200826-3jfzxsp9yx/) [DeathRansom](https://www.fortinet.com/blog/threat-research/death-ransom-new-strain-ransomware) [200803-bktwtzlfze](https://tria.ge/200803-bktwtzlfze/behavioral1) ## 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](https://www.lastline.com/labsblog/infostealers-weaponizing-covid-19/) appeared around August 2019. **Analyses:** [200818-t1jk5m8sc6](https://tria.ge/200818-t1jk5m8sc6/behavioral1) [200624-gbxe29kehe](https://tria.ge/200624-gbxe29kehe/behavioral1) ### 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.](https://cofense.com/kutaki-malware-bypasses-gateways-steal-users-credentials/) **Analyses:** [200805-k11vh8yarj](https://tria.ge/200805-k11vh8yarj/behavioral1) [200805-arnebas9fa](https://tria.ge/200805-arnebas9fa/behavioral1) ### 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:** [200624-3pqyjfy64j](https://tria.ge/200624-3pqyjfy64j/behavioral1) [200817-h4pjdtget2](https://tria.ge/200817-h4pjdtget2/behavioral1) -----