Basical Trojan Banker Win32.Banz.a Anatomy - Reverse Engineering
Today we are going to inspect a Rootkit Technology based Banker, called Win32.Banz.a or RKIT/Banker.9088.
This rootkit presents some interesting aspects from a reverse engineering point of view because has two
layers of protection:
Before starting the direct analysis let's study the general structure, with a PE inspection.
[b].DalKit is the section where DalKrypt Loader is placed.[/b]
[b] * KERNEL32.DLL
We have also presence of [b]TLS Directory[/b], this should be make aware that is necessary to preview Debug Break Event on TLS presence, to avoid risk of code execution without our control. Now let's inspect the resource directory that usually in there kind of applications presents interesting hints useful to uncover his structure.
Suddely we can see a suspicious Resource Entry, named[b] "SYSFILE"[/b] and inside it "[b]AVGBKILL"[/b] this is the kernelmode component of Win32.Banz that will work as AV Killer for AVG, the .sys is stored in encrypted form.
Preliminar inspection is finished, now let's disassemble it, here the Banz EntryPoint Placed into Loader section obviously:
.DalKiT:017B0000 push offset byte_281000
.DalKiT:017B0005 pop eax
.DalKiT:017B0006 push offset sub_17AC570
.DalKiT:017B000B pop edi
.DalKiT:017B000C xor ebx, ebx
.DalKiT:017B000E jmp short loc_17B001D
.DalKiT:017B0010 mov dl, [ebx+eax]
.DalKiT:017B0013 sub dl, 7
.DalKiT:017B0016 xor dl, 4
.DalKiT:017B0019 mov [ebx+eax], dl
.DalKiT:017B001C inc ebx
.DalKiT:017B001D cmp ebx, offset dword_1381000
.DalKiT:017B0023 jb short loc_17B0010 ;Decryption iterator
.DalKiT:017B0025 jmp edi ; EDI points to 017AC570
In the successive piece of code we have another layer of decryption plus an Import Address Table building, here how look the second decrypt layer:
UPX1:017AC571 mov esi, offset dword_1602000
UPX1:017AC576 lea edi, [esi-1381000h]
UPX1:017AC57C push edi
UPX1:017AC57D or ebp, 0FFFFFFFFh
UPX1:017AC580 jmp short loc_17AC592
UPX1:017AC588 mov al, [esi]
UPX1:017AC58A inc esi
UPX1:017AC58B mov [edi], al
UPX1:017AC58D inc edi
It's clear that this layer belongs to UPX encryption layer, successively we have an on fly IAT building:
UPX1:017AC6A6 call dword_152E204[esi] ;LoadLibraryA
UPX1:017AC6AC xchg eax, ebp
UPX1:017AC6AD mov al, [edi]
UPX1:017AC6AF inc edi
UPX1:017AC6B0 or al, al
UPX1:017AC6B2 jz short loc_17AC690
UPX1:017AC6B4 mov ecx, edi
UPX1:017AC6B6 push edi
UPX1:017AC6B7 dec eax
UPX1:017AC6B8 repne scasb
UPX1:017AC6BA push ebp
UPX1:017AC6BB call dword_152E208[esi] ;GetProcAddress
after building this import address table we land to the effective code of the banker
003477E4 /55 PUSH EBP
003477E5 |8BEC MOV EBP,ESP
003477E7 |83C4 F0 ADD ESP,-10
003477EA |53 PUSH EBX
003477EB |B8 5C733400 MOV EAX,OFFSET key.0034735C
003477F0 |E8 ABF1F3FF CALL 002869A0
003477F5 |8B1D 54A73400 MOV EBX,DWORD PTR DS:[34A754]
003477FB |68 30793400 PUSH OFFSET key.00347930 ; ASCII "Microsoftt"
00347800 |68 3C793400 PUSH OFFSET key.0034793C ; ASCII "TApplication"
00347805 |E8 CEF9F3FF CALL ; Jump to USER32.FindWindowA
as you can see we have the string TApplication this mean that Banz is coded in Delphi.
0034782B 8B0D 0CA93400 MOV ECX,DWORD PTR DS:[34A90C]
00347831 8B03 MOV EAX,DWORD PTR DS:[EBX]
00347833 8B15 7C533400 MOV EDX,DWORD PTR DS:[34537C]
[b]00347839 E8 06BAF9FF CALL 002E3244[/b]
0034783E 8B0D DCA63400 MOV ECX,DWORD PTR DS:[34A6DC]
00347844 8B03 MOV EAX,DWORD PTR DS:[EBX]
00347846 8B15 9C543300 MOV EDX,DWORD PTR DS:[33549C]
[b]0034784C E8 F3B9F9FF CALL 002E3244[/b]
003478E9 8B0D 38A53400 MOV ECX,DWORD PTR DS:[34A538]
003478EF 8B03 MOV EAX,DWORD PTR DS:[EBX]
003478F1 8B15 D0473300 MOV EDX,DWORD PTR DS:[3347D0]
[b]003478F7 E8 48B9F9FF CALL 002E3244[/b]
003478FC 8B0D 68A33400 MOV ECX,DWORD PTR DS:[34A368]
00347902 8B03 MOV EAX,DWORD PTR DS:[EBX]
00347904 8B15 9C1D3300 MOV EDX,DWORD PTR DS:[331D9C]
[b]0034790A E8 35B9F9FF CALL 002E3244[/b]
0034790F 8B0D F8A73400 MOV ECX,DWORD PTR DS:[34A7F8]
00347915 8B03 MOV EAX,DWORD PTR DS:[EBX]
00347917 8B15 D04C3400 MOV EDX,DWORD PTR DS:[344CD0]
[b]0034791D E8 22B9F9FF CALL 002E3244[/b]
00347922 8B03 MOV EAX,DWORD PTR DS:[EBX]
00347924 E8 9BB9F9FF CALL 002E32C4
The structure should be clear, we have a recurrent call 002E3244 and ECX that is used as selector to run the wanted routine. During analysis of these CALL we should be aware of the MultiThreaded structure of this malware, so it's fundamental to have Break on New Thread Event enabled.
We will encounter a considerable amount of new threads that deals with various networking aspects of this malicious application. By jumping from thread to thread we can notice the presence of certains URL stringsinto stack, at this point due to the general overview nature of this post, we will move to the Network Analysis.
In the previous blog post we traced the essential structure of Win32.Banz, that is essentially protected by two packers UPX and DalKrypt.
Here I want to add some other specification on this packer, that is often used into malicious applications, we can meet essentially two versions of DalKrypt
[b] * v 1.0 (our case)
* v 2.0[/b]
Both of them are easy to unpack, some quick specification that I forgot to mention yesterday
.DalKiT:017B0025 jmp edi[b] ;EDI Points to the Partial-OEP[/b]
All what you have to do is to reach the Partial-OEP, in this case due to the fact that we have two packers, the OEP corresponds to the UPX packer, this last one is truly easy to unpack, after finishing executable could be Dumped and IAT reconstructed with ImportReconstructor.
After this little unpacking parentesis let's move on the main topic of this post, the Malicious Networking Activity Profiling. We will use Wireshark to capture and successively analyze network activity, due to the malicious nature of the application it's a great practice to plain a campaign of observations usefull to characterize the activity in the three key infection events:
[b] 1. Observations at Infection Time
2. During Idle Activity
3. At Restart[/b]
Obviously we have also to identify and profile interactions with victim, so we have to add:
[b] 1. At User Activity Time[/b]
Run Wireshark and wait a minute to identify unwanted disturbating network packets like NBNS Protocol Activity, became clear that this annoyance could be avoided with a packet filter; now let's run key.exe
Here how malicious net activity starts:
Activity begins with a [b]DNS Query[/b] and successively starts the [b]TCP[/b] and [b]HTTP transaction [/b] suddenly after we have other two DNS Queries to different domains, each of these query belongs to a new thread created by Win32.Banz. Before starting analyzing the various transaction we have to know all Domains Involved, so let's perform a research of DNS Queries:
We have a total of 6 different DNS Request, this make us aware of what we really have to look for. The pcap is rich of informations so we have to summarize a bit the conversations, here an abstract taken from Expert Infos Analyse option:
After obtain DNS in the same order that they are called we have HTTP activity, in first instance a classical GET to reach and check if the malicious domain is active and successively more targeted GET Requests. The most important information that we can carve out from this image is that we should concentrate on HTTP Activity, we are lucky Wireshark has an HTTP Statistics Collector, here the involved Domains:
Enough clear :) bb.com.br is the networking activity most attractive pole, indeed as you can see presents an activity percentage of 58,82 % This mean that bb.com.br has a preminent role in the malicious exchange so we have to pay particular attention to this domain. My scope here is to show how pragmatically build a scalable awareness of a generic malicious activity, now we have a complete knowledge of the network architecture, we can move on Coversations Chart and analyze HTTP Exchanges
At this point we can bild the complete URL, let's start from bb.com.br
This is a brazilian bank, targeted by Banz.a, as should be clear at this point also other domains are Banz.a targets, this suggest us how to prosecute analysis. We have to mime Victim Interaction with these Banks, so let's open the browser and reach another targeted bank
Little surprise here.. Banz is faulty :) when the user accesses this bank due to a bug, key.exe crashes.
In the previous episode we encountered an unexpected crash caused by a bug into Win32.Banz, here an evidence of Banz infection
After acceping the request in the Script Error page, key.exe crashes. Same fake error message comes out from others targeted URLs. At this point became clear how Win32.Banz works, we have a multithreaded application that monitors [b]Victim Browser Activity[/b], each thread belogs to a different scanned Bank, when user reaches one of the se Urls banker registers and sends disclosed credentials.
What we have to ask for now is, when Credential Theft is accomplished, who receives data?
Response can come out only from network analysis, as you've seen we have a set of HTTP most of them are GET action, to identify [b]POST Actions[/b], with a filter to
ip.dst == 220.127.116.11
The isolated behaviour is this:
With this packet filtering, we can discover what and how credentials are delivered.
In the final episode we will take a look to avgbkill.sys Driver
Giuseppe 'Evilcry' Bonfa