Dark Comet (Part I)

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.

#BOT#VisitUrl
#BOT#OpenUrl
HTTP://
www.
http://
BTRESULTOpen URL|
is now open!|
#BOT#Ping
BTRESULTPing|Respond [OK] for the ping !|
#BOT#RunPrompt
BTRESULTRun command|
Command successfully executed!|
#BOT#CloseServer
BTRESULTClose Server|close command receive, bye bye…|
#BOT#SvrUninstall
BTRESULTUninstall|uninstall command receive, bye bye…|
#BOT#URLUpdate
.exe
BTERRORUpdate from URL| Error on downloading file check if you type the correct url…|
BTRESULTUpdate from URL|Update : File Downloaded , Executing new one in temp dir…|
#BOT#URLDownload
RPCLanScan
GateWay
GetActivePorts

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:

dc19

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 2nd 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 2nd 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:

dc31

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

 

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

 

Leave a Reply

Your email address will not be published. Required fields are marked *