Lab 9-1

Description

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.
Questions

  1. How can you get this malware to install itself?
  2. What are the command-line options for this program? What is the password requirement?
  3. How can you use OllyDbg to permanently patch this malware, so that it doesn’t require the special command-line password?
  4. What are the host-based indicators of this malware?
  5. What are the different actions this malware can be instructed to take via the network?
  6. Are there any useful network-based signatures for this malware?

Solution

  1. The malware can be installed by using the following command: Lab09-01.exe -in abcd. (abcd here serves as the password for the sample, otherwise it deletes itself.)

  2. The command line arguments provided by the program are the following: the sample must have abcd as a last argument, should have at most 4 arguments. (including the program executable)

    1. Lab09-01.exe -in <Service_Name>: The sample installs itself as a service with the specified name.
    2. Lab09-01.exe -re <Service_Name>: Uninstalls the service whose name is given in the cmdline args.
    3. Lab09-01.exe -c <Str1> <Str2> <Str3> <Str4>: Sets the configuration subkey in HKLM\Software\ Microsoft\XPS to the specified strings respectively.
    4. Lab09-01.exe -cc: Prints out the configuration key’s content to the console.
    5. The password requirement for the malware is abcd, without it the malware deletes itself.
  3. We can patch this program so that it jumps directly to the command line parser instead of checking the last argument given, as such: NOP out the initial call to the check_last_arg call at 0x402b38

    Keep in mind that this does not cancel the need for a password because the order of the arguments is used respectively within the sample, so you need to give in anything as a last parameter.

  4. There are several host based indicators for this malware:

    1. command.com
    2. Registry key HKLM\SOFTWARE\Microsoft \XPS
    3. The service that ends with <Service_Name> Manager Service (The malware can customize the service name based on the -in argument)
  5. There are different actions that the malware can take from its C2:

    1. SLEEP: causes the malware to sleep.
    2. NOTHING: does absolutely nothing.
    3. UPLOAD: downloads a file from the C2 server (presum)
    4. CMD: creates a pipe that executes the command and sends it to the C2.
    5. DOWNLOAD: uploads a file to the C2.

    The C2 server is specified in the configuration key in the registry.

  6. The sample has one network-based signature: http://www.practicalmalwareanalysis.com


Lab 9-2

Description

Analyze the malware found in the file Lab09-02.exe using OllyDbg to answer the following questions.
Questions

  1. What strings do you see statically in the binary?
  2. What happens when you run this binary?
  3. How can you get this sample to run its malicious payload?
  4. What is happening at 0x00401133?
  5. What arguments are being passed to subroutine 0x00401089?
  6. What domain name does this malware use?
  7. What encoding routine is being used to obfuscate the domain name?
  8. What is the significance of the CreateProcessA call at 0x0040106E?

Solution

  1. We don’t see anything interesting other than the imports of the file itself: we see signs of GetProcAddress(), GetCommandLineA(), LoadLibraryA(), we can also see the presence of a MessageBox within the strings, which means the malware could print something to the victim.

    Malware can import other libraries at runtime.

  2. Nothing seems to be happening.

  3. The malware retrieves its name and compares it with ocl.exe, returns 1 (fail) if they’re not equal and jumps to the main epilogue, otherwise it takes a different path if they’re equal, so the malware needs to have the name ocl.exe.

  4. The malware initializes an array of characters that contains what seems to be random characters: 1qaz2wsx3edc

  5. Two memory references are passed to this subroutine, one that has the random character initialized array and a secondary array reference that was copied into from .data:0x405034

  6. After the subroutine at 0x00401089 finishes, the function returns the deobfuscated domain name www.practicalmalwareanalysis.com (and that’s why we couldn’t see it in the strings output of the program.)

  7. The program keeps taking a byte from the random character array 1qaz2wsx3edc and XORs it with 460616544205121B470C07025D1C00164516011D520B050F480208091C141C15 and stores the result in a memory location, then it does this until it iterates over each byte of 1qaz2wsx3edc and then goes around every 0xC bytes, which means that this random string actually serves as an XOR key (or at least, each byte of the string)

We took every 0xC from the big key and kept iterating it through the smaller key to showcase the XOR operation.


Concatenate all the result and store them in memory.
8. This function is reached when the program succeeds in making a connection with the server, so that means we need to fake a server to whom the sample connects to, otherwise the malware sleeps after attempting to beacon out to the server.

We can just modify the EIP register to the jump location or patch it to jump directly, but it seems that CreateProcessA() takes the second argument as cmd which means that the sample creates a secondary shell and then waits indefinitely, this could be a reverse shell.

Keep in mind that CreateProcessA() will attempt to redirect all I/O to the socket, so if we jump directly without a socket, things can work unexpectedly.


We can see that the function that calls CreateProcessA() is sub_401000() which takes the connected socket as a parameter.

The sample then initializes the STARTUPINFO structure used for process creation so that it hides the process’ window and redirects stdin, stderr and stdout to the connected socket, and then it creates the process with the command line cmd.


Lab 9-3

Description

Analyze the malware found in the file Lab09-03.exe using OllyDbg and IDA Pro. This malware loads three included DLLs (DLL1.dll, DLL2.dll, and DLL3.dll) that are all built to request the same memory load location. Therefore, when viewing these DLLs in OllyDbg versus IDA Pro, code may appear at different memory locations. The purpose of this lab is to make you comfortable with finding the correct location of code within IDA Pro when you are looking at code in OllyDbg.
Questions

  1. What DLLs are imported by Lab09-03.exe?
  2. What is the base address requested by DLL1.dll, DLL2.dll, and DLL3.dll?
  3. When you use OllyDbg to debug Lab09-03.exe, what is the assigned based address for: DLL1.dll, DLL2.dll, and DLL3.dll?
  4. When Lab09-03.exe calls an import function from DLL1.dll, what does this import function do?
  5. When Lab09-03.exe calls WriteFile, what is the filename it writes to?
  6. When Lab09-03.exe creates a job using NetScheduleJobAdd, where does it get the data for the second parameter?
  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?
  8. How can you load DLL2.dll into IDA Pro so that it matches the load address used by OllyDbg?

Solution

  1. The sample imports DLL1.dll and DLL2.dll dynamically, but we can notice that the program loads DLL3.dll at runtime using GetProcAddress() and LoadLibraryA().
  2. Every single DLL has the base address of 0x10000000.
  3. In this instance of x32dbg, we notice that DLL1.dll is indeed mapped in 0x10000000 but DLL2.dll is mapped in 0x330000 and DLL3.dll is mapped in 0x390000.
  4. Prints DLL1 mystery data <PID_of_Sample>
  5. WriteFile() takes the handle to the open file as a first parameter so by using procexp, we can view what this handle points to: temp.txt
  6. The 2nd parameter passed seems to be from the runtime loaded DLL3.dll:.data, looking at the dump, we find ping www.malwareanalysisbook.com
  7. DLL 1 mystery data is the PID of the current instance of the process, DLL 2 mystery data is the handle to temp.txt’s value in decimal (0x2c = 4410) and DLL 3 mystery data is the memory address of the string in DLL3 (0x39B0C0 = 378080010)
  8. We can either manually load the DLL in IDA to match the x32dbg base address, or rebase it after loading it automatically in IDA.

Next Lab: Lab 10
Previous Lab: Lab 7