Fulcrum Blog

Article: Better Hacking Through Powershell

Mar 5, 2019 | blog |

by The Fulcrum Security Team

Powershell, Microsoft’s follow-up to batch scripting, has quickly become a Windows sysadmin’s Swiss army knife. Time-consuming and esoteric tasks are now easily automatable. Microsoft, recognizing this, has pushed Powershell as the preferred method for accomplishing a variety of administrative tasks. In a nod to free and open-source software (FOSS), they have also created an open-source fork that is available on Github and usable on systems outside of the Microsoft ecosystem.[1]

Like many useful Windows features, Powershell is also of great use to attackers. It has become the go-to tool for pen testers and the like due to its ease of use, availability of existing tools, presence on nearly every Windows system, and small footprint. On February 26th, The Register published an article highlighting that IBM’s X-Force sees a little over half of attacks conducted over Powershell.[2] In our own pen testing engagements, tools such as Metasploit’s web delivery module, Empire, Inveigh, and Powersploit are often successfully utilized against clients.

Powershell itself is not new, and neither are the mitigations that we recommend. Unfortunately, script signing, a sometimes recommended mitigation option, is still not widely used and in itself cannot always prevent attacks. Instead, Fulcrum recommends that administrators take advantage of Microsoft’s Powershell logging features and ingest those logs into their SIEM of choice. Other security companies have made the exact same recommendations for years, and yet we rarely see proper Powershell monitoring in place.

There are a few reasons why Powershell monitoring is not generally seen in an enterprise environment: Powershell upgrades may be required across the environment, older versions of Windows Server require manual updates to administrative templates, and logs may take up space and license usage in a client’s SIEM. At a minimum, the installed version of Powershell must be version 5 or later for logging to be possible. For Windows Server versions 2012 or older, ADMX templates must be downloaded from Microsoft and copied to all DCs for in order for Powershell logging GPOs to be created.[3]

This may sound daunting to some sysadmins, but the benefits outweigh the up-front effort. Powershell can be logged in three different ways: script blocks, transcription, and modules. All three options provide benefits to security analysts.

  • Script block logging records code as it is executed by Powershell. This code is deobfuscated, meaning common XOR and base64 encoding tricks will be stripped away. These logs get written as Event ID 4104 in the Application Event log.
  • Transcription logs the entire Powershell session as it appears, including input and output. This is written to files along a configurable path. We recommend writing these to a write-only directory, ingesting them into a SIEM, and periodically clearing out this directory.
  • Module logging allows for logging of specific Powershell modules. An asterisk can be used as a wildcard for logging all modules. This form of logging provides details that may not be captured by the other two logging methods. These logs get written as Event ID 4103 in the Application Event log.

When properly deployed, Powershell logging provides invaluable insight into attacks as they happen as well as a forensic trail that would not otherwise be available. Given that Powershell-based attacks tend to reside in memory only, logs may be the only way to have evidence beyond a reasonable doubt of the attack. As attackers evolve, so too must defenders, and only with proper logging and monitoring can an enterprise ensure the integrity and stability of its day-to-day operations.

[1] https://github.com/PowerShell/PowerShell

[2] https://www.theregister.co.uk/2019/02/26/malware_ibm_powershell/

[3] https://security.stackexchange.com/questions/143543/missing-powershell-logging-options-in-group-policy-editor


Leave a Reply

Your email address will not be published. Required fields are marked

The Fulcrum Difference

At Fulcrum Technology Solutions, we differentiate ourselves from other technology- and business-consulting firms with a unique guarantee: when you hire Fulcrum, we commit to finish the job. Whether working under a time-and-materials contract or a cost-plus arrangement, we will not leave until we’ve delivered exactly what we said we’d do. Our word defines us, and motivates us to give you the service that you deserve!

2603 Augusta Dr. Suite 1325, Houston, TX 77057

Phone: 832-954-2800 


Share This