# Sebastian Banescu - Drained Before any Code Exploit: The Non-Code Risks of Web3 - Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup) - Date: 2026-07-09 - Duration: 33:22 - Watch: https://streameth.org/watch/yt-9-Fc3YdGzjY - YouTube: https://www.youtube.com/watch?v=9-Fc3YdGzjY ## Description Most web3 losses don't start with a contract bug. They start with people, devices, recovery paths, signers, and admin controls. This talk maps the real attack chain behind modern drains and shows how users and teams can break it early. ## Transcript Thanks for everyone uh that joined this early talk. Um today I'm going to be talking about um you know things that get you hacked before the act like that lead to a hack before you're actually exploited. And for that we're going to address the three big elephants in the room. Um these are the three elephants. The big one I think the biggest one is operational security. And that has to do with people, right? People, humans are some of the weakest links. Everyone knows that. Uh but not just the human itself. Of course, it's the devices that they have that they bring to work. It's sort of the bring your own device policy. in pretty much every web free company and people mix personal with work rellated information on their devices. This is this leads to issues um especially when they also use those devices to sign important transactions that move a lot of value. The second elephant in the room is vibe coding. And I just want to, you know, preface that with saying I'm not against using AI to code, but there's a difference between vibe coding and using AI properly and we're going to discuss that. And the third elephant um that I think was already pretty nicely addressed in the previous presentation um is AI audits. And again, I'm not against using AI for audits. I think it's a great compliment, but um they shouldn't be fully like humans shouldn't be fully replaced. So with that, let's jump in to the first elephant, which is OBSC. As I mentioned, it's about people and devices. So of course with people everyone knows the the social engineering attacks have been around since forever like even before the internet people were calling someone up and pretending to be someone else. Now with the internet it's getting more and more complex with social media interactions uh on serious platforms like LinkedIn uh or on less serious platforms. people are getting business on that those platforms and of course scammers are pretending to be people that they're not and uh exploiting key actors in certain organizations. Now, this combined with the fact that some people use social media and so on uh on their work laptops and sometimes they download things um that they shouldn't on on devices where they have keys uh amplifies this issue. And um you know this together with the fact that there are specific admin paths in every decentralized application also leads to damage and compromise. So, let's look at, you know, a real attack chain. This is something that you might be familiar with, but I'm not sure if it's, you know, um, clear to everyone. Most defenses, you know, they they try to break one of these these links here. So, the first step that an attacker would do is called OSENT, which is basically gathering intelligence about their target. So, they pick, let's say, a project. I'm going to have the the drift hack as a use case after this. But let's say they pick a project, right? Um and they figure out who are some of the key players, where are they going to the next conference, the next event, where do they hang out in their free time, how can I get to interact with them, what do they like, uh what do they dislike? Um and so on. That's that's Osit, right? They just gather intelligence pretty passively most of the time. And based on that intelligence, they decide when to act and performed the social engineering attack. The next step, which is either a message on LinkedIn, an email, um a telegram message, or even a phone call. And if you know the the target bites, they're in. If they don't if they don't bite, they try another way, right? It's not like they're going to give up after the first try. You have very wellfunded state actors like the Lazarus group who are not just going to give up after a first try. And I'm sure many of you have been targeted multiple times by this group because they're pretty much after everyone. After they manage to compromise someone via social engineering, they get to this point, the endpoint compromise. And the endpoint is a device basically a device that you have either your phone or a laptop or something else. Maybe it's a VM on AWS or something. Who knows? Whatever they they can get their hands on. And once they get their hands on it, they figure out what this device is being used for, what information it's storing, and if they can maybe take over that account and horizontally escalate in your organization or maybe even vertically escalate to hire a higher admin. And uh once the account is taken over, if that device has keys, they will steal the keys, drain wallets or even you know treasury wallets, not just personal wallets. and they will abuse any privileges that that account has in terms of like especially if it's an admin account they will you know maybe even try to let's say they compromise a developer then they use that developer's account to contact the CEO and ask the CEO for something using that developer's account so that's even harder for the CEO to distinguish from an external um attacker that is trying to do social engineering so imagine this chain applied in parallel to multiple uh employees of the same organization, right? And sometimes, you know, when they're maybe doing the account takeover, uh they take over someone's account and then they try to socially engineer someone else in that organization, right? Which makes it even harder. And at the end, the last step is, you know, they really strike and they drain some account. It could be a personal wallet. It could be a treasury wallet and so on. Now, as I mentioned, we're looking at the drift hack. This is a project uh which is not um on the EVM chains. It's a Solana project that got exploited um I think it was end of March, but um it was a big hack. It was somewhere around 200 million uh dollars worth of assets. And what was astonishing about this hack was that it was very well planned and it um basically lasted for more than half a year. The attackers met their victims at a conference um at a well-known conference in Singapore. They shook hands and they presented themselves as a potential customer and integrator and they said uh we want we we love your project. We want to build some we're building something that you know we can integrate with you. We want to deploy funds in your project. And they actually ended up after a couple of months deploying funds. So, as far as we know, the attacker here is a legitimate business partner. They deployed 1 million worth worth of assets into Drift and now they have like a good ongoing relationship, right? Every project wants to grow their TVL. And at some point, the attacker basically compromised one of the signers by sending them a code repo for something that they were cooking and they just wanted to hear their the opinion of someone from Drift if it's okay with them, right? So, they sent them a repo saying, "Hey, just check this out. I just want to get like a quick, you know, um, approval from your side. and they opened the the repo that had the malicious script in it. uh and they clicked I trust this repo and the malicious script was executed that compromised the signer's machine and later uh the the that signer was asked to do a signature but we all know I mean probably everyone has experienced this on hardware wallets when you get something to sign it asks you to do a blind signature and then you look at the message and it's all hex code you can't make anything out of it right and that's that's the point where you know due to not sufficiently performant UX people just sign it right they're just like okay I'm going to I don't know how how can I tell this apart from anything else they sign it and that gives more leverage that gave more leverage in this case to the attacker and that combined you know with uh nonsis on Solana which you know basically um allowed the attacker to delay the attack and not attack immediately. Then they realized you know we can escalate quickly from this point and at the point in time where the exploit was performed and the funds were transferred um there were no effective breaks circuit breakers cancellation mechanisms to stop that transfer. And making it even worse, after they detected using their monitoring system and others notified them about this, um the response that should have come from stable coin issuers such as USDC lagged for hours and hours on end until the attackers managed to actually get the funds out um and they were no longer freezable. Um, yeah, we need do need to give props to USDT here because they did manage to freeze a part of the funds that were stolen, but not everyone acts as quickly as they do. So, that's just one use case, one example of, you know, um, very sophisticated hack that took over 6 months um, to execute, not to plan, to execute, right? Um so in terms of hacks sophistication of code and and the attacker basically figuring out very difficult code patterns that's not the only problem. Obsec is something which in essence is not rocket science but I think we talked about this during uh the panel yesterday. You know people are lazy so it's hard to get right. Um, so you're you're going to get and you probably do get this on a daily basis. You have either fake VCs that want to fund your project or recruiters promising you, you know, 10x uh your salary for, I don't know, clean take bringing coffee or cleaning something. Um, you have journalists that want to interview because your project is so cool. Um, and all of these, you know, might be potential attackers and you just, you know, might not suspect it because you think like, ah, oh, someone likes my project, someone wants to, you know, do something about it. And, um, they don't necessarily strike immediately. So, they won't just, you know, some of them do, but, um, some of them wait for the right time. So, they set up a call with you in a week or two because they're also very busy attacking other people. Um, and they, you know, when you get on the call, they're like, "Oh my god, Google Meet doesn't work in my country. Can you please download this because it's much better?" Um, or things like that, right? And uh they definitely also, you know, using that osin step that I mentioned before, they figure out where you're traveling or when you're traveling and they also try to strike at those times when you're less vigilant, right? Um and the outcome is of course, you know, you just need to download one file and execute it. Um and that becomes the incident. So, one other thing that I wanted to touch upon here because a lot of people I think when the when the drift hack came out, one of the most common response that I've seen on X is people talking about why did they just have a two out of three or I don't know three out of five multisig, right? And the point is that this threshold, you know, it's a number. The higher the number, the in theory, the higher the number, the better the security. However, the problem is that if you don't have a good process behind that uh multi- signature wallet where you know people are not rushed, they don't share devices for signing and for coding and you don't have a proper review of what they're signing and they're just signing something blind and they cannot really make out what they're signing. And then if they cannot make out or if if something looks fishy, they cannot escalate to someone else to figure out what this is then that is not a proper multisig setup, right? So I think everyone is working hard to create better UX for multi-IG users and we've seen this is possible like one one like one of the first um applications I would say or or use cases where I saw finally you know a proper multi-IG message was this um Ethereum DAO fund. they have this funding round and and they had, you know, like users needed to to use their hardware wallet to sign um in order to get some voting tokens and so on >> and it was finally a proper message that you could see on your multi- on your on your hardware wallet as well, right? So, it was like, oh, this is this is possible. It's it's just that you know many applications don't bother creating those messages that look well you know you could read them on your hardware wallet display. It's possible it's difficult but definitely doable and more people should do that. And I think there's after these hacks there's way more effort put into creating better UX. The fastest way to lose money. That's that's one of my favorite slides. So, you know, whenever you're in an organization, you have a multi-IG wallet and someone out of the blue while you're traveling maybe or you're under pressure due to some deadline to just say, "Hey, just sign this quickly because I need it for whatever, you know, it's it's super urgent, the CEO will be super pissed if you don't do this." That's, you know, that's uh a basically a a stored loss event. Um because you know you should never sign something that you've not been properly briefed on before and uh don't trust that someone's going to get upset because someone else says so. So rule number one this blind side uh signing is definitely operational debt right and um it's um you know uh incident waiting to happen. The second rule is that um unreadable payloads are should be treated as suspicious always and you should always ask if someone sends you a transaction that you want to sign is like how can I verify this right and um whenever there's like pressure it's like oh don't don't don't worry about it it's good you know that's that's when the the quality of the review process matters the most And now on to the second elephant. Um, if you remember this was about the free elephants. The second elephant is vibe coding. And I want to make this distinction between using AI to code which is totally fine. The what what what I call vibe coding in this presentation is building something using AI that you do not understand. You do not understand the code. You see how it works. You try it out, you do smoke tests manually, but if you look into the code, it looks just unreadable and you're like, I have no idea how this actually works. And I've seen I've I've heard a lot of uh, you know, stories about this. So, this is this basically breaks it up into what good AI assisted engineering means and vibe coding. In both cases, the speed goes up, right? That's why people are using this because they want to ship quickly. But the big difference is that in the good engineering practice, the engineer still understands what the code is doing, right? And they take ownership of that code and they don't just say, "Oh, it's not my fault. Claude wrote it." Right? Like it not you were using Claude, so you wrote it. Right? Um, you don't you can't blame an AI. Um, you should take ownership of it, right? And you should be able to explain what Claude wrote because you prompted Claude to write that code. If you can't do that and you're still confident about the code even though you don't understand how it works, that's that's vibe coding. Just wanted to make this distinction. The big problem there is that you can't properly secure something that you don't understand. So mature teams that use AI to write code, they could always answer these four questions, right? What where does the value move in my code? What are the critical paths? What are the assumptions that really matter and who can stop like which role can stop a certain attack or a transfer at which time? Right? If you just, you know, yolo it, Vibe code, you hear things like, "Oh my god, awesome. It's finally compiled. No more errors. All the tests pass. Let's ship it. We'll clean it up later." And this happens a lot um in hackathons, right? Because people are under pressure. They want to ship something really quickly. The big problem there is that temporary code built during hackathons has this very annoying habit of becoming permanent and being able to hold value after a few months. You know, if you have a very successful hackathon project, it's going to, you know, hold real value as sooner than you think because people like it. They they want to use it. It promises high yield maybe. And that's all MVP debt or hackathon debt that all founders promise themselves that they will fix. But all the time or not all the time but most of the time that cleanup sprint never comes or it comes much later than the actual value arrives in their application and when they're actually targeted by attackers. And now the third elephant is AI audits. And again, I want to preface this. This is not an anti-AI talk. I'm actually like very much proAI. I think pretty much no one does full manual audits nowadays. Everyone uses an AI assisted audit. So, it's a great tool, but it shouldn't be a full substitute of a human audit, right? Um, I totally understand why why founders love AI audits, pure AI audits, because they're super fast, very cheap, close to zero, right? And instant, right? You don't have to wait a long time for them. So founders are already under pressure to ship fast. You know, we just talked about that with vibe coding and the market is moving. They want to be the first mover. And when you go at the end of that develop long development cycle and you want to launch it and you ask an auditor, hey, how much does it cost and when can you start? And they say, well, it's going to cost six figures and we can start in two months. You're like, oh my god, you know, we can't do that. Uh, that's that's way too late. So this AI pure AI audit that that what I mean here is just someone writes a prompt find all the bugs in this code and they attach the zip that you know is um it sounds modern sounds inevitable but we're not there yet and there's this hidden cost that such a review gives you a false confidence if the AI is not able to find something or it finds some things that are obviously false positives due to some you know um glitch. It gives you you know um this confidence to deploy on mainet uh which is totally you know should be totally avoided. Um most of the time you know the those those super cheap audits they end up being a very expensive mistake. So founders in the beginning when they're just starting they want to optimize their costs but um the important thing to keep in mind is that this this cheap review given to you by an LLM model which you know everyone has access to these days is going to maybe come back and bite you. Um a real audit is probably more expensive. It takes more time but it can actually influence launch decisions say hey you guys are not ready to launch yet. I we have you know unfortunately had situations with customers where exactly this happened. They came to us it was too expensive for them. They decided just to do an an AI scan using you know what state-of-the-art meant at that point in time and they launched and they got hacked. Now I'm not saying this will always happen. Sometimes you know uh the code is actually very properly written but in some cases it's not and you know false negatives that are missed basically vulnerabilities that are missed by the AI could end up costing you the entire project and all the hard work that you've put into it. Now AI is very good at some things and you know I'm not claiming to be an expert on AI but it's really good even for us auditors to get a fast summary about the project quickly ramp up on it um you know using AI has reduced ramp up time significantly and it's also improved the quality of ramp up significantly because before if you got a a repo and no document presentation, you were basically learning about you were reverse engineering the code as you were looking through it line by line. Nowadays, you could still put the code into an AI model and it will tell you what the code does before you actually jump and read the code line by line. That that's a a tremendous benefit. AI is very good at spotting existing patterns of course and I think like it also goes a bit beyond that with these new frontier models it can also reason um especially if the code base is relatively small. I think the issue becomes with if the context gets larger and larger, the codebase gets larger and larger, things will definitely be missed. But it's also great for developers in order to increase their test coverage to to write some really cool edge case tests and, you know, basically just improving their posture overall. Humans, I think, are still better at holding the entire messy system with all the context, maybe from like the BD guy and the PM and all the all the people they talk to on the kickoff call or even, you know, in in real life interactions in their head and um you know, figuring out what matters to that project and what doesn't, right? they're they're not going to dwell on something like oh the admin can change one parameter which I've heard from someone uh at this conference like you know things are being reported by LLMs like oh if the admin can change a significant parameter that can you know cause a lot of damage that's reported as a critical but of course you know um in some cases where the admin actually is properly secured has decent opsec that is not a critical Humans are also very you know they have this gut feeling of this doesn't seem right right I think I don't know if AI is there yet right I don't know if we can say AI has a gut feeling but um they can you know feel that something's wrong even before they spotted the bug and you know the line of code which is vulnerable and um you know I think the the business logic bugs the subtle bugs the the attack chains are still something that you know some humans are able to find I think also AI I can find some of them. But basically the the answer is a combination between the two. Not replacing humans with AI or just doing uh pure human audit. It's a combination. So you should do AI assisted audits and also combine them with advanced testing methodologies with such some of them are indicated here. So fuzzing is a very successful testing methodology that has been used for decades uh by large enterprises to find really important bugs and they're also being used by web free products or projects to find important bugs that humans miss because it just pounds the system with like millions or billions of possible inputs that would be inhumanly feasible u to do manually. Um and then you have formal methods. I think formal verification is something which doesn't always fit with u the project that you might have or it only fits for some functions that make sense. Form of verification has this issue of um you know combinatorial explosion if the code has a lot of loops and branches and therefore it typically works for code that either has a bounded number of iterations or no iterations maybe heavy math that is something that where formal verification shines. In other cases, you always have to bound the loops which might limit the you know real world use of that code right if you say I can only do five loop iterations you know the vulnerability might appear only at iteration number 42 and one other thing that I want to sort of like emphasize having a human auditor is is definitely better than just doing uh AI but sometimes I think, you know, like we at Adiver Labs think that having two human auditors actually even better because sometimes auditors have a bad day or they have like something in their lives. They maybe they're sick, maybe their, you know, cat is sick or who knows, right? And it's very difficult to detect that. and auditors maybe sometimes typically don't admit that I've had a bad day and I you know I couldn't really work on the the audit. So having two people is great because you have this, you know, um self or like or like peer check and you see like if one auditor is able to find a dozen findings before the other has found anything, there's something up, right? You should check with the other one to see if something's going on. and and we've had these situations in in our audits and this is one way we've been able to detect that something is wrong. I think if there were always just one auditor, you you wouldn't be able to to see if there's a difference and therefore you would say, okay, you know, this guy did his best, but maybe his best was not at his best, right? He was not in a in a good condition to do the audit. So make sure you know my my advice is make sure you follow the four eyes security principle and you have like at least two auditors on your on your audits. In conclusion, I want to talk about responsible security. So it's not just about auditing. You should also make sure you have opse right make sure your code is secure but also your ops should be secure. Make sure when you're launching everything has been fixed and verified by someone independently, not just that you got some issues and you fix them and no one actually verified if the fix maybe introduced other issues. Once you've launched, of course, my recommendation is to also have a bug bounty program, also to have real-time monitoring of issues and not just monitoring, but also an incident response plan such that if an alert comes from the monitoring system, you know exactly who needs to do what and not just for code issues, but also for ops issues. Here's a very short pre-launch checklist. So if the answer is vague to any of these questions, you're maybe a bit you're launching a bit too early, right? So try to understand and and explain how the value flows for your system, the key invariance, weird edge cases, where funds move. Right? This this is important with respect to the code. But then also with respect to your audit, make sure that there was a manual review combined with AI and that there was ideally more than one reviewer. There was more than just an AI scan done via the frontier models and the fixes that were implemented after the audit were verified. Um, finally for the operational side, make sure that you know you would be able to pause or upgrade something in case a vulnerability is discovered after launch. And then make sure you have someone on duty to respond to alerts. So there's, you know, companies like ours that offer, I mean, we we are starting to offer that, but like there are companies that offer um 247 monitoring and they're able to, you know, immediately respond and start a war room if something happens. and um you know have this incident response plan even for issues like duress where you know maybe some of the key players are kidnapped that happens very often in France around Paris. Um yeah, I think the the key takeaways from this talk are um the opposite of security is actually false confidence and this is very often given by AI in this day and age. So you know weak OPSSEAC is is is is problematic. Just fully relying on vibe coding or AI scans and not doing a proper audit is also problematic. And that's it. Sorry for being over time. I don't know.