How to Catch PowerShell Script Attacks

Would you be able to detect an attacker running PowerShell on your network? As penetration testers, it’s rarer than you might think for our PowerShell script attacks to be detected, despite how noisy we think we’re being. This is understandable, because we’ve seen how network admins can get overwhelmed by the amount of log data generated when using best-practice logging settings, causing important log events to be ignored by even some of the most diligent organizations.

Here are three effective ways to catch an attacker using PowerShell in your Windows environment with tools you already have.

Windows Antimalware Scan Interface

Windows Antimalware Scan Interface (AMSI) is a built-in feature on Windows 10+ and Windows 2016+. AMSI was released publicly with the version of PowerShell 3.0. The purpose of AMSI is to hook into processes and perform string-based scans to detect malicious code.

The power of AMSI is the ability to use the cloud to generate signatures for inspection. Today’s malware is often obfuscated and changed slightly in order to bypass anti-virus detection. With cloud inspection, AMSI is able to quickly react to malicious strings all over the world. Although AMSI is on by default thanks to Windows Defender starting with Windows 10 and Windows Server 2016, error messages and EventIDs for AMSI alerts are often not reviewed. Although it’s important to collect as many logs as possible, there are two critical AMSI EventIDs to log and ship to a security information and event management (SIEM) system or log manager.

The Windows Defender logs are located at:

%SystemRoot%System32WinevtLogsMicrosoft-Windows-Windows Defender%4Operational.evtx

EventID 1117: The antimalware platform performed an action to protect your system from malware.

EventID 1006: The antimalware engine found malware or other potentially unwanted software.

Script Block Logging

Windows PowerShell 5.0, released in 2016, brought an important ability for network defenders. Script block logging allows all PowerShell scripts executed on a host machine to be transcribed and saved. As stated previously, malware is now obfuscated to help it bypass detection. To successfully hide the malicious actions of their code, attackers will layer obfuscation of classes and methods using a variety of techniques. As a defender capturing an obfuscated PowerShell script, it is very time consuming to determine what the script is doing. Script block logging removes the obfuscation and saves a copy of what was executed to the event log.

The Group Policy Object (GPO) to turn on script block logging can be found at:

HKLM:Administrative Templates -> Windows Components -> Windows PowerShell -> PowerShell Script Block Logging.

The script block logging event logs are located at:

%SystemRoot%System32WinevtLogsMicrosoft-Windows-PowerShell%4Operational.evtx

EventID 4104: CommandStart.

EventID 4105: CommandStop.

Script Transcription

Windows PowerShell 5.0 also launched PowerShell transcription. Transcription allows for a backup copy of the script that was run to be saved either locally or in a remote place for further inspection. Shipping the scripts to a remote write-only location gives defenders a great tool in the unfortunate event of an incident. Script transcription will help determine the scope of the impacted systems and applications.

The script transcription function can be turned on using the GPO located at:

HKLM:Administrative Templates -> Windows Components -> Windows PowerShell -> PowerShell Transcription.

By implementing AMSI, script block logging and script transcription, you are more able to detect an attacker running code or phoning home, and possibly even able to block their ability to enumerate the network. Adhering to these principles of layered defense can help you detect and deter an attacker, allowing you to remediate and recover more quickly. Should your organization require assistance fortifying or testing its defenses, don’t hesitate to reach out to Sikich’s team of cybersecurity experts.