September 11, 2018

"Tracing" Malicious Downloads

In this blog post, I will be covering a very interesting artifact found in the Windows registry, which indicates whenever an executable (i.e. legitimate and illegitimate) attempted to establish a network connection to download files for the first time.

"Tracing" Malicious Downloads

Whenever threat actors use malicious Microsoft Word documents or legitimate Windows system utilities (e.g. Notepad, PowerShell, etc.) to download a malicious tool or a piece of malware, it can create many different indicators on a Windows system. In this blog post, I will be covering a very interesting artifact found in the Windows registry, which indicates whenever an executable (i.e. legitimate and illegitimate) attempted to establish a network connection to download files for the first time. We will go over the "tracing" registry keys, highlight a couple of sample cases, and show you how to detect these artifacts and what they mean.


Before We Continue

This artifact is not going to give you all the answers to an investigation, but it will be helpful in identifying if a threat actor may have leveraged other systems to download malicious files. This is extremely useful when you know a threat actor is leveraging a specific tool (i.e. legitimate and illegitimate), that isn't used in the organization to do this. At the time of this blog, I was using a Windows 7 Professional Edition to extract artifacts and figures used here. With that in mind, let's dig in!


Tracing Registry Keys

Windows has a feature where it will create subkeys within the "tracing" registry key for whenever Windows needs to trace issues or monitor an application and its execution. These keys are located in the following path on a Windows 7 workstation:

HKLM\Software\Microsoft\Tracing

The majority of subkeys within the "tracing" registry key are related to Remote Access Service (RAS) (https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ras-architecture-overview), which means that some of the applications that are listed under the "tracing" key attempted to establish network connections (Important Note: This does not apply to all applications that attempt network connections, which I will explain in a bit). The following figure provides a snippet of some of the keys on my Windows 7 system:

Figure 1: Subkeys from the "HKLM\Software\Microsoft\Tracing" registry key

In this blog, we will be focusing only on the "RASAPI32" and "RASMANCS" registry keys, as they are the ones that are associated to the different applications listed in the figure above. Therefore, the keys that we are going to focus on are:

HKLM\Software\Microsoft\Tracing\<executable_name>_RASAPI32
HKLM\Software\Microsoft\Tracing\<executable_name>_RASMANCS

These registry keys get created the first time an application interacts with the Remote Access API, "rasapi32.dll", and the Remote Access Connection Manager, "rasman.dll". Since these Dynamic-Link Libraries (DLLs) are related to RAS, it indicates that applications that have "RASAPI32" and "RASMANCS" registry keys attempted network connections.

Therefore, using "powershell" from Figure 1 as an example, if a system administrator uses PowerShell very heavily, and used it to download files on a system, the timestamps of these registry keys would be related to the system administrator's first file download using PowerShell on the system. So, even if a threat actor managed to gain access to the machine afterwards, and leveraged PowerShell to download a malicious payload, the timestamp would not get updated, rendering this artifact a bit meaningless. Nonetheless, for this blog, let's consider that system administrators and regular users do not use PowerShell at all.

Now, back to these registry keys. Within them you will have various values that won't be really useful from a forensic standpoint, but let's quickly cover them. The figure below shows the values for the "RASAPI32" and "RASMANCS" registry keys, since they both have the same contents:

Figure 2: "RASAPI32" and "RASMANCS" registry key values

There are a couple of interesting values that standout when you look at the figure above. "FileDirectory" is the path where Windows Tracing will output trace logs, if enabled. However, since "EnableFileTracing" and "EnableConsoleTracing" are both set to "0", then no trace logs will be created for the application. Now, as a security person you would think that you would want to log these entries as they may contain useful information, but they really don't. Nevertheless, if you want to test it out, open up "regedit.exe" and edit those values to "1" to enable them.

Figure 3: Contents of the "powershell_RASAPI32.log" file
Figure 4: Contents of the "powershell_RASMANCS.log" file

In these figures above, I conducted three different tests to determine whether trace logs would provide any intrinsic forensic value, so I tested the three scenarios in the following order, and you will see that aside from "ProcessId", there's not much we can pivot off of.

  1. Successfully connected to "www.allthingsdfir.com"
  2. Attempted to connect to "www.allthingsdfir.com" without a network connection
  3. Attempted to connect to a non-existing page with a network connection

Examples

After conducting various investigations and personal research, I have seen these registry keys pop up many times. In some cases you can get to see the creation of these registry keys with malicious binary names or even potentially unwanted program (PUP) names. However, since I do not have a piece of malware handy with me, here are some of the ways that I have seen that these keys can get created legitimately and illegitimately.

PowerShell

We have already seen this in the previous section, but this is by far one of the most common ones I have seen. There are malicious Microsoft Word documents out there in the wild containing PowerShell commands that attempts to download and execute a payload on a system– thus essentially creating a backdoor. Most of these commands are obfuscated or encoded in Base64, but for this blog, this is the raw command that triggers the creation of the registry key:

(New-Object Net.WebClient).DownloadString(<URL>)

Simply replace "<URL>" with the address to where the malicious script is located. By running a command like this, it will trigger Windows Tracing, which will lead to the creation of the "powershell_RASAPI32" and "powershell_RASMANCS" registry keys.

Notepad

Yes, Notepad. This is an oldie, but a goodie. If you look closely at Figure 1, you would notice that there are two "notepad" registry key entries. In order for this to happen, launch Notepad and click on "File > Open...". Once a new window is prompted, instead of searching for a filename, you can simply insert a URL and Notepad will open up a network connection, thus creating these registry keys.

Figure 5: Downloading a file using Notepad

From a threat actor's perspective, they can download malicious binaries and execute them on the system using Notepad, instead of having to use PowerShell. From a security standpoint, because of the "RASAPI32" and "RASMANCS" registry keys, it's easy to track. Notepad is not utility commonly used to establish network connections and let alone download files. So the existence of these keys for Notepad is a clear indicator that there is something odd.


After Thought

So what's the main point of all this? By understanding the "RASAPI32" and "RASMANCS" registry keys and going through the different examples, here's another way to identify if an application had established a network connection to potentially download a file. Even though this artifact is very specific and there are other easier ways to detect whenever a malicious file was downloaded on a system (assuming that no one uses Notepad or PowerShell to download files), it simply presents another artifact to search for.

Let's assume that a threat actor has used PowerShell to download a malicious payload on a system to create a backdoor. As a threat actor, they would most likely want to deploy various backdoors across multiple systems on the network. But let's say that due to the sophistication of the threat actor and their anti-forensics capabilities, they may delete the malware files (i.e. if any, since you can run everything in memory with PowerShell) on all systems and clear Windows Event logs. At that point, it's a bit tough to run a search across all systems to identify if the threat actor had access to them. However, with these registry keys, it's possible to say that those systems may have been impacted.

I hope that this blog post has been useful for you. I have been fascinated by this artifact for a while and I've wanted to post something about it. Hopefully this can help you identify additional compromised systems in an investigation or create additional triggers to further protect your environment. By no means am I an expert with Windows Tracing and RAS functionalities, as this has all been my personal research on it. Nonetheless, if you do get see anything that is out of the ordinary please don't hesitate to reach out! Happy hunting!