PMA Lab 14-2: Malware-Focused Network Signatures
Analyze the malware found in file Lab14-02.exe. This malware has been configured to beacon to a hardcoded loopback address in order to prevent it from harming your system, but imagine that it is a har
Lab 14-2
Analyze the malware found in file Lab14-02.exe. This malware has been configured to beacon to a hardcoded loopback address in order to prevent it from harming your system, but imagine that it is a hardcoded external address.
Analysis
In the WinMain function the Malware starts by reading a string from the Resources, and creating two pipes. After that there’s a call to DuplicateHandle. The following is the syntax of this API Function:
BOOL DuplicateHandle(
[in] HANDLE hSourceProcessHandle,
[in] HANDLE hSourceHandle,
[in] HANDLE hTargetProcessHandle,
[out] LPHANDLE lpTargetHandle,
[in] DWORD dwDesiredAccess,
[in] BOOL bInheritHandle,
[in] DWORD dwOptions
);
Here it is possible to see the parameters on the stack prior to the call:
From the msdn documentation it is possible to undestand that the Malware is duplicating a handle on the same process (hSourceProcessHandle set to -1). Also, the Malware is duplicating handle 98 (hSourceHandle) and storing it on memory address 0012FE04 (lpTargetHandle).
The following 3 parameters are dwDesiredAccess, bInheritHandle, and dwOptions. From the documentation it is possible to understand that these values mean that the Malware will have GENERIC_WRITE access to this handle (dwDesiredAccess = 2), the handle will be inheritable by any child process (bInheritHandle = 1), and no specific options are provided for the duplicate handle (dwOptions = 0).
Since the Source and Target handle is the same, it is possible to assume that the only goal of the Malware here is to make sure this handle is inheritable by any child processes. And the Malware then calls CreateProcessA, which spawn a cmd.exe process.
So why is the Malware doing all of this? This is way easier to understand in Pseudocode C:
From line 40 to 54 we see a StartupInfo struct being constructed. This startup structure is then passed to CreateProcessA. So, in a way the Malware just redirected the stdout and stderr of the cmd.exe process to the “WritePipe” (handle 98) and stdin to the “ReadPipe” (handle 94).
After creating the first thread, the Malware calls PeekNamedPipe, which has the following syntax:
BOOL PeekNamedPipe(
[in] HANDLE hNamedPipe,
[out, optional] LPVOID lpBuffer,
[in] DWORD nBufferSize,
[out, optional] LPDWORD lpBytesRead,
[out, optional] LPDWORD lpTotalBytesAvail,
[out, optional] LPDWORD lpBytesLeftThisMessage
);
PeekNamedPipe copies data from a named or anonymous pipe into a buffer without removing said data from the pipe.
Looking at the parameters in the stack prior to the call, it is possible to understand the following:
- The pipe handle provided is 94;
- Address 00373FA8 is going to receive the data that is read from the buffer (lpBuffer);
- The size of the buffer is 4 (lpBuffer);
- Address 00BFFFB4 is a pointer to the variable that is going to receive the data (lpBytesRead)
- The following two parameters (lpTotalBytesAvail, and lpBytesLeftThisMessage) are Null.
After the call, the address of lpBuffer is populated with a 4 byte string:
On address 00401546 the Malware calls ReadFile. Although the API function is called “ReadFile”, it can read data other types of sources other than files. In this case it is reading data from a pipe:
BOOL ReadFile(
[in] HANDLE hFile,
[out] LPVOID lpBuffer,
[in] DWORD nNumberOfBytesToRead,
[out, optional] LPDWORD lpNumberOfBytesRead,
[in, out, optional] LPOVERLAPPED lpOverlapped
);
From some of the values pushed to the stack prior to the call it is possible to understand that:
- hFile = 94 (handle to the read pipe);
- The buffer that is going to receive the data that is read is 00373FA8 (lpBuffer);
- 257 bytes are to be read (nNumberOfBytesToRead)
After the call it is possible to see the lpBuffer address filled with a string:
This information is the prompt from the cmd.exe process that has been created earlier.
At somepoint in the second thread there’s a call to strcmp with two strings being compared, the data receveived by the c2 server (in this case the InetSim banner) and the string “exit”.
If the command received by the C2 is “exit”, the Malware will eventually delete itself on sub_401880 and terminate execution:
At somepoint the data from the C2 is written to the “Write Pipe”, which being the stdin of the command shell, it makes sense to replace the banner from InetSim with valid command line commands to see if this works. After simulating a dir command from the C2 the following request is made:
Using CyberChef to try to decode the User-Agent, providing the custom Base64 table, it is possible to see that the Malware can indeed execute commands on the spawned cmd.exe:
Here’s part of the dir command, with the rest of it being sent on different web requests.
With this, it’s possible to understand that the Malware spawns a command shell, receives commands from the C2 server and uses one thread to send the responses to the C2 server, and the other thread to query the C2 server for more commands. Thread 1 exfiltrates the output of the commands using the User-Agent.
1) What are the advantages or disadvantages of coding malware to use direct IP addresses?
Coding Malware with direct IP Addresses allows the Malware author to avoid the Malware being blocked by sink-holes. In terms of disadvantages, and given the fact that this Malware performs web requests, the requests will likely standout from others, since in this case the Malware author won’t be mimicking legitimate domains.
2) Which networking libraries does this malware use? What are the advantages or disadvantages of using these libraries?
The Malware uses libraries such as InternetOpenA, InternetOpenUrlA, InternetReadFile, and InternetCloseHandle.
These API Functions allows the Malware to blend in with regular traffic, since these are the same API functions used in regular browsing.
Here we can see the Malware pushing a URL into the stack prior to calling InternetOpenUrlA:
One disadvantage from the Malware author prespective is that the API Functions that the Malware is using require the Malware to specify a User-Agent, and in this case, after reverse engineering the Malware, one can find this User-Agent string and use it to create a detection rule.
3) What is the source of the URL that the malware uses for beaconing? What advantages does this source offer?
The Malware uses LoadStringA in order to load a string resource. Below it is possible to see the syntax of LoadStringA:
int LoadStringA(
[in, optional] HINSTANCE hInstance,
[in] UINT uID,
[out] LPSTR lpBuffer,
[in] int cchBufferMax
);
Following the syntax, and looking at the stack prior to the function call, we can see that the Malware is loading the string number 1, from the current file and is going to write the string to the buffer provided by eax (in this case 0012FE24):
Using the “Follow in Dump” feature of x32dbg it is possible to find the content of the buffer:
One advantage of using this method is that the Malware author may replace this resource of the Malware with a different one without having the need to recompile it. This possibility has actually been “exploited” in order to make the Malware analysis easier.
4) Which aspect of the HTTP protocol does the malware leverage to achieve its objectives?
This Malware is communicating to a loopback IP Address. In order to better analyze it using Network monitoring tools, the sample has been edited and the Resource URL has been edited to a local IP Address where traffic can be captured and intercepted.
After executing the Malware, several HTTP requests have been made. The first one contains a different User-Agent, which from the looks of it, is an encoded base64 string:
All the remainder HTTP Requests contain a hard coded User-Agent:
After debugging the Malware, it is possible to see that 2 Threads are launched, the first Thread only makes one request with the “strange” User-Agent, whilst the second Thread will make several requests.
5) What kind of information is communicated in the malware’s initial beacon?
The Malware is exfiltrating an encoded string via User-Agent. The information is the prompt of a Windows command line that has been just opened. After impersonating a C2 server it is possible to see that this function also exfiltrates the outputs of the commands that are executed in the spawned cmd.exe process.
6) What are some disadvantages in the design of this malware’s communication channels?
This Malware performs several requests. Some of these requests have the same User-Agent string and are followed with a pattern, since each request is made 2 to 3 seconds after the last one. This can be used to create a Snort Signature to detect the beaconing process of this Malware.
(Note that once again, in order to make the analysis easier, the IP Address of the sample has been changed)
7) Is the malware’s encoding scheme standard?
The Malware uses Base64 encoding. It is possible to see that the User-Agent that it uses on the first request has the pattern of a Base64 string (except the first 3 characters):
It is also possible to understand that sub_401000 is the function responsible to create the User-Agent string. Also on the Malware strings we can see a Base64 character table, but it is not the default table:
8) How is communication terminated?
The communication is terminated if the C2 server sends a command “exit”. Otherwise it will keep requesting the C2 which commands to run on the system.
9) What is the purpose of this malware, and what role might it play in the attacker’s arsenal?
This Malware is a backdoor that provides the attacker access to the infected system via a spawned command shell. The C2 communication is made via web requests, instead of sockets.