JUNE
07, 2018
Last year,
researchers identified new crimeware, Loki-Bot, which steals
data and login credentials. Loki-Bot is generally distributed through malicious spam, and is difficult
to identify without getting into the malware. Loki-Bot crimeware targets
Windows, in contrast to the recent Android banking ransomware, Loki Bot. While the crimeware is not as prevalent
in the wild, it has some unique and differentiating characteristics.
Loki-Bot’s crypter is
especially interesting and unique because it utilizes Visual Basic 6.0 to load
multiple stages of shellcode to deliver the Loki-Bot payload. We saw
an interesting sample highlighted by
@DissectMalware on Twitter and
decided to take a closer look for ourselves. We’ll walk through Loki-Bot’s
crypter functionality, the first and second stage shellcodes, the payload, and
then provide some thoughts on stopping these kinds of attacks and what we can
expect to see next.
Loki-Bot
Crypter Functionality
The main Visual Basic
compiled binary uses a raw pointer access technique to jump into the first
stage shellcode which then calls the second-stage shellcode that is executed
off of the stack. The first stage shellcode disables data execution prevention
(DEP) to make the stack executable, and uses jmp esp to jump into the stage 2
shellcode to allow it to begin execution. Stage 2 then sets up persistence,
decrypts the payload, and executes the payload contents by using process
hollowing. In this case the payload is Loki-Bot, crimeware designed to steal
private information from a system. Loki-Bot’s functionality has already
been covered in detail
elsewhere, so we will instead
focus on the mode of compromise and its anti-reversing engineering tactics.
DELIVERY CONTEXT
This particular
malware sample began its life as an executable with an RTF exploit. Generally
an RTF exploit is a specially crafted file that exploits vulnerabilities in the
Rich Text Format parser of an application like Microsoft Word or Adobe Acrobat
in order to gain code execution on the victim. The malware can then use this
initial code execution to begin its exploit chain. Usually, crafted files are
spread as attachments in phishing emails, which was the case in this sample.
Once the malware gets code execution on the host it then downloads jazz.exe
from the link below.
Source:
hxxp://tpreiastephenville.com/jazz.exe
Sha256:
a66f989e58ada2eff729ac2032ff71a159c521e7372373f4a1c1cf13f8ae2f0c
PE DESCRIPTION
The binary was compiled
with VB6.0 professional/enterprise and so contains normal x86asm with a
dependency on msvbvm60.dll. Stage 1 makes specific use of the visual basic
runtime DLL to make dll calls to other libraries.
First
Stage Shellcode
The first stage
shellcode exists within the VB6 portion of the malware, which we’ll refer to as
the crypter. The first stage shellcode exists in the “rentegninger” sub
module. The original sub module is then partially overwritten with obfuscated
shellcode. The “Remanipulation8” public function is called from Load_Form().
This function manipulates the list of values of the Virtual Function Table
returned by the “Me” reference to the form.
Set var_2 = Me
HOW TO GET THE SHELLCODE ENTRYPOINT
Stage 1 overwrites one
of the variables in the compiled Visual Basic 6 code to point to an offset in
the middle of the “rentegninger” submodule. The pointer is a hard coded integer
that is calculated with division and a square root as shown below.
var_17 = 0x1526C77
new_value = var_17 \ CLng(Sqr((25)))
new_value = 0x43AF4B
UTILIZING STRPTR TO ACCESS ADDRESSES
In the code example
below the pointer to the Me value points to the beginning of the Virtual
Function Table of the class that Me points to. In this case the Class is a
Form. The offset 0x2B0 is actually the function “Show”. The pointer to the show
function is overwritten by the entry point of the shellcode which is 0x43AF4B.
Then you can easily call “Form.Show” and call into your shellcode. An example
of this is located in the Appendix.
var_num1 = StrPtr(var_2) +
2B0h
ReplacePtr(var_num1,
new_value)
This value is later
called in the “Remanipulation8” function as call dword ptr [eax+2B0h].
It treats this call as a method of the Me object. DispCallFunc .
STRING-TO-STACK METHOD
The crypter uses a
common trick to get the strings that are inline with the assembly onto the
stack. When a call is made, the next address gets pushed onto the stack as the
return destination address. A disassembler will try to disassemble the string
even though it never gets executed.
USING SHELL_NOTIFYICON
The first stage
shellcode uses the Shell_NotifyIcon in a non-standard way. It passes an address
off the stack that does not resemble a proper PNOTIFYICONDATA struct. The Windows
API still processes the events as if they were normal. As you can see below,
the Shell_TrayWnd icon is junk data for this process. It is called twice
where NIM_ADD and NIM_DELETE are used.
UTILIZING THE PEB LOADER AND DLLFUNCTIONCALL
The first stage
shellcode uses a common technique among other Windows shellcode to get a
reference to DllFunctionCall by utilizing the Process Environment Block (PEB).
The PEB is a data structure provided to every running process, and can be used
to gain information about that process such as environment variables, image
base addresses and DLL imports. This shellcode contains a PEB loader routine
that gets a reference to msvbvm60.dll and then finds the offset of
DllFunctionCall at 0x8D560CEC. Once it has the correct offset to
DllFunctionCall, it can then use it to load Windows APIs so that it can make
calls to them. More information on the PEB can be found here.
In a nutshell, the PEB
is a linked list of offset values and the string names of the desired
functions. You can linearly traverse the linked list, check for the desired
function and save its offset if found.
DISABLING DATA EXECUTION PREVENTION (DEP)
The function
ZwSetInformationProcess can be called with parameters -1 and 0x22 to
turn off DEP for the process. DEP was originally intended to prevent programs
from executing code on the stack, however DEP can also cause normal programs to
crash without any notifications. Giving the program the ability to turn off DEP
for itself allows the malware to avoid unknown crashes while also allowing
malware authors to execute shellcode explicitly on the Stack. Microsoft
Support provides additional details about DEP.
DECODING THE SHELLCODE
The stage 1 shellcode
then utilizes JMP ESP to jump into that stack at the offset where the buffer
for stage 2 shellcode was allocated. The stage 2 shellcode that was initially
loaded onto the stack undergoes an initial pass of XOR decoding with an
immediate value of 0x510473D1.
Second
Stage Shellcode
SANDBOX EVASION
The stage 1 shellcode
executes CPUID to detect if it’s being run in a virtual
environment. If it is running in a virtual environment, it exits. If the stage
1 shellcode is not running in a virtual environment, then it continues
execution normally. As detailed elsewhere, the malware sets the EAX register
to 1, calls CPUID and then checks the 31st bit of the ECX register
by applying a bitmask. If the 31st bit is 0 it knows it’s
being run in a virtual environment.
Subsequently, the
stage 1 shellcode calls the sleep function. Sleeping for prolonged durations of
time is one evasion technique used by malware to subvert detection in sandboxed
environments which are usually constrained by resource allocation to not run
any given sample for longer than some established period of time, such as 30
seconds. Thus for the first 30 seconds of the program’s lifetime, it is benign
and might fool some sandboxing environments.
ANTI-DEBUGGING USING NTYIELDEXECUTION
The ntdll function
NtYieldExecution or its kernel32 equivalent SwitchToThread function allows the
current thread to allocate the rest of the execution time, and allows the next
scheduled thread to execute. If no threads are scheduled to execute or when the
system is busy (and will not allow such a switch to occur), the ntdll
NtYieldExecution() function returns a STATUS_NO_YIELD_PERFORMED (0x40000024)
status code, which causes the kernel32 SwitchToThread function to return zero.
When an application is being debugged, the act of single-stepping through the
code causes debug events to occur and often results in no yield being allowed
to occur. However, this is a hopelessly unreliable method of detecting the
presence of a debugger because this method will also detect the presence of a
thread that is running with high priority. An example of this code can be
found here.
for (int i = 0; i < 0x20;
i++)
{
Sleep(0xf);
if (NtYieldExecution() != STATUS_NO_YIELD_PERFORMED)
iDebugged++;
}
CHECK FOR ADAPTERS AND WINDOWS
The stage 2 shellcode
calls VirtualAllocEX to populate a new memory region with GetAdaptersInfo. It
checks the offset +10Ch of the struct for the Description. It then calls
EnumWindows to check if the window has an empty string, most likely an attempt
to detect execution within some sandbox.
PERSISTENCE AND PROCESS HOLLOWING
The stage 2 shellcode
takes two routes. During the first route, the shellcode sets up persistent
mechanisms with schtasks.exe. It then decrypts the payload with Xor and RC4
during the second route, creating a suspended process of itself and then
hollows it out with the payload’s contents. Each route is explained below.
Route
1 (Persistence)
The stage 2
shellcode’s first route will acquire the hardcoded strings APPDATA=, TEMP=,
and copied.exe in order to place a copy of itself in
the %APPDATA% and %TEMP% locations as %AppData%\\Roaming\\copied.exe.
Once the path is acquired, it will create a scheduled task to copy and run
copied.exe using ShellExecuteA.
schtasks.exe" /Create
/SC MINUTE /TN "Startup Key" /TR
"%AppData%\\Roaming\\copied.exe"
schtasks.exe "/run /tn
\"Startup Key\""
If that fails it will
try again by adding "\" /RU SYSTEM"
schtasks.exe" /Create
/SC MINUTE /TN "Startup Key" /TR
"%AppData%\\Roaming\\copied.exe" /RU SYSTEM
It will also set the
registry startup run key with:
schtasks.exe /Create /SC
HOURLY /MO 12 /TN \"Startup Key\" /TR \"reg add
\"HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\" /v
\"\\\"\"Startup Key\"\\\"\" /f /t REG_SZ /d
\"\\\"\""
Route
2 (Process Hollowing)
The stage 2
shellcode’s second route focuses on decrypting the executable payload into
memory and then hollowing out a child process to execute the payload.
“Wee2" is the marker on the stack in the shellcode and in the file that
denotes the beginning of the copy operation. The format is Wee2<length
of payload><key>.
Decrypting
the Payload with Key
The key is stored in
the shellcode after the marker and size in the shellcode. Its length is 0x100h,
and is shown below.
00000000: 9944 4203 c046 b4f2
38dd 33ed 0281 473a .DB..F..8.3...G:
00000010: 1c76 67d8 43bc d9c6
000f 58c2 c9f7 280e .vg.C.....X...(.
00000020: 9fec 49ac 0bef bb56
8386 7d96 4c2a 4de3 ..I....V..}.L*M.
00000030: 221f 6e80 8e65 e02b
06b8 5f6a cf5c 72b7 ".n..e.+.._j.\r.
00000040: ea51 9354 1197 05ff
892e 843e 53d2 548b .Q.T.......>S.T.
00000050: 6dc7 b829 940d e6d3
0d60 a913 d604 795f m..).....`....y_
00000060: f0f9 9afd 183f 0ca7
d4d7 cee7 597b 9e34 .....?......Y{.4
00000070: 7370 bfd1 dfb6 317c
5709 b0bb 20ad c308 sp....1|W... ...
00000080: f7a2 e461 62e8 1250
da3b d54b a423 a5dc ...ab..P.;.K.#..
00000090: be18 c536 e51a 3724
5eb1 fa20 2755 cab0 ...6..7$^.. 'U..
000000a0: 414a eb0a 6990 5df8
e1e4 dbf4 aacc ef41 AJ..i.]........A
000000b0: c4c1 10de ecc3 3ecd
645a 01c8 2dfe d015 ......>.dZ..-...
000000c0: 48f3 f1b2 b339 63a1
2b8c 269c f530 f6e9 H....9c.+.&..0..
000000d0: cb25 1687 366b 8875
af02 0771 78a6 1bbd .%..6k.u...qx...
000000e0: 4e9b 3c5b bae1 ae49
3235 2c45 fbd9 fc92 N.<[...I25,E....
000000f0: 15ce 1d2f 3d14 8f1e
b567 5219 7e4f 2166 .../=....gR.~O!f
The stage 2 shellcode
uses the 0x100 sized byte key to xor the Loki-Bot payload of 0x34801 size then
uses the same key to RC4 decrypt the product of the xor operation.
The shellcode then
calls CreateProcessW to create a process of itself in suspended mode. It uses
NTCreateFile, NTWriteVirtualMemory, NTUnMapViewofSection for process hollowing
on the newly created process which contains the Loki-Bot payload.
NtGetContextThread and NtSetContextThread and NtSetContextThread resume the
process. The parent process terminates allowing the child to run as an orphan
process. Because the Loki-Bot payload has already been reviewed by many researchers, we did not post the
details about this malware.
Conclusion
There are a few key
aspects to this crypter and its behaviour that make it fishy, including its
crafty implementation of the VB6 runtime in shellcode, and use of anti-reverse
engineering techniques and process hollowing. First, VB6 and the VB6 run time are
rather old. While there are numerous binary distributions of software in the
wild that were built with VB6 enterprise, it is still suspicious. Other
suspicious activities include disabling its own DEP and checking if it’s being
virtualized. Lastly, the crypter makes calls to the Windows API with malformed
structs (i.e. the lack of an image for Shell_NotifyIcon). The combination of
all of these suspicious activities could signal to a sensor like Endgame MalwareScoreTM that the program is up to no good, allowing us to stop it
before the final execution occurs.
As for the future, we
are likely to see more samples using legacy run times and features. Judging
from this sample, a performant Visual Basic 6 crypter has recently been
distributed in the wild. It seems natural that in the future its capabilities
will improve and the volume of distribution will increase with continued black
market adoption.
Appendix: Stage 1 Code Replication
After careful
analysis, we were able to reproduce the method of Stage 1 shellcode execution
in VB6. The code below will only display an empty message box.
VB6 CODE
Private Declare Sub
CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
(ByRef lpvDest As Any, _
ByRef lpvSrc As Any, _
ByVal cbLength As Long)
Private Sub Form_Load()
Me.Hide
Dim lngRc As Long
CopyMemory lngRc, Me, 4
CopyMemory lngRc, ByVal lngRc, 4
CopyMemory ByVal (lngRc + 688), 4202169, 4
Me.Show
End Sub
SHELLCODE
E9 88 00 00 00 59 E9 8E 00 00
00 5A E8 0C 00 00 00 50 6A 00 6A 00 6A 00 6A 00
FF D0 C3 64 A1 30 00 00 00 8B
40 0C 8B 40 14 8B 00 8B 58 28 BE 4C 00 53 00 46
39 33 75 F1 81 7B 04 56 00 42
00 8B 70 10 56 8B 5E 3C 36 8B 34 24 01 DE 8B 5E
78 36 8B 04 24 01 D8 89 C6 83
C6 28 AD 85 C0 74 FB 03 04 24 BB 55 8B EC 83 39
18 75 EF 81 78 04 EC 0C 56 8D
75 E6 5B 31 DB 53 53 53 54 6A 00 81 04 24 00 00
04 00 52 51 54 FF D0 83 C4 1C
C3 E8 73 FF FF FF 75 73 65 72 33 32 00 E8 6D FF
FF FF 4D 65 73 73 61 67 65 42
6F 78 41 00
ASSEMBLY
[SECTION .text]
global Start
Start:
jmp
getdll
nextstring:
pop ecx
jmp
getstring
getapi:
pop
edx ;put string in ebx
call
loadapi
push
eax ;get MessageBoxA
push
0
push
0
push
0
push
0
call
eax
retn
loadapi:
mov
eax, [fs:0x30] ;Get the address of PEB
mov
eax, [eax+0x0C] ;Get the address of PEB_LDR_DATA
mov
eax, [eax+0x14] ;Get InMemoryOrderModuleList
loop1:
mov
eax, [eax]
mov
ebx, [eax+0x28]
mov
esi, 0x53004C ;L S
inc
esi ;M S for MSVBVM60.DLL
cmp
[ebx], esi
jnz
loop1
cmp
dword [ebx+0x4], 0x420056 ;V B for MSVBVM60.DLL
mov
esi, [eax+0x10]
push
esi
mov
ebx, [esi+0x3C]
mov
esi, [ss:esp] ;<msvbvm60.Ordinal958>
add
esi, ebx
mov
ebx, [esi+0x78]
mov
eax, [ss:esp] ;<msvbvm60.Ordinal958>
add
eax, ebx
mov
esi, eax
add
esi, 0x28
loop2:
lodsd
test eax, eax
jz short loop2
add eax, [esp]
mov ebx,
0x83EC8B55
cmp dword [eax],
ebx
jnz short loop2
cmp dword
[eax+0x4], 0x8D560CEC ;DllFunctionCall
jnz short loop2
pop ebx
xor ebx, ebx
push ebx
push ebx
push ebx
push esp
push 0
add dword [esp],
0x40000
push edx
;MessageBoxA
push ecx ;user32
push esp
call eax
;DllFunctionCall
add esp, 0x1C
retn
getdll:
call nextstring
db 0x75 ;u
db 0x73 ;s
db 0x65 ;e
db 0x72 ;r
db 0x33 ;3
db 0x32 ;2
db 0x00
getstring:
call getapi
db 0x4D ;M
db 0x65 ;e
db 0x73 ;s
db 0x73 ;s
db 0x61 ;a
db 0x67 ;g
db 0x65 ;e
db 0x42 ;B
db 0x6F ;o
db 0x78 ;x
db 0x41 ;A
db 0x00
https://www.endgame.com/blog/technical-blog/what-year-it-vb6-payload-crypter
