You might think that something as basic as PowerShell, Microsoft\u2019s a task automation and configuration management framework, shouldn\u2019t 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\u2019s version of PowerShell has much more robust logging.What if you aren\u2019t 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\u2019s 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:Install Windows Management Framework 4.0.Install .NET 4.5 on Windows 7.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. MicrosoftAdd PowerShell Script Block logginThe first, \u201cTurn on Module logging\u201d, records portions of scripts and de-obfuscated code, and will log events to event ID 4103 in the Windows PowerShell log. You\u2019ll 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 \u201cTurn on PowerShell Script Block logging\u201d. This records when blocks of code executed, thus capturing the code executed by an attacker including scripts and commands. It\u2019s 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. \u00a0It 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. MicrosoftSample PowerShell commandAs you can see below, you can see the PowerShell script results in the audit log and review them after the fact. MicrosoftEvidence of a PowerShell command being executedYou 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.