Skip to main content

Supported Attack Paths

Identities

Currently, only AWS identities are supported.

Admin

Internet → ... → IAM role

  • This attack path uses an admin IAM role.
  • The admin role is the path target node because if an attacker can get the admin role, they own the entire account. So Lacework does not calculate further hops after an admin IAM role.
  • If someone has an AWS organization SCP to reduce the permission of this role and if Lacework gets the SCP policy, then we determine net effective permissions. However, if SCP is not received (because of a missing AWS Config integration with the AWS organization management account, etc.), then the role is still full admin.

Admin Role Example

The following example depicts an attack path that uses an admin AWS IAM role.

Internet → Internet gateway → Security group → Host → IAM role

Non-admin

Internet → ... → Host → IAM role → Data asset

  • This attack path uses a non-admin IAM role associated with the host to reach the data asset (such as a group of S3 buckets) accessible by the role. If it is an admin role, then the path will resemble the admin role attack path.
  • To determine accessibility, Lacework considers the following:
    • The host → IAM Role portion means the IAM role associated with the host.
    • For the IAM Role → data asset portion, Lacework can cluster together all the assets accessible by the role.
    • GetObject permission from the IAM role and the permission allows accessing the target data asset.
    • The data asset resource policy does not block the role from accessing it.
  • An identity attack path supports an RDS instance as a target node, but an RDS cluster is not supported.

Non-admin Role Example

The following example depicts an attack path that uses a non-admin AWS IAM role associated with the EC2 instance to reach the group of S3 buckets accessible by the role.

Internet → Internet gateway → Security group → EC2 instance → IAM role → S3 bucket cluster

Container Images

Supported for:

  • AWS
  • Azure
  • Google Cloud

Internet → ... → Container image

  • The AWS container image could be directly exposed or indirectly exposed through a compromised asset (two-hop attack path).
  • Attack paths to Azure and Google Cloud container images are single-hop only.

Container Image Example

The following example depicts an attack path to a container image.

Internet → Internet gateway → Security group → Container image

  • The example shows the path from the internet through the internet gateway and security group and then to the container image.
  • The container image is directly exposed to the internet and has critical vulnerabilities.

Data Assets

Supported data assets:

  • Amazon RDS
  • Amazon S3
  • Azure Blob Storage
  • Azure Database (SQL, PostgreSQL)
  • Google Cloud SQL

Internet → ... → Data asset

  • The AWS data asset could be directly exposed or indirectly exposed through another compromised asset (two-hop attack path).
  • Attack paths for Azure and Google Cloud data assets are single-hop only.
note

In the attack path and Exposure Polygraph context, AWS RDS clusters and S3 clusters refer to Lacework-defined clusters of assets that an EC2 instance can access through an AWS role. The clusters are not AWS native clusters.

Data Asset Example

The following example depicts a two-hop attack path that traverses an AWS EC2 instance on the way to an RDS instance.

Internet → Internet gateway → Security group → EC2 instance → Security group → RDS

  • The example shows the path from the internet through the internet gateway and security group and then to the EC2 instance. If the EC2 instance becomes compromised, there is a path through a security group to the RDS instance.
  • The EC2 instance is directly exposed to the internet and has critical vulnerabilities.
  • The RDS instance is not directly exposed to the internet but is accessible by the EC2 instance.

Data Asset Example 2

The following example depicts an attack path to a publicly exposed Google Cloud SQL instance.

Internet → Firewall rule → Cloud SQL

  • The Cloud SQL instance is directly exposed to the internet.

Data Asset Example 3

The following example depicts an attack path to a publicly exposed Azure SQL database.

Internet → Security group → SQL

  • The SQL database is directly exposed to the internet.

Hosts

Supported hosts:

  • AWS EC2 instances
  • Azure Virtual Machines
  • Google Cloud Compute instances

Internet → ... → Host

  • The AWS host could be directly exposed or indirectly exposed through a compromised asset (two-hop attack path).
  • Attack paths to Azure and Google Cloud hosts are single-hop only.

Host Example

The following example depicts a single-hop attack path to an AWS host.

Internet → Internet gateway → Security group → EC2

  • The example shows the path from the internet through the internet gateway and the security group and then to the EC2 instance.
  • The instance is directly exposed to the internet and has critical vulnerabilities.

A similar attack path to a Google Cloud Compute instance would show a Compute instance as the host and a firewall rule instead of a security group.

Host Example 2

The following example depicts a two-hop attack path to an AWS host.

Internet → Internet gateway → Security group → EC2 → Security group → EC2

  • The example shows the path from the internet through the internet gateway and the security group and then to the first EC2 instance. If the first instance becomes compromised, there is a path through a security group to a second EC2 instance.
  • The first instance is exposed to the internet and has critical vulnerabilities.
  • The second instance is not directly exposed to the internet but is accessible from the first instance and has critical vulnerabilities.
note
  • In the host vulnerability report the second instance would be internet exposure = no because it isn't exposed to the internet directly. It requires the first instance to be accessed and compromised, it's still a potential attack path.
  • To open the single machine dossier and view a host's Exposure Polygraph, you can go to the Machine details tab under the EC2 Instance section and click the hostname.

Host Example 3

The following example depicts a single-hop attack path to an Azure host.

Internet → Load balancer → Security group → VM

  • The example shows the path from the internet through the load balancer and the security group and then to the VM.
  • The VM is directly exposed to the internet and has critical vulnerabilities.

Kubernetes Services

Supported K8s services for EKS and GKE:

  • Ingress
    Supported ingress controllers:
    • AWS Load Balancer Controller
    • Istio Ingress
    • NGINX Ingress Controller
    • Traefik Kubernetes Ingress provider
  • LoadBalancer
  • NodePort

Internet → ... → Kubernetes service

  • (EKS only) For Lacework to build attack paths to a Kubernetes service, node and cluster collectors must be installed. For installation steps, read how to set up node and cluster collectors.
    GKE does not require installing additional collectors.
  • (EKS only) The Kubernetes service could be directly exposed or indirectly exposed through a compromised asset (two-hop attack path).
    Attack paths to GKE K8s services are single-hop only.

Kubernetes Service Example

The following example depicts an attack path to a Kubernetes service.

Internet → Internet gateway → Security group → Kubernetes service

  • The example shows the path from the internet through the internet gateway and security group and then to the K8s service.
  • The K8s service is directly exposed to the internet and has critical vulnerabilities.

A similar attack path to a GKE K8s service would show a firewall rule instead of a security group.

Transit Gateways

Transit gateway support includes the following path type:

... → NLB → Transit gateway → NLB → ...