~/Malware Must Run
back to write-ups
PMA March 8, 2025

PMA Lab 14-1: Malware-Focused Network Signatures

Analyze the Malware found in file Lab14-01.exe. This program is not harmful to your system.

pmachapter-14

Lab 14-1

Analyze the Malware found in file Lab14-01.exe. This program is not harmful to your system.

1) Which networking libraries does the Malware use, and what are their advantages?

The Malware uses UrlDownloadToCacheFileA. Since this function uses the COM Interface, it gives an advantage to the Malware Developer since the requests are made by the OS and. These requests will blend in among the several other legitimate requests that usually made by the infected host.

2) What source elements are used to construct the networking beacon, and what conditions would cause the beacon to change?

In order to understand better this function, lets jump to it and move backwards. URLDownloadToCacheFileA is inside sub_4011A3:

This function takes the following parameters:

HRESULT URLDownloadToCacheFile(
  _In_       LPUNKNOWN           lpUnkcaller,
  _In_       LPCSTR              szURL,
  _Out_      LPTSTR              szFileName,
  _In_       DWORD               cchFileName,
  _Reserved_ DWORD               dwReserved,
  _In_opt_   IBindStatusCallback *pBSC
);

The URL is the second parameter, which we can see in the IDA Image that is passed from aHttpWww_practi var_210 and then to ecx. Following this string in IDA, we can see that it is stored in the .data section and has the following format:

image-20210331220642680

The %s of the string is the parameter passed to sub_4011A3, thus we know this parameter will be used as the URI path. The %c (single character) will have the value of the last character of the URI (obtained between the _strlen and _sprintf calls before URLDownloadToCacheFileA) which is passed to var_214.

Function sub_4011A3 is called from Main, so let’s go back to Main in order to find out how the URI is created.

Main starts with two API Calls:

  • GetCurrentHwProfileA - Retrieve information about the current hardware profile for the local computer.
  • GetUserNameA - Retrieve the name of the user associated with the current thread.

As we can see after GetCurrentHwProfileA several characters are being pushed to the stack, which will then be used to build a string with _sprintf. This string is being created with the last characters of the GUID.

For example, considering the following GUID: 12340001-4980-1920-6788-123456789012

The Malware is pushing characters 25 (19h) to 36 (24h), thus considering only the substring 123456789012 and thus the _printf would create the following string: 12:34:56:78:90:12

Looking closely at the previous image, in the bottom we have a second _printf call, this will create another string with the following format “%s-%s” where the two parameters are the GUID and the Username (e.g. 12:34:56:78:90:12-User123).

This string is then passed to sub_4010BB:

sub_4010BB has several arithmetic operations and calls another function (sub_401000) also with several arithmetic operations. From the KANAL output, it looks like a Base64 encoding function:

image-20210401145206651

Since this function takes a buffer (string) as a parameter and the same buffer is then passed to URLDownload_func (sub_4011A3) we can deduct that sub_4010BB is the string responsible for encoding the GUID/Username string and thus generating the URI that is going to be used later.

This can be proved with a Debugger:

image-20210401142752810

By placing a breakpoint at the call sub_4010BB we can observe the GUID/Username string in the memory buffer that is passed to the function (ecx) and a second buffer (eax). After stepping over this call and inspecting the second buffer (eax), we can find the generated URI:

image-20210401142951686

This is the URI used by the Malware to perform the requests to the C2:

image-20210401143027014

3) Why might the information embedded in the networking beacon be of interest to the attacker?

At the Server side it sure is a decoding routine that is able to decode the Path and thus identify the infected host. The attacker then can send specific instructions to that host that may be different from the instructions sent to other hosts.

4) Does the malware use standard Base64 encoding? If not, how is the encoding unusual?

The Base64 encoding routine has a slight change. Inside sub_40100 it seems that the Base64 padding has been substituted by the character “a” whereas in the normal routine the padding is done using the character = . These changes are highlighted in the following images:

  • Lab14-01.exe:

image-20210401150736781

  • Executable with regular Base64 encoding routine:

image-20210401150640645

As we can see the the ”=” character has been replaced by the “a” character.

In the following command executions it’s possible to see the decoding of the generated string by the Malware. Using a regular Base64 character table there is a strange char in the end:

printf "ODA6NmQ6NjE6NzI6Njk6NmYtS2V2aW4a" | base64 -d
80:6d:61:72:69:6f-Kevin�

By replacing the last character of the encoded string (a) with the regular padding character (=) the string is perfectly decoded:

printf "ODA6NmQ6NjE6NzI6Njk6NmYtS2V2aW4=" | base64 -d
80:6d:61:72:69:6f-Kevin

Thus, we can assume that this Malware uses a Base64 encoding with a custum change.

5) What is the overall purpose of this Malware?

This Malware will beacon a C2 server each 60 seconds waiting for a File to execute. While it doesn’t receive the file it will keep on beaconing the C2 and sleeping for 60 seconds. After receiving a file and executing it will terminate the execution.

6) What elements of the Malware’s communication may be effectively detected using a network signature?

A simple network signature to check the domain www.practicalmalwareanalysis.com would be useful to detect this Malware, but obviously isn’t too reliable in the long term since the domain is easily replaced by a Malware Author.

A more reliable signature would be to look for the URI patter. After reverse engineering the Malware, it was possible to understand that the pattern used by the Malware to generate the URI is a Base64 encoded string created dynamically with information obtained from the infected host (GUID and Username).

Before the Base64 encoding, a pattern is easily observed (e.g. 12:34:56:78:90:12-User123):

  • 2 chars + ”:” + 2 chars + ”:” + 2 chars + ”:” + 2 chars + ”:” + 2 chars + ”:” + 2 chars + ”-” + anything (Username)

Even though the string generated by the Malware is going to be Base64 encoded, there is still a pattern that stands out.

In the following image we have 5 examples of strings that would be generated by this Malware (in the yellow rectangles). The common pattern in these examples is highlighted in red.

These examples generate the strings in the red rectangles after going through both sub_4010BB, and sub_4011A3, and the common pattern in these examples is highlighted in yellow:

  • 3 chars + “6” + 3 chars + “6” + 3 chars + “6” + 3 chars + “6” + 3 chars + “6” + 3 chars + “t” + anything (Username Base64 part) + ”/” + 1 char (same as the last char of the Username part) + “.png”

image-20210402023132242

This pattern may be unique enough for the creation of a Regex to detect the Beaconing behavior employed by this Malware. In order to test the Regex I used the regex101 website and fed it 200 unique Base64 strings with the same pattern used by the Malware:

image-20210402024208891

Regex example:

/\/[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}[a-zA-Z0-9]*\/[a-zA-Z0-9]{1}.png/

7) What mistakes might analysts make in trying to develop a signature for this malware?

Without fully understanding the Network elements of this Malware some mistakes may be done while creating Network signatures.

For example, if the Malware is executed only in one machine and a rule is blindly created, two mistakes may occur:

  • Assumption of the URI character size is fixed
  • Assumption that the requested file has a fixed name (e.g. a.png)

8) What set of signatures would detect this Malware (and future variants)?

In order to test the Snort rule development process in order to detect Lab14-01.exe, two Snort rules were created:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS \
( \
        msg:"PMA domain detect"; \
        content:"www.practicalmalwareanalysis.com"; \
        sid:1 \
)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS \
( \
	msg:"PMA Lab 14.1 - Beacon C2"; \
	flow:to_server; \
	content:"GET"; http_method; \
	pcre:"/\/[a-zA-Z0-9+\/]{3}6[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}6[a-zA-Z0-9]{3}t([A-Za-z0-9]){1,}\/\1\.png/"; \
	sid:2; \
)

The first rule is a simple rule to detect requests made to www.practicalmalwareanalysis.com and the second rule is more specific and aims at detect the Beaconing request with a Regular Expression, as explained in question 6).

In the following image it’s possible to see the content of the Alert logs being written to a file named log/alert while the Malware is running and using a machine with Snort running as a Gateway:

image-20210401235433912