Private connections after revocation

PrivateLink, shared Amazon Virtual Private Cloud (VPC) subnets, and Transit Gateway separate creation permission from existing network state. This can leave an attacker with a foothold after a temporary access window closes: the endpoint, workload, or attachment already in place may remain usable even after its creation permission is gone. The surviving resource preserves network reachability, not a bypass of application authentication; access still depends on working routes, network controls, and any required application credentials.

Creation permission and connection state

flowchart LR
    A([Attacker gets temporary access]) --> C[Create private network path]
    C --> P[PrivateLink endpoint]
    C --> S[Workload in shared subnet]
    C --> T[Transit Gateway attachment]
    D([Defender revokes sharing permission]) --> N[Creation grants removed]
    D -. existing path survives .-> P
    D -. existing path survives .-> S
    D -. existing path survives .-> T
    P --> O([Traffic can keep flowing])
    S --> O
    T --> O
    class A,D,O principal
    class C,P,S,T,N awsResource

The contractor endpoint survives revocation

A company exposes an internal deployment API through PrivateLink. During a contractor’s migration access window, an attacker compromises a role in the allowlisted account.

The attacker creates an interface endpoint and waits for it to become available, while also obtaining an application credential accepted by the deployment API. When the migration ends, the provider removes the contractor account from the endpoint service’s allowed principals and receives a successful API response.

Removing the contractor’s only effective creation grant blocks another endpoint request, but does not reject the previously accepted connection.^[1] API access can continue while the network path and application credential remain usable; a permission-change response alone does not establish either continued access or completed containment.

Conditions for continued access

The attacker must make the network object usable before revocation. That requires:

• Temporary access to create the endpoint, workload, or attachment.
• Enough permission in the participant account to create that exact resource.
• A working route, security group, network ACL, and application protocol.
• Time for the network object to reach a usable state before access is revoked.

The endpoint or attachment preserves only the network path. Application authentication remains in force; valid routes, network controls, and application credentials still determine what can cross it.

PrivateLink endpoint connections

Removing an allowed principal does not reject an endpoint connection that was already accepted. Allowed principals can be accounts, roles, users, or *; removing one entry does not necessarily remove all effective creation permission. Manual acceptance controls connection admission, not application authentication or the termination of previously accepted connections.^[1:1]

AWS_PROFILE=provider aws ec2 modify-vpc-endpoint-service-permissions \
  --service-id "$ENDPOINT_SERVICE_ID" \
  --add-allowed-principals "arn:aws:iam::$CONSUMER_ACCOUNT_ID:root"

ENDPOINT_ID=$(AWS_PROFILE=consumer aws ec2 create-vpc-endpoint \
  --vpc-endpoint-type Interface \
  --vpc-id "$CONSUMER_VPC_ID" \
  --service-name "$ENDPOINT_SERVICE_NAME" \
  --subnet-ids "$CONSUMER_SUBNET_ID" \
  --security-group-ids "$CONSUMER_SECURITY_GROUP_ID" \
  --query 'VpcEndpoint.VpcEndpointId' --output text)

until [[ "$(AWS_PROFILE=consumer aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids "$ENDPOINT_ID" \
  --query 'VpcEndpoints[0].State' --output text)" == "available" ]]; do
  sleep 5
done

AWS_PROFILE=provider aws ec2 modify-vpc-endpoint-service-permissions \
  --service-id "$ENDPOINT_SERVICE_ID" \
  --remove-allowed-principals "arn:aws:iam::$CONSUMER_ACCOUNT_ID:root"

AWS_PROFILE=consumer aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids "$ENDPOINT_ID" \
  --query 'VpcEndpoints[0].{State:State,DNS:DnsEntries[0].DnsName}'

Resources in shared VPC subnets

VPC subnet sharing lets a participant account place its own resources in a subnet owned by another account. When unsharing completes and no other effective share grants access, the participant loses permission to create new resources. Existing participant resources keep running, and the participant can still describe, modify, and delete them. Managed workflows such as scaling or node replacement may still need continuous access to the shared subnet.^[3][4]

The participant-owned workload and its elastic network interface (ENI) preserve the network foothold for as long as they remain active.

SHARE_ARN=$(AWS_PROFILE=owner aws ram create-resource-share \
  --name shared-subnet-window \
  --resource-arns "$SUBNET_ARN" \
  --principals "$PARTICIPANT_ACCOUNT_ID" \
  --no-allow-external-principals \
  --query 'resourceShare.resourceShareArn' --output text)

INSTANCE_ID=$(AWS_PROFILE=participant aws ec2 run-instances \
  --image-id "$AMI_ID" \
  --instance-type t3.nano \
  --subnet-id "$SHARED_SUBNET_ID" \
  --security-group-ids "$SECURITY_GROUP_ID" \
  --query 'Instances[0].InstanceId' --output text)

AWS_PROFILE=participant aws ec2 wait instance-running \
  --instance-ids "$INSTANCE_ID"

AWS_PROFILE=owner aws ram disassociate-resource-share \
  --resource-share-arn "$SHARE_ARN" \
  --resource-arns "$SUBNET_ARN"

AWS_PROFILE=participant aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].State.Name'

Shared Transit Gateway attachments

A participant can create a VPC attachment while a Transit Gateway is shared through RAM. The owner can later unshare the gateway, but AWS explicitly leaves that attachment functional.^[5]

After unsharing, the participant can no longer describe the Transit Gateway. Revocation runbooks must also inspect the attachment inventory.

SHARE_ARN=$(AWS_PROFILE=owner aws ram create-resource-share \
  --name transit-gateway-window \
  --resource-arns "$TRANSIT_GATEWAY_ARN" \
  --principals "$PARTICIPANT_ACCOUNT_ID" \
  --no-allow-external-principals \
  --query 'resourceShare.resourceShareArn' --output text)

ATTACHMENT_ID=$(AWS_PROFILE=participant \
  aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id "$TRANSIT_GATEWAY_ID" \
  --vpc-id "$PARTICIPANT_VPC_ID" \
  --subnet-ids "$PARTICIPANT_SUBNET_ID" \
  --query 'TransitGatewayVpcAttachment.TransitGatewayAttachmentId' \
  --output text)

AWS_PROFILE=owner aws ec2 accept-transit-gateway-vpc-attachment \
  --transit-gateway-attachment-id "$ATTACHMENT_ID"

until [[ "$(AWS_PROFILE=owner \
  aws ec2 describe-transit-gateway-vpc-attachments \
  --transit-gateway-attachment-ids "$ATTACHMENT_ID" \
  --query 'TransitGatewayVpcAttachments[0].State' \
  --output text)" == "available" ]]; do
  sleep 5
done

AWS_PROFILE=owner aws ram disassociate-resource-share \
  --resource-share-arn "$SHARE_ARN" \
  --resource-arns "$TRANSIT_GATEWAY_ARN"

AWS_PROFILE=owner aws ec2 describe-transit-gateway-vpc-attachments \
  --transit-gateway-attachment-ids "$ATTACHMENT_ID" \
  --query 'TransitGatewayVpcAttachments[0].State'

Finding objects left after revocation

Use revocation requests to trigger reconciliation, not as proof of completed revocation. Confirm the intended permission or RAM association change, inspect per-resource failures, and then check the current endpoint, workload, or attachment state. EC2 and RAM management events identify the requests, not downstream application activity.^{[7][8][9][2:1]}

For PrivateLink, retain the actor and service identifier from ModifyVpcEndpointServicePermissions. This fragment is attribution and service context only: it identifies neither a removed principal nor a successful removal. Establish the actual change with allowed-principal inventories rather than inferring revocation from the event name.^[10][11]

{
  "eventSource": "ec2.amazonaws.com",
  "eventName": "ModifyVpcEndpointServicePermissions",
  "userIdentity": { "arn": "<provider identity ARN>" },
  "requestParameters": {
    "ModifyVpcEndpointServicePermissionsRequest": {
      "ServiceId": "<endpoint service ID>"
    }
  }
}

Use before-and-after DescribeVpcEndpointServicePermissions inventories to identify which entries were actually removed, then evaluate current effective permission, including account-wide, role, user, and wildcard grants. Without a prior inventory or supported removal evidence, the event above cannot establish a removal. Compare that result with DescribeVpcEndpointConnections: vpcEndpointOwner identifies the endpoint’s owning account, not its creating role or user. Do not equate the provider actor with the consumer or compare an account ID directly with every principal ARN. Identity-specific attribution needs separate creation evidence; account-level inventory alone cannot identify the affected role or user.^{[1:3][11:1][12][13]}

For RAM, resolve the changed share’s resources, principals, and source constraints, including organization or organizational-unit membership and overlapping shares. Check each association for completed DISASSOCIATED state rather than treating DISASSOCIATING or FAILED as effective revocation. Join the affected accounts and resources to current participant ENIs or instances and Transit Gateway attachments, retaining Region and owner-versus-participant account context. An organization trail may record creation in the participant account and revocation in the owner account.^[9:1][14]

Track usable objects that remain after the intended revocation is effective until they are removed, contained, or explicitly approved. Use event time and current state, tolerate late or out-of-order events, and revisit the correlation when lifecycle or credible activity evidence changes. A transitional object or a deleted attachment still visible in inventory is not proof of usable access; deleted Transit Gateway attachments remain visible for two hours. Review current routes, network controls, ownership, and application authentication separately from inventory presence, and distinguish surviving network reachability from observed application requests.^[6:1]

Completing revocation

Remove or isolate the live network object as well as the sharing permission:

• PrivateLink: reconcile the effective allowed principals and enumerate the affected endpoint connections. Request rejection of unapproved connections, inspect unsuccessful results per endpoint, and confirm completed rejection or deletion before declaring the connection removed.^[1:4][2:2]
• Shared subnet: inventory participant-owned instances and ENIs before unsharing and arrange termination through the participant account. The subnet owner can describe participant ENIs but cannot otherwise manage them or modify participant-owned security groups. Owner-controlled routes and network ACLs can constrain paths crossing subnet boundaries, with potential impact on other workloads; network ACLs do not filter same-subnet traffic. Use controls on protected destination resources and revoke application credentials where participant resources cannot be promptly removed, then verify the intended paths are contained.^[15][16]
• Transit Gateway: delete unapproved VPC attachments and confirm completed deletion, distinguishing deleting and deleted-but-visible inventory from live attachments. Reconcile route-table associations and propagations as well; an accepted deletion request is not completed containment.^[6:2]
• Application layer: revoke the API token, certificate, or identity used over the private path. Network access should never be the only authorization check.

References