Security Monitoring MP: Powershell Exploit Toolkit Rules
Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.
In this post we will discuss using SCOM to detect various PowerShell Exploits that are commercially available for download and use. I’d note that there are limits to this type of detection activity. First, it is worth noting that good attackers don’t use commercially off the shelf attack tools but instead recompile them to suite their needs. That makes it very difficult to detect, and any detection activity would require having access to the attackers tools (at which point, they will update them to bypass your detection). There is some value to this from the standpoint that it increases their costs and time effort, which at some point will encourage them to find a different victim, but these detections are not something that one can rest on and say “I’m secure.” That said, some attackers have been known to use these tools, as it requires little or no effort to get up and running. As such, I’m building these into the Security Management Pack, as most have very little practical use in an environment.
All of these will be included in the Security Monitoring MP. Two rule sets will be created. One will target the Windows PowerShell log on Windows Servers. The other will target the Forwarded Events log on the Windows Event Forwarders. All of this requires PowerShell logging to be enabled on servers and desktops. With desktops, those log items will need to be forwarded to the Event Collector Servers.
- Security Monitoring: Invoke-Shellcode is in use – used to inject payload into an existing process and execute it.
- Security Monitoring: Invoke-DllInjection is in use – used to inject a DLL file into an existing process.
- Security Monitoring: Find-AVSignature is in use – used to split a file into multiple smaller files to determine the location of the signature that antivirus is detecting.
- Security Monitoring: Get-DllLoadPath is in use – Used in conjunction with Invoke-DLLInjection. It finds the path of the DLL that an application is using.
- Security Monitoring: Invoke-PortScan is in use – Used to scan open ports on servers.
- Security Monitoring: Get-HTTPStatus is in use – Used to dictionary a web service to find status of a specific HTTP or HTTPS path.
- Security Monitoring: Invoke-Mimikatz is in use – this is a PowerShell version of mimikatz that sits in memory and is undetectable by AV.
- Security Monitoring: Get-Keystrokes is in use – this is a PowerShell key logger.
- Security Monitoring: Invoke-NinjaCopy is in use – this is used to make a copy of the SAM while it is in use. Said copy can be then brute forced for the secrets it stores.
Of these rules, only Invoke-Mimikatz was checked in the first release. The rest will be in the next release. There is not much special to these rules. PowerShell logging generates an event ID of 800 in the Windows PowerShell log with the command that was run. All of our rules key in on that event ID and the specific command in the Event Description. If these tools are in use in your environment, you should get visibility. While I don’t believe that this will be beneficial against an advanced threat, this will catch some nefarious activity if the attackers are using commercially available tools.