aws-ebs-volume-detach-reattach-write

id: aws-ebs-volume-detach-reattach-write
emits:
- CanWriteData
- CanModifyConfiguration
description: Detaching a volume from a victim instance, attaching it to an attacker-controlled instance,
  modifying the filesystem (cron, SSH keys, startup scripts), and re-attaching enables both data write
  and indirect CanModifyConfiguration on the victim instance. This is the inverse of aws-ebs-volume-mount-read.
match:
- - principal: null
  - CanWrite
  - volume: null
where:
- node_type(?volume) == BlockStorage
- '?principal has EFFECTIVE ec2:DetachVolume (scoped to the volume or Resource: *)'
- '?principal has EFFECTIVE ec2:AttachVolume (scoped to instances they control or Resource: *)'
- the caller has an EC2 instance in the same AZ as the volume to attach to (for reattachment to victim)
emit:
- source_type: Identity
  target_type: BlockStorage
  source: ?principal
  edge_type: CanWriteData
  permissions:
  - ec2:DetachVolume
  - ec2:AttachVolume
  conditions:
  - iam_permission
  - service_state
  - region_or_boundary
  state_logic: ACTIVE when both ec2:DetachVolume and ec2:AttachVolume are effective AND the caller has
    instances in the correct AZ for the cycle (detach from victim, attach to attacker instance, modify,
    re-attach to victim). CONDITIONAL(service_state) if victim instance is in a different AZ or if instances
    are not accessible. CONDITIONAL(region_or_boundary) if attachment crosses region/account boundaries.
  confidence: 0.85
  derived_from:
  - <CanWrite edge on ?volume>
  - Direct IAM evaluation of ec2:DetachVolume + ec2:AttachVolume
  narrative: '{principal.name} can detach {volume.name} from a victim instance, attach it to an attacker-controlled
    instance, write malicious data (cron jobs, SSH keys, startup scripts), and re-attach it to the victim.'
- source_type: Identity
  target_type: VirtualMachine
  source: ?principal
  edge_type: CanModifyConfiguration
  target: <victim instance the volume is attached to>
  permissions:
  - ec2:DetachVolume
  - ec2:AttachVolume
  conditions:
  - iam_permission
  - service_state
  - region_or_boundary
  state_logic: 'ACTIVE when both ec2:DetachVolume and ec2:AttachVolume are effective (same as CanWriteData
    case). The CanModifyConfiguration edge on the victim instance summarizes the meaningful escalation:
    by modifying the volume''s filesystem, the principal can change the victim instance''s behavior (persistence,
    code execution, lateral movement).'
  confidence: 0.85
  derived_from:
  - <CanWrite edge on ?volume>
  - Direct IAM evaluation of ec2:DetachVolume + ec2:AttachVolume
  linchpin_citations:
  - "can-control.yaml (escalation roll-up: CanModifyConfiguration + ExecutesAs \u2192 CanControl)"
  narrative: "{principal.name} can modify the filesystem of any instance running {volume.name} by the\
    \ detach-modify-reattach cycle, enabling persistence, code injection, and lateral movement. Feeds\
    \ into can-control.yaml for the CanModifyConfiguration \u2192 CanControl escalation."
  false_positive_note: This rule requires that the principal has instances in the same AZ as the target
    volume for the reattachment phase. If the principal's instances are in different AZs, the CanWriteData
    and CanModifyConfiguration edges downgrade to CONDITIONAL. Volume detachment may require the instance
    to be stopped (depending on the volume type and attachment state); check the victim instance's AttachedTo
    edges for constraints. The permissions must be scoped to allow both detach and attach operations;
    if scoped to existing volumes only, the principal cannot attach to new instances.