With the significant rise of cryptocurrency platforms, these platforms have become increasingly vulnerable targets by attackers due to their reliance on cloud computing services to improve their scalability and availability.
When a cloud computing account or service is accessed by an attacker, they can navigate through application security measures; therefore, an attacker doesn’t have to compromise an individual device with malware to move funds or change balances or to steal credentials, an attacker only needs access to the cloud computing environment.
Attackers utilize multiple methods to exploit cloud environments:
1. Secrets are exposed within source code repositories:
AWS access keys, Google Cloud service accounts, or other API tokens that have been inadvertently committed.
2. Cloud storage was misconfigured; for example, S3 bucket or GCS or Azure Blob containers were left publicly accessible.
3. IAM privileges have been escalated:
The IAM Role is overly permissive, which enables the attacker to assume a user account they shouldn’t be able to.
4. An integration with a third party: A tool, Dashboard, CI/CD pipeline, etc., that has been compromised may allow the attacker to inject malicious scripts through any number of mechanisms, and a single compromised API key may result in significant financial damage of millions of dollars worth.
Real-World Patterns and Examples
Example 1: Misconfigured S3 Buckets
An attacker found that a company’s storage bucket was publicly available without any password protection. The attacker was able to perform the following actions:
Detection:
aws s3 ls s3://company-crypto-wallet-backups --no-sign-request
1. Downloaded sensitive keys
2. Gained direct access to cold wallets
Mitigation: Configure the bucket’s ACL as private and require IAM policies be enforced.
Example 2: Compromised Continuous Integration/Continuous Deployment Secrets
An engineer unintentionally committed the AWS keys to a public repository on GitHub. The attackers were then able to do the following:
1. Access deployment pipelines
2. Change the address for the wallet in their build processes
3. Intercept funds during the transfer process
Detection:
git log -p | grep “AWS_SECRET_ACCESS_KEY”
The SOC teams examine Cloud Access logs that relate to an engineer's Git log to determine if there was unauthorized access.
Example 3: OAuth or API Token Abuse
Some crypto exchanges promote the use of Dashboard/Trading Bots from third parties.
1. Attackers obtain stolen API tokens
2. Bots make trades or shift funds
3. Logs from the bots look legitimate, unless the logs are cross-referenced against the original source
The Hunting Example written in Python:
for event in cloud_logs:
if event[“user_agent”] == “api-client” and event[“location”] not in expected_regions:
print(“Suspicious API activity detected:”, event)
Example 4: Internal or Third Party Compromise
Breach of data can occur from more than just external sources. Vendors or employees with excessive access to cloud data have recently taken items from our servers and sold them, as shown below:
1. Downloaded Private Key
2. Modified contracts before they were successfully deployed
3. Temporarily turned off monitoring systems
Detection of these events is based on internal audits of role-based access controls and anomalies detected in privileged employee accounts.
Monitoring cloud breaches is accomplished by utilizing a combination of:
1. Cross-cloud audit logs (AWS CloudTrail, GCP Audit Logs, Azure Activity Logs),
2. Secret-scanning tools (truffleHog, git-secrets),
3. Cloud Security Posture Management - CSPM platforms,
4. SIEM Correlation Rules to identify Malicious API calls or privilege escalation.
For example, a secret scanning command for truffleHog can be run:
truffleHog --regex --entropy=true https://github.com/company/crypto-project.git
Why do Typical Security Solutions Fail?
1. Cryptographic systems are designed for machine speed and automate the majority of processes; therefore, very few, if any, human eyes assess them.
2. To make development as fast as possible, it is common for developers to commit secret data.
3. Misconfigured cloud infrastructures are commonplace and ongoing.
4. Instead of attacking endpoint devices, attackers capitalize solely on the Trust Model put forth by the cloud.
Even with Multi-Factor Authentication, attackers can still take advantage of API Keys that have already been compromised or roles that have been assumed.
Defensive Practices
1. Both audits of all IAM Roles, and Vetting of all "Too Much Access" and "Not Used"
2. Enable both Monitoring and Alerting on all API activity, as well as changes to Cloud
3. Continuous scanning of repositories to detect potential inadvertent exposure of secrets before deployment
4. Token lifetime limitations; making use of short-lived keys reduces exposure
5. Using Third-Party Verification Tools to Enforce 'Least Privilege' for all development, deployment, and operation environments.
Key Takeaways
1. Crypto Losses are usually a byproduct of Clouds and not typical "Malware"
2. Attackers look for Misconfigured Services (exposed secrets), and abuse of Privileges
3. Intentional Continuous Monitoring/Auditing, and Automated Scanning are essential
4. Logs, API activity, and Cloud Configuration changes provide insight into attack behavior prior to funds being "Moved"
5. Even the tiniest cloud governance lapse could lead to a multi-million-dollar incident.
