Monitoring with PowerShell: Monitoring Powershell Protect

So let’s start with the great news first; PowerShell protect is now open-source and free to use! PowerShell Protect is a AMSI Provider for PowerShell, now technically this sounds rather complex but it pretty much means that PowerShell Protect is able to secure the PowerShell host in the same way your antivirus does.

The great thing about PowerShell Protect is that it allows you to monitor exactly which commands have been executed, but also catch them and block them for usage if you don’t trust it.

This means you can block so called LoLBas and LolBin via Powershell with relative ease. In this blog I’ll show you to do deploy PowerShell Protect, and how to monitor activity generated by it. So let’s start getting our clients more secure and less prone to persistence attacks.

Installing PowerShell Protect

Installing PowerShell Protect is done from the PowerShell gallery, the moment you install the module nothing happens yet, and you’ll need to add rules and install the actual AMSI provider. We’re using the default rules, but are also adding some rules for logging entries we want to see, as an example I’ll add logging for invoke-restmethod

This means we’ll block the following list;

  • Block AMSI Bypass Protection
  • Block Module and Script Block Logging Bypass Protection
  • Block Assembly Load from Memory
  • Block Disabling Defender
  • Block Use of the System.Reflection.Emit Namespace
  • Block PowerSploit(Invoke-mimikatz and derivatives.)
  • Block the Marshal Class
  • Block WMI Event Subscription persistance
  • Block Bloodhound
  • Block Kerberoasting
  • Block invoke-expression

All of these rules heighten our protection against bad actors, while still allowing enough flexibility to actually use PowerShell for our day to day operations with our RMM system, so let’s deploy shall we?

write-host "Getting the PowerShellProtect Module" -ForegroundColor Green
If (Get-Module -ListAvailable -Name "PowerShellProtect") { 
    Import-module PowerShellProtect
Else { 
    Install-Module PowerShellProtect -Force
    Import-Module PowerShellProtect
Write-Host "Applying PowerShellProtect default settings" -ForegroundColor Green

$Condition = New-PSPCondition -Property "command" -Contains -Value "Invoke-RestMethod"
$WriteToFile = New-PSPAction -File -Path "C:\Programdata\PowerShellProtect\Log.txt" -Format "{timestamp},{rule},{ApplicationName},{UserName},{ContentPath},{Script}" -Name 'AdminFile'
$Rule = New-PSPRule -Name "LogToFile" -Action $WriteToFile -Condition $Condition

$Config = New-PSPConfiguration -Rule $Rule -Action $WriteToFile

Set-PSPConfiguration -Configuration $Config -FileSystem 

So now all invoke-restmethod requests are logged to C:\Programdata\PowershellProtect\Log.txt, and all those things up there get blocked by PowerShell too! Let’s move on to a bit of monitoring:

Monitoring the PowerShell Protect log

Because we’re outputting the log in a CSV form, it becomes easy to monitor in PowerShell, we load the file as a CSV and filter only events that happened in the last 5 minutes.

$AllEvents = import-csv 'C:\Programdata\PowerShellProtect\Log.txt' -Header timestamp, rule, ApplicationName, UserName, ContentPath  -Delimiter ',' | ForEach-Object { $_.Timestamp = [datetime]::ParseExact($_.timestamp, "dd/MM/yyyy HH:mm:ss", $null); $_ }

$FilteredEvents = $AllEvents | Where-Object { $_.timestamp -gt (Get-Date).ToUniversalTime().AddMinutes(-5) }

if ($FilteredEvents) {
    write-host "Unhealthy - Events found. "
} else {
    Write-Host "Healty - No events found."

So this outputs if there are no events found, or when there are events it’ll output exactly what was found, the time and date, which executable ran the script and to top it off which user executed the command.

And that’s it! there’s a lot more to PowerShell protect and I’ll probably make a second blog about it soon, right after I assist the project with some changes 😉

As always, Happy PowerShelling!

1 Comment

  1. Nicholas Jenkins January 28, 2021 at 4:20 pm

    Great Stuff…please forgive my ignorance…
    Does PSProtect account for compressed + encrypted here document type code?
    As in Does PSProtect:
    A) focus on what powershell library calls occur, or
    B) decompress/decrypt/expand all embedded objects before analyzing (so that it’s looking at full text before searching for specific terms)?
    Are there technical limits we should be aware of? e.g. command or object aliasing so that command lines don’t trigger alerts?
    As a Security Defender, I’m trying to understand how easy/likely it will be for threat actors to adjust their powershell code to avoid detection?

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.