Cloud environments face the same security threats as on-premises infrastructure, but the attack surface and detection methods are different. Traditional network appliances don’t work the same way. Visibility gaps exist where they didn’t before. Attackers know this and exploit it.

I’ve responded to incidents across AWS, Azure, and GCP environments. The patterns are consistent. Cryptojacking for resource theft, lateral movement for persistence and escalation, and coordinated attacks that exploit cloud-native misconfigurations. Understanding these threats and how to detect them is essential for maintaining security in public cloud environments.

Cryptojacking: The Silent Resource Thief

Cryptojacking is when attackers compromise your infrastructure to mine cryptocurrency using your compute resources. They get the profit, you get the bill. With cloud’s elastic scalability and pay-per-use model, this is incredibly appealing to attackers.

How Cryptojacking Works

Cryptocurrency mining involves solving complex mathematical equations to validate blockchain transactions. Each solved equation earns digital tokens. As more equations are solved, difficulty increases, requiring more computational power. Running mining operations legitimately requires massive electricity costs and hardware investment.

Attackers bypass these costs entirely by hijacking someone else’s infrastructure. In cloud environments, they can:

  • Compromise instances and install mining software
  • Exploit auto-scaling to spin up hundreds of instances
  • Use stolen credentials to deploy mining workloads as legitimate services
  • Embed mining scripts in container images or serverless functions

The beauty of cloud for attackers is scalability. Compromise one account with auto-scaling enabled and they can potentially deploy thousands of mining instances across multiple regions. Your monthly cloud bill explodes while they collect cryptocurrency.

Detection Challenges

Cryptojacking is hard to detect because miners often use legitimate tools. XMRig is a popular cryptocurrency miner that’s perfectly legal to run. It doesn’t trigger antivirus alerts on its own. Malicious mining code often runs quietly in the background, consuming just enough resources to avoid suspicion.

Traditional indicators like overheating workstations don’t apply to cloud instances. You’re not physically touching the hardware. The server could be maxed out at 100% CPU and you wouldn’t know unless you’re actively monitoring.

Common detection indicators:

Unexplained resource consumption spikes:

Terminal window
# Check CPU utilization across instances
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2026-01-01T00:00:00Z \
  --end-time 2026-01-06T00:00:00Z \
  --period 3600 \
  --statistics Average

Look for instances running at sustained 80-100% CPU with no corresponding application load increase.

Unusual network traffic patterns: Mining operations communicate with mining pools. Watch for sustained outbound connections to non-standard ports, especially to IPs in suspicious geographic locations.

Terminal window
# Example suspicious outbound connections
Destination: 45.76.x.x:3333 (Common mining pool port)
Destination: 95.179.x.x:5555 (Another common mining pool port)
Protocol: Stratum (Mining protocol)

Increased costs without corresponding business activity: Your cloud bill doubles but you haven’t deployed new services. Check for unauthorized instance launches or auto-scaling events.

Processes with suspicious names: Miners often disguise themselves with legitimate-sounding process names:

Terminal window
# Suspicious processes commonly used for mining
ps aux | grep -E 'xmrig|minerd|cpuminer|ccminer|systemd-resolve|kthreadd'

Legitimate system processes like systemd-resolve exist, but miners sometimes use these names. Check the process path and parent process to verify legitimacy.

Real-World Detection Example

I worked an incident where auto-scaling kept launching instances that immediately hit 100% CPU utilization. The application team insisted their code was fine. Digging into the instances revealed a mining binary installed in /tmp/.system running as a systemd service.

The attacker had compromised an EC2 instance through an unpatched vulnerability, installed their miner, and configured it to launch on boot. Every time auto-scaling created a new instance from that AMI, the miner came with it. The bill that month was $47,000 higher than normal.

Detection came from monitoring cost anomalies and correlating with resource utilization metrics. The instances were running at full CPU but producing no application logs or legitimate traffic.

Mitigation Strategies

Education: Phishing emails with malicious attachments remain the most common infection vector. Train users to recognize suspicious emails and never click unknown links or download unexpected attachments.

Patch management: Keep all systems updated. Cryptojacking malware often exploits known vulnerabilities in operating systems, applications, and container runtimes.

Terminal window
# Automate patching for cloud instances
# AWS Systems Manager example
aws ssm send-command \
  --document-name "AWS-RunPatchBaseline" \
  --targets "Key=instanceids,Values=*" \
  --parameters "Operation=Install"

Least privilege access: Restrict who can launch instances and what instance types they can use. Implement approval workflows for large instance deployments.

API key protection: Rotate API keys regularly. Use temporary credentials when possible. Never commit keys to source control.

Terminal window
# Use instance roles instead of API keys in code
# Bad: Hardcoded credentials
aws_access_key_id = "AKIAIOSFODNN7EXAMPLE"


# Good: Instance role with temporary credentials
# Code automatically uses role-based credentials

Network monitoring: Deploy network traffic analysis tools. Alert on connections to known mining pools. Block mining pool IPs at the firewall level.

Resource quotas: Implement service quotas to limit maximum instances per account. Prevents attackers from spinning up thousands of instances even if they compromise credentials.

DevSecOps practices: Scan container images for mining software before deployment. Use admission controllers to prevent suspicious workloads from running.

# Kubernetes admission policy to block miners
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: block-miners
spec:
  volumes:
    - 'configMap'
    - 'secret'
  runAsUser:
    rule: 'MustRunAsNonRoot'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
  # Block common miner binaries
  forbiddenSysctls:
    - kernel.threads-max

Lateral Movement: The Attacker’s Playbook

Once attackers compromise a single system, their next goal is lateral movement. Moving from the initial foothold to other systems in your environment. In cloud environments, this can happen entirely within a single subnet without triggering traditional IPS or firewall alerts.

Legitimate vs. Malicious Lateral Traffic

Not all lateral traffic is malicious. Applications communicate with each other, databases sync, monitoring systems collect metrics. The challenge is distinguishing normal operational traffic from attack traffic.

Start by documenting your legitimate traffic patterns:

Application dependencies: What services does each application communicate with? Which ports and protocols?

Terminal window
# Document normal traffic patterns
Application: Web Server
Communicates with: Application Server (port 8080), Database (port 5432)
Protocol: TCP
Frequency: Constant


Application: Batch Processor
Communicates with: Object Storage API (port 443)
Protocol: HTTPS
Frequency: Every 4 hours

Operating system maintenance: OS updates, log shipping, time synchronization all create lateral traffic. Document these patterns so they don’t trigger false positives.

Monitoring and management: Your monitoring agents communicate with central collectors. Backup agents send data to backup servers. Security agents report to SIEM.

Once you understand normal traffic, anomalies stand out. A web server suddenly connecting to another web server on a random high port? Suspicious. Database servers initiating outbound HTTPS connections? Investigate.

Attack Patterns

Malicious lateral movement follows predictable patterns:

Reconnaissance: Attackers map the environment before moving. Excessive ARP/GARP traffic indicates scanning. High volumes of DNS queries to internal hosts suggest enumeration.

Terminal window
# Detecting excessive ARP traffic
tcpdump -i eth0 arp | awk '{print $NF}' | sort | uniq -c | sort -rn
# Look for single sources generating hundreds of ARP requests

Credential theft: After initial compromise, attackers dump credentials from memory, crack password hashes, or steal SSH keys. They use these to authenticate to other systems.

Tool deployment: Attackers deploy their own tools for persistence and further exploitation. Small payloads transferred repeatedly between systems indicate tool distribution.

Command and control: Compromised systems beacon to external C2 servers. Internal systems shouldn’t initiate outbound connections to random internet IPs.

Detection Methods

Cloud environments require different detection approaches than on-premises networks:

VPC Flow Logs: Your primary visibility into network traffic. Enable flow logs on all VPCs and send them to central logging.

Terminal window
# Enable VPC Flow Logs (AWS example)
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs

Analyze flow logs for lateral movement indicators:

-- Query for unusual internal connections
SELECT sourceaddress, destinationaddress, destinationport, COUNT(*) as connection_count
FROM vpc_flow_logs
WHERE sourceaddress LIKE '10.%'
  AND destinationaddress LIKE '10.%'
  AND destinationport NOT IN (80, 443, 22, 3389, 3306, 5432)
GROUP BY sourceaddress, destinationaddress, destinationport
HAVING COUNT(*) > 100
ORDER BY connection_count DESC

Unusual connection patterns: Same source connecting to many destinations, or many sources connecting to a single destination. Both indicate potential compromise.

Protocol anomalies: HTTP traffic on non-standard ports, encrypted traffic from systems that shouldn’t produce it, or unexpected protocols entirely.

Payload analysis: While flow logs show connections, they don’t show payload. Deep packet inspection or next-gen firewalls can analyze payload for malicious content.

Real Incident: Lateral Movement Detection

An alert fired for a web server connecting to a database server on port 4444. That port wasn’t in our documented traffic patterns. Investigation showed the web server had been compromised through a vulnerable plugin. The attacker used it to deploy a reverse shell and was attempting to move to the database server.

Flow logs showed the connection pattern. Security groups weren’t configured to block inter-subnet traffic on non-standard ports, allowing the connection. We isolated both instances, analyzed the attack vector, patched the vulnerability, and implemented network policies to prevent similar lateral movement.

Isolating Attacks in the Cloud

When an attack is detected, immediate isolation is critical. But the knee-jerk reaction to shut everything down often isn’t the right approach. Working with the attack to understand its scope before complete isolation provides better long-term security.

Determining Threat Level

Before taking action, assess the threat:

Low threat: Automated scanning, failed authentication attempts, probing for known vulnerabilities. Continue monitoring. Maybe adjust security group rules to block the source.

Medium threat: Successful exploitation of a vulnerability, but no evidence of data access or lateral movement. Isolate affected systems. Patch the vulnerability. Investigate the extent of compromise.

High threat: Active data exfiltration, lateral movement detected, ransomware deployment, or compromise of privileged accounts. Immediate isolation of affected resources. Full incident response engagement.

Threat assessment requires understanding what systems are affected, what data they have access to, and what the attacker has done so far. Review logs, analyze network traffic, check for indicators of compromise.

Isolation Techniques

Cloud-native methods for attack isolation:

Security group modification: The fastest isolation method. Modify security groups to block attacker traffic while maintaining legitimate application functionality.

Terminal window
# Example: Block specific source IP while maintaining application access
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,IpRanges='[{CidrIp=10.0.0.0/16}]'


aws ec2 revoke-security-group-ingress \
  --group-id sg-12345678 \
  --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,IpRanges='[{CidrIp=0.0.0.0/0}]'

This allows internal traffic on port 443 while blocking external access. Isolates the attack vector without completely disabling the service.

IAM policy restriction: If the attack uses compromised credentials, tighten IAM policies immediately.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "198.51.100.0/24"
        }
      }
    }
  ]
}

Denies all actions from the attacker’s source IP. Even if they have valid credentials, they can’t perform actions.

Network ACL changes: More aggressive than security groups. NACLs operate at the subnet level and can block traffic before it reaches instances.

Disable compromised accounts: Immediately disable user accounts showing signs of compromise. Reset passwords, revoke access keys, terminate active sessions.

Terminal window
# Disable IAM user
aws iam update-login-profile \
  --user-name compromised-user \
  --password-reset-required


aws iam delete-access-key \
  --user-name compromised-user \
  --access-key-id AKIAIOSFODNN7EXAMPLE

Snapshot and isolate: Take a snapshot of compromised instances for forensic analysis, then isolate or terminate them.

Terminal window
# Snapshot for forensics
aws ec2 create-snapshot \
  --volume-id vol-1234567890abcdef0 \
  --description "Forensic snapshot - incident 2026-01-06"


# Move to isolated network for analysis
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --groups sg-forensics-isolated

Account and Access Maintenance

After containing the immediate threat, conduct a thorough review:

User account audit: Remove inactive users, service accounts no longer in use, and any suspicious accounts created by attackers.

Permission review: Apply least privilege. Most users and services have more permissions than needed. Trim them down.

Password reset: Force password changes for all accounts with access to affected systems. Assume credentials were compromised until proven otherwise.

Service account rotation: Rotate API keys, service account credentials, and secrets stored in secrets managers.

Third-Party Tools

Native cloud controls are effective for initial isolation, but comprehensive security requires additional tools:

Cloud NGFW: Next-gen firewalls provide deep packet inspection and can block attacks based on signatures, not just IPs and ports.

CSPM (Cloud Security Posture Management): Continuously monitors cloud configurations for security issues. Helps prevent attacks by catching misconfigurations before exploitation.

EDR/Server protection: Endpoint detection and response for cloud instances. Detects malicious processes, blocks them, and provides forensic data.

Network traffic analyzers: East-west traffic visibility. Mirrors internal traffic for analysis. Detects lateral movement that security groups miss.

SOAR platforms: Orchestrates incident response actions. When Sentinel detects an attack, SOAR can automatically isolate instances, block IPs, and notify responders.

Putting It All Together

Effective cloud security requires layered defenses:

Prevention: Proper configuration, least privilege access, network segmentation, patch management. Make it hard for attackers to get in.

Detection: Comprehensive logging, flow logs, SIEM integration, behavioral analytics. Know when something bad happens.

Response: Documented incident response procedures, automated isolation playbooks, regular tabletop exercises. React quickly when attacks occur.

Recovery: Backup strategies, disaster recovery plans, forensic analysis capabilities. Return to normal operations and understand what happened.

The cloud’s shared responsibility model means you’re responsible for security in the cloud. The provider secures the infrastructure, you secure your workloads, data, and configurations. Attackers exploit the gap between what providers secure and what you’re supposed to secure.

Common themes across cryptojacking, lateral movement, and attack isolation:

Visibility is critical: You can’t protect what you can’t see. Enable logging everywhere. Send everything to a central SIEM.

Normal baselines matter: Understanding normal behavior is how you spot anomalies. Document your environment’s traffic patterns and access patterns.

Defense in depth: No single control stops all attacks. Layer security controls so if one fails, others catch it.

Automation scales: Manual security operations don’t scale in cloud environments. Automate detection, isolation, and response.

Continuous improvement: Attackers evolve. Your defenses must evolve too. Regular security reviews, threat modeling, and penetration testing keep you ahead.

Cloud security isn’t fundamentally different from on-premises security, but the implementation details matter. The tools are different, the visibility points are different, and the attack surface is different. Adapt your security practices to the cloud environment and you’ll be in good shape.

Ignore the differences and you’ll get compromised. It’s that simple.