Malware Final Report

Running head: ANALYZING MALWARE SAMPLES’ ASSEMBLY AND FUNCTION 1
The Microsoft Malware Protection Center Challenge: Analyzing Malware Samples’ Assembly
and Function
Zachary Adams
Our Lady of the Lake University

ANALYZING MALWARE SAMPLES’ ASSEMBLY AND FUNCTION 2
Abstract
The purpose of this paper is to analyze the first two samples of malware the Microsoft Malware
Protection Center (MMPC) provided for their malware analysis challenge. Microsoft provided
the first sample, but the instructions to get the second sample are hidden in the first sample.
Proper analysis is needed to retrieve the second sample. Analyzing the samples involve
disassembling the malware executables using IDA Pro and debugging them using OllyDbg.
Screenshots of the process will be provided for each malware sample to illustrate the analysis
process. For the first sample, there was little guidance on how to proceed. The analysis of the
first sample will follow my own process and how solving the first sample leads into the second
sample’s analysis. The second sample required answering some questions about the sample’s
functionality, which I will detail the process of how I discovered the answers.

Executive Summary
The first sample of malware was a login program that required a username and password.
The goal of the analysis of sample 1 is to gain access to the file that would give instructions on
how to obtain sample 2. I was able to find all the usernames in the strings of the file and crack all
but one of the passwords in the program, but I decided instead to patch the program to bypass the
password checking function. As a result, I was able to log into the program and view the key.txt
file that would give instructions on how to obtain sample 2.
Sample 2 appeared to be a pump controller program that could be behind the login screen
of sample 1. In sample 2, I was given five questions to answer about the sample:
1. What are the commands accepted by the program?
2. What is the logic of the loop in the program?
3. How does the temperature model in the program work?
4. What are the vulnerabilities in the program? Can you create a proof of concept and
exploit them? What is the impact?
I was able to answer each of the questions in my analysis, which I will detail in the following
pages of my report.

Analyzing Sample 1: Login Program
Figure 1 (Login Screen)
When first opening sample 1, I was greeted with a message to supply a username as seen
in Figure 1. Trying my own username, I discovered that I was not able to login. At this point, I
could take two approaches to bypassing this login: 1) Find the passwords and crack them, or 2)
create a patched version of the sample that would skip the password check function. First, I
looked into the strings of sample 1. I found several usernames and MD5 password hashes in
Table 1 on the next page. I was able to crack all but one of them during my analysis. Also in the
strings of the program was a filename called “key.txt.” This particular file is protected by a
permission that is only granted to certain users.

Username MD5 Hash Password
jroam e10adc3949ba59abbe56e057f20f883e 123456
todgrad 5f4dcc3b5aa765d61d8327deb882cf99 password
sammie eb31870669f13fd8444c2bc918375f09 heaven
wiltil 5dac4f26f11849cc71d129edcc55283b 1london
reamik 7ab41869306b693f2d9d4f5fa793f0f0 superman99
test1234 bd04dfaad15639a6aa4314d63ce02f9a [Unknown]
reagmc 73023d8e8351392686261f2afce5ebad abc541
carlti 5fcfd41e547a12215b173ff47fdd3739 trustno1
rogid 6081d0da1ee073e537b933674e66ea4a blah1blah
admin 1e88a70ee1ccb2a25f63c8e5b7761702 msftflag!#37
Table 1 (Login Credentials)
The most interesting credential of this list is the “admin.” Since the contents of the file are only
allowed to be viewed by certain users, “admin” must be the one to have the permission to view
key.txt. I could have used the “admin” login to access the file, but I decided to try and crack the
program so that the password checking function would be bypassed. Looking into the assembly
in IDA Pro, I was able to identify the function in Figure 2.

Figure 2 (Password checking function)
Figure 4 (New Jump Location)
I noticed that right before the program checks the entered password there is a conditional jump
into the code block. Using OllyDbg, I set a breakpoint at that location and changed the assembly
from a conditional jump to an unconditional jump that completely skipped the password
checking function. The edited code is shown in Figure 3 and the new jump location in Figure 4.
After completing the edit, the patch program granted me access to the file without a password, as
shown in Figure 5.
Figure 3 (Patched Code)

Figure 6 (Key.txt)
Figure 5 (Bypass successful)
Finally granted access, I was able to view the content of the key.txt file. Inside it were
instructions on how to obtain the second sample from Microsoft. Figure 6 shows the programs
output from the key.txt file.

Analyzing Sample 2: Pump Control Program
Figure 7 (Sample 2 Start)
Starting the program shows a short boot progress screen before showing a monitor
interface. The “Workload” and “Temperature” are constantly fluctuating with the temperature
increasing as the workload does, and depending on the temperature “Pump 1” and “Pump 2” are
turn on. When the pumps are on, the temperature drops as well until it is low enough to where
the pumps turn off. If the “Controller” is turned off, the pumps do not automatically turn on and
the temperature will rise to around 120 degrees Celsius.
The following sections of my analysis will attempt to answer the questions outline in the
Executive Summary:
1. What are the commands that the program accept?
The commands are stored in the program as strings in Figure 8. Looking into the strings, I
noticed several commands that I can use to manipulate three objects in the program: Pump 1,
Pump 2, and the Controller.

Figure 8 (Commands)
All of these strings are located in the same function, which I renamed to “cmd_commands” in
the rest of the following Figures. To confirm my findings, I entered a command to see if it
worked. The results are shown in Figure 9.
Figure 9 (Command Successful)

2. What is the logic of the loop in the program?
I discovered three loops that run concurrently when the program is started. These loops are infinite
and only stop when the program does, or have other special conditions which I will describe in the
following paragraphs.
Figure 10 (Loop 1)

Figure 11 (Loop 2)

Figure 12 (Loop 2 Continued)

Figure 13 (Loop 3)

Figure 14 (Loop 3 Continued)

These loops perform several functions for the program and I will describe them one by one.
In box 1.1 of Figure 10 on page 10, the function “generate_status_nums” is called. This function
will print the values shown in the Workload and Temperature fields, and the status of Pump 1,
Pump 2, and the Controller. The variables that define these fields are set in another loop. In box
1.2, the program calls the C function “_kbhit” which checks to see if a key was hit since the last
time the loop ran. If the “Enter” was hit, the program creates a buffer that is 1023 bytes large as
seen in box 2. This buffer is then taken to box 3 where it is passed into the “cmd_commands”
function so that the program will perform the command entered. This function does not stop until
the program ends, but there is a vulnerability that I will detail later.
The second loop in Figures 11 and 12 on pages 11 and 12 is a complex function that uses a
complicated math equation to calculate the ever changing numbers in the Workload and
Temperature fields of the program. While I cannot abstract the exact equation from the assembly,
I can describe what the function does. In box 1, the “temperature” variable is copied into the
“xmm0” so that the value can be manipulated by the equation later on in the function. Below
that, the memory address for the C function “rand” is passed into the ESI register for future calls
in the function. “Rand” returns a pseudo-random number to EAX. In Figure 12 in boxes 4
through 7, the value for “cpu_load” is calculated and so that it can be used to determine the value
for the “temperature” variable right after. In box 8, the value for “pump_status” is copied to
EAX. “Pump_status” can have either 0 for no pumps on, 1 for one pump on, or 2 for both pumps
on. This value is used in the equation to determine the “temperature” value, which is set in box 9.
3. How does the temperature model in the program work?
This loop answers question 3 as well as the last part of question 2. The last loop in Figures 13
and 14 on pages 13 and 14 monitors the “temperature” value and it turns the pumps on when the

value gets too high. In box 1.1, the function sets EBX to 40. Before continuing to box 1.2, the
program checks to see of the Controller is off. If not, the program continues onto box 1.2 where
“temperature” is compared to EBX, which still contains 40. If the temperature is higher than 40,
Pump 1 is turned on in box 1.3. Usually this is enough for the loop to run once and it restarts.
The next relevant section is boxes 3.1 and 3.2 where the temperature is compared to 30. If the
temperature is less than 30, Pump 1 is turned off. This process is repeated in boxes 4.1-2 and 5.1-
2 where the temperature is compared to 40. If the temperature is higher, Pump 2 is turn on, or if
lower than 40 is turned off. In box 6, the values for “temperature” and “pump_status” are saved
in the ESI and EDI registers for use in the second loop that generates “temperature” value.
4. What are the vulnerabilities in the program? Can you create a proof of concept and
exploit them? What is the impact?
I discovered two vulnerabilities in sample 2. The first involves exploiting the command
prompt history function provided by pressing the F7 key. By doing so, a dialog box appears on
the screen that contains all the strings that have been entered during the session as shown in
Figure 15 (F7 Command History)

Figure 15. This can include login credentials in plaintext. In this case, the command history
allows someone who is not familiar with the program to know what commands the program
accepts if they were entered in before. This particular vulnerability is not one that can be
mitigated because it is an issue with the OS. As far as I can tell, there is no way to disable the
command history in Windows.
Figure 16 (Buffer Overflow Opportunity)
The other vulnerability I discovered was the potential for a buffer overflow. This occurs
in the loop in Figure 10 that prints the text to the command prompt and monitors for “Enter”
keystrokes. As seen in Figure 16, after the “Enter” key is presses, a buffer is created to capture
Figure 17 (Overflow Result: Overheating)

the input. This buffer is 1023 bytes and there is no mechanism to check if the user entered more
than what the buffer can hold. As a result, I was able to break the loop without crashing the
program and no more commands can be entered without restarting. If this program were in use,
an attacker could issue the “Controller Off” command and break the loop with catastrophic
effect. With the Controller off, the pumps cannot turn on to reduce the temperature and it
skyrockets as seen in Figure 17. This is a rather crude way to use the exploit and I am aware that
it can be used for remote code execution. However, I do not have the expertise to exploit it
myself.

Malware Final Report

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (9)

Similaire à Malware Final Report

Similaire à Malware Final Report (20)

Malware Final Report