gcp-filestore-backup-exfiltrate

A principal holding file.backups.get in the source project plus file.instances.create or file.instances.update in an attacker-controlled destination project can restore a Filestore backup to the destination, exfiltrating all data. This is a multi-project, multi-permission escalation path documented as one of the three central attack primitives for Filestore.

derived gcp emits CanExfiltrate

match

A conjunctive graph pattern. Variables (?x) bind node ids; every clause must hold.

{'principal': None} HasPermission file.backups.get {'backup': None} LocatedIn {'source_project': None} {'principal': None} HasPermission file.instances.create

where

node_type(?backup) == Backup ?backup.sourceInstance references ?source_instance: node_type(?source_instance) == FileStorage the third HasPermission edge (?principal -> file.instances.create) is scoped to ?dest_project ?principal controls ?dest_project (or is a member of a compromised account there) ?dest_project != ?source_project

emit

source typeIdentity
target typeBackup
source?principal
target?backup
permissionsfile.backups.get file.instances.create file.instances.update
conditionsiam_permission
state logicACTIVE when both conditions hold: (a) file.backups.get is effective in the source project AND (b) file.instances.create or file.instances.update is effective in the destination project at the same principal scope, AND the destination project is under attacker control. CONDITIONAL(iam_permission) if one permission is confirmed but the other scope is unresolved (e.g. destination- project grant not yet discovered). BLOCKED if an IAM deny policy denies either permission at the effective scope.

Narrative

{principal.name} holds file.backups.get in {source_project.name} and file.instances.create in {dest_project.name}, and can restore the {backup.name} backup to an instance in the destination project, exfiltrating all data from the original {source_instance.name} Filestore instance.

Raw rule rules/derived/gcp/filestore.yaml

id: gcp-filestore-backup-exfiltrate
emits: CanExfiltrate
description: A principal holding file.backups.get in the source project plus file.instances.create or
  file.instances.update in an attacker-controlled destination project can restore a Filestore backup to
  the destination, exfiltrating all data. This is a multi-project, multi-permission escalation path documented
  as one of the three central attack primitives for Filestore.
match:
- - principal: null
  - HasPermission
  - file.backups.get
- - backup: null
  - LocatedIn
  - source_project: null
- - principal: null
  - HasPermission
  - file.instances.create
where:
- node_type(?backup) == Backup
- '?backup.sourceInstance references ?source_instance: node_type(?source_instance) == FileStorage'
- the third HasPermission edge (?principal -> file.instances.create) is scoped to ?dest_project
- ?principal controls ?dest_project (or is a member of a compromised account there)
- ?dest_project != ?source_project
emit:
  source_type: Identity
  target_type: Backup
  source: ?principal
  target: ?backup
  permissions:
  - file.backups.get
  - file.instances.create
  - file.instances.update
  conditions:
  - iam_permission
  state_logic: 'ACTIVE when both conditions hold: (a) file.backups.get is effective in the source project
    AND (b) file.instances.create or file.instances.update is effective in the destination project at
    the same principal scope, AND the destination project is under attacker control. CONDITIONAL(iam_permission)
    if one permission is confirmed but the other scope is unresolved (e.g. destination- project grant
    not yet discovered). BLOCKED if an IAM deny policy denies either permission at the effective scope.'
  confidence: 0.95 when both permissions confirmed and projects verified as distinct
  derived_from:
  - gcp-filestore-backup-exfiltrate
  false_positive_note: 'Both permissions are REQUIRED: read access to the backup in source project + write/create
    access to instances in destination project at the same principal scope. Confirm the principal (or
    a group it belongs to) holds both permissions at the right scopes and the destination project is controlled
    by the attacker (or can be reached via compromise chain). Backups are regional artifacts; the restore
    can target any GCP region. All data in the backed-up instance is exfiltrated; this is not filtered
    by IAM or access controls on the destination share. If destination-project permission is unresolved,
    do not emit as ACTIVE.'
  narrative: '{principal.name} holds file.backups.get in {source_project.name} and file.instances.create
    in {dest_project.name}, and can restore the {backup.name} backup to an instance in the destination
    project, exfiltrating all data from the original {source_instance.name} Filestore instance.'
move · open · esc close