Practical Malware Analysis, Lab 1-1

May 07, 2017 malware

Twitter Google+ Facebook LinkedIn

This is a walkthrough of the Lab 1-1 from the book Practical Malware Analysis: basic static malware analysis techniques are applied to the samples Lab01-01.exe and Lab01-01.dll.

Please note that there may be many different (and even better) ways to solve this lab, so the one described here is just my solution.

The samples for this lab can be downloaded from here.

Let’s start!

1) Upload the files to VirusTotal and view the reports. Does either file match any existing antivirus signatures?

I will compute the hashes first and then look for those hashes on VirusTotal.

Lab01-01.exe

Lab01-01.dll

The VirusTotal reports are available at the following links:

• Lab01-01.exe

• Lab01-01.dll

At present date both files are identified as malicious:

2) When were these files compiled?

The compilation time can be seen by opening each file with PEview and looking under: IMAGE_NT_HEADERS / IMAGE_FILE_HEADER / Time Date Stamp. This image shows the Time Date Stamp of Lab01-01.dll:

The compilation time of the two files is:

3) Are there any indications that either of these files is packed or obfuscated? If so, what are these indicators?

We can analyze the files with PEiD or ExeinfoPE and see that there are no indications of them being either packed or obfuscated.

Looking at their PE sections also does not reveal any sign of packing or obfuscation: sections names are as expected and their sizes in memory and on disk have coherent values.

Lab01-01.exe

Lab01-01.dll

A good sign that neither one is packed is also that both contains many meaningful strings.

C:\malwarelab> strings2 -nh Lab01-01.exe

!This program cannot be run in DOS mode.
$
Richm
.text
`.rdata
@.data
UVWj
@jjj
@jjj
ugh 0@
_^][
SUVW
h00@
_^][
SUVW
@jjj
@jjj
h|0@
D$Pj
l$\u
S$QWR
FxRVP
D$$3
D$8R
t$<f
p0@
t0@
x0@
T$PR
hL0@
h|0@
hD0@
_^]3
hp @
 SVW
%8 @
%D @
%\ @
%` @
CloseHandle
UnmapViewOfFile
IsBadReadPtr
MapViewOfFile
CreateFileMappingA
CreateFileA
FindClose
FindNextFileA
FindFirstFileA
CopyFileA
KERNEL32.dll
malloc
exit
MSVCRT.dll
_exit
_XcptFilter
__p___initenv
__getmainargs
_initterm
__setusermatherr
_adjust_fdiv
__p__commode
__p__fmode
__set_app_type
_except_handler3
_controlfp
_stricmp
kerne132.dll
kernel32.dll
.exe
C:\*
C:\windows\system32\kerne132.dll
Kernel32.
Lab01-01.dll
C:\Windows\System32\Kernel32.dll
WARNING_THIS_WILL_DESTROY_YOUR_MACHINE

C:\malwarelab> strings2 -nh Lab01-01.dll

!This program cannot be run in DOS mode.
$
Rich
.text
`.rdata
@.data
.reloc
L$xQh
IQh `
L$4PQj
D$\D
t       WVS
NWVS
u7WPS
u&WVS
_^[]
CloseHandle
Sleep
CreateProcessA
CreateMutexA
OpenMutexA
KERNEL32.dll
WS2_32.dll
strncmp
MSVCRT.dll
free
_initterm
malloc
_adjust_fdiv
exec
sleep
hello
127.26.152.13
SADFHUHF
/0I0[0h0p0
141G1[1l1
1Y2a2g2r2
3!3}3

4) Do any imports hint at what this malware does? If so, which imports are they?

Since the samples are not packed the imports can be viewed either with Dependency Walker, IDA Pro or even by examining the strings contained in the samples.

The sample Lab01-01.exe imports the following functions from KERNEL32.dll:

CloseHandle
CopyFileA
CreateFileA
CreateFileMappingA
FindClose
FindFirstFileA
FindNextFileA
IsBadReadPtr
MapViewOfFile
UnmapViewOfFile

This is the same list as showed in the upper right pane of Dependency Walker:

Imports from MSVCRT.dll are functions that are included in nearly every executable as wrapper code added by the compiler, so they are not of much interest.

The sample Lab01-01.dll imports functions from KERNEL32.dll and WS2_32.dll.

These are the functions imported from KERNEL32.dll:

CloseHandle
CreateMutexA
CreateProcessA
OpenMutexA
Sleep

The functions from WS2_32.dll are imported by ordinal so their names are not immediately visible in Dependency Walker. In order to find their names, it suffices to look for the ordinal value in the lower pane that shows all importable functions. For instance, the function with ordinal 0x4 is connect:

The names of the functions imported by ordinal are automatically showed within IDA Pro. Here is the complete list of imports for Lab01-01.dll:

So these are the functions imported by Lab01-01.dll from WS2_32.dll:

closesocket
connect
htons
inet_addr
recv
send
shutdown
socket
WSACleanup
WSAStartup

5) Are there any other files or host-based indicators that you could look for on infected systems?

By examining the strings from both samples, I can identify two references to file names that can be used as host-based indicators:

• File: Lab01-01.dll
• File: C:\windows\system32\kerne132.dll

Notice the name kernel132.dll (with a 1) trying to disguise itself as the legitimate kernel32.dll (with an l).

The string SADFHUHF appears to be the name of a mutex. A mutex is often used by malware as an infection mark, that is to check if another instance of the same malware is already running on a system. Searching for SADFHUHF in IDA Pro (press Alt+T to search for text) confirms this hypothesis, as apparent from the following image:

So the name of the mutex is an additional host-based indicator:

• Mutex: SADFHUHF

6) What network-based indicators could be used to find this malware on infected machines?

By examining the strings in Lab01-01.dll I can identify this network-based indicator:

• 127.26.152.13

7) What would you guess is the purpose of these files?

By examining the imported functions my guess is that this malware searches for (FindFirstFile, FindNextFile) and manipulates (CopyFile, CreateFile) files. It also gets a map of an existing file into memory (MapViewOfFile) making it accessible for reading or writing; this function can be used to read and modify PE files thus avoiding using WriteFile. The executable uses the DLL Lab01-01.dll which is probably copied to C:\windows\system32\kerne132.dll, a name resembling the legit kernel32.dll.

The malware communicates with the remote IP 127.26.152.13. The function Sleep makes me think that after infecting a system the malware sits waiting for commands from the remote IP; the strings exec, sleep, hello seems to be the commands that can be sent to the malware.

That’s all for this lab!

May 07, 2017 malware

Twitter Google+ Facebook LinkedIn