How to Execute the Bybit $1.5B ETH Heist — An Attack Path for Offensive Security Operations in AWS
📰 Background on the Bybit Crypto Heist
On February 21st, cybercriminals infiltrated one of ByBit’s suppliers, covertly modifying the digital wallet address intended for the transfer of 401,000 Ethereum coins, valued at approximately $1.5 billion. ByBit believed it was transferring the funds to its own digital wallet, but instead, the entire amount was redirected to the hackers.
According to the preliminary investigation conducted by Zachxbt, the hackers responsible for this attack are identified as the Lazarus Group. (Source).
This incident stands as the largest cryptocurrency theft in history.
📰 Fun Fact About this Incident
- This incident occurred due to the Lazarus hackers compromising the AWS environment of Safe{WALLET}, while the Bybit system itself remained secure. (Source: Ben Bybit & Safe{WALLET})
- Therefore, this was a supply chain attack specifically targeting Bybit.
⚠️ Disclaimer
- The attack scenarios and techniques discussed in this blog are intended for educational purposes only.
- The architecture, design, services, or any elements mentioned here do not represent the actual Safe{WALLET}. I provided solely for illustration and example purposes.
- The attack path described here does not represent the actual actions of Lazarus, as there are no official reports confirming this. It is provided solely as an example of an attack path for offensive security operations.
- In order to understand context of this medium post, please read the official investigation report from Bybit first (link: Ben Bybit)
🧠 Understanding Offensive Operations
Imagine this: as an offensive security engineer or a member of a red team, your mission is to carry out red team operations with the goal of stealing cryptocurrency from a client. To succeed, you need to know the attack paths and strategies that will help you achieve this goal.
For our example, let’s look at the Bybit crypto heist incident. In this case, it was found that the Safe{WALLET} developer machine and AWS were compromised by the Lazarus group, allowing them to backdoor the JavaScript file in Safe{WALLET}’s S3 storage.
*In this medium post we will only focus on AWS attack vector
👨🏼💻 Initial Access to AWS via Compromised Dev’s Machine
The Lazarus hackers gained initial access to Safe{WALLET}’s developer machine through malware. From this foothold, they were able to pivot their access to AWS. As the malware quietly executed its mission, the hackers gained their initial foothold. This was no small victory; the developer’s machine was a treasure trove of sensitive information. It housed everything related to the internal workings of the organization — from the application source code that powered their services to critical internal documents like Product Requirement Documents (PRDs) and technical design specifications.
But that was just the beginning. The developers, in their daily routines, had active sessions open to various developer tools, including GitLab for version control and automation tools that streamlined their workflows. Even more tempting was the active session to their cloud infrastructure, specifically AWS, where the real power lay.
With this insight, the we saw a world of possibilities for lateral movement from the developer’s machine to AWS. Each option was like a door waiting to be opened, leading us further into the heart of the system. They could choose from a variety of tactics, including:
➡️ Searching for AWS Credentials:
In the daily routine of a developer, AWS credentials can be found in many different places, often in plain sight. These important keys might be stored in the source code, saved as environment variables, or even held in the computer’s memory. They could be located in essential documents like product requirement papers or technical guides, stored in password manager vault, or simply written down in a text file.
➡️ Active AWS Session in~/.aws Directory:
By default, any configured AWS-related credentials are stored in the ~/.aws directory. This location is like a goldmine for us looking to gain access. It’s an easy target where they can find AWS credentials or even an active SSO AWS session. With these credentials in hand, a we can quickly move laterally within the AWS environment, making it much simpler to expand their access and exploit the system.
➡️ Exploiting Internal Services:
Internal services, such as APIs or microservices or internal tools, may have vulnerabilities or misconfigurations that attackers can exploit. For example, If a developer’s machine is connected to a Virtual Private Network (VPN), it often has access to internal resources that are not exposed to the public internet, attackers can send requests to it and potentially gain access to AWS resources.
➡️ Abusing CI/CD Pipelines:
Developers often have access that allow to modify or run Continuous Integration/Continuous Deployment (CI/CD) jobs. Frequently, these CI/CD runners are integrated with infrastructure like AWS to automate various processes. For example, we can retrieve secret keys, upload files to S3, push Docker images to private registries, and deploy applications to production.
By taking advantage of these CI/CD capabilities, we can exploit this feature to pivot our access into AWS. The technique for abusing CI/CD we can follow established CI/CD threat models, allowing us to navigate the environment with greater ease, but one common technique is dumping environment variables by modifying the CI/CD process is often time enough to get the important system credentials data.
🗺️ Attack Path to S3 from Developer Level Access
Once we gain access to AWS through one of the methods mentioned earlier, our next step is to identify the attack path that will help us reach our goal. In this case, our objective is to obtain write access to the frontend S3 bucket. There are various ways to escalate our access to the S3 bucket, depending on the architecture and services used within AWS. Below are several attack paths we can explore to achieve this.
🧭 Attack Path 1 — Developer AWS Access to S3
In some cases, developers are granted excessive permissions to access infrastructure resources. Therefore, the first attack path is to directly check if the developer-level access includes write permissions to the frontend S3 bucket.
Modifying objects in an S3 bucket can often be hard to detect because, by default, CloudTrail logging for S3 object activity is disabled. This is done to avoid generating too many logs. However, this lack of logging can actually work to our advantage during offensive operations, helping us avoid detection while we carry out our activities.
🧭 Attack Path 2 — Abusing Development related tools
In companies with a strong engineering culture, there are often internal developer tools like SCM GitLab. These tools typically use CI/CD processes for automatic building and deployment. It’s common for CI/CD runners to be integrated with AWS, particularly with services like S3, which is used to store artifacts. We can take advantage of this setup to exploit it, allowing us to escalate our access and achieve our goals in offensive operations.
➡️ Abusing CI/CD
Since the main purpose of CI/CD is to build and deploy applications, it’s common to integrate it with infrastructure resources like AWS S3 buckets, often granting write permissions. Knowing this, we can exploit the CI/CD process to push a backdoored version of JavaScript into the frontend S3 bucket. In many internal development services, often time DevOps teams don’t restrict CI/CD jobs to only run on protected branches because they want to do something with the new pushed code. This allows us to take advantage of the situation by creating a new branch in the repository and modifying the CI/CD configuration.
In the CI/CD attack path, there are several actions we can take, such as exfiltrating secret variables to steal access tokens for various services and backdooring the Docker image builds. This occurs because DevOps teams often set these variables for the GitLab Runner to authenticate with different resources or services, or to integrate other components for a smooth deployment and build process. Therefore, understanding DevOps-related activities is crucial when carrying out offensive operations.
🧭 Attack Path 3 — Exploiting AWS Service
In this attack path, it’s important to understand the common services and their functions to effectively carry out the attack and escalate our access to achieve our goals. Some of the common services in AWS include IAM, Lambda, EC2, SSM, and Secrets Manager, etc. Among these services, having a solid understanding of IAM concepts can help us about 60% (in my opinion) in figuring out how to exploit AWS services. The remaining 40% involves understanding the behavior and features of each service.
It’s also crucial to note that if we want to perform privilege escalation, we need to check what actions we can take with the current user permissions and who has the ability to perform specific actions. For example, if our goal is to gain write access to an S3 bucket, we need to look for IAM users or roles that have the necessary permissions.
Additionally, we may need to perform an attack chain involving two, three, or more services to achieve our goal.
🛡IAM (Identity and Access Management)
IAM, or Identity and Access Management, helps us control who can safely access AWS services and resources. However, from an offensive operations perspective, we examine IAM to identify users, roles, and policies that might grant us extra permissions. By doing this, we can find ways to escalate our privileges and gain access to AWS resources that we want, in this case S3 bucket of Frontend.
⏺ Important Objects in IAM for Privilege Escalation:
🗝 User: Individual accounts that can access AWS resources. Each user has specific permissions assigned to them.
- Example: A developer account that has access to deploy applications on EC2 instances.
🗝 Role:A set of permissions that can be assumed by users or services. Roles are often used to grant temporary access to AWS resources.
- Example: An EC2 instance role that allows the instance to read data from an S3 bucket.
🗝 Group: A collection of users that share the same permissions. Groups simplify permission management by allowing you to assign permissions to multiple users at once.
- Example: A “Developers” group that has permissions to access development resources like Lambda functions and DynamoDB tables.
🗝 Permission: Defines what actions are allowed on specific resources. Permissions are specified in policies attached to users, roles, or groups.
- Example: A permission that allows a user to perform the
s3:PutObjectaction on a specific S3 bucket.
🗝 Policies is Documents that specify permissions for users, roles, or groups. Policies can be managed (AWS-managed) or custom (user-defined).
- Example: A custom policy that grants a user full access to all S3 resources in a specific region.
⏺ Example Techniques for Privilege Escalation:
➡️ Finding Roles with Broader Access:
Identifying roles that have more permissions than necessary can allow an attacker to gain elevated access.
- Example: Discovering a role that has
AdministratorAccesspermissions and assuming that role to gain full control over AWS resources.
➡️ Exploiting Trust Relationships Between Roles:
Some roles may trust other roles or users, allowing them to assume those roles without additional authentication.
- Example: If Role A trusts Role B, an attacker with access to Role A can assume Role B and gain its permissions.
➡️ Adding a User to a Group:
If a user has limited permissions, adding them to a group with broader permissions can escalate their access.
- Example: Adding a user to the “Admins” group, which has full access to all AWS services.
⚛️ Lambda
AWS Lambda allows users to run code without provisioning servers. We can enumerate Lambda functions to identify potential entry points for executing malicious code.
If we can manipulate AWS Lambda functions, we are able to execute arbitrary code with the permissions of the Lambda execution role, potentially leading to privilege escalation, and we are able to access S3 bucket of Frontend.
⏺ Important Objects in Lambda for Privilege Escalation:
🗝 Labda Functions:
The core components that execute code in response to events. Each function can have specific permissions that allow it to access other AWS services.
- Example: A Lambda function that processes data from an S3 bucket and writes results to a DynamoDB table. If this function has excessive permissions, it can be exploited to access sensitive data.
🗝 Execution Role:
The IAM role that a Lambda function assumes when it is executed. This role defines what AWS resources the function can access.
- Example: If a Lambda function’s execution role has permissions to write to an S3 bucket, we could exploit this to upload malicious files or backdoored code.
🗝 Event Sources:
The AWS services that trigger the execution of a Lambda function, such as S3, DynamoDB, or API Gateway.
- Example: An S3 bucket configured to trigger a Lambda function when new objects are uploaded. If we can upload a file to this bucket, it means we can invoke the Lambda function to execute their code.
🗝 Environment Variables:
Key-value pairs that can be used to pass configuration settings to a Lambda function at runtime.
- Example: If sensitive information, such as API keys or database credentials, is stored in environment variables, it means we could exploit this to gain unauthorized access to other services.
⏺ Example Techniques for Privilege Escalation:
➡️ Finding Functions with Excessive Permissions:
Identifying Lambda functions that have broader permissions than necessary can provide opportunities for exploitation.
- Example: A Lambda function that has permissions to access all S3 buckets instead of just the one it needs can be targeted to access sensitive data.
➡️ Exploiting Trust Relationships:
If a Lambda function’s execution role trusts another role, it may allow for privilege escalation.
- Example: If the execution role trusts a role that has admin permissions, it means we could assume that role to gain elevated access.
➡️ Modifying Environment Variables:
If we can modify the environment variables of a Lambda function, it means we can change its behavior or access sensitive information.
- Example: Changing an environment variable to point to a malicious endpoint can redirect legitimate traffic to an our server.
➡️ Adding a Lambda Function to a VPC:
If a Lambda function is added to a Virtual Private Cloud (VPC) with access to sensitive resources, it can be exploited to access those resources.
- Example: A Lambda function that can access a database within a VPC can be used to extract sensitive data if the function has the right permissions.
🖥 EC2 (Elastic Compute Cloud)
EC2 provides scalable computing capacity in the cloud. Attackers enumerate EC2 instances to identify running applications and services that may be vulnerable to exploitation.
By compromising an EC2 instance, we can potentially gain access to the underlying infrastructure and escalate privileges through instance metadata or by exploiting vulnerabilities in the operating system.
⏺ Important Objects in EC2 for Privilege Escalation:
🗝 EC2 Instances:
These are virtual servers that we can use to run applications. Each instance can have different configurations and permissions that we can exploit.
- Example: We might find an EC2 instance running a web application with overly permissive IAM roles that allow access to sensitive data, especially to Frontend S3 Bucket.
🗝 IAM Roles Attached to EC2:
Roles that grant permissions to our EC2 instances, allowing them to interact with other AWS services.
- Example: If an EC2 instance has a role that allows it to access S3 buckets, we can use that role to read or write data in those buckets.
🗝 User Data:
This is a script that we can provide when launching an EC2 instance, which runs automatically when the instance starts. It can be used to configure the instance or install software.
- Example: We can inject a malicious script in the user data to install a backdoor on the instance, allowing us to gain persistent access.
🗝 Amazon Machine Images (AMIs):
AMIs are templates used to create EC2 instances. They contain the operating system and application configurations.
- Example: If we have access to create or modify AMIs, we can create a custom AMI that includes our malicious code, allowing us to launch new instances with our backdoor already installed.
⏺ Example Techniques for Privilege Escalation:
➡️ Finding Misconfigured IAM Roles:
We can look for EC2 instances that have roles with excessive permissions.
- Example: If we discover an EC2 instance with a role that has full access to all S3 buckets, we can exploit this to upload backdoored JS to Frontend S3 Bucket.
➡️ Launching a New Instance with Elevated Permissions:
If we have access to create new EC2 instances, we can launch an instance with a role that has broader permissions, giving us more access to AWS resources.
- Example: We can create a new EC2 instance with an IAM role that has full access to S3, allowing us to read, write, and delete objects in any S3 bucket, speficically to Frontend S3 bucket.
➡️ Exploiting User Data Scripts:
We can modify the user data script of an EC2 instance to execute malicious commands.
- Example: By launching a new instance with a user data script that downloads and executes a malicious payload, we can gain control over the instance.
➡️ Using EC2 Instance Metadata:
We can access instance metadata to retrieve sensitive information, including IAM role credentials.
- Example: By querying the instance metadata service (e.g via SSRF), we can obtain temporary security credentials that allow us to access other AWS resources.
➡️ Lateral Movement to Other Instances:
If we gain access to one EC2 instance, we can look for ways to move to other instances within the same network.
- Example: We can use SSH keys or credentials found on the compromised instance to access other EC2 instances in the same environment.
📖 Conclusion
In this exploration of the Bybit $1.5B crypto heist, we have uncovered the intricate attack path taken by the Lazarus hackers, starting with their initial access to Safe{WALLET} through a compromised developer’s machine. This initial foothold, achieved via malware, allowed them to pivot into the AWS environment, where they could exploit various services and configurations to further their objectives.
The incident serves as a stark reminder of the vulnerabilities that can exist within cloud environments, particularly when security measures are not adequately enforced. By understanding the tactics employed in this attack, we can better appreciate the importance of robust security practices, including regular audits, strict access controls, and continuous monitoring of systems.
As we reflect on this case, it becomes clear that offensive security operations must evolve alongside the tactics of malicious actors. By learning from incidents like the Bybit heist, we can enhance our defenses and better protect sensitive assets in the ever-evolving landscape of cybersecurity. Ultimately, this incident highlights the critical need for vigilance and proactive measures in safeguarding our digital environments against sophisticated threats.
