 Good morning. Thanks for coming out. I was going to say at 10, but at this point it's like 1020. Sorry. My name is Phillip Martin. I am the CISO at Coinbase. I've been Coinbase about three years. And, yes, and apparently I am too tall for the microphone. That's fine. What we're going to talk about today is a follow on to a blog post we released yesterday, but we're going to talk about an attack from what I think is one of the most dangerous attacker groups in cryptocurrency today. The attack specifically targeted cryptocurrency companies around about 20 different companies, including us. It leveraged two different Firefox ODAs in the execution of the attack as well as a really extensive social engineering phase that we'll get into as well. And we're going to spend the next 50 or so minutes until you kick me out of here. So we're breaking down the attack, how it went down, lessons we learned from it, indicators we took from it, what we know about the attacker, and whatever questions you could have at the end. My expectation is I'm probably going to get more than normal amount of questions at the end of this. So I'm going to try to leave like at least 10, hopefully 15 minutes. And if there's not that many questions, I'm going to talk some more. So ask questions. Let's talk about that. That's me. I do things. I've done things other places. We don't need to dwell on that. So we don't advise that like I told you when I start sort of breaking down the attack, give you a high level overview of sort of the way I'm breaking down in terms of phases. I doubt I'll just caveat this. I'm going to say it later too. Well, I'm going to break this down in terms of sort of phases of the attack. I doubt the attack, the attacker thought of it the same way. And I doubt it happened like that in terms of the actual timeline. But I'm chunking it up so we can like talk about each piece discreetly, right? So the timeline makes it look like it all happened one after the other. I doubt that's actually true in the real world. We'll talk about what our detection strategy, why we why we why and how we detected it, lessons learned a little bit about the attacker. So let's get into it. So that's the quick overview. The the super high level discussion of this. Thanks for reminding me to put my phone on silent is that an attacker attacker group. It's known in non English reporting has been from reporting in Polish and Japanese on this group that they call hide seven. We track them as crypto three. So the third in our serialization of of actors put together a list of about 200 people, all for the most part in crypto sent out a really elaborate social engineering scheme that was that was involved with Cambridge and a couple of academic prizes that they award. And like I said, we'll go into that in depth. They windowed that list of 200 down to about five that they actually wanted to exploit. They delivered a Firefox Oday to the two Firefox Odays to those to those five, which then delivered a as a malware set up that went through a traditional sort of recon pillage with with phase two being a more full featured rat. We think this is the same actor that breached coin check. We think this this actor has been active in Asia and Eastern Europe for quite a while. This actor's dropped over the course of their lifetime that we can do we can see, which goes back to about 2016. We think this attacker has dropped about six Odays of various quality. So obviously well funded, well-renized, like they know their shit. So let's let's break this down a little bit. I was going to do a really fancy like set of I'm going to fade everything else out and make that the one bright. If you ever try to make opaque squares and Google Google sheets or Google slides, I'm so sorry for you because it is such a pain in the ass. So phase one recon, this is the phase we know the least about in terms of what the attacker did and what they were looking for. We know that they put together a list of about 200 people in the initial target set. We know it was it was concentrated in America and EMEA as a little bit of targeting in APAC too. We know that for the for the for the majority of the targets, they were right. They were involved in crypto. There were a few where they were just dead wrong and there had literally nothing to do with cryptocurrency. They seem more interested in IT infrastructure, security, engineering for obvious access reasons. But but we're willing to take any foothold they can get based on based on sort of actions that they took later. What do we not know? We do have no idea how they source their data zero at all. The email addresses they're they're using are personal email addresses. They weren't really using much in the way of corporate email addresses. Like I said, they got they got the list right. My my suspicion is they're using classical OSINT techniques. They were looking at names in news reports, things like that, using that to then develop further information about it and specifically dig up personally mail addresses to bypass corporate controls. But we don't actually know that for sure. We don't know how long this recon phase lasted. We don't know if they were just sitting on a portfolio of people that they wanted they wanted to breach, or if they'd got it all together. We don't know if if I might have phase one and two switched, they may have acquired the Oday before they put the list together, right? We just sort of don't know exactly how that played out because that's this is the phase we have the least visibility into. So next phase or weaponization, right? And this is this is a really, really rich topic area. And some some really, really interesting pieces here. Exploitation. This is a pretty rich, rich topic area. I've lumped into this sort of both the exploit dev as well as what I call sort of the infrastructure prep that the attacker did. And we'll go through sort of both of those things. Number. So there were two days leverage in this attack, CV 2019 11707 and 708. They're both Firefox exploits. One is a is essentially a jit exploit. And the other is a sandbox escape from like I'm stepping on a cable here. From Firefox, the net result of the two is a zero user interaction, Oday and Firefox, right? Pretty pretty awesome. So CV. So 707 was was a simultaneous discovery by a researcher at Project Zero, named Sanel Gross, and the attacker, whoever the attacker acquired this this exploit from. Sanel has a really good write up on on Twitter about the differences between his approach between like the way they discovered it, and the result and exploit that they wrote. And what the attacker wrote, the TLDR of that is that we think that that the attacker found it a very, very different way than Google did. Google found it via fuzzing. The attacker probably found it as a variant of another existing Oday, CV 2019 9810, which was disclosed in in April of this year, right? So based on the based on the similarities and those two types of bugs, what we think was happening was the attacker was looking for that that same pattern bug, potentially as potentially just a straight variant of 9810 and ran across this bug as well at about the same time. The the second bug is actually way more interesting. So so 11708 was a was a novel discovery by the attacker never before seen sandbox escape in Firefox, while the the underlying mechanism that was used in the attack has actually been in Firefox for years. The specific way this attacker chose to trigger it had only been possible since May 12. Right. So so what does that imply that that implies the attackers had about a two week discovery to weaponization cycle, which is insane. Right. If you have ever tried to write an exploit for something as complicated as a browser on a platform like Mac, two weeks is just crazy fast to be able to get that out the door. Right. And we know this because we saw the attacker starting to set up infra, setting registering domains, things like that on about made on about May 28 is when we think the attack, the attacker started to get set up in for a because they're setting up info, we're assuming that means they had the O day, or at least they were almost done with the O day. Otherwise, why go to the effort if you if you if you don't know what you're going to do with it? Sorry, I'm going a little bit faster than I'd planned to because we're a little bit tight on time. Oh, right. The the talk about the came. So the Cambridge side of stuff is really interesting too. So the attackers gained access to two accounts at the Cambridge University professors accounts. Well, more a little bit more on that a little bit later, two accounts, two email accounts, legit Cambridge domains. And they use those email addresses or those accounts in both the fishing. So we'll see examples of this later where they were sending from legit Cambridge University accounts, as well as to host pieces of the the actual exploit pages themselves. They didn't host the O day on Cambridge. I was in a separate domain, but they hosted all the lower pages, everything else. One of the things that Cambridge does for people that have accounts is you can, you know, the old school home directory, right, tilde user name right after the top level domain, they make that available when you have an account. So the attackers leverage that as part of the overall social engineering process, you'll see some of the links they used when we talk about the fishing, but it really, really, really improved their ability to fool their targets quite thoroughly. We don't know a ton about the Cambridge side of this equation. We don't know how long the attackers were in. We don't know if they used it for other attacks. We don't know. We don't know if the accounts they used were or actual user accounts, or they were just completely fake. We've done a fair bit of background on this. The LinkedIn profiles, we think are fake. So they backed these accounts with that like LinkedIn profiles and other data. There's no other results for these names like we think it's probably the attacker had enough access to create these users, but we don't know either way. So the delivery is my favorite face. It's my favorite phase because the level of effort we saw from these attackers on the social engineering side was in my experience extraordinary. We'll see this in a second. The attackers took on average 10 days to two weeks with the victims from the first contact all the way through a non-nilicious phase of social engineering until they went down the list and figured out, do we care enough about you to give you a zero day until they finally actually delivered at the far and that took about 10 days to two weeks. Because they were responding on like normal human timelines, they weren't doing like automated responders or cut and paste stuff. It felt looking at the email threads. It felt normal. It felt like a human. It felt like an academic responding back and forth. So let's take a look at that and what that looked like. So this is what the initial outreach email was. There were two versions of this. So this one, this one references the the Adam Smith Prize, which is an economic prize, economics prize that Cambridge awards to, I think it's post postdocs, I believe, on an annual basis. And it's specifically, specifically focused on, like I said, economics, a couple of things to note about this, I'll use this example, because it's better colored that link you see right there. Number one, note that it's going to that that this user's homepage or home directory, not a top level Cambridge site. To that link is entirely benign. There's not a malicious bone in that link's body, or in the resulting web pages, nothing. It is a pure copy of the Adam Smith Prize page that you can find on Cambridge, right, pure copy, nothing, nothing changed about it. The second phase, so you respond back, you say, like, great, this is amazing. I'm going to do this. This is so cool. Well, first, I'll show you the the Adam Smith Prize variant. So different name, same pattern, right? So you follow up back up, say, great, I would love to do this sounds amazing. Thank you so much for reaching out. And you get something like this back, right? So thanks so much for your reply. There were a few variants of this that we saw. But basically, if you if you reach back and said, like, yep, this is awesome. I love math because reasons, they said this, if you if you responded back and said, like, hey, I'm in marketing, dude, like, why are you emailing me this? They ceased contact immediately. Really, any reply other than, yes, this is right down my alley is amazing. The attacker sees contact immediately and just moved on. Right. And keep in mind, of course, up to now, if if you were a normal user, and you said this, like, there's nothing suspicious here, is an email from from a Cambridge University account referencing a Cambridge University University Cambridge page. The most suspicious thing is I wonder how they got my name. Right. So far, so good in terms of obstacles, attackers. So a few days after that, what you would get is this. You would get the the the and in some cases, there were a few more back and forths based on like specific questions and answers, the attackers like engage wonderfully. You'll note throughout this entire thing, good grammar, good writing. Like, they're using reasonable punctuation. This is not what you expect on a normal sort of like low or even mid quality fishing. So this is the actual exploitation as far as it starts, right? So that that link there, that's malicious. That link is the link that hosts the that that sort of does the final checks and hosts the actual O day or links to it at least. Like I said, so from tip to tail from from this to that 10 days to two weeks, it for most for most recipients, right? So so really, really high effort, very high quality, like nothing super weird about this, right? So at this point, they're saying like, Okay, these are the specific projects we want you to review, law view it log in. This goes to that link is actually copied again from Cambridge University's actual website. It's their IDP login page that the attackers stole, right? And at that point, once we click there, we talk, we start to talk about exploitation, right? So there's two small changes to to that to the website that the attackers made. Number one, they included this, right? Which is just saying, if you're back, if you're using Firefox on Mac, you're good to go. The the bit about if you're using anything that's not a Mac, we think is, while we looked when we saw this code, we looked and said, do they have more exploits? Are they exploiting like other shit too? That'd be really cool. We don't think so. We think there was only the one exploit. We think that that was more around op sec, than it was around target selection, so that a person who visited on Windows, right, is going to see nothing really weird. The username password won't work because there's nothing hooked into the form on the back end. But it's like, Oh, that's weird. I wonder what happened, right? As opposed to if you're on Mac, now if you're on Mac, and you're on Firefox, or sorry, if you're on Mac and you're not on Firefox, what you get is this, right? Oh, so sorry, your browser is not supported. Please install Firefox and continue, right? And almost to a person, every person who actually went and installed Firefox and passed this step said some variation of, Oh, I just assumed it was a weird academic thing, right? It's a university. Universities do weird shit all the time, right? That's almost to the person. That's what folks said. So you go ahead and do that, and you visit the site, and then this is the second thing they changed. They injected that script at the very, very bottom. That's the actual exploit code. Well, that's the reference to the file that contains the actual exploit code. We're not releasing the ODA yet until more and more users get on upgraded versions of Firefox and users are slow at patching. So Analogs Fit is an attacker-controlled domain. This one was registered on the 28th of May, so right before the campaign started, it does nothing but host this JavaScript file. It wasn't involved in C2, wasn't involved in anything else. It's just nothing but host this. Let's see. So sort of I'm lumping together for the exploitation installation C2. So you visited that. Your browser was exploited. It was a nice clean exploitation. We didn't we didn't observe much of the way of crashes. It seemed quite stable. What happened is your browser would shell out to curl, download stage one, right? So stage one was a variant of the Netwire family. While it is technically a full-fledged rat, the attacker seemed to use it for mostly recon, basic pillaging, and then deciding if they care enough to send stage two down the wire. Stage two is a variant of Mox. The attacker seems to use as a full-fledged rat. We see activity indicative of hands-on keyboard. So at this point, we're not talking automated exploitation. We're seeing somebody somewhere behind a computer telling this thing what to do. One of the difficulties as we advance out of this and into sort of actions on target is that it took us about, so we got our alerts essentially here, right? So when the ODE landed and the shell to curl happened, we started getting paged by our loading systems. So the attacker was only active in a place where we could see them for about 20 minutes, tip to tail in this incident. So they didn't have a lot of time to do post-exploitation activities where we could see them, pluses and minuses there. We have had some access to other systems where the attacker was there, was present longer, but we don't have real-time EDR shall logs from those. We have sort of Deadbox forensics from those things. So we don't really know everything we would hope to know about what the attacker was doing after the initial breach. But we do know a few things. Number one, we know that they went after browser stored credentials, including session tokens. They pivoted, interestingly enough, they pivoted from the endpoint into the cloud. We saw several times, right? So from the endpoint, stealing session tokens, stealing credentials, using that to go into email accounts, online file storage, other cloud-based services was a thing this attacker particularly seemed to like. We saw a bunch of other weird stuff on a few endpoints, like applications that the user didn't recognize that were suddenly installed after the attacker showed up. But again, Deadbox forensics, it's really hard for us to start talking about intent and what the attacker was actually trying to do with that. There is a fair bit of Japanese language reporting on these attackers. So we released a blog post earlier yesterday about this as well and references this. I'm going to forget the name. But the Japanese search, basically, published a really in-depth write-up that goes much more in-depth into some of the techniques that these actors are using. And it really starts, it's one of the ways where we're sort of assessing these are linked actors is all the similarities we saw in the TTPs there. I feel like I'm stepping on something that's half broken, which is why this is happening. So let's talk about the attacker a little bit. Number one, based on open source reporting, we think they've been active since about 2016. We think, in fact, we know they're not covered as a named group by any of the threat intelligence companies that we've talked to. Some cover them as like unknown or unattributed groups in some ways, but no one has sort of named coverage of this group. We think this is the same from the breached coin check. That's the Japanese language reporting I was referring to was specifically talking about the coin check breach. Overlaps include the use of academic emails as fishing, the same malware, the same kind of lures and patterns and how they were reaching out to users. We think this group, lastly, has dropped at least half a dozen O-days since 2016, which when you think about it is actually quite a few O-days in the last three years. This Firefox O-day was by far the most interesting of them. The rest were like O-days in RAR or things like that, that were used, they were much harder to operationalize. We think this is the most interesting O-day. We've seen evidence of them dropping, but what this says to me, and this is why I said at the beginning, I think this is the most dangerous attacker group in crypto today, is a well-funded organized, the skill sets we saw displayed in that exploitation chain. That's not someone somewhere alone. That's a small group between the social engineering and the infra and the O-days and packaging all together. That's a small group. My guess, like looking at the code, looking at the structure, looking at the short development timeline on the O-days is that they bought the O-days, they didn't, I don't think they developed them. I could be very wrong on that. I'd say that's like low confidence statement, but because that cycle was so fast and because when you look at the code, it's nice, it's modular, it was done by somebody who's I think used to building these things before. That makes me suspect that we're dealing with a brokered O-day as opposed to an internally developed O-day. But if that's true, that means, and these guys have done six O-days in the last three years, that's a very well-resourced organization to spin that money for those capabilities. So very, very scary attacker group and not well tracked. So response, so shock, we did not leverage Magic Cyber AI to detect this attack. There were no blockchains involved in this attack, in detection of this attack, nor was there any machine learning. This attack was detected with essentially behavioral rules, right? Shit that just shouldn't happen. It turns out Firefox should not be shelling out to curl. It turns out that files probably shouldn't be executing from temp. It turns out unknown or in this case, unsigned processes shouldn't be touching.sh.ibus.genia.pg shouldn't be touching the keychain, right? These are behavioral alerts that literally any of us can write. The other reason we detected this is because we're fanatical about visibility. We treat endpoints that don't have security tooling like endpoints that have unpatched major vulnerabilities, right? We focus heavily on 100% deployment of our visibility infrastructure and that I think pays dividends broadly. The other reason, so that's why we sort of detected it. That's how we detected it. The reason it was a 20 minutes to containment incident for us is because we're fanatical about practice, right? So the thing I tell the team all the time is if you can't do it drunk at 3am on Christmas morning, you can't do it. Flat out, right? We don't practice it like that, although there have been some proposals. But seriously, this means playbooks. This means practicing. This means knowing your tools. This means finding the edge cases, finding the bugs in practice before you find the bugs in reality. I was in the military for about a decade and the saying we had was the more you bleed in practice, the less you bleed in war, right? Same concept here, right? The more problems and bugs and just things you find in practice, the fewer you're going to find when it actually counts and it's 3am on Christmas morning and you're drunk. Because that's not when you want to find bugs, right? The last thing and really this is more in the lessons learned side is that if anyone in cryptocurrency was laboring under the impression that an O day is not actually in your threat model and I will upfront say for most organizations, O day is not probably not in the threat model. If you're in cryptocurrency, O days are in your threat model. If you're not already planning for it, you should be today and you should already have been. And this means, right? When you're talking about O days, we're talking about layered defenses. We're talking about consistency. We're talking about high quality execution, playbooks, practice, making sure that you know what to do and can do it at a moment's notice. Or you can do it when someone's on vacation or we can do it when two people are on vacation, right? Without calling that person in the beach in Hawaii and saying, Hey, can you respond to an incident? Because no one is at their best responding to an incident on a beach in Hawaii. I promise you. A couple other things I'll highlight. And I think I'm blasted through this and I'm going to not delay the rest of the stuff too much. A couple other things I will highlight is interesting here. The use of personal email was particularly interesting as what the attacker targeted. The intent was clearly to bypass controls on corporate email. Great, that makes sense. The consequence, though, was that we saw several cases where targeted individuals felt prey and downloaded everything and compromised their personal endpoints in addition to potentially corporate endpoints, right? From a corporate incident response perspective, this is a big problem for me, right? Not only do I lack visibility on those endpoints, it's not always totally clear that the user even is going to know that they're compromised, right? And for most people, not everyone has great hygiene about separating work from private life. Even if they do, that kind of access can be leveraged in follow on phishing campaigns that will be much more effective as they're coming from these personal well-known email addresses as opposed to something else, right? So that I think is an interesting thing. Again, we talk about this in red teaming a lot, right? An actual red team can't go target your personal life. An actual attacker probably prefers to, right? Because of lack of controls. With that, I'm going to leave about 10 minutes for questions. I hope it's been useful. What I've tried to do, tried to leave you guys with is sort of a view into this actor. They are an actor to watch. Go read the blog post. Reference the reporting. If you can read Japanese, that's even better. If not, I'm sure it's going to get translated at some point soon. If you're in cryptocurrency, you should be looking at this actor, and then just a few notes on practice, practice, practice. I think security is about execution or anything else, right? With that, happy to have your questions and thank you all for your attention. And sorry for the AV issues. Go ahead. So I think instead of the very, very beginning, it's hide seven, HYD7. HYDSE, the word seven, that's what the Japanese reporting calls it. We track it as, we don't use the fancy names, we use just numbers. We track it as crypto three. Which one? HYDSEV. Yep. No, it was not. There was almost no use of obfuscation, at least on the JavaScript guide in these attacks, which is nice because then we're able to do things like look at the structure of the JavaScript and like make draw conclusions or at least form opinions on that stuff. Yep. Yep. No, it is not. Yep. Um, how do you mean generalized attack? So, so I would say it's part of their, yeah. Oh, yeah, yeah. So, so just to clarify, they, we saw no evidence of them going after the blockchain specific accounts. It was, it was all about email file storage. It was all about that stuff. Yeah. So this is clearly part of their post exploitation TTPs. Like this is just part of their playbook. It'll be my guess. Yes. I mean, they only delivered this O day to like five people. Just to be clear, right? This they started with 200. They wintered it down in the in the in the emails and they only picked about five to deliver the O day link to this was not mass exploitation. This was highly targeted. They were not they were not after your wallet. They were after they were after my wallet. Quite frankly, in the context of Coinbase. I don't know enough about how many mask stores data, but my guess is yes. No, so it was a it was a broad broad swath of cryptocurrency companies. So about 20 different companies were involved among the 200 people. We have relatively limited visibility into into some of this stuff. So we know we know they threw them at at least one of our users. We know they threw them at other users, not not at Coinbase as well. No, absolutely not. So because they're they're looking at browser token theft, right? So they're not stealing your credentials. They're stealing your session token. Right. So you've already logged in, even if two factors in place, it depends on your two factor, right? And when what what exactly are you using? So so they're not they're not like this isn't credential phishing. This isn't something where they're trying to impersonate you per se. They're on your they're on your system. They can steal your session tokens. They can they can steal your cookies. They can impersonate you in that way. But even more than that, right? They're they're more than likely had we let this intrusion continue what we what we would have seen was internal network pivoting and seeking out internal systems documentation, like fairly standard post exploitation stuff for a group like that. Sir, I don't know. We think we think there are attacks we can we can attribute back opensource tax we can attribute back to them back to 2016 or so. We think they did the coin check breach. In this attack, my guess is if they bought that Oday, they spent between half a million dollars and a million dollars on that, depending on lots of factors. But like I said, this this group is I think under researched, and there's not enough light on them really from to have for me to be able to say, sir, in regard to traffic phillips to work with. We do. So I mean, a when this happened, we went public with it immediately, shared the hashers, actually the IPs. And and we look, I'm not I'm not Mandy, I'm not CrowdStrike. I make no money from having private threat intelligence, right? I get I derive all my benefit from sharing this intelligence as widely as humanly possible. So hence, hence this basically, and hence, hence the work we do directly with with other cryptocurrency organizations. Yeah, sir. Yeah. Well, in this attack, I don't believe I don't believe they made any money on this attack, although I could be wrong. There may have been other organizations that lost the lost funds to them in some way or shape or form. So so in this attack, they again, this is this is my guess. I'm guessing they spent between half a million and a million dollars putting this together. So this was this was a loss to them. But if they were the ones to the coin check breach, they got away with about, I think it was $500 million in NEM, the sum of which they were actually able to convert and take take with them. They've been active in cryptocurrency so long that my my assumption is they're essentially self funding at this point. And like the million dollars they lost here was like, we took a swing, we failed, we'll do it next time. Yes. Can you share any details about your run after you got the alert, how you responded to it, especially when there's so many potential things were such a good one? Yeah, so so fortunately, the attack was highly targeted, it ended up on one one endpoint, right? So that we were able to a go the general shape of that is we went we went broad and then deep, we said, okay, here are the indicators, here's the malware, here's the hashers, here's the IPs. Is this present anywhere else in our in our entire ecosystem? No, outstanding. Let's take it, let's take a much deeper look at this. So we were able then to pull the endpoint logs and say, okay, what files did these processes touch, which is which is how we can gain certainty on like what they were getting access to before we quarantine the machine. And then based on that, we said, okay, they probably got these things, we don't know if they exfiltrated the data or not before we quarantine. So it's just roll all those credits. And and move on from there. We were also able, thanks to some quick action from the incident response team, to this is how we pulled the OD code directly from the site, right before they knew we were responding, we detected and were responding, we're able to set up a pre existing VM analysis VM infrastructure with with burp sitting in front of all the connections, go pretend to get exploited, just like the same user is clicking on it from another device, basically. And it happily tried to re exploit us, we happily snagged the the zero day from there. And then report the Firefox, actually, I forgot to give Firefox a shout out, they were incredibly, incredibly great in this entire process. They got the first they got the the the the first day was patched the the the same date note the next day. The second OD was passed the same week. The first one they'd already been working on fix on the second one, they, they, they went from never before hearing of this thing to shipping a patch in under a week, right? Very, very impressive. They were they were a joy to work with. Sir, yeah, we're gonna share the slides later. And then, of course, we have, we were ripple and and us like happy to happy to share whatever else you want to you want to hear afterwards. Yep, right. I actually don't want to share that quite frankly. So so the the we do use an MSP for for tier one. We also do independent detection on that same data feed for for stuff that we feel is more targeted to us. Maybe maybe last question. Or no. Outstanding. Thank you all very much.