TransitGateway

A Direct Connect Gateway-to-TransitGateway association spanning account boundaries establishes network-layer trust (on-prem has routed path into remote account's VPCs).

A Direct Connect Gateway with an accepted association to a TransitGateway routes on-premises traffic to the TGW and its attached VPCs.

IAM principal with Direct Connect write actions can create or modify virtual interfaces and DXGW associations, altering which networks have a routed path into AWS VPCs (network topology manipulation). Covers constructive/expansive actions only (Create, Update, Accept); Delete actions are modeled separately as CanDelete.

A private or transit Direct Connect Virtual Interface in AVAILABLE state routes the on-premises network into the attached VGW or DXGW, establishing a non-internet routed path from on-prem into AWS private address space.

A shared Transit Gateway enables the consumer VPC to reach owner-account resources attached to the TGW, derived from the CrossAccountTrust fact and confirmed TGW attachments.

A principal with ec2:AssociateTransitGatewayRouteTable or ec2:EnableTransitGatewayRouteTablePropagation can silently re-route an attachment to a permissive route table or add a propagation that opens routing between otherwise-isolated VPCs - a quiet network-isolation bypass. Modeled as CanModifyConfiguration on the TransitGateway node.

A consumer-account VPC with a confirmed (state==available) attachment to an owner-account Transit Gateway has L3 network reachability to subnets in the owner account (subject to TGW route table routing and L4 security group evaluation). This is a network-layer foothold (CanNetworkReach), not control-plane account entry (CanEnterAccount).

A principal with ec2:AcceptTransitGatewayVpcAttachment can accept a pending attachment request, transitioning the VPC connection to active routing status.

A principal with ec2:CreateTransitGatewayVpcAttachment can initiate a VPC attachment request to a Transit Gateway, expanding the VPC's routing domain to the TGW network (if the attachment is accepted).

Write access to the Virtual WAN or Virtual Hub object (virtualWans/write or virtualHubs/write, both included in Network Contributor) grants full control of the vWAN topology, all hub connections, route tables, gateways, and routing policy.

An active ExpressRoute connection (expressRouteConnections, provisioningState=Succeeded) is an explicit routing fact: the Virtual Hub routes traffic to and from the on-premises network via the ExpressRoute circuit. NOTE - Semantic Extension: RoutesTo normally targets [Network, Subnet]. On-premises networks may not exist as discrete nodes in the collected inventory if they are not explicitly modeled as Network nodes. In this case, the target is the ExpressRoute Circuit (TransitGateway) representing the on-premises reachability point. The network-chains linchpin must handle TransitGateway targets of RoutesTo as a special case distinct from Network/Subnet targets, treating them as proxies for external networks.

Write access to hub VNet connections (hubVirtualNetworkConnections/write) lets an attacker attach a new spoke VNet to the hub, inserting an attacker-controlled VNet into the transit topology and gaining network-layer reach to all existing connected resources, or detach an existing spoke to disrupt connectivity.

Write access to hub route tables (hubRouteTables/write) lets an attacker inject custom routes redirecting spoke traffic through an attacker-controlled next hop (NVA/VM), enabling network interception or MitM within the vWAN transit topology.

Write access to hub routing intent policies (routingIntentPolicies/write) lets an attacker modify inter-hub and internet traffic routing, redirecting traffic flows through attacker-controlled firewalls or NVAs or disabling firewall inspection entirely.

An active hub VNet connection (hubVirtualNetworkConnections, provisioningState=Succeeded) is an explicit routing fact: the Virtual Hub routes traffic to and from the connected spoke VNet.

An active S2S VPN connection (vpnConnections, connectionStatus=Connected) is an explicit routing fact: the Virtual Hub routes traffic to and from the on-premises branch via the VPN tunnel.

A principal with effective networkconnectivity.hubs.update on a hub can disable the spoke acceptance gate by setting requireAcceptance=false. This eliminates the approval gate, auto-accepting all PENDING_REVIEW spokes (including attacker-controlled ones) immediately and placing them on the routing fabric without manual review.

A principal with effective networkconnectivity.spokes.create on a hub that does not require manual spoke acceptance (requireAcceptance=false) can attach an attacker-controlled VPC, VPN, or Interconnect to the hub's routing domain. The spoke becomes ACTIVE immediately, placing the attacker's network on the same routing fabric as all legitimate spoke- attached networks - a transit pivot without modifying any VPC firewall rule in the destination projects.

A principal with effective networkconnectivity.spokes.update on the hub project can accept PENDING_REVIEW spokes that are awaiting hub approval. If an attacker has created a pending spoke attaching their VPC to the hub, a compromised hub-project identity can immediately accept it, placing the attacker's network on the routing fabric without requiring hub owner approval.

A source whose subnet routes to the destination's subnet (intra-VPC/VNet routing) reaches the destination when its ingress rule admits the source.

A source reaches a destination through a shared transit hub (Transit Gateway/VWAN/NCC/Direct Connect gateway/VPN gateway) that forwards between attachments - transitive across the hub's associated route table.