Hunt or be Hunted: Hunting RunMRU for Credential Exposure

Start with the invariant, not the variant

ClickFix-style attacks have been changing every month or two since 2025. New lures, new delivery, new payloads. MITRE added the technique to ATT&CK as T1204.004, User Execution: Malicious Copy and Paste, on 18 March 2025, and its defining property for a hunter is that the victim performs the execution by hand. The adversary’s work ends at persuasion: a fake CAPTCHA, a fake error dialog, an instruction to press Win+R and paste.

A customer asked whether they were covered against the current variant. Chasing variants one at a time is a losing game, because by the time you have content for this month’s version there is a new one. So, the playbook targeted the part that does not change. Whatever the lure, almost every variant ends the same way: a user types or pastes a command into the Windows Run dialog.

Hunt the place the user types, and the variant stops mattering.

Why RunMRU is the right source

Windows keeps a record of what goes into the Run dialog at:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Each command is stored as a string value named a, b, c and so on, with an MRUList value recording the order they were used in. It is per-user, it persists across reboots, and in most estates, nobody is watching it.

Three properties make it good hunting ground:

• It records intent, not just execution. A command in RunMRU is something a human deliberately typed or pasted. That is a far higher signal-to-noise ratio than a process-creation feed.
• It is retrospective. You are reading a history, so the hunt is not limited to what happened while your tooling was watching.
• It is cheap to query. One registry value, one question, no agent-side deployment, no new telemetry pipeline.

The pivot

Querying that value across a large estate returned tens of thousands of results. That is the moment most hunts stall, and it is where the method matters more than the query.

Instead of narrowing by keyword, the filter narrowed by behavior: commands that reach outside the estate to fetch something. Payload retrieval is the step ClickFix depends on, so it was the right filter for the original hypothesis. It also happens to catch a completely different class of problem.

One line stood out, and not because of the domain or the tooling. Two small details did it: a -u flag, and an output filename that referred to vulnerability data.

In curl, -u takes credentials inline as user:password. The username and the password were right there in the registry, in plain text, exactly as they had been typed months earlier. Whoever wrote that line was solving a problem: pull the findings export, save it locally, open it. Nobody was thinking about the fact that Windows remembers.

Fifteen minutes, and what made that possible

The notebook skeleton already existed, which is the part worth copying. Data was readable five minutes after deciding to look. The cleartext password was visible within fifteen, and the team was messaged immediately to verify both the credential and the endpoint. A ticket was raised and the password rotated inside the hour.

That speed came from the query already being written, not from the discovery being dramatic.

Why the destination mattered more than the credential

The credential did not open the customer’s own environment. It logged in to a third-party vulnerability-management portal, which holds the register of every unpatched weakness across the estate.

An attacker holding that does not need to scan or guess, and does not need to make noise finding a way in. They can read the list. And because the account lived on a third-party platform, the question of who owns rotating it has no obvious answer, which is exactly the condition under which credentials sit unrotated for months.

On Verizon’s 2026 numbers that is the direction the risk is moving. Third-party involvement in breaches rose 60% year on year and now features in close to half of them, and among third-party organizations weak passwords and permission misconfigurations take close to eight months to fix for half of all findings.

What did not work

Keywords were the obvious place to start, and they were a dead end. Searching the Run history for https, PowerShell or cmd gives you either nothing or far too much. All three are trivial for an attacker to obfuscate, and all three appear constantly in legitimate use. "Simple indicators like these are easy to obfuscate and rarely provide value," the HuntIQ hunter who found it said.

The distinction is worth stating precisely, because it generalizes past this hunt. Keyword filters ask what string is present. Behavioral filters ask, “what is this command trying to do”. The first is easy to evade and noisy. The second is small enough to read line by line.

Run this yourself

1. Pull the Run-dialog history from every endpoint. In Tanium that is a single question: Get "Registry Key Value Names with Data" [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU] from all entities
2. Filter for external retrieval, not for keywords. Commands that fetch something from outside the estate: HTTP clients, file-transfer utilities, script interpreters pulling a remote resource. That set is small enough to read.
3. Read the survivors for authentication flags. In practice that means -u and --user on curl, -p and --password on a range of clients, /user: on Windows utilities, and any URL carrying credentials in the authority section as user:pass@host.
4. Treat third-party destinations as the priority. Credentials to somebody else’s platform are the ones nobody in your organization owns the rotation of.
5. For those with Tanium Atlas run the following prompt: /hunt Check the Windows Run-dialog history (the RunMRU registry key) on all endpoints for typed commands that pull from the internet and carry an inline password — like curl -u user:pass. Report the host, user, and destination, and mask the password.

Preconditions and limits

• The endpoint must be online. This reads the registry live, not a historical store.
• You get the currently logged-on user only. RunMRU lives in HKCU, so one pass on a shared endpoint returns one person’s history.
• On shared or shift-working estates, re-run the hunt at different times of day. You pick up additional users as they log in, and a single sweep will quietly miss most of them.
• It is evidence of typing, not of execution. A command in RunMRU was entered; whether it ran successfully is a separate question.
• Absence proves nothing. The key can be cleared, and plenty of users never touch the Run box at all.

ATT&CK mapping

What the customer changed

Three things, in increasing order of usefulness.

• They rotated the password.
• They educated the users who had been doing it.
• Then they removed the reason it existed.

The manual request that needed a password typed into a Run box was replaced with a properly authenticated API call collecting the same vulnerability data. The first two fix an incident. The third fixes the class.

The takeaway

Content built for one hypothesis routinely finds something outside it, and that’s not luck. A hunt aimed at a specific technique still surfaces whatever else shares that technique’s substrate. Hunt where users act, filter on behavior rather than strings, and read what comes back.

The question worth asking your own estate this week is not whether your credentials are strong. It is where they are written down in plain text right now.

Get ahead of the next one

• Learn how Tanium Security Operations and HuntIQ catch what keyword hunting misses.
• See how fast Tanium Atlas turns a hunting hypothesis into a fleet-wide sweep.

Sources for the external figures

Verizon 2026 Data Breach Investigations Report, via Help Net Security, 20 May 2026. helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/ (opens in a new tab)

MITRE ATT&CK, T1204.004 User Execution: Malicious Copy and Paste. attack.mitre.org/techniques/T1204/004/ (opens in a new tab) Added 18 March 2025.