-
Notifications
You must be signed in to change notification settings - Fork 30
PSReadLine Evasion #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hello! Thanks for the comment, and sorry for the late response, I realized that I hadn't enabled notifications for this repo. I wasn't aware of such a detection. Is there a good online resource (article, blog post, thread, forum) that mentions or discusses this in more detail? |
Hello ! I haven't come across resources mentioned this fact (maybe on X somewhere ?), but from personal OpSec experience with some past engagement. Not tested on all EDRs in the market, but currently aware that BitDefender is snooping on ConsoleHost_history.txt to search for keyword such as Invoke-* ... :) My previous script is a bit agressive though as I was wiping all the PsReadLine options, you could just disable the history handler this way : Cheers! |
OK, thanks for the update. In that case, it might be worth digging a little bit deeper in that direction. I'll see what I can do. Do you know if this kind of detection is included in the free version of BitDefender? Second, are you aware of any specific keyword that it detects, so that I can easily test? |
Not sure if it is included in free version, but I'm sure other EDRs are having similar tactics to keep an eye on the command you typed. For testing, I suggest, disable AMSI/ETWI/scriptlogging, then use the classic noisy keywords : Invoke-Mimikatz, Invoke-winPEAS.. |
I created a new Windows VM, installed Bitdefender EDR, started PowerChell, and used known commands such as I repeated the same steps with So I can't see an evident sign that the console history is leveraged for additional detection. |
Weird, might depend on the policy enforced ? I've tried for TrendMicro EDR as well, this is not triggering blocking action, though in the dashboard it gathers all the previous command from the console history. Might be worth to investigate others one if you have time. From my perspective, this is similar to some kind of "command logging" and can be used to monitor for malicious actions. So feel free to implement or close the issue as you want. Though, I'm keeping this trick under the hood to avoid from stupid IOCs ;) |
I investigated this a bit further. As it turns out, the type PS C:\Users\Admin> [Microsoft.PowerShell.PSConsoleReadLine].Assembly
GAC Version Location
--- ------- --------
False v4.0.30319 C:\Program Files\WindowsPowerShell\Modules\PSReadLine\2.0.0\Microsoft.PowerShell.PSReadLine.dll Contrary to PowerShell, though, I don't load default built-in modules in PowerChell. Therefore the One of the side effects is that there is actually no console history being logged. So, I have nothing to patch here. I checked my console history file while using PowerChell, and indeed, nothing is logged. No wonder why I was unable to reproduce the behavior... Nonetheless, the issue could arise if the module By the way, about the "patch" itself, You can do something like this. It's less "invasive" and way easier to implement in C/C++ than setting the console history handler. # Method 1: Simple use
Set-PSReadLineOption -HistorySaveStyle SaveNothing
# Method 2: Same as 1 but "manual"
$options = [Microsoft.PowerShell.PSConsoleReadLine]::GetOptions()
$options.HistorySaveStyle = [Microsoft.PowerShell.HistorySaveStyle]::SaveNothing
# Method 3: Reflection
$ConsoleReadLineOptions = [Microsoft.PowerShell.PSConsoleReadLine]::GetOptions()
$ConsoleReadLineOptionsType = $ConsoleReadLineOptions.GetType()
$HistorySaveStyleProperty = $ConsoleReadLineOptionsType.GetProperty("HistorySaveStyle")
$HistorySaveStyleProperty.SetValue($ConsoleReadLineOptions, 2) Still need to work a bit more on this. I need to find out if there is more to importing PowerShell modules than just loading an assembly. But I wanted to share this bit of (interesting?) information. |
Conclusion... There is indeed more to importing a PowerShell module than just loading its assembly. The work required to do that goes beyond the point of this project, whilst it can be achieved with just a few lines of PowerShell in the console. According to the documentation, the point of the To load the module, and prevent commands from being logged to the history file, one could do the following. Import-Module PSReadLine
Set-PSReadLineOption -HistorySaveStyle SaveNothing |
Hello Clément,
Super article as always 👍
Lors d'un engagement redteam récent, j'ai remarqué que les EDR(s) étaient en monitoring aussi sur le module PSReadLine notamment sur le history handler/file output. (Pas cool de se faire toper après bypass AMSI/ETW et se faire avoir juste à cause de l'historique de commande lol).
Je suggère l'ajout suivant :
Before :

After :
The text was updated successfully, but these errors were encountered: