SEC595: Applied Data Science and AI/Machine Learning for Cybersecurity Professionals

Experience SANS training through course previews.
Learn MoreLet us help.
Contact usBecome a member for instant access to our free resources.
Sign UpWe're here to help.
Contact UsLet's take a look at a sneaky attack to use PowerShell maliciously while evading detection (and some ways to detect it).
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 [code]clip.exe[/code] to copy malicious PowerShell code into the clipboard on the command line, then executing the code using the .NET [code]System.Windows.Clipboard[/code] static method [code]GetText.Invoke()[/code].
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>
When the attacker wants to run the malware, they can use [code]Get-Clipboard[/code] (for Windows 7 and later; earlier versions of PowerShell need to use [code][System.Windows.Clipboard]::GetText.Invoke()[/code]) and [code]Invoke-Expression[/code]:
PS C:\Users\Sec504> Invoke-Expression (Get-Clipboard)[0]
Hello from the clipboard
Organizations relying on PowerShell logging may miss this as an attack, since the logged PowerShell command will only be [code]Invoke-Expression (Get-Clipboard)[0][/code]. However, there are some additional opportunities for detection.
When AppLocker is turned on, Windows will log all commands executed to the [code]Microsoft-Windows-AppLocker/EXE and DLL[/code] 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 [code]clip.exe[/code] 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 [code]clip.exe[/code] 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 [code]Get-Clipboard[/code] and [code]Invoke-Expression[/code] as threat candidates as well. (Don't forget to look for aliases too: [code]gcb[/code] and [code]iex[/code].) 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.
-Joshua Wright
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.
As Senior Technical Director at Counter Hack and SANS Faculty Fellow, Joshua has advanced cybersecurity through ethical penetration testing, uncovering critical vulnerabilities across Fortune 500 companies and national infrastructure providers.
Read more about Joshua Wright