RAT – ZIRCONIC

Darktrack

Posted on October 8, 2017 - October 14, 2017 by rhyolite

I was recently looking through a certain community of 1337 hax0rs and found someone trying to promote some malware that they allegedly cracked [Note: as I researched this, I later learned that the actual developer never charged for this RAT, so just the fact that the person who linked to this sample claimed to have cracked it shows that something’s up]. One of these is called Darktrack RAT, and the other is Reaper ransomware.

Jump to:
Static and Dynamic Analysis
Disassembly
Debugging
Conclusion
Hashes and IoCs

Initial Look

This is apparently a Darktrack 5.0 builder “with all plugs”. We’ll see about that, I guess. As I researched this, it looks like Darktrack 5 (also called Darktrack Colorful) hasn’t been released yet.

Running the builder gives you a pop up / license agreement window, and also drops two files into the %TEMP% folder:

2lWVy5LvsEb3quWh6S.exe
MBvI0Nh1JQcmVthRdCAy6TfJ2FA.exe

MBvI0Nh1JQcmVthRdCAy6TfJ2FA.exe is the panel executable that is presenting me with the EULA. Reading through the EULA doesn’t provide much interesting info. Someone (or some group) called Luckyduck appears to be responsible for Darktrack. One thing that’s interesting to me is that the English in the EULA starts out good, then gets noticeably worse as it goes along. Perhaps the beginning was just copied and pasted from somewhere else. The following snippet suggests that the product’s name is actually Darktrack Alien and the purported developer is this Luckyduck:

3. PRIVATE VERSIONS AND SOURCE CODE

3.1 THERE IS NO PRIVATE OR CUSTOM VERSION OF DARKTRACK ALIEN, IF YOU BOUGHT ANY KIND OF
DARKTRACK ALIEN VERSION THEN YOU BEEN SCAMMED.

3.2 THE SOURCE CODE ARE FULLY CLOSE, ONLY THE CODER OF DARKTRACK ALIEN (LUCKYDUCK)
GOT
THEM, DONT TRY TO FIND THEM NEITHER YOU WILL NEVER FIND THEM SO DONT LOOSE YOUR TIME.

The panel is pretty nice looking, actually:

There’s a help section, which tries to connect to the “Darktrack Tube” found at https://www.youtube[.]com/embed/0hByqnu6-Z4. This’ll be good to dig through later. There’s also a nice “About Me” section:

There are a bunch of names to look into someday, plus also what appears to be the website for Darktrack at www.darktrack[.]net. I also see that this appears to be Darktrack Alien 4.1, not the 5.0 version as promised by the original poster. Bug reporting is handled at https://forum.darktrack[.]net/.

Besides this stuff, the rest is sort of typical RAT panel features — client management panel, client builder/client settings, IP address map / victim geography, etc. The only problem is that one of the most important parts doesn’t appear to work — the client builder. If you can’t build your own clients, you can’t really do anything useful with this thing. It looks like this package came with a pre-built client from whoever cracked this (called “stub.exe”) but this won’t help anyone trying to create their own clients. Going back to the forum where I found this malware, the majority of ratings the post got indicated that the malware wasn’t functioning. I’m guessing that the only people who rated it as working were the original poster and his pals (or multis). I’m going to try to work with the stub.exe file anyway and see if I can get some more info about Darktrack from it.

Static and Dynamic Analysis

Taking a look at the stub.exe program, it’s a fairly big file (around 650k). It looks like it’s Delphi (ewww). Some people I know definitely are not fans of looking at entropy, but I like looking at it and it helps me, so bear with me if you disagree. Here’s an entropy plot of the stub.exe program before execution:

Looking at this, it seems fairly normal until you get to around 425k into the file, and then it looks like we have something there. Running the program, and then dumping the process with Volatility gives us something different, with the following entropy plot:

Whatever there was at the 425k area, it’s in use now. Looking in memory of the running stub.exe program, there’s some interesting stuff already:

xaf5c78 (40): C:\DOCUME~1\Owner\LOCALS~1\Temp\Klog.dat 0xaf5cf8 (40): C:\DOCUME~1\Owner\LOCALS~1\Temp\Klog.dat 0xafcfa8 (47): [String Search]-(9/27/2017 / 8:13:43 PM) 4 0xafcfe8 (46): [String earch]-(9/27/2017 / 8:13:43 PM) 0xafd028 (46): [String Search]-(9/27/2017 / 8:13:43 PM) 0xb042d8 (91): Num 4AltAltAltAltfNum 2Num 2Num 2Num 4ShiftShiftShiftShiftShiftShiftShiftShiftShiftShift4

Further on, we see what could be the config info of the client:

080IAM010010DAR8K89TR3SDTACK 4.1 Alien+ Local User 123456 127.0.0.1 notepad.exe SYSTEMROOT WINDIR APPDATA

The item at the top is the mutex used by this malware, I presume (to be confirmed) to ensure that only a single instance is running at a time on the victim’s machine. You can also see the default password and host (123456 and 127.0.0.1) listed there as well. We’ll have to see what the rest is for. Perhaps notepad.exe is injected or something.

Looking through the rest of the stuff revealed in memory suggests the following capabilities for Darktrack, though this needs to be confirmed by deeper digging:

Keylogging (keylogger file will be stored in the victim’s %TEMP% folder in a plaintext file called KLog.dat)
Possible Anti-Sandbox / Anti-VM capabilities (against Virtual Box and Sandboxie)
Anti-Debugging (reference to KERNEL32.IsDebuggerPresent and even a reference to SoftIce?)
Credential stealing:
Outlook/Exchange
Firefox
Skype
YandexBrowser
Comodo Dragon
Chrome
Possibly some Anti-AV capability
Possible harassment feature (open and close optical drive)
Supports Windows versions from Windows 2000 through Windows Server 2016 Technical Preview

There was another interesting string found in memory:

C:\Users\gurkanarkas\Desktop\Dtback\AlienEdition\Server\SuperObject.pas

This might provide another username to follow up on.

Disassembly

Let’s start looking at this thing in the disassembler. Opening this in Ida 5.0 (as I am still waiting for all that money from the Nigerian Oil Minister to hit my account, I cannot yet afford a paid copy of Ida) reveals some further detail behind some of the information we found by looking at it statically and dynamically. My earlier pieces on this site included many, many screenshots from Ida (and often from Olly) but I’m not going to kill you with 47 pictures of disassembly. However, I’ll try to mention a few things I found while poking around in the guts of the unpacked stub.exe.

Subroutine 425654 appears to be where libraries and functions are loaded. Take a look at the following:

KERNEL32.LoadLibrary and KERNEL32.GetProcAddress are basically ubiquitous. LoadLibrary takes a single parameter (the name of the library) and GetProcAddress takes two parameters, the handle to the module (library) and the name of the process to load. The sequence of events looks like this to me (at this time):

Push a proc name, then a library name. The stack should look like this, from last to first: library name, proc name
Call LoadLibrary (the return should be the handle to the library, which should go into EAX). At this point, the stack should just have the proc name on it.
PUSH EAX to put the handle to the library on the stack, so now we should have: Handle to library, proc name
Call GetProcAddress which should then return the address of the export
Then we see that the address of that proc is being moved into a structure, e.g.: MOV [ESI+20H], EAX, that is, the returned handle of the proc is being moved into the memory address of wherever ESI+20H is in that instance of the program
Iterates for many libraries and procs

I’m going to call sub 407CCC “MaybeLoadLibrary” and sub 407CE4 “MaybeGetProcAddress” [note that 407CCC was later revealed to be a call to KERNEL32.GetModuleHandle]. I’m also going to create a structure in Ida and then start labelling all of these references to proc addresses so it’s easier to read than [ESI+0CH].

449E60 looks like the sub that actually does the stored login harvesting from the various browsers supported by this RAT. Sub 460740 is a giant control subroutine containing a very large and ugly switch statement with 154 cases:

Within this switch statement, there are several cases that will pass the locations of stored credentials for the supported browsers and then call sub 449E60 to acquire them. The cases are:

0x54h Yandex Browser
0x55h Comodo Dragon
0x88h Google Chrome

The following parts of the switch statement refer to targeting other platforms, though with different underlying mechanisms than the areas above:

0x60h Skype
0x89h Firefox

An additional interesting case in this switch statement is 0x72h, System inventory (gathers some info about processor architecture). Stub.exe determines whether or not the processor is 32- or 64-bit using code beginning at location 4605C3. The subroutine called in that area, 45E340, makes a call to KERNEL32.IsWow64Process and determines the architecture based on the returned value.

I also found an evasion subroutine at 425F34. This sub starts by going to the `Software\Microsoft\Windows\CurrentVersion` Registry key. It checks the Product ID for the string `76487-337-8429955-22614` which would detect Anubis Sandbox. Other evasion subroutines I found are as follows, with their associated product:

Sub 425E7C checks Product ID for string `76487-644-3177037-23510` for CWSandbox
Sub 425DC4 checks Product ID for string `55274-640-2673064-23950` for Joe’s Sandbox
Sub 425DA0 calls KERNEL32.GetModuleHandle to check for `dbghelp.dll` for Threat Expert
Sub 425D7C calls KERNEL32.GetModuleHandle to check for `SbieDll.dll` for SandBoxie
Sub 425B78 VMXh magic value trick to detect VMWare
Sub 425C20 checks for `VBoxService.exe` as a running process to detect VirtualBox
Sub 4260C4 checks for debuggers via a call to KERNEL32.IsDebuggerPresent
Sub 42611C checks for debuggers by determining if the debug flag is set to 1 in the PEB at offset 0x2h
Sub 4261E8 checks for software breakpoints (0xCC, Int 3)
Sub 426174 not 100% sure — checks for `DAEMON` and also does the PEB antidebugger check again
Sub 42624C checks for Syser Debugger via a call to KERNEL32.CreateFileA to check for the files `Syser`, `SyserDbgMsg` and `SyserBoot`
Sub 4262AC checks for SoftICE Debugger via a call to KERNEL32.CreateFileA to check for the file `SICE`
Sub 4262E8 checks for SoftICE Debugger via a call to KERNEL32.CreateFileA to check for the file `NTICE`
Sub 426158 is the master anti-debugging sub for two user mode methods above, which calls 4260C4 and 42611C
Sub 4265AC is the master evasion sub, as it contains calls to the evasion subs listed above

One strange thing about this sample is that despite all of these evasion methods above, some of the functionality of the malware still appears to execute even though I’m not running it in a hardened VM. I’d expect none of the functionality to work given that this malware is detecting my VM.

Subroutine 45F938 looks like the overall system inventory sub. I was able to identify the following subroutines within it, and their apparent functions:

Sub 45F4A4 Identify the Windows Version
Sub 45F0F4 Identify user type (administrator / regular user)
Sub 405344 Appears to be called to store system inventory information once gathered
Sub 45F8C0 Has calls to USER32.GetForegroundWindow and USER32.GetWindowText the result of which is stored
Sub 45D74C is used to identify the presence of services on the victim machine by the port that is in use. The specific services that the malware looks for are: FTP (ports 20/21), SSH (22), Telnet (23), SMTP (25), Whois (43), DNS (53), DHCP (68), HTTP (80/8080), POP3 (110), NetBIOS (137/138/139), IMAP (143/220), SNMP (161), IRC (194 [usually this is 6667? Looks like they are just using the “standard” ports]), SSL (443), SMB (445), Lotus Notes (1352), MS SQL Server (1433), Oracle (1521), NFS (2049), MySQL (3306), ICQ (4000), and VNC (5800/5900). Any other open ports are listed as “Unknow [sic] Service Port.”
Sub 45DED4 uses subroutine 45D74C above to identify open and closed ports and services

Sub 4423BC contains many function calls related to setting up for and taking what is probably a screenshot of the victim’s desktop. Sub 442020 looks like it could be the network communications startup subroutine. Besides seeing that there appears to be a user-agent construction section within this subroutine, there are also a bunch of unlabeled calls in there. Two of these look very much like they could be a call to WS2_32.WSAStartup and WS2_32.Socket based on the parameters being passed. I can’t discern any of the other function calls one would normally look for (things like listen, send, recv, getaddrinfo, etc.) based on the rest of the disassembly but I’m going to label 442020 as possibly the network communications startup subroutine. Sub 43BD50 appears to be a performance monitoring subroutine, based on information from a very old article located at (http://bcbjournal.org/articles/vol3/9906/Writing_a_Performance_Monitor.htm?PHPSESSID=058081f577534833ddc780e5995cdbae).

Going back to the C2 switch statement referred to earlier, located at 460740, there is what I refer to as a harassment section (sometimes referred to as “fun stuff” by the malware developers). This subroutine falls under case 0x61 in the main C2 subroutine and is also a switch statement with 15 cases. The cases and associated functionality are as follows:

0x1 Unknown
0x2 Disable shortcuts and the desktop
0x3 Enable shortcuts and the desktop
0x4 Hide Program Manager
0x5 Show Program Manager
0x6 Turn the monitor off
0x7 Turn the monitor on
0x8 Unknown
0x9 Force Shutdown/Poweroff
0xA Force Logoff
0xB Force Reboot
0xC Hide Taskbar
0xD Show Taskbar
0xE Open Optical Drive
0xF Close Optical Drive

45C218 is a network sniffing subroutine. The full functionality is not 100% clear, however the code will call WS2_32.WSAStartup, WS2_32.Socket and WS2_32.Bind before likely making a call to WS2_32.WSAIoctl and one other function. This appears to be designed to sniff all packets that the victim machine is exposed to.

At location 468894, one can actually see the PE header for an executable file packed with UPX. Sub 4484C0 references this location, and while it’s a bit difficult to see what’s going on due to indirect calls, it looks like this sub sets aside 175,616 bytes in memory and then unpacks the file into that. One of the parent subroutines of this one appears to actually be the code found at this Github page: https://github.com/jasonpenny/democode/blob/master/dGinaTest/BTMemoryModule.pas. It seems that the malware uses this to load and parse a PE header from a file (probably the UPX-packed file we are discussing) and then appears to use the code to then load a bunch of SQL Lite functions. I’m guessing that this file that is packed is probably SQL Lite and it is probably being used to store data about the victim’s machine, but I’m going to dump this file and take a look at it to be sure. Sub 4484E8 is the overall subroutine that is responsible for this, and I’m going to tentatively going to call this the “Unpack SQL Lite and Setup” sub.

45A360 appears to be the subroutine handling opening a chat window with the victim. Sub 45A4EC is strange. I believe this is some sort of encryption subroutine. It has a few dozen cross-references in the disassembly, and uses a strange 51-character string which is “Yhuol08uJhGfCVzzXdFG.==+t&t&y7877wSWqwDw12123ghhGTG”. I’m going to label sub 45A4EC as “MaybeEncryption” and keep moving on, and maybe I’ll see something that will shed more light on this if I run this in the debugger.

After pulling the UPX file out of the stub with Hiew, I unpacked it and it appears to just be a regular sqlite3.dll. The file did get a few detections on VirusTotal, but the detections aren’t really ones I would trust. Based my own examination of the actual contents this appears to just be a SQL Lite .dll. I noticed that the Darktrack builder appears to store victim information in a SQL Lite file, so maybe the developer just uses SQL Lite for storing the various information about victims both on the panel machine and on each victim machine.

Debugging

Running the stub.exe program through the debugger really helped to clarify some things that were not clear in the disassembly either because my older version of Ida didn’t work 100% correctly or because there were some indirect calls in the code that were hard for me to discern via the disassembly alone. What I’m calling the master evasion sub, 4265AC, actually has some other things going on in it that I didn’t see before. The first thing is that I see near the beginning of this sub that the program tries to load a resource called “settings” which I presume is the RAT config info. Stub.exe isn’t able to load this from the .rsrc section. The error returned is “ERROR_RESOURCE_NAME_NOT_FOUND”. I’m not sure what’s wrong, but I’m going to keep going and see what other stuff I can find out via the debugger.

A small detail that I assumed was the case was confirmed while I was running stub.exe in the debugger. The RAT client does use the mutex to ensure that only a single instance of the malware is running on a victim’s machine at a time. Sub 42651C controls this. It will make a call to another subroutine to create the mutex and then it will make a call to KERNEL32.GetLastError. It will compare the error returned with the constant 0xB7 (which would indicate “ERROR_ALREADY_EXISTS”). If it does already exist, then the malware will terminate, while success or any other error returned will allow the malware to continue to execute. See below from my debugger:

Sub 426CF0 is another subroutine that has been greatly filled in via the debugger. This subroutine handles several calls to various WS2_32 functions that handle connection to the RAT host. Moving back over to the evasion subroutine beginning at 4265AC, I set a new entry point to put us back in the various anti-analysis tests. Sub 425FEC appears to get the current user name and compare it with the string “CurrentUser”. I’m not sure what this is supposed to accomplish. In doing some reading on the subject, this appears to be another way to detect certain sandbox environments. Another thing that became clear in the debugger is that the main evasion sub contains two calls to KERNEL32.GetTickCount to add this timing check to the other anti-analysis techniques. The two KERNEL32.GetTickCount calls are located at 426710 and 426858, and in this case the malware will terminate if there has been more than five seconds between the two calls.

Sub 425040 is very interesting now that I’ve been able to look at it in the debugger. I had previously named this as some sort of function loading subroutine, but running it in the debugger I see that there are some more interesting things going on. The Darktrack stub will invoke a new notepad.exe process and then allocates memory and starts to write to those newly allocated areas with what appear to be procedures to load from KERNEL32. It then tries to start a remote thread in that notepad.exe process, which in my test environment crashes notepad. After this, stub.exe goes a bit bonkers and enters a very processor intensive infinite loop (perhaps this is some sort of evasion technique itself). I’m going to step back a bit and see if I can get into other functions.

One subroutine that I am very interested in is sub 45A4EC. This one contains a really nasty looking string as mentioned earlier (“Yhuol08uJhGfCVzzXdFG.==+t&t&y7877wSWqwDw12123ghhGTG”). Earlier I’d guessed that this is some sort of encryption subroutine, so I set a breakpoint on this subroutine to see what happens here. When the breakpoint hit, I saw something very interesting which looks a lot like RAT C2 communication being used here:

We can see a lots of things passed here, such as the logged in user, the Windows version, the Darktrack version, the active window, the user type (administrator or regular user), and the password for this Darktrack stub (in this case, the default “123456”). After observing this subroutine for a bit, I noticed that there is a loop starting at location 4552AF and looping back from 455329 that uses that big ugly string to do a some sort of multibyte XOR of the system inventory information that we saw being passed to this overall subroutine before:

I tried to arrange the screen to best view the encryption/decryption loop and the area of memory where it can be seen that the string is in fact being encyphered via XOR. While it appears to be some sort of multibyte XOR, it’s not actually as simple as just taking the key and the plaintext and doing a multibyte XOR. There is some mechanism that I can’t discern that is adding some extra complexity to how this encyphering is being handled. Maybe someone with more experience with this could look at this someday. In the meantime, I suppose it would be possible to take the code from the malware, put it into some format of your choice, and use that to decypher traffic. I actually tried this just to be sure — I took the final encyphered text, put it where the plaintext should go, and watched as I ran the malware again and it decyphered what it had previously encyphered with this subroutine.

I tried manipulating various things in sub 426CF0 which appears to be the subroutine to connect to the RAT host. Looking in here confirms that the port used by this stub is 9633 by observing the call to WS2_32.htons. After stepping through this subroutine and trying to keep things going in the right direction by modifying memory or the code, I was able to get the stub to connect to my panel:

Right clicking on the connected Darktrack client reveals some options. Control center is probably the most interesting, but it can still be seen that from this quick menu there are options to obtain information about the victim’s machine, execute commands or open web pages on the victim’s machine, uninstall the RAT client or options to help organize the victim in the overall list of infected machines.

The control center is pretty slick and has several screens worth of options:

The interface is actually very nice, I’m impressed by how this was put together, compared with some other malware samples I’ve worked with. Looking through all of these options, this confirms a lot of functionality that was either suspected based on the static/dynamic analysis or was seen in the disassembly and debugging:

File manager functionality
Registry editing
Process manager
Windows Services manager
Installed application enumeration
Active connections enumeration
Startup manager
Clipboard manager
Surveillance functionality (online and offline keylogger, remote desktop connection, remote camera and microphone capture, remote shell, saved passwords harvesting, ability to download/upload and execute files on the victim’s machine)
Hosts file editing
Script execution
Dialog box generator
Networking management features (share enumerator, LAN scanning, port scanning, TCP sniffing)
Information gathering (system privileges and monitoring)
Miscellaneous features I classify as harassment features (ability to send a key input to the victim’s machine, print a file, text to speech, user chat, restart/lock/logoff/shutdown the machine)
Skype management (obtain users, contacts, file transfers, and conversation info)
RAT client management features (restart, close, uninstall, share client)

As I said before, some of these are very nice. For instance, the process manager functionality is very well presented and allows the RAT controller a lot of control over the running processes on the victim’s machine (such as suspending the process, killing it, altering the priority, etc.). The remote shell functionality is very easy to use, also.

This pretty much wraps up everything I’m interested in looking at in this particular malware sample.

Conclusion

Darktrack RAT has a nice user interface and contains a lot of functionality that would be of interest to a malicious actor. Nothing is too notable (when compared with other RATs) however the interface for the RAT controller is well-designed and easy to use. Some flaws emerged from examining this sample. For instance, the evasion subroutines do not fully work, even in an obvious analysis environment. The evasion routines also appear to be old/outdated due to some of the platforms targeted. Obfuscation of traffic via the XOR-based scheme is weak, especially when the key is so easy to obtain from the stub file and in the worst case one can just use the malware’s own subroutine to encypher or decypher traffic. The lack of a working client builder is a major issue, but this might have been an issue introduced by whoever cracked this particular copy of Darktrack. Overall, this was an interesting malware sample to analyse and reverse (even if it is Delphi).

Hashes and IoCs

Builder Archive
MD5 367ba50a6f212e9f722b72a92ae9b7a8
SHA-1 bf6f497f654c920d6485d723d310a7373f2b72f1
File Type RAR
SSDeep 393216:gO3Otn+wKEqgvtYgeUNDA1H0Kw1VvUACZ1t6HoF:MxK8CTXTw1VvSZ1tR
File Size 18.01 MB

Builder Main Executable
MD5 c2cae2249e422ec8d3d2da5712679262
SHA-1 35e2c4d521d0ce60ae1a78f88f116057367d83fa
Imphash 029f303dc25c06dd65b86262c6a9ed20
File Type Win32 EXE
SSDeep 98304:Bkl5IlOxWJBWN6O5zjfxIhItSQfmK36t+iuHWWoS9sHOAaMnq6+q3SATTzGypMLD:eKupzlefQOKU+iuHkORMnq6+4eLoMSQL
File Size 6.5 MB

Stub.exe
MD5 edc9c0a3eaaf592dba89ec3735ef022b
SHA-1 4c1196733e6bafa0b7d3e078896d0937111a9440
Imphash ee46edf42cfbc2785a30bfb17f6da9c2
File Type Win32 EXE
SSDeep 12288:BOqvQomCg4G6q90tmPvj+GU/ttJuqwh3EQiXRUVZs4ixsiNhkApRaw:9oovgbAKvBgtJuqwh3EQihUb1ifNh
File Size 627.5 KB

Dumped Stub.exe
MD5 ecae681b11dac1bb8facde439229f50a
SHA-1 391a75dc8b37a8716cb5856fae7c0dd965162930
Imphash 62201a8d9ef3cb9372a8618dffb33bd0
File Type Win32 EXE
SSDeep 12288:dOqvQomCg4G6q90tmPvj+GU/ttJuqwh3EQiXRUqr:5oovgbAKvBgtJuqwh3EQihUq
File Size 627.5 KB

UPX Packed sqlite3.dll
MD5 63f87edc6c0fcc88c9951119e39ccd7f
SHA-1 7e19bea3abcfec0ef66d3ee0ae01ce8812f6e32a
Imphash 9b821a35d20f9a8955f8d5e54b175675
File Type Win32 DLL
SSDeep 3072:XsABLvEx/5jcESAxpeGwuYwTPk9cJx9RjhkZ726EJS2vICXPnwL1nPTsb+jRsR8:XZLvExxjcixs+XNhkA6GSaRXfy1nbO
File Size 215.36 KB

Unpacked sqlite3.dll
MD5 dddf597f6546ddae942ce08bc773f646
SHA-1 6dde01d2699afa2c731a7344f5e8ad129a98ce4a
Imphash af2a1cf0ae9d12b4ef9c165cff60e4b3
File Type Win32 DLL
SSDeep 6144:OICvMnOTvcfgA0qBlJ89Ojo33C1oVDtY4sG2/WctyzuYf0ob8L23/8O:uvMnAA9BleOjoH4Ktm+jbFX3/l
File Size 379.86 KB

Stub-specific signatures:
Mutex: 080IAM010010DAR8K89TR3SDTACK (hard-coded to this stub, but likely changeable in a working builder)
C:\DOCUME~1\Owner\LOCALS~1\Temp\Klog.dat (keylogging results in plain text)
Ports 4157 and 9633 are two default ports in this particular copy of the Darktrack builder
XOR key: Yhuol08uJhGfCVzzXdFG.==+t&t&y7877wSWqwDw12123ghhGTG
Example C2 communication:
Local User|Owner@[redacted]|Windows XP|No[refers to web camera]|4.1 Alien+|Immunity Debugger – stub.exe – [CPU – main thread, module stub]|ENU|Administrator|123456|C:\DOCUME~1\Owner\LOCALS~1\Temp\|1|

I’m Back! (and Droidjack Analysis)

Posted on May 14, 2017 - May 30, 2017 by rhyolite

After a long break, I’ve decided to start posting material again. Last time I posted, it was to announce that I had just started doing malware analysis professionally. I’m still doing that, but now that I’ve gotten up to speed on my new role I wanted to start posting my own work again. I’m going to focus on things that I find interesting and also keep my work topics completely separate from my personal research. I’m also not going to focus on a strict timeline, because work demands often wreak havoc on any scheduling ideas I might have (the recent WanaCrypt0r incident is one such example). I’ll get to this stuff when I can, and post when I feel like it’s ready to go.

I’ve been interested in mobile malware for a while now, but we don’t cover that at work. I decided to take a look at what mobile malware is available on a certain underground forum and found several examples. On a separate but related topic, now that I’ve been doing this full time as my day job, I’ve learned that many malware developers try to hide behind claims that what they’re doing is either 1) creating “educational” malware to learn to code or 2) that they are peddling legitimate “system management” tools. Some good examples of these include Orcus RAT or NexusLogger (“protect your kids! Monitor your employees!”). Droidjack appears to be one of these Remote Admin “Tools” for Android devices. According to the DroidJack website (http://www.droidjack[.]net):

There is nothing that you can do with a PC that you can’t do using an Android phone. Since the power in the hand has grown so much, a control over that power is also needed. DroidJack is what you need for that. DroidJack gives you the power to establish control over your beloveds’ Android devices with an easy to use GUI and all the features you need to monitor them. [Emphasis mine]

Yes, because what we all need is to “control our beloveds…”. Total BS, and once you start to examine the software in more detail, you get to see the real picture painted by the developer.

On an underground forum, some kind individual uploaded a cracked DroidJack 4.4 builder with the following characteristics:

MD5 502b45d4d238e02f793a5b8669fa77fb
SHA1 6defd64dfde0bfdfec8b8d92371aa5d5dd5e4e95
SHA256 6dfef45751e209486aa714b8cf80fbd5b74b2f6f7c522bbb3a83c002ca3e5d6b
ssdeep:
393216:jf9tMySrGbauBeysCQTAjrW5yXkgKuRnKuU3R/T5GLaX:DQySSepbCQTarW54MuRCpEe
File size 17.9 MB ( 18811664 bytes )

Taking a look inside, there’s a readme file, let’s see what’s interesting in there:

Author:
——–
L.R Sanjeevi (c) 2015.

Good to know.

Setup Instructions:
——————–
1) Register a dynamic dns from no-ip or dnsdynamic.com
2) Choose a port (Example: 1337), forward the chosen port (1337) and 1334
(default) so u need to port forward 2 ports!
3) Generate the APK with the chosen port (1337) and ur dynamic dns and other details!
4) Do not scan it on virustotal or such sites so that it remains FUD longer.

Huh, well, that’s interesting right? There’s nothing necessarily wrong with places like VPS hosts, except that it’s common to see them hosting some shady stuff. But DroidJack is a legit tool, why do we need to go to these lengths? Also, don’t upload it to VT so that it stays FUD longer? For those unfamiliar with this term, FUD means Fully UnDetectable and is a common claim from skids uploading their tools to underground forums (and usually their garbage malware isn’t FUD anyway). Gee, sure seems pretty paranoid for a LEGITIMATE system management tool…

Ah, they have a helpful FAQ further down, here are some interesting questions and answers:

5) I have used the stealth mode but app icon is visible!
Ans) The app needs to be opened once at least then it will automatically hide the icon. In some devices after a reboot the icon will disappear.
6) I am getting an error when I try to bind with an app or game!
Ans) Try binding with a different app or game. Some apps or games will have checks when modifying so it will not allow modifications.
8) Can I use a different port instead of port 1334 (default port)?
Ans) No. Port 1334 must be opened only for DroidJack.
12) I am not able to upload files to the device!
Ans) Check if you have write access on that folder. You can see that by selecting the folder.
13) I am not able to delete SMS messages!
Ans) In Android 4.4 and above this feature will not work due to API restrictions.

So, there’s a stealth mode so the victim user can’t see that the RAT is installed… there’s a bind feature to bind the malware totally legit tool to an actual legitimate application… you can upload files to the device running DroidJack and apparently access SMS messages. Totally sounds like things you’d need to do for legitimate system management purposes.

The last line is sort of funny:

Feel free to contact me for support and suggest your ideas.

Uh, how about, stop writing malware?

OK, so looking in this thing, there are several files and folders in the builder after extraction. Looking in the Apktool folder, I see something called SandroRat.apk – Googling Sandro RAT results in a bunch of results regarding the targeting of banks using Sandro RAT in phishing. Such a legit tool! Maybe the developer of DroidJack stole this person’s work, or maybe it’s this dev’s work that’s being reused.

One thing that is nice about looking at something like Java (or .Net) is that because of the nature of the language, if you have the application, you typically have the source code (unless it’s been obfuscated, and even then you usually will get it). Scanning through the SandroRat.apk file, it looks like there’s code to support the following functionality:

SMS activity logging and tracking
- Incoming / Outgoing / Draft SMS messages
- The malware grabs the following fields:
  - FROMTXT
  - CNAME
  - FROMPHNO
  - MDATE
  - MYTXT
  - TOPHNO
- Goes after Whatsapp data (via the msgstore.db file)
- Gathers contact info, browser and bookmark history, and call records
- Gets GPS / location information
- Turn screen on/off
- Gather device information (system inventory function):
  - Brand
  - Serial number
  - Model
  - OS version / release
  - WiFi connection info (specifically the MAC address)
  - Device IP address
  - Device ID
  - Phone network operator name
  - List of installed apps
  - Current running task list
- Recording of audio (sample rate 11025, encoding bitrate 128)
- Ability to turn on WiFi or mobile data in order to achieve connectivity with the RAT controller
- Take photos and record videos using the onboard cameras
- Update feature
- Phone state information (Offhook, Idle, etc.)
- Call recording
  - Files will appear in the format “rec_*.amr” and will also log the date/time group of the call, state, and phone number

This file had numerous references to both Sandro RAT as well as DroidJack within it. Sort of makes me think that DroidJack is just the next iteration of Sandro RAT. Adding to this, looking inside the Droidjack.jar file (which is the main builder Java executable), one of the main blocks of code in there refers to Sandro RAT.

OK, let’s run this thing.

How friendly it is. The main panel is where you can view a summary of all of your victims, displaying their country, phone number, phone model and manufacturer, OS version, IP address, phone ID, the current running app and idle time. You’d think that if you were just using this for something “legitimate” like spying on your spouse or your kids that you would already know what country they’re in and their phone number… but anyway…

In the about tab, you can see that the developer isn’t shy about this:

Going to the Generate APK tab, we see this:

What’s that on the right? “The generated APK file should be installed on the victim’s Android device!” Wait, what? VICTIM? WHAT EVER DO YOU MEAN SIR, THIS IS A LEGITIMATE ADMIN TOOL… I’ll try to stop going off about this but can’t guarantee it. Anyway, here we can see the various characteristics we can set for the generated RAT client that would be used to infect a target device. These are App Name, File Name, Dynamic DNS provider, Port, Bind (so as to package your RAT with something actually legitimate), and the option to engage “Stealth Mode”.

The advanced options button brings up a new window with the following appearance:

So it appears that you can disable certain functionality that we saw in the quick review of the Sandro RAT code, specifically access to and/or harvesting of files, SMS messages, call data, contacts, location data and the ability to remotely record audio and/or still or video images. It also looks like there’s an obfuscator built into this to obscure strings using AES, DES, TripleDES or Blowfish. I’m going to skip all this for now, but will come back to this later.

OK, I generated a sample of the client using the following parameters:

App name: totally-legit
File name: totally-legit
Dynamic DNS: 127.0.0.1
Port: 31337 (because I’m SUPAR 1337)

I guess I should also note that at this point I haven’t seen anything drop or observed any “strange” network activity, so it appears that this builder was leaked “clean”. Great, so now we have our totally-legit.apk file. Let’s take a look inside…and it’s basically exactly the same code as the Sandro RAT apk. All that discussion about Sandro RAT from before, just s/Sandro RAT/DroidJack/ and we’re pretty much done. However, let’s try applying some of the obfuscation to the clients and see what happens.

What I noticed is that while the clients do come out differently, I’m just not seeing how they are obfuscated when applying the various crypto methods to the clients. Opening each of these files in my tool just shows me all the strings in plaintext. The only thing that’s different is that when I built a “stealth” client, there were a couple new classes added (“oa” and “qa”) which appear to use a combination of Base64 and Blowfish to help obscure things. I must not be getting something, though, because when I try to apply crypto to obfuscate strings, I expect to not be able to see any strings anymore.

I hope all this was interesting. I don’t currently have an Android test environment up and running, so this was done all statically. I went ahead and uploaded the files that came out of all this, maybe you’ll find these and play around with them yourself. For my first time ever looking at something for a mobile device, I think this isn’t an awful first attempt at looking at a mobile RAT.

Some mitigation recommendations:

Don’t download shady apps that might have something like DroidJack bound with it.
Given that the RAT has to use port 1334 (and seems to like 1337), one could be aware of strange traffic on these ports.
Given the functionality, one could try to observe the following indicators:
- If you observe strange files being saved on your device, such as the aforementioned “rec_*.amr” files or other indicators, that could possibly indicate this (or perhaps another) RAT is present on the device
- Also, unusual amounts of mobile data being used could indicate an infection, as this malware appears to be able to activate mobile data for connectivity purposes
- Finally, if the screen randomly or unintentionally turns itself on or off, this could also indicate something malicious present on the device

Here are the rest of the file hashes from DroidJack:

Sandro RAT .apk
MD5 9202458b25d8c56b85b5801c254c43e9
SHA1 97b1a631fd88b13327b00269f859f0e311b5ac93
SHA256
03ac348fc2978168bf86a1ba63a32f411e5642fbd11c95f59ff4d4c7e7b049c6
ssdeep6144:yuObopWPaR7mM++Iu8hK+CqoDTvJpsbV1dFqQOG8/8V4Sy8:yuObyjOu1+ToDTRpE1utDf8
File size 252.5 KB ( 258537 bytes )
https://www.hybrid-analysis.com/sample/03ac348fc2978168bf86a1ba63a32f411e5642fbd11c95f59ff4d4c7e7b049c6?environmentId=200

DroidJack Builder Main Executable
MD5 2f1d90b58522ebec2846c8dd27943b9c
SHA1 bc821c3ee2a4b86a08b4ec701cdb8fe79300b80c
SHA256
0842b4ac4b0c2198ea305f56fc5d649598a903dccfcbdd22ec22f2b0f68cb7be
ssdeep24576:lO0l4+lqJxEHBu6oF3NKfaHpvZwE+08jnt/o3Tim6xD8m:lBG++6ObJvOp0YSji/5
File size 1.6 MB ( 1675231 bytes )
https://www.hybrid-analysis.com/sample/0842b4ac4b0c2198ea305f56fc5d649598a903dccfcbdd22ec22f2b0f68cb7be?environmentId=100

Basic DroidJack Client
MD5 132f2b9f6775d51f2c776358f1176989
SHA1 2ecadde1b70c245d6725565ff1684468b3e2da31
SHA256 a664d235973da209501ef982754389b1515a96d7bee9dec6692dbe2d9b6a12ca
ssdeep6144:Eybt4/YCgynNsY3ShU7cM63ezK+Kylye4Rb/Il09UVGGOv:tWwXLYiM63eO+Ky0Rb/+6UVZOv
File size 254.4 KB ( 260475 bytes )
https://www.hybrid-analysis.com/sample/a664d235973da209501ef982754389b1515a96d7bee9dec6692dbe2d9b6a12ca?environmentId=200

Basic DroidJack Client (3DES)
MD5 e2391b89afbade0d1a95f653c9c89159
SHA1 e66f7b7ddb10f8e8311bd3b10bcbe0a79976a04e
SHA256 e1d10b2be5e94d4e16ed440a6a2bedc813e072dbed96eebb578345947128c7dassdeep6144:4yce4/wfBjdznG0Gy1YIAcplQ1C2mtYKhEMsDbwH7aqF8V1hV:5C4f1dhGyeI3plQRlDcH7ao8PhV
File size 264.8 KB ( 271171 bytes )
https://www.hybrid-analysis.com/sample/e1d10b2be5e94d4e16ed440a6a2bedc813e072dbed96eebb578345947128c7da?environmentId=200

Basic DroidJack Client (AES)
MD5 037065bbd4aa6deefff7cb0dbf015eb6
SHA1 2ed326cff4941759ea8d7011a705905801d8e9fb
SHA256 4553f97bff44cdafebab6b403ba7d1607a4720a85b9e63eac850b56049b4296d
ssdeep6144:5ny2w4lYCgynNsY3ShU7cM63ezK+Kylye4Rb/Il09UVGGOO:4qWXLYiM63eO+Ky0Rb/+6UVZOO
File size 254.4 KB ( 260479 bytes )
https://www.hybrid-analysis.com/sample/4553f97bff44cdafebab6b403ba7d1607a4720a85b9e63eac850b56049b4296d?environmentId=200

Basic DroidJack Client (Blowfish)
MD5 9c65c53a31b31c769efa7d7d01ae846b
SHA1 19b3a0f8e787ebb2c9b95f9ebd88d0a5181d2f92
SHA256
82c113ce99b9596db142e36de4ef54410213bd6df1f5f58df72d5392e0743a25
ssdeep6144:nyeo42MLxMh+BTENZZyQxERHyJVO43CtCV0MQ2mPxuGQeZW:yO2+xRBANnJxERSJV5CYV9sPxuuZW
File size 264.9 KB ( 271260 bytes )
https://www.hybrid-analysis.com/sample/82c113ce99b9596db142e36de4ef54410213bd6df1f5f58df72d5392e0743a25?environmentId=200

Basic DroidJack Client (DES)
MD5 b5c6dcc9e98463dbb06707d173bfa0ee
SHA1 b80b73fe66a2f846364d121d7591b32239f09abc
SHA256
80a785327ebbce92f43f2668581f5f55ca616b865d956adf89d92e56d86d680c
ssdeep6144:nyBF4j5NqMwyJPFcsPNsCqDz6002+RaIrKOKTH9UiF:y4j5NqXy5CsFODG00vRVXKjye
File size 264.7 KB ( 271088 bytes )
https://www.hybrid-analysis.com/sample/80a785327ebbce92f43f2668581f5f55ca616b865d956adf89d92e56d86d680c?environmentId=200

Basic DroidJack Client (Stealth)
MD5 0ed3e8f1dff311602aae835b5aa931a3
SHA1 b52a9fb2f93c2a2e724bdc48894fd3d290668b5f
SHA256 19a07f586fc7b52123ff20751a8601f03aa48fee248d33e231f79a27eeca27bb
ssdeep6144:kyWh4diqGpPtW5363otvNDwPnZRQZzegBk3WdmM73H:NXdiqaPtW5fvN0PZRGzeuE0mM3H
File size 264.8 KB ( 271122 bytes )
https://www.hybrid-analysis.com/sample/19a07f586fc7b52123ff20751a8601f03aa48fee248d33e231f79a27eeca27bb?environmentId=200

Dark Comet (Part II)

Posted on September 27, 2016 - July 5, 2018 by rhyolite

Continuing from last post… This is my first time disassembling a sample this big, so I’m going to do my best to explain things in a way that makes sense. It’ll be an interesting exercise to figure out how to keep track of such a large disassembly as I go along.

The start function is located at 48F888 and one of the first things that happens here is 0x30 is MOVed into ECX (768 decimal) and this is used for a loop that consists of pushing 0 onto the stack twice (so, at the end of this loop, you’ll have 1,536 zeroes pushed onto the stack). After this, there’s a parameter pushed onto the stack, located at 48E3C0 (which points to 0xA1) and then a call is made to a subroutine at 4076D4. This sub moves the TlsIndex then pushes a module name onto the stack before getting a handle to that module. Within this sub is another subroutine at 4051DC. In this subroutine, we see a couple of double words being set up to point to RaiseException (495014) and RtlUnwind (495018), and then a call to another subroutine at 4050C8 which directs some activity towards FS:

2dc1
I think this will be a lot easier to discern when being debugged. I’m curious what offset this takes at runtime. What’s also happening here is that you can see the pointer at EAX+4 being set to the location 405028, which contains some code related to calling an unhandled exception filter.

The next call after these branches is to 405174, where the code starts to get busier. A bunch of things are pushed onto the stack, and then we see that the double word at 4977D0 (which we saw had something put into it earlier, during the execution of subroutine 4051DC) is put into EAX and then this is TESTed. If the contents of dword_4977D0 is equal to 0, then we jump to the end of this subroutine and we return. Otherwise, execution continues and we hit the first block of code of 405174:

2dc2

We have the contents of the area pointed to at EAX being MOVed into EDI, then we can see that the target of the pointer at EAX+4 (which, currently points to that little block of code having to do with structured exception handling) is put into EAX. This then gets put into the target of var_4 and then EAX gets cleared out. We see something located at 4051C1 get pushed onto the stack – this turns out to be a single instruction, JMP sub_404B30, which contains exception handling information:

2dc3

Not to go too far down this rabbit hole, there are some interesting things in this sub 404B30. One interesting thing is one branch where a subroutine at 40450C is called:

2dc4

I’ve seen other examples of using “f-” instructions as part of some sort of shellcode techniques – I’m not too familiar with these instructions but my intuition is that this isn’t what’s going on here.

Later, after the call to 40450C, we see that something at dword 495010 is put into EDX and then EDX is TESTed to see if it contains anything – if it’s not 0, then it’s used as part of an indirect call. I couldn’t find any direct references to this double word (in terms of putting an address in there) so this is probably another thing that will have to wait until debugging. What’s interesting is that whatever is at this indirect call controls a significant portion of the remaining flow of this subroutine. If this subroutine returns 1, then the entire subroutine branches to an exit, and overall this subroutine returns 1. Otherwise, we continue to branch through these other areas related to exception handling. As part of the “failure” branch, we see a call that ultimate results in an indirect call to RaiseException:

2dc5

Various other calls are there, to RtlUnwind, to the unhandled exception filters, etc. Towards the end, there is a call to 407644. Several layers deep into this sub, we find some branches related to exiting the application with an error, and writing this information to a file:

2dc6

We also see that an error message can be put in a MessageBox:

2dc7

Overall, we step all the way back up to where we entered these many branches, and we’re back to 48F8A0, continuing now that the malware has set up its error and exception handling mechanisms.

Next we see EAX being zeroed out and then some things being pushed onto the stack before a call to CoInitialize. These things being pushed don’t really mean much to the CoInitialize call, though, as this takes only a single parameter which is reserved and must be null (per MSDN: “This parameter is reserved and must be NULL”). One of the things pushed, though, was a location (490656) which contains an instruction to JMP to a subroutine at 404DE4. This appears to go down a similar rabbit hole as earlier, with similar instructions to the error handling stuff discussed above. Shortly after this, there is a call to a subroutine at 481628. This is where we appear to get into the real “malwarey” activity.

This subroutine begins with some setup and also a reference to some of the exception handling material we already saw. Next we see the value 0x320 being MOVed into EAX and then a call to a subroutine at 402F00. The first thing this subroutine does is TEST EAX, EAX and then jumps if the result is less than or equal (JLE). I must be missing something, because I would think that if you just MOVed 0x320 into EAX, then you have a JLE, you should always follow the jump – it becomes sort of an unconditional conditional (equivalent to a JMP). Here’s a quick look at this area of code:

2dc8

I’m wondering if there is some sort of anti-disassembly tactic going on here. Sometimes you might see a conditional jump that appears to be “always taken”, like what I seem to observe above or something like this:

XOR EAX, EAX
TEST EAX, EAX
JZ <location>

So here we’re zeroing out EAX and then TESTing it – since we just zeroed it out, the zero flag (ZF) should be set a this point so therefore the JZ (jump if zero) should ALWAYS be followed. Sometimes malware authors can do things like this with the opcodes in order to get code to disassembly incorrectly (but still execute as intended, it’s just fooling the analyst). When I undefine this section of code and then start redefining different slices of the opcodes as code again, I don’t come across anything that appears to be meaningful, so for now I’m going to leave this be and just note that this might be someplace I need to come back to. Overall, I wouldn’t say that this is a terribly “hostile” sample, though, so I’m not as suspicious as I might be from seeing something like this.

Within this subroutine however, we eventually get sent to a somewhat mysterious, complicated and large subroutine at 401A0C. I’m not able to fully understand what this subroutine is doing – The beginning of the subroutine almost makes me think that it’s looking for an address:

2dc9

I suppose this could be anything, but I feel like those values look similar to addresses. I’m not sure if this would even make sense for a sample of this age, since I think that chances are pretty slim of finding anything at a specific address in any version of Windows you might find out there for the last few years. I don’t recall when address space layout randomization first became prevalent, but I believe it was at least several years before this sample was found in the wild. The rest of this sub is full of arithmetic operations, shifts, rotations, compare/exchanges, and bitscans. At one point, this subroutine also calls another subroutine that allocates memory somewhere. Normally I would associate all of this with some sort of coding routine, but I feel that this isn’t the case here. I’m going to rename this subroutine MaybeDecoding and move on. Just in case it’s of interest, here’s a higher-level view of this subroutine, to give some idea of the activity going on here:

2dc10

Coming back up to 481628, next we see calls to GetCurrentProcess and OpenProcess followed by Sleeping for 1 millisecond. One of the parameters PUSHed onto the stack is the token handle – perhaps the “coding” routine we were just discussing was some method to find an appropriate token. Perhaps the bit scanning functions had to do with that also.

Below this, we then see a call to GetTokenInformation:

2dc11

I notice that number we saw earlier, 0x320, being pushed as the TokenInformationLength. Seeing this number in relation to tokens makes me think that the earlier subroutine was in fact doing something related to finding a particular token or type of token. I’m going to rename the sub accordingly.

After this call to GetTokenInformation, we see additional calls to that token search subroutine, and then we see the malware looping around getting privilege names:

2dc12

The subroutine at 405728 compares CL with the non-zero memory contents of four bytes beginning at [EDX]. There is a mechanism to increment EDX, but what’s interesting here is that this sub 405728 does not end with a RETN but rather with a JMP to a subroutine at 405620. This subroutine runs through some of the same code as before related to token searching / possible antidisassembly and then also calls a subroutine at 4030FC (if the token search function was successful, as an intermediate step) and 405530 (after 4030FC, or simply as the next subroutine in the event that the token search / anti-disassembly routine was unsuccessful). 4030FC conducts a number of arithmetic and floating point operations using EAX and ECX. 405530 leads us down some paths that includes code we’ve seen before, like the area that was focused on shifts/rotations/bitscanning of information. These branches within these subs lead us to more manipulations, more shifts/rotations of values, and even an exit path.

Stepping back up to 481628, the next subroutine being called is 4814E8. Within this subroutine, we see the process token being opened, and also some error handling functions. What’s very interesting is that later on in the code, we see the privileges of a token being adjusted in order to remove all privileges:

2dc13

I wonder if this is some scheme to hide activity from the user. I’ve read about techniques involving replacing user privileges with administrator privileges so that the malware can more stealthily conduct activity that normally would appear in Event Viewer. This is going to be my working model for this, at least for now, as I haven’t really heard of malware that “de-escalates” privileges. After some more calls to the manipulations code we’ve already seen, sub 481628 finishes and we’re back up top at the Start function.

The next subroutine, 48DECC, conducts more transformations of data and floating point operations. 48DF40 is the next subroutine called, and we see “DCDATA” being MOVed into EDX shortly before this call, as well as having its own exception handling being set up right before that. The major things that 48DF40 do include:

– Sub 48DDC0 which involves finding/loading/locking/freeing the .rsrc section, as well as some of the previously seen floating point operations and token activity
– Sub 405864 which involves more of the same token activity and floating point operations

The next sub, 48DF40, contains many, many manipulations and floating point operations, as well as a possible exit path. I’m not interested in digging through what all of these are doing, as I want to keep moving on to what I consider to be the main malware operations. After that, sub 40F21C calls GetModuleFileNameA and also one of the manipulations subs from earlier. Next, 40A588 was not obviously interesting, though right after that we see an offset for “GENCODE” MOVed into EAX and then a call to 47DFE4.

Digging into the subroutine at 47DFE4, I continue to get bogged down in what appear to be endless manipulations of various registers and floating point operations. I’m not really trying to reverse this sample in the sense that I want to understand exactly how it works (how it is written / could be rewritten) but rather I want to disassemble it in order to try to glean the interesting parts of the malware functionality. It’s a good exercise in any event, as this is the largest sample I’ve ever tackled, but I think I’m going to change my tactics on this. I’m going to start looking at specific functions and strings of interest and then work around those in order to try to get to the interesting stuff faster.

Going in no particular order, I’m going to take a look at mutex creation in this malware. We saw earlier that a mutex DCPERSFWBP was created. This string appears in the malware and is referenced in a subroutine at 42F27C, which turns out to be a very interesting subroutine. We see some manipulations and floating point operations being done, and then we see some of these being done in the context of notepad.exe:

2dc14

The first reference we see to DCPERSFWBP follows this, right before a call to CreateProcessA:

2dc15

After that, we see something odd:

2dc16

We have a series of strings being used in conjunction with a call to a subroutine at 42EB10. This subroutine consists mainly of calls to an earlier privilege name searching subroutine, and then a call to VirtualAllocEx and WriteProcessMemory.

After that, we see calls to GetModuleHandle and GetProcAddress:

2dc17

This looks familiar and strange at the same time. This looks like the malware is getting a handle to a module and then calling GetProcAddress in order to get the address of a function to import. Maybe this is something to do with how Delphi handles this sort of task. I’m more used to seeing the LoadLibraryA/GetProcAddress combination.

Towards the end of this block of code is a call to a subroutine at 42EBD8. The main things happening in this thread are a couple of calls to subroutines that call VirtualAlloc and WriteProcessMemory, then a call to CreateRemoteThread:

2dc18

Another aspect of this malware that’s interesting to me is the surveillance capabilities, such as the keylogging and webcam functionality. There are some strings that lead me to these places, such as CTRLA and WEBCAMLIVE. I notice that there seems to be a common subroutine found whenever named functionality appears to be called – see a couple of screen shots below:

2dc19

As you can see, the offset for WEBCAMLIVE is MOVed into EDX right before 405974 is called. This code comes from an absolutely monumental subroutine beginning at 4850A8.

2dc20

Here we see this same subroutine being called, this time in the context of recording CTRL key combinations in the keylogger. This code comes from a subroutine beginning at 481A6C.

405974 is interesting because there doesn’t appear to be an obvious call to something that would cause the action to take place. 405974 begins with a few comparisons and tests:

2dc21

As you can see, there is a comparison of two registers (EAX and EDX) and then a TEST between the same two (though in different order). What we’re missing from this view is that prior to 405974 being called, a parameter is put in EAX while EDX receives an offset pointing to the action – here’s a view of this coming from 4850A8:

2dc22

Going back to 405974 now, we:
– compare the two – if equal (zero), we jump to a RETN
– test the two – again, if equal (zero) we jump to another test
– at this second test, we test to see if EAX is zero – and if so, jump to a couple lines of code where we compare the variable 4 bytes behind the current offset in EDX to what is in EAX, and then RETN
– if EAX is nonzero, then we test EDX to see if it’s nonzero (see below for more code), continuing with the code if it ISN’T zero (at which point, we execute a couple of lines to do a similar comparison of what lies in memory at EAX-4 bytes with EDX)

2dc23

– If we get through all of that, then we MOVe with zero extend what is in memory at the location specified at EAX into ECX, then subtract the lower byte of ECX from the contents of EDX, jumping to a RETN if this results in a nonzero result
– Next (see following image), assuming we didn’t jump to the RETN, we can see some manipulations taking place – contents of EBX get saved by PUSHing them onto the stack, then we see the contents of memory at EAX-4 bytes being MOVed into EBX. The contents of EDX-4 bytes are subtracted from EBX, then we get this new result PUSHed onto the stack also. What’s in ECX (which, remember, contained the contents of memory at EAX-4 bytes with the contents of EDX subtracted from the low byte at CL) has 0xFFFFFFFF added (with carry) to it. The result of this will be to take the contents of ECX, add 0xFFFFFFFF and the result of the carry to ECX. ECX and EBX get ANDed and then we see the contents of memory at EAX-4 bytes being subtracted from ECX, then ECX being subtracted from EAX, and then finally ECX being subtracted from EDX. Some sort of decoding?
– In the next block of code, the contents of the memory stored at the address resulting from the sum of ECX and EAX are MOVed into EBX. This then is XORed with the contents of memory located at the address resulting from the sum of ECX and EDX. This block finishes with a Jump if the zero flag is set.

2dc24

– If the jump is not taken, then we ADD 4 to ECX and loop (via the JS) if the sign flag gets set, otherwise we follow a branch where we POP EAX, add EAX to itself, and the POP EBX before continuing to the RETN. Stepping back through the code, the contents of EAX should be the last thing PUSHed onto the stack (which was the contents of EBX, which had the contents of EAX-4 bytes MOVed into it before having the contents of EDX-4 bytes subtracted from it) and the contents of EBX should be the next thing on the stack, which in this case would be the returned value from a successful call to recv in the WS2_32 library. In order to find this, I had to move up several levels in the code, and will put another screenshot below showing this.

2dc25

Screenshot showing the contents of EBX, code copied from subroutine 479E38:

2dc26

Coming back to 405974 now – there’s a final branch to look at, see below:

2dc27

– Once the loop is finished (and the JNZ is taken), then we enter a block where we bitscan forward (BSF) EBX with itself, and then shift the result to the right by three places. This new value in EBX gets added to ECX, and then we come to another conditional jump. If the jump IS taken (sign flag did NOT get set) then we head over to that branch already discussed where we have values being POPped into EAX and EBX. Otherwise, we go to the last block of code to look at in this section.
– If the sign flag does get set, then we move the contents of ECX+EAX into AL, compare AL with the contents of ECX+EDX, and then POP the last two values on the stack into EBX before returning, which in the process loses the first value that was left on there (which was the contents of EBX, which had the contents of EAX-4 bytes MOVed into it before having the contents of EDX-4 bytes subtracted from it) and leaving only the second thing PUSHed onto the stack in EBX (the returned value from a successful call to recv in the WS2_32 library, after the BSF and SHR have been executed on that value).
– Finally, keep in mind that the discussion of what is in EBX here is going to be dependent on exactly where this subroutine is called – in the example I gave above, this particular instance of using the code had to do with values returned from the call to recv, but this sub 405974 is called 357 times in the malware so obviously the values of the registers can vary widely from call to call.

So what does this entire mess actually mean? To be honest, I’m not entirely sure. Overall, we have an action being taken depending on whether or not a parameter being passed to the function matches a string stored at an offset. I’ve observed MANY different situations and offsets in this code. At first glance it’s almost as if the malware has a parameter passed to the function and then it checks against several different command names within that function. It sort of appears to be an inefficient way of doing this, since in some cases you almost cascade through a large number of code blocks checking along the way. It also looks like this is some sort of way to decode an address within the malware execution. There’s a .reloc table within the PE header, perhaps this is some way of finding functions within the code if the malware is able to ascertain where parts of itself have been relocated? I think I need to look at more samples of malware written in Delphi so that I could get a better idea of what is happening. Coming from a background of looking at samples written in other languages, this code doesn’t appear to really “do” anything so I suspect that this is just my lack of knowledge of Delphi showing through. At least you got treated to an excruciating walk through of some assembly code!

Moving on to other malware functionality, going through the functions imported in IDA I notice that there’s a subroutine beginning at 478968 that contains a call to CallNextHookEx. The malware could hook things for various reasons, but in checking this subroutine out we see that it begins with some code that includes the call to CallNextHookEx, and then a check is done to make sure that the hook code passed is nonzero:

2dc28

If it is nonzero, then we jump to a code section built around another call to CallNextHookEx, before doing some cleanup and returning. Otherwise, the code continues to an area containing a couple of large switch statements (overall a couple dozen cases, see graph below):

2dc29

Within here, we see code that calls GetKeyState and also branches that will allow the malware to add other information to the log file, such as the code that adds in statements about the clipboard status and other things:

2dc30

Here’s an example of one of the subordinate subroutines showing a reference to text that gets added to the log file for clarity:

2dc31

I went looking for a reference to UrlDownloadToFileA and found one in the giant subroutine 4850A8. Here’s a graph of that subroutine to give you some idea of the scale:

2dc32

Somewhere very close to the bottom one finds a reference to UrlDownloadToFileA. It’s not clear from the disassembly precisely what file is being downloaded, however we can see later that if the file is successfully downloaded that this status update is reported and also this file is executed after downloading:

2dc33

We can also see the reference to Bots here, suggesting this is part of the functionality offered via this malware. What I’ve also noticed in browsing through this very large sub is that there appears to be another subroutine that is similar in its role in the malware to 405974. You might recall that 405974 was the subroutine taken apart in some detail earlier, and this was one of the subroutines that would “do” whatever was being referred to in the malware according to a particular string. I’m noticing that this new subroutine at 405A84 also appears to fulfill a role like this (and happens to be referenced 296 times, a similar volume compared with 405974). I’m not going to go into the same amount of detail in looking at 405A84, but this new one seems simpler while also have some resemblance to 405974.

Further along in 4850A8, we see references to some of the bot-type functionality related to floods:

2dc34

Here’s a reference to remote shells:

2dc35

References to using the webcam and capturing audio:

2dc36
2dc37

There are many other references that suggest additional functionality such as getting torrents, sharing the host desktop, getting the victim’s clipboard contents, playing sounds, opening and closing the CDROM drive, opening Task Manager, and other things.

Here’s a little thing I noticed going through other areas of the code:

2dc38

I’ll keep this in mind for the signatures part of this analysis.

471E70 is where we see references to several registry changes, including ones related to persistence:

2dc39

In the subroutine at 483A04, the malware obtains and names the version of Windows it is running on:

2dc40

For some reason, the only version it explicitly names is Windows Server 2003 (in terms of referencing a string):

2dc41

I’m getting to the point where I need to move on from this sample, so let’s take a look at some of the stuff I dumped using Volatility. Starting with the second of the two iexpore.exe processes, there was code injected at two places. Looking at what I dumped from the first place (at 0x420000), I see what appears to be several hundred lines of a sled that all lead to a jump to 0x76AD9204, example below:

2dc42

I tried attaching a debugger to this process to see what was at this location, but none of them allowed me to (all of my versions of Olly and Immunity). The other dump from this same process, at location 0x5FFF0000, didn’t make any sense, so I’m not sure what this is.

Looking in the dumps from the notepad.exe process, two of the dumps contain code that I can’t make sense of (I wouldn’t call them spurious just because I don’t understand them…) but one of the injected areas does appear to contain code with many indirect function calls (found at 0x1A0000):

2dc43

I’m wrapping up this analysis at this point, as think I’ve gotten as many interesting things as possible out of this, particularly during the dynamic analysis in the previous post. I could spend a lot more time on this sample, and maybe down the road I should so I can get a better handle on Delphi. There are a few more things I’d look at if I had more time:

– Figure out what is preventing me from attaching to one of the injected iexplore.exe processes and further investigate the address I found in the injected code. One other thing of note related to this, is that while there is a TLS section (which as far as I know is normally associated with antidebugging techniques), IDA does not see an entry point associated with it.
– How the domain name is generated within the code, as I did not see any string looking like “max19916.hopto.org”
– The log file generation code (it appears to be pretty simple, but I would still be interested in seeing the specific code that does this)
– Where the code actually specifies the msdcsc.exe file name (again, I did not see a direct reference to this in the disassembly, nor for the directory name generation)
– Mutex name generation (we saw that there is a static piece that we did find, but there is also a dynamically generated piece)

References:
https://en.wikipedia.org/wiki/.bss

Findings and observations:
Remote access trojan coded in Delphi. Extensive functionality to monitor user activity (inputs, files, desktops, remote shells, audio/video equipment). This malware also appears to have capabilities more often related to botnets (such as DDoS capabilities).

Recommendations:
Avoid downloading files hosted publicly on DC hubs (or other P2P services). Don’t allow users access to these services without some vetting (e.g., an IT professional may need access to bittorrent in order to obtain Linux ISOs). Keep regular users from running in administrator mode, as there was a bit of lost functionality for the malware in terms of system control when run as a regular user. Blocking the domain max19916.hopto.org would be good, but given the number of shady sites hosted at hopto.org it might be best to simply block the entire domain.

Conclusion:
A very interesting sample, particularly around how it was being distributed. The extent to which one could invade a victim’s privacy with this malware was a bit disturbing.

Report:malexe005

Hashes:
MD5:be1fa25529308e909381777bcd7f0e92a
SHA1:9a3c2eefb12d527d2d7377a8c6f96854baf566c9
SHA256:d673493ef6288338bace20a165b32b7fb897400e943c7b313a0cef3d1cba22dd
ssdeep:12288:C9HMeUmcufrvA3kb445UEJ2jsWiD4EvFuu4cNgZhCiZKD/XdyF5:uiBIGkbxqEcjsWiDxguehC2SE

Dark Comet (Part I)

Posted on September 20, 2016 - September 6, 2016 by rhyolite

I went looking for new places to find malware and decided to check out DC hubs. Think of these places as sort of like Napster (for those of you who can remember Napster). I’ve heard of private hubs, and have been on a few myself, but those were generally both vetted and clean. I went looking through various public hubs for stuff that sounded shady.

Most of the stuff I found was just pirated software or movies, but there were a couple of users who I suspect might be the same person due to the naming style and content shared. On a few hubs I found users with some variation of “torrent” in their names (e.g., torrent_com, torrentino_net), etc. and their shares looked pretty odd:

dc1

This folder is basically 17gb of files all with extremely similar sizes (as you can see, typically only a few bytes different from one another). Running ClamAV against my newly acquired files, I found “a few” things:

dc2

Looks like the motherlode of malware here. What I thought was interesting was that the file names spanned all types of files and applications – you saw copies that were supposed to be installers for Adobe products, Windows, games, utilities, porn, music, everything. I’m guessing that this person put these out there hoping to catch people searching for particular things who wouldn’t necessarily check his file list (and I guess they were also hoping that someone wouldn’t notice anything amiss about a full copy of Adobe Lightroom that was only 574k).

Each username appeared to have a different set of malware – for example, in torrentino_net’s folder “НУЖННННННОООООООООООООООООООООООООО” (means needed or necessary, as adverb) was almost entirely Dark Comet, while the other user had different things (though it was mostly that Trojan.Inject-15717 you see in the screenshot above). I’m going to see what I can find in one of the Dark Comet samples.

Static Analysis

I usually start with the strings, but this is relatively a huge file compared with what I normally work with (roughly 10 times the size in bytes of stuff I’ve worked on so far) so I started with some tools first. PEiD, as well as some strings found in the file, indicate some crypto signatures, as well as the fact that the program was written in Delphi:

dc3

I wouldn’t really call these crypto signatures since what we seem to be looking at are functions used to check the integrity of the file. The ZLIB reference suggests that something is compressed in the file. Maybe this has a .PDF or something inside it that it uses for something.

PEview indicates that there’s a TLS table, so maybe this is for anti-debugging (to get code to execute before the debugger breaks the program). The number of data directories looks normal. This program has several sections, and all of them except one looks normal in terms of virtual / raw sizes:

dc4

Normally if I saw a section that had such a discrepancy between the raw and virtual size, I’d think that there was something packed there. In the case of .bss, this is a section that contains zero-valued bits initially (at the time of execution) and so only the length of the section, but no data, is stored in the header.

We also see there’s a whole lot of stuff in the .rsrc section:

dc5
Opening the malware in Resource Hacker, we see that it has a bunch of mouse pointers under “Cursor” in the .rsrc section. There is also a section called “String Table” with some interesting things in there. The very first table (4083:0) appears to contain strings related to a help function. 4085:0 contains many strings that make me think of a keylogger:

STRINGTABLE
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
{
65344, “Yes to &All”
65345, “BkSp”
65346, “Tab”
65347, “Esc”
65348, “Enter”
65349, “Space”
65350, “PgUp”
65351, “PgDn”
65352, “End”
65353, “Home”
65354, “Left”
65355, “Up”
65356, “Right”
65357, “Down”
65358, “Ins”
65359, “Del”
}

Keys such as “Left”, “End”, “Ins” and so on don’t have a visible character associated with them, so if you were logging keystrokes you would need some other way of recording these. I’ve seen samples that would check for whether or not these keys were pressed and would then insert these strings into the keylogging file so that the author can follow what’s being input.

As I go through these, it’s interesting to see that all of these strings are in English. The rest of the string tables are basically error messages of one type or another, but nothing too useful for our purposes. The last section is “Version Info” which contains:

dc33

Going back to PEview, the address table of the .idata section gives up LOTS of information, all in the clear. It imports:

advapi32.dll
avicap32.dll
comctl32.dll
gdi32.dll
gdiplus.dll
kernel32.dll
msacm32.dll
netapi32.dll
ntdll.dll
ole32.dll
oleaut32.dll
shell32.dll
shfolder.dll
urlmon.dll
user32.dll
version.dll
wininet.dll
winmm.dll
ws2_32.dll
wsock32.dll

Things I found interesting in these imports include:

Advapi32.dll: I see RegQueryValueExA, RegOpenKeyExA, and RegCloseKey. I wonder if this is used to do a system inventory or other reconnaissance of the host system. I also see RegSetValueExA, RegEnumValueA, RegDeleteValueA, RegCreateKeyA and RegCloseKey so I’m guessing there’s something done in the registry to either make the system more friendly towards the malware (such as disabling a firewall) or to achieve persistence. A very interesting import here is AdjustTokenPriveleges, which can be used to enable privileges for a process. I’m guessing that this is used in conjunction with the process injection/replacement functions (discussed later in this section) to gain additional permissions for the malware. I also see CreateServiceA, StartServiceA, and DeleteService, so the malware probably runs at a service and might also achieve persistence as a service.

Kernel32.dll: I see VirtualAlloc, CreateProcessA, CreateThread, CreateRemoteThread, ReadProcessMemory, ResumeThread, SetThreadContext, WriteProcessMemory, etc., all of which in conjunction with the call to NtUnmapViewOfSection makes me think that there is process replacement or injection going on in this sample. GetTickCount is there, which could be used for anti-debugging but also has legitimate uses such as being part of a random number generation function (as seen in prior analyses). I see FindFirstFileA and FindNextFileA which tells me that this thing probably looks for a particular file somewhere, maybe in %system%. WriteFile is here, which is always a good one to look for in terms of file system signatures. RaiseException is interesting – I wonder if this is used to do something confusing with the SEH to obfuscate execution. When I disassemble this, we should have a better idea of whether or not this is the case. WinExec is imported, which could be useful to look at in the disassembly to see what is being executed on the host. I see TerminateProcess, which makes me wonder if this sample spawns a new copy of itself and then terminates the original in order to make debugging more difficult. PeekNamedPipe is a cool one to see, this lets you look at the data in a pipe without modifying it, so perhaps this is used in some sort of C2 function (maybe a reverse shell?). CreatePipe is also imported, by the way. I see imports for GetVersion and GetVersionExA, so I’m thinking this is either part of a system inventory or the malware checks to see that it’s running on a compatible version of Windows (or both). GetWindowsDirectoryA shows that there’s probably something done in that directory, maybe this is where the malware installs itself or otherwise achieves some sort of persistence or stealth. I see GetDriveTypeA and GetDiskFreeSpaceExA, probably as further info for the system inventory. DeleteFileA is imported, and like with WriteFile, it will be interesting to see what this sample deletes (probably the original copy of the malware after it installs itself). CreateMutexA is imported, probably to help ensure that the malware doesn’t run multiple copies of itself on the same host or perhaps to share resources. I see CreateDirectoryA being imported, which is interesting because typically I don’t see malware create directories, usually just a single file somewhere already existing (such as the %system% directory, the malware’s working directory, or maybe a temp file directory). Finally – Beep is imported. Why?

Ntdll.dll: This is interesting to see because typically this is not called directly by legitimate programs (as far as I know) – programs typically call something in kernel32, which then calls something in ntdll.dll and so on. NtUnmapViewOfSection is imported as part of process replacement/injection. There is also an import for NtQuerySystemInformation which can have several uses that I’ll speculate on. One piece of info available from this function is the number of processors or information on running processes. There are also various ways to use this function to seed random numbers.

Ole32.dll: I see that CoCreateInstance is imported, which creates a COM object. During disassembly, I’ll look to see how this is used specifically.

Shell32.dll: I see ShellExecuteA and ShellExecuteExA imported, which again will be useful to look for to find additional things run by this malware. SHEmptyRecycleBinA is imported – this is interesting, because typically if a file is deleted from the command line, it doesn’t go into the recycle bin (I’ve never seen a sample that left anything in the recycle bin), so I wonder why this malware needs the function. I’m guessing this is to help hide its tracks, though.

Urlmon.dll: URLDownloadToFileA is imported, which is great, because this tells me to look for the malware reaching out to the author to obtain a new file of some sort.

User32.dll: GetKeyboardType is not one that I’ve seen before, but would make sense in the context of a keylogger. This function is pretty self explanatory, but note that it doesn’t necessarily give you the language of the keyboard but rather the type (e.g., IBM enhanced, Nokia 1050, etc.) of the keyboard. The exception would be that it could tell you if it was a Japanese keyboard. This function will also let you know the number of function keys on the keyboard. There are also many, many functions related to windows and graphics imported here (not to mention what’s imported with gdi32.dll). Not sure why you’d want your malware to do this.

Version.dll: I see GetFileVersionInfoA is imported – I wonder how this is used. Maybe to check the version of the malware so that an update can be performed?

Wininet.dll: InternetReadFile, InternetOpenUrlA, InternetConnectA, HttpQueryInfoA, FtpPutFileA… Great! Lots of stuff to look out for during dynamic analysis. Looks like it takes some sort of information from the host and sends it somewhere (probably the logged keystrokes, at a minimum).

Winmm.dll: PlaySoundA is imported. I wonder what this malware could possibly be doing playing sounds, as that seems like it would be a pretty conspicuous thing to do. Maybe this malware masquerades as a game or something?

Wsock32.dll: Lots of good stuff here. WSAStartup is imported, which is always nice to see in the disassembly because this will tell you where the networking functions are beginning (which also helps you find the points at which any obfuscation or encryption is going to be applied, either outgoing or incoming). I see socket, connect, send and recv which would be used to set up the client side of connectivity, but I also see bind, listen, and accept, which would allow this to function as the server side as well. I see gethostbyname, so I’m expecting to see a DNS request at some point.

Now to get to the strings. I think that most of the interesting material has already been covered using the earlier tools, but there are still some interesting strings that I found in the file (full list of meaningful strings can be found in the .pdf report of this analysis):

FastMM Borland Edition
2004, 2005 Pierre le Riche / Professional Software Development

Another indication of Delphi.

%s, ClassID: %s
%s, ProgID: “%s”
%s (%s)

Always interesting to see anything being constructed dynamically by the malware.

-.-.-.-
[::]
need dictionary
stream end
file error
stream error
data error
insufficient memory
buffer error
incompatible version
1.2.3
1.2.3

Maybe this uses version 1.2.3 of zlib?

80211_OPEN
80211_SHARED_KEY
WPA_PSK
WPA_NONE
RSNA
RSNA_PSK
IHV_START
IHV_END
NONE
WEP40
TKIP
CCMP
WEP104
WPA_USE_GROUP OR RSN_USE_GROUP

Maybe this has something to do with a system inventory?

\Internet Explorer\iexplore.exe
explorer.exe

This tells me that the malware does something with Internet Explorer (perhaps the process replacement/injection).

TThemeServices
Theme manager
2001, 2002 Mike Lischke

I guess this refers to another tool used in the creation of this malware.

1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
ShortCutText
\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\
Layout File
KbdLayerDescriptor

Something being done regarding the keyboard layout, I’m guessing as part of the system inventory or something to do with the keylogging.

IP :
IP Mask :
Broadcast adress :
Status : UP
Status : DOWN
Broadcasts : YES
Broadcasts : NO
Loopback interface
Network interface
Software
Microsoft
Windows
CurrentVersion
Policies
System
DisableTaskMgr
Software
Microsoft
Windows
CurrentVersion
Policies
System
DisableRegistryTools
Software
Microsoft
Windows
CurrentVersion
Policies
System
EnableLUA
Software
Microsoft
Security Center
AntiVirusDisableNotify
SYSTEM
CurrentControlSet
Services
SharedAccess
Parameters
FirewallPolicy
StandardProfile
EnableFirewall
SYSTEM
CurrentControlSet
Services
SharedAccess
Parameters
FirewallPolicy
StandardProfile
DisableNotifications
SYSTEM
CurrentControlSet
Services
wscsvc
Start
Software
Microsoft
Security Center
UpdatesDisableNotify
Software
Microsoft
Windows
CurrentVersion
Policies
Explorern
NoControlPanel
Software
Microsoft
Security Center
AntiVirusDisableNotify
SYSTEM
CurrentControlSet
Services
wscsvc
Start
Software
Microsoft
Security Center
UpdatesDisableNotify
Software
Microsoft
Windows
CurrentVersion
Policies
Explorern
NoControlPanel
drivers\etc\hosts
drivers\etc\hosts
I wasn’t able to open the hosts file, maybe because UAC is enabled in remote computer!
UNKNOW
STOPED
RUNNING
PAUSED
STARTED
STOPED_P
CONTINUE_P
PAUSED_P
Not Available
Removable
Fixed
Network
CD-ROM
RAM
WinDrive
Bytes
KiB
MiB
GiB
Local drive (default)
IsWow64Process
kernel32
HARDWARE\DESCRIPTION\System
SystemBiosDate
HARDWARE\DESCRIPTION\System
Identifier
HARDWARE\DESCRIPTION\System\CentralProcessor\0
Identifier
HARDWARE\DESCRIPTION\System\CentralProcessor\0
VendorIdentifier
Unknow
Windows NT 4.0
Windows 2000
Windows XP
Windows Server 2003
Windows Vista
Windows 7
Windows 95
Windows 98
Windows Me
0x%.2x%.2x%.2x%.2x%.2x%.2x
memory allocation failed!
%.2x-%.2x-%.2x-%.2x-%.2x-%.2x
64 bit
32 bit

This looks to me like a whole lot of system inventory information. It also seems to indicate changes made by the malware to the host to report back to C2.

\uTorrent\
*.torrent

What’s that about?

Offline
Online
Invisible
Busy
Be Right Back
Idle
Away
On The Phone
Out to lunch
Offline
Online
Invisible
Busy
Be Right Back
Idle
Away
On The Phone
Out to lunch

These look like instant messenger statuses. Is this some sort of trojan that masquerades as an instant messenger client? That’s not really what I would expect from a file called Deadliest Catch…

SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\
HKCU\
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg\
command
item
hkey
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupfolder
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupfolder\
location
HKLM
HKCU
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupfolder

I always like to see specific references to the registry…

/k
cmd.exe
open
*.*

Looks like something is executed on the command line. The /K switch, though, runs a command and then returns to the command prompt. Not sure why you’d want to use this with malware.

Sockets
%d.%d.%d.%d
0.0.0.0
WSAStartup
WSACleanup
POST /index.php/1.0
Host:
BTRESULTHTTP Flood|Http Flood task finished!|
myappname
BTRESULTVisit URL|finished to visit
Times.
BTERRORVisit URL|An exception occured in the thread|
DATAFLUX
UntProcess
SYSERRNot a valid range set!
SYSERRCannot open remote process for reading..
SYSERRCannot create the output file!
SYSINFORemote process (
) successfully dump in
Normal
Hight
Real Time
> of the Normal
< of the Normal
Low
ACCESS DENIED (x64)
LanErr
SVW3
127.0.0.1
.255
LanList
LanErr
PortScanAdd
TScan
TScanRange
BTRESULTSyn Flood|Syn task finished!|
BTRESULTUDP Flood|UDP Flood task finished!|
FTPPORT
FTPPASS
FTPUSER
FTPHOST
FTPROOT
FTPUPLOADK
FTPSIZE
TReceiveFileThread
UPLOADFILE
FILEBOF
FILEEOF
FILEEND
FILEERR
TSendFileThreadU
FILETRANSFER
FILEBOF
FILEERR
FILEEOF
FILEEND
TReceiveDataFlux
UPFLUX
TScreenThumb
THUMB
TSendDataFluxThread
DATAFLUX
TSearchThreadU
TCaptureWebcam
CAMERA
#CAMEND
ENDSNAP
MONSIZE
DISPLAY
MONSIZE0x0x0x0
DEFAULT MONITOR (DISPLAY)
OK|Successfully started..|
ERR|Socket error..|
ERR|Cannot listen to port, try another one..|
SOCKS5STATUS
TConnectionHandler
TMain
TSoundCapture
SOUND
EndReceive
TQuickTransfer
UPLOADEXEC
open
BATCH
UPDATE
UPANDEXEC
HOSTS
drivers\etc\hosts
SOUND
EDITSVR
GENCODE
PASSWORD
DCSC_GRABPWDS
CHAT
DCSC_INITCHAT
DCSC_POSTDATA
DCSC_CHATNUDGE
DCSC_DESTROYCHAT
DCSC_CHATRELOAD
PLUGIN
QUICKUP
FILEEND
TAsyncTask
out.txt
tmp.txt
Mozilla
BTRESULTMass Download|Downloading File…|
DownloadSuccess
DownloadFail
BTRESULTDownload File|Mass Download : File Downloaded , Executing new one in temp dir…|
BTERRORDownload File| Error on downloading file check if you type the correct url…|
ping 127.0.0.1 -n 4 > NUL && ”
GetTorrent

Always great to see this sort of stuff that will help give indications of what networking activity is supposed to happen. Also note the mention of the flood tasks. Maybe this has some sort of botnet-like feature where C2 can use infected hosts to DDoS a target. It also appears to have a scan function. Some of these strings may even be commands that the malware uses to execute instructions from C2. I wonder what those .txt files are. Also – this thing gets torrents?

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ/*-+.=

Looks like a slightly nonstandard base64 index. Notice the special characters after Z which here are /*-+.= while in a regular string it would be just +/. This also makes it longer than a regular base64 index. Also, the numerals come in the beginning of this string while in a standard index they would come after the alphebetic characters. In this index, the lowercase letters also come before the upper case, which would be reversed in a standard base64 index.

.log
dclogs\
::
:: Clipboard Change : size =
Bytes (
\newl\
\space\
ONLINESTROKES\newl\::
ONLINESTROKES
[ESC]
[<-]
[NUM_LOCK]
[F1]
[F2]
[F3]
[F4]
[F5]
[F6]
[F7]
[F8]
[DEL]
[INS]
[SNAPSHOT]
[LEFT]
[RIGHT]
[DOWN]
[UP]
CTRLA
CTRLV
CTRLC
CTRLX
CTRLP
CTRLZ
CTRLY
CTRLF
dclogs\

This all looks like strings related to the keylogging function that I’m presuming is part of this malware. This also helps in that it appears we’re looking for files with a .log extension in a dclogs folder.

taskmgr.exe
notepad.exe

I see this string out in the middle of nowhere, so to speak. Maybe this also has something to do with the process replacement, etc.

TScreenCapture

Maybe this malware takes screenshots, too.

systeminfo
SYSINFO
Software\Microsoft\Windows\CurrentVersion\Run
Software\Microsoft\Windows\CurrentVersion\Run
Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Userinit
UserInit
Software\Microsoft\Windows NT\CurrentVersion\Winlogon

This gives me some ideas of what changes may be made to the registry by the malware, and also some idea of how persistence may be accomplished.

127.0.0.1:1604
#KCMDDC51#-
Unknow
5.3.0

Not really sure what these threads are for, but it looks like something might be started locally on 1604. Maybe this is the port that C2 will use for a remote shell or other networking.

DelDir
rmdir ”
” /s /q
attrib ”
” +s +h

Covering its tracks?

NETDRV
REFRESHPROC
PROCESS
REFRESHMODS
MODULES
KillProcess
SuccesProc
KILLPID
KillSProcess

Maybe this allows C2 to kill processes locally.

ActiveOnlineKeylogger
UnActiveOnlineKeylogger
GETLOGSHISTORY
KeylogOn
dclogs\
ActiveOfflineKeylogger
UnActiveOfflineKeylogger
ActiveOnlineKeyStrokes
UnActiveOnlineKeyStrokes

More indications of keylogging functionality.

OpenCD
CloseCD
Set cdaudio door closed wait

Seems like odd functionality for typical malware.

Indications that there is a bot functionality to this malware as well.

GETDRIVEINFO
DELETELOG
REFRESHLOGS
PREVIEWF
ADDSOCKS5
SOCKS5FLUSH
SOCKS5CLOSE
DUMP
DOWNLOADFILE
DOWNLOADFOLDER
DWNFOLDERRES
UPFLUX
UPLOADFILE
SEARCHFILES
STOPSEARCH
ACTIVEREMOTESHELL
DOSCAP
SUBMREMOTESHELL
KILLREMOTESHELL
DESKTOPCAPTURE
DESKTOPSTOP
WEBCAMLIVE
WEBCAMSTOP
DESKTHMB
REFRESHWIFI
WIFI
SOUNDCAPTURE
SOUNDSTOP
QUICKUP
PLUGIN
PASSWORD
CHAT
CHATOUT
CHATNUDGE
CLOSECHAT
FTPFILEUPLOAD
URLDOWNLOADTOFILE
PWD
OFFLINEK

Some of these are pretty creepy, referring to things like webcam, soundcapture, etc. Perhaps more commands that the malware parses from C2 somehow to turn functionality on or off.

PADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDING

Uh, OK.

Some final notes before getting into the dynamic analysis. I notice a .reloc section, which is interesting because I usually don’t see these in samples (and especially not in .exes, typically in .dlls). One sandbox reported seeing French language PE resources, the rest being either neutral or US English.

Dynamic Analysis

For this part, I ran the malware three different times: 1) as a regular user; 2) as administrator; 3) as a regular user with Fakenet. I’m going to look at the regular user run first.

Running the malware from the command prompt, nothing appears to happen. One funny thing is that the working directory for the malware “disappears”, as does the executable. The files are still there, it’s just that they’ve been hidden. Sort of stupid, actually, because you’d think that any user running this would notice that their directory is “gone”, especially if you ran it from somewhere like your Downloads directory. Maybe I’m wrong, but it just seems a bit overkill.

I also noticed this pretty much immediately:

dc6

msdcsc.exe is not something that I recognize, but I do recall seeing notepad.exe in the strings from the malware, so both of these together appear suspicious to me. Msdcsc.exe appears to have the same strings as the original malware executable glancing through it. This file resides in the Documents directory in a folder called MSDCSC, and again both this directory and the msdcsc.exe file are both hidden. The MD5 value of both files confirms that they are the same.

Regshot revealed some changes:

Key added:
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\System

Values added:
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\Run\MicroUpdate: “C:\Users\Linux Derp\Documents\MSDCSC\msdcsc.exe”
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\System\DisableRegistryTools: 0x00000001
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\System\EnableLUA: 0x00000000

I see some files added also:
c:\Users\Linux Derp\AppData\Roaming\dclogs\2016-08-31-4.dc
c:\Users\Linux Derp\Documents\MSDCSC\msdcsc.exe
c:\Windows\ServiceProfiles\LocalService\AppData\Roaming\PeerNetworking\39781e30c2068da8ca1d5675055b8c116729b03c.HomeGroupClassifier\a155957c683b979ad24b1ae52041d2d2\grouping\tmp.edb
c:\Windows\System32\Microsoft\Protect\S-1-5-19\13356aac-165b-496d-8fb0-21b47bc91dbd

That one file in the beginning is VERY interesting. This path and file name lines up with some strings we saw earlier. This directory is not hidden, actually, so I guess the author figured that the user wouldn’t venture into this directory. The file 2016-08-31-4.dc isn’t hidden, either. The contents clearly show that keystrokes are being captured, along with times, the applications/windows used for input, and clipboard changes:

dc7

Some of the exact strings highlighted earlier as indications of a keylogger can be seen in the capture above. I tried typing a bunch of things into the cmd.exe window, but noticed that the log file was not updated. After some testing, it appears that data is written to the log file when I open a new program (in my test, I opened a bunch of new cmd.exe sessions). Testing this some more, it appears that keylogging data is saved in a buffer and then written to the log when there is data being typed into a new window. For example, simply opening a program from the start menu did not trigger writing to the log. Opening a program by typing the name into the start menu triggered writing to the log. Opening Internet Explorer via the start menu did not trigger logging, however typing an address into the window DID trigger writing to the log. Typing input into Internet Explorer without hitting enter triggered writing to the log immediately, however typing multiple commands in a row into a cmd.exe window did not trigger logging on its own. Probably not important, but sort of interesting to see different ways to get this program to take actions.

Looking in Process Monitor, first I’m starting with the original malware process. Several pages in, after loading several libraries and enumerating many entries in the Registry, I see a odd operation, a call to CreateFileA for C:\MA\lab\JBDyF4FCmWXH.dcp (which is not found). Much later on, we see the malware try to call CreateFileA for the path C:\Users\Linux Derp\Documents\MSDCSC\JBDyF4FCmWXH\msdcsc.exe, which is again not found. Another call is made, this time to C:\Users\Linux Derp\Documents\MSDCSC\msdcsc.exe which is ultimately where we see the file being copied to and hidden.

Shortly after, at this point we seem to see that the malware starts the process of copying itself into the new directory that we found:

dc8

Then the writing of the file to the new location:

dc9

After this, we see the malware trying to make some changes to the registry, some of which are successful, one that is not:

dc10

The value that was successfully set to the MicroUpdate key is the full path of the new copy of the malware. I think what we’ve observed here was the malware checking to see if it was already installed, and not finding a copy of itself, it installed itself.

We see some more registry changes:

dc11

We see how the malware uses the /k switch for cmd.exe, when it hides the working directory of the original malware file:

dc12

Going through the rest of the results, there are thousands of keys/values enumerated by the original malware process, but at the end you don’t see any new processes being created, but looking in Process Monitor for processes whose parent was the original malware process (PID 944), we see some interesting things. First we see that there were two cmd.exe processes created, PIDs 2636 and 1860, which hid the original malware file and its working directory. Later, we see the first of the new malware processes created (PID 560) which is started via the command line:

dc13

msdcsc.exe again looks for the JBDyF4FCmWXH.dcp file, as the original process did. A bit later, some strange behavior as the new malware process starts trying to make many modifications to the registry:

dc14

One interesting change is that the malware sets the EnableLUA value to 0, so that Windows will not notify the user when programs try to make changes to the computer:

dc15

We also see that it tries to set AntiVirusDisableNotify to 1 (true):

dc16

I’m noticing that some of these operations are unsuccessful as we’ve been going through here. I’ll be curious to see what happens in the run of this malware where I was in admin mode.

Later, I see the creation of the other malware-associated process, the notepad.exe process (PID 2404):

dc17

We see the malware process (560) again set values in the registry, like the original process, apparently around persistence:

dc18

Autoruns confirms this:

Later on in the results, I see this operation being repeated many times, all successfully. I’m not sure why the malware does this. Maybe this is some sort of error.

The new malware process (560) then sets up the location for the keylogging file:

dc20

Here is the first write to the logging file:

dc21

Looking at the final malware process, the notepad.exe process created (PID 2404), shows it was started from the command line by the 2^nd process (560). I’m not really seeing this process do that much, on the face of it. Its strings in memory match what should be there for a legitimate notepad.exe process. There’s also no visible window, when I tried to access that via Process Explorer. This notepad process, however, does have a mutant, which my other legitimate notepad.exe process does not:

dc22

That mutant name matches one of the strings found in the malware exactly. The malware process also has some handles to places in the registry (under HKLM) having to do with locales that my legitimate notepad.exe process doesn’t have.

Looking at the 2^nd process (560) in process explorer, one very weird thing is that there appear to be hundreds (maybe thousands) of handles to \Device\Afd (auxiliary function driver). We also see a few other things:

dc23

There’s a handle to a token, and also a handle to a couple of threads within the new notepad.exe process. I’m guessing that the malware injected something into notepad.exe based on this and also on how we found all of those function imports earlier that were associated with process injection/replacement. There’s also a mutant DC_MUTEX-K5DAH26. I’m not seeing this string in what I found earlier, though I do see DCMUTEX. One other little note from the Process Explorer review is that the malware’s description of msdcsc.exe is “Remote Service Application” which is something we found during the static analysis.

I happen to notice there are two iexplore.exe processes running (PIDs 2968 and 356). Sort of strange, because I did start Internet Explorer from the start menu, however, I only ran a single copy. The first process seems legitimate (2968). When I try to bring the second process to the front using Process Explorer, I’m informed that there is no visible window for the process. Some of the interesting stuff in the GMER output includes GetKeyState, CallNextHookEx, SetWindowsHookExW, GetAsyncKeyState, UnhookWindowsHookEx and others. These are things I’d associate with keyloggers, especially GetAsyncKeyState and GetKeyState. We saw that iexplore.exe was a string within the malware:

dc24

Looking at the network traffic, I see that the malware tried to resolve a domain, max19916.hopto.org:

dc25

For some reason the address didn’t resolve, and no traffic was observed. Max19916.hopto.org appears to be up, though…

Looking in the run I made as administrator, I noticed some differences in the results from Regshot. For example, in the run as a regular user, we saw these keys added:

HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\System
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\DC3_FEXEC

In the admin mode run, we see:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion\Explorern
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion\Explorern
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\Policies\System
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\DC3_FEXEC

Running as admin, we see some other interesting changes that we didn’t see running as a regular user:

———————————-
Values added: 45
———————————-
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion\Explorern\NoControlPanel: “1”
HKLM\SOFTWARE\Wow6432Node\Microsoft\Security Center\AntiVirusDisableNotify: “1”
HKLM\SOFTWARE\Wow6432Node\Microsoft\Security Center\UpdatesDisableNotify: “1”
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion\Explorern\NoControlPanel: “1”

The changes already mentioned in the user mode run were also observed, these are just the additional successful changes made to the registry. Otherwise, the behavior appears to be more or less the same, at least what I can see from this perspective.

I decided to dump the memory from the user run and see what, if anything, turned up in there. I used Moonsols to dump the memory, and then I ran some Volatility plugins on the results just to see what I could find. I’m not the strongest Volatility user, by any means, though I’m working on it. Using this tool on this sample is a good opportunity for me, so please bear with me if this is very basic to you.

There is a Volatility plugin called psxview which can be used to find processes using several different methods. The book The Art of Memory Forensics has a great description of processes and their structures in the sixth chapter of the book. There are several methods for finding processes listed here, and the psxview plugin incorporates all of the ones listed in the book into a single plugin. What’s nice is that, as you can see in the screenshot below, the plugin gives you a table showing each process with its offset and PID and then whether or not it would have been found using a certain method (for example, in the example below, the cmd.exe process, PID 1688, would have been found using any method).

dc26

ExitTime would show when a process was terminated but for some reason still is showing up in the process list. This could happen if another process has an open handle to a terminated process.

Going through the list reveals nothing out of the ordinary. There’s something weird at the end, though:

dc27

This is the end of the listing, and what it looks like is there is a running process (PID 504) that was unrevealed by all methods except for thrdproc (thread scanning). Each process must have at least one active thread. This method scans for thread objects and then maps them back to an owning process. Like I said before, I’m a fairly new user with Volatility, so maybe this is some idiosyncratic thing that I just am not familiar with, but it appears to be a very well hidden process that I’m assuming is associated with the malware. The point of the Process Crossview plugin (psxview) is that rootkits are unlikely to have hidden themselves from the active process linked list and then ALL of these other methods – however it looks like this one almost did that.

I was unable to dump this process with the procdump plugin (it told me that it couldn’t find a process with PID 504 and advised me to try with an offset, which also did not work). Psscan does not reveal this mysterious process 504. I tried memdump, using an offset and the PID, but nothing.

Running the privs plugin revealed some info about what privileges are available to the malware process msdcsc.exe (PID 560), and others such as the injected/replaced iexplore.exe process, but nothing appeared to be out of the ordinary.

The mutantscan plugin revealed the two malware mutexes that we know about, but nothing really new here. Grepping the mutantscan results didn’t reveal anything near the offset of process 504.

dc28

Grepping the results of the thrdscan plugin does show a bit more detail about this thread:

dc29

It’s definitely still open…running the threads plugin doesn’t reveal anything, though. I decided to try dumping the memory from my admin run and seeing if psxview revealed something similar, and what I got was pretty weird:

dc30

In another run of the malware in user mode, I wasn’t able to replicate the original run’s mysterious nameless process. I’ll still keep this in the back of my mind, but I think it might have just been some weird artifact from either the VM or Moonsols.

On another note, I ran the malfind plugin and had it dump whatever was injected into the two iexplore.exe processes (PIDs 2968 and 4036) and the notepad.exe process (PID 2404), so when I get to disassembly I’ll be able to see what the malware put in there.

At this point I’m wrapping up the dynamic and static analysis, and am going to move into the disassembly. Maybe in the future when I’m better with Volatility I’ll try some new things, but for now I think I’ve exhausted all avenues on this one.

Disassembly and Debugging

Ugh:

No, it’s not a Super Star Destroyer – it’s a graph of all the function calls in this thing.

Zoomed in 110%:

dc32

References:
https://en.wikipedia.org/wiki/.bss