Advanced Threat Detection in AWS
Last updated
Last updated
You'll be working with services such as Amazon GuardDuty, Amazon Macie, Amazon Inspector, Amazon CloudWatch, AWS Lambda, AWS Systems Manager, AWS Config, and AWS CloudTrail. 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.
You should have some level of familiarity with AWS services such as EC2, VPC and S3. Exposure to AWS Lambda and CloudFormation are a bonus. Some experience working with the AWS console is helpful as well.
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.
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.
Please use the us-west-2 (Oregon) region for this workshop.
In this module you will be configuring all the initial detective and remediation 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.
Review current configurations and run the 1st CloudFormation template – 5 min
Configure the remaining controls – 15 min
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:
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.
To initiate the scenario and configure your environment you will need to run the module 1 CloudFormation template:
Region
Deploy
US West 2 (Oregon)
Click the Deploy to AWS button above. This will automatically take you to the console to run the template.
On the Specify Details section enter the necessary parameters as shown below.
Parameter
Value
Stack name
ThreatDetectionWksp-Env-Setup
Email Address
A valid email address
AWS Config
Yes or No (Is AWS Config enabled already?)
Once you have entered your parameters click Next, then Next again (leave everything on this page at the default).
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
You will get an email from SNS asking you to confirm the Subscription. Confirm this so you can receive email alerts from AWS services during the Workshop.
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.
Open the CloudWatch console
In the navigation pane on the left, under Events, click Rules
What are the current Rules in place setup to do?
Click Create Rule
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:
For Targets, click Add Target, select Lambda Function, and then select threat-detection-wksp-remediation-nacl.
Click Configure details
On the Configure rule details screen fill out the Name and Description (suggestions below).
Name: threat-detection-wksp-guardduty-finding-ec2-maliciousip
Description: GuardDuty Finding: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom
Click Create rule.
Now let’s examine the Lambda function to see what it does. Open the Lambda console
Click on the function named threat-detection-wksp-remediation-nacl
What will the function do when invoked?
What will the threat-detection-wksp-remediation-inspector functions do?
The next step is to enable Amazon GuardDuty, which will continuously monitor your environment for malicious or unauthorized behavior.
Go to the Amazon GuardDuty console.
Click the Get Started button.
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.
Since you plan on storing sensitive data in S3, let’s quickly enable Amazon Macie. Macie is a security service that will continuously monitor data access activity for anomalies and generate alerts when it detects risk of unauthorized access or inadvertent data leaks.
Go to the Amazon Macie console.
If you get a Failed to Fetch error you may have a script blocker enabled in your browser.
Click Get Started.
Macie will create a service-linked role when you enable it. If you would like to see the permissions that the role will have you can click the View service role permissions.
Click Enable Macie.
Macie is also used for automatically discovering and classifying sensitive data. Now that Macie is enabled, setup an integration to classify data in your S3 bucket.
In the Amazon Macie console click on Integrations on the left navigation.
Find your AWS account ID (there should be only one) and click Select
Click Add then on the next screen click the check box next to the S3 bucket that ends with “-data”. Click Add
Leave the options here at the default, click Review.
On the next screen click Start Classification.
Finally click Done. Macie is now enabled and has begun to discover, classify and protect your data.
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.
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.
Run the 2nd CloudFormation template – 5 min
To initiate the attack simulation you will need to run the module 2 CloudFormation template:
Region
Deploy
US West 2 (Oregon)
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.yml) is also available in the templates folder if you'd like to download it and manually upload it to create a stack.
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).
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
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.
Attack Recap
1. Module 2 CloudFormation template creates two EC2 instances. They are in the same VPC but different subnets. The Malicious Host represents the attacker which we pretend is on the Internet. The Elastic IP on the Malicious Host is in a custom threat list in GuardDuty (in order to generate . The other instance named Compromised Instance represents the web server that was lifted and shifted into AWS.
2. Although company policy is that only certificate authentication should be enabled for SSH, at some point password authentication for SSH was enabled on the Compromised Instance
3. The Malicious Host performed a brute force SSH password attack against the Compromised Instance. The brute force attack is designed to be successful
4. The SSH brute force attack was successful and the attacker was able to log in to the Compromised Instance
5. We pretend here that the attacker then copied the temp credentials (that came from IAM Role for EC2) from the instance to an S3 bucket - in reality the API calls from the Malicious Host use the temp creds from the IAM Role for EC2 attached to the Malicious Host
6. The CloudFormation template that we ran in Module 2 enables encryption for the Data bucket and then the EC2 instance removes the encryption. In addition the CloudFormation template made the Data bucket public. This is used for the Macie part of the investigation in Module 3. We pretend that the attacker made the bucket public and removed the default encryption from the bucket.
7. The API Calls that generated the API findings come from the Malicious Host. The calls use the temp creds from the IAM role for EC2 running on the Malicious Host. The GuardDuty findings are generated because the EIP on the Malicious Host is in a custom threat list.
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.
Detect, respond & remediate – 30 min
You’ve received the first alerts from GuardDuty. Now what? Since the alert came from GuardDuty, we will check there first.
Go to the Amazon GuardDuty console.
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.
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.
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?
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.
Go to Amazon Inspector in the Amazon Console.
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 threat-detection-wksp, and click Run. Please allow 15 minutes for 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.
Filter down the findings by typing in Password.
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.)
Go to CloudWatch logs.
Click on the log group /threat-detection-wksp/var/log/secure
If you have multiple log streams, filter using the Instance ID you copied earlier and click on the stream.
Within the Filter Events text-box put the following Filter Pattern:
Do you see any failed (invalid user) attempts to log into the instance?
Now replace the Filter with one for successful attempts:
Do you see any successful attempts to log into the instance?
Which linux user was compromised?
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?
At this point you know how the attacker was able to get into your systems and a general idea of what they did. If you review the permissions associated with the IAM Role attached to the compromised instance you will notice that it has a very permissive policy as it relates to your S3 data bucket. Verify what sort of sensitive data is in your bucket and take a closer at your Macie Alerts.
Go to the Amazon Macie console.
Look through the latest alerts.
Do you see any critical alerts?
Next lets verify what sort of sensitive data exists in that bucket.
Click Dashboard on the left navigation. You should see the following data classifications:
You can slide the risk slider to filter data classifications based on risk levels.
Click the magnifying glass to the left of the bucket name listed.
Check if any of the data in the bucket is considered a high risk
Look for the Object PII priority field and Object risk level field
Verify if any of the data is unencrypted
Look for the Object encryption field. (Does a portion of the blue bar indicate that encryption is set to none?)
At this point you have identified that there is a bucket with high risk data that has open public read permissions and that certain objects in that bucket are not encrypted. When you first configured the environment you enabled default encryption for the bucket so this could be an indicator that someone has disabled it.
Since you are already in the Macie service, create a new Basic Alert that will alert you in the future if default encryption is disabled on any of your buckets.
Click on Settings in the left navigation and then Basic Alerts.
Click on Add New
Create an alert with the following parameters:
Alert title: Encryption Removed
Description: Evidence of encryption being removed from a bucket
Category: Data Compliance
Query: eventNameErrorCode.key:DeleteBucketEncryption
Macie allows you to create queries using the Apache Lucene Query Parser Syntax. The query created for this alert uses the Macie field name eventNameErrorCode.key which corresponds to the CloudTrail field name eventName.
Index: CloudTrail Data
Severity: Critical
You can leave the other options at the default settings
Click Save
In the list of alerts find the alert you just created and click on the magnifying glass to the right of the screen to run the alert.
Review the alert details.
Next you need to track down if someone recently disabled default encryption and who did it.
Go to the AWS CloudTrail console
Click Event History on the left navigation.
Set the Filter to Event name and for the event name enter DeleteBucketEncryption. Set the Time Range to today.
Expand the latest event and click on View Event to see the details of the API call.
Which AWS IAM Role disabled default encryption on the S3 Bucket?
Is this the same AWS IAM Role seen in your GuardDuty findings?
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.)
The IAM credentials for the instance were stolen, published to S3, and used to perform reconnaissance against the account.
An S3 bucket was made public and encryption was removed - most likely for data exfiltration.
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.
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.
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.
Go to the AWS Config console.
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
Click Resources in the left navigation.
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 threat-detection-wksp-compromised for the Tag value (this is allowing us to search for the NACL with that name):
Click on the Network ACL ID in the Config timeline column.
On the next screen you should see two Change events in the timeline. Click on Change for each one to see what occurred.
Evaluate the NACL changes.
What does the new NACL rule do?
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.
Go to the Amazon EC2 Console.
Find the running instances with the name threat-detection-wksp: Compromised Instance.
Under the Description tab, click on the Security Group for the compromised instance.
View the rules under the Inbound tab.
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.
Click Save
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.
First verify what the current credentials are for the EC2 instance.
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 threat-detection-wksp: Compromised Instance with a Ping status of Online.
To see the keys currently active on the instance, click on Run Command on the left navigation and then click Run a Command.
For Command document select AWS-RunShellScript
You may need to scroll through the list or just enter the document name in the search bar.
Leave the Document version at the default.
Under Command Parameters type the following in Commands:
Under Targets select Manually selecting instances and check the checkbox next to threat-detection-wksp: Compromised Instance.
Under Output options uncheck the checkbox labeled Enable writing to an S3 bucket.
Leave all of the other options at their default, scroll to the end and click Run.
Scroll down to the Targets and outputs section and click the Instance ID (which should correspond to the instance ID of the compromised instance)
Expand Step 1 - Output and make note of the AccessKeyID, SecretAccessKey, and Token. (the command will take a minute or so to run)
Now revoke the IAM Role session:
Browse to the AWS IAM console.
Click Roles and the threat-detection-wksp-compromised-ec2 role (this is the role attached to the compromised instance).
Click on the Revoke sessions tab.
Click on Revoke active sessions.
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.
In the EC2 console Stop the Instance named threat-detection-wksp: Compromised Instance.
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.
Repeat the first 10 Systems Manager 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.
With the EC2 instance access scoped down and the IAM credentials revoked, we need to stop external access to the S3 bucket. Before we restore the previous configuration, we can quickly make the bucket only accessible from inside the VPC. Then we can re-enable encryption.
First, check the configuration of the S3 endpoint in your environment by going to Amazon VPC and clicking on Endpoints on the left navigation.
Copy the Endpoint ID (if there are multiple endpoints, look for the one with the VPC ID that ends in threat-detection-wksp)
Click the Policy tab and review the policy statement. Notice that all access is allowed.
Click the Route Tables tab to get the Route Table ID associated with this endpoint. You can then go to the VPC to see which subnets are associated with this route table and therefore the endpoint.
Notice that routing to S3 is through the VPC endpoint
Go to the Amazon S3 console.
Click the bucket that starts with threat-detection-wksp- and ends in -data.
Click on the Permissions tab.
Click Bucket Policy
Update the Bucket Policy with the following policy:
Be sure to replace with the name of the bucket and with endpoint ID you copied down earlier.
Click Save. Now regardless of the bucket’s Access Control List, if the request for get object isn’t coming from the VPC endpoint it will be denied. This also provides more security and better pricing for legitimate traffic.
Is there still a problem with the bucket permissions given the Access Control List that is still in place?
To quickly restore the previous configuration for this bucket, we start by going to the AWS Config console.
Under Resources click on S3 Bucket.
Click on your Bucket (bucket name starts with threat-detection-wksp- and ends in -data).
Click on Change under the previous configuration in the slider at the top of the screen
Make note of the changes to Permissions
Click on Manage Resource in the top right. This will take you to the S3 console.
Click on the Permissions tab.
Remove Public Access based on Config change you just looked at.
Click on the Properties Tab.
Re-enable S3 Default AES-256 encryption.
With the configuration reestablished and some additional protections in place, you can focus on alerts and automated remediations in the event of another attack.
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.
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.)
Review & Discussion – 10 min
Questions – 10 min
Cleanup – 5 min
Diagram of the overall lab setup:
In Module 1 of the lab you setup the initial components of your infrastructure including GuardDuty, Macie and a simple notification and remediation pipeline. Some of the steps required manual configuration but you also ran a CloudFormation template which setup 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 attack's computer. The other instance (named Compromised Instance) was your web server and it was taken over by the Malicious Host. In Module 3 you investigated the attack, remediated the damage, and setup some automated remediations for future attacks.
There are two instances created by the Module 2 CloudFormation template. They are in the same VPC but different subnets. The Malicious Host represents the attacker which we pretend is on the Internet. The Elastic IP on the Malicious Host is in a custom threat list in GuardDuty. The other instance named Compromised Instance represents the web server that was lifted and shifted into AWS.
Although company policy is 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.
The Malicious Host performed a brute force SSH password attack against the Compromised Instance. The brute force attack is designed to be successful.
GuardDuty Finding: UnauthorizedAccess:EC2/SSHBruteForce
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 (/threat-detection-wksp/var/log/secure).
The EC2 Instance that is created in the Module 2 CloudFormation template disabled default encryption on the Databucket. In addition the CloudFormation template made the Data bucket public. This is used for the Macie part of the investigation in Module 3. We pretend that the attacker made the bucket public and removed the default encryption from the bucket.
Macie Alert: S3 Bucket IAM policy grants global read rights
The Compromised Instance also has a cron job that continuously pings the Malicious Host to generate a GuardDuty finding based off the custom threat list.
GuardDuty Finding: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom
The API Calls that generated the API findings come from the Malicious Host. The calls use the temp creds from the IAM role for EC2 running on the Malicious Host. The GuardDuty findings are generated because the EIP attached to the Malicious Host is in a custom threat list.
GuardDuty Finding: Recon:IAMUser/MaliciousIPCaller.Custom
GuardDuty Finding: UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom
A number of CloudWatch Events Rules are evoked by the GuardDuty findings and then these trigger various services.
CloudWatch Event Rule: The generic GuardDuty finding invokes a CloudWatch Event rule which triggers SNS to send an email.
CloudWatch Event Rule: The generic Macie alert invokes a CloudWatch Event rule which triggers SNS to send an email.
CloudWatch Event Rule: The SSH brute force attack finding invokes a CloudWatch Event rule which triggers a Lambda function to block the attacker IP address of the attacker via a NACL as well as a Lambda function that runs an Inspector scan on the EC2 instance.
CloudWatch Event Rule: The Unauthorized Access Custom MaliciousIP finding invokes a CloudWatch Event rule which triggers a Lambda function to block the IP address of the attacker via a NACL.
In order to prevent charges to your account 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 cleanup when you are done. It is very easy to leave things running in an AWS account, forgot about it, and then accrue charges.
You will need to manually delete some resources before you delete the CloudFormation stacks so please do the following steps in order.
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 threat-detection-wksp.
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 threat-detection-wksp-compromised-ec2.
Click the check box next to it and click Delete.
Repeat the steps above for the role named AWSServiceRoleForAmazonInspector.
Delete all three S3 buckets created by the Module 1 CloudFormation template (the buckets that start with threat-detection-wksp and 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.
Delete Module 1 and 2 CloudFormation stacks (ThreatDetectionWksp-Env-Setup and ThreatDetectionWksp-Attacks).
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.
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.
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 threat-detection-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/threat-detection-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/threat-detection-wksp-remediation-inspector
/aws/lambda/threat-detection-wksp-remediation-nacl
/threat-detection-wksp/var/log/secure
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 threat-detection-wkspin the Subscription ARN.
Select Action and then click Delete subscriptions
Disable Macie (if you didn't already have Macie enabled before the workshop).
Go the Amazon Macie console.
In the upper right-hand corner select the down arrow to the left of the Region and select Macie General Settings.
Check the two boxes and click Disable Amazon Macie
Disabling Macie will actually log you out of the AWS Console so you will need to log back to do any other tasks.
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:
Now let's examine the low severity UnauthorizedAccess:EC2/SSHBruteForce finding since this was one of the first findings to show up.
