This is called a "ClickFix" attack. There is really _never_ a time when a CAPTCHA will require you to execute code on your machine.
The attack is basically getting someone to accidentally run malicious code.
- ctrl + R brings up the Windows "run" dialogue.
- the code executes a powershell command that reaches out to a remote server
- if successful, the remote server answers and you have installed a dropper or something.
Really, you should never do _anything_ like this for any website. You don't need to protect yourself. This is sort of equivalent (in the strict metaphorical sense) of getting a call from your bank and they ask you for your banking password: you just never do it, no matter what. Same thing here. You don't ever execute code via the run dialogue to solve a CAPTHCA. Never.
> There is really _never_ a time when a CAPTCHA will require you to execute code on your machine.
I think the concern is the user not knowing they're executing code on their machine.
And as a counterexample: some captchas require you to compute something expensive to prove you're not a llm scraper or whatever. It's normal for captchas to require you to execute code on your machine, it's just usually done within the browser's sandbox.
And anyway, these things are completely incomprehensible to non-technical users.
True enough... but even then, you can download and review the script before running. Usually it just detects your OS/Distro and then downloads and runs the appropriate installer. You can also do this by hand.
For that matter, there's always a risk of downloading/installing anything from anywhere. There have been successful compromises of many application supply chains at this point in official release paths. You will accept some risk regardless of your approach.
$dayjob just sent out a corporate wide email saying the same thing... I guess it's starting to go around... it's been a while since I've seen a fake website telling people to eg. disable UAC.
I make it a rule never to give confidential information to an incoming call. I had a primary doctor whose office would send notification calls immediately asking for part of my social security number, I always hung up.... I figured out it was for the doctor later, and commented that it was ridiculous and I wouldn't ever receive any such notifications.
Just that simple practice has kept me reasonably safe, even from an AI scam once.
I've seen sites with similar fake captchas posted twice in the last month by old time regular users. My guess is that the sites were infected after they saw and decide to post it here.
As a workaround, is it possible to disable Ctr+R to add some friction in case I am distracted?
What’s the Venn diagram of 1) HN users, 2) on Windows, 3) willing to paste something tagged as malware into their own systems to verify?
Given that the asker isn’t experienced enough to know for sure, erring on the side of giving all the information was the right call. If they didn’t, someone would be riding them about “how are we suppose to know if you don’t show us?”.
Was the site itself actually infected(hacked)? If not, then all you need is adblock (like ublock origin). And that was true for last 20 years.
If website actually got hacked then I don't know of any good solutions. It will be flagged soon or later, and new visitors will be blocked by "Google Safe Browsing". Using something like "Qubes OS" might protect you against attacks based on browser zero-days but VMs don't really protect against ClickFix when people usually share clipboard between host and client VMs.
Google is trying to normalize a new "complete the captcha on your phone by scanning a QR code" flow, which I'm sure will be a whole new vector for scams.
Users are habituated to clicking links (mostly from their email) as verification, too. QR codes get a weird amount of hate for something that basically amounts to a hyperlink you can transmit through meatspace.
this is wildly complex, way more so than a traditional ClickFix attack. it's fetching JS scripts from a Ethereum/Base contract and executing them - i've never seen something like this before
I've seen similar before where it wasn't the page itself that injected it - rather it was injected by a compromised/sold extension that has permissions on all pages.
Not this time. Go to crookedtimber dot org and you can still see it. Just don't follow the instructions... but clean your browser afterwards!
It even supports Macs. But the Mac clipboard content is just "Oops...".
P.S.: even worse: the crookedtimber site itself is infected. No third-party attack. It registers a service worker on the user's browser that stays even when you leave the site. Be sure to clean up the storage data after visiting that site.
So done a much deeper analysis - there is an loader injected at the Wordpress side which triggers a read of a payload from a smart contract on the Ethereum chain. It stores this in localStorage, registers a ServiceWorker etc so it is persistent.
It then spins up the ClickFix attack - limited to one time per day. I haven't dug into the payload given by the ClickFix attack yet.
For people that have visited while it exists:
1. On Chrome go to chrome://serviceworker-internals search for crookedtimber and unregister the ServiceWorker
2. On Firefox go to about:debugging#/runtime/this-firefox, search for crookedtimber and unregister the ServiceWorker.
If you want to be even safer - just clear all local data for CrookedTimber.
Claude's analysis: "it skips logged-in WordPress users (wordpress_logged_in_* cookie), skips /wp-admin and /wp-login.php, and rate-limits to once per day per visitor via localStorage. That's why site admins don't see it — and why you only saw it on first load."
Doing a bit of digging too - it also filters only to users running MacOS or Windows and skips everything else which is why it will be invisible to the devices I tried it on.
As you might imagine, these attacks are aimed at less sophisticated users who may have no idea what Win+R even does, and who might be tricked into believing that this actually has anything to do with website verification.
The site you visited -- or one of the resources it depends on -- might have been compromised. If you're enterprising, you could probably determine where the malicious script is getting loaded from by looking in the page source.
Heh, the URL OP gave returns an MP3 file (starts with hex FF FB), at the end it mentions "LAME3.100" and about half a kilobyte of U's. It plays in a media player too.
But I guess if it was loaded via mshta it will respond with a different payload.
Now watch the people with "overabundance of caution" tell me what I did was stupid...
> But I guess if it was loaded via mshta it will respond with a different payload.
No, the MP3 file is the payload, mshta ignores the binary noise and executes the HTML in it. The HTML is in the middle of the file (search for "DOCTYPE") and it contains an obfuscated VBScript.
Skipping many steps in the whole chain (registering a scheduled task to be executed 1 second later, disabling TLS certificate verification, corrupting the antimalware scan, deobfuscation/decryption, evasion delays, in-memory PE loading, etc.), it as a whole, roughly speaking:
- downloads second stage payload from gpurq.gravityzone.army/{id}
- downloads an image from i.ibb.co/Q7yqNJpr/init-block.jpg (public image hosting) with a steganographically hidden third stage payload
- decrypts and loads a native PE32, heavily obfuscated and without imports
I ran into the same thing on a cooking blog (which I had visited many times before) a few weeks back. I was pretty mystified but like you, spidey sense kept me from running the code. It's insidious because it looks like it's coming from Captcha. I do have uBO Lite running on Chrome. Tried the website in Firefox and also got the same manual run thing.
I wasn't sure what to do about it. Obviously I was unable to notify the blog owner. I came back to the website about a week later and it didn't come up again.
Almost, recently. I bought a new Mac, needed something reliable to carry around. I never had a Mac or anything from Apple before, so I wasn't familiar with how exactly does it work. I knew homebrew existed, I understood it's similar to Linux/Windows in that not all applications are in the store, but wasn't familiar at all with how those are commonly installed.
Here's what I did:
1. Open Safari, the only browser there was.
2. Typed "claude mac download" in the search bar (needed Cowork).
3. Clicked the first link.
4. Copied the command it told me to, instructing me to run it in terminal.
Only now I realize that there's something fishy about the command; it had base64 payload in it. Didn't run it and took closer look on the page - it was a Claude share (which I quickly scrolled over).
I can admit mistakes, but Google, Apple and Anthropic deserve some blame here, too.
- Google: pushed malware link up top, didn't (distinctly, at least) mark it as a paid result and I'd swear it didn't show me the URL (which I usually always check before clicking, but maybe I just missed it as the search results are rendered differently from Kagi's)
- Safari: hides path by default, so all you see is "claude.ai". Someone probably thought this looked nice, I think it's just borderline idiotic.
- Anthropic: hosts what's essentially a user-content on their main domain.
Also recently saw a few legit projects using base64 in their install one-liners. Please, stop it.
> How do you protect yourself ?
Installed not Safari and made Google not my default search engine, as I always do. That way I at least always know where I am.
As a "end-user" one of the most effective way is to either disable js, which isn't the most practical thing for most of us. You can also use ublock-origin, it doesn't only block ads!
You can also throw a lying-DNS in the chain, either by using something like Quad9 or a local resolver with appropriate blocklists (think of unbound or for a more user-friendly solution piehole)
Also an anti-virus can help detect the usual stealer that will be dropped by these FakeCaptcha/ClickFix attack, but they are also easily bypassed, that's why you need multiple layers of protection : each of them can and will fail
This is called a "ClickFix" attack. There is really _never_ a time when a CAPTCHA will require you to execute code on your machine.
The attack is basically getting someone to accidentally run malicious code.
- ctrl + R brings up the Windows "run" dialogue.
- the code executes a powershell command that reaches out to a remote server
- if successful, the remote server answers and you have installed a dropper or something.
Really, you should never do _anything_ like this for any website. You don't need to protect yourself. This is sort of equivalent (in the strict metaphorical sense) of getting a call from your bank and they ask you for your banking password: you just never do it, no matter what. Same thing here. You don't ever execute code via the run dialogue to solve a CAPTHCA. Never.
https://www.sentinelone.com/blog/how-clickfix-is-weaponizing...
> There is really _never_ a time when a CAPTCHA will require you to execute code on your machine.
I think the concern is the user not knowing they're executing code on their machine.
And as a counterexample: some captchas require you to compute something expensive to prove you're not a llm scraper or whatever. It's normal for captchas to require you to execute code on your machine, it's just usually done within the browser's sandbox.
And anyway, these things are completely incomprehensible to non-technical users.
>And as a counterexample: some captchas require you to compute something expensive to prove you're not a llm scraper or whatever.
I've never run into one of these. What do they ask you to compute?
For example: https://anubis.techaro.lol/
Wikipedia has a good explanation: https://en.wikipedia.org/wiki/Anubis_(software)#Design
If one user makes the mistake, it would be fair to blame them.
Because thousands of users make the same mistake, blame needs to be directed at Windows UX.
MS could fix this easily by 1) moving Run to optional features and 2) removing online features from Start to make performance comparable.
The other "run" interfaces (terminal, conhost, Powershell) are sufficiently menacing to scare away non-devs already.
but people pipes a shell script from a URL to bash all the time. with enough practices, it becames second nature.
True enough... but even then, you can download and review the script before running. Usually it just detects your OS/Distro and then downloads and runs the appropriate installer. You can also do this by hand.
For that matter, there's always a risk of downloading/installing anything from anywhere. There have been successful compromises of many application supply chains at this point in official release paths. You will accept some risk regardless of your approach.
$dayjob just sent out a corporate wide email saying the same thing... I guess it's starting to go around... it's been a while since I've seen a fake website telling people to eg. disable UAC.
I make it a rule never to give confidential information to an incoming call. I had a primary doctor whose office would send notification calls immediately asking for part of my social security number, I always hung up.... I figured out it was for the doctor later, and commented that it was ridiculous and I wouldn't ever receive any such notifications.
Just that simple practice has kept me reasonably safe, even from an AI scam once.
I've seen sites with similar fake captchas posted twice in the last month by old time regular users. My guess is that the sites were infected after they saw and decide to post it here.
As a workaround, is it possible to disable Ctr+R to add some friction in case I am distracted?
> There is really _never_ a time when a CAPTCHA will require you to execute code on your machine.
Oh yeah? What about Google saying “install the reCAPTCHA app in the App Store” <https://reclaimthenet.org/google-broke-recaptcha-for-de-goog...>?
It’s absurd, but these nominally-security tools frequently genuinely train users to become susceptible to attacks.
Not directly answering your questions, but I just wanted to say: Great instincts!
You saw something unusual, then
1. Stopped what you were doing.
2. Investigated to see if this was legitimate or malicious.
3. Identified a place to asked others about it.
4. Formulated a good question with enough background information to help people answer it.
All around good job! Well done.
5. Put the malicious payload directly into work AI system.
"Great instincts!" lmao
I do this literally several times a week. “Hey Droid, this looks like malware. What do you make of it?”
It’s the best sandbox I have near at hand for investigating things like that.
5. Paste the entire command on HN so the aspiring script kiddies have a launching point. 6. ? 7. Profit!
What’s the Venn diagram of 1) HN users, 2) on Windows, 3) willing to paste something tagged as malware into their own systems to verify?
Given that the asker isn’t experienced enough to know for sure, erring on the side of giving all the information was the right call. If they didn’t, someone would be riding them about “how are we suppose to know if you don’t show us?”.
I guess it's ok then.
> How do you protect yourself
Was the site itself actually infected(hacked)? If not, then all you need is adblock (like ublock origin). And that was true for last 20 years.
If website actually got hacked then I don't know of any good solutions. It will be flagged soon or later, and new visitors will be blocked by "Google Safe Browsing". Using something like "Qubes OS" might protect you against attacks based on browser zero-days but VMs don't really protect against ClickFix when people usually share clipboard between host and client VMs.
Google is trying to normalize a new "complete the captcha on your phone by scanning a QR code" flow, which I'm sure will be a whole new vector for scams.
Can’t wait for the first “scan this code to verify” scam that takes you to a mobile Chrome 0day
Or you could send them to download some spyware/adware Play Store app
Couldn't any exploit possible via that pathway also be executed based on a link? I don't see how a QR code makes the situation any worse.
Once users are habituated to scanning QR codes for verification, it becomes easier.
Users are habituated to clicking links (mostly from their email) as verification, too. QR codes get a weird amount of hate for something that basically amounts to a hyperlink you can transmit through meatspace.
this is wildly complex, way more so than a traditional ClickFix attack. it's fetching JS scripts from a Ethereum/Base contract and executing them - i've never seen something like this before
Do you have any browser extensions enabled?
I've seen similar before where it wasn't the page itself that injected it - rather it was injected by a compromised/sold extension that has permissions on all pages.
Not this time. Go to crookedtimber dot org and you can still see it. Just don't follow the instructions... but clean your browser afterwards!
It even supports Macs. But the Mac clipboard content is just "Oops...".
P.S.: even worse: the crookedtimber site itself is infected. No third-party attack. It registers a service worker on the user's browser that stays even when you leave the site. Be sure to clean up the storage data after visiting that site.
So done a much deeper analysis - there is an loader injected at the Wordpress side which triggers a read of a payload from a smart contract on the Ethereum chain. It stores this in localStorage, registers a ServiceWorker etc so it is persistent.
It then spins up the ClickFix attack - limited to one time per day. I haven't dug into the payload given by the ClickFix attack yet.
For people that have visited while it exists:
1. On Chrome go to chrome://serviceworker-internals search for crookedtimber and unregister the ServiceWorker
2. On Firefox go to about:debugging#/runtime/this-firefox, search for crookedtimber and unregister the ServiceWorker.
If you want to be even safer - just clear all local data for CrookedTimber.
I'm not getting it at all! I'm guessing something about my environment has caused it to cloak itself.
Claude's analysis: "it skips logged-in WordPress users (wordpress_logged_in_* cookie), skips /wp-admin and /wp-login.php, and rate-limits to once per day per visitor via localStorage. That's why site admins don't see it — and why you only saw it on first load."
Doing a bit of digging too - it also filters only to users running MacOS or Windows and skips everything else which is why it will be invisible to the devices I tried it on.
Reporting to https://safebrowsing.google.com/safebrowsing/report_phish/, which if their tests reproduce the problem will make most browsers unwilling to load the domain. Generally ether caused by a hacked CMS or bad advertisement.
VT says no bueno: https://www.virustotal.com/gui/url/4812564b97c63e1607e9182d0...
This exact technique has been around for a while; there are even government resources warning about it (e.g. https://www.michigan.gov/msp/divisions/intel-ops/cyber/mc3/c... - April 2025).
As you might imagine, these attacks are aimed at less sophisticated users who may have no idea what Win+R even does, and who might be tricked into believing that this actually has anything to do with website verification.
The site you visited -- or one of the resources it depends on -- might have been compromised. If you're enterprising, you could probably determine where the malicious script is getting loaded from by looking in the page source.
fine-work-team.com has been reported as suspicious. Cloudflare is blocking it now.
Heh, the URL OP gave returns an MP3 file (starts with hex FF FB), at the end it mentions "LAME3.100" and about half a kilobyte of U's. It plays in a media player too.
But I guess if it was loaded via mshta it will respond with a different payload.
Now watch the people with "overabundance of caution" tell me what I did was stupid...
> But I guess if it was loaded via mshta it will respond with a different payload.
No, the MP3 file is the payload, mshta ignores the binary noise and executes the HTML in it. The HTML is in the middle of the file (search for "DOCTYPE") and it contains an obfuscated VBScript.
Skipping many steps in the whole chain (registering a scheduled task to be executed 1 second later, disabling TLS certificate verification, corrupting the antimalware scan, deobfuscation/decryption, evasion delays, in-memory PE loading, etc.), it as a whole, roughly speaking:
- downloads second stage payload from gpurq.gravityzone.army/{id}
- downloads an image from i.ibb.co/Q7yqNJpr/init-block.jpg (public image hosting) with a steganographically hidden third stage payload
- decrypts and loads a native PE32, heavily obfuscated and without imports
I ran into the same thing on a cooking blog (which I had visited many times before) a few weeks back. I was pretty mystified but like you, spidey sense kept me from running the code. It's insidious because it looks like it's coming from Captcha. I do have uBO Lite running on Chrome. Tried the website in Firefox and also got the same manual run thing.
I wasn't sure what to do about it. Obviously I was unable to notify the blog owner. I came back to the website about a week later and it didn't come up again.
Seems like the attack is still happening.[0]
> 0. https://imgur.com/a/KnxRDKg
> How do i protect myself from these scams / hack attempts in the future
Endless vigilance. Scammers are always working on new tricks. You were rightly suspicious and not fooled by this one.
> Has this happened to you before ?
Almost, recently. I bought a new Mac, needed something reliable to carry around. I never had a Mac or anything from Apple before, so I wasn't familiar with how exactly does it work. I knew homebrew existed, I understood it's similar to Linux/Windows in that not all applications are in the store, but wasn't familiar at all with how those are commonly installed.
Here's what I did:
1. Open Safari, the only browser there was.
2. Typed "claude mac download" in the search bar (needed Cowork).
3. Clicked the first link.
4. Copied the command it told me to, instructing me to run it in terminal.
Only now I realize that there's something fishy about the command; it had base64 payload in it. Didn't run it and took closer look on the page - it was a Claude share (which I quickly scrolled over).
I can admit mistakes, but Google, Apple and Anthropic deserve some blame here, too.
- Google: pushed malware link up top, didn't (distinctly, at least) mark it as a paid result and I'd swear it didn't show me the URL (which I usually always check before clicking, but maybe I just missed it as the search results are rendered differently from Kagi's)
- Safari: hides path by default, so all you see is "claude.ai". Someone probably thought this looked nice, I think it's just borderline idiotic.
- Anthropic: hosts what's essentially a user-content on their main domain.
Also recently saw a few legit projects using base64 in their install one-liners. Please, stop it.
> How do you protect yourself ?
Installed not Safari and made Google not my default search engine, as I always do. That way I at least always know where I am.
> showed showed
> How do you protect yourself ?
As a "end-user" one of the most effective way is to either disable js, which isn't the most practical thing for most of us. You can also use ublock-origin, it doesn't only block ads! You can also throw a lying-DNS in the chain, either by using something like Quad9 or a local resolver with appropriate blocklists (think of unbound or for a more user-friendly solution piehole)
Also an anti-virus can help detect the usual stealer that will be dropped by these FakeCaptcha/ClickFix attack, but they are also easily bypassed, that's why you need multiple layers of protection : each of them can and will fail
pinged one of the authors on bsky, let's see
I have seen it before in infected WordPress instances related to recent remote RCE. Probably one victim more.
It’s a typical technique, report it to safe browsing, upload it to VirusTotal, that should be tit flagged quickly