The Heist: Chasing an Advanced Crypto Attacker Across the Multi-cloud

The Heist: Chasing an Advanced Crypto Attacker Across the Multi-cloud

Speakers: Yotam Meitar

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=0ptcg7KPFQc

Overview

Yotam Meitar, Director of Incident Response at Wiz, delivered a compelling talk at BSides SF, detailing a sophisticated, multi-stage cyber heist that targeted a large cryptocurrency exchange. The presentation, aptly titled "The Heist: Chasing an Advanced Crypto Attacker Across the Multi-cloud," dissected a real-world incident response effort, tracing an attacker's intricate path across numerous cloud services and on-premises infrastructure. Meitar, leveraging his decade of experience in incident response and prior background in offensive cyber operations, unveiled how a seemingly straightforward $18 million theft escalated into a much larger, multi-month campaign totaling $107 million, orchestrated by a patient and technically adept adversary.

This talk is crucial for security professionals, particularly those operating in multi-cloud environments or within the cryptocurrency sector. It provides a granular, step-by-step breakdown of a modern attack chain that meticulously bypassed multiple layers of security, including multi-factor authentication, third-party transaction verification, and cloud-native monitoring. The incident serves as a stark reminder of the escalating sophistication of threat actors and the critical need for integrated, cloud-specific defenses and rapid incident response capabilities. Meitar's narrative not only exposes the vulnerabilities inherent in complex distributed systems but also underscores the human element as a persistent weak link, particularly through social engineering of help desks.

The significance of this incident extends beyond the financial losses, highlighting fundamental challenges in cloud security. It demonstrates how attackers can leverage native cloud tools, exploit supply chain elements like GitHub, and pivot seamlessly between different cloud providers and on-prem systems. The speaker's ability to unravel this complex narrative, despite the challenges of redaction and anonymization, offers invaluable insights into the investigative process, the importance of comprehensive logging, and the strategic implications for building resilient security postures in today's dynamic threat landscape.

Background

▶ Watch: Speaker introduction and attack details disclaimer (0:00)

The victim organization was a large cryptocurrency exchange facilitating the trading and selling of various digital currencies. Their architecture, designed to secure high-value transactions, involved several critical components. When a customer initiated a withdrawal, the request first underwent authentication via Entra ID (formerly Azure AD), used for both internal and customer authentication. Following this, a dedicated Know Your Customer (KYC) server verified the legitimacy of the request and the identity of the person making it, often involving manual checks like photo verification.

Upon KYC approval, the transaction was forwarded to a hot wallet transaction server. Hot wallets, unlike cold wallets (which store signing keys offline), are online and automate transaction creation. For a large exchange, these hot wallets can still hold substantial sums. After the hot wallet server signed the transaction, it was sent to a third-party verification service, in this case, BitGo. BitGo served as an additional security layer, enforcing rules such as blocking transactions to known malicious wallets or those exceeding predefined limits. A critical rule for this organization was that any transaction over $1 million required manual approval by a small group of highly privileged administrators. This multi-layered process was intended to prevent large-scale fraud and unauthorized fund transfers.

The incident response effort commenced when the organization discovered an unauthorized $18 million transaction that had bypassed all these controls. The transaction was not recognized, nor was the destination wallet, immediately triggering an investigation into how such a significant bypass could occur. This initial discovery set the stage for unraveling a far more extensive and deeply entrenched compromise.

Key Findings

▶ Watch: Understanding the cryptocurrency exchange's withdrawal process (1:00)

The investigation into the $18 million heist progressively revealed a multi-faceted attack, expanding dramatically in scope and duration:

1. Initial Compromise of BitGo Admin: The $18 million transaction was found to have been approved by a legitimate BitGo admin user within the victim organization. This user authenticated via Entra ID, indicating a compromise of their identity.
2. Hot Wallet Server as Transaction Origin: Logs confirmed the malicious transaction originated from the internal hot wallet transaction server, suggesting an internal infrastructure compromise, not just an external bypass.
3. Help Desk Social Engineering (First Instance): The BitGo admin's Entra account was compromised through a social engineering attack targeting the company's help desk. Attackers reset the admin's password and multi-factor authentication (MFA) by providing the last four digits of their Social Security Number, which was likely obtained from a prior data leak. The help desk, overwhelmed with calls, failed to detect the malicious intent.
4. Discovery of Prior, Smaller Thefts: Analysis of the blockchain revealed the $18 million transaction followed a distinct pattern: a "double hop to mixer" (funds from the hot wallet to a new wallet, then to another new wallet, then to an automated exchange/mixer for laundering). Searching for this pattern uncovered over 40 smaller, unauthorized transactions totaling an additional $27 million, occurring over a seven-month period. This expanded the total theft to $107 million and the attack timeline significantly.
5. AWS SSM for Malicious Transactions: The smaller transactions, and eventually the large one, were initiated by attackers using AWS Systems Manager (SSM) to run commands directly on the EC2 instance hosting the hot wallet transaction server. This bypassed the need for malware or direct persistence, utilizing cloud-native management tools.
6. Compromised AWS IAM User: The SSM commands were executed by an unknown AWS IAM user named secops, which the organization confirmed was not legitimate and likely created by the attackers.
7. Compromised Legitimate AWS IAM User: Further investigation showed the secops user was created by another legitimate AWS IAM user, primarily used for testing in CI/CD pipelines. This test user possessed excessive privileges, allowing it to create new IAM users and assign high-level permissions.
8. GitHub Repository Compromise: The legitimate AWS test user's credentials (an Access Key) were stored as GitHub Action secrets. Attackers accessed these secrets via a malicious GitHub Action that created the secops IAM user and assigned it privileges. This action was triggered by a Pull Request (PR) in a compromised GitHub repository.
9. Compromised GitHub Personal Access Token (PAT): The malicious PR was executed using a GitHub Personal Access Token (PAT) belonging to a legitimate developer.
10. Password Manager Compromise: The developer's PAT was stored in the organization's corporate password manager. Attackers accessed the password manager by compromising the developer's Entra ID account.
11. Help Desk Social Engineering (Second Instance): The developer's Entra account was compromised seven months prior, likely through another help desk social engineering attack. This was a more sophisticated attack, timed precisely after the developer had performed a mandated password change. Attackers used an old-fashioned AD auditing tool and NTDS.DIT file analysis to reconstruct password change history and identify the attacker's password reset.
12. Initial Reconnaissance via Earlier Compromise: Attackers gained intelligence about the mandated password reset (which helped them time the developer's account compromise) from an even earlier, less privileged Entra user compromise. This initial compromise, also via help desk social engineering eight months prior, allowed attackers to access the user's mailbox and search for keywords like "password" and "reset," revealing the upcoming organizational password change mandate.

This complete picture revealed a highly patient and adaptive attacker, chaining multiple vulnerabilities across disparate systems over an extended period.

Technical Deep Dive

▶ Watch: Critical security rule: $1M+ transactions require manual approval (3:15)

The attack leveraged a sophisticated chain of exploits across multiple cloud and on-premises services, demonstrating a profound understanding of modern enterprise IT environments.

The initial large $18 million transaction was approved by a BitGo admin whose Entra ID account was compromised. This compromise was achieved through social engineering of the organization's help desk. Attackers, impersonating the admin, called the help desk to report a lost phone, requesting a password reset and MFA device removal. Critically, the attackers provided the last four digits of the admin's Social Security Number (SSN), a detail often leaked in data breaches, which was sufficient for the help desk to bypass identity verification protocols. The help desk then reset the password to a simple, temporary one (e.g., "summer 2020 with a capital S") and removed the MFA, granting the attackers full access.

The investigation revealed that the malicious transaction itself originated from the victim's hot wallet transaction server, an EC2 instance in AWS. This pointed to an internal compromise of the AWS environment. Analysis of AWS CloudTrail logs confirmed that attackers used AWS Systems Manager (SSM) to execute commands directly on this EC2 instance. SSM, a legitimate cloud-native management tool, allowed the attackers to trigger the organization's own scripts designed for initiating transactions, but with attacker-controlled parameters (target wallets, amounts). This eliminated the need for deploying custom malware or establishing persistent reverse shells, making the activity harder to detect as it blended with legitimate administrative actions.

The AWS IAM user responsible for these SSM commands was identified as secops, which the organization did not recognize. This user had been created by another legitimate AWS IAM user, a "test user" typically used in CI/CD pipelines. This test user possessed overly broad permissions, including the ability to create and assign high privileges to other IAM users. The credentials for this test user (an Access Key) were stored as a GitHub Action secret within the organization's GitHub environment.

Attackers exploited a known vulnerability or misconfiguration in how GitHub Action secrets are handled. While GitHub aims to prevent direct exfiltration of secrets by redacting them in logs, techniques like double Base64 encoding can bypass these protections, allowing attackers to print and retrieve the actual credential values. In this case, attackers created a malicious GitHub Action that, when executed, would create a new IAM user in AWS (secops) and assign it the necessary privileges to interact with SSM and the hot wallet server. This malicious action was triggered by a Pull Request (PR) in a compromised GitHub repository.

The GitHub Personal Access Token (PAT) used to create and execute this malicious PR belonged to a legitimate developer. This PAT was stored in the organization's corporate password manager. The password manager itself was protected by Entra ID SSO, meaning attackers had to compromise the developer's Entra account to access it.

The developer's Entra account compromise was a more intricate social engineering attack, occurring approximately seven months prior, aligning with the start of the smaller, stealthy transactions. The attackers likely knew when to strike due to an earlier reconnaissance phase. About eight months prior, a different, unprivileged user's Entra account was compromised via the help desk (again, through social engineering). While this initial compromise was quickly detected and remediated, attackers leveraged their brief access to that user's mailbox to search for keywords like "password" and "reset." This allowed them to discover an upcoming, organization-wide mandated password reset campaign.

Armed with this knowledge, the attackers waited. When the developer performed their mandated password change, the attackers called the help desk shortly after, knowing the user had just changed their password. They reset the developer's password and MFA, leading to a situation where the developer, upon returning to work, found they couldn't log in. Assuming they had simply forgotten their newly set password or made an error, the developer called the help desk again to reset it, unknowingly handing control back to the attackers for a brief period. This subtle timing prevented the developer from realizing they were targeted. The reconstruction of this sequence was achieved by analyzing an old-fashioned AD auditing tool (which had longer retention than Entra logs) and cross-referencing password hashes extracted from the NTDS.DIT file on the on-prem Active Directory domain controller with generated lists of known help desk patterns and the user's password patterns. This forensic work allowed the team to match specific hashes to specific password changes over time, revealing the attacker's intervention.

This entire sequence, from initial reconnaissance to final exfiltration, demonstrated a deep understanding of the target's multi-cloud infrastructure, internal processes, and human vulnerabilities.

Demo / Proof of Concept

▶ Watch: Discovery of the unauthorized $18 million transaction (4:10)

The talk focused on a detailed incident response narrative, dissecting a real-world attack rather than presenting a live demonstration or proof of concept of a specific exploit. The speaker meticulously walked the audience through the investigative process, showcasing redacted logs, call transcripts, and forensic findings to illustrate how the attack unfolded and was unraveled.

Defensive Implications

▶ Watch: BitGo logs reveal compromised admin approved transaction (5:30)

The "Heist" incident provides critical lessons for defenders operating in complex multi-cloud environments:

1. Cloud-Native Defenses are Non-Negotiable: Relying on traditional on-premises security tools and methodologies ported to the cloud is insufficient. Each cloud service (Entra ID, AWS, GitHub, SaaS password managers) has its own security model and native tools. Organizations must implement cloud-specific detection and prevention mechanisms, leveraging tools like AWS CloudTrail, AWS SSM Session Manager logging, and robust Entra ID audit logs with extended retention.
2. Elevate Help Desk Security: Social engineering targeting help desks remains a primary initial access vector. Organizations must significantly harden help desk procedures, especially for privileged accounts. This includes:

• Stronger Identity Verification: Moving beyond easily compromised data like SSNs. Implementing knowledge-based authentication that is not publicly available, requiring manager approval, or even in-person verification for critical resets.
• No Help Desk for Privileged Users: For highly sensitive accounts (e.g., BitGo admins, core developers), remove the help desk's ability to reset passwords or MFA. Implement alternative, more secure, multi-party processes for such changes.
• Enhanced Training: Continuously train help desk staff on social engineering tactics and red flags.

1. Centralized Visibility Across All Cloud Services: The attack spanned Entra ID, AWS, GitHub, BitGo, and a password manager. Without a single pane of glass or centralized logging and monitoring platform that aggregates data from all these disparate services, detection is fragmented, and investigations are significantly slower and less effective. Correlating events across these services is crucial for identifying lateral movement and attack progression.
2. Prioritize Speed in Detection and Response: Attackers moved rapidly between stages once access was gained (e.g., from GitHub to AWS, from help desk compromise to transaction approval). If an organization's detection and response capabilities take longer than the attacker's operational tempo, the battle is already lost. This necessitates automated detections, well-rehearsed incident response playbooks, and continuous drills.
3. Secure CI/CD Pipelines and Secrets Management: GitHub repositories and CI/CD pipelines are increasingly attractive targets. Organizations must:

• Review IAM Permissions: Ensure AWS IAM users used by CI/CD have the principle of least privilege applied, strictly limiting their ability to create new users or assign high-level permissions.
• Harden GitHub Secrets: Implement robust controls around GitHub Action secrets, including strong access policies and monitoring for unusual access patterns or attempts to exfiltrate secrets (e.g., via Base64 encoding tricks).
• Monitor GitHub Activities: Actively monitor for suspicious GitHub actions, pull requests, and PAT usage, especially those involving credential creation or privileged operations.

1. Strengthen Password Manager Security: Password managers are critical assets. They must be secured with strong MFA, and access logs should be meticulously reviewed for anomalous activity. Shared vaults for sensitive credentials should be preferred over individual storage where possible, with granular access controls.
2. Proactive Threat Hunting and Blockchain Monitoring: The discovery of the smaller $27 million theft relied on proactive blockchain analysis for specific transaction patterns ("double hop to mixer"). Organizations handling cryptocurrencies must integrate similar forensic capabilities to detect stealthy, lower-value exfiltrations that might otherwise go unnoticed.
3. Understand Attacker Patience and Reconnaissance: This incident highlighted attackers' willingness to conduct multi-month reconnaissance, starting with low-privilege compromises to gather intelligence (like upcoming password resets) before launching higher-impact attacks. Defenders must assume initial access can be stealthy and long-lived, necessitating continuous monitoring for subtle indicators of compromise.

Key Takeaways

• Cloud-Native Attacks Demand Cloud-Native Defenses: Traditional on-premises security strategies are insufficient for securing complex multi-cloud environments. Organizations must adopt cloud-specific tools, configurations, and monitoring to effectively detect and prevent modern threats.
• Social Engineering Remains a Potent Initial Access Vector: Help desks are frequently targeted. Strengthening identity verification protocols, limiting help desk authority for privileged accounts, and continuous staff training are paramount to mitigate this persistent threat.
• Speed in Detection and Response is Critical: Attackers move rapidly between compromised services. Organizations need integrated visibility across all cloud platforms and automated response capabilities to reduce the time attackers have to inflict damage.
• Centralized Visibility is Essential for Complex Investigations: Correlating logs and events from disparate services like Entra ID, AWS, GitHub, and SaaS applications into a single platform is vital for effective threat hunting and incident response.
• Supply Chain Elements (e.g., GitHub Actions) are High-Value Targets: Attackers are increasingly exploiting CI/CD pipelines and code repositories to gain access to credentials and pivot across cloud environments. Robust security for these components, including least privilege and vigilant monitoring, is crucial.
• Patience and Sophistication Characterize Advanced Adversaries: This attack demonstrated an adversary willing to conduct extensive reconnaissance over many months, chaining multiple, seemingly minor compromises into a highly lucrative, large-scale heist. Defenders must anticipate and prepare for such long-term, multi-stage campaigns.

About the Speaker(s)

Yotam Meitar is the Director of Incident Response at Wiz, a cloud security company. With a decade of experience in incident response, Yotam specializes in unraveling complex cyberattacks and guiding organizations through recovery. Prior to his work in the private sector, he gained valuable experience in offensive cyber operations within the military, providing him with a unique perspective on attacker methodologies and defensive strategies. His expertise lies in understanding the intricate ways threat actors exploit vulnerabilities across diverse IT infrastructures, particularly in multi-cloud environments.