Release defensive manuals

README.md

@@ -162,7 +162,7 @@ Litesh Ghute, Software Engineer (Cloud) Intern, INE <[email protected]>
 
 # Solutions
 
-The manuals are available in the [solutions](solutions/) directory 
+The offensive manuals are available in the [attack-manuals](attack-manuals/) directory, and the defensive manuals are available in the [defense-manuals](defense-manuals/) directory. 
 
 Module 1 Exploitation Videos: <https://www.youtube.com/playlist?list=PLcIpBb4raSZEMosUmY8KpxPWtjKRMSmNx>
 

defence-manuals/AWS Config.md

@@ -0,0 +1,135 @@
+# Objective
+Detect changes in configuration using AWS Config
+
+# Solution
+
+* Log in to [AWS account](https://aws.amazon.com/) where [AWS Goat](https://github.com/ine-labs/AWSGoat) infrastructure has been deployed
+
+*  Now, search for **Config** and head to it's page.
+
+    ![](./images/AWS-Config/1.png)
+
+* Click on **Get Started**
+
+    ![](./images/AWS-Config/2.png)
+
+## Creating Config Rule
+
+* In the next page, select the options as shown below
+
+    ![](./images/AWS-Config/3.png)
+
+* Leave the rest as defualt and click on **Next**.
+
+* In the **Step 2** page, search for `iam-policy-no-statements-with-admin-access` under **AWS Managed Rules**.
+
+    ![](./images/AWS-Config/4.png)
+
+* Select that rule and click on **Next**.
+
+* Leave all options as default in the next page and create the rule.
+
+* We have successfully created a rule which monitors for policy that has access to all services and all resources.
+
+* Let's check if this rule is working properly.
+
+## Testing Config Rule
+
+* Head to **IAM** > **Policies** > **Create Policy** on the console
+
+    ![](./images/AWS-Config/5.png)
+
+* Now, in the **Create Policy**, select on **JSON** and paste the below policy.
+
+    ```JSON
+    {
+        "Version": "2012-10-17",
+        "Statement": [
+            {
+                "Effect":"Allow",
+                "Action":"*",
+                "Resource":"*"
+            }
+        ]
+    }
+    ```
+
+    ![](./images/AWS-Config/6.png)
+
+* Click on **Next** and name the policy as `FullAccessPolicy`.
+
+    ![](./images/AWS-Config/7.png)
+
+* Now, head back to **Config** > **Rules**.
+
+    ![](./images/AWS-Config/8.png)
+
+* We can see that now we have 1 Non-Compliant Resource! click on the rule to view the **Non-Compliant Resourse**.
+
+* Voila! it is the policy that we had just created.
+
+    ![](./images/AWS-Config/9.png)
+
+* Now, delete the policy and check if the **Detective Complaince** status has changed.
+
+    ![](./images/AWS-Config/10.png)
+
+    ![](./images/AWS-Config/11.png)
+
+* The status changed, the rule is working perfectly! You can add more rules to monitor the changes in the configuration.
+
+# Inferences
+
+* AWS Config tracks and monitors changes in the configuration.
+
+* We can trigger the evaluations periodically or trigger them when all/specific resource changes.
+
+* When we created a policy with full access to all resources, AWS Config quickly evaluated the resources based on the trigger and changed the complaince status, this helps us identify if someone is trying to exploit our resources.
+
+* This can help us detect the attack performed in [IAM Privilege Escalation Manual](https://github.com/ine-labs/AWSGoat/blob/master/attack-manuals/module-1/07-IAM%20Privilege%20Escalation.md). where the hacker tries to create an overly permissive policy.
+
+# Additional Things To-Do
+
+* By performing above steps, we can only view the complaince status in AWS Console. We won't be able to check the Config page every now and then to view the complaince status. Therefore, we need an automatic notification system.
+
+* To do that, we can trigger the config to publish a message into an SNS Topic which in turn sends an email whenever the rule is non-complaint.
+
+* This is possible by creating a remediation to the rule in AWS Config.
+
+## Creating Topic
+
+* First, head over to **Simple Notification Sevice** Page.
+
+    ![](./images/AWS-Config/12.png)
+
+* Now, create a topic names `Config-Change-Email`.
+
+    ![](./images/AWS-Config/13.png)
+
+* Now, create a subscription for the topic. Select the **Protocol** as **Email** and enter the preferred email where you want to receive the notification.
+
+    ![](./images/AWS-Config/14.png)
+
+## Creating Remediation
+
+* Head back to **Config** > **Rules** and select **Manage Remediation** under **Actions** dropdown for our rule.
+
+    ![](./images/AWS-Config/15.png)
+
+* In the next page, select the options as shown below.
+
+    ![](./images/AWS-Config/16.png)
+
+* Type in the Topic arn, Message and AutomationAssumeRole.
+
+    ![](./images/AWS-Config/17.png)
+
+* We have successfully created a remediation. With this we will now be able to get an email notification whenever there is change in the configuration.
+
+# Further Readings
+
+* [What is AWS Config?](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+
+* [IAM Security Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+
+* [What is Amazon Macie?](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html)

defence-manuals/AWS IAM Access Analyzer.md

@@ -0,0 +1,111 @@
+# Objective
+
+Use AWS IAM Access Analyzer to identify resources shared with an external entity and unintended access to your resources and data, which may pose a security risk.
+
+# Solution
+
+Log in to [AWS account](https://aws.amazon.com/) where [AWS Goat](https://github.com/ine-labs/AWSGoat) infrastructure has been deployed.
+
+Search for "IAM" and navigate to the IAM dashboard.
+
+![](./images/AWS-IAM-Access-Analyzer/1.png)
+
+Click on "Access analyzer" from the access reports.
+
+![](./images/AWS-IAM-Access-Analyzer/2.png)
+
+Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, shared with an external entity. This lets you identify unintended access to your resources and data, which is a security risk.
+
+Now, Click on "Create analyzer".
+
+![](./images/AWS-IAM-Access-Analyzer/3.png)
+
+Set everything as default and click on "Create analyzer".
+
+Access Analyzer generates a finding for each instance of a resource shared outside of your account. The findings include details about the access and the external principal who granted it. When you create an analyzer, you choose an organization or AWS account to analyze. Any principal in the organization or account that you choose for the analyzer is considered trusted.
+
+![](./images/AWS-IAM-Access-Analyzer/4.png)
+
+Access Analyzer generates a finding for each instance of a resource-based policy that grants access to a resource within your zone of trust to a principal that is not within your zone of trust. Any sharing that is within the zone of trust is considered safe, so Access Analyzer does not generate a finding.
+
+Click on "Finding ID" of the resource "S3 Bucket". This will list details about the finding.
+
+![](./images/AWS-IAM-Access-Analyzer/5.png)
+
+This finding shows that the resource (S3 Bucket) is open to the public and "Read" and "List" operations can be performed on it.
+
+Here, Access level "List" is the unintended access to this S3 Bucket and this may lead to the sensitive data exposure. The "s3:ListBucket" permission returns a list of all buckets owned by the authenticated sender of the request and we don't want our user to have this permission. Whereas, "s3:GetObject" permission is simply used to retrieves objects from Amazon S3 bucket. And we need "s3:GetObject" permission to run our web application.
+
+Click on the resource ARN to navigate to the resource (Open it in a separate tab).
+
+![](./images/AWS-IAM-Access-Analyzer/6.png)
+
+Click on "Permissions" 
+
+![](./images/AWS-IAM-Access-Analyzer/7.png)
+
+Here, click on "Edit" and remove the "s3:ListBucket" action.
+
+![](./images/AWS-IAM-Access-Analyzer/8.png)
+
+Remove the "s3:ListBucket".
+
+![](./images/AWS-IAM-Access-Analyzer/9.png)
+
+Now, click on the "Save changes".
+
+![](./images/AWS-IAM-Access-Analyzer/10.png)
+
+We can see the permission got removed.
+
+![](./images/AWS-IAM-Access-Analyzer/11.png)
+
+Click on "Rescan" and you will see the "Status" got changed to "Resolved".
+
+If the resource is no longer shared outside of your zone of trust, the status of the finding is changed to Resolved. The finding is no longer displayed in the Active findings table, and instead is displayed in the Resolved findings table. Now, the access is removed, the status changed to Resolved.
+
+![](./images/AWS-IAM-Access-Analyzer/12.png)
+
+Now, navigate back to the findings dashboard and click on the another finding ID.
+
+![](./images/AWS-IAM-Access-Analyzer/13.png)
+
+This finding is due to the bucket being open to the public, as we intended. So, let us "Archive" this finding by clicking on the "Archive" button.
+
+![](./images/AWS-IAM-Access-Analyzer/14.png)
+
+Again, navigate back to the findings dashboard and click on the next finding ID.
+
+![](./images/AWS-IAM-Access-Analyzer/15.png)
+
+Same as before, this finding is due to the bucket being open to the public, as we intended. So, let us "Archive" this finding as well by clicking on the "Archive" button.
+
+You can click on the resource ARN to view the resource details.
+
+![](./images/AWS-IAM-Access-Analyzer/16.png)
+
+Click on the "Archive" button to archive the finding.
+
+When you archive a finding, it is removed from Active findings and the status changes to Archived.
+
+![](./images/AWS-IAM-Access-Analyzer/17.png)
+
+Navigate back to the findings dashboard. Since, we resolved and archived all the findings no more findings are listed here to resolve.
+
+![](./images/AWS-IAM-Access-Analyzer/18.png)
+
+# Inferences
+
+* Access Analyzer identifies the resources, shared with an external entity which may pose security threat.
+
+* Access Analyzer generates a finding for each instance of a resource shared outside of your account. The findings include details about the access and the external principal who granted it.
+
+* Using the findings we can take the necessary actions.
+
+* This can defend us against the attack performed in [IAM Privilege Escalation](https://github.com/ine-labs/AWSGoat/blob/master/attack-manuals/module-1/07-IAM%20Privilege%20Escalation.md) when the attacker tries to list the bucket objects. 
+
+# Further Readings
+
+* [What is IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+
+* [IAM Security Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)

defence-manuals/Amazon Guarduty.md

@@ -0,0 +1,101 @@
+# Objective
+
+Use Amazon GuardDuty findings to analyze S3 data events from your S3 buckets and monitor them for malicious and suspicious activity.
+
+# Solution
+
+Log in to [AWS account](https://aws.amazon.com/) where [AWS Goat](https://github.com/ine-labs/AWSGoat) infrastructure has been deployed.
+
+Search for "GuardDuty" and navigate to the GuardDuty dashboard.
+
+![](./images/Amazon-Guardduty/1.png)
+
+Amazon GuardDuty is a threat detection service that continuously monitors your AWS Service accounts, workloads, and data stored in Amazon S3 for malicious activity and provides detailed security findings for visibility and remediation.
+
+Click on "Get Started".
+
+![](./images/Amazon-Guardduty/2.png)
+
+Click on "Enable GuardDuty".
+
+![](./images/Amazon-Guardduty/3.png)
+
+A GuardDuty finding denotes a potential security issue discovered in your network. When GuardDuty detects unexpected and potentially malicious activity in your AWS environment, it generates a finding. You can view and manage your GuardDuty findings via the Findings page in the GuardDuty console, as well as through AWS CLI or API operations.
+
+Since GuardDuty takes time to generate the findings, there may not be any findings available initially. The findings will eventually appear after some time. Keep pressing the refresh button.
+
+![](./images/Amazon-Guardduty/4.png)
+
+Once the finding appears, click on the finding to get a detailed view. This will provide the details about the affected resources.
+
+![](./images/Amazon-Guardduty/5.png)
+
+Each GuardDuty finding has an assigned severity level and value that reflects the potential risk. GuardDuty breaks down this range into High, Medium, and Low severity levels. This bucket is having "High" severity level.
+
+![](./images/Amazon-Guardduty/6.png)
+
+The finding will provide the details about the affected resource. It will also provide the action done. Here the action was to change bucket Policy and it is listed as "PutBucketPolicy".
+
+![](./images/Amazon-Guardduty/7.png)
+
+The finding also informs you that the listed S3 bucket has been publicly exposed to all the authenticated AWS users because an IAM entity has changed a bucket policy on that S3 bucket.
+
+To take the necessary action on the resource (S3 bucket), click on the "Resource ID" and it will navigate you to the resource. 
+
+![](./images/Amazon-Guardduty/8.png)
+
+Here we want to check the bucket permissions so, click on the "Permissions" tab.
+
+![](./images/Amazon-Guardduty/9.png)
+
+Here, "s3:ListBucket" permission is the unintended access to this S3 Bucket and this may lead to the sensitive data exposure. The "s3:ListBucket" permission returns a list of all buckets owned by the authenticated sender of the request and we don't want our user to have this permission. Whereas, "s3:GetObject" permission is simply used to retrieves objects from Amazon S3 bucket. And we need "s3:GetObject" permission to run our web application.
+
+To edit the bucket permissions, click on the "Edit" button.
+
+![](./images/Amazon-Guardduty/10.png)
+
+Here remove the "s3:ListBucket" permission using editor and click on the "Save changes" button.
+
+![](./images/Amazon-Guardduty/11.png)
+
+You can see the Bucket policy got changed.
+
+![](./images/Amazon-Guardduty/12.png)
+
+Now, navigate back to the GuardDuty dashboard and click on the another finding available.
+
+You will notice that this finding is identical to the one discussed above, just the bucket name is different.
+
+![](./images/Amazon-Guardduty/13.png)
+
+![](./images/Amazon-Guardduty/14.png)
+
+To check the bucket policy click on the "Resource Id" and it will navigate you to the resource.
+
+![](./images/Amazon-Guardduty/15.png)
+
+Here, click on the "Permissions" tab.
+
+![](./images/Amazon-Guardduty/16.png)
+
+The bucket policy looks exactly what we wanted. So, we will not take any action or change anything here.
+
+![](./images/Amazon-Guardduty/17.png)
+
+Thus, GuardDuty generates the findings whenever it detects unexpected and potentially malicious activity in your AWS environment and allows us to take the necessary actions.
+
+# Inferences
+
+* GuardDuty is a threat detection service that continuously monitors your AWS Service accounts, workloads, and data stored in Amazon S3 for malicious activity.
+
+* When GuardDuty detects unexpected and potentially malicious activity in your AWS environment, it generates a finding.
+
+* Using the findings we can take the necessary actions.
+
+* This can defend us against the attack performed in [IAM Privilege Escalation](https://github.com/ine-labs/AWSGoat/blob/master/attack-manuals/module-1/07-IAM%20Privilege%20Escalation.md) when the attacker tries to list the bucket objects. 
+
+# Further Readings
+
+* [What is AWS GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html)
+
+* [IAM Security Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)