# Scaling threat detection and response in AWS

This workshop is broken up into the four modules below:

### I. Environment Build and Configuration

1. Deploy the AWS CloudFormation template


2. Setup Amazon CloudWatch event rules and automatic response

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

3. Enable AWS Security Hub


### II. Attack Simulation

1. Deploy another Cloudformation [Template](https://s3-us-west-2.amazonaws.com/sa-security-specialist-workshops-us-west-2/threat-detect-workshop/staging/02-attack-simulation-nom.yml)

> ***WARNING***
> -
> Do remember to change both instance types of your EC2, as the cloudformation template's default is **m5.Large** type which cost ±$0.1/hour


### III. Detection and Remediation (Here Comes the Attack)

1. Part 1 - Compromised AWS IAM credentials

The Iam instance profile contains **a unique ID** for the entity making the API request, and when the request is made using **temporary security credentials** (which is what happens for an assume role call) it also includes a session name. In this case the session name is the EC2 instance ID since the assume role call was done using an IAM role for EC2.


Respond:
1. **Revoke the IAM role sessions (IAM)**
2. Stop the Compromised EC2 Instance
3. Restart it
4. Verify if the access key is rotated via AWS Systems Manager

2. Part 2 - Compromised EC2 instance

1. Explore findings related to the instance ID (AWS Security Hub)

2. Determine if ssh password authentication is enabled on the EC2 instance (AWS Security Hub)

3. Determine if the attacker was able to login to the EC2 instance (CloudWatch logs)

Respond :
**Modify the EC2 security group (EC2)**

### IV. Review and Discussion

Cleanup~ ur done