ETHMilan26 - How North Korea Tried to Hack Me

Transcript

Thank you. Okay, Milano. I'm happy to be here. Let's get started. So, yeah, just a little correction on the slides or on the agenda. It says they tried to hack me. Um, they succeeded as we will very quickly find out. So, yeah, I was hacked by North Korea. Um, we'll be discussing a little bit about the landscape, more specifically the Lazarus group and the manners in which they operate, as well as how the various attacks have gotten significantly more sophisticated over the years. So, first up, a little bit about me. Who am I? I've been a tech nerd from as far back as I can remember.

I started mining Ethereum back in 2017, back when mining was actually commercially viable on a GPU at your house. Um, I've been a blockchain dev since 2021, having worn many hats in the space, been a protocol dev, a bit of R&D, DevOps, project management, and engineering lead. Today, I'm working at Enidium where we're building a new blockchain trying to scale to 1 million transactions per second. So, some of you might remember me. Two years ago, I was at Ethan and as you can see, the name was crossed out. Someone wasn't able to to show up and I volunteered to go on stage. So hopefully this time around things are prepared a little bit better and we can we can have a good session.

So I wanted to start out with a icebreaker but I thought you guys are looking at it. So yeah, why should you listen to me? I made the mistake so that you guys don't have to. The red flags were obvious maybe more so in hindsight and attacks today are significantly more sophisticated than the one I'll be chatting to you about. Uh just a little bit of context what I'm sharing today happened about 3 years ago. Um and then also AI has killed the bad grammatell making things a lot more difficult with impersonations etc. And then of course social engineering is evolving far faster than our defenses are able to.

So what was about to happen? The la little that I know, the Lazarus group that had been planning for a while and targeted me as a blockchain engineer at a centralized exchange had the goal of compromising my device and pivoting to hopefully extract private keys to get money to fund their regime. I was job hunting which put took my blinders down a little bit and I wasn't as cautious as what I should have been. But let's discuss the red flags in a bit more detail. So, someone first point of contact, I was reached out to by an individual called Young. Um, he said, "Hey, Ben, I'm a tech manager. Insert large company name. Your profile has caught our our attention and we would

like to chat." So, red flag number one, reaching out on Telegram. Not that I would consider this too extreme, but usually recruiters would reach out via more formal means of communication via LinkedIn, via email, and once there's been that initial chat, then you could switch over to Telegram for a bit quicker um means of communications. Secondly, it was a Friday afternoon, mid-after afternoon time. I was in Europe. I was in Italy and the communication that I was having was in Hong Kong. that time it was already quite late in the evening and who's going to be working on a Friday evening.

That being said, Hong being Hong Kong, I thought maybe it's the 996 culture. So, I didn't think too much about it. The the individual, Mr. Young, he was quite busy at the time. So, he said, "Okay, cool. Let's fasttrack things. Let's keep it async." Um, so there was no call. We briefly discussed my experiences. I didn't think too much of this. oftentimes um protocols or companies to ensure that they're interviewing talented individuals and that they're actually technically capable, they just jump straight into technical challenges and if you don't pass that, cool. We're not going to waste our time. If you do, great stuff.

Let's take things from there. Then the sense of urgency being Friday afternoon, I thought to myself, well, a I would rather be doing this over the weekend, have a bit more time, be a bit more relaxed. It's been a busy week. Also doing it on my own device, ideally in an isolated environment. So I said, "Cool, I'll do it. A little bit busy." I could immediately notice that there was a bit of tension and that it was a lot more urgent from their side. But again, I didn't think too much of this. He provided me with a technical challenge.

And interestingly, yet another red flag, no deadline. Usually with technical challenges, it's always, "Okay, cool. you've got an hour to do this or you've got a weekend to do the project. And this was just here's the file. When you've done it, done it. Let me know. Cool. Cheers. Bye. So, curiosity killed the cat. He had shared the link with me. And although I was still on my work device, I thought it's just the link like let's have a look on our browser. Surely that doesn't cross the personal device um workplace rules. Did that open the link and I noticed that it was a Google Drive link. There's a zip file inside. It had been marketed or advertised as a arbitrage bot um system and there were some bugs in it

that I had to fix before sharing it with them. I downloaded the zip file. Google did its little scanning this file. Cool. No problems. I thought security right? What could go wrong? I opened the individual files. It was about 10 or 12 Python files inside of the file in a text editor as to ensure that um nothing was executed on my device. taking a little bit of precautionary measures. I did a quick skim through the device through the device through the code. This was before I could just ask my claude code session, hey, please scan this and tell me if there's any anything that catches your attention. That being said, all in all, it looked like everything was more or less okay.

However, I did notice an encrypted string. I decrypted this a string, found a link, tried accessing the link via my browser, wasn't able to get to it. So of course curiosity having killed the cat time to open the project in my IDE again my ID warned me saying do you trust this code I said no and we take things a step further so jumping through the various stages of the Lazarus attack stage one initial compromise I'd already downloaded the file or the project I'd open it up on my computer and now after investigation I ran main.py Pi. The output said that it had ex it hadn't executed. And of course, this was the

technical challenge. The code didn't work. I had to make it work. But little did I know a subprocess had spawned which had downloaded a file in the background. Um, but not just having downloaded the file, it also did a bit of cleanup so that I wouldn't be aware that this file had been downloaded. We move over to stage one, the dropper. Again, this now downloaded script that wasn't originally contained downloaded an additional script which also obiscated and hid in my system files. Then moving over to the payload. So the second file what its job and responsibility was was to launch a scrambled file so that the antivirus wasn't able to detect that there was anything happening communicate with the

attacker servers and to then have the payload executed directly in my RAM bypassing any um investigation by antivirus. Then they needed the loader. If I restarted my device, how would they be able to ensure that next time it starts up that they're still able to access things? So what they did is they tied it to the Discord binary which resulted in every time your computer starts Discord successfully starts and before that's happening they're injecting their little code. But now the interesting part is the injecting code that they're loading it never gets loaded onto the disk. It gets pushed directly into your memory.

So there's no way for the antivirus system to detect it either. So, of course, things couldn't get more unlucky than what they did. And it was time to open Discord to see what the Cosmos devs had replied. And little did I know, this is when I actually triggered the virus to attack me. With Discord now open, or trying to open, should I rather say, I got the elastic notification popping up. Direct memory injection. Whoops. A few seconds later, it messaged me. What have you done? I said I downloaded a file from the internet and that I had proceeded to execute it. Being a Friday afternoon, they just said, "Okay, cool.

Share it with us. We'll chat on Monday." So that's what I did. Monday came, they investigated the the the zip file or the project that I had shared with them and they were perplexed. There was nothing wrong with what they had seen. It seemed completely innocent, confused and frustrated. They told me like surely like is are you sure this is what you downloaded? I said 100%. But fortunately for me, I'd shared a screenshot where I shown the download and I downloaded the zip twice. The second zip, of course, not having had the cleanup code run and subsequently being untouched. I then shared that with them for them to proceed with their further investigation. And that's when they started realizing the severity of what

had actually happened. The last step, the payload step, is when my device was fully compromised and when all of the files on my disc could be read, when they could be written, they could be deleted. And furthermore, the password manager that I was used, if I had unlocked it during the 3, four days that they had access to my device, all of my passwords would be un or in sorry, decrypted in RAM for them to access. So, here's a little bit of the execution flow for those of you that are a bit more interested. Um the presentation slides are available in the app. As you'll see there's a little source in the bottom. Elastic did a very extensive article on this. As I highlighted, Lazarus has used this approach to attack not just me but many other um

individuals at centralized exchanges as well as other large D5 protocols. That being said, fortunately, due to very strict um security policies and vast radius controls where I was at, there was no damage done to the computer to the computer to the company and they didn't get away with any funds. So, lessons learned, take security seriously, not just as the individual, but also as the company. Additionally, companies shouldn't be skimping on security budgets. We're now in the age of agentic AI, which means more code is being shipped per day, increasing the total surface area and resulting in more cracks to be found and exploited. If you slip up, own it fast. The quicker we're

able to own this, the the greater we decrease the blast radius and the less damage is actually able to happen. Look for things out of place. In hindsight, there were a lot of red flags that I should have taken as warnings. Um but often times being human we try and think oh no but surely this is okay and we we proceed nonetheless and then pressure is not equal to professionalism. Recruiters are not going to say oh hey quickly download this run this blah blah blah blah blah just take your time be relaxed and be safe. So additionally we want to now discuss things a little bit further about the Lazarus group. Um okay sorry before we get to that has it happened again? Yes. Fortunately though, I've learned my lessons and I've protected

myself such that there haven't been any further compromises. But if we look at the various attacks performed by the Lazarus group over the last six years, we will notice a very alarming rate. In 2020 and 21, we see that their total hack crypto hacks within the year were less than 10%. Moving over then to more recently 2026 where we're not even halfway where the Lazarus group has accounted for 76% of the attacks and this has resulted in more than half a billion dollars of crypto being compromised.

Over here the Lazarus playbook, they're a nation state. They have been part of the North Korean government since at least 2009 and they operate extremely agile. They get in and get out as quickly as possible. They burn infrastructure very quickly. They've got multiple DNS's registered. They focus a lot on social engineering. They go as far as hacking people's LinkedIn accounts to try and then impersonate an individual that seems accreditable. So today's landscape. Additionally, we're going to talk about two of the more recent hacks. Um as many of you are aware, we had Drift Protocol's 285 million attack earlier in April this year. So what happened? very much like

you guys now. Drift was at an international conference. A quant fund approached them at this conference stating that they were interested in doing business with them and they started to proceed to build a relationship of trust. Um there were many back and forths. There was additional meetups in various countries at other conferences and they even went as far as depositing a million dollars into a vault to show that they could be trusted. So what actually happened? the being on Salana the drift protocol one of the largest projects by TVL um there was the necessity of having a two out of five quum when it came to any type of governance within the the protocol so what they did is they proceeded to have

um in Salana we also have what's called a durable non a durable nons is a transaction that can be signed in advance and it can be executed at a later point in time oftentimes week later uh weeks later without actually having access to being online Think of it like a banking check. You can write out the check, but until it's cashed, nothing's going to be happening with it. So, they tricked the uh various two out of five at least um of the individuals to blindly sign the transaction that way would then later execute which would give them full admin access to the protocol. Interestingly enough, two days after having had the two out of five cororum signing the transaction, the malicious transaction, um Drift actually went and changed things such that when

Cororum is voted on, there's no delay. There's immediately you have um the permissions that you want and yet again they went because the quorum rules had been changed and got two of the five to blindly sign the transaction again. So what had been happening in the meantime? In the meantime, they had uh created a token called CVT. The CVT token they controlled 80% of the supply for they created a small pool of about $500 with it. And they were um trading it to artificially create a price for it. They also had a oracle which they were in control of. And with this back and forth trading that they were doing, they were able to give the token an artificial value of $1. So now that they had the

pre-signed durable nonses, they went to action. First transaction executed asking for the approval of admin access. One second later, transaction number two approved. At that point in time, step one list the CVT token as a valid um uh collateral. And from there they went to deposit 500,000 tokens which had no value which the protocol now thought had the value of half a billion dollars. From there it was easy. They were in all that they had to do is post collateral into various pools and just drain them.

So they went on to drain at least 18 pools USDC, USDT, Salana, Ethereum, all of the big ones. And as you're aware, they got away with the $285 million. the hack that they did with regards to me. It was a question of days. Over here, we can see they were really, really patient and this took the course of six months. Next up, we've got Kulp Dow. Again, same month, rough month for the crypto industry. And yeah, interestingly enough, this was not a smart contract hack. Um, instead, what happened is KULP was using layer zero as their bridging protocol. And they needed to have um a DVN. And a deviian is a decentralized validator network and unfortunately against uh layer zero's

recommendations kelp decided to have a quorum of a single node. So if you can spoof the data that this node is seeing you can get the node to do what it wanted to. And in fact that's exactly what they did. So what they ended up doing is they infiltrated layer zero. They managed to replace the binaries on two of their RPC nodes and then they went to work. They knew that if they were able to do the other nodes RPC nodes that the only point of truth would be the nodes that they had compromised.

Furthermore, what happened is they were able to continue reporting fake data to layer zero such that they thought that everything was hunky dory whilst in fact what they had been doing is saying okay cool um being a bridge of course we need to have a burn and mint event. So, they were telling the protocol, "Okay, cool. We want to burn $292 million of RSF. Um, can you please mint it on the following chain?" And because their only source of truth was their spoof transactions, they were able to do so. That being said, um, the Kulp DA was able to respond very quickly, instantly, pausing their smart contracts as soon as what they were able

to, and this prevented an additional attempted drainage of $95 million. um crypto being as or DeFi being as connected as what it did resulted in the funds being bridged and then the collateral causing there to be a lot of other issues further downstream to at least 20 other protocols that we're aware of. So more lessons learned. Firstly, cororum design is security design. The whole point of blockchain is to be decentralized. And if you've got a single cororum, where's the decentralization? we might as well be running a single node blockchain at that point in time. Then audits don't cover offchain dependencies. We've been so focused on covering smart contracts and the security loopholes with them for the

past 10 years that we forget to look at the more obvious things our infrastructure the signing the RPCs etc. Then invariant monitoring is better than transaction monitoring. In both of these cases if we look at the individ individual transactions we will notice that there was nothing wrong with them. They had the governance, they had the approvals, everything was great. But for example, in the case of KULP, because there's a bridging transaction and the mint has to be equal to the burn. If we have a monitoring process which says, "Oh, hey, we're minting this, but there was no equivalent burn that had taken place, don't proceed or at least ring the alarm bells as soon as possible so that we can decrease the blast radius."

Then never sign blindly. The fact that we had two out of the five cor five five cor members blindly signing a transaction which gave them administrative rights that's something that should never have done the inter intervention window was small so in conclusion defenses have never been better we've got tees we've got zk proofs the list goes on attackers have been never be better either with agentic AI with LLMs impersonation has become significantly easier the cost asymmetry has flipped. It's a lot easier for hackers to spam hacks and it's becoming a lot more difficult for the industry to try and patch all of the various vulnerabilities. The hackers are growing at a significantly faster rate than what

we can protect ourselves at. Then default to paranoia for anything unsolicitated. In the case of um drift, it was six months of building trust. I mean, I think most of us in this room would have made that same same problem. But with regards to the kelp um issues, what we'd actually notice is besides having a one node corum from Kulp side, Kulp was never hacked. Culp was never exploited. It was the infrastructure. It was layer zero that had the infected binaries replaced. Then security culture beat security stack. If the technical individuals in the company aren't, I don't want to say paranoid, but at least security conscious when it comes to how are we writing this code? What are we thinking about in terms of security?

like are they fallbacks? What systems are in place? Like we really should have it as a as a culture and it should be a primary culture within the company. The next talk could be someone telling you their story. We're all one click, one signature, one trust assumption away. With me, the attack took a few days. With Drift, it took a couple months. And with Kalp, we saw multiple pieces of infrastructure that needed to be infiltrated. um attacks are just becoming more and more sophisticated. So, we need to do everything we can to protect ourselves. Additionally, we need to share these stories with one another.

Without sharing these stories, others won't necessarily need to fall and make the same mistakes that we've done. And in the case, you might end up on stage here just like me if you if you share your stories. That being said, thank you for your time and your attention. If you'd like to reach out, it's pretty simple. Benval for everything. DM at benvula.com. All my socials, Telegram, GitHub, LinkedIn, everything. Benvolart and then yeah, my website benvulf.com. Thank you.