The amazing Internet Storm Center handler Xavier Mertens wrote a recent article titled Malicious Code Passed to PowerShell via the Clipboard following analysis of the Boxter malware family. Xavier shows an example where the malware uses the CMD utility clip.exe to copy malicious PowerShell code into the clipboard on the command line, then executing the code using the .NET System.Windows.Clipboard static method GetText.Invoke().
What is interesting about this technique is that there is no long, Base64-encoded PowerShell command line to spot as an Indicator of Compromise (IoC). Instead, the attacker uses CMD to produce the malicious code and copy it into the clipboard:
C:\Users\Sec504>echo Write-Host "Hello from the clipboard" | clip.exe C:\Users\Sec504>
Since CMD shells are less likely to be logged than PowerShell sessions, this creates an opportunity for an attacker to evade threat detection controls on the endpoint.
When the attacker wants to run the malware, they can use Get-Clipboard (for Windows 7 and later; earlier versions of PowerShell need to use [System.Windows.Clipboard]::GetText.Invoke()) and Invoke-Expression:
PS C:\Users\Sec504> Invoke-Expression (Get-Clipboard) Hello from the clipboard
I had to obtain the first element of the Get-Clipboard array response for use with Invoke-Expression using the  notation
Organizations relying on PowerShell logging may miss this as an attack, since the logged PowerShell command will only be Invoke-Expression (Get-Clipboard). However, there are some additional opportunities for detection.
When AppLocker is turned on, Windows will log all commands executed to the Microsoft-Windows-AppLocker/EXE and DLL event log. Commands that are allowed to execute use event ID 8002:
PS C:\WINDOWS\system32> Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL' | Select-Object -Property Id, Message Id Message -- ------- 8002 %SYSTEM32%\CLIP.EXE was allowed to run. 8002 %SYSTEM32%\CMD.EXE was allowed to run.
Here the event log reveals that clip.exe was allowed to run. This is a valid Windows tool, so it does not necessarily indicate malicious intent. However, can use it as a potential indicator, particularly if the system does not run clip.exe on a regular basis.
The Windows Diagnostic Policy Service records all commands run on the Windows system for a 30-day logging period. We can use Mark Baggett's SRUM-Dump tool to convert the data into an Excel spreadsheet, or Eric Zimmerman's Srum tool to produce CSV files that can be examined in Timeline Explorer.
While conventional threat hunting in PowerShell logs might not pick up this threat, we can search for instances of Get-Clipboard and Invoke-Expression as threat candidates as well. (Don't forget to look for aliases too: gcb and iex.) This may lead to false-positives though, since these cmdlets are not necessarily malicious, but may be helpful in evaluating a possible incident.
This is a technique I'll utilize in my next red team engagement, for sure.
Return to Getting Started With PowerShell
Joshua Wright is the author of SANS SEC504: Hacker Tools, Techniques, and Incident Handling, a faculty fellow for the SANS Institute, and a senior technical director at Counter Hack.