azure-synapse-execute-as-via-ir-key

Retrieve IR auth key (CanReadSecret) + register a self-hosted IR node the attacker controls -> that node executes pipeline activities as the workspace MI. No generic linchpin covers this path; rule is Synapse-specific.

derived azure emits CanExecuteAs

match

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

where

emit

source type	`Identity`
target type	`Identity`
source	`<principal>`
target	`<workspace managed identity>`
permissions	`Microsoft.Synapse/workspaces/integrationRuntimes/listAuthKeys/action`
conditions	`service_state`
state logic	CONDITIONAL(service_state): the attacker must register an IR node with the stolen key AND a pipeline must be triggered that routes through that IR. If the IR already has a trigger/scheduled pipeline using it, ACTIVE once the node is registered. Requires the self-hosted IR to accept the new node registration (node registration is gated by IR admin settings).

source type

Identity

target type

Identity

source

<principal>

target

<workspace managed identity>

permissions

Microsoft.Synapse/workspaces/integrationRuntimes/listAuthKeys/action

conditions

service_state

state logic

CONDITIONAL(service_state): the attacker must register an IR node with the stolen key AND a pipeline must be triggered that routes through that IR. If the IR already has a trigger/scheduled pipeline using it, ACTIVE once the node is registered. Requires the self-hosted IR to accept the new node registration (node registration is gated by IR admin settings).

Narrative

{principal.name} retrieved IR auth key for integration runtime in workspace {workspace.name} (listAuthKeys/action); by registering an attacker-controlled self-hosted IR node, pipeline activities executing on that IR run as workspace MI {mi.name}.

Raw rule rules/derived/azure/synapse.yaml

id: azure-synapse-execute-as-via-ir-key
emits: CanExecuteAs
description: Retrieve IR auth key (CanReadSecret) + register a self-hosted IR node the attacker controls
  -> that node executes pipeline activities as the workspace MI. No generic linchpin covers this path;
  rule is Synapse-specific.
match:
- - principal: null
  - CanReadSecret
  - irKey: null
- - workspace: null
  - ExecutesAs
  - mi: null
where:
- 'node_type(?irKey) == Credential  # IR auth key'
- ?irKey belongs to an integration runtime in ?workspace
- node_type(?workspace) == AnalyticsService
- ?mi.privilege_level >= ?principal.privilege_level
emit:
  source_type: Identity
  target_type: Identity
  source: <principal>
  target: <workspace managed identity>
  permissions:
  - Microsoft.Synapse/workspaces/integrationRuntimes/listAuthKeys/action
  conditions:
  - service_state
  state_logic: 'CONDITIONAL(service_state): the attacker must register an IR node with the stolen key
    AND a pipeline must be triggered that routes through that IR. If the IR already has a trigger/scheduled
    pipeline using it, ACTIVE once the node is registered. Requires the self-hosted IR to accept the new
    node registration (node registration is gated by IR admin settings).'
  derived_from:
  - <CanReadSecret edge_id>
  - <ExecutesAs edge_id>
  false_positive_note: This path requires the attacker to control a machine that can run the self-hosted
    IR agent and register it with the stolen key. It is CONDITIONAL by default because that external step
    is not observable from Azure API data. Only emit ACTIVE if evidence of an existing attacker-controlled
    IR node is confirmed (out of band). Only applicable for workspaces with self-hosted IR (not Azure-hosted
    AutoResolve IR).
  narrative: '{principal.name} retrieved IR auth key for integration runtime in workspace {workspace.name}
    (listAuthKeys/action); by registering an attacker-controlled self-hosted IR node, pipeline activities
    executing on that IR run as workspace MI {mi.name}.'