Practical Malware Analysis - Chapter 9 Lab Write-up
Chapter 9. OllyDbg
Analyze the malware found in the file Lab09-01.exe using OllyDbg and IDA Pro to answer the following questions. This malware was initially analyzed in the Chapter 3 labs using basic static and dynamic analysis techniques.
Lab 9-1
Analyze Lab09-01.exe.
Question 1
How can you get this malware to install itself?
Answer 1
Opening up the malware in OllyDbg we can see that it immediately pauses as soon as it hits the specified executable entry point.
By examining the function at address 0x403945 we can see that 3 arguments are available to be passed to the program and what looks to be the start of the main function.
Using F8 we can step over instructions of the program, and once we reach the instruction past ‘GetCommandLine’, we can see that EAX has been updated to reflect the program command line, which in this case was running the application without any arguments.
Once we reach the main function, if we press F8 the program runs through it which isn’t what we want. By pressing F7 we can step into the function to continue analysis with F8.
Upon hitting 0x402AFD we can see a comparison takes place to see if the number of arguments passed to the program is equal to one.
As no arguments were passed the comparison fails. As such a jump is not taken and the program continues to call 0x401000.
Once again by stepping into this with F7 we can examine some more. Inside this function stands out a particular check for what looks to be a typo’d registry key ‘HKLM\SOFTWARE\Microsoft \XPS’. As this doesn’t exist the jump statement after is never taken and we instead jump to 0x401066 (once again we can step into this with F7).
After this a return occurs and after a few more comparisons we wind up at 0x402410. By stepping through this once more, using F8 to skip Windows API calls as required, we find that the malware begins to build an instruction designed to delete the malware as it was run without any kind of parameters. This is a common anti-analysis technique.
Because we’re running the program in OllyDbg an open handle exists on the program and deletion fails.
At this point we know that running the program is not enough to install it, so we re-examine the comparisons undertaken when the program runs, first up is ‘-in’.
By using Debug > Arguments, we can add in -in as a command line argument and restart using CTRL+F2. Once again we move through analysis, except this time a Jump is taken, and we can see a comparison will be run on our provided argument ‘-in’.
Looking inside of 0x402510 which is called we can see that a number of arithmetic operations occur but no functions are called. In this instance it looks to be a check for certain characters, so we can assume that ‘-in’ may be for installing the malware, and this may be checking for some sort of password. What we’re aiming to achieve from this function is to return EAX with a value of 1 (signifying a success in relation to the calling conditions). Highlighted in red are conditions that if evaluated will jump past the statement that sets EAX to 1. Highlighted in blue is our end goal, but as we can see straight away the first comparison fails and we jump straight to the end of the function without setting EAX to 1.
One way to completely bypass the check is to patch it so that it returns with EAX = 1, or by modifying the value of EAX to return one after the checks fail.
This time by stepping through we can see that a jump does occur and we move past 0x402410 that executes binary deletion.
Stepping through we hit another function at 0x40380F. If we continue to step through this we will see more comparisons taking place to ensure that the parameters provided match expected parameters of the program. This passes; however, at one point we will find ourself falling back into 0x402410 again due to a comparison that checks if more than 3 elements have been passed to the program (noting that the application name is passed as an argument). Due to the comparison failing we wind up again in a state of deletion.
Repeating the process once more except with any random given parameter for the password we can meet this requirement and continue with application installation.
With this we now see that a jump doesn’t occur and the program continues as expected.
Once we hit 0x40268F and step into it we can see reference to ‘.exe’ and ‘%SYSTEMROOT%\system32\Lab09-01’ which has been taken from the file name passed to the malware.
As we progress we can see that this opens the Service Control Manager and looks at creating a service with the name Lab09-01 if it doesnt exist already.
This service is created with a number of parameters. Which can be seen within OllyDbg.
After stepping over this function we can see that a service has been created pointing to %SYSTEMROOT%\system32\Lab09-01.exe and that the malware has indeed copied itself to this directory indicating it has been successfully installed.
Question 2
What are the command-line options for this program? What is the password requirement?
Answer 2
In addition to the mentioned ‘-in’ argument check, we can see 3 other command-line options in this malware. “-re” “-c” and “-cc”
The password requirement mentioned previously can be uncovered by carefully examining how many checks occur in this function and breaking down what each comparison is used for knowing that we want their comparisons to be true. As such we need to also look at activity occurring before the comparison, and if required examine the current stack content as we move through it.
First off we can see that the password is 4 characters long, then we look for it containing (61) ‘a’ as the first letter, then we compare the result of letter 2 (62) take letter 1 (61) and see if it equals 1, then we compare whether the next character is c (63), before finally adding 1 to this and checking if the next character is d (64).
If we break down how the value ‘b’ is obtained, we can see that it is derived directly from what we’ve pushed to the stack.
By using the ‘-re abcd’ argument (or any of the others, we can see this still performs the same password check, so this indicates abcd needs to be passed to the malware to run unless you want it to simply remove itself.
By stepping through and stepping over this execution as required, we reach a point where the Service Control Manager is instructed to delete a service.
Continuing through this results in the malware removing itself by deleting the service and associated binary.
By using the ‘-c’ argument we wind up once again with the malware attempting to remove itself. This is due again to a check on the number of arguments passed to the program. Looking at the hex dump of the malware while it is running leads us to believe a default configuration is setup to communicate to a URL with 2 associated parameters ‘80’ and ‘60’.
Given these parameters look to be related to post-compromise activity, we need to first ensure the malware is installed using -in.
By using the ‘-cc abcd’ argument we see that the application looks for its current configuration that’s been stored at: ‘HKLM\SOFTWARE\Microsoft \XPS’ and dumps it to the programs output.
Question 3
How can you use OllyDbg to permanently patch this malware, so that it doesn’t require the special command-line password?
Answer 3
As mentioned in answer 1, this malware can be patched under 0x402510 to always return with EAX = 1. To do this we right click the start of the function call, click edit, and use the assocviated HEX values to make it assign EAX as 1.
After this we edit the next HEX values to immediately make it return from the function signalling a successful outcome.
To patch the binary we can right click and select copy to executable > all modifications, before right clicking and selecting save file. At this point if we open the modified binary and run as normal, we can now run commands without the need for a password.
Question 4
What are the host-based indicators of this malware?
Answer 4
Host-based indicators of this malware include the registry key used to store the malware configuration:
- ‘HKLM\SOFTWARE\Microsoft \XPS’
The service created for persistence with the name:
- “
Manager Service"
or
- “
Manager Service"
and finally the presence of a binary at:
- %SYSTEMROOT%\Windows\System32
With the name of the service name argument passed, or the binary name.
Question 5
What are the different actions this malware can be instructed to take via the network?
Answer 5
By opening this using IDA we can find sub_402020 which contains a number of instructions that help determine what different actions this malware can be instructed to take. This is also seen at 0x402020 in OllyDbg.
In this instance functions have been renamed to “Command_*” for readability.
- SLEEP: Do nothing for a certain amount of seconds. Note: This is registered in milliseconds so the value passed is multiplied by 1000.
- UPLOAD: Download a file from a web resource over a specified port and write it to disk. Note: This isn’t a typo, in this instance upload is in fact downloading to the host.
- DOWNLOAD: Upload a file from disk to a web resource. Note: This isn’t a typo, in this instance download is in fact uploading to a remote the host.
- CMD: Execute a command and send back the output to a web resource.
- NOTHING: Do nothing
Question 6
Are there any useful network-based signatures for this malware?
Answer 6
We know from previous analysis of this malware that configuration is stored in the registry so by default it communicates with:
- http://www.practicalmalwareanalysis.com
To analyse how this communication occurs and whether there’s any other network-based indicators we look back to sub_402020 and the function it calls prior to comparing the response received to one of the mentioned commands. This function is sub_401E60.
This contains a number of unusual string comparisons and operations based on backticks and apostraphes.
Moving back to Ollydbg we can move back to debugging the application in an attempt to understand this. Starting out we add a breakpoint at 0x401E60 by using CTRL + G to jump to this address and using F2 to toggle a breakpoint.
We need to confirm the application isn’t running with any command line parameters and move through with F8 until the breakpoint we set is hit. From here we can begin to analyse specific register or stack values before and after a number of subroutines are run by setting breakpoints similar to the below.
After running through the first function by using F9 twice, we see reference to WinINet API and the previously mentioned domain which leads us to believe this is likely using FTP or HTTP for communication.
Repeating the process with F9 twice reveals our ECX register with the value ‘80’.
Based on what we know and it being stored in a value ‘p’, we can infer that this is the port that the malware communicates via. Repeating the process once more reveals what looks like it may be part of a URL.
By repeating the process once more we see that it fails to run through to our later break points in our isolated environment. Subsequent analysis shows that the URL elements mentioned above change. If we step through to 0x401EF9 we can see that this is indeed being passed as an argument to a function at 0x401AF0.
Stepping into this function we can see evidence this is making a HTTP/1.0 Get request to the server for C2 without any headers.
After the request is made there are some comparisons based on returned backtick and apostraphes as we found earlier, and this looks to be determining exactly how the C2 process will execute the command passed to it (how the C2 protocol works).
Based on all of this we can conclude that Get requests using HTTP/1.0 beaconing to http://www.practicalmalwareanalysis.com/xxxx/xxxx.xxx without any headers or user agent is a network indicator of this malware.
Lab 9-2
Analyze the malware found in the file Lab09-02.exe using OllyDbg to answer the following questions.
Question 1
What strings do you see statically in the binary?
Answer 1
Running Strings over the binary reveals a number of entries for what look like imports or function names, and ‘cmd’, but other than that not a lot else.
Question 2
What happens when you run this binary?
Answer 2
Attempting to run the binary results in it terminating almost instantly without showing any other visible actions.
Question 3
How can you get this sample to run its malicious payload?
Answer 3
By stepping through the program with a debugger and a few break points, we can see that after the call at 0x401626, EDX is filled with the value “ocl.exe”, and this remains throughout the program until a comparison check to it fails and the program terminates.
Based on this we can assume that the program checks if it is named ocl.exe, and if it isn’t then it terminates. If we rename it and continue to debug, we realise that termination doesn’t occur here anymore.
Question 4
What is happening at 0x00401133?
Answer 4
If we examine 0x00401133 we can see that a number of Hex values are being moved onto a relevant area of the stack segment.
This is a common string obfuscation technique to make analysis more challenging.
If we take the hex values accounting for the null values present and convert this to ascii we get the following:
- 31 71 61 7a 32 77 73 78 33 65 64 63 = 1qaz2wsx3edc
- 6F 63 6C 2E 65 78 65 = ocl.exe
Question 5
What arguments are being passed to subroutine 0x00401089?
Answer 5
Adding breakpoints and running through the application later reveals the presence of 1qaz2wsx3edc which is being passed to subroutine 0x00401089 and a pointer to 0x12FD58 (Incl ESI).
Question 6
What domain name does this malware use?
Answer 6
By running through this program to our next breakpoint we can see that it flows through the decoding routine at 0x00401089 and reveals the domain used by this malware in EAX ready to be passed to the ‘gethostname’ imported function: www.practicalmalwareanalysis.com
Question 7
What encoding routine is being used to obfuscate the domain name?
Answer 7
To figure this out we need to move into the encoding routine at 0x00401089. Here we can see a routine that loops and contains reference to an XOR command against EDX (which we know contains the random string we discovered earlier).
By adding a breakpoint at this command and running the program we can see that it performs this XOR against a letter one by one, and in the first instance it XORs 46 and 31 (first letter of our key).
Running the program again reveals it XORs 6 and 71 (second letter of our key)
By creating a break point at the comparison statement that occurs, and following the associated memory dump, we’re able to see the string being decoded in real time as we run through the program and hit our breakpoints.
Question 8
What is the significance of the CreateProcessA call at 0x0040106E?
Answer 8
This function isn’t called when we run through the program as there’s no successful beacon to the C2 we uncovered previously. Having said this we can see from this function that CreateProcessA looks to be run with cmd.exe as the process before waiting indefinitely in a loop.
By examining this in IDA for more context, we can see that it is making the cmd.exe window hidden, in addition to specifying the standard input, output, and error streams be sent to an argument that’s passed into this function.
Looking at the only calling function to this, we can see that the argument passed to this is the established socket to the C2. We now know that this process acts as the reverse shell allowing access to this host.
Lab 9-3
Analyze the malware found in the file Lab09-03.exe using OllyDbg and IDA. This malware loads three included DLLs (DLL1.dll, DLL2.dll, and DLL3.dll) that are all built to request the same memory load location.
Question 1
What DLLs are imported by Lab09-03.exe?
Answer 1
By opening the program in IDA we can see that the imported DLLs of this program are:
- DLL1.dll
- DLL2.dll
- KERNEL32.dll
- NETAPI32.dll
In addition to these, if we examine calls to the WinAPI ‘LoadLibraryA’, we can find another 2 DLLs that are dynamically loaded into memory from the running program.
- DLL3.dll
- user32.dll
Question 2
What is the base address requested by DLL1.dll, DLL2.dll, and DLL3.dll?
Answer 2
By opening these up in PE-bear, we’re able to see that they all have an image base set to 0x10000000.
Question 3
When you use OllyDbg to debug Lab09-03.exe, what is the assigned based address for: DLL1.dll, DLL2.dll, and DLL3.dll?
Answer 3
Because we know that DLL3.dll is dynamically loaded in we’ll need to add a breakpoint after this loadlibrary call to check when all 3 are loaded into memory.
To view where these are in memory we can use ALT+M to view the programs memory. Note: These values will likely differ per run through or system.
In this instance the results are:
- DLL1: 0x10000000
- DLL2: 0x00150000
- DLL3: 0x00160000
Question 4
When Lab09-03.exe calls an import function from DLL1.dll, what does this import function do?
Answer 4
Because this occurs prior to the breakpoint we previously set, we can get our first glimpse on what has happened by viewing the program output while it is at our breakpoint.
This appears to display an output of “DLL 1 mystery data”, and then a number. By disassembling this in IDA we can get more information on what is happening.
Based on this we conclude that this is printing out the current processID of the process in which the DLL has been loaded into.
Question 5
When Lab09-03.exe calls WriteFile, what is the filename it writes to?
Answer 5
To get this answer we need to look at both DLL2.dll, and Lab09-03.exe. In Lab09-03.exe we can see that this calls and moves the output into ebp+hObject before passing it a buffer of the characters “malwareanalysisbook.com” to write.
By examining DLL2.dll, and looking at the exported DLL2ReturnJ function, we can see that this returns a value stored under dword_1000B078. When we examine this we can see it is being assigned based on the DLLs Main method as a handle to a file with the name “temp.txt”.
Based on this we know that this writes “malwareanalysisbook.com” into a file called “temp.txt”.
Question 6
When Lab09-03.exe creates a job using NetScheduleJobAdd, where does it get the data for the second parameter?
Answer 6
If we look at this execution we can see that it passes 3 parameter items: JobID, Buffer, and Servername.
Buffer is called from the output of Dll3GetStructure which once again is determined by the DLLs main function.
If we examine the NetScheduleJobAdd function documentation we can see that buffer needs to be a pointer to an AT_INFO structure defining the job to submit.
By using IDA we can add in the AT_INFO structure and then apply this to dword_1000B0A0. After first adding it to the structures window:
By viewing dword_1000B0A0 in memory and clicking Edit > Struct Var to AT_INFO we can change this directly and make more sense of the data at hand.
Based on this we can see that it will ping www.malwareanalysis every day at 3600000 milliseconds (60mins) past midnight (1am).
Question 7
While running or debugging the program, you will see that it prints out three pieces of mystery data. What are the following: DLL 1 mystery data 1, DLL 2 mystery data 2, and DLL 3 mystery data 3?
Answer 7
We already know what these are by the analysis conducted in previous questions. These are outputted from the values found in our relevant DLL files.
- DLL 1 mystery data 1: Process ID DLL is running under. (This was found in Question 4)
- DLL 2 mystery data 2: Handle ID for the Handle on file temp.txt. (This was found in Question 5).
- DLL 3 mystery data 3: Memory location of “ping www.malwareanalysisbook.com”. (This was found in Question 6).
Question 8
How can you load DLL2.dll into IDA Pro so that it matches the load address used by OllyDbg?
Answer 8
In this instance we want it to match the load address of 0x00150000. We can do this by clicking the ‘Manual Load’ checkbox in IDA when analysing the DLL and specifying the load address wanted.
This concludes chapter 9, proceed to the next chapter.
