The need for PowerShell logging and further analysis.
As we continue to develop CyberEasy, our engineering team added a lot of features for enabling, collecting and analyzing PowerShell and full command line logging, which give us a lot of visibility in the endpoint in an efficient and performant way.
Recent publications suggest that has been an increase in the number of attacks that rely on PowerShell. There are some good reasons for that:
- PowerShell is enabled by default on Windows
- Widely distributed and used by Sysadmins
- Not too many people are looking at PowerShell from a defensive point of view.
- Powershell attacks seem to have a very low-level degree of obfuscation, that could be because threat actors know that not too much defensive tools are focused on detecting PowerShell attacks.
- Usage of new techniques such as the so-called Fileless attacks where not a file is created in the disk.
However, this kind of attack poses a great weakness too. As explained by Justin Henderson in his talk “Detecting Modern PowerShell Attacks with SIEM”, attackers need to send their attacks via the command line.
If our detection capabilities are doing the job and you have full command line logging, then chances are you can spot this behavior. At CyberEasy, we are able to collect and analyze the full command line string, which helps organizations to detect this technique.
Why PowerShell logging is needed?
The more visibility our detection tools could have regarding PowerShell, the better the detection ratio can be implemented. Back in 2016, FireEye folks published a great article that describes what is PowerShell Logging and how it should be turned on.
As described in the article, PowerShell 2.0 does not provide a good mechanism to log attackers activity but this feature has been improved in Powershell v 5.0.
I have extracted some of the key features of the different ways of PowerShell logging, those key ideas are an abstraction from Henderson’s talk referenced above. My handwriting might be hard to decode but I hope it gives an idea, in any case, you can go back to the presentation referenced above.
Just logging is not enough
Microsoft and the PowerShell team have made a great work on the logging of PowerShell scripts, they also provide a Warning log in the event that the analysis of the script reveals suspicious activities.
Unfortunately, this analysis might lead to both False-Positives and False-Negatives. As you can see on my Twitter from a few days ago, I was doing some research around Emotet Malware and it’s modus operandi on a compromised workstation.
Had I been paying attention, I would have noticed that PowerShell logging Base64 decoded the command line argument, however, it did not flag the script as a warning, even though it has a very low-level of obfuscation.
This PowerShell script block was executed by a macro when Microsoft Word document was opened. If you look at the code, it uses some obfuscation techniques such as the combination of upper and lower cases and the use of rogue variable names.
What it is clear is that the script is downloading a file, dragging it up in the user’s profile working path and right after it is starting the application if its content’s length is equal to 23931.
A lot of room for detection
This use case is a great candidate for Machine Learning detections; traditional string searches do not seem to be the right thing to do just because of the domain of combinations possible might be quite big. However, a tool can start by doing atomic detections, for example identifying when a download of a file is happening followed by the execution of that file.
In our team, we are applying several mechanisms of detection including the ones based on Machine Learning to reduce the rate of false positives.
As I was attending the SANS presentation, we can extract some potential detections that can be implemented to detect such behaviors.
Final Notes
Powershell is awesome and really really powerful; threat actors know that and as we analyze malware, we can see that different campaigns are using it.
If we analyze the PowerShell technique from MITRE ATT&CK Technique T1086, we understand that this technique is being used by so many threat actors including well-known Advanced Persistent Threat (APT groups).
Powershell logging is a key feature that was added in the version 5 of PowerShell; it enables defenders to have full visibility on every single command that is being executed in the endpoint and increase their detection capabilities to identify sophisticated attacks early in the Cyber kill chain.
However, relying on the built-in capabilities and features from PowerShell logging is not enough; event when Microsoft is doing a great job to detect suspicious script programs, it is far from being perfect.
For these detections to be effective we, the defenders, need to think out of the box (as always) but this time by taking advantage of multiple detection capabilities such as Yara Rules, Machine Learning, Regular Expressions, Patterns, and Behaviour Analysis and Profiling.
CyberEasy goes a step ahead and empower us to define behaviors and profiles from the command line execution and can be extrapolated to PowerShell scripts that are run on the endpoint.
