Malware Analysis & Sandboxing in Cloud Environments

Malware in Cloud Environments

Cloud environments face malware through several vectors:

Vector	Example	Primary Target
Compromised container image	Docker Hub image with embedded miner	EC2 / EKS / ECS
Malicious Lambda layer	npm package with backdoor	Lambda functions
Malware in user-uploaded files	Ransomware in S3-stored document	S3 → EC2 processing pipeline
Compromised CI/CD artifact	Build pipeline backdoor	Production deployment
Fileless malware via SSM	Shell commands injected via SSM Run Command	EC2 instances

Cloud malware has specific characteristics that differ from endpoint malware:

• Persistence: Achieved through IAM backdoor users, rogue Lambda functions, EventBridge rules — not Windows registry run keys
• C2 communication: Often uses AWS SDK calls (S3 GetObject, SQS receive) as covert channels to avoid network detection
• Payload: Often crypto miners (targeting cloud compute) or credential harvesters (targeting IMDS)
• Anti-forensics: Disabling CloudTrail, deleting VPC Flow Logs, rotating access keys to remove attacker key from IAM history

Cloud-Based Malware Sandbox Architecture

Running malware analysis in the cloud offers significant advantages over dedicated on-premises sandboxes:

• Elastic capacity: Spin up hundreds of analysis VMs simultaneously for parallel analysis
• Snapshot and revert: EBS snapshots allow instant revert to clean state
• Network control: VPC with outbound-only rules allows studying network behaviour safely
• Isolation: Isolated VPC with no internet access except monitored egress

Architecture

Malware Sample
     ↓
S3 (sample quarantine bucket, Object Lock, no execution permissions)
     ↓
SQS analysis queue
     ↓
Analysis EC2 (isolated VPC, specific OS/environment matching target)
     │   ├── Static analysis (strings, file type, hash, YARA rules)
     │   ├── Dynamic analysis (execute in clean environment, monitor syscalls)
     │   └── Network analysis (Fakenet-NG intercepts network calls)
     ↓
Results to S3 (report bucket)
     ↓
EBS snapshot revert (clean state for next sample)

Networking for Safe Malware Execution

The analysis VPC must be completely isolated except for controlled outbound inspection:

Analysis EC2 instance
      │
      ▼
Transparent HTTP/HTTPS proxy (INetSim / FakeNet-NG)
      │  (intercepts and logs all DNS and network requests)
      │  (returns fake responses; no real internet connection)
      ▼
VPC — no internet gateway, no NAT gateway, no VPC peering

Never allow a malware analysis sandbox direct internet access. The malware will phone home, receive commands, and may compromise C2 servers — creating legal liability.

Static Analysis of Cloud Malware

Static analysis examines the artifact without executing it.

Container Image Analysis

# Pull image without running it
docker pull suspicious/image:latest

# Extract filesystem
docker export $(docker create suspicious/image:latest) | tar -x -C ./extracted/

# Search for known malicious patterns
grep -r "169.254.169.254" ./extracted/   # IMDS access (credential theft)
grep -r "aws_access_key" ./extracted/   # Hardcoded credentials
grep -r "curl.*pastebin" ./extracted/   # Payload download from pastebin

# Scan with Trivy
trivy image suspicious/image:latest

# Hash all executable files
find ./extracted/ -type f -executable -exec sha256sum {} \; > hashes.txt

# Check hashes against VirusTotal (requires API key)
while read line; do
  hash=$(echo "$line" | awk '{print $1}')
  vt-cli scan file "$hash"
done < hashes.txt

Lambda Package Analysis

Lambda functions are deployed as ZIP packages. Extract and analyse:

# Get function code
aws lambda get-function --function-name suspicious-function \
  --query 'Code.Location' --output text > download_url.txt

# Download and extract
curl -o function.zip "$(cat download_url.txt)"
unzip function.zip -d function_extracted/

# Analyse
find function_extracted/ -name "*.py" -exec grep -l "subprocess\|os.system\|eval\|exec" {} \;
grep -r "169.254.169.254" function_extracted/
strings function_extracted/ | grep -E "https?://"

YARA Rules for Cloud Malware Detection

YARA is the pattern-matching language for malware detection. Write rules targeting cloud-specific malware characteristics:

rule CloudMalware_IMDSCredentialThief
{
    meta:
        description = "Detects scripts attempting to steal credentials via IMDS"
        author = "Cloud Security Team"
    strings:
        $imds_url = "169.254.169.254" ascii wide
        $iam_path = "iam/security-credentials" ascii wide
        $curl = "curl" ascii wide
        $wget = "wget" ascii wide
    condition:
        $imds_url and $iam_path and ($curl or $wget)
}

rule CloudMalware_CryptoMinerIndicators
{
    meta:
        description = "Detects common crypto mining indicators in cloud"
    strings:
        $pool1 = "stratum+tcp://" ascii wide
        $pool2 = "xmrig" ascii wide nocase
        $pool3 = "mining.pool." ascii wide
        $pool4 = "monero" ascii wide nocase
    condition:
        any of them
}

Deploy YARA scanning in the CI/CD pipeline and as a Lambda function triggered by S3 uploads to scan user-uploaded files.

Detecting Malware in Running AWS Environments

GuardDuty includes trained ML models specifically for crypto mining and known malware C2:

GuardDuty Finding	What It Means
CryptoCurrency:EC2/BitcoinTool.B!DNS	Instance querying cryptocurrency mining pool DNS
Trojan:EC2/BlackholeTraffic	Instance communicating with known botnet C2
Backdoor:EC2/C&CActivity.B!DNS	Instance communicating with known C2 domain
Malware:EC2/MaliciousFile	GuardDuty Malware Protection scan found malware on EBS
UnauthorizedAccess:EC2/MaliciousIPCaller.Custom	Instance communicating with IP in custom threat intel list

GuardDuty Malware Protection (launched 2022) can scan EBS volumes attached to EC2 instances when a suspicious finding is generated — without stopping the instance. It uses snapshots to perform the scan, so the running instance is unaffected.