Lab 15-01.exe
Analyze the sample found in the file Lab15-01.exe. This is a command-line program that takes an argument and prints “Good Job!” if the argument matches a secret code.
Question 1
What anti-disassembly technique is used in this binary?
We can see that a jump instruction with constant condition and then a target that’s in the middle of a “call” instruction.
Question 2
What rogue opcode is the disassembly tricked into disassembly?
The attacker uses 0xE8 which is the opcode for the call instruction, the call instruction takes about 5 bytes worth of operand so, the disassembly is incorrect.
We may fix this by undefining the instruction and defining the jmp target as code and it shows up the real disassembly.
Question 3
How many times is this technique used?
This technique is used roughly 5 times in the disassembly.
Question 4
What command-line argument will cause the program to print “Good Job!”?
The program checks if the number of command line arguments are 2 (including the program name) and the input Lab15-01.exe pdq.
Lab 15-02.exe
Analyze the malware found in the file Lab15-05.exe. Correct all anti-disassembly countermeasures before analyzing the binary in order to answer the questions.
Question 1
What URL is initially requested by the program?
We know that the malware uses InternetOpenUrlA() to beacon out to domains, so we can check all xrefs to this function:
Following that xref, we can see that the malware takes in it’s lpszUrl parameter from sub_401386 (renamed to Init_URL):
Digging into this function, we find that it sets up a URL but in a more peculiar way, it defines an array of characters and then sets each index with the character of the URL.
Normally when defining strings, the compiler would take the string literal, put it in the
.datasection and simply sets up string variables by setting them to the pointer of the hardcoded string.
It also needs to set the last element to a null terminator so the URL becomes a null terminated C string, after which it calls the strdup() function and returns a pointer to the now valid C string.
From there, we can conclude that the initial URL that the malware beacons to is: http://www.practicalmalwareanalysis.com/bamboo.html
Question 2
How is the User-Agent generated?
When malware firsts beacons to the internet, it has to initialize the functions that do that, and the first function that it calls is InternetOpenA as one of it’s parameters allows us to set the User-Agent used for beaconing, so we will have to see all the xrefs to this function.
From there we notice that the lpszAgent parameter is set to a certain name variable, so we’ll have to trace back and see what this name variable is evaluated to:
Checking the first xref of this function, we see that name variable actually contains the hostname of the victim’s computer.
But that’s not all, the malware then loops over the name variable such that it increments each character by one (according to the ASCII table), and if the characters are boundary characters (such as 'a', 'A', 'Z', etc…) it rolls back to the start of the character set so that it doesn’t print out unprintable characters.
Question 3
What does the program look for in the page it initially requests?
After beaconing out to the server, the malware then reads the content which is responded back to the malware, then it looks for a substring Bamboo:: within the reply, if it does find it then it carries on, if not, the main function returns.
Question 4
What does the program do with the information it extracts from the page?
After the malware finds Bamboo::, it takes the string next to :: and then attempts to beacon to that as a URL.
The malware then reads back the response and writes it back to a file whose name is initialized by the function sub_40130F (renamed to File_Init) which sets up the name in a similar manner to the original URL beacon in [[#Lab 15-02.exe#Question 1|Question 1]].
The file name is
Account Summary.xls.exe.
Lastly, the malware then calls ShellExecuteA to execute the newly created file.
So in summary, the malware beacons for an initial URL which responds back with another URL (that the malware parses for) that has an executable as a URL (for example: www.c2.com/text.exe) and then it writes back whatever that C2 server responds with into a file called Acconut Summary.xls.exe and then executes that newly written executable using ShellExecuteA().
We can conclude that the malware serves as a downloader and an installer.
Lab 15-03.exe
Analyze the malware found in the file Lab15-03.exe. At first glance, this binary appears to be a legitimate tool, but it actually contains more functionality than advertised.
Question 1
How is the malicious code initially called?
Taking a general look at this code, we can see that it’s a process enumerator where it prints out every process throughout the system and also prints basic information such as the priority, thread count, parent PID, etc…
But throughout the course of the main function, we do not see a reference to the URLDownloadToFileA() which is odd because why would a program that prints out process information ever download files from the internet?
Checking the xrefs to this function, we only find a single location in which this function is called and it seems to be in a place where alot of disassembly techniques are used, so we’ll have to manage those out and clean up the disassembly logic.
If we take a look at this screenshot, we can see that this function sets up an exception handler and then invokes a division by zero handler to jump to this location loc_4014C0.
So we’ve established that something suspicious will get executed starting from 40148C
But how does it reach the location 40148C in the first place?
If we take a look at the main function when it sets up the stack frame, we can see that it actually modifies the return address to point to 40148C so that it’ll start from there after the _main function ends.
This serves as a good way to hide any xrefs to the malicious address’ code as it has to compute it first.
Question 2
What does the malicious code do?
As discussed in the previous question, we see that the sample sets up an exception handler, pushes it to the SEH chain and then invokes a division by zero exception to jump to that handler.
The handler removes itself from the SEH chain and then takes some data in the .data section and decodes it using sub_403010, which are eventually passed to URLDownloadToFileA() and what is downloaded is executed by the means of WinExec().
Question 3
What URL does the malware use?
As explained in the previous question, we know that the malware attempts to decode some hardcoded encoded data within the executable so decoding them will unveil the parameters to URLDownloadToFileA.
Decoding the sub_401534, it just XORs each character with 0xFF as a key:
Turning into Cyberchef to decode this for us, we see that this is the URL that is beaconed to.
http://www.practicalmalwareanalysis.com/tt.html
Please Note:
You may notice that I used a NOT gate instead of an XOR gate, that’s because XORing with 1
(0xfffffff)is equivalent to negating all the bits of input (taking one’s complement of the input).
Question 4
What filename does the malware use?
As shown in the previous question, the malware encodes the parameters of URLDownloadtoFileA, so we apply the same approach as the previous question and we obtain the filename.
spoolsrv.exe
So in conclusion, the rogue program does it’s work as it’s supposed to do (printing process information)
and then after it’s job is complete, it attempts to beacon out to a C2 server to download it onto the victim’s PC and then executes it, so it is a downloader and an installer.