REVIEWED by Sophos
Hello Threat Hunters!
I mentioned in this post: https://community.sophos.com/products/intercept/early-access-program/f/live-discover-response-queries/120201/live-response---command-audit/ how you could audit the history of PowerShell commands as a way of auditing a Live Response session.
You could also use the principal of this technique https://attack.mitre.org/techniques/T1146/ for threat hunting PowerShell command history.
Thinking as a bad actor might with a PowerShell command line, either:
1. They don't know or care that my commands are logged. This helps us out with forensics.
2. They do know of this and will try and cover their tracks in same way as purging event logs.
Given scenario 2 and not wanting to record the session, I can think of a few ways this could play out...
Initially use Get-PSReadLineOption to understand the current logging location (HistorySavePath), when and if the file is written to (HistorySaveStyle) and maybe the history count of items (MaximumHistoryCount).
Knowing the configuration, I might then do one or more of the following:
Backup the existing file with a view to restore it after. e.g.
rename-item -path $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt -newname ConsoleHost_history_before.txt
Using a PowerShell command line to do this seems a poor choice as the last command to rename the file would be recorded to the file. You would have to manually remove this line from the file, if you were to restore the file. I would imagine someone would use anything other than PowerShell for this, e.g. Explorer.exe, cmd.exe, etc...
Delete the referenced file from the PowerShell prompt at the end of a session:
remove-item -force -path $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
Would anyone be surprised to have lost their history of commands if it was simply deleted? Unlikely but what would perhaps be more interesting and a possible IoC would be the creation time of the file had this have happened as presumably it would be created again as and when it was used legitimately. You could also consider that the file not being present in any profile might also be odd but this depends on the user and software installed.
A bad actor might run a command to prevent history being recorded if it was already enabled (which is the default):
Set-PSReadlineOption -HistorySaveStyle SaveNothing
After a session re-enable it:
Set-PSReadlineOption -HistorySaveStyle SaveIncrementally
Again the act of changing the style of event history from a PS prompt would be logged. These commands in the history would be a red flag.
So to help us out, I would think IoCs surround this would be:
- Any file access to this file from a process that isn't PowerShell.exe.
- PowerShell_ise.exe doesn't appear to use this file but (Get-PSReadlineOption).HistorySavePath shows: C:\Users\[user]\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\Windows PowerShell ISE Host_history.txt
- A recent creation time - This could indicate the file has been deleted by a bad actor and then re-created after.
- A process being created with the command line:
-HistorySaveStyle SaveNothing - The command Get-PSReadLineOption being issued. It seems quite unlikely the average user would care out this information.
The above could be used from Live Query before manual investigation of the file.
select CAST( datetime(sfj.time,'unixepoch') AS TEXT) DATE_TIME,
sfj.subject,
CAST( datetime(sfj.creationtime,'unixepoch') AS TEXT) CREATION_DATE_TIME,
sfj.pathname,
spj.cmdline,
spj.sid
from sophos_file_journal sfj join sophos_process_journal spj on spj.sophosPID = sfj.sophosPID
where sfj.pathname like '%ConsoleHost_history.txt' and spj.cmdline not like '%powershell%';
In the above query we would cover, the file being deleted by Explorer.exe. The file being opened by a text editor, maybe a bad actor is searching the file for passwords, recent commands to glean some information.
Something to think about.
Regards,
Jak
