Crypto hacks are no longer rare. In fact, they've become a grim rhythm in the blockchain industry each month seems to bring news of another project losing millions. From smart contract exploits to compromised private keys, the attack surface is enormous. The stakes are equally high: in some cases, a single vulnerability can result in losses exceeding billions overnight.
The sophistication of these attacks has outpaced what most developer teams can realistically defend against. A typical dev team is optimized for building features quickly, not for conducting adversarial threat modeling or penetration testing at nation-state levels. Add to this the sheer complexity of modern crypto applications which interact with dozens of external libraries, APIs, and user wallets, and you have a security landscape where even tiny oversights can have catastrophic outcomes.
This post shares insights from one such case: a real-world incident involving a multi-million heist. Due to NDA restrictions, I can't disclose every detail, but the client approved this write-up to help other teams understand the realities of defending high-value crypto systems.
The Emergency Call
Not long ago, we were approached by a crypto company in crisis. Their users' accounts had been drained of funds. A devastating situation, especially given the non-custodial nature of their application.
The situation was particularly difficult because the client's application was non-custodial. In a custodial exchange, the platform has visibility into transactions, balances, and often even user behavior. But in a non-custodial setup, users hold their own keys, and the app acts more like a facilitator. This meant we had almost no direct data to work with.
Our only initial signal came from support tickets and messages from users who noticed missing funds. There was no central database showing "who lost what and when".
First Steps: Contain and Understand
In any breach investigation, the first question is always:
Is the attack still ongoing?
If the answer is yes, containment becomes the top priority. Every minute lost could mean millions more disappearing. In this case, the initial analysis suggested that the exploit had occurred over a very short timeframe. By the time we were involved, the attack seemed to have already stopped.
That shifted the focus: instead of active defense, our job was now forensics. We had to figure out what happened, how, and how to prevent a repeat.
We began by asking the client to start collecting every possible detail about the affected users.
Even without personal data tracking, these fragments of information are invaluable. Cyber investigations often start like a jigsaw puzzle with half the pieces missing, where you have to build the picture slowly, starting with the clearest patterns.
Mapping Possible Attack Vectors
Our next step was to map out all possible attack vectors. When user funds disappear, there are dozens of potential explanations:
-
Cross-site scripting (XSS) or injection attacks on the application frontend.
-
Domain theft: The company's domain name was stolen, potentially allowing attackers to impersonate the site and trick users.
-
Smart contract exploit: Vulnerabilities in the smart contract code can be abused to drain funds, manipulate balances, or bypass intended restrictions.
-
DNS hijacking: Redirecting users to a fake frontend that drains wallets.
-
Private key compromise: Through phishing, malware, or insecure storage.
-
API exploits: If backend services mis-handle requests or authentication.
-
Dependency or supply chain attacks: A compromised NPM package or malicious update.
-
Rogue insiders or compromised developer accounts.
Each of these scenarios can look very different in practice. For example, if only one specific token was affected, that might suggest a smart contract flaw. If losses were random but linked to a certain app version, maybe the build pipeline was compromised.
We brainstormed and documented 20+ possible scenarios and then began the process of elimination, testing each hypothesis against the limited data we had.
The Investigation Grind
Investigations like this are part science, part art. Every lead was tested against what we knew from the support messages and transaction records.
Slowly, we narrowed it down. Three scenarios seemed plausible. We dove deeper into the client's codebase, which, like most production systems, was huge and multi-layered. Vulnerabilities are often buried in the "dark corners" of code, in modules written a long time ago and in details that very few people can recall.
After a lengthy, non-stop group research session, we filtered down to a single scenario that fit most of the observed evidence.
Aftermath of the attack
We always advise our clients' development teams to keep one thing in mind: while crypto and blockchain are exciting, innovative, and technically challenging environments, there is always someone out there who understands your stack better than you do and who has the resources, patience, and motivation to compromise even the most "reliable" third parties you rely on.
In other words: you cannot outsource responsibility for security.
Real defense starts with tools and audits but it is not enough; it should start with discipline and a commitment to continuous improvement. That discipline means:
-
Having at least one person on the team who truly understands security, and
-
Empowering them to make security concerns a priority that everyone must address.
Unfortunately, this is not the norm in many modern crypto companies. Too often, developers are left to decide on their own whether the code they've just written has security implications. That's a dangerous pattern. Security needs to be built into the culture, not left to individual discretion.
There is, however, another way. If a company does not yet have a dedicated "security champion" on the team, they can bring in an external partner to fill that role. A specialized security firm can integrate with the dev process, ensure operations continue smoothly, and at the same time raise security standards to the highest possible level. This is exactly what our team has done for clients in the past. Unfortunately, most of them only reach out after a serious incident has already occurred. The earlier security is prioritized, the less costly and painful it is to defend against inevitable attacks.
If your product is securing millions (or hundreds of millions or even billions), you have to assume that everything around it, whether it is dependencies, infrastructure, DNS, even your own CI/CD pipeline, could be compromised at any time. Teams that recognize this reality and act on it stand a far better chance of surviving the inevitable attempts against them.
So What Can Be Learned From This Incident?
Improving the security of a crypto product requires more than just patching vulnerabilities as they appear. It means building a system and culture that assumes attacks will happen, and preparing accordingly. From this case and many others, here are key takeaways:
-
Don't just focus on smart contracts. Map out every way your system could be attacked, from phishing campaigns and DNS hijacking to compromised dependencies or poisoned CI/CD pipelines. Attackers will look for the weakest link, not the most obvious one.
-
Audit, verify, and pin dependencies. Use monitoring tools to detect malicious package updates or suspicious modifications in libraries. The supply chain is one of the easiest paths for attackers into modern systems.
-
Even non-custodial apps can safely track aggregated signals such as app versions, wallet behavior anomalies, or suspicious transaction patterns. These data points provide critical early warning signs without violating user privacy.
-
Have at least one person formally responsible for raising and tracking security concerns and empower them to stop a release if necessary. Security should never be "optional" or left to developer discretion.
-
Security roles should be split across at least two individuals. Why? Because insider compromise is real. One person may get bribed or coerced into overlooking a critical issue. In the crypto world, offers in the hundreds of thousands are not hypothetical - they happen.
-
Discourage employees from openly advertising their role in your project on LinkedIn, Discord, or other public channels. Hacker groups actively scan for potential insider targets, and not everyone will reject a $500k offer. Protect your people, and by extension, your product.
The Real Goal
The ultimate goal isn't to make your system "unhackable" - that's impossible. The goal is to limit the blast radius when something inevitably goes wrong. Resilient systems ensure that one flaw doesn't escalate into catastrophic, company-ending losses.
Final Thoughts
Security is one of the most complex tasks in crypto. It often feels secondary right up until the moment a major incident happens. By then, it's usually too late.
Don't wait for things to go wrong. Hire motivated professionals who live and breathe security. If you cannot bring such people directly into your team, consider partnering with companies like ours to help you organize and elevate your security practices.
Here's what we can do for you:
-
Comprehensive code audits to ensure private keys are generated with reliable entropy sources and are never leaked through code or unsafe implementations.
-
Dependency and supply chain verification to confirm all libraries come from trusted sources, are up-to-date, and don't contain "unexpected code" or hidden exploits, which are increasingly common.
-
Secure build and deployment pipelines so your releases cannot be tampered with.
-
Code review process validation, making sure reviews are real, consistent, and in line with security best practices.
-
Dependency lifecycle management, removing outdated or abandoned packages that no longer receive security support.
-
API communication hardening, ensuring external integrations use strong protections against manipulation and "unexpected behaviors."
Unlike what many companies expect, our services don't cost "tens of thousands" just to get started. Our pricing is closer to the cost of hiring a senior developer, with the flexibility to expand depending on your needs. Our involvement can scale with your workload, whether that means full-time integration with your team or targeted support during critical phases.
Security is not a checkbox, and it's not a one-time expense. It's an ongoing discipline. With the right approach, and the right partners, you can protect your users, your assets, and your company's future.