Skip to main content

Attack Path Investigation

beta feature

This topic describes functionality that is currently in beta.

Overview

The Path investigation page contains all detected attack paths and 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 or container image.

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.

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.

ColumnDescription
NameThe name of the attack path.
AccountThe cloud account associated with the asset.
Resource typeThe type of resource exposed in the attack path.
Path severityThe severity of the attack path. See Path Severity for details.
VulnerabilitiesThe number of vulnerabilities in the path.
SecretsThe number of exposed secrets in the path.
Compliance violationsThe 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, or a data asset such as an RDS instance. Badges depict the types of risks that make the path possible.

attack path polygraph

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

Attack paths to 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 (which 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 and has critical vulnerabilities.

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

rds two-hop attack path

For details about the contextualized information related to the attack path, see Detailed Attack Path Information.

Host

Attack paths to 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.

ec2 two-hop attack path

Hover over the EC2 instance node for additional information about the risks detected.

For details about the contextualized information related to the attack path, see Detailed Attack Path Information.

Container Image

Attack paths to an exposed container image can have one hop.

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

container image single-hop attack path

Hover over the container image node for additional information about the risks detected.

For details about the contextualized information related to the attack path, see Detailed Attack Path 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, container type, created time, size, container count, and machine count) and list of active containers (pod name, repository, pod namespace, Kubernetes cluster, PID)
  • Vulnerabilities - CVEs, severity, CVSS score, vulnerability impact score, and package name
  • 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, 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, failed logins), and bad login (IP address, username, count)
  • Active listening ports - Port number, machines, applications, 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 TypeExample 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.

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.

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.

rds two-hop attack path

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.

ec2 two-hop attack path

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.

container image single-hop attack path

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.