Laxed Security Protocols Will Cause Huge Losses
How can an S3 Bucked cost over a Billion dollars?
One of the largest heists in history did not stem from a cutting-edge zero-day exploit or a clandestine nation-state operation using classified information. It hinged on something far more simple and entirely preventable: a misconfigured AWS S3 bucket. That was the critical piece required to steal over a billion dollars.
The largest crypto hack (and accompanying heist) in history
In this article we are going to detail how the cryptocurrency exchange Bybit’s pattern of negligence allowed attackers to make off with over a billion dollars. Something as simple as changing a JavaScript file stored on an AWS S3 bucket allowed the attackers to alter transaction details during crypto currency transaction signing. This allowed the redirecting of funds to attacker-controlled crypto wallets and the eventual stealing of 1.5 billion dollars.
Even more amazing was that within two minutes of the fraudulent transaction, a “clean” JavaScript files replaced the compromised ones in the S3 bucket and the evidence of tapering essentially vanished. The main cause of the breach was the exploiting of lax access controls on a cloud storage bucket.
A major state sponsored hacking group
Let’s take a step back for just a few paragraphs. This attack is attributed to the Lazarus group. Lazarus is known for a variety of major hacking attacks that have stemmed from various types of attacks: phishing, spear-phishing, fake job offers, and custom cross-platform malware such asWannaCry, AppleJeus to steal crypto, and PondRAT. They also have used supply-chain attacks in various software products: 3CX VoIP Software, VeraPort, and most recently Innorix file transfer software. All of these leveraged hacked software dependencies and then breached cloud systems through various vulnerabilities.
Some other past hacks this group has been identified in include:
They breached Sony’s network, stole terabytes of data, and wiped systems with wiper malware. Losses topped $35 million.
Targeting in 2016 the SWIFT banking system, stealing $81 million (aiming for $1 billion) from Bangladesh’s central bank. A mix of insider access and malware pulled it off — again, no direct AWS link, but a financial masterstroke.
WannaCry ransomware worm, leveraging an NSA-stolen EternalBlue exploit, infected 300,000+ computers across 150 countries.
A $625 million crypto heist from Axie Infinity’s blockchain bridge
Harmony Horizon Bridge $100 million crypto theft in which keys were compromised.
We must redefine what is safe (or secure)
The concept of a Safe{Wallet}, often just called “Safe,” is defined as an open-source, decentralized multi-signature, known as a multisig, wallet platform. This one in particular was built primarily for Ethereum and Ethereum-compatible blockchains. It is designed to enhance security for managing crypto assets by requiring multiple approvals for transactions, rather than relying on a single private key. This sounds very secure on the surface and, in theory, the concept should be infallible.
To put it in perspective, there are an estimated 50,000 Safe wallets manage $100 billion+ in assets in existence right now. Also, if Bybit could be fooled, what about the hundreds of other firms using it to safeguard their assets?
The attack chain in brief
Here is the sequence of the hack from what can be gathered from audits and reports:
Lazarus compromised a Safe{Wallet} developer’s machine, likely via phishing or malware.
This gave them access to credentials (an API key or token) for Safe{Wallet}’s AWS infrastructure, specifically an S3 bucket hosting the app.safe.global frontend.
On February 19, 2025, at 15:29:25 UTC, they replaced a benign JavaScript file in the S3 bucket with a malicious version. This code targeted Bybit’s wallet, activating during a transaction on February 21 at 14:13:35 UTC. (for more info on securing S3 buckets: 11 AWS S3 Security Leaks Hackers Look For))
The tampered file was served via AWS CloudFront, a CDN that caches S3 content globally,
Bybit’s signers loaded it. The JavaScript tricked them into approving a transaction that handed wallet control to the attackers.
The payload likely used document object model manipulation to mask a smart contract upgrade or delegate call. This allowed the siphoning of 400,000+ ETH and stETH.
Two minutes later, the S3 bucket was updated with a clean file — possibly by Lazarus to cover tracks or Safe{Wallet} reacting.
So based on this information, the Lazarus group followed their typical attack scheme. The developer’s machine was compromised by targeted phishing and/or malware and this leads to the question of proper endpoint protection and security training. Tokens are easily stollen and since no MFA was configured the single factor of authentication was easily exploited. Since the JavaScript file was changed and then changed back it appears as though no security operations center was monitoring the contents of the bucket.
Does My Bucket Have a Hole?
AWS S3 is a powerful storage solution, but there are many settings and misconfigurations that can expose data to hackers. The old saying "loose lips sink ships" applies here. These leaks can sink the ship!
When it comes to access, misconfigured access controls can lead to publicly accessible buckets which allow unauthorized users to view or modify data. Unencrypted data in transit or at rest exposes sensitive information to interception or theft. Leaving S3 buckets with default public access settings increases the risk of unintended exposure. Overly permissive policies, also known as weak policies, can grant excessive access to users or external entities.
Logging is extremely important. Failing to activate access logging makes it hard to track unauthorized access or detect breaches and it is important to note that logging is not turned on by default for S3 buckets. Buckets allowing “Everyone” or “Any AWS user” access invite exploitation by malicious actors. Versioning control for data inside a bucket is important since disabled or misconfigured versioning controls can lead to data loss or unauthorized rollbacks.
An insecure IAM integration can lead to poorly managed IAM roles or policies and when these are tied to an S3 bucket, they can escalate privileges unintentionally. Equally important is multifactor authentication (MFA). Not requiring MFA for bucket access leaves accounts vulnerable to credential theft. Meta data can often be as important as the data itself. Unprotected bucket metadata can reveal sensitive details about the bucket’s contents or structure. If an AWS Access Key or CloudFront API key is exposed, attackers could modify CloudFront settings, pointing it to their own malicious S3 bucket or injecting harmful content.
These are some products and practices that can help in the AWS world:
Always implement and use least privilege principles
Rotate and monitor IAM credentials
Enable and configure AWS CloudTrail
Enable AWS Config and AWS Trusted Advisor
AWS Security Hub to perform compliance checks for S3 and IAM misconfigurations
Utilize Amazon Macie to scan for sensitive metadata
Always include a Security Operations Center to monitor AWS infrastructure
Some key takeaways
So why should everyone lose sleep over this? It is extremely important to note that this heist was not due to an AWS S3 flaw. Instead, it was caused by a failure in risk prioritization. Many view S3 as low hanging fruit or an acceptable risk. This is no longer acceptable. This heist was not just about crypto theft. Instead, it exploited systemic and human frailties:
Blind trust in “secure” platforms: Users assumed SafeWallet’s transaction process was tamper-proof. It wasn’t. Just because we are using AWS automatically means it is secure. It is not.
DevOps blind spots: Overemphasis on “critical” vulnerabilities ignored foundational hygiene within the AWS ecosystem.
Forensic evasion: The two-minute cleanup suggests attackers anticipated and potentially outmaneuvered post-breach scrutiny.
The human factor was not secured properly on the developer’s computer and the AWS account. One must wonder if proper XDR software and security monitoring was installed and enabled on their development computer(s). Did the compromised AWS account have MFA enabled on it?
The human factor was also not secured with regard to the blind signing of the transaction messages. There was no mechanism in place to allow for the verification of the contents of the transfers. It is possible that this could have been preventable if more transfer information was provided to the signing parties.
API Keys can be stollen. Plain and simple, it has become extremely easy for them to be stollen. Since keys are a single factor of authentication it is impossible to guarantee that they will always be used by the correct actor. Because of this, safeguards must be in place.
Summary
This incident proves that being proactive with cybersecurity measures can pay dividends in the long run. Incidents like this are avoidable. All it takes is one misconfiguration or one slip of discretion to trigger the cause for a huge loss. The old saying that an ounce of prevention is worth a pound of cure is true. Especially in this scenario.