A nice white paper has been published by FireEye recently, entitled “Investigating PowerShell Attacks” written by Ryan Kazanciyan and Matt Hastings.
It’s actually the white paper they announced in the article they published in the two-week Security series on PowerShell Magazine last month, also entitled “Investigating PowerShell Attacks”
First, I’d like to applaud the initiative and the awesome work they did 😀
It’s a good reading that summarizes what artifacts a DFIR analyst may find during a post-mortem investigation:
- Network Traffic
If you’re not familiar with the Prefetch feature, you can read the following pages:
A side note: please bear in mind that the Prefetcher is turned off by default if the OS is running Windows 7 on a Solid State Drive (SSD).
If you’re not familiar with the “Remoting” feature of Windows PowerShell, I’d recommend reading the “Secrets of PowerShell Remoting” free ebook published by PowerShell.org and written by Don Jones, Tobias Weltner and Dave Wyatt.
While not referenced by the “Investigating PowerShell Attacks” white paper, if you want to explore how to read the data chunks in the WinRM analytic eventlog, you should read the “Diagnostics and Troubleshooting” chapter in the “Secrets of PowerShell Remoting” ebook where the authors provided and showed how to use the Construct-PSDataRemoteObject cmdlet. This cmdlet is available from the PSdiagnostics.zip file hosted on http://www.concentratedtech.com/downloads
The “Investigating PowerShell Attacks” white paper is available from
- http://www.fireeye.com/resources/pdfs/fireeye-lazanciyan-investigating-powershell-attacks.pdf (original source)
There’s one technique Ryan Kazanciyan and Matt Hastings talked about that could give additional forensics evidence:
The authors have worked with several organizations that have implemented homegrown logging solutions. One such technique entails overwriting PowerShell’s built-in Prompt function22 (again, through the addition of code in all user profiles). A custom prompt could capture any input submitted at the local PowerShell command line and save it to a file or to an event log (using the Write-EventLog cmdlet). Once again, this approach would not capture remoting activity.
That’s a great idea 🙂 Unfortunately, they didn’t show what the code may look like.
James O’Neill already shared some code on his blog about this technique http://jamesone111.wordpress.com/2012/01/28/adding-persistent-history-to-powershell/
More recently a PowerTip that explores other techniques was also published on this page http://powershell.com/cs/blogs/tips/archive/2014/08/08/logging-what-a-script-does.aspx It uses the Start-Transcript and the Set-PSDebug cmdlets
System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time
Source and more on http://technet.microsoft.com/en-us/sysinternals/dn798348
My fellow Windows PowerShell MVP Carlos Perez already wrote an awesome post about this new Sysmon tool that shows how useful it can be for DFIR post-mortem analysis http://www.darkoperator.com/blog/2014/8/8/sysinternals-sysmon