Attack Path Investigation

Overview

The Path investigation page contains all detected attack paths, their associated Attack Path Polygraphs, and contextualized information about the attack path so you can investigate and review issues. The Attack Path Polygraph provides attack path analysis for investigation by adding in-depth risk context. Generating an Attack Path Polygraph requires the existence of attack path risk factors that allow Lacework to build a path on the workload. Currently, Lacework generates an attack path only if a critical vulnerability is associated with the host instance, container image, RDS instance, or Kubernetes service and they are exposed to the internet.

View Attack Paths

Click an attack path to see its Attack Path Polygraph and related information.

By default, the page displays critical and high severity attack paths across your environment. Attack paths are sorted by their path severity in descending order.

Filters and Search

To target specific areas or resources, use the following methods:

• Click a filter dropdown, select items, and click Show results to make them active. To remove an active filter, click the filter and then click Reset or deselect items. One filter can be active at a time.
• Use the search function to find specific text in the details that are available for attack paths.

Attack Path List

Each attack path has the following details.

tip

The attack path data represents aggregated counts for all nodes in the attack path, not just the host listed.

Column	Description
Name	The name of the attack path.
Account	The cloud account associated with the asset.
Resource type	The type of resource exposed in the attack path.
Path severity	The severity of the attack path. See Path Severity for details.
Vulnerabilities	The number of vulnerabilities in the path.
Secrets	The number of exposed secrets in the path.
Compliance violations	The number of compliance violations in the path.

note

Multiple attack paths can have the same name with different attack path severities, but they are associated with different asset criteria (hostname, container image).

Attack Path Polygraph

The Attack Path Polygraph indicates that there is a potential attack path to your cloud environment assets. The Attack Path Polygraph visually displays the exact attack path a potential attacker could use to access those assets.

The Attack Path Polygraph uses nodes to represent each step along the path. Possible nodes depend on what the attack path endpoint is: host, container image, Kubernetes service, or a data asset such as an RDS instance. Badges depict the types of risks that make the path possible.

For additional information, hover over a node that has badges. Possible badges:

• Vulnerabilities
• Secrets
  • SSH keys
  • API keys
  • Passwords
• Compliance/misconfiguration

Attack Path Types

Attack paths can have one of the following as an endpoint (the final node in the path):

• Data asset (RDS)
• Host (EC2 instance)
• Container image
• Kubernetes service

Data Asset

Attack paths terminating in an exposed RDS instance can have one hop or two hops.

• A single-hop path has an RDS instance that is directly exposed to the internet and has critical vulnerabilities/compliance violations.
• A two-hop path traverses an EC2 instance or a Kubernetes service (the instance or service is exposed to the internet and has critical vulnerabilities/compliance violations) before reaching the RDS instance that is the endpoint. The RDS instance is not directly exposed to the internet but is accessible from the EC2 instance or Kubernetes service and has critical vulnerabilities.

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

For details about the contextualized information related to the attack path, see detailed RDS information.

Host

Attack paths terminating in an exposed host can have one hop or two hops.

• A single-hop path has an EC2 instance that is directly exposed to the internet and has critical vulnerabilities/compliance violations.
• A two-hop path traverses an EC2 instance (which is exposed to the internet and has critical vulnerabilities/compliance violations) before reaching a second EC2 instance that is the endpoint. This second EC2 instance is not directly exposed to the internet but is accessible from the first EC2 instance and has critical vulnerabilities.

The following example illustrates a two-hop attack path to an EC2 instance.

For details about the contextualized information related to the attack path, see detailed EC2 information.

Container Image

Attack paths terminating in an exposed container image can have one hop.

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

For details about the contextualized information related to the attack path, see detailed container image information.

Kubernetes Service

Attack paths terminating in an exposed Kubernetes service can have one hop.

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

For details about the contextualized information related to the attack path, see detailed Kubernetes information.

Detailed Attack Path Information

Container Image

This section displays for container paths only and provides tabs with the following contextualized information.

• Image details - Separate tables for container images (repository, image tag, container type, created time, size, container count, machine count, user count, OS, vulnerabilities, image scan status, and scan action) and list of active containers (container ID, pod name, pod namespace, start time, Kubernetes cluster, hostname, vulnerabilities, and image repository)
• Vulnerabilities - CVE, severity, score, package name, current version, fix version, and introduced in layer
• Hosts - A list of hosts (each linked to a single machine dossier) that the container image has run on with associated information: IAM role, vulnerabilities, secrets, and compliance violations.

EC2 Instance

This section displays for host attack paths only and provides tabs with the following contextualized information.

• Machine details - Separate tables for machine properties (hostname, IP address, and any associated vulnerabilities) and machine tab summary (tag name and tag value)
• Vulnerabilities - CVEs, severity, CVSS score, vulnerability impact score, and package name
• Secrets - Secret type (can be SSH key, API key, or password), identifier, file path, and number of connected resources
• Compliance violations - Failed policy, ID, status, and severity
• Users - Separate tables for user login activity (username, hostname, login time, logoff time, source IP), user authentication summary (username, user ID, successful logins, and failed logins), and bad login (IP address, username, and count)
• Active listening ports - Port number, machines, applications, and protocol

Secrets Detection

note

Secrets detection is available only when agentless workload scanning (AWLS) integration is enabled.

Lacework logs details about any secret credentials and associated file metadata. The files are identified as secrets if they adhere to a common format (the format depends on the type of credential). The actual content of any secret credentials is not logged.

The table lists the types of credentials detected and example filesystem locations:

Credential Type	Example Filesystem Locations
SSH private keys	/home/ec2-user/.ssh/id_rsa
AWS Access Key IDs (if a secret key is associated)	/home/ec2-user/.aws/credentials /root/.aws/credentials
GCP Service Account and User Credentials files	/etc/keys.json /home/user/.config/gcloud/keys.json
Kubernetes user tokens and certificate private keys	/root/.kube/config /home/user/.kube/config
Authorized Keys files	/home/user/.ssh/authorized_keys /root/.ssh/authorized_keys
Authentication log	/var/log/auth.log

note

While the authorized_keys and auth.log files are not secrets, the data is used in combination with the detection of SSH private keys to determine whether keys are authorized and/or used on hosts.

Kubernetes Service

info

Kubernetes agent collectors are required to view Kubernetes service attack paths. Read how to set up Kubernetes agent collectors.

This section displays for Kubernetes service attack paths only and provides tabs with the following contextualized information.

The Kubernetes agent collector data provides service, pod, and node resources. The data identifies the workload that owns each pod. Each service lists the container images that its pods run. The vulnerability count for the service is the sum of the vulnerabilities in its containers.

• Service details - Separate tables for properties (cluster name, name, namespace, type (LoadBalancer | NodePort), workload name, workload kind, pod count, and creation time) and label summary
• Vulnerabilities - Repository, vulnerability, package, package namespace, severity, CVSS score, package status, current version, and fix version
• Exposed ports - Name, node port (where the container is exposed), target port (where the container listens), protocol, and container
• Container images - Container name, container image name, image ID, and port count

Security Group

This section provides contextualized information related to security group configuration and CloudTrail logs. This provides full details for the security group to give additional context on exposed services. Separate tables for inbound and outbound rules contain the following information: type, protocol, port range, source, and description.

Security groups in multi-hop attack paths can have an additional level of selections. To view the JSON version, click View JSON file. Viewing the JSON gives you the option to see its details in the AWS console and to the download the JSON file.

Load Balancer

This section provides contextualized information related to load balancer configuration and CloudTrail logs. To view the JSON version, click View JSON file. Viewing the JSON gives you the option to see its details in the AWS console and to the download the JSON file.

RDS

This section shows the RDS configuration history. To view the JSON version, click View JSON file. Viewing the JSON gives you the option to see its details in the AWS console and to the download the JSON file.

Path Generation

Basics

The Attack Path Polygraph requires the existence of attack path risk factors that allow Lacework to build a path on the workload. Currently, Lacework generates an attack path only if a critical vulnerability is associated with the host instance or container image.

Path Support

• The Attack Path Polygraph supports single-hop and two-hop paths.
• Single-hop paths can traverse nodes such as public, ELBv1, NLB, ALB, two-level cascading ELB to the exposed asset.
• Two-hop paths can have RDS or EC2 instances as endpoints.
• Lacework uses path reduction, which occurs when a node that appears in a longer path doesn't have a path with itself as an ending node. Lacework builds the RDS endpoint paths first, followed by EC2 endpoint paths.

Network Considerations

• Lacework builds paths within the same VPC only.
• The second hop covers both intra-subnet and inter-subnet routes.
• For second hops, Lacework checks bi-directional security group settings between the first hop and second hop entities (ingress rules only). If both source and destination allow the traffic, the path is valid.
• Lacework checks NACL for both ingress and egress denies and if the rule explicitly denies the traffic between the two subnets, then Lacework won't build the attack path.
• Lacework builds route analysis and checks internet gateway routing to determine internet reachability.
• For inter-subnet routability, in AWS typically all subnets within the same VPC can reach each other based on a route table.

Example Attack Paths

Two-hop Path to an RDS Instance

The following two-hop attack path traverses an EC2 instance on the way to the RDS instance endpoint.

The example illustrates the following:

• The Attack Path Polygraph 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.
• Two badges above the instance indicate that the instance has issues.
• The EC2 instance is exposed to the internet and has critical vulnerabilities and compliance violations.
• The RDS instance is not directly exposed to the internet but is accessible by the EC2 instance above.
• The counts in the table represent the combined total found across all nodes in the attack path.

Additional information

• 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.

Two-hop Path to an EC2 Instance

The following two-hop attack path traverses an intermediate EC2 instance on the way to an EC2 instance endpoint.

The example illustrates the following:

• The Attack Path Polygraph 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.
• Two badges above the first instance and one badge above the second instance indicate that both instances have issues.
• The first instance is exposed to the internet and has critical vulnerabilities and compliance violations.
• The second instance is not directly exposed to the internet but is accessible from the first instance and has critical vulnerabilities.
• The counts in the table represent the combined total found across all nodes in the attack path. For example, the number of vulnerabilities is the combined total for both instances.

Additional information

• 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.

Single-hop Path to a Container Image

The following single-hop attack path has a container image as the endpoint.

The example illustrates the following:

• The Attack Path Polygraph shows the path from the internet through the internet gateway and security group and then to the container image.
• The container image is exposed to the internet and has critical vulnerabilities.
• The counts in the table represent the combined total found across all nodes in the attack path.

Single-hop Path to a Kubernetes Service

The following single-hop attack path has a Kubernetes service as the endpoint.

The example illustrates the following:

• The Attack Path Polygraph shows the path from the internet through the internet gateway and security group and then to the K8s service.
• The K8s service is exposed to the internet and has critical vulnerabilities.
• The counts in the table represent the combined total found across all nodes in the attack path.