GITBOOK-505: change request with no subject merged in GitBook

HackTricks-wiki · Dec 27, 2023 · 6195015 · 6195015
1 parent d04ea1e
commit 6195015
Show file tree

Hide file tree

Showing 90 changed files with 442 additions and 88 deletions.
diff --git a/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1).png b/.gitbook/assets/image (1) (1).png
diff --git a/.gitbook/assets/image (1).png b/.gitbook/assets/image (1).png
diff --git a/.gitbook/assets/image (10) (1) (1) (1).png b/.gitbook/assets/image (10) (1) (1) (1).png
diff --git a/.gitbook/assets/image (10) (1) (1).png b/.gitbook/assets/image (10) (1) (1).png
diff --git a/.gitbook/assets/image (10) (1).png b/.gitbook/assets/image (10) (1).png
diff --git a/.gitbook/assets/image (10).png b/.gitbook/assets/image (10).png
diff --git a/.gitbook/assets/image (100).png b/.gitbook/assets/image (100).png
diff --git a/.gitbook/assets/image (101).png b/.gitbook/assets/image (101).png
diff --git a/.gitbook/assets/image (102).png b/.gitbook/assets/image (102).png
diff --git a/.gitbook/assets/image (103).png b/.gitbook/assets/image (103).png
diff --git a/.gitbook/assets/image (104).png b/.gitbook/assets/image (104).png
diff --git a/.gitbook/assets/image (105).png b/.gitbook/assets/image (105).png
diff --git a/.gitbook/assets/image (106).png b/.gitbook/assets/image (106).png
diff --git a/.gitbook/assets/image (107).png b/.gitbook/assets/image (107).png
diff --git a/.gitbook/assets/image (108).png b/.gitbook/assets/image (108).png
diff --git a/.gitbook/assets/image (109).png b/.gitbook/assets/image (109).png
diff --git a/.gitbook/assets/image (11) (1) (2) (1).png b/.gitbook/assets/image (11) (1) (2) (1).png
diff --git a/.gitbook/assets/image (11) (1) (2).png b/.gitbook/assets/image (11) (1) (2).png
diff --git a/.gitbook/assets/image (11) (1).png b/.gitbook/assets/image (11) (1).png
diff --git a/.gitbook/assets/image (11).png b/.gitbook/assets/image (11).png
diff --git a/.gitbook/assets/image (110).png b/.gitbook/assets/image (110).png
diff --git a/.gitbook/assets/image (111).png b/.gitbook/assets/image (111).png
diff --git a/.gitbook/assets/image (2) (1) (1) (1) (1).png b/.gitbook/assets/image (2) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (2) (1) (1) (1).png b/.gitbook/assets/image (2) (1) (1) (1).png
diff --git a/.gitbook/assets/image (2) (1) (1).png b/.gitbook/assets/image (2) (1) (1).png
diff --git a/.gitbook/assets/image (2) (1).png b/.gitbook/assets/image (2) (1).png
diff --git a/.gitbook/assets/image (2).png b/.gitbook/assets/image (2).png
diff --git a/.gitbook/assets/image (3) (1) (2) (1).png b/.gitbook/assets/image (3) (1) (2) (1).png
diff --git a/.gitbook/assets/image (3) (1) (2).png b/.gitbook/assets/image (3) (1) (2).png
diff --git a/.gitbook/assets/image (3) (1).png b/.gitbook/assets/image (3) (1).png
diff --git a/.gitbook/assets/image (3).png b/.gitbook/assets/image (3).png
diff --git a/.gitbook/assets/image (4) (1) (3).png b/.gitbook/assets/image (4) (1) (3).png
diff --git a/.gitbook/assets/image (4) (1).png b/.gitbook/assets/image (4) (1).png
diff --git a/.gitbook/assets/image (4).png b/.gitbook/assets/image (4).png
diff --git a/.gitbook/assets/image (5) (1) (1) (2).png b/.gitbook/assets/image (5) (1) (1) (2).png
diff --git a/.gitbook/assets/image (5) (1) (1).png b/.gitbook/assets/image (5) (1) (1).png
diff --git a/.gitbook/assets/image (5) (1).png b/.gitbook/assets/image (5) (1).png
diff --git a/.gitbook/assets/image (5).png b/.gitbook/assets/image (5).png
diff --git a/.gitbook/assets/image (6) (1) (2).png b/.gitbook/assets/image (6) (1) (2).png
diff --git a/.gitbook/assets/image (6) (1).png b/.gitbook/assets/image (6) (1).png
diff --git a/.gitbook/assets/image (6).png b/.gitbook/assets/image (6).png
diff --git a/.gitbook/assets/image (7) (1) (2) (1).png b/.gitbook/assets/image (7) (1) (2) (1).png
diff --git a/.gitbook/assets/image (7) (1) (2).png b/.gitbook/assets/image (7) (1) (2).png
diff --git a/.gitbook/assets/image (7) (1).png b/.gitbook/assets/image (7) (1).png
diff --git a/.gitbook/assets/image (7).png b/.gitbook/assets/image (7).png
diff --git a/.gitbook/assets/image (8) (1) (1) (1) (1).png b/.gitbook/assets/image (8) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (8) (1) (1) (1).png b/.gitbook/assets/image (8) (1) (1) (1).png
diff --git a/.gitbook/assets/image (8) (1) (1).png b/.gitbook/assets/image (8) (1) (1).png
diff --git a/.gitbook/assets/image (8) (1).png b/.gitbook/assets/image (8) (1).png
diff --git a/.gitbook/assets/image (8).png b/.gitbook/assets/image (8).png
diff --git a/.gitbook/assets/image (9) (1) (1) (1).png b/.gitbook/assets/image (9) (1) (1) (1).png
diff --git a/.gitbook/assets/image (9) (1) (1).png b/.gitbook/assets/image (9) (1) (1).png
diff --git a/.gitbook/assets/image (9) (1).png b/.gitbook/assets/image (9) (1).png
diff --git a/.gitbook/assets/image (9).png b/.gitbook/assets/image (9).png
diff --git a/.gitbook/assets/image (98).png b/.gitbook/assets/image (98).png
diff --git a/.gitbook/assets/image (99).png b/.gitbook/assets/image (99).png
diff --git a/.gitbook/assets/image.png b/.gitbook/assets/image.png
diff --git a/SUMMARY.md b/SUMMARY.md
@@ -326,15 +326,17 @@
     * [Az - Virtual Machines](pentesting-cloud/azure-security/vms.md)
   * [Az - Permissions for a Pentest](pentesting-cloud/azure-security/az-permissions-for-a-pentest.md)
   * [Az - Lateral Movement (Cloud - On-Prem)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md)
-    * [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
-    * [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md)
-    * [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md)
-    * [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md)
-    * [Azure AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
+    * [Az AD Connect - Hybrid Identity](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/README.md)
       * [Federation](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md)
       * [PHS - Password Hash Sync](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md)
       * [PTA - Pass-through Authentication](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/pta-pass-through-authentication.md)
       * [Seamless SSO](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/seamless-sso.md)
+    * [Az - Local Cloud Credentials](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md)
+    * [Az - Pass the Cookie](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md)
+    * [Az - Pass the Certificate](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md)
+    * [Az - Pass the PRT](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md)
+    * [Az - Phishing Primary Refresh Token (Microsoft Entra)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md)
+    * [Az - Primary Refresh Token (PRT)](pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md)
   * [Az - Persistence](pentesting-cloud/azure-security/az-persistence.md)
   * [Az - Dynamic Groups Privesc](pentesting-cloud/azure-security/dynamic-groups.md)
 * [Digital Ocean Pentesting](pentesting-cloud/digital-ocean-pentesting/README.md)

diff --git a/...g-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md b/...g-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
@@ -22,7 +22,7 @@ If an attacker can somehow compromise the Github Action, he will be able to **co
 
 Example of artifact **download from a different repository**:
 
-<figure><img src="../../../.gitbook/assets/image (8) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (8) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 For more info and defence options (such as hardcoding the artifact to download) check [https://www.legitsecurity.com/blog/artifact-poisoning-vulnerability-discovered-in-rust](https://www.legitsecurity.com/blog/artifact-poisoning-vulnerability-discovered-in-rust)
 

diff --git a/pentesting-ci-cd/jenkins-security/README.md b/pentesting-ci-cd/jenkins-security/README.md
@@ -336,7 +336,7 @@ You can list the secrets accessing `/credentials/` if you have enough permission
 
 If you can **see the configuration of each project**, you can also see in there the **names of the credentials (secrets)** being use to access the repository and **other credentials of the project**.
 
-![](<../../.gitbook/assets/image (9) (1) (1).png>)
+![](<../../.gitbook/assets/image (9) (1) (1) (1).png>)
 
 #### From Groovy
 

diff --git a/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md b/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md
@@ -18,7 +18,7 @@ Other ways to support HackTricks:
 
 In "New Item" (accessible in `/view/all/newJob`) select **Pipeline:**
 
-![](<../../.gitbook/assets/image (10) (1) (1).png>)
+![](<../../.gitbook/assets/image (10) (1) (1) (1).png>)
 
 In the **Pipeline section** write the **reverse shell**:
 

diff --git a/pentesting-ci-cd/jenkins-security/scm-ip-whitelisting-bypass.md b/pentesting-ci-cd/jenkins-security/scm-ip-whitelisting-bypass.md
@@ -76,7 +76,7 @@ http://jenkins.example-domain.com/j_acegi_security_check?j_username=admin&j_pass
 We fire the webhook, and see the results. All SCM vendors display the HTTP request and response sent through the webhook in their UI.\
 If the login attempt fails, we’re redirected to the login error page.
 
-<figure><img src="../../.gitbook/assets/image (6) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (6) (1) (2).png" alt=""><figcaption></figcaption></figure>
 
 But if the **login is successful**, we’re redirected to the main Jenkins page, and a **session cookie is set**.
 
@@ -110,7 +110,7 @@ It means we can:
 
 Jenkins **login accepts a redirection parameter** – “_from_”. Originally used to **redirect users to the page they aimed to reach after they login**, but in our case – a feature we can abuse to send a GET request attached with a session cookie to an internal Jenkins page of our choice. Let’s see how:
 
-<figure><img src="../../.gitbook/assets/image (5) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (5) (1) (1) (2).png" alt=""><figcaption></figcaption></figure>
 
 1. Set a webhook with the following URL:
 

diff --git a/pentesting-ci-cd/okta-security/README.md b/pentesting-ci-cd/okta-security/README.md
@@ -32,7 +32,7 @@ To perform a security review of an Okta environment you should ask for **adminis
 
 ### Summary
 
-There are **users** (which can be **stored in Okta,** logged from configured **Identity Providers** or authenticated via **Active Directory** or LDAP). \
+There are **users** (which can be **stored in Okta,** logged from configured **Identity Providers** or authenticated via **Active Directory** or LDAP).\
 These users can be inside **groups**.\
 There are also **authenticators**: different options to authenticate like password, and several 2FA like WebAuthn, email, phone, okta verify (they could be enabled or disabled)...
 
@@ -64,19 +64,19 @@ getST.py -spn HTTP/clientname.kerberos.okta.com -dc-ip 1.2.3.4 LAB/comprommisedu
 
 With a ticket retrieved for the AD user, we need to inject this on a host we control using Rubeus or Mimikatz:
 
-<figure><img src="../../.gitbook/assets/image (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 You’ll need to make sure that `clientname.kerberos.okta.com` is added to the “Intranet” security zone in Internet Options. And then, in our browser, if we hit the below URL, we should find that we receive a JSON response providing an `OK` result when the Kerberos ticket is accepted:
 
-<figure><img src="../../.gitbook/assets/image (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 Heading over to the Okta dashboard, if everything is OK, you’ll be signed in.
 
 Moreover, if we are able to compromise the actual Okta service account exposing the delegation SPN, we can perform a Silver Ticket attack.
 
 It should be noted that as Okta only support AES for ticket encryption, we’ll need to ensure we have the AES key or plaintext password to authenticate:
 
-<figure><img src="../../.gitbook/assets/image (2).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (2) (1).png" alt=""><figcaption></figcaption></figure>
 
 To craft our ticket for the victim user of `testuser`, we use:
 
@@ -88,7 +88,7 @@ ticketer.py -domain-sid S-1-5-21-4170871944-1575468979-147100471 -domain lab.loc
 
 And again, deliver this to Okta via our browser session:
 
-<figure><img src="../../.gitbook/assets/image (3).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (3) (1).png" alt=""><figcaption></figcaption></figure>
 
 ### Hijacking Okta AD Agent
 
@@ -104,15 +104,15 @@ C:\Program Files (x86)\Okta\Okta AD Agent
 
 We’re going to take a look at the `OktaAgentService.exe.config`, which contains a few interesting bits of XML:
 
-<figure><img src="../../.gitbook/assets/image (4).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (4) (1).png" alt=""><figcaption></figcaption></figure>
 
 The Base64 encoded `AgentToken` is where we set our sights. If we open up `OktaAgentService.exe` in dnSpy, we can see how these values are decrypted:
 
-<figure><img src="../../.gitbook/assets/image (5).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (5) (1).png" alt=""><figcaption></figcaption></figure>
 
 That’s right.. good ol’ DPAPI! The `RandomEntropy` value is set to a value of:
 
-<figure><img src="../../.gitbook/assets/image (6).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (6) (1).png" alt=""><figcaption></figcaption></figure>
 
 This means that we can decrypt this Base64 encoded XML value using:
 
@@ -126,7 +126,7 @@ $k = [System.Security.Cryptography.ProtectedData]::Unprotect([System.Convert]::F
 
 The DPAPI master key used belongs to the user account running the “Okta AD Agent” service, so you will need to run the above in the context of the service account, or grab the master key for the account and decrypt:
 
-<figure><img src="../../.gitbook/assets/image (7).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (7) (1).png" alt=""><figcaption></figcaption></figure>
 
 For example, within `OktaAgentService.exe.config` we have two further XML fields, `APPID` and `AGENTID`. Combined with the `AgentToken`, we can make a `GET` request as follows:
 
@@ -196,11 +196,11 @@ https://example.okta.com/oauth2/authorize?redirect_uri=%2Foauth-response&respons
 
 This will give you a permission prompt for you to accept:
 
-<figure><img src="../../.gitbook/assets/image (8).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (8) (1).png" alt=""><figcaption></figcaption></figure>
 
 Accepting the presented prompt will give you a redirection to `/oauth-response` along with a `code` parameter:
 
-<figure><img src="../../.gitbook/assets/image (9).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (9) (1).png" alt=""><figcaption></figcaption></figure>
 
 We need to take this `code` parameter and request a API token using the POST request:
 
@@ -323,7 +323,7 @@ python ./main.py --tenant-domain example.okta.com --skeleton-key WibbleWobble99
 
 Another technique which has been very useful during assessments is the deployment of a fake SAML provider.
 
-Recently Okta actually provided [a security update](https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection)  on in-the-wild attacks using this technique, so it’s certainly useful to know about this when simulating activity on an environment, especially for clients who would like to test their detections of this particular attack.
+Recently Okta actually provided [a security update](https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection) on in-the-wild attacks using this technique, so it’s certainly useful to know about this when simulating activity on an environment, especially for clients who would like to test their detections of this particular attack.
 
 If we hold access to an elevated Okta account, we can deploy an external Identity Provider as part of Okta’s functionality. This allows external providers like Entra ID to complete the authentication before redirecting the user to Okta to select integrated apps.
 
@@ -335,13 +335,13 @@ This server will listen for incoming HTTP requests on `/saml`, so we first need
 
 First, we select the SAML 2.0 IDP:
 
-<figure><img src="../../.gitbook/assets/image (10).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (10) (1).png" alt=""><figcaption></figcaption></figure>
 
 When configuring the IDP, we need to pay attention to a few settings. The first is the `Name`, which is the friendly name to be shown to any other administrators of Okta.
 
 Next is the issuer URL, which should be set to the value of an identifier in URI format. This again can be anything, but we’ll use `https://www.example.com/`.
 
-<figure><img src="../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (11) (1).png" alt=""><figcaption></figcaption></figure>
 
 We also need to set the `IdP Single Sign-On URL` field to the location where our SAML server is running. Now, the cool thing is that this DOES NOT need to be a URL which points to our server. I feel like it’s worth pointing this out because we can get quite creative in the URL that we input here and make the Blue Team’s job a bit harder. For example, we can set this field to something like `https://idp.google.com/saml` if we want to, and the only thing we need to be able to do is to catch the inbound SAML request. Here’s the cool thing: the SAML request is forwarded client-side. By that, I mean that Okta will generate the SAML `AuthRequest` and have our browser redirect to `https://idp.google.com/` along with the SAML request. This of course, means that we can just modify the local hosts file to point `idp.google.com` to `127.0.0.1`:
 

diff --git a/pentesting-ci-cd/travisci-security/README.md b/pentesting-ci-cd/travisci-security/README.md
@@ -44,7 +44,7 @@ It looks like It's not possible to set crons inside the `.travis.yml` according
 
 TravisCI by default disables sharing env variables with PRs coming from third parties, but someone might enable it and then you could create PRs to the repo and exfiltrate the secrets:
 
-![](<../../.gitbook/assets/image (1) (1) (1) (1) (1) (1).png>)
+![](<../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png>)
 
 ### Dumping Secrets
 

diff --git a/pentesting-ci-cd/travisci-security/basic-travisci-information.md b/pentesting-ci-cd/travisci-security/basic-travisci-information.md
@@ -99,7 +99,7 @@ Travis CI Enterprise is an **on-prem version of Travis CI**, which you can deplo
 
 The amount of deployed TCI Worker and build environment OS images will determine the total concurrent capacity of Travis CI Enterprise deployment in your infrastructure.
 
-![](<../../.gitbook/assets/image (8) (1) (1) (1).png>)
+![](<../../.gitbook/assets/image (8) (1) (1) (1) (1).png>)
 
 <details>
 

diff --git a/...g-cloud/aws-pentesting/aws-post-exploitation/aws-codebuild-post-exploitation.md b/...g-cloud/aws-pentesting/aws-post-exploitation/aws-codebuild-post-exploitation.md
@@ -33,7 +33,7 @@ The **CodeBuild project must have access** to the configured source provider, ei
 An attacker with **elevated permissions in over a CodeBuild** could abuse this configured access to leak the code of the configured repo and others where the set creds have access.\
 In order to do this, an attacker would just need to **change the repository URL to each repo the config credentials have access** (note that the aws web will list all of them for you):
 
-<figure><img src="../../../.gitbook/assets/image (11) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (11) (1) (2).png" alt=""><figcaption></figcaption></figure>
 
 And **change the Buildspec commands to exfiltrate each repo**.
 

diff --git a/...ost-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md b/...ost-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md
@@ -35,12 +35,15 @@ The Docker image you could use is [https://github.com/carlospolop/docker-mitm](h
      * **DO NOT SET `http_proxy`** to not intercept requests to the metadata endpoint.
    * You could use **`ngrok`** like `ngrok tcp 4444` lo set the proxy to your host
    * Once you have the Docker image built, **upload it to a public repo** (Dockerhub, ECR...)
-2. **Set the environment**
-   * Create a **new Codebuild project** or **modify** the environment of an existing one.
-   * Set the project to use the **previously generated Docker image**
-   *
+2.  **Set the environment**
 
-       <figure><img src="../../../../.gitbook/assets/image (18).png" alt=""><figcaption></figcaption></figure>
+    * Create a **new Codebuild project** or **modify** the environment of an existing one.
+    * Set the project to use the **previously generated Docker image**
+    *
+
+    ```
+    <figure><img src="../../../../.gitbook/assets/image (18).png" alt=""><figcaption></figcaption></figure>
+    ```
 3. **Set the MitM proxy in your host**
    * As indicated in the **Github repo** you could use something like:
 
@@ -99,9 +102,9 @@ An attacker with **elevated permissions in over a CodeBuild could leak the Githu
 
 <figure><img src="../../../../.gitbook/assets/image (91).png" alt=""><figcaption></figcaption></figure>
 
-<figure><img src="../../../../.gitbook/assets/image (10) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../../.gitbook/assets/image (10) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
-* Then, change the URL of the github repo to use HTTP instead of HTTPS, for example: **http://**github.com/carlospolop-forks/TestActions
+* Then, change the URL of the github repo to use HTTP instead of HTTPS, for example: \*\*http://\*\*github.com/carlospolop-forks/TestActions
 * Then, run the basic example from [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) in the port pointed by the proxy variables (http\_proxy and https\_proxy)
 
 ```python

diff --git a/pentesting-cloud/aws-pentesting/aws-post-exploitation/aws-kms-post-exploitation.md b/pentesting-cloud/aws-pentesting/aws-post-exploitation/aws-kms-post-exploitation.md
@@ -106,7 +106,7 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 Note that if you change that policy and only give access to an external account, and then from this external account you try to set a new policy to **give the access back to original account, you won't be able**.
 {% endhint %}
 
-<figure><img src="../../../.gitbook/assets/image (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ### Destroy keys
 

diff --git a/pentesting-cloud/aws-pentesting/aws-post-exploitation/aws-s3-post-exploitation.md b/pentesting-cloud/aws-pentesting/aws-post-exploitation/aws-s3-post-exploitation.md
@@ -42,7 +42,7 @@ For example, **airflow** could be storing **DAGs** **code** in there, or **web p
 
 The following screenshot shows an example of a file that was targeted for a ransomware attack. As you can see, the account ID that owns the KMS key that was used to encrypt the object (7\*\*\*\*\*\*\*\*\*\*2) is different than the account ID of the account that owns the object (2\*\*\*\*\*\*\*\*\*\*1).
 
-![](<../../../.gitbook/assets/image (2) (1) (1) (1).png>)
+![](<../../../.gitbook/assets/image (2) (1) (1) (1) (1).png>)
 
 Here you can [find a ransomware example](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/s3\_ransomware/s3-ransomware-poc.py) that does the following:
 

diff --git a/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md b/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
@@ -62,7 +62,7 @@ Note that ECR requires that users have **permission** to make calls to the **`ec
 
 It's possible to automatically replicate a registry in an external account configuring cross-account replication, where you need to **indicate the external account** there you want to replicate the registry.
 
-<figure><img src="../../../.gitbook/assets/image (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 First, you need to give the external account access over the registry with a **registry policy** like:
 

diff --git a/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md b/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md
@@ -248,7 +248,7 @@ It's possible to generate API keys in the API Gateway portal and even set how mu
 
 To make an API key work, you need to add it to a **Usage Plan**, this usage plan mus be added to the **API Stage** and the associated API stage needs to have a configured a **method throttling** to the **endpoint** requiring the API key:
 
-<figure><img src="../../../.gitbook/assets/image (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ## Unauthenticated Access