What's in Your Clipboard? Pillaging and Protecting the Clipboard

Published: 2020-09-11
Last Updated: 2020-09-11 12:39:02 UTC
by Rob VandenBrink (Version: 1)
9 comment(s)

Recently I happened to notice that the Cisco AnyConnect VPN client clears the clipboard if you paste a password into it.  (Note - if you know and can type any of your passwords in 2020, you should at least partially examine your life choices).  Several password managers also do this "right thing" - retaining passwords in the clipboard is a great way for folks to accidentally paste that information into the worst possible place after login (like say into something that'll post that info into clear text log files), or in the worst case allows it to get stolen post-login.

This got me to thinking, why doesn't putty do this after password entry, or the Windows RDP client for that matter?  Or a myriad of traditional and web apps that take userid/password input for access?

From an attacker's point of view, the clipboard really is simple to collect in Powershell:

> $clp = Get-Clipboard -Format text



This can be a valuable piece of information to collect in a penetration test, if you happen to have code execution in the user context.  If you catch the right person, you are likely to collect the password for some other system - a router, switch or firewall, a hypervisor, or even a mainframe.  Or even better, collecting credentials from "standalone" business systems like accounting or shop floor control systems are also pure gold.  Pivoting from your existing access to other systems and privilege levels is the whole point of any internal security assessment / penetration test.

You can of course also collect any graphics or files that are in the clipboard, which can sometimes be just as useful.

If you don't have code execution, you can just ask the Chrome or Opera browser to give up your target's clipboard by tricking your target person to browse to a specific website - "ClipboardMe"  is a decent tool to do this.  The main down side is that this tool involves a third party site to collect this information.  For some extra fun, this tool can also be used to modify your victim's clipboard.  This this tool also records the IP addresses of your victim(s) - just keep in mind that if those folks are all in the same organization (and on premise), they'll likely all have the same public IP address.  In the screenshot below you see me testing this tool using 3 different browser versions:

While you can technically also collect a remote station's clipboard using any of the various remote admin tools, in most cases this opens a new session.  Since clipboards are tied to sessions, these methods will either collect null values or the clipboard of the station doing the remoting, so in most cases this is a dead end.  If you can however get a scheduled task onto your target's machine, for instance, that can be made to run against your target user.  If you can get them to run this short powershell script, a scheduled task will grab their clipboard every 10 minutes (or whatever interval you specify).  It does "flash" on the screen, when it runs though - unfortunately if you run it in the background it's another session so doesn't work.  (If anyone has a decent workaround for this, please drop it in our comment section?)

$argument = "-windowstyle hidden -noninteractive -command `"whoami | out-file -append c:\xfer\example.txt ; get-clipboard | out-file -append c:\xfer\example.txt `""

$action = New-ScheduledTaskAction -Execute 'PowerShell.exe' -Argument $argument 

$u = whoami ; $principal = New-ScheduledTaskPrincipal -UserID $u 

$trigger = New-ScheduledTaskTrigger -Once -At 7am -RepetitionDuration  (New-TimeSpan -Days 1)  -RepetitionInterval  (New-TimeSpan -Minutes 10) 

$settings = New-ScheduledTaskSettingsSet -Hidden -AsJob -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries 

$task = New-ScheduledTask -Action $action -Principal $principal -Trigger $trigger 

Register-ScheduledTask "StealClip" -InputObject $task -Force

The other caveat of course is that to do this you have to have that user (and likely the domain) compromised.  Remember that this method is all about pivoting to that next (non AD) platform.

From a defensive point of view, the clipboard is also pretty easy to clear, both in PowerShell and otherwise:

From the basic command line you can use the "clip" command to clear the clipboard - any of these commands will work:

break | clip

type nul | clip

echo. > nul | clip

(echo anything to nul will work)

From Powershell it's not even convoluted, it's documented:
First, you can still use nul and the clipboard:

echo $null | clip.exe

Yes, this works in powershell for Linux as well, as long as xclip is in the path you can use

echo $null | xclip

In Windows you can use .NET - you'll see a noticeable pause when this one executes:

Add-type -AssemblyName System.Windows.Forms

Or, you can just use the native Powershell command - by far the preferred approach these days:

Set-Clipboard $null

This last one also works in Powershell for Linux, again, you need xclip in your path (normally it is)

As expected, this one is documented at https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/set-clipboard?view=powershell-7

So if it's that easy to clear, why don't common apps that accept passwords just do this?  

While it's not well documented, Matt Graeber (Mattifestation) outlines various ETW (Event Tracer for Windows) providers for the clipboard here: https://gist.github.com/mattifestation/04e8299d8bc97ef825affe733310f7bd

Notably, a vendor could monitor for this one during password input, and clear the clipboard if a paste is detected (in other words, clear the clipboard if a password is pasted in, just after it's used.  I'm assuming that this is how most password managers get the job done:

ETW Provider name: Microsoft.Windows.OLE.Clipboard
Provider guid: 3e0e3a92-b00b-4456-9dee-f40aba77f00e

Unfortunately, there isn't much documentation for this provider past Matt's "look what I found" listing.  So do I have code for this?  Nope, sorry I do not.  However, if you've got any code that uses this provider, please post a link in our comment form, the more we "pile on" to this concept, the fewer excuses our various vendors have not to be responsibly clearing passwords out of clipboards (after they are used of course).

So stay tuned, if someone posts an ETW method to our comments everyone wins.  If not, I'll keep poking at this, you might see a related story in the next couple of weeks.

In the meantime, if you've noticed any other apps that clear the clipboard (or don't clear the clipboard) at the right time, please also let us know in our comment form - this would be a good "list of things to fix"

Rob VandenBrink
rob <at> coherentsecurity.com

9 comment(s)


It's really cool what you worked out wrt accessing the clipboard, Rob! Thanks for your elaborate blogpost, it's explaining everything very well, and nicely documented!

I have nothing to add to it, only one small remark about "lifechoices" :-)

your attack method won't catch any of the people who chose to live their digital life along the Roger A. Grimes motto "Password size does matter" [more than complexity matters] - see https://www.infoworld.com/article/2655121/password-size-does-matter.html (from 2006 AD, still valid nevertheless)

So if one chooses to use a VerylongPasswordwhichiseasytoremember instead of eg. 9reGebxc$c#w, there is no need to copy-paste the password because it is - as stated! - easy to remember, AND is several orders of magnitude more difficult to bruteforce than the 12-character complex password you're obliged to copy-paste from your password manager to the password field.

Unless of course abovementioned people choose to copy-paste their perfectly rememberable password. Now THAT'S a poor lifestyle choice! ;-)

High Regards
The kicker with easy-to-remember (and hence type-able) passwords is that folks generally have room in their brain for one or two of those, so they get re-used, at least that's my situation. So remembering lengthy passwords tends to open you up to a whole other set of attacks - for instance your local newspaper gets compromised, and since your paypal account uses that same password (or the same password with "paypal" at the end), it's now also compromised.

From a personal defense point of view, really a password manager and MFA (for services that offer MFA) is your best bet these days.

Anyway, this approach is more useful against those difficult-ish passwords that tend to end up in clipboards, either copied from text files or not-so-savvy password managers. If you can type it then (as they say in pentesting) "there's always another way"
If you have clipboard history turned on (Settings > System > Clipboard > Clipboard history) then these methods of "clearing" the clipboard by overwriting it with an empty entry simply add that empty entry to the top of the clipboard and make it the active entry.

This would protect from things that read the active entry, but any functions which can access the entire clipboard history are still going to get the S00p3rS3cr3tPassw0rd, which is now the second entry in the history.
Good point - with clipboard history turned on all the "replace with null" (or replace with anything for that matter) won't work as "traditionally expected". That's off by default, which is normally how I find it in pentests, but I'll test the PowerShell approach to both clearing and "stealing" with clipboard history enabled, stay tuned.

The only way I've found to get around the PowerShell window flashing is to use a small VBScript file to run the PowerShell. I've used this technique several times for scheduled tasks. Here is the command I use:

C:\Windows\System32\wscript.exe -nologo LaunchPS.vbs sample.ps1

Here is the VBScript file LaunchPS.vbs.
Option Explicit
On Error Resume Next

If WScript.Arguments.Count > 0 Then

Dim objWshShell
Set objWshShell = WScript.CreateObject("WScript.Shell")

Dim strPS
Dim strCommand
Dim intResult

strPS = objWshShell.ExpandEnvironmentStrings("%WinDir%") & "\System32\WindowsPowerShell\v1.0\powershell.exe"
strCommand = strPS & " -Nologo -Noprofile -Noninteractive -File " & Chr(34) & WScript.Arguments(0) & Chr(34)

intResult = objWshShell.Run(strCommand, 0, False)

Set objWshShell = Nothing
End If
Don't forget macOS. It has shell/Terminal based utilities: pbcopy, pbpaste.

I did a quick test of password interaction and sure enough pbcopy pulls out the last text item that was copied!

Good Article.
I like this article! While some applications may implement clipboard clearing it would sure be nice to see it in the OS such that the clipboard was more of a temporary thing. In Windows you could easily set a scheduled task to clear the clipboard on unlock with the mentioned commands (it wont work when the system is locked). Or, with a little more work you could probably monitor the clipboard for changes and clear after X amount of time. But I bet the malware does the same and pulls the data out immediately so you are just protecting from in person snooping.
If you have clipboard history turned on (Settings > System > Clipboard > Clipboard history) then these methods of "clearing" the clipboard by overwriting it with an empty entry simply add that empty entry to the top of the clipboard and make it the active entry.

Diary Archives