ThreatOps Analysis: Keyed Malware

Malware authors are always coming up with clever ways to avoid detection. For malware written with managed code—for example, PowerShell or .NET malware—the authors will encode it to make it even harder to identify its malicious intent.

But if we were to take that a step further, attackers will sometimes “key” the malware for a particular host or user. This means the malware can only be run on the targeted host because it is tied based on hostname, IP address, or even the logged-in user.

Let's dig into an example.

In this blog, we’re looking at a PowerShell command with an environmentally keyed payload. In other words, the payload will (normally) only execute on the particular host for which it was keyed, making automated analysis much more difficult.

The Find

We identified a host with multiple malicious footholds. One such foothold was a PowerShell command configured to run as a service:

The command uses the COMSPEC environment variable, which by default points to cmd.exe. The command first starts an instance of cmd.exe, which starts another cmd.exe, which ultimately starts PowerShell.exe running a command specified by the -C option (the shortened -Command option).

The PowerShell command itself consists of a long hexadecimal string concatenated with a call to Convert.FromBase64String() and a base64 string as the argument. Decoding the base64 string reveals what appears to be a decoder that the hexadecimal string (789cbd588f73…) is piped into:

The 'Bad key' on the last line of the decoder stands out; there seems to be a case where the decoder can fail. Looking closer, we can see the COMPUTERNAME, USERNAME, DOMAINNAME, and IP address (lines 11–13) are combined to create a key — $kl— which is required to decode the payload (the hexadecimal string from the command):

Malware authors and attackers like to use PowerShell because it is ubiquitous. In addition, the nature of PowerShell code makes it harder to identify as malicious, especially if the command is encoded. To inspect it, you either have to decode it or observe it while running. In this case, the payload was keyed to the host, so you can’t just run it anywhere.

We were able to hard code the key using the details we knew about the host (line 2) and print the decoded payload (line 17) rather than executing it:

The decoded payload is a stager used to download and execute Meterpreter directly from memory.

Interestingly, the payload includes several error messages that you would not expect to find in malware. For example, “something blocking access to the ‘Connect’ method, probably Firewall or AV software.” With the use of meterpreter and the expressive error messages, we initially thought this was from a penetration test, but the customer said they had not engaged a pen-testing company. 🤨

• • •

We hope you enjoyed this glimpse into the types of shady tactics that cross our threat analysts' desks. If anything, it shows the lengths attackers will go to maximize their payload and minimize their chance of being detected.

Want to dive into more threat analysis? Read some of our other blogs:

• Cobalt Strikes Again: An Analysis of Obfuscated Malware
• Abusing Ngrok: Hackers at the End of the Tunnel
• Tried and True Hacker Technique: DOS Obfuscation