Audited. Formally Verified. Totally Compromised | Diogo Pereira - Hedera

as part of normal treasury operations and essentially attackers compromised the safe wallet UI and we and targeted the by bits routine operations to then drain the call wallet funds. Just a few stats about this uh this this hack. The attack happened last year between the 4th and 21st of February. Approximately$ 1.5 billion dollars have been lost.

401ks dispersed across intermediary addresses were stolen. And the track actor is a North Korean linked linked group that is called Lazarus group. They have been quite uh successful in uh leveraging web three projects for their own benefit. Just a few numbers here to see the impact of this hack. So the buy bit exploit alone was profited more than half from the total crypto wise in 2024 and almost half for 2025.

That's a very very impactful hack and uh I think these numbers give you this perspective as well. regarding the hack anatomy how attackers exactly proceeded to to compromise by a bit. So first the hackers compromised the safe wallet develop developer laptop and they did this via social engineering. With this initial foothold they were able to get access to the AWS token session and with this they gained permission to do operations on their own infrastructure. The S3 buckets that they found was used to be as a work as a CDN to deliver the front-end assets of safe UI to the users.

And essentially from the window of when the attack happened, everyone that was visiting safe UI wallet was also downloading the malicious JavaScript that they uh used to that they uploaded in the S3 bucket to be delivered for their front end. However, the code was lying dormant there. It was waiting for the right time so that when by bits transaction routine operation was going through they knew exactly the target address that they were using and the JavaScript triggered and the tip the users by changing the UI to not show the what was exactly being signed as malicious but uh something else that appear uh normal. One thing that I would like to highlight here is that we mainly see web two related mechanism for attacks. Of course, they they leveraged their attack to then um uh to then um manage the smart contract proxies and so on, but it was it with the right permissions, they didn't uh do anything that broke the logic, right?

They used as they used it legitimately. So most of the vectors we see here is web two related. Now let's take a step back. When we build a web3 project, usually these kind of projects they are quite complex. They they are working in the scope of distributed systems.

Blockchain has a bunch of concepts that are not uh uh very easy to understand and they take some work and some practice to get acquainted to those concepts. So but when we when we get engineers to engineer this software and make it run on the web three the attack surface of that specific project is only on where it runs which is the blockchain. Plus complex projects serve nothing if they don't don't have any users to use it, right? Because we have to because it's it's basically complex stuff and we we have to make it easy for improve usability so that the users can use this project our project. So we come up with a bunch of tools to name a few SDKs, wallets, dabs, third party dependencies are already here just to make to name a few and all of them work together to improve the usability of our web three projects.

Now one thing worth mentioning is because all these components are connected now attackers attackers can can just target the lower hanging fruits. They can uh manage to just target the weakest link of of this whole environment and the whole component dependency graph here. Now reframing this this diagram to the buy bit hack. We got the web two scope the web three scope on the web two we have our safe UI wallet and the web three we got their smart contract running on the blockchain and as we saw earlier it's it's connected because we need this connection for usability purposes as I mentioned earlier. Now we got our attack the attacker there from Lazarus group and as we saw also earlier they injected the JavaScript into the S3 bucket.

Uh but that was not the actual exploit right that was just part of a whole chain of attack. What they exactly leveraged was this bridge here. And what is this bridge? This bridge is a semantic gap. It's basically how data is presented and interpreted by end users on the web two scope and how data is represented at the bite level for blockchain transactions on the web three scope.

So the blockchain executed exactly what was signed. The problem was that users signed something they couldn't reliably understand. Now as uh one month ago there was another attack that uh shows that attackers and threat actors they keep leveraging this this uh this semantic gap that exists between the two scopes where this attack was an address poisoning attack. And as a fun exercise I um just for a bit a bit of background address poisoning attack means we are trying to compute an address whose three first characters and last three characters of the address are the same as the victim's wallet uh destination destination wallet that they want to transfer funds to. And the probability to get these rights is bigger than to win the lottery.

Plus the profit is probably the same or much higher as we saw. So of course attackers will continue to leverage this semantic gap and keep uh uh attacking our projects because they have huge gains, huge motive, huge incentive. Right now I wanted to reference a few other entities of our industry that highlight exactly this problem. Certic on their hack 2025 report they say that supply chain was the most costly attack vector representing almost half of the total amount stolen in 2025. Plus fishing compromises followed being the attack vector with the highest number of incidents slightly above code vulnerabilities which is where we have our smart contracts usually being categorized when they get also incidents.

And lastly, Open Zeppelin in a blog they said when we talk about web3 security smart contract vulnerabilities tend to dominate the whole conversation. However, unlike smart contracts which operate within the EVM constraint as we saw earlier a single exploit in the blockchain whole infrastructure can the entire network leading to downtime and loss of funds. Now what can we do about it? What are some of the small steps we can take that gain us and le uh that we can leverage for the highest defensive capability? Right, let's go through a few on the protocol domain.

Do not neglect human factor when developing your web3 project. There is a good example of this. Despite supporting EVM address equivalence natively, it tries to shrink the semantic gap that we saw earlier by having the following. We have a consistent uniform entity ID format. For instance, accounts, they have this specific format of shard number, realm number, and account number.

And it's all base 10. It's way easier to understand, way uh more human friendly than B 16. We also have self-describing transaction ids. So a transaction is composed of the payer account with a format we saw earlier at a valid start time stamp. And finally, HIPP 15 introduced an optional fivelet checksum.

So like when users want to transfer their funds, they can input a check sum which helps them validate that they introduced the right number of the accounts that it gives them power in a way to keep being safe when managing their wallet. On the supply chain domain, we got a few as well. Dependency colons, I think it's one of the biggest wins. What it means is that there's a delay between dependency updates and its adoption on your project. So let's say you have a 48 hour dependency colon.

It means that all the dependencies that are updated within that uh that uh threshold your project is is not going to play to those versions. It will wait it will wait 48 hours. And this gives us room to if any incident, any alert happens, it will basically make us have time to to respond. Another one is log files for your projects and for the dependencies of the dependencies of the dependencies, right? Because what these do is they record exact dependency version instead of having ranges there.

So every time you build your project, you have the exact dependencies that you want it to build upon. And it's not just important this for your project but the projects you depend on and you fetch from the registries they also need to have a log file or otherwise when you build them they they will they will also make your compromise your your project because of the dependency graph version pinning is another example to lock the software the on this example I have the GitHub actions where on the first scenario we have v35 and this is flexible right if the minor versions change, you will automatically fetch the latest version. And on the other scenario, we got a a sham of the version of the exact version we want to use. And finally, scope packages, which is more on the npm native uh npm registry native scope. And these restrict dependencies uh in a way that okay let's say you have a project and you set the package name to just a string and usually in in in our companies we have multiple projects multiple internal projects.

Your project might be the dependency on when you build it on on the future of another project. And if you set a name that is not scoped that has not a name space then any attacker can register this name and whenever you build your project it will fetch the registry first. So it will inject your project with malicious code and not your dependency. So as a good practice always scoping your package names. It's good even if it's not a dependency because in the future it might be.

And these controls don't stop change right? They just make change intentionally intentional and observable on the fishing domain. So one thing that I like to say and to highlight is that hackers they are not some very special species in a way they are just like us. They are builders. They are engineers.

They have the same background. The difference is the questions they ask and how they focus their energy. When you're building something, we are asking how can we build this to make sure the requirements are there, our user use cases are are according and mirror mirroring exactly what we implement. But as a hacker, you are asking how can I break this? Is there a workaround?

And because this these people, they ask different questions, they get different results. But usually we're kind of the same. So adopting a hacker's mindset can help you as well when you're building your project. Be skeptical. If something is too good to be true, it probably is.

We've seen this when uh we have uh um people reaching out to candidates and they they send a take-home challenge, but it's it's uh it's not legit is malware. Trust, but always verify. And in the end, you are the last line of defense of your whole project. Because even if you have the most hardened web three system running, in the end, attackers can always try to bribe your employees, try to leverage your interests and make you execute malicious code that you didn't intend to, and that can compromise your project as we saw it by bit. Another one is ownership attitude.

This alone is so easy to scale because it helps and has ex an extended coverage because users turn from passive executors to active defenders. It reduces the fishing success, promotes verification and accountability. And finally, a proactive mindset. This encourages early questioning validation and you are you have time to strategize. You don't you are not running and being reactive and not and just trying to fix the holes, right?

You have time to think. Ultimately, every contributor is a security enabler and becomes part of the security chain on the team's domain really. Okay. So it's over. Okay.

So pretty quick. We don't have time to go through this, but uh just to if there's one thing that I want to go you to go uh one message to take home from this session is to be a bit more like Neo from the matrix. just load some security uh some security skills now with AI is very easy and you can leverage yourself to also account for security on your own projects pretty quick. There's some header bounty tracks that you can go on our boot with some prizes. Please check this that as well.

And we also have another CTF $3k still on the price. And finally, thank you all so much. Thanks Ashgraph and thanks my team for helping and supporting on this session. Thank you so much.