Talk With an Expert

Month of PowerShell: Fileless Malware with Get-Clipboard

Let's take a look at a sneaky attack to use PowerShell maliciously while evading detection (and some ways to detect it).

Authored byJoshua Wright
Joshua Wright

#monthofpowershell

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.

AppLocker 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.

SRUM Analysis

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.

Excel spreadsheet titled SRUM_DUMP_OUTPUT showing output of SRUM-Dump tool; arrow pointing to entry indicating execution of clip.exe

PowerShell Logging

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.