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.
Results below are taken from pescanner.
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 ================
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
 CryptEncrypt > Encryption  CopyFileA  CreateFileA  CreateFileW  DeleteFileA  WriteFile  GetTempFileNameA  GetTempPathA > File manipulation  TerminateProcess  CreateProcessA > Creates a process and does file manipulation  FindResourceA  LockResource > Dumper? > String: "CONFIG"  GetProcAddress  LoadLibraryW > Injector? Look for function calls in the 'Strings' section as well.  HttpQueryInfoA  HttpSendRequestA  InternetCloseHandle  InternetConnectA  InternetOpenA  InternetQueryDataAvailable  InternetReadFile > Communication to a C2 server? Notice the call to InternetReadFile. > Could be communicating the encryption password for a ransomware  IsDebuggerPresent > Debugger detection  RegCloseKey  RegDeleteValueA  RegOpenKeyExA > Modify registry
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
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.
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).
CONFIGresource 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.
IsDebuggerPresentcall that I have to watch out for. ScyllaHide in x64dbg is great for that.
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
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 intercepted the above HTTP request towards
brb.3dtuts.by. I see some interesting bits here:
/ads.php. You’ll need an API like
InternetReadFileto read what’s happening there. Remember that we saw
InternetReadFilein our suspicious IAT from pescanner output.
&p=is hex. Could be encrypted
We see two entries here:
C:\Users\REM\AppData\Roaming\brbbot.exe. I’m assuming for persistence.
brbconfig.tmpis created in the same directory I ran the malware from ‘Desktop’. The file’s content is encrypted.
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.
Shows one process only: brbbot.exe. It didn’t really try to kill itself or spawn any other processes.
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.
brb.3dtuts.by? (Top priority)
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
Another minor point of interest I found while scrolling around is the password used to create the hash used to encrypt/decrypt
Attaching a x64dbg and setting a breakpoint on
CryptDecrypt reveals the decrypted contents of
We’ll come back to this string later.
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
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:
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.
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
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:
After re-infecting the machine with
brbbot.exe, we see a wild calculator appear!
It also launches a new one every 30 seconds.
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.