Practical Malware Analysis - 1

B A S I C  S T A T I C  T E C H N I Q U E S

---

- Antivirus Scanning: A Useful First Step

- Hashing: A Fingerprint for Malware    

C:\>md5deep c:\WINDOWS\system32\sol.exe

373e7a863a1a345c60edb9e20ec3231 c:\WINDOWS\system32\sol.exe

- Finding Strings

ASCII strings use 1 byte per character, and Unicode uses 2 bytes per character.

But those bytes may not actually represent that string; they could be a memory address, CPU instructions, or data used by the program

- Packed and Obfuscated Malware

If upon searching a program with Strings, you find that it has only a few strings, it is probably either obfuscated or packed, suggesting that it may be malicious

Packed and obfuscated code will often include at least the functions LoadLibrary and GetProcAddress, which are used to load and gain access to additional functions

- Portable Executable File Format

the format of a file can reveal a lot about the program’s functionality.

- Linked Libraries and Functions

Knowing how the library code is linked is critical to our understanding of malware because the information we can find in the PE file header depends on how the library code has been linked.

Static, Runtime, and Dynamic Linking

Exploring Dynamically Linked Functions with Dependency Walker

Imported Functions

Exported Functions

EXEs are not designed to provide functionality for other EXEs, and exported functions are rare. If you discover exports in an executable, they often will provide useful information.

- Static Analysis in Practice

- The PE File Headers and Sections

Executable Description

.text Contains the executable code

.rdata Holds read-only data that is globally accessible within the program

.data Stores global data accessed throughout the program

.idata Sometimes present and stores the import function information; if this section is

not present, the import function information is stored in the .rdata section

.edata Sometimes present and stores the export function information; if this section is not

present, the export function information is stored in the .rdata section

.pdata Present only in 64-bit executables and stores exception-handling information

.rsrc Stores resources needed by the executable

.reloc Contains information for relocation of library files

The section sizes can be useful in detecting packed executables. For example, if the Virtual Size is much larger than the Size of Raw Data, you know that the section takes up more space in memory than it does on disk. This is often indicative of packed code, particularly if the .text section is larger in memory than on disk. This tells us that a packer will unpack the executable code to the allocated .text section.

Lab01-1.exe

---

Lab 1-1

This lab uses the files Lab01-01.exe and Lab01-01.dll. Use the tools and techniques described in the chapter to gain information about the files and answer the questions below.

Questions

1. Upload the files to http://www.VirusTotal.com/ and view the reports. Does either file match any existing antivirus signatures?

2. When were these files compiled?

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

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

CreateProcess를 통하여 새로운 프로세스를 만드는 것을 확인 할 수가 있으며 WS2_32.dll은 Networking을 하기 위하여 필요한 dll로써 다른 곳과 연결을 할려는 것을 알 수가 있다.

문자열을 확인해보면 특정한 주소가 있는 것을 확인할 수가 있고, 이 주소와 네트워킹을 하려한다는 것을 알 수가 있다.

FindFirstFile과 FindNextFile을 통하여 특정한 이름의 파일을 찾는 과정과 CreateFile과 CopyFile을 통하여 특정한 파일에 어떠한 작업을 하는 것을 예상 할 수가 있다.

아래와 같이 C:\windows\system32\kernel132.dll과 작업을 할려는 것을 확인 할 수가 있고, 아래와 같이 Lab01-01.dll과도 직접적으로 관련이 있는 것을 확인 할 수가 있다.

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

.EXE의 CreateFile, CopyFile, FindFirstFile, FindNextFile과 같은 함수를 통하여 확인을 할 수가 있다. C:\Windows\System32\kerne132.dll 과 직접적으로 관련이 있다는 것 또한 우리는 문자열을 통하여 알 수 있다.

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

.dll의 WS2_32.dll의 모든 내용이 Network와 관련이 되어 있기에 이를 통해서 알 수가 있다. 또한 문자열을 확인하였을때 IP주소가 존재하는 것까지 확인을 할 수 있다.

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

The .dll file is probably a backdoor. The .exe file is used to install or runthe DLL.

Detailed Analysis

To answer the first question, we upload the file to VirusTotal.com, which performs

a scan against antivirus signatures.

Next, we open the files in PEview. For each file, we navigate to the

IMAGE_NT_HEADERSIMAGE_FILE_HEADERTime Date Stamp field,

which tells us the compile time. Both files were compiled on December 19,

2010, within 1 minute of each other. This confirms our suspicions that these

files are part of the same package. In fact, a compile time that close strongly

suggests that these files were created at the same time by the same author.

We know that the files are related because of the compile times and where

they were found. It’s likely that the .exe will use or install the .dll, because

DLLs cannot run on their own.

Then we check to see if either file is packed. Both files have small but

reasonable numbers of imports and well-formed sections with appropriate

sizes. PEiD labels this as unpacked code compiled with Microsoft Visual C++,

which tells us that these files are not packed. The fact that the files have

few imports tells us that they are likely small programs. Notice that the DLL

file has no exports, which is abnormal, but not indicative of the file being

packed. (You will learn more about this export section when we return to

these files in Lab 7-3.)

Next, we look at the files’ imports and strings beginning with the .exe. All

of the imports from msvcrt.dll are functions that are included in nearly every

executable as part of the wrapper code added by the compiler.

When we look at the imports from kernel32.dll, we see functions for

opening and manipulating files, as well as the functions FindFirstFile and

FindNextFile. These functions tell us that the malware searches through the

filesystem, and that it can open and modify files. We can’t be sure what the

program is searching for, but the .exe string suggests that it is searching for

executables on the victim’s system.

We also see the strings C:\Windows\System32\Kernel32.dll and C:\windows\

system32\kerne132.dll. (Notice the change from the letter l to the number 1

in kernel32.dll.) The file kerne132.dll is clearly meant to disguise itself as the

Windows kernel32.dll file. The file kerne132.dll can serve as a host-based indicator

to locate infections, and it is one that we should analyze for malicious code.

Next, we look at the imports and strings for Lab01-01.dll, which imports

functions from WS2_32.dll. Because these functions are imported by ordinal,

we don’t know which functions are being imported. We also see two interesting

functions imported from kernel32.dll: CreateProcess and Sleep, which are

commonly used as backdoors. These functions are particularly interesting to

us in combination with the strings exec and sleep. The exec string is probably

sent over the network to command the backdoor to run a program with

CreateProcess. The sleep string is probably used to command the backdoor

program to sleep. (This malware is complex. We’ll return to it in Lab 7-3,

once we have covered the skills to analyze it fully.)

Lab01-2.exe

---

Lab 1-2

Analyze the file Lab01-02.exe.

Questions

1. Upload the Lab01-02.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

PEView로 확인을 했을때 UPX 섹션이 존재하기도하며 이에 더해 첫번째 UPX 섹션의 경우 SizeOfRawData가 0으로써 언패킹 과정 중에 그곳에 Instruction이 쓰이는 것으로 예상된다.

3. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

우선 패킹이 되어있을때는 프로그램이 실행되면서 실행압축된 것을 해제 할때 LoadLibrary를 사용하므로 인하여 저곳에 존재하고 있는 것을 확인 할 수가 있다. 그리고 언패킹 후에는 ADVAPI32.dll에서 CreateServiceA라고 되어있는데, 이 dll은 주로 Registry나 서비스를 제어할때 쓰는 dll 이므로 CreateService는SCM에 새로운 서비스를 등록한다는 것으로 예상이 된다. 여기서 내 예상으로는 아마 자동실행에 등록을 하지 않을까 싶다.( 물론 아닐 확률도 높음 )

그리고 WININT.dll 보면 InternetOpen과 InternetOpenUrl을 볼수가 있는데, 이는 특정 사이트를 여는 것이다. 구체적인 사이트는 두번째 사진에서와 같이 www.malwareanalysis.com으로 연결이 될 것이라 예상할 수가 있다.

4. What host- or network-based indicators could be used to identify this malware on infected machines?

만약 레지스트리에 등록하는 것이 맞다면 host-based에도 포함이 되고 그렇지 않다면 Network-based에만 포함이 된다. 

Detailed Analysis

When analyzing Lab 1-2, we upload the file to VirusTotal.com and see that it

matches at least three virus signatures. One antivirus engine identifies it as a

malicious downloader that downloads additional malware; the other two identify

it as packed malware. This demonstrates the usefulness of VirusTotal.com.

Had we used only one antivirus program to scan this file, we would probably

not get any information.

Upon opening the file with PEview, several indicators tell us that this

file is packed. The most obvious indicators are sections named UPX0, UPX1,

and UPX2—section names for UPX-packed malware. We could use PEiD to

confirm the file’s packed nature, but it is not foolproof. Even if PEiD fails

to identify the file as UPX-packed, notice the relatively small number of

imports and that the first section, UPX0, has a virtual size of 0x4000 but a raw

data size of 0. UPX0 is the largest section, and it’s marked executable, so it’s

probably where the original unpacked code belongs.

 Having identified the program as packed, we can unpack it by downloading

UPX from http://upx.sourceforge.net/ and running the following command:

upx -o newFilename -d originalFilename

The -d option says decompress the file, and the -o option specifies the

output filename.

After unpacking, we look at the imports sections and the strings. The

imports from kernel32.dll and msvcrt.dll are imported by nearly every program,

so they tell us little about this specific program. The imports from wininet.dll

tell us that this code connects to the Internet (InternetOpen and InternetOpenURL),

and the import from advapi32.dll (CreateService) tell us that the code creates a

service. When we look at the strings, we see www.malwareanalysisbook.com, which

is probably the URL opened by InternetOpenURL as well as by Malservice, which

could be the name of the service that is created.

We can’t be sure what this program is doing, but we’ve found some indicators

to help search for this malware across a network.

Lab01-3.exe

---

Lab 1-3

Analyze the file Lab01-03.exe.

Questions

1. Upload the Lab01-03.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

3. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

패킹이 FSG 1.0으로 되어있기에 언패킹 툴을 구하지 못하였다. 따라서 Manual Unpack을 하였는데 언패킹 후에 아래와 같이 dll이 확인이 되는 것을 볼 수가 있다.

4. What host- or network-based indicators could be used to identify this malware on infected machines?

프로그램을 실행할 경우 아래와 같이 해당 사이트로 연결이 되는 것을 확인 할 수가 있다. 이는 네트워크에 기반했음을 알수가 있다.

Manual Unpack

Detailed Analysis

For the file Lab01-03.exe, VirusTotal.com reports a variety of different signatures

with vague-sounding names. The most common signature is that of a

file packed with the FSG packer.

When we open the file in PEview, we see several indications that the file

is packed. The first is that the file sections have no names. Next, we see that

the first section has a virtual size of 0x3000, but a raw data size of 0. We run

PEiD to confirm, and it identifies the packer as FSG 1.0 -> dulek/xt.

To confirm that the file is packed, we search for the imports, but there

doesn’t seem to be an import table. An executable file without an import

table is extremely rare, and its absence tells us that we should try another

tool, because PEview is having trouble processing this file.

We open the file with Dependency Walker, and see that it does have an

import table, but it imports only two functions: LoadLibrary and GetProcAddress.

Packed files often import only these two functions, which further indicate

that this file is packed. We can try to unpack the file using UPX, but we

know that the file is packed with FSG, rather than UPX. We’ll return to this

file in Chapter 18, once we have covered the skills to unpack it.

Lab01-4.exe

---

Lab 1-4

Analyze the file Lab01-04.exe.

Questions

1. Upload the Lab01-04.exe file to http://www.VirusTotal.com/. Does it match any existing antivirus definitions?

2. Are there any indications that this file is packed or obfuscated? If so, what are these indicators? If the file is packed, unpack it if possible.

3. When was this program compiled?

4. Do any imports hint at this program’s functionality? If so, which imports are they and what do they tell you?

아래에서와 같이 ADVAPI32.DLL을 통하여 권한에 대하여 어떠한 작업을 하려고 한다. 또한 CreateFile, WriteFile, 등을 통하여 특정 파일을 생성을 하고 WinExec 함수를 통하여 그 파일을 실행 시키려고 하는 것 같다.

이뿐만 아니라 Resource와 관련된 함수또한 존재하는데 이는 Resource 부분에서 무엇인가를 가져온다는 것이다. 

5. What host- or network-based indicators could be used to identify this malware on infected machines?

우선 권한을 변경한 뒤에 System32\wupdmgrd.exe라는 파일을 생성하거나 실행할 것이라 예상할 수가 있다. 이를 통해 우리는 호스트 기반이라는 것을 확인 할 수가 있었다. 하지만 문자열을 보면 도메인주소가 존재하는 것을 확인할 수가 있다. 하지만 위에서 봤듯이 네트워킹과 관련된 함수는 존재하지 않았다.

여기서 우리는 위에서 리소스를 다루는 함수가 있었다는 것을 상기해야한다. 즉 리소스 섹션에 무엇인가가 숨겨져 있을수도 있다는 것이다.

6. This file has one resource in the resource section. Use Resource Hacker to examine that resource, and then use it to extract the resource. What can you learn from the resource?

Resource Hacker를 통하여 해당 File을 열어보면 PE 구조의 첫 시작부분부터 존재하는 것을 확인 할 수가 있다. 이것이 처음에는 파일을 잘못 인식한줄 알았지만 알고보니 저 부분 자체가 하나의 다른 파일이였던 것이다. 아래의 사진과 같이 Action > Save resource를 통하여 저장을 해보자.

이렇게 나온 파일을 우리는 PEView를 통하여 열어보면 네트워킹을 하는 함수를 발견할 수가 있다. 이러한 방식은 실제 멀웨어에서 이용되는 방식이므로 잊지 말자.

Detailed Analysis

For the Lab01-04.exe file, the results from VirusTotal.com suggest a program

related to a downloader. PEview gives no indication that the file is packed

or obfuscated.

The imports from advapi32.dll tell us that program does something

with permissions, and we can assume that it tries to access protected files

using special permissions. The imports from kernel32.dll tell us that the program

loads data from the resource section (LoadResource, FindResource, and

SizeOfResource), writes a file to disk (CreateFile and WriteFile), and executes

a file on the disk (WinExec). We can also guess that the program writes files

to the system directory because of the calls to GetWindowsDirectory.

Examining the strings, we see www.malwareanalysisbok.com/updater.exe,

which is probably the location that holds the malicious code for download.

We also see the string \system32\wupdmgr.exe, which, in combination with

the call to GetWindowsDirectory, suggests that a file in C:\Windows\System32\

wupdmgr.exe is created or edited by this malware.

We now know with some confidence that this malicious file downloads

new malware. We know where it downloads the malware from, and we can

guess where it stores the downloaded malware. The only thing that’s odd is

that the program doesn’t appear to access any network functions.

  The most interesting part of this malware is the resource section. When

we open this malware in Resource Hacker, we see one resource. Resource

Hacker identifies the type of the resource as binary, meaning arbitrary binary

data, and when we look at the data, most of it is meaningless. But notice the

string !This program cannot be run in DOS mode. This string is the error message

included in the DOS header at the beginning of all PE files. We can therefore

conclude that this resource is an additional executable file stored in the

resource section of Lab01-04.exe. This is a fairly common technique used in

malware.

To continue analyzing this file with Resource Hacker, we click Action

Save resource as binary file. After saving the resource, we open the file in

PEview to analyze the file embedded within it. Looking at the imports, we see

that the embedded file is the one that accesses the network functions. It calls

URLDownloadToFile, a function commonly used by malicious downloaders. It

also calls WinExec, which probably executes the downloaded file.