- Original Packed Sample: 3F77B24C569600E73F9C112B9E7BE43F
- Automatic Generated Report: PepperMalware Report
- Virustotal First Submission: 2018-08-28 14:36:26
- Sample Creation Date: 2018-08-27
- Unpacked Banker Module: 896609A8EE8CC860C2214FCD1E3CF264
- Internal executable id: aug27
- Related links:
Analysis
- 1. Loader
- 1.1. First stage packer
- 1.2. Second stage, custom packer / injector
- 1.2.1. Antidebug Tricks
- 1.2.1.1. Antidebug tricks: API Obfuscation
- 1.2.1.2. Antidebug tricks: Time Tricks
- 1.2.1.3. Antidebug tricks: HKCU\Software\Microsoft\Windows\Identifier
- 1.2.1.3. Antidebug tricks: CPUID checks
- 1.2.1.4. Antidebug tricks: Walk running processes searching for wellknown names
- 1.2.1.5. Antidebug tricks: Walk own process' modules searching for wellknown names
- 1.2.1.6. Antidebug tricks: IsDebuggerPresent / CheckRemoteDebuggerPresent
- 1.2.2. Injection
- 1.2.3. Other details
- 1.2.3.1. BotId and mutex
- 1.2.3.2. PRNG
- 2. Banker module
- 2.1. WebInjects
- 2.2. Browser hooks
- 2.3. Other stealer capabilities
- 3. Similarities with NukeBot leaked source code
- 3.1. InjectDll function at banker module
- 3.2. Hollow-process explorer.exe
- 3.3. Random BotId
- 4. Yara rules
- 5. Conclussions
1. Loader
1.1. First stage packer
In the first stage, the sample is packed with an usual packer that allocates a memory block where it copies a shellcode that decrypts a second stage code, and that second stage code is overwritten over the original PE in memory.
1.2. Second stage, custom packer / injector
This second stage is an executable that is unpacked over the original executable in memory. This second stage perfoms some antidebug tricks such as VM detection and API calls obfuscation. In addition, it decrypts the third stage PE: the main banking code, and it injects this third stage PE to explorer.exe process.
1.2.1. Antidebug Tricks
1.2.1.1. Antidebug tricks: API Obfuscation
In the Neutrino Bot loader, each time a API is going to be called, it is got from a hash.
It seems to be using a custom hash algorithm, not crc32 or similar well-known algorithm (frequently used by other malware families).
1.2.1.2. Antidebug tricks: Time Tricks
The analyzed sample plays with GetTickCount and waits (Sleep and WaitForSingleObject), performing usual tricks to detect that it is running into a VM. From analyzed sample (IDA decompiled):
1.2.1.3. Antidebug tricks: HKCU\Software\Microsoft\Windows\Identifier
The analyzed sample checks the key: HKCU\Software\Microsoft\Windows value: Identifier, it hashs the content of that value with Fowler–Noll–Vo hash algorithm and it compares the hash with 0xC9C8F009. I don't know exactly what content would match this hash, but probably it matchs an specified content for some wellknown VMs (virtualbox, vmware, ...). From analyzed sample (IDA decompiled):
1.2.1.3. Antidebug tricks: CPUID checks
The analyzed sample executes cpuid instruction to get cpu information, then it calculates a fowler-noll-vo hash with the information returned by cpuid, and compares that hash with a set of values: 0x3A72221D, 0xB609E57D, 0x11482F93, 0xA7C9423F, 0x7816EDDD, 0x6361F34. I don't know exactly the original data causing these hashes, but probably they are values returned by cpuid related to wellknown VMs such as vmware, virtualbox, etc... From analyzed sample (IDA decompiled):
1.2.1.4. Antidebug tricks: Walk running processes searching for wellknown process's names
The analyzed sample calls toolhelp32's functions to walk running processes. Again, it calculates the fowler-noll-vo hash foreach process name and compares against a set of precalculated hashes: 0x4FAEA2EB, 0x689ED848, 0x57337435, 0xE8BC3AB9, 0x3C30BBA6, 0xA421254D, 0x26638D6A, 0xE3449C1. These hashes probably correspond to names such as vmtoolsd.exe and other well known processes associated to VMs and security products.From analyzed sample (IDA decompiled):
1.2.1.5. Antidebug tricks: Walk own process' modules searching for wellknown module' names
In addition, it walks the modules of the current process searching for wellknown libraries such as SbieDll.dll, etc... It compares the fowler-noll-vo hash of each module's name with the following set of hashes: 0xCC23DB0E, 0xCCFE57BB, 0x9FECD578, 0xE69D9465, 0xC55CC270, 0x601CDCE9, 0x9DF7C709, 0x23E9F2F5, 0x70E2598E, 0x2C82D8A, 0x99CC8618, 0xB62000C5. From analyzed sample (IDA decompiled):
1.2.1.6. Antidebug tricks: IsDebuggerPresent / CheckRemoteDebuggerPresent
Not necesary explanation, usual antidebug checks:
1.2.1.7. Antidebug tricks: Query device' names
The analyzed sample calls QueryDosDeviceW to get a list of devices, and calculates the fowler-noll-vo hash foreach name, and then compares each name with a set of values: 0x5C86B533, 0x7F65B61C, 0x464768AD, 0x9A781952. It tries to detect VM's common devices, such as vmci or HGFS. From analyzed sample (IDA decompiled):
1.2.2. Injection
The analyzed sample decrypts the third stage PE (the banking module) by using the RC4 algorithm + decompression. It creates an explorer.exe instance, and it will inject the decrypted PE into the address space of that explorer.exe instance (hollow process). From analyzed sample (IDA decompiled):
1.2.3. Other details
1.2.3.1. BotId and mutex
The analyzed sample contains a kind of executable id, and the name of the mutex is created based on that executable id. In the case of the analyzed sample this exe id is "aug27", probably the date that it was generated (the virustotal first analysis date is 2018/08/28). From analyzed sample (IDA decompiled):
A fowler-noll-vo hash is calculated from the string "aug27". Later, it uses the calculated hash to initialize a PRNG (based on idum=1664525*idum+1013904223) to generate a random guid, that will be the name of the created mutex. From analyzed sample (IDA decompiled):
1.2.3.2. PRNG
From analyzed sample (IDA decompiled):
2. Banker module
The third stage is the banker module. You can find the unpacked banker module's dll that I unpacked here. It is quite similar to this other dll that was extracted by @james_in_the_box (you can read about at twitter, here) from a sample shared by @malware_traffic, here.
This is a list of strings of the Neutrino Bot unpacked banker module.
2.1. WebInjects
The banker module performs webinjects. The following parts of code manage the downloaded injects (IDA decompiled):
Nss3 hooks (IDA decompiled):
Wininet hooks (IDA decompiled):
2.2. Browser hooks
It performs hooks at frequently targetted nss3 and wininet APIs at browsers.Nss3 hooks (IDA decompiled):
Wininet hooks (IDA decompiled):
2.3. Other stealer capabilities
Other strings found into the banker module reveal additional stealer capabilities:
3. Similarities with NukeBot leaked source
Comparing some parts of the NukeBot code that was leaked on spring 2017 with the disassembled/decompiled code of the analyzed sample, we can check that there are similarities between them. Probably Neutrino Bot is an evolution or, at least, it reused code from NukeBot leaked code.
In this section, I comment about some parts of code where I found similarities, but probably, there are other parts of code that are very similar too.
3.1. InjectDll function at banker module
InjectDll is a function that appears in NukeBot leaked code and Neutrino Banker module.You can find the full code of both functions here:
- InjectDll source code from NukeBot leaked source: https://pastebin.com/LL9PnVb6
- InjectDll decompiled code from Neutrino Bot analyzed sample: https://pastebin.com/K4cfUq4C
Comparing both codes, we can check both functions are almost identical between NukeBot leaked source code and Neutrino analyzed sample. Probably this part of code was reused.
3.2. Hollow-process explorer.exe
The following parts of code from the neutrino and nukebot loader get the path of explorer.exe, create an instance of the process, and inject it (hollow process).
From NukeBot leaked source code:
From Neutrino analyzed sample's loader (IDA decompiled):
The code used to inject processes is quite similar between the leaked source code and the analyzed version:
From Nukebot leaked source code:
From Neutrino analyzed sample's loader (IDA decompiled):
3.3. Random BotId
Both, leaked NukeBot and Neutrino, generate a random GUID that is used as botid and to create a mutex that the malware uses to know it is already running.
From NukeBot leaked code:
Random GUID is used to create the mutex:
From Neutrino analyzed sample (IDA decompiled):
Random GUID is used to create the mutex:
4. Yara rules
Banker module:
rule jimmy_08_2018 {
strings:
$string1 = "reg add HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /ve /t REG_SZ /d \"%ls\" /f" wide
$string2 = "Rundll32.exe SHELL32.DLL,ShellExec_RunDLL \"cmd.exe\" \"/c %ls\"" wide
$string3 = "Rundll32.exe SHELL32.DLL,ShellExec_RunDLL \"%ls\"" wide
$string4 = "Rundll32.exe url.dll,FileProtocolHandler \"%ls\"" wide
$string5 = "Rundll32.exe zipfldr.dll,RouteTheCall \"%ls\"" wide
$string6 = "/a /c %s" wide
$string7 = "%ls_%ls_DLL" wide
$string8 = "Cookie: %s=%s;uid=%ls"
$string9 = "%ls\\nss3.dll" wide
$injects1 = "injects"
$injects2 = "set_host"
$injects3 = "set_path"
$injects4 = "inject_setting"
$injects5 = "data_keyword"
$injects6 = "inject_before_keyword"
$injects7 = "inject_after_keyword"
condition:
(all of them)
}
Packer stage 2:
rule neutrino_packer_stage2_08_2018 {
strings:
$code1 = { 6A 25 [0-15] 6A 6C [0-15] 6A 73 [0-15] 6A 5C [0-15] 6A 2A [0-15] 6A 25 [0-15] 6A 6C [0-15] 6A 73 [0-15] 6A 5C [0-15] 6A 25 [0-15] 6A 6C [0-15] 6A 73 }
$code2 = { 6A 65 [0-15] 6A 78 [0-15] 6A 70 [0-15] 6A 6C [0-15] 6A 6F [0-15] 6A 72 [0-15] 6A 72 [0-15] 6A 2E [0-15] 6A 78 }
$code3 = { 6A 6B [0-15] 6A 65 [0-15] 6A 72 [0-15] 6A 6E [0-15] 6A 65 [0-15] 6A 6C [0-15] 6A 33 [0-15] 6A 32 [0-15] 6A 2E [0-15] 6A 64 [0-15] 6A 6C }
$code4 = { 6A 25 [0-15] 6A 6C [0-15] 6A 73 [0-15] 6A 5C [0-15] 6A 25 [0-15] 6A 6C [0-15] 6A 73 }
condition:
all of them
}
5. Conclussions
We have analyzed a Neutrino Bot sample dated 2018/08/27. After analyzing the sample (3F77B24C569600E73F9C112B9E7BE43F), we have checked it could be an evolution (or at least, could be using parts) of the leaked NukeBot source code's loader. Nukebot / JimmyNukebot / NeutrinoBot / ... Probably, this set of families share code between them and are in continuous development.
No comments:
Post a Comment