The State of DeFi Security - 2025

DeFi Security Summit at Devconnect Argentina 2025 · November 2025 · 21:18

Peter Kacherginsky, blockchain threat researcher at BlockThreat, returns for a third year with a compact, data-driven overview of the state of DeFi security. He highlights how attackers are adapting and how defenders must respond, and closes with a look ahead at the countermeasures, tools and incident response practices DeFi teams will need against tomorrow's threats.

Speakers

Topics

From DeFi Security Summit at Devconnect Argentina 2025, hosted by DeFi Security Summit.

Transcript

All right. We're going to start this Argentina. >> All right. Welcome, welcome to the state of DeFi security. I'll talk a little fast. I'm trying to cram six different talks in this 20 minutes. So, bear with me, please. Uh my name is Peter Kachaginsky. Uh you're probably most familiar with my work on block thread uh thread intelligence newsletter uh and other projects that I've been involved in. So, today what are we going to discuss? As is now a tradition, we'll talk about D5 thread landscape, all the big attacks, lessons that we've seen from the last year. Uh, but we'll really try to focus on emerging D5 threats this time around because I really want to prevent the next buy bit. What is the signal that we've seen in the industry so far that we should learn from and

dodge the bullet in the future as well as future DeFi defenses that I'm really excited about. So, let's start with the DeFi threat landscape first. So first the good news uh the stolen private keys uh that went down significantly. We went from half a billion dollars lost to stolen private keys attack vector to around hund00 million. So whatever you guys are doing either moving funds from your private keys on your developers machines to multi-y please continue doing that. Uh price oracle manipulation that was the top smart contract exploit that we've seen in many many years time after time after time went out all the way down to fourth place. So even last year the total stolen funds was around 50 plus million but now we're down to

$30 million. That's all the good news I have time for today. But let's talk about the bad news. Uh the bad news is we've seen the emergence of two new attack vectors that did not even register on top 10 list in the past. And that is of course the multi-stick hijacking and rounding error uh vulnerabilities. So multi-sync hijacking of course are the type of exploits that we've seen unfortunately with the safe wallet/bybit compromise where uh the instance we had this year North Korean DPRK thread actors went in compromised the safe wallet front end to inject malicious payloads and after that they were able to subvert the key signing protocol for the bybit exchange and steal $ 1.5

billion which is insane. The most painful thing about that one is that we knew about that one just before the the buy bit compromise. We had radiant capital where attackers used a similar technique where they injected malicious payloads into multi-IG signing operation and they were able to subvert it the same way. It's just that this attack did not get enough publicity. People like Pikar Visaceio from Seal, they wrote tools and scripts for you to verify the transactions that you're signing. People writing simulation for the transactions. It's just that we did not adopt it as an industry. So pretty please make sure if you're using multi-IG do simulated transactions do use scripts from people like Pico Visaceio Pascal and others to make sure

that whatever you're signing in hardware wallets is legit. Rounding error I I don't think I can add too much more that was already covered at this conference. This is a very tricky attack class to to detect. we have to really understand the math behind all the contracts and especially the edge cases which normally we did not have time to really dig into. So in the interest of time let's dive into emerging DeFi threats. Those are the things that don't get too much attention. Those are the threats that do not have multi-billion or even multi-million hacks yet. And yet every single thread that I'm about to cover with you has the potential to become the next bite bit. So please pay attention and build defenses that I will recommend so we can avoid it alto together.

Okay, the first one that we'll cover is the watering hole contracts threat. This one is kind of tricky because this threat comes along the same time when we're seeing the emergence of a new class of attackers, the patient attacker. They don't just go in and smash and grab and steal funds the second they can get a chance to. No, they will sit there and wait until a sufficiently large whale or a target shows up and then and only then they will run the exploit. So the way it's usually executed, this is a sample proxy contract and an attacker finds a way to subvert it and there are variety of ways. There's a classic private key compromise or developer compromise, but also you can do things like uh take over uninitialized contracts or you can find

uh coal arbitrary call injection to be able to act on behalf of the protocol. Once that is done, your first in your first intuition is to smash and grab of course, but not these guys. What they do is they carefully wait until external users of this protocol show up and as we all do make infinite approvals to this protocol and then instead of targeting the project itself, they target users. And in fact, this attack vector makes it so much more attractive to compromise not large popular protocols, but a tiny ones where TVL is not that really large.

As long as a whale comes in and approves their funds to this watering hole contract, they will win. So, there was an excellent talk yesterday from Giannis at DDOP talking about one particular instance of the watering hole contract. Uh, I invite you to scan the QR code. I promise it's not malicious. opsec um but uh read about it but TLDDR is that this particular attacker was going around for months looking for uninitialized contracts initialize them with a back door and then carefully sitting and waiting.

Luckily we were able to find it three over three months after they started doing this. So it took three months to detect it and how lucky are we that nothing was stolen. a whale did not come in and Infinite approved hundreds of millions of dollars to this contract. Uh after that was detected luckily by someone who dug into an extra event that popped up. A seal came in uh ran a massive uh operation rescue operation. Attackers were still able to detect that someone is rescuing funds and take away $2 million which compared to the potential nuclearized bullet that we dodged here is nothing. So we got

extremely lucky here. A special case of this attack vector is the arbitrary call injection. It's very easy to detect when your contract is actually subverted or upgraded in some way. But if there is a vulnerability, an arbitrary call injection vulnerability when attacker can inject arbitrary calls to act on behalf of your contract. They can sit on this vulnerable exploit. In fact, there was a there was an exploit in previous years pop up all the time and only run it and expose themselves once the whale shows up. So once they see someone interesting then they will train. So what you should be doing if you are a protocol don't just monitor for events. You have to watch for unusual storage slots that suddenly pop

up in your protocol. If you see unexpected transactions on your protocol where for some reason your your contract is initializing transfers to some third party something that is not normally done look for those unusual transactions and alert on them. Then of course a big common advice to users do not infinite approve everything to your to whatever contracts you're interacting with. And if you do have to approve something try to limit it to some degree which is sane so you don't lose the uh the inconvenience of doing multiple approvals but you don't lose the whole thing.

Okay legacy contracts. So how many of you are familiar with the Lindy effect? So Lindy effect not too many. Lindy effect started out as a joke but pretty adopted by crypto industry at least a while back that basically says that the longer something was existing the more likely it's going to exist for that much time in the future but does it apply to security if something was not hacked for let's say 5 years can we guarantee that it's not going to get hacked for the next 5 years let's see if that applies so I did a quick quick analysis and I found 65 projects which have a significant enough code base which is five plus years old with at least $1 million TVO and I found 65 projects.

Between those 65 projects, I found $54 billion locked in there. And if you look at the actual list, you'll find a lot of usual suspects like Uniswap V2 and the AI V2 and of course the recent recently in the news balancer v2 as well. Of these projects, about 50% had a major security incident. And that's not surprising because when when I watch what is going on on chain, I constantly see attackers who are scanning the network, scanning blockchains with ever more sophisticated tools again and again to look for vulnerabilities, to look for deeper vulnerabilities which simply did not have capabilities to find before.

So this is what's left of the uh the Lindy restaurant from from the Lindy's effect. Now it's basically a bunch of discount stores completely abandoned and trashed. Uh, and that's there's there's a lesson there is that we got significantly better as an industry at finding smart contract vulnerabilities. We have much better tools and we have much better techniques at looking bugs. And you know what? So did attackers. But all those contracts from five or 10 years back, they simply did not have the same tool set, the same capabilities to perform the same level of assessment that we can do today. So I don't think Lady Effect applies. You should be extra careful. And just just picture that somewhat time travel with the foundry and the knowledge of all of these attack vectors back to the DAO

days. You know, you know about flashbots, you know about re-entry. Like people in the DAO times, they didn't even know re-entry existed. So what vulnerabilities are going to be uncovered in the future that that could be used to compromise these older contracts. So some recommendation if you're fork or pool or integration that you rely on older code monitor for exploits because the second the upstream code that gets exploited you are going to be next. Remove or isolate any dependencies. If you have some some project which hasn't been audited in five plus years isolate it somehow. There's a risk or if you're so inclined and you really depend on it why not run another audit on it. Make sure that it's on the same level as you are. If you're unis swap and you went through 24 code audits and you rely on

some project which wasn't audited in a decade, maybe do another audit. Okay. The other attack vector that we keep on dodging bullets again and again and again are supply chain attacks. So let's let's look at a traditional security instances. So this is the uh this is the message that popped up last year [clears throat] where someone found a vulnerability in open SSH. Everyone familiar Open SSH is basically the gateway to the majority of servers out there. And someone found that you know as I'm logging into this uh to the server that I just installed, it's taking a little long. I'm not sure why there's a delay. And once they started investigating, they saw there was a

carefully embedded back door. Um and as they were digging they started the whole incident response process. So the potential impact of this traditional security backdoor is that everything would get compromised everything. Luckily time to detect was 2 months and the furthest point that this this um back door got into was unstable branches of most uh Linux distros out there. So the real impact was none or unknown mostly people scrambling and uninstalling it. But the key thing is there's few months that these vulnerable not vulnerable but backdoor SSH clients sitting in all of those repos and no one noticed and noticed purely by accident

by some thank god some engineer doing an extra investigation and that brings us to web three supply chains. This is an instance from a few months back uh for the shyude warm. How many of you are familiar with the shy loot attack? Okay. [clears throat] The idea was that there was a actual war in Britain that was compromising hundreds and hundreds of npm packages. But the thing is it was specifically targeting the cryptocurrency industry where it was building wallet drainers.

Wallet drainers were embedded in those packages designed specifically to subvert uh crypto developers projects and so on. Uh the the only reason why this was discovered is that again we had a curious investigator like looking like hey my CI/CD is failing for some reason like there's there's some there's some environment variables that the npm package was not checking for so it was airing out the potential could have been a disaster mass crypto compromise less than 24 hours to detect massive bullet dodged the actual impact was just $1,000 and you know us as an industry We we came in and we said like those suckers

they they did this mass compromise and they only got away with $1,000. The thing is we shouldn't we shouldn't be really celebrating this because these guys they will be back and they will learn from their mistakes. It's like oh we messed up on this environment variable. Sure we'll fix that next time. We have the attack vector. We know the impact. So we will keep on trying. In fact over the last year we dodged at least four major bullets. We had the Salana Web3JS in December. We had Coinbase agent kit. We had Ripple SDK and of course Shy Holluted uh in recent months. So over and over again we keep on dodging these bullets. But I guarantee you that sooner or later if we don't pay attention and we don't build defenses against supply chains, one of

these bullets is going to make real damage. And in terms of the type of damage that you could look forward to, this is what the attackers are interested in. They're not interested in compromising some random package of some random project. No, they're going for the motherload. This is, if you're not familiar, this is the Nick L. Franklin. This is a DPRK thread actor that was involved in the Radiant Capital hack, in fact. And this guy was looking to subvert Open Zeppelin. They were looking for an inn to get inside Open Zeppelin and eventually compromise the most fundamental library in our ecosystem.

So, what can you do for this emerging threat? Well, protect your private keys. I don't want to see private keys sitting on your dev boxes in an un unencrypted environment variables or anything like that. I want you to protect your developer environment. Please do not deploy your master contract on the mainet from the same box you do telegram chats and emails and take interviews from DPRK, whatever else you're doing on your personal machines. For all of you VIP coders out there, it's a cesspool. Please be careful with those extensions because every other extension on especially on Vibe seems to be malware laced. So be very careful what you install and what verification checks you perform.

>> Harden your CI/CD. This is your last barrier. Maybe there's some unusual behavior and anomaly that you can scan for or detect both in your code and in thirdparty dependencies. And of course, pin your detection, pin your versions of the packages that you're using in your environment because I don't want you to be the first one to get the freshest package that just came out yesterday. The longer you can wait, the more there's a chance that whatever back door that was embedded in there would be detected. >> So far, we've been good at catching those things in one or two days. But look at that SSH bug. There was two months and no one was able to detect it.

>> Okay, this is my favorite section. I keep on I kept on missing it in past but these are the things I'm excited in defi defenses that I think will protect us not only against the threats of today but against the threats of the future. So defensive mev bots. So this is this is a sample snippet from the recent balancer hack. Uh the attacker deployed their exploit contract. They ran it at 7 7 a.m. 40 46 and 47 milliseconds. The second they did that, exactly one block later, a company called Bitfinding deployed a counter exploit. It took it took under a minute to figure out that

this is an exploit, this is a profitable exploit and deploy countermeasures. What these guys did next was insane. They were able to automatically figure out what is the vulnerability, what are the additional pools that may be vulnerable, and claw back a million dollars. It was not much, but it shows us the way. This is 1 million less that the attacker can get away with. The key in this discussion is defensive versus financial. So, financial bots also did their job in especially in the um in the balancer hack. You probably if you if you're following all these exploits, you probably heard of me bots like Coffee Babe that are constantly

hacking all of the exploits and then returning funds. But even now uh on bar chain there was a a traditional financial bot that clawed back $ 122.6 million from the balancer exploiter. So this works but would those bots ever try to intercept funds if it was not immediately profitable for them? If you are optimizing for profit will you save the protocol when the real question is is is this protocol going to survive. So that's why I think we need to start thinking about different a different type of incent financial incentives to to give funds to these to these operators of these defensive bots where they will save your protocol even at an immediate loss to them at a time

of the exploit knowing that there's some kind of bounty or some kind of reward they can expect in the future. So how do we create financial incentives for these defensive bots and others in the in the defense industry? I'm glad you asked. Let's talk about competitive incident response. So this is a sample incident timeline that I like to use. So we have pre-inccident where you try to find as many bugs as you can uh and hopefully patch them. We have the incident itself where this is t minus0 the the hack is happening. You're scrambling. Then you have t plus 15 minutes and this is the time you really have a 15-minute window.

whatever mitigations or containment actions that you can do. If you don't do it by 50 minutes mark, usually everything is gone. There's not much else you can do. And then of course one plus hours is when you can try to track down the attacker, maybe negotiate for the return of funds and so on so on. The thing is we have a lot of stuff in the pre-inccident portion. We have you know the immunifi and cantas and sherlocks and code arenas where you can crowdsource all of these security researchers who look for bugs. they compete. There's a lot there. On the one plus hour mark, we have Arkham Intel Marketplace, which isn't used as often as it should be, where you can put out a bounty to basically identify who is the attacker, what is the who's the owner of

the wallet. On the incident side, the best thing we've got so far is the safe harbor. And how many of you are familiar with SEAL's safe harbor? All right. Safe harbor is an agreement that very two protocols signed so far. So consider signing it. It's an agreement that you will not legally hold accountable white hats who try to save your ass in case your protocol is under attack. For those bitfinding other defensive bots, you promise not to sue them. In fact, I can encourage them with some kind of bounty. Please save my protocol. If you can intercept those funds, please do it.

The question is what's beyond that? There isn't much else. I propose that we create a new marketplace, a new marketplace for defensive protocols where for the incident we put out bounties to report a hack so that people are encouraged to build detection bots to tell you when the hack occurs. Uh we want to encourage defensive bots to allow you to intercept exploits. For the 50-minute mark, I want to put out bounties for root cause analysis. So you're not busy reverse engineering the protocol and the hack. you're busy managing the incident and allow all the people, all the security researchers in the world give you what exactly happened so you can focus on mitigations and

containment. Put out a bounty for the best containment action. How many times have you seen a protocol that could have paused their protocol and they just simply forgot about it were not aware and at last first to reveal attacker identity and maybe even successful asset recovery. So to summarize um here is the call to action to all of you Immutifies and canas out there. Stretch your muscle into this new domain of competitive instant response. For all of you DeFi protocols and all of you uh users and developers, grow awareness about emerging threats and make those dodge bullets continue being dodge bullets and not see another billion dollar hack. And for us as the industry, it was a very

tough year. We lost too much value, too many assets, and most importantly, too much trust. But we are strong. We are many. We know why we're fighting this good fight. And ultimately, we will prevail. So, unfortunately, I don't have too much time for questions, but if you find me outside, I'll be happy to discuss anything they have. Thank you. [applause]