The Evolution of Identity Theft: Understanding ClickFix and ConsentFix

Defences get stronger, attackers get smarter.

And so it goes.

Now that strong MFA has made compromising identities a lot more difficult, attackers are increasingly looking for other ways to compromise accounts and organisations. Social engineering isn’t new, but what they are asking users to do is changing.

In this post we will look at ClickFix and ConsentFix; two methods that are gaining traction as they bypass traditional controls, tricking users into performing actions that grant attackers access without even realising it, and then we’ll look at how we can protect against them.

ClickFix

ClickFix is a sophisticated social engineering attack where attackers compromise the user by tricking them into performing dangerous actions. It can take many forms, but a common one is a fake website that shows an error and copies malicious commands to the clipboard in the background.

The user is then instructed to ‘fix’ the error by pressing Windows+R, then CTRL+V, then hit enter. This pastes the malicious code into the run dialogue and executes it. The code then runs in the background, potentially installing infostealers like Lumma Stealer or Vidar.

Attackers are favouring this method because it bypasses the numerous scans that both the browser and operating system perform to check for malware. As far as Windows knows, the user has executed a command entirely of their own volition!

Attackers may also encode the command using Base64 encoding, making it appear mostly gibberish. Either way, for non-technical users it can be an easy trap to fall into.

This blog post is an excellent deep dive investigation into a fake Google Meet ClickFix campaign.

ConsentFix

If ClickFix is looking for access to the local machine to extract data, ConsentFix is after a Microsoft 365 or Azure tenant to compromise.

ConsentFix often uses a fake verification page (frequently impersonating Cloudflare CAPTCHA), but instead of a puzzle or pictures of cars it asks the user to sign in to their account. The clever part is the attacker uses the legitimate Microsoft sign-in page to authenticate the user. They can do this because it isn’t after the credentials.

They’re after the redirect URL.

When an OAuth app is registered, it listens for a reply, which is where Microsoft redirects the browser to after authenticating. But because it isn’t a legitimate OAuth request, nothing is listening, so the browser shows an error. The URL is still in the address bar though, and this contains an authorisation code.

The attacker then tells the user Hey, let me help you with this error. Just send me the URL of the error page and I’ll sort that.

Once the attacker has that URL they can get the code, exchange it for an access token, and gain full delegated access to the user's corporate environment, completely bypassing MFA and passkeys because the initial login was legitimate. Even if it is only a ‘standard’ user, not an admin, the attacker can still do an awful lot of damage.

Mitigations

These are social engineering attacks, so a large part of the mitigation is educating users not to paste content if asked to, and to recognise fake CAPTCHAs and websites.

There are also some technical mitigation’s administrators can perform:

ClickFix

1. Disable the Run dialog box. This should stop the attack, unless the user is being engineered over the phone, where the attacker can pivot to cmd or PowerShell.
2. Use Microsoft Attack Surface Reduction rules to block processes running from user folders. This means that if the user does run the attackers script, it can’t start up any processes.
3. Enable PowerShell Script Block Logging. This doesn’t stop the command running, but it ensures that if it has been obfuscated then the plaintext version is stored in the logs, making investigations and postmortems easier.

ConsentFix

1. Prevent users consenting to apps. In Entra, you can force an admin consent workflow that requires authorisation before any consent is granted.
2. Token Binding. Here we are again. The most effective way to stop attackers stealing tokens is to make them useless if they don’t have access to the device itself. By binding the token to the device (check out this post), the attacker cannot use the token in the URL.
3. Only allow verified publishers. This ensures the only apps that can be consented to are apps that have been published by companies vetted by Microsoft.

Conclusion

As admins we’re used to users inadvertently working against us. Sure, they mean well, but we all know users that would fall for these attacks all to easily. A well rounded security posture should already have controls in place to mitigate these attacks, but it is worth checking.