Have you ever seen a shell game being played? Nobody but the swindler knows which cup holds the ball. Detecting a cyberattack launched using PowerShell is a lot like playing a shell game, except, in this case, it is possible to outwit the swindler. All you need is keen observational skills and the right tools.
The key to detecting any PowerShell attack is to try to catch it early.
In the final part of this three-part series, we will see how a SIEM solution with Active Directory auditing capabilities can help you detect a PowerShell attack by watching out for some telltale signs. We will take the examples of two common attack techniques used by malicious actors to try to infiltrate the Active Directory environment of an organization. They are:
Attackers use AD enumeration for reconnaissance and the pass-the-hash exploit to obtain credentials and elevate privileges.
We will be simulating these executions in the Active Directory of a virtual test environment using a popular pen testing tool called PowerShell Empire. We recommend that you read the first and second part of this series to get a better understanding of the tool, the test environment, and how to execute the attack.
We will first list the various executions that will occur on the victim server and then see how a SIEM solution can help detect them.
Before we deploy the agent from the Kali Linux machine to execute malicious PowerShell commands on the target Windows server, we need to disable certain features of Windows Defender. Windows Defender is the built-in antivirus and security tool that comes with all Windows machines. We will be doing this using PowerShell commands to avoid easy detection.
The features we will disable and the commands we will use to disable them are as follows:
Disabled feature | Function | Command used to disable it |
---|---|---|
Real-time monitoring | Disabling real-time monitoring stops Windows Defender from continuously tracking all the file and process scanning in real time. | Set-MpPreference -DisableRealtimemonitoring $true |
Archive scanning | Archive scanning allows users to set up scans to detect malicious software in archive folders (files with the ZIP extension, for example). | Set-MpPreference -DisableArchiveScanning $true |
When organizations enable PowerShell logging, a SIEM tool with Windows change auditing capabilities can pick these logs up, parse them, and display them in the form of easily comprehensible dashboards, graphs, and reports. ManageEngine Log360, for example, displays three different reports: Process Tracking, Script Block Logging, and Module Logging. Both of the commands listed above are picked up by Log360 and displayed in Script Block Logging reports. They can be viewed under the Script Data column as shown in Figure 1 and 2.
Figure 1. The PowerShell command to disable real-time monitoring in Windows Defender shown in Log360 under the Script Data column.
Figure 2. The PowerShell command to disable archive scanning in Windows Defender shown in Log360 under the Script Data column.
After disabling the above features of Windows Defender, we can deploy the agent. This requires generating a script through PowerShell Empire and launching it on the server. This is a malicious PowerShell script that must be executed through administrator access. The agent helps execute the rest of the scripts on the server.
When Script Block Logging is enabled through PowerShell auditing, the entire script executed to connect the victim server with the attacker's machine is captured in the Script Block Logging report, as shown in Figure 3.
Figure 3. The launcher script captured by Log360's PowerShell auditing reports.
Analysts can engineer an alert or custom report profile to detect, record, and respond to the executed script. Log360 provides a built-in report based on the parameters used to execute a PowerShell Empire launcher. The report is called Empire PowerShell Launch Parameters and is displayed in Figure 4.
Figure 4. The Empire PowerShell Launch Parameters report in Log360.
Once the agent has been deployed, we can execute various modules present in PowerShell Empire. For AD enumeration, we will be using situational awareness modules by executing the following scripts:
When the agent executes these PowerShell scripts on the victim server, it does so in the form of obfuscated code. In this case, most of the scripts use a Get command or module. This is obfuscated in the form of Get-Random commands, which can be captured by module logs.
Using a SIEM solution, analysts can set up alerts to be notified whenever a suspicious number of Get-Random commands has been executed within a particular time frame. By scanning through the other module logs and the script data in those log entries, analysts can identify whether the executions are malicious or not. Figure 5 shows an obfuscated command captured by PowerShell audit reports in a SIEM solution.
Figure 5. An obfuscated Get command captured by the Module Logging reports of Log360.
PowerShell can also be used to encrypt scripts in Rivest-Shamir-Adleman (RSA) encryption format. The execution of the code to create the agent is given in RSA format, which has been captured by the Module Logging reports of Log360 (Fig. 6).
Figure 6. Module Logging reports capture encrypted code.
Once we have obtained information about the users, groups, and other AD objects and their access, we will choose a target user who has the privileges we need or who can be the right next step to obtaining them.
We must now obtain that user's credentials. We can do this using Mimikatz under the credentials module. The scripts used for this are as follows:
Mimikatz modules are executed in the form of obfuscated code. Log360 captures the obfuscated code in the script data of its Script Block Logging reports. Often, Mimikatz uses the same commandlets. Analysts can recognize these and create custom alerts to get notified when they are executed.
For example, Mimikatz often uses scripts that include the $TypeBuilder set of commands. Figure 7 shows this being captured by the Script Block Logging reports in a SIEM solution.
Figure 7. Log360 captures the obfuscated code used by Mimikatz to extract the passwords.
Log360's Module Logging reports capture which application is executing these commands. In this case, it is the agent deployed by the attacker's machine on the target server. Figure 8 displays this.
Figure 8. Log360 captures the host application (agent) that executed the code.
Apart from offering the reports mentioned above, a SIEM solution can also help you:
A comprehensive SIEM solution like Log360 comes equipped with MITRE ATT&CK® reports (Fig. 9) that help track specific techniques and sub-techniques, including malicious PowerShell scripts as well as commands—both successful and failed executions. An advantage of using PowerShell Empire for pen testing is it lists all the ATT&CK techniques associated with a module before running it. Defense teams can use this to set up alerts and track specific PowerShell activities to which they are most susceptible.
Figure 9. ATT&CK reports in Log360.
PowerShell attacks are being increasingly used since most organizations do not log PowerShell activity. These organizations find the number of logs generated to be too high to manage and analyze. Investing in the right security tool can help you track, monitor, analyze, and archive PowerShell logs to easily detect suspicious executions that could lead to a cyberattack.
To learn more about Log360, our comprehensive SIEM solution with built-in AD and PowerShell auditing capabilities, do check out our free, 30-day trial or reach out to our product experts for a personalized demo.
You will receive regular updates on the latest news on cybersecurity.
© 2021 Zoho Corporation Pvt. Ltd. All rights reserved.