Advanced AWS Forensics

You'll be working with services such as Amazon GuardDuty, Amazon Inspector, Amazon CloudWatch, AWS Lambda, AWS Systems Manager, AWS Config, AWS CloudTrail, and AWS Athena. You will learn how to use these services to set up a notification and remediation pipeline, investigate threats during and after an attack, and add additional protections in place to improve the security posture of your environment.

Scenario

Your company is new to the cloud and has recently performed a lift-and-shift of your infrastructure for piloting purposes. You are a systems administrator and have been tasked with security monitoring within your AWS environment. As part of that maintenance you are also responsible for responding to any security event in your environment.

Architecture overview

For this Workshop you will have a single instance setup in the us-west-2 region. As this was a “lift-and-shift” migration for piloting, you have yet to build redundancy into your application, so you have a single public-facing webserver. The webserver has access to the Internet Gateway through an Elastic Network Interface. Customers access your web server through a DNS entry pointing to the Elastic Network Interface. You store static content in an S3 bucket and use the VPC S3 Endpoint Gateway for access from the webserver.

Before you migrated the application you saw a webinar about AWS security best practices. Because of that webinar, you knew to enable a number of Security services provided by AWS.

Region

Please use the us-west-2 (Oregon) region for this workshop.

Module 1: Environment build and configuration

In this module you will be configuring the threat detection controls for your environment. You'll be running the first of two CloudFormation templates which will automate the creation of some of these controls and then you will manually configure the rest.

Agenda

1. Review current configurations and run the 1st CloudFormation template – 5 min

2. Configure the remaining controls – 10 min

Review current configurations

When you launch the first CloudFormation template you'll be prompted with questions regarding whether certain resources are already configured. Please verify whether you already have the following configured in your account:

1. Go to AWS IAM and see if you have the following Role created:

   If you do not see the Inspector Role; you'll answer No when prompted if the Inspector Role exists when launching the CloudFormation template.

2. Go to AWS Config (in the us-west-2 - Oregon region) and see if it is already enabled.

   If you see a Get Started button; you'll answer No when prompted if Config is enabled when launching the CloudFormation template.

Deploy the CloudFormation template

To initiate the scenario and configure your environment you will need to run the module 1 CloudFormation template:

Region	Deploy
US West 2 (Oregon)

1. Click the Deploy to AWS button above. This will automatically take you to the console to run the template. The file for the CloudFormation template (01-environment-setup.yaml) is also available in the templates folder if you'd like to download it and manually upload it to create a stack.

2. On the Specify Details section enter the necessary parameters as shown below.

   • Enter a valid Email Address. This is so you can receive email alerts from AWS services during the Workshop.

   • Please use the answers you discovered during the Review Current Configurations.

1. Once you have entered your parameters click Next, then Next again (leave everything on this page at the default).

2. Finally, acknowledge that the template will create IAM roles and click Create.

This will bring you back to the CloudFormation console. You can refresh the page to see the stack starting to create. Before moving on, make sure the stack is in a CREATE_COMPLETE status as shown below.

1. You will get an email from SNS asking you to confirm the Subscription so you can receive email alerts from AWS services during the Workshop.

Setup CloudWatch Event rules and automatic remediation

The CloudFormation template you just ran created three CloudWatch Event Rules for alerting and remediation purposes. The steps below will walk you through creating the final rule. After this you'll have all the necessary rules in place to receive email notifications and trigger the appropriate AWS Lambda functions for remediations.

Below are steps to create this rule through the console but you can also find out more about doing it programmatically by reviewing the GuardDuty Documentation.

1. Open the CloudWatch console

2. In the navigation pane on the left, under Events, click Rules

   What are the current Rules in place setup to do?

3. Click Create Rule

4. On the Create rule screen do the following:

   • Under Event Pattern click Build event pattern to match events by service and select Custom event pattern in the drop down.

   • Paste in the custom event pattern below:

   {
     "source": [
   	"aws.guardduty"
     ],
     "detail": {
   	"type": [
   	  "UnauthorizedAccess:EC2/MaliciousIPCaller.Custom"
   	]
     }
   }

   • For Targets, click Add Target, select Lambda Function, and then select forensics-wksp-remediation-nacl.

   • Click Configure details

5. On the Configure rule details screen fill out the Name and Description (suggestions below).

   • Name: forensics-wksp-guardduty-finding-ec2-maliciousip

   • Description: GuardDuty Finding: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom

6. Click Create rule.

7. Now let’s examine the Lambda function to see what it does. Open the Lambda console

8. Click on the function named forensics-wksp-remediation-nacl

   What will the function do when invoked?

   What will the forensics-wksp-remediation-inspector function do?

Enable GuardDuty

The next step is to enable Amazon GuardDuty, which will continuously monitor your environment for malicious or unauthorized behavior.

1. Go to the Amazon GuardDuty console.

2. Click the Get Started button.

3. On the next screen click the Enable GuardDuty button.

GuardDuty is now enabled and continuously monitoring your CloudTrail logs, VPC flow logs, and DNS Query logs for threats in your environment.

Architecture overview

Your environment is now configured and ready for operations. Below is a diagram to depict the detective controls you now have in place.

After you have successfully setup your environment, you can proceed to the next module.

Module 2: Attack simulation and detection

Now that you have all the detective controls setup and some automated remediations, you'll be running another CloudFormation template which will simulate a variety of findings.

Agenda

1. Run the 2nd CloudFormation template – 5 min

2. Threat Detection & Remediation Presentation – 20 min

Deploy the CloudFormation Template

To initiate the attack simulation you will need to run the module 2 CloudFormation template:

Region	Deploy
US West 2 (Oregon)

1. Click the Deploy to AWS button above. This will automatically take you to the console to run the template. The file for the CloudFormation template (02-attack-simulation.yaml) is also available in the templates folder if you'd like to download it and manually upload it to create a stack.

2. The name of the stack will be automatically populated but you are free to change it, after which click Next, then Nextagain (leave everything on this page at the default).

3. Finally, acknowledge that the template will create IAM roles and click Create

This will bring you back to the CloudFormation console. You can refresh the page to see the stack starting to create. Before moving on, make sure the stack is in a CREATE_COMPLETE status as shown below.

The Big Picture

Below is a diagram of the setup after the Module 2 CloudFormation stack is created.

If you are going through this workshop in a classroom setting then wait till the presentation is over before starting module 3 (the presentation will allow enough time to pass for the attack scenario to complete.)

If you are going through this workshop outside of a classroom setting you can proceed to Module 3. Please note it will take at least 20 minutes after the 2nd CloudFormation template has completed before you will start seeing findings.

Module 3: Forensics and remediation

Unfortunately, due to a misconfiguration in your environment, a hacker has been able to gain access to your webserver. Now, with the intruder in your environment you’re getting alerts from the security tools you’ve put in place indicating nefarious activity. These alerts include communication with known malicious IP addresses, account reconnaissance, changes to S3 policies, and disabling security configurations. You must identify exactly what activity the intruder has performed and how they did it so you can block the intruder’s access, remediate the vulnerabilities, and restore the configuration to its proper state.

Agenda

Perform forensics and remediate – 30 min

Find out what's happening!

You’ve received the first alerts from GuardDuty. Now what? Since the alert came from GuardDuty, we will check there first.

Check GuardDuty findings

1. Go to the Amazon GuardDuty console.

2. In the navigation pane, click on Findings. You should see all the findings below:

   Don't panic if all of these findings fail to show up at first. The findings generated will take at least 20 minutes to show up in the GuardDuty console.

3. The high severity UnauthorizedAccess:EC2/SSHBruteForce finding is a result of the activity going on in the background to simulate the attack and can be ignored. You can archive the finding if you choose with the steps below:

   • Click on the check box next to the "UnauthorizedAccess:EC2/SSHBruteForce" Finding.

   • Click on Actions.

   • Select Archive.

     If you're interested in seeing all of your findings (current and archived) you can click on the filter icon to the left of Add filter criteria to toggle them in the console.

   • After archiving you should have four findings that are associated with this workshop.

4. Now let's examine the low severity UnauthorizedAccess:EC2/SSHBruteForce finding since this was one of the first findings to show up.

   • Click on the Finding.

   • Review the Resource affected and other sections in the window that popped open on the right.

   • Copy down the GuardDuty Finding ID and the Instance ID.

     Was the brute force attack successful?

Check Inspector assessment and CloudWatch logs

Following security design best practices you already setup your instances to send certain logs to CloudWatch. You’ve also setup a CloudWatch event rule that runs an AWS Inspector scan when GuardDuty detects a particular attack. Let’s look at the Inspector findings to see if the SSH configuration adheres to best practices to determine what the risk is for the brute force attack. We will then examine the CloudWatch logs.

1. Go to Amazon Inspector in the Amazon Console.

2. Click Findings on the left navigation.

   If you do not see any findings after awhile, there may have been an issue with your Inspector agent. Click on Assessment Templates, check the template that starts with forensics-wksp, and click Run. Please allow 15 minutesfor the scan to complete. You can also look in Assessment runs and check the status. Feel free to continue through this module and check the results later on.

3. Filter down the findings by typing in Password.

4. Review the findings.

   Which Inspector rule packages were used for this scan?

Based on the findings you see that password authentication is configured on the instance with no password complexity restrictions which means the instance is more susceptible to a SSH brute force attack. Now that we know that let’s look at the CloudWatch logs and create a metric to see if there are any successful SSH logins (to finally answer the question of whether the SSH brute force attack was successful.)

1. Go to CloudWatch logs.

2. Click on the log group /forensics-wksp/var/log/secure

3. If you have multiple log streams, filter using the Instance ID you copied earlier and click on the stream.

4. Within the Filter Events text-box put the following Filter Pattern:

   [Mon, day, timestamp, ip, id, msg1= Invalid, msg2 = user, ...]

   Do you see any failed (invalid user) attempts to log into the instance?

5. Now replace the Filter with one for successful attempts:

   [Mon, day, timestamp, ip, id, msg1= Accepted, msg2 = password, ...]

   Do you see any successful attempts to log into the instance?

   Which linux user was compromised?

Check the remaining GuardDuty findings

Now that you have verified that the brute force attack was successful and your instance was compromised, go back to the Amazon GuardDuty console and view the other findings.

Does it look like you are early in identifying the attack (just intrusion), or has the intruder started performing malicious actions?

View the following GuardDuty findings and take a note of the resources involved:

• Recon:IAMUser/MaliciousIPCaller.Custom

• UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom

• UnauthorizedAccess:EC2/MaliciousIPCaller.Custom

You can see by these findings that the compromised instance is communicating with an IP address on your custom threat list and that API calls are being made from a host on your custom threat list.

The API calls are being made using AWS IAM temporary security credentials coming from an IAM Role for EC2. How could you determine this fact yourself?

Query CloudTrail logs with Athena

In order to find out more about what has happened, we'll perform some additional forensics using Amazon Athena, which lets us query the CloudTrail logs contained in S3.

You will first need to set up an Athena database for your CloudTrail logs against which you can run the queries that follow.

Begin by reading the documentation on this page: https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html

1. Browse to the CloudTrail event history: https://us-west-2.console.aws.amazon.com/cloudtrail/home?region=us-west-2#/events

2. Click the link that says "Run advanced queries in Amazon Athena".

3. For Storage Location, select the CloudTrail S3 bucket that starts with "forensics-wksp" and ends in "-logs".

4. Click "Create table".

5. Once the table is created, click "Go to Athena" to go to the Athena console.

6. Make sure the Database is set to "default".

7. Copy the name of your table, which should be in the format cloudtrail_logs_forensics_wksp_<account_id>_us_west_2_logs, by clicking the ellipsis (...) to the right of the table name and selcting "Show properties".

For each query below, replace {TABLE} with the name of your table.

1. Identify some more details about the launch of the suspect EC2 instance. Replace the instance ID in this query with the ID of the suspect EC2 instance.

SELECT eventtime, useridentity, awsregion,
       sourceipaddress, useragent, requestparameters
FROM "default"."{TABLE}"
WHERE eventsource = 'ec2.amazonaws.com'
      AND eventname = 'RunInstances'
      AND regexp_like(responseelements, 'i-12345678901234567') limit 1;

1. Identify if any other EC2 instances were launched with the same EC2 key-pair as the suspect EC2 instance. Replace the string "suspect-keypair" with the name of the EC2 key used by the suspect EC2 instance.

SELECT *
FROM "default"."{TABLE}"
WHERE eventsource = 'ec2.amazonaws.com'
      AND eventname = 'RunInstances'
      AND regexp_like(requestparameters, '\"keyName\":\"suspect-keypair\"');

1. Identify if any other EC2 instances were launched with the same EC2 instance profile as the suspect EC2 instance. replace the string "suspect-instance-profile" with the name of the instance profile, or IAM role, with which the suspect EC2 instance is running.

SELECT *
FROM "default"."{TABLE}"
WHERE eventsource = 'ec2.amazonaws.com'
      AND eventname = 'RunInstances'
      AND regexp_like(requestparameters, '\"iamInstanceProfile\":{\"name\":\"suspect-instance-profile\"}');

1. Identify the last 2 days of activity for the threat actor (e.g. IAM user) whom launched the suspect EC2 instance. Replace the principal ID string with the actual principal ID of the user that launched the suspect EC2 instance.

SELECT *
FROM "default"."{TABLE}"
WHERE useridentity.principalid = 'AIDAJ45Q7YFFAREXAMPLE'
      AND (to_unixtime(now()) - to_unixtime(from_iso8601_timestamp(eventtime)))/(24*60*60) < 2;

1. Identify who created an IAM user involved in suspicious activities. Replace the string "suspicious-user" with the name of the IAM user that made the call to CreateUser. (Hint: try looking for that API call in CloudTrail via the console and examine the raw JSON for the event by clicking View Event).

SELECT eventtime, useridentity, awsregion,
       sourceipaddress, useragent, requestparameters
FROM "default"."{TABLE}"
WHERE eventsource = 'iam.amazonaws.com'
      AND eventname = 'CreateUser'
      AND regexp_like(requestparameters, '\"userName\":\"suspicious-user\"');

What additional info were you able to learn about the incident by performing these queries?

Stop and evaluate

So at this point you have identified a successful intrusion into your network and specific actions taken against your account. Let’s recap what those are:

• A SSH brute force attack against an internet accessible EC2 instance was successful.

• The EC2 instance communicated with a known malicious IP address (possibly indicating that malware was installed.)

Now that you've identified the attacker’s actions you need to stop them from performing any additional activities, restore your systems to their previous configurations, and protect your resources so this can’t happen again.

Respond and remediate

Before we get ahead of ourselves, we must stop any further actions from taking place. This requires removing the foothold in our environment, revoking any active credentials or removing those credentials' capabilities, and blocking further actions by the attacker.

Verify your automated remediation

Based upon your existing work, you’ve implemented the first step by using the CloudWatch Event rule to trigger the Lambda function to update the NACL for the subnet that the instance is located in. Let’s look at what changed.

1. Go to the AWS Config console.

2. You may initially see the following message (if you don't see the message just go on to the next step):

   Click the Click Here button to proceed with using Config without Config Rules

3. Click Resources in the left navigation.

4. We can search here to find configuration changes to the NACL. Select the radio button for Tag and enter Name for the Tag key and forensics-wksp-compromised for the Tag value (this is allowing us to search for the NACL with that name):
5. Click on the Network ACL ID in the Config timeline column.

6. On the next screen you should see two Change events in the timeline. Click on Change for each one to see what occurred.

7. Evaluate the NACL changes.

   What does the new NACL rule do?

Modify the security group

Now that the active session from the attacker has been stopped by the update to the NACL, you need to modify the Security Group associated with the instance to prevent the attacker or anyone else from coming from a different IP.

1. Go to the Amazon EC2 Console.

2. Find the running instances with the name forensics-wksp: Compromised Instance.

3. Under the Description tab, click on the Security Group for the compromised instance.

4. View the rules under the Inbound tab.

5. Click Edit and delete the inbound SSH rule. You've decided that all administration on EC2 Instances will be done through AWS Systems Manager so you no longer need this port open.

   In your initial setup you already installed the SSM Agent on your EC2 Instance.

6. Click Save

Revoke IAM role active sessions

Now that the attacker can’t SSH into the compromised instance, you need to revoke all active sessions for the IAM role associated with that instance.

1. Browse to the AWS IAM console.

2. Click Roles and the forensics-wksp-compromised-ec2 role (this is the role attached to the compromised instance).

3. Click on the Revoke sessions tab.

4. Click on Revoke active sessions.

5. Click the acknowledgement check box and then click Revoke active sessions.

   What is the mechanism that is put in place by this step to actually prevent the use of the temp credentials issued by this role?

Restart instance to rotate credentials

Now all active sessions for the compromised instance role have been invalidated. This means the attacker can no longer use those credentials, but it also means that your application that use this role can't as well. In order to ensure the availability of your application you need to refresh the credentials on the instance.

To change the IAM credentials on the instance, you must Stop and Start the instance. A simple reboot will not change the keys. Since you are using AWS Systems Manager for doing administration on your EC2 Instances you can use it to query the metadata to validate that the credentials were rotated.

First verify what the current credentials are.

1. Go to AWS Systems Manager console and click Managed Instances (found under the Shared Resources section on the left navigation).

   You should see an instance named forensics-wksp: Compromised Instance with a Ping status of Online.

2. To see the keys currently active on the instance, click on Run Command on the left navigation and then click Run a Command.

3. For Command document select AWS-RunShellScript

   You may need to scroll through the list or just enter the document name in the search bar.

4. Leave the Document version at the default.

5. Under Targets check the checkbox next to forensics-wksp: Compromised Instance.

6. Under Command Parameters type the following in Commands:

   curl http://169.254.169.254/latest/meta-data/iam/security-credentials/forensics-wksp-compromised-ec2

7. Leave all of the other options at their default, scroll to the end and click Run.

8. Scroll down to the Targets and outputs section and click the Instance ID (which should correspond to the instance ID of the compromised instance)

9. Expand Step 1 - Output and make note of the AccessKeyID, SecretAccessKey, and Token. (the command will take a minute or so to run)

Next, you need to stop and restart the Instance.

1. In the EC2 console Stop the Instance named forensics-wksp: Compromised Instance.

2. Wait for the Instance State to say Stopped and then Start the instance.

Lastly, you can need to query the metadata again to validate that the credentials were changed.

1. Repeat the first 10 steps to retrieve the credentials again.

   Notice the keys are different.

   If you want, try again after rebooting the instance. The keys will stay the same.

This is a good use case for auto-scaling groups and golden-image AMI’s, but that is out of scope for this workshop. Also out of scope is clearing the suspected malware.

After you have remediated the incident and further hardened your environment, you can proceed to the next module.

If you are going through this workshop in a classroom setting then the instructor should start the module 4 presentation soon.

Module 4: Review and cleanup

In the last module we will have a short discussion of the lab (and discuss exactly what occurred.) We will also go over a number of questions and then provide instructions on how to clean up the lab environment (to prevent future charges in your AWS account.)

Agenda

1. Review and discussion – 10 min

2. Cleanup – 5 min

Architecture Overview

Diagram of the overall lab setup:

What is Really Going On?

In Module 1 of the lab you setup the initial components of your infrastructure including GuardDuty and a simple automated forensics workflow. Some of the steps required manual configuration, but you also ran a CloudFormation template that set up some of the components.

In Module 2 you launched a second CloudFormation template that initiated the attack simulated by this lab. The CloudFormation template created two EC2 instances. One instance , named Malicious Host, had an EIP attached to it that was added to your GuardDuty custom threat list. Although the Malicious Host is in the same VPC as the other instance, for the sake of the scenario (and to prevent the need to submit a penetration testing request) we acted as if it is on the Internet and represented the attacker's computer. The other instance, named Compromised Instance, was your web server that was taken over by the Malicious Host.

In Module 3 you performed forensics to investigate the attack by looking at GuardDuty findings, an Inspector assessment, CloudWatch logs, and Athena query results. You also learned about how to remediate the damage and set up some automated remediation for future attacks.

What occurred during the attack:

1. There were two instances created by the Module 2 CloudFormation template. They were in the same VPC but different subnets. The Malicious Host represented the attacker that we pretended was on the Internet. The Elastic IP on the Malicious Host was in a custom threat list in GuardDuty. The other instance, named Compromised Instance, represented the web server that was lifted and shifted into AWS.

2. Although company policy was that only key-based authentication should be enabled for SSH, at some point password authentication for SSH was enabled on the Compromised Instance.

   This misconfiguration is identified in the Inspector scan that is triggered from the GuardDuty finding.

3. The Malicious Host performed a brute force SSH password attack against the Compromised Instance. The brute force attack had been purposefully designed to be successful.

   GuardDuty Finding: UnauthorizedAccess:EC2/SSHBruteForce

4. The SSH brute force attack was successful and the attacker was able to log in to the Compromised Instance.

   Successful login is confirmed in CloudWatch Logs (/forensics-wksp/var/log/secure).

5. The Compromised Instance also had a cron job that continuously pinged the Malicious Host to generate a GuardDuty finding based off the custom threat list.

   GuardDuty Finding: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom

6. The API Calls that generated the API findings came from the Malicious Host. The calls used the temp creds from the IAM role for EC2 running on the Malicious Host. The GuardDuty findings were generated because the EIP attached to the Malicious Host was in a custom threat list.

   GuardDuty Finding: Recon:IAMUser/MaliciousIPCaller.Custom

   GuardDuty Finding: UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom

7. A number of CloudWatch Events Rules were evoked by the GuardDuty findings and then these triggered various services:

   1. CloudWatch Event Rule: The generic GuardDuty finding invoked a rule that triggered SNS to send an email.

   2. CloudWatch Event Rule: The SSH brute force attack finding invoked a rule that triggered a Lambda function to (a) block the IP address of the attacker via a NACL change, (b) used a Lambda function to run an Inspector scan on the EC2 instance.

   3. CloudWatch Event Rule: The Unauthorized Access Custom MaliciousIP finding invoked a rule that triggered a Lambda function to block the IP address of the attacker via a NACL.

Clean-up

In order to prevent charges to your account from the resources created during this workshop, we recommend cleaning up the infrastructure that was created. If you plan to keep things running so you can examine the lab a bit more, please remember to do the clean-up when you are done.

Automated clean-up

To delete the CloudFormation stack, a Bash script, cleanup.sh, has been provided. Run as follows:

chmod +x cleanup.sh
./cleanup.sh

• Q: I'm using a different AWS CLI profile than the default.

• A: The script supports a flag to specify a CLI profile that is configured in your ~/.aws/config file. Do ./cleanup.sh -p PROFILE_NAME. To see all supported options for the clean-up script, do ./cleanup.sh -h.

Manual clean-up instructions

These manual clean-up steps can be used in lieu of the automated clean-up script.

1. Delete the Inspector objects created for the workshop.

   • Go to the Amazon Inspector console.

   • Click on Assessment targets in the navigation pane on the left.

   • Delete all that start with forensics-wksp.

2. Delete the IAM Role for the compromised EC2 instance and the Service-Linked Role for Inspector (if you didn't already have this Role created).

   • Go to AWS IAM console.

   • Click on Roles

   • Search for the role named forensics-wksp-compromised-ec2.

   • Click the check box next to it and click Delete.

   • Repeat the steps above for the role named AWSServiceRoleForAmazonInspector.

3. Delete all three S3 buckets created by the Module 1 CloudFormation template (the buckets that start with forensics-wkspand end with -data, -threatlist and -logs)

   • Go to Amazon S3 console.

   • Click on the appropiate bucket.

   • Click Delete Bucket.

   • Copy and paste the name of the bucket (this is an extra verification that you actually want to delete the bucket).

   • Repeat the steps above for all three buckets.

4. Delete Module 1 and 2 CloudFormation stacks (BlackHat2018-AwsForensicsWksp-Core and BlackHat2018-AwsForensicsWksp-AttackSim).

   • Go to the AWS CloudFormation console.

   • Select the appropiate stack.

   • Select Action.

   • Click Delete Stack.

   • Repeat the steps above for each stack.

   You do not need to wait for the first stack to delete before you delete the second one.

5. Delete the GuardDuty custom threat list and disable GuardDuty (if you didn't already have it configured before the workshop)

   • Go to the Amazon GuardDuty console.

   • Click on Lists on the left navigation.

   • Click the X next to the threat list that starts with Custom-Threat-List.

   • Click Settings in the navigation pane on the left navigation.

   • Click the check box next to Disable.

   • Click Save settings and then click Disable in the pop-up box.

6. Delete the manual CloudWatch Event Rule you created and the CloudWatch Logs that were generated.

   • Go to the AWS CloudWatch console.

   • Click on Rules in the navigation pane on the left.

   • Click the radio button next forensics-wksp-guardduty-finding-maliciousip.

   • Select Action and click Delete.

   • Click on Logs in the navigation pane on the left.

   • Click the radio button next to /aws/lambda/forensics-wksp-inspector-role-creation.

   • Select Action and click Delete log group and then click Yes, Delete in the pop-up box.

   • Repeat for:

     • /aws/lambda/forensics-wksp-remediation-inspector

     • /aws/lambda/forensics-wksp-remediation-nacl

     • /forensics-wksp/var/log/secure

7. Delete the SNS subscription that was created when you subscribed to SNS Topic.

   • Go to the AWS SNS console.

   • Click on Subscriptions on the left navigation.

   • Select the check box next to the subscription that shows your e-mail as the Endpoint and has forensics-wksp in the Subscription ARN.

   • Select Action and then click Delete subscriptions