Cloud Anomaly Detection Demo

Feature Not Yet Released

This page is intended for customers with early access to the Cloud Anomaly Detection feature, which is not generally available (GA) yet. We request that you do not share this URL/page outside of the Rapid7 organization or with customers that do not have early access.

If you have questions, issues, or suggestions about the content provided here, we are happy to receive feedback.

Reach out to your CSM or to support through the Customer Support Portal.

InsightCloudSec includes a few, self-contained demos that you can run in your cloud environment to visualize simulated malicious behavior in Cloud Anomaly Detection. The demos leverage AWS CloudFormation Templates (CFTs) to automatically set up the necessary services and simulation behavior in minutes.

The demos can help show the immediate value of Cloud Anomaly Detection, without needing the feature to be enabled and running in your environment consistently for a long period of time. Because the demos are only a simulation, they don't pose any risk to your environment. For more information on Cloud Anomaly Detection, consult the feature overview documentation.

Prerequisites

  • AWS cloud account and the appropriate permissions to run CloudFormation Templates (CFTs)
  • InsightCloudSec running with Cloud Anomaly Detection configured
    • Ensure there are no errors for the audit log associated with the Cloud Anomaly Detection-configured AWS account
  • Data events are logged for the S3 buckets involved in the demos

Run the demos

These demos are available:

  • Unauthorized access pattern - This demo simulates an attacker successfully assuming a role with access to one or more S3 buckets, and then stealing and encrypting the data found within the buckets.
  • Unusual database activity attack - This demo simulates an attacker successfully assuming a role with access to one or more DynamoDB tables, and then contaminating the tables while also stealing their data.
  • Unusual search account activity - This demo simulates an attacker using a stolen account ID from a public S3 bucket to access additional S3 buckets.

Each of the demos takes 20 to 30 minutes to run.

Cloud Anomaly Detection demos simulate malicious activity

These demos simulate malicious activity, so we recommend running them in a non-critical environment.

Unauthorized access pattern

Two distinct CFTs divide the unauthorized access pattern demo into a initialization phase and an attacker phase:

  1. R7-ICS-CFT-Trailblazer-Demo-Start-Access-Pattern.yaml - CFT that creates basic profiling and baseline activity for the anomaly engine on the role that will be assumed by the simulated attacker. The profiling should run for at least 24 hours before running the attacker CFT. The baseline activity is generated from a Lambda function that assumes a role and writes data to several S3 buckets every few minutes. This simulates a periodic backup job.
  2. R7-ICS-CFT-Trailblazer-Demo-Attack-Access-Pattern.yaml - CFT that simulates the attack using the role created using the first CFT. When the attack phase begins, the simulated attacker lists all S3 buckets in the relevant account and attempts to access the data in each of them. When the simulated attacker succeeds, they steal all the data in the bucket and encrypt the data.

This attack demo was based on Hacking the Cloud's Exfiltrating S3 Data with Bucket Replication Policies example.

Unauthorized access pattern demo

Step 1: Initialize the unauthorized access pattern demo

The first CFT stack creates a lambda function, an IAM role, and several S3 buckets. The lambda function assumes the IAM role and writes data to the buckets every few minutes. This CFT needs to run for at least 24 hours to let the anomaly engine learn and create a baseline profile.

Ensure demo account is onboarded

Before continuing with demo initialization, ensure the account that will be running the demo is onboarded and monitored on the Audit Log Monitoring page in InsightCloudSec.

  1. Download the CFT: R7-ICS-CFT-Trailblazer-Demo-Start-Access-Pattern.yaml
  2. In the appropriate account, log in to AWS and navigate to CloudFormation > Stacks.
  3. Click Create stack > With new resources (standard).
  4. Click Template is ready.
  5. Click Upload a template file > Choose file, select the R7-ICS-CFT-Trailblazer-Demo-Start-Access-Pattern.yaml file, and then click Next.
  6. Select the R7-ICS-CFT-Trailblazer-Demo-Start-Access-Pattern.yaml file and upload it. Click Next.
  7. Provide a unique, descriptive stack name (for example, ICS-CAD-Demo-Unusual-Access-Pattern-Init), and then click Next.
  8. Select I acknowledge that AWS CloudFormation might create IAM resources, and then click Submit.

Step 2: Simulate the unauthorized access pattern attack

The second CFT stack creates another simulated, malicious lambda function that will use the role created in the first step to search for S3 buckets it has access to, steal data, and encrypt it.

Ensure baseline was run for at least 24 hours

Before continuing with attack phase of the demo, ensure the baseline profile was run for at least 24 hours.

  1. Download the CFT: R7-ICS-CFT-Trailblazer-Demo-Attack-Access-Pattern.yaml
  2. In the appropriate account, login to AWS and navigate to CloudFormation > Stacks.
  3. Click Create stack > With new resources (standard).
  4. Click Template is ready, click Upload a template file then click Choose file.
  5. Select the R7-ICS-CFT-Trailblazer-Demo-Attack-Access-Pattern.yaml file and upload it. Click Next.
  6. Provide a unique, descriptive stack name. We recommend something like ICS-CAD-Demo-Unusual-Access-Pattern-Attack. Click Next.
  7. Select the I acknowledge that AWS CloudFormation might create IAM resources checkbox, then click Submit.

Step 3: Verify the unauthorized access pattern threat findings

After waiting at least 15 minutes for the simulated attack to occur, you should verify the detected threats inside the InsightCloudSec Threat Findings feature. Review the Threat Findings or reviewing Cloud Anomaly Detection findings documentation for more context.

  1. Login to InsightCloudSec and navigate to Security > Threat Findings.
  2. Click Add Filter, then click + Add Filter.
  3. Configure the filter as such: Event Source is in Rapid7. Click Apply.
  4. You should see the following finding types were detected, including the suspected cloud account and resource:
    • API Activity: Unusual Change In Count Of Unauthorized Access Attempts
    • API Activity: Unusual Change In Count Of Unique Caller IPs
    • API Activity: Unusual Access Pattern

After reviewing InsightCloudSec for your findings, continue to the Remediation section to determine ways to prevent this attack from affecting your production environments.

Remediation

After having successfully simulated an attacker utilizing an unauthorized access pattern, you should ensure your production environments are protected from similar attacks by assessing these common vulnerabilities:

Centralized back-ups:

Centralized backups consolidate data in one location, creating a single point of failure that is vulnerable to hardware issues or cyberattacks. In contrast, distributed backups spread data across multiple locations, enhancing resilience and reducing the risk of data loss.

Cloud resource compromised:

  • Identify and monitor potentially-compromised Lambda functions
  • Activate multi-factor authentication (MFA) on the AWS account root user and any users with interactive access to AWS Identity and Access Management (IAM)
  • Check the code used inside Lambda functions to ensure there are no security bugs inside it
  • Ensure all Lambda user inputs are correctly sanitized following the security guidelines for writing code securely
  • Apply the least-privileged access concept in all the AWS IAM Roles applied to cloud features to avoid unwanted actions or possible privilege escalation paths inside the account

Over-permissive principals:

To prevent over-permissive principals in AWS roles and users, regularly review IAM policies, adhere to the principle of least-privileged access, utilize IAM policy conditions, implement automated policy enforcement, and provide comprehensive training on IAM best practices.

Social Engineering:

Preventing cyber social engineering involves a combination of education, awareness, and implementing security measures. Here are some strategies to help prevent cyber social engineering:

  • Education and training
  • Verify requests by contacting the supposed requester
  • Use multi-factor authentication
  • Use strong passwords

Unusual database activity attack

Two distinct CFTs divide the unusual database activity attack demo into an initialization phase and an attacker phase:

  1. R7-ICS-CFT-Trailblazer-Demo-Start-Unusual-DB-Activity.yaml - CFT that creates basic profiling and baseline activity for the anomaly engine on the role that will be assumed by the attacker. The profiling should run for at least 24 hours before running the attacker CFT. The baseline activity is generated from a Lambda function that assumes a role and retrieves data from a DynamoDB table every few hours. This simulates a periodic data fetch job.
  2. R7-ICS-CFT-Trailblazer-Demo-Attack-Unusual-DB-Activity.yaml - CFT that simulates the attack using the role created using the first CFT. When the attack phase begins, the simulated attacker contaminates a DynamoDB table with irrelevant record rows, and then scans the data from the table and sends it to system logs using syslog.
Unusual database activity attack demo

Step 1: Initialize the unusual database activity demo

The first CFT stack creates a lambda function, an IAM role, and a sample DynamoDB table. The lambda function assumes the IAM role and reads from the table. This CFT needs to run for at least 24 hours to let the anomaly engine learn and create a solid baseline profile.

Ensure demo account is onboarded

Before continuing with demo initialization, ensure the account that will be running the demo is onboarded and monitored on the Audit Log Monitoring page in InsightCloudSec.

  1. Download the CFT: R7-ICS-CFT-Trailblazer-Demo-Start-Unusual-DB-Activity.yaml
  2. In the appropriate account, login to AWS and navigate to CloudFormation > Stacks.
  3. Click Create stack > With new resources (standard).
  4. Click Template is ready, click Upload a template file then click Choose file.
  5. Select the R7-ICS-CFT-Trailblazer-Demo-Start-Unusual-DB-Activity.yaml file and upload it. Click Next.
  6. Provide a unique, descriptive stack name. We recommend something like ICS-CAD-Demo-Unusual-DB-Activity-Init. Click Next.
  7. Select the I acknowledge that AWS CloudFormation might create IAM resources checkbox, then click Submit.

Step 2: Simulate the unusual database activity attack

The second CFT stack creates another lambda function that will use the role created in the first step to contaminate a database table, retrieve data from the table, and export the data using syslog.

Ensure baseline was run for at least 24 hours

Before continuing with attack phase of the demo, ensure the baseline profile was run for at least 24 hours.

  1. Download the CFT: R7-ICS-CFT-Trailblazer-Demo-Attack-Unusual-DB-Activity.yaml
  2. In the appropriate account, login to AWS and navigate to CloudFormation > Stacks.
  3. Click Create stack > With new resources (standard).
  4. Click Template is ready, click Upload a template file then click Choose file.
  5. Select the R7-ICS-CFT-Trailblazer-Demo-Attack-Unusual-DB-Activity.yaml file and upload it. Click Next.
  6. Provide a unique, descriptive stack name. We recommend something like ICS-CAD-Demo-Unusual-DB-Activity-Attack. Click Next.
  7. Select the I acknowledge that AWS CloudFormation might create IAM resources checkbox, then click Submit.

Step 3: Verify the unusual database activity threat findings

After waiting at least 15 minutes for the simulated attack to occur, you should verify the detected threats inside the InsightCloudSec Threat Findings feature. Review the Threat Findings or reviewing Cloud Anomaly Detection findings documentation for more context.

  1. Login to InsightCloudSec and navigate to Security > Threat Findings.
  2. Click Add Filter, then click + Add Filter.
  3. Configure the filter as such: Event Source is in Rapid7. Click Apply.
  4. You should see the following finding types were detected, including the suspected cloud account and resource:
    • API Activity: Unusual Change In Count Of Unique Actions
    • API Activity: Unusual Database Activity

Unusual search account activity

Two distinct CFTs divide the unusual search account activity demo into a initialization phase and an attacker phase:

  1. R7-ICS-CFT-Trailblazer-Demo-S3-Account-Search-Start.yaml - CFT that creates basic profiling and baseline activity for the anomaly engine on the role that will be assumed by the attacker. The profiling should run for at least 24 hours before running the attacker CFT. The baseline activity is generated from a Lambda function that assumes a role and retrieves data from an S3 bucket every few hours. This simulates a periodic data fetch job.
  2. R7-ICS-CFT-Trailblazer-Demo-S3-Account-Search.yaml - CFT that simulates the attack using the role created using the first CFT. When the attack phase begins, the simulated attacker uses an account ID from an existing S3 bucket to successfully access other S3 buckets.
Unusual search account activity demo

Step 1: Initialize the search account activity demo

The first CFT stack creates a lambda function, an IAM role, and a sample S3 bucket. The lambda function assumes the IAM role and writes data to the buckets every few minutes. This CFT needs to run for at least 24 hours to let the anomaly engine learn and create a solid baseline profile.

Ensure demo account is onboarded

Before continuing with demo initialization, ensure the account that will be running the demo is onboarded and monitored on the Audit Log Monitoring page in InsightCloudSec.

  1. Download the CFT: R7-ICS-CFT-Trailblazer-Demo-S3-Account-Search-Start.yaml
  2. In the appropriate account, login to AWS and navigate to CloudFormation > Stacks.
  3. Click Create stack > With new resources (standard).
  4. Click Template is ready, click Upload a template file then click Choose file.
  5. Select the R7-ICS-CFT-Trailblazer-Demo-S3-Account-Search-Start.yaml file and upload it. Click Next.
  6. Provide a unique, descriptive stack name. We recommend something like ICS-CAD-Demo-Account-Search-Init. Click Next.
  7. Select the I acknowledge that AWS CloudFormation might create IAM resources checkbox, then click Submit.

Step 2: Simulate the search account activity attack

The second CFT stack creates another lambda function that will use the role created in the first step to access an S3 bucket and determine other buckets that can be accessed.

Ensure baseline was run for at least 24 hours

Before continuing with attack phase of the demo, ensure the baseline profile was run for at least 24 hours.

  1. Download the CFT: R7-ICS-CFT-Trailblazer-Demo-S3-Account-Search.yaml
  2. In the appropriate account, login to AWS and navigate to CloudFormation > Stacks.
  3. Click Create stack > With new resources (standard).
  4. Click Template is ready, click Upload a template file then click Choose file.
  5. Select the R7-ICS-CFT-Trailblazer-Demo-S3-Account-Search.yaml file and upload it. Click Next.
  6. Provide a unique, descriptive stack name. We recommend something like ICS-CAD-Demo-Account-Search-Attack. Click Next.
  7. Select the I acknowledge that AWS CloudFormation might create IAM resources checkbox, then click Submit.

Step 3: Verify the search account activity threat findings

After waiting at least 15 minutes for the simulated attack to occur, you should verify the detected threats inside the InsightCloudSec Threat Findings feature. Review the Threat Findings or reviewing Cloud Anomaly Detection findings documentation for more context.

  1. Login to InsightCloudSec and navigate to Security > Threat Findings.
  2. Click Add Filter, then click + Add Filter.
  3. Configure the filter as such: Event Source is in Rapid7. Click Apply.
  4. You should see the following finding type was detected, including the suspected cloud account, resource, and an entity ID:
    • API Activity: Unusual Change In Count Of Unauthorized Access Attempts

Each threat entry should also include an entity ID that looks something like this in the raw JSON: my-baseline-start-search-1-AttackSimulationRole-XXXXXX/AssumeRoleSessionTbAttack

Advantages of Cloud Anomaly Detection

Cloud Anomaly Detection can find detections that other similar services can't because it is an artificial intelligence-driven, agentless anomaly detection security engine. With Cloud Anomaly Detection using machine learning to analyze threat detections, auditing logs, and tracking API sessions is no longer a challenge and requires zero human intervention. After reviewing detections in InsightCloudSec, you can compare the results to AWS GuardDuty to visualize the discrepancies.

Stopping the demos

To stop the simulated behavior and extra service costs in your environment, complete these steps to remove the demo material.

Unauthorized access pattern

To remove the unauthorized access pattern demo:

  1. Return to AWS and log in again, if necessary.
  2. Navigate to Lambda > Functions.
  3. Search for TbAttackSimulationLambdaNormal and click the function name to open the Lambda.
  4. Navigate to Configuration > Triggers.
  5. Find the EventBridge (CloudWatch Events): demo111-RunNormalLambda-<id> entry and click the event name to open the rule in Amazon EventBridge.
  6. Click Disable, and then return to Lambda > Functions.
  7. Search for TbAttackSimulationLambdaRemoval and click the function name to open the Lambda.
  8. Click Deploy.
  9. Navigate to CloudFormation > Stacks.
  10. Select and delete the two stacks you created to initialize and simulate the attack demo.
Unusual database activity

To remove the unusual database activity demo:

  1. Return to AWS and login again if necessary.
  2. Navigate to CloudFormation > Stacks.
  3. Select and delete the two stacks you created to initialize and simulate the attack demo.
Unusual search account activity

To remove the unusual search account activity demo:

  1. Return to AWS and login again if necessary.
  2. Navigate to CloudFormation > Stacks.
  3. Select and delete the two stacks you created to initialize and simulate the attack demo.