Attack Techniques: Trojaned Clipboard

Today in “Attack techniques so stupid, they can’t possibly succeed… except they do!” — the trojan clipboard technique. In this technique, the attacking website convinces the victim to paste something the site has silently copied to the user’s clipboard into a powerful and trusted context.

A walkthrough of this attack can be found in the ThreatDown Blog, but simple screenshots give you the gist:

A similar one:

Now, in the modern Windows Terminal, trying to paste a string with a CRLF in it will show a warning prompt:

… but that protection still relies upon the user having some concept that they might be under attack and not hitting Enter.

Update: Microsoft’s Threat Intelligence team has a lengthy writeup of techniques we’ve seen in the wild.

Nothing New Under the Sun

In the current scenario, the target victim context is a native execution surface, but this is far from the first time an attack like this has been seen.

Two weeks ago, attackers were abusing the Win+R Run dialog:

Here’s a nice video explanation that walks through what the attackers do if you fall for the Win+R attack.

UPDATE: A few months later, an attack coupled full-screen abuse with a fake WindowsUpdate reboot screen:

Thirteen years ago, Socially-Engineered XSS Attacks were all the rage, where bad guys would use the Address Bar / Omnibox get access to your Facebook account and worm the attack through all of your friends and contacts:

That attack led browsers to start dropping the javascript: prefix when pasting into the address bar. If a user really wants to run JavaScript, they have to manually type the scheme prefix themselves.

Similarly, pasting into DevTools was a recognized attack vector, so before browsers introduced built-in protections, websites would take it upon themselves to console.log a warning message like this one on WordPress.com:

Nowadays, Chromium blocks pasting by default:

…as does Firefox:

Other Execution Surfaces

The Windows Run dialog is a convenient target because it’s just a Win+R hotkey away. But it’s not the only such surface; for example, the location bar in Windows Common File dialogs and File Explorer windows are also execution surfaces.

An real-world attack campaign is now using the Common File Dialog vector:

Note: Enterprises or administrators who are concerned about their users unsafely running commands from Windows Explorer execution surfaces like the Run dialog or the Location bar may set a policy to disallow such actions.

You can do so by using RegEdit.exe to create a REG_DWORD named NoRun with a value of 1 in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

…or you can use the Group Policy editor to configure User Configuration > Administrative Templates > Start Menu and Taskbar > Remove Run menu from Start Menu

Beyond Explorer, Command Prompts, Terminals, and PowerShell IDE windows, are obvious targets, and several Windows utilities like Task Manager also have command-runners:

So, protecting just the Run dialog might not be enough.

Alas, We Can’t Patch the Human

All of these attacks make the end-user an active participant in their own victimization.

What are defenders to do about all of this?

Block copy from the browser? Warn on every paste into a sensitive context? Introducing friction would be annoying — 99.99% of the time, nothing bad is happening, and the user is pasting trustworthy or harmless content.

Mark of the Web – Clipboard Edition?

If you squint at it, this problem is somewhat like the problem of Windows Security Zones — Windows wants to apply additional scrutiny to files from the Internet, but as soon as you download a file, that file is no longer “on the Internet” — it’s on your disk.

Way back in 2003, Windows invented the “Mark-of-the-Web” which marks a file as having originated from the Internet, storing information about its origin in an NTFS Alternate Data Stream named Zone.Identifier:

While the Windows clipboard does not today have the exact equivalent, several analogous features do exist. In the Windows Vista era, a new format was added to the clipboard to reflect that the clipboard’s contents came from a Low IL page.

Starting with an Internet Explorer 9 update in 2011, an additional data format named msSourceUrl was added to the clipboard containing (in UTF-16) the source URL:

Much more recently, Chromium implemented a similar concept, originally for DLP purposes, as I understand it. In modern Chromium, when you copy text from the web, the clipboard now contains an additional data format called Chromium internal source URL that indicates from what URL the content was copied¹.

Firefox has a similar format, text/x-moz-url-priv:

An application which wishes to protect itself from potentially untrusted clipboard data can check for these data formats, and if found, call Windows’ MapURLToZone API on the URL to determine what security zone the clipped text belongs to, prompting the user if needed.

Update: For my first foray into “vibe coding“, I worked with Google Gemini to build this tiny C++ app that examines text copied from browsers. I wrote a blog post about vibe-coding with Google Gemini here.

-Eric

¹ When drag/dropping data (e.g. links or text), Chromium puts the source origin (not the full URL) in a different clipboard format, named chromium/x-renderer-taint.