Scariest hack in 2026...

The Drift Protocol hack is probably the scariest hack that's ever happened in my opinion in the Web3 ecosystem, even scarier than Bybit, which was technically six times larger than this hack. Let me explain. So, if you haven't seen it, Drift Protocol is a protocol on the Solana chain, and they were hacked for between 240 and 290 million dollars. A lot of money. Now, the actual root of the hack can be summed up by this tweet that the team sent was that the attack was enabled by a combination of a pre-signed durable nonce transactions, which I think a lot of blogs are over-indexing on. Don't really let that distract you. They basically signed a transaction and compromise of multiple signers' approvals, likely through targeted social engineering or transaction misrepresentation. So, the actual technical compromise here was it was a multi-sig compromise, not particularly technically interesting. Now, this is something we have seen in the past, and this is exactly what we saw with the Bybit hack. The playlist is pretty straightforward. Compromise people's computers, show them transactions that look good, but send bad data to the wallet. Nobody checks what the hell they're signing. — [snorts] — Step three, profit. Now, if this was the whole story, there's a lot of remediations we can do to help prevent against this, and yes, you know, probably a lot of things this team should have done. You know, hindsight's 20/20. But, what's really scary is how these devices were compromised. The Drift Protocol operated behind a two of three multi-sig, so all they needed was two approvals to send a transaction, and the hacker was able to craft a transaction and get access to two people's devices or two people signers and send a malicious transaction out of this multi-sig that had the admin functionality. And yes, the Drift team said that they were using hardware wallets, but if you've been watching my channel for some time, you know that doesn't matter if you're not checking what actually goes onto your hardware wallets. Now, like I was saying, there's a lot of remediations this team could do, and there are a lot of things they probably should have done to help prevent this because defense in depth is what's really important here. But, what's really terrifying about this hack is the way that these devices were compromised. Historically, meeting in person with a state-sponsored hacker was too dangerous for these hackers to do. So, what a lot of projects did to help mitigate that they were going to hire a hacker or work with a hacker was they would meet them in person, at an event, etc. These hackers met the Drift team in person. Drift contributors were approached by a group of individuals at a major crypto conference who presented as a quantitative trading firm looking to engage on the protocol. They were technically fluent, had a verifiable professional backgrounds, and were familiar with how Drift operated. So, the Drift team started working with this team, gaining the trust, the hackers sent the Drift team links, things to download, etc. The Drift team ran those things or downloaded those or did kind of all the bad stuff you're really not supposed to do, but a large part of it was because they had gained the trust of these users. But, the reason for this was because the Drift team had started to trust this other team because they were contributing, they were working together, and they started to believe what they were working on. Like I said, yes, they shouldn't be running the software, and you know, blah blah. But, this type of attack is becoming too common in the and still the fact that they met in person is quite terrifying because that means that meeting somebody in person isn't going to be the obstacle we historically thought it would be. So, this actually changes the game a lot more than you might think it would. What's also terrifying about this is the timeline. The timelines are getting longer and longer for these projects. The Drift Protocol hack was in the makings for over 6 months. It's actually kind of reminiscent of the XZ backdoor, where there was a GitHub user who was created who was actively contributing to this XZ project, which was a foundational tool in Linux. Actively contributing, actually being incredibly helpful for years up to the point where the maintainer said, "Hey, sure. Hey, you can take more control. Go ahead, and you can write more code. " And boom, that's when they strike. So, the reason that this is so terrifying is number one, meeting in person isn't quite the obstacle that we thought it is, although you still should do it. And number two, it's just kind of more proof that these timelines for these hackers are getting longer and longer. So, given all this, the question then becomes, what can we do? And I think there's actually two approaches to this answer. There is the nuanced, the smaller, individualistic answer, and then there's also the systemic answers that a lot of people tend to ignore, but I think is the more important thing we should always be looking at as security researchers and developers. Now, I'm going to explain the minute details, the minutia, oh oh, you could have done this, hindsight's 20/20, because there were a lot of things that this team could have done better. However, then I'm going to explain why this is a systemic issue, and there is a much broader problem that we're running into here. A lot of people will say, "Oh, we have solutions for this. " However, my response to that always is the default path must be the secure one. Write this down. Scream it from the top of your lungs. The default path must be the secure one. And what I mean by that is, for example, passwords. We all know you shouldn't reuse passwords. However, in practice, memorizing 10 bajillion passwords was infeasible. So, that's why we developed password managers and passkeys to make having unique passwords much easier to do. Security fatigue is a

real thing. In these scenarios, historically, we could 100% just blame people. Hey, you really need to just come up with 10,000 passwords and have them stored in your head or written down in somewhere safe cuz it's like we have a solution to this, but the systemic issue was that this default path was incredibly laborious. And so, we said, "Let's fix this at a systemic level. Let's do password managers. Let's do passkeys, etc. " And that has already proved to be much better. The default path must be the secure one. So, for each one of these minute issues, yes, the team should have taken the steps to prevent these, right? However, there's a systemic issue here. So, great. The crux of the issue is this blind signing or transaction misrepresentation or whatever you want. So, first of all, transaction misrepresentation has been an issue that I've been shouting about for quite some time. This is a little link to a video I made last year calling out the issue about how ridiculous it is that we are signing things on our hardware devices that nobody can read, and most people aren't even checking what they're signing. This is what I mean by, "Okay, cool. You have a hardware wallet, but if you don't know what the hell you're signing, it doesn't matter. " The summary of this transaction misrepresentation bit is that it's very easy for hackers to manipulate a small piece of call data or transaction data, send it to your hardware wallet, and you just kind of blindly sign it because it's so hard to verify what's on your hardware wallet. A lot of these transactions are very complex. It might be 20 pages of call data, where if a single character is off, you are going to send a malicious transaction. So, if you look at kind of this picture here, this is an example. This is a real Grid+ wallet. hardware wallet, and you need to verify that every single one of those characters is correct. So, if you're going through 2,000 characters and you accidentally think a seven is a one or a three is a B or who knows, and that was the character that ends up getting hacked, you're screwed. So, what a lot of people do today is they just don't bother checking, which is really bad. So, here is the Squads user interface. This is the multi-sig infrastructure that the Drift Protocol team used, and I'm going to show you what a transaction looks like for me just to create one of these multi-sig wallets, and you will understand the problem that I'm talking about with it being incredibly difficult to verify these transactions. So, I'm going to go ahead and confirm, and here's what shows up on my Phantom wallet. Uh a bunch of nonsense. How Okay. Um it looks like it's actually trying to decode this instruction data, and it's having a hard time. Oh, it literally it fixed itself in the middle of doing that. That's great. Phantom Phantom, I found a bug. But, so there's all this nonsense, and how are you going to verify that this actually is what you want to do? Now, as a security researcher, yes, what I have to do is I have to go through every single piece of data on here and double-check that it is correct, which is quite laborious and tedious and very annoying. And what's worse is that when this gets sent to my hardware wallet, it's going to be even longer and more horrendous for me to check. Uh and in the wallet, I can't even like really review the data in a good way, which is not good. So, if this UI was hacked or my machine was compromised, it would be very trivial for someone to make a malicious transaction and for you to sign it and you to think you were signing something good because it is very hard to decode that data. The good news is we are making a lot of progress on this. At least on the Ethereum side, we have ERC-8213, which I've created, which is specifically for technical users, and we have 7730 being worked on. Uh however, this hack on the Drift Protocol was in the Solana ecosystem. So, as of 10 minutes ago, I created a discussion to do basically the exact same thing, create an ERC-8213 and 7730 of the Solana ecosystem. But, the next piece is going to be, "Okay, throughout all of the interactions with the team, links were shared for projects, tools, and apps they claim to be building. " And if we scroll down in particular, there are some classic attacks that, you know, I've talked about on this channel as well. The first one being one contributor may have been compromised after cloning a code repository shared by the group under the guise of deploying a front end from their vault. On this channel, we have talked about Docker containers and dev containers. Pascal from the Seal team goes one step forward and says you should use Q Cubes OS, use VM, don't use any type of software when running software. Additionally, there were hacks historically where just opening a folder was good enough to compromise devices or run hooks. So, running code that you don't know is a bad thing and continues to be a bad thing. However, I know all of you watching this video have started to trust somebody a little bit. Maybe you just go ahead and install whatever they say to install, and boom, you get compromised. So, I think Pascal's note about, "Hey, maybe we should move to Cubes OS. " I actually think it's pretty good, and I think all operating systems should take this approach of running things in isolation, but that's a much broader issue. First off, just never do this. Second of all, use containers. Third of all, there is always advice of your signing device should be separate from your working device. So, for every single one of these missteps, there was some type of remediation or something this team could have done to help prevent it. But, what I'm saying is those steps, as of today

suck and are hard. A lot of people say, "Oh, we need to educate people more. " You know, I have hundreds of hours of Cipher and Updraft videos explaining, "Don't put your private key in plain text. " and I still get replied boys saying, "Oh, yo, it's fine if you're just smart. " No, the default path must be the secure path. If you're teaching people to export their private key and have it chill in plain text, you have done a bad thing by perpetuating that this is the default path. It is not. For blind signing, you have to check as of today, your call data. It sucks. It is what it is. Your signing device should be different from your working device. So, if your working device gets compromised, it doesn't matter for your signing device. Never ever run code that you have not vetted on any of your computers. And if you are going to do something like that, use Docker containers, dev containers, something like Qubes OS, some way to containerize your script to keep it isolated where it is. Arguably, don't do industry unless you're technical as hell. And that suck to say in the age of AI. Now, I think these remedia- these these immediate kind of oh, here's what you should have done are super easy to say. But, but again, I think we are taking the fundamental attribution error here, where it's our cognitive bias to under-emphasize the situational and environmental factors for the behavior of an actor while over-emphasizing dispositional or personality factors. Thank you, Wikipedia. But, basically, what I'm trying to say is we should look at the overall situation and fix that. So, at least in the meantime, please go to those ERCs and those discussions, bump them up because we can at least fix this situational issue that's been plaguing us for a decade of nobody knowing what the hell that they're signing. Otherwise, we're just going to keep seeing this every other week. Thanks. Bye.