jan-karel.com
Home / Security Measures / Cloud Security / Stopping Cloud Lateral Movement
Cybersecurity Handbook Cloud Guardrails For Every Deploy Immediate Actions (15 Minutes) Why This Matters Defense Measures Zero Trust Architecture

Stopping Cloud Lateral Movement

Stopping Cloud Lateral Movement

Stopping Cloud Lateral Movement

Guardrails For Every Deploy

In the cloud, consistency is crucial: policy in code, minimal permissions, and visibility into drift.

For Stopping Cloud Lateral Movement, segmentation is the lever: explicit paths, deny-by-default, and controlled management.

This way, you maintain speed in the cloud without security depending on manual luck.

Immediate actions (15 minutes)

Why this matters

The core of Stopping Cloud Lateral Movement is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Defense Measures

Zero Trust Architecture

Principle                          Implementation
+-------------------------------+------------------------------------------+
| Verify explicitly             | MFA on all accounts, conditional access |
| Least privilege access        | JIT access, time-bound role assignments  |
| Assume breach                 | Micro-segmentation, monitoring            |
| Verify every transaction      | API-level authorization, not just authn  |
| Limit blast radius            | Account isolation, service boundaries    |
+-------------------------------+------------------------------------------+
# AWS: Implement permission boundaries
aws iam put-role-permissions-boundary \
  --role-name DeveloperRole \
  --permissions-boundary arn:aws:iam::111111111111:policy/DeveloperBoundary

# Azure: Implement Conditional Access
az rest --method POST \
  --url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
  --body '{
    "displayName": "Require MFA for role assumption",
    "state": "enabled",
    "conditions": {
      "applications": {"includeApplications": ["All"]},
      "users": {"includeRoles": ["ROLE_ID"]}
    },
    "grantControls": {
      "operator": "OR",
      "builtInControls": ["mfa"]
    }
  }'

Network Segmentation

# AWS: Restrictive security groups for peered VPCs
aws ec2 create-security-group \
  --group-name restricted-peering \
  --description "Only necessary traffic via peering" \
  --vpc-id vpc-abc123

aws ec2 authorize-security-group-ingress \
  --group-id sg-xyz789 \
  --protocol tcp \
  --port 443 \
  --cidr 10.1.0.0/24  # Only specific subnet, not entire VPC

# Azure: NSG at subnet level
az network nsg rule create \
  --nsg-name restricted-nsg \
  --resource-group prod-rg \
  --name deny-lateral \
  --priority 100 \
  --direction Inbound \
  --access Deny \
  --source-address-prefixes "10.0.0.0/8" \
  --destination-port-ranges "*"

Cross-Account Audit

# AWS: Organization-wide CloudTrail
aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name org-audit-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation

# Monitor AssumeRole events
aws logs filter-log-events \
  --log-group-name CloudTrail/org-trail \
  --filter-pattern '{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "*cross-account*" }'

# Azure: Activity Log forwarding to central SIEM
az monitor diagnostic-settings create \
  --name "central-audit" \
  --resource "/subscriptions/SUB_ID" \
  --logs '[{"category": "Administrative", "enabled": true}]' \
  --workspace "/subscriptions/SUB_ID/resourceGroups/rg/providers/Microsoft.OperationalInsights/workspaces/central-siem"

Reference Table

Technique MITRE ATT&CK AWS Azure GCP
Cross-account role assumption T1550.001 - Application Access Token sts:AssumeRole chains Lighthouse delegations Service account impersonation
Hybrid AD pivot T1078.004 - Cloud Accounts N/A Azure AD Connect, ADFS Google Cloud Directory Sync
SAML token forgery T1606.002 - SAML Tokens SAML federation abuse Golden SAML via ADFS SAML IdP compromise
OIDC federation abuse T1550.001 - Application Access Token Web Identity Federation Workload Identity Workload Identity Federation
SSRF to IMDS T1552.005 - Cloud Instance Metadata IMDSv1/v2 (169.254.169.254) IMDS (169.254.169.254) Metadata (metadata.google.internal)
Service-to-service pivot T1021.007 - Cloud Services Lambda→DynamoDB→S3 Function→Key Vault→SQL Function→Firestore→GCS
VPC peering exploitation T1599 - Network Boundary Bridging VPC Peering, Transit Gateway VNet Peering, vWAN VPC Network Peering
Managed identity abuse T1550.001 - Application Access Token EC2 instance profiles Managed Identity (system/user) Service account tokens
Multi-cloud credential reuse T1078.004 - Cloud Accounts Credentials in Secrets Manager Credentials in Key Vault Credentials in Secret Manager
Intune command push T1072 - Software Deployment Tools N/A (use SSM) Intune scripts/config N/A
PrivateLink abuse T1599.001 - Network Address Translation VPC Endpoints Private Endpoints Private Service Connect
VPN configuration theft T1120 - Peripheral Device Discovery Site-to-Site VPN configs VPN Gateway shared keys Cloud VPN tunnels
Container metadata T1552.005 - Cloud Instance Metadata ECS task metadata, EKS IRSA AKS pod identity GKE workload identity
Service mesh pivot T1021.007 - Cloud Services App Mesh exploitation N/A Anthos Service Mesh
Federation trust abuse T1484.002 - Trust Modification IAM OIDC providers External identity providers Workload Identity pools

In the cloud, you do not move from machine to machine. You move from trust to trust. And trust, as it turns out, is almost always misconfigured.

Further reading in the knowledge base

These articles in the portal give you more background and practical context:

You need an account to access the knowledge base. Log in or register.

These articles provide additional context and depth:

Op de hoogte blijven?

Ontvang maandelijks cybersecurity-inzichten in je inbox.

Gerelateerde artikelen

← Cloud Security ← Home