Since Red Canary relies heavily on telemetry streamed from endpoint agents, we don’t have good visibility into IIS logs. Despite that blindspot, these kinds of compromises consistently generate a predictable variety of endpoint telemetry, so let’s walk through some of the detection logic that was helpful in surfacing this threat and discuss the malicious behaviors associated with them.
It’s never a surprise when an adversary leverages PowerShell for malicious intent, as its capabilities are endless. Sadly, many organizations still struggle with detecting some of the easy wins, which is why adversaries continue to utilize it. Even when we feel we are making strides at having complete coverage for
PowerShell, research pops up leaving us to quickly verify our coverage.
Having previously done system administration, I can count on zero hands the number of times I’ve ever needed or wanted to encode any PowerShell commands/usage. There are always edge cases, but system administrators tend to want to work smarter, not harder, and that’s why simply looking for variations of
encodedcommand within your environment can be effective at detecting evil.
Detecting on all
encodedcommand variations is easier said than done, but even if you do not have complete coverage, having some detection logic that looks for a PowerShell command with the
-enc string will make an immediate impact within your environment. There are so many PowerShell exploitation frameworks that leverage that shortened usage of
-encodedcommand that the shortened
-enc string alone has almost become an indicator of compromise by itself due to it being the default by most frameworks.
In this case, the IIS worker process spawned PowerShell, which might be suspicious on its own in certain environments (which we’ll discuss below), and PowerShell then ran an encoded command. Although we wouldn’t have determined this activity was malicious purely based off of the usage of
-encodedcommand, had the adversary chose to not utilize encoding, then this activity would have been more difficult to alert on at scale without the additional detection logic that follows.
Another indicator within this activity that helped us quickly identify this threat was the usage of
Comsvcs.dll has a
minidumpw function that can be abused as a memory dumping technique and has been popping up more frequently as of late. Looking for instances of
comsvcs.dll to leverage the minidump function and/or
rundll32.exe with a command line containing the string
comsvcs.dll has been an effective way for us to identify this activity. For this technique to be successful, debug privileges are needed; in this instance, the exploit performed by the adversary provided them with requisite
Injection into lsass
Since adversaries can readily change up command-line parameters, command line-based detection methods are a bit brittle. To enhance these kinds of detection analytics, it’s a good idea to look out for any indications of processes injecting into
lsass.exe. With an appropriate amount of tuning, this “behavior” can be very effective at not only catching the above
comsvcs.dll activity, but identifying any custom code that is utilized to perform various types of credential dumping, like you might expect to see from
Mimikatz or other similar tools.
IIS spawning PowerShell
Microsoft Exchange isn’t what you typically think of for a web application, but because it does depend on IIS, the telemetry generated after a compromise will look very similar. For any third-party vendor, monitoring activity where IIS is spawning PowerShell alone doesn’t provide a lot of detection value because there are many administrative applications that we see on a daily basis that leverage PowerShell in similar ways, resulting in a lot of additional noise that can be detrimental to any security team. Additionally, this activity alone isn’t malicious by any means, but it can be helpful as supporting detection logic if you understand how your web services are expected to behave within your environment.