Americas

  • United States

Asia

Oceania

sbradley
Contributing Writer

How to install PowerShell 5 on Windows 7

How-To
Feb 27, 20194 mins
SecuritySmall and Medium BusinessWindows

Have older Windows systems on your network? You can give them PowerShell 5's event logging capabilities even if they run Windows 7.

11 event logging
Credit: Getty Images

You might think that something as basic as PowerShell, Microsoft’s a task automation and configuration management framework, shouldn’t need to be updated. After all, it comes with the operating system, right? However, Windows 7 has hardly any ability to log PowerShell, whereas Windows 10’s version of PowerShell has much more robust logging.

What if you aren’t quite ready to roll out Windows 10 network-wide? All is not lost. You can update to PowerShell 5 on Windows 7, and in fact it’s recommended to do so to add suspicious-script block-logging that is not in the PowerShell shipped on Windows 7.

To install PowerShell 5 on Windows 7, there are a few mandatory prerequisites:

  1. Install Windows Management Framework 4.0.
  2. Install .NET 4.5 on Windows 7.
  3. With the first two steps done, you can install Windows Management Framework 5.1. Once this is in place, you can use the abilities of PowerShell 5 on Windows 7 and turn on the enhanced logging that 5 provides.

Next enable logging through Group Policy by configuring it as follows:

Go to Administrative Templates, then Windows Components and then Windows PowerShell. There you will make a few settings.

bradley powershell 1 Microsoft

Add PowerShell Script Block loggin

The first, “Turn on Module logging”, records portions of scripts and de-obfuscated code, and will log events to event ID 4103 in the Windows PowerShell log. You’ll want to determine what modules you want to track. To obtain a list of modules, use the Get-Module -ListAvailable PowerShell cmdlet and then add the modules you want to audit. Alternatively, you can enter * to log all modules. Use the wild card to initially set up logging.

The next logging item to set up is “Turn on PowerShell Script Block logging”. This records when blocks of code executed, thus capturing the code executed by an attacker including scripts and commands. It’s not recommended to enable the start and stop of script blocks, as this adds a large amount of logging events. Merely adding script block logging means that you can capture quite a bit of detail.

If you are concerned about attacks and password grabbing, PowerShell Transcription logging can be very effective in identifying scripts that are run by attackers.  It provides a record of the PowerShell session, plus input and output, exactly as it appears in the session. This can capturing PowerShell commands of lateral movements.

Finally make sure your PowerShell event log is increased to 1 gigabyte (or as large as your environment can have), and consider a logging solution that will move these files off machines for later review if you have a sensitive and secure environment.

Once you have logging set up, you can then look in the PowerShell event log for events. For example, you can see even the benign PowerShell script below that merely enumerates running services being done after the fact in the event logs.

bradley powershell 2 Microsoft

Sample PowerShell command

As you can see below, you can see the PowerShell script results in the audit log and review them after the fact.

bradley powershell 3 Microsoft

Evidence of a PowerShell command being executed

You can now review the PowerShell logs to see what prior activity occurred on the system. This can help identify malicious PowerShell activities. As noted in a Fireeye blog, malicious PowerShell scripts can be further obfuscated with base64 encoding. Attackers will often ensure that such scripts run silently. Even if you cannot examine the full details of the PowerShell script, you can look for these obfuscation techniques and compare the events tracked with the scripts you use in your network.

Ensuring that you have logging enabled before an event occurs enables you to investigate and determine what may have occurred on your systems.

sbradley
Contributing Writer

Susan Bradley has been patching since before the Code Red/Nimda days and remembers exactly where she was when SQL slammer hit (trying to buy something on eBay and wondering why the Internet was so slow). She writes the Patch Watch column for Askwoody.com, is a moderator on the PatchManagement.org listserve, and writes a column of Windows security tips for CSOonline.com. In real life, she’s the IT wrangler at her firm, Tamiyasu, Smith, Horn and Braun, where she manages a fleet of Windows servers, Microsoft 365 deployments, Azure instances, desktops, a few Macs, several iPads, a few Surface devices, several iPhones and tries to keep patches up to date on all of them. In addition, she provides forensic computer investigations for the litigation consulting arm of the firm. She blogs at https://www.askwoody.com/tag/patch-lady-posts/ and is on twitter at @sbsdiva. She lurks on Twitter and Facebook, so if you are on Facebook with her, she really did read what you posted. She has a SANS/GSEC certification in security and prefers Heavy Duty Reynolds wrap for her tinfoil hat.

More from this author