Installation
Download Invoke-LiveResponse and extract into Powershell profile.
Import-Module Invoke-LiveResponse
Get-Help Invoke-LiveResponse -detailed
On a Powershell 4+ collector machine, assuming you trust me, run the following proxy aware Powershell commands to download then install. The install places Invoke-LiveResponse into the running users profile.
$url="https://raw.githubusercontent.com/mgreen27/Invoke-LiveResponse/master/Content/Ancillaries/Get-Forensicating.ps1";[Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls";$WebClient=(New-Object System.Net.WebClient);$WebClient.Proxy=[System.Net.WebRequest]::GetSystemWebProxy();$WebClient.Proxy.Credentials=[System.Net.CredentialCache]::DefaultNetworkCredentials;Invoke-Expression $WebClient.DownloadString($url)
For remote use over WinRM, I recommend setting WinRM up via Group policy for simplified deployment across all Powershell versions. Setting up WinRM is outside the scope of this wiki however, please see the resource section for some good resources and a detailed lab walkthrough.
For a quick and dirty emergency install, Invoke-StartWinRM will turn on PSRemoting and configure appropriate credential configurations on Powershell 3 machines and above. Similarly, Invoke-StopWinRM may also be used to revert changes. Keep in mind, this will initiate some forensic footprint.
To minimise credential risk, CredSSP (and any basic) authentication over WinRM should always be disabled. This results in a network logon type 3 and protected credentials of the account running WinRM. This has been implmented in Invoke-LiveResponse however the drawbacks here means our SMB share for copy use cases requires unauthenticated write access or credentials passed into the script at runtime. As share credentials will be pushed to the endpoint, best practice would be to create temporary account/access to our share for the duration of our redirected file acquisition.
Powershell has a configuration option to restrict the amount of memory available in a shell. This value is called MaxMemoryPerShellMB, and depending on Powershell version may be set in both Shell and Plugin WSMan configurations. In Powershell 2.0, the default is 150MB, which will likely need to be increased or turned off for custom Live Response mode content over WinRM. As later versions of Powershell have been released, the default values have risen appropriately for most WinRM use, for example in 3.0 MaxMemoryPerShellMB = 1024, multiples above required memory - even for badly written custom content.
To view this setting locally
Get-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB
Get-Item WSMan:\localhost\Plugin\Microsoft.PowerShell\Quotas\MaxMemoryPerShellMB
To edit this setting locally
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB -Value 1024 -Force
Set-Item WSMan:\localhost\Plugin\Microsoft.PowerShell\Quotas\MaxMemoryPerShellMB -Value 1024 -Force
The simplest approach is to deploy WinRM via Group policy and configure these settings via GPO or logon script. For manual intervention, Invoke-MaxMemory will connect via WinRM and turn off this setting (set to 0). Powershell 2.0 has restrictions in remotely changing WinRM settings, although not ideal from a forensic standpoint, the “–Legacy” switch uses scheduled tasks to force a local configuration change.
