fix links

src/pentesting-ci-cd/apache-airflow-security/README.md

@@ -53,7 +53,7 @@ If you have **access to the web console** you might be able to access some or al
 - **Variables** (Custom sensitive information might be stored here)
 - **Connections** (Custom sensitive information might be stored here)
   - Access them in `http://<airflow>/connection/list/`
-- [**Configuration**](./#airflow-configuration) (Sensitive information like the **`secret_key`** and passwords might be stored here)
+- [**Configuration**](#airflow-configuration) (Sensitive information like the **`secret_key`** and passwords might be stored here)
 - List **users & roles**
 - **Code of each DAG** (which might contain interesting info)
 

src/pentesting-ci-cd/cloudflare-security/README.md

@@ -34,7 +34,7 @@ On each Cloudflare's page:
 
 - [ ] Check for **sensitive information** in the **`Build log`**.
 - [ ] Check for **sensitive information** in the **Github repository** assigned to the pages.
-- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/).
+- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html).
 - [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any).
 - [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code**
 - [ ] In the details of each page `/<page_id>/pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**.

src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md

@@ -93,7 +93,7 @@ _I couldn't find any option related to security_
 
 ### **Workers Routes**
 
-_You should have already checked_ [_cloudflare workers_](./#workers)
+_You should have already checked_ [_cloudflare workers_](#workers)
 
 ### Rules
 

src/pentesting-ci-cd/gitea-security/README.md

@@ -86,7 +86,7 @@ A user token can be used **instead of a password** to **authenticate** against G
 
 ### With Oauth Application
 
-For an introduction about [**Gitea Oauth Applications check the basic information**](./#with-oauth-application).
+For an introduction about [**Gitea Oauth Applications check the basic information**](#with-oauth-application).
 
 An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
 

src/pentesting-ci-cd/github-security/README.md

@@ -51,7 +51,7 @@ Tools (each tool contains its list of regexes):
 
 ### External Forks
 
-It's possible to **compromise repos abusing pull requests**. To know if a repo is vulnerable you mostly need to read the Github Actions yaml configs. [**More info about this below**](./#execution-from-a-external-fork).
+It's possible to **compromise repos abusing pull requests**. To know if a repo is vulnerable you mostly need to read the Github Actions yaml configs. [**More info about this below**](#execution-from-a-external-fork).
 
 ### Github Leaks in deleted/internal forks
 
@@ -116,7 +116,7 @@ Note that **2FA may be used** so you will only be able to access this informatio
 > [!NOTE]
 > Note that if you **manage to steal the `user_session` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA.
 
-Check the section below about [**branch protections bypasses**](./#branch-protection-bypass) in case it's useful.
+Check the section below about [**branch protections bypasses**](#branch-protection-bypass) in case it's useful.
 
 ### With User SSH Key
 

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -153,7 +153,7 @@ It's possible to check the permissions given to a Github Token in other users re
 > [!NOTE]
 > This would be the easiest way to compromise Github actions, as this case suppose that you have access to **create a new repo in the organization**, or have **write privileges over a repository**.
 >
-> If you are in this scenario you can just check the [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action).
+> If you are in this scenario you can just check the [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
 ### Execution from Repo Creation
 
@@ -248,7 +248,7 @@ We have mentioned all the ways an external attacker could manage to make a githu
 
 ### Untrusted checkout execution
 
-In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](./#pull_request).
+In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](#pull_request).
 
 In case of a workflow using **`pull_request_target` or `workflow_run`** that depends on a workflow that can be triggered from **`pull_request_target` or `pull_request`** the code from the original repo will be executed, so the **attacker cannot control the executed code**.
 

src/pentesting-ci-cd/jenkins-security/README.md

@@ -105,7 +105,7 @@ If the compromised user has **enough privileges to create/modify a new Jenkins n
 
 ![](<../../images/image (218).png>)
 
-You will usually find Jenkins ssh credentials in a **global provider** (`/credentials/`), so you can also dump them as you would dump any other secret. More information in the [**Dumping secrets section**](./#dumping-secrets).
+You will usually find Jenkins ssh credentials in a **global provider** (`/credentials/`), so you can also dump them as you would dump any other secret. More information in the [**Dumping secrets section**](#dumping-secrets).
 
 ### **RCE in Jenkins**
 
@@ -163,7 +163,7 @@ The most common triggers to execute a custom pipeline are:
 
 ### Pipeline RCE
 
-In the previous RCE section it was already indicated a technique to [**get RCE modifying a pipeline**](./#rce-creating-modifying-pipeline).
+In the previous RCE section it was already indicated a technique to [**get RCE modifying a pipeline**](#rce-creating-modifying-pipeline).
 
 ### Checking Env variables
 
@@ -234,7 +234,7 @@ At the end of this page you can **find all the credential types**: [https://www.
 
 > [!WARNING]
 > The best way to **dump all the secrets at once** is by **compromising** the **Jenkins** machine (running a reverse shell in the **built-in node** for example) and then **leaking** the **master keys** and the **encrypted secrets** and decrypting them offline.\
-> More on how to do this in the [Nodes & Agents section](./#nodes-and-agents) and in the [Post Exploitation section](./#post-exploitation).
+> More on how to do this in the [Nodes & Agents section](#nodes-and-agents) and in the [Post Exploitation section](#post-exploitation).
 
 ### Triggers
 

src/pentesting-cloud/aws-security/README.md

@@ -43,7 +43,7 @@ From a Red Team point of view, the **first step to compromise an AWS environment
     - `C:\Users\USERNAME\.aws\credentials`
 - 3rd parties **breached**
 - **Internal** Employee
-- [**Cognito** ](aws-services/aws-cognito-enum/#cognito)credentials
+- [**Cognito** ](aws-services/aws-cognito-enum/index.html#cognito)credentials
 
 Or by **compromising an unauthenticated service** exposed:
 
@@ -123,7 +123,7 @@ AWS has an astonishing amount of services, in the following page you will find *
 aws-services/
 {{#endref}}
 
-Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](./#automated-tools).
+Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](#automated-tools).
 
 Moreover, in this stage you might discovered **more services exposed to unauthenticated users,** you might be able to exploit them:
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md

@@ -85,7 +85,7 @@ The way to grant **access to over K8s to more AWS IAM users or roles** is using
 > [!WARNING]
 > Therefore, anyone with **write access** over the config map **`aws-auth`** will be able to **compromise the whole cluster**.
 
-For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
+For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
 
 Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
 

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md

@@ -57,7 +57,7 @@ The `cloudformation:SetStackPolicy` permission can be used to **give yourself `U
 
 An attacker with permissions to **pass a role and create & execute a ChangeSet** can **create/update a new cloudformation stack abuse the cloudformation service roles** just like with the CreateStack or UpdateStack.
 
-The following exploit is a **variation of the**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) using the **ChangeSet permissions** to create a stack.
+The following exploit is a **variation of the**[ **CreateStack one**](#iam-passrole-cloudformation-createstack) using the **ChangeSet permissions** to create a stack.
 
 ```bash
 aws cloudformation create-change-set \

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md

@@ -14,7 +14,7 @@ For more info about Cognito check:
 
 As Cognito can grant **IAM role credentials** to both **authenticated** an **unauthenticated** **users**, if you locate the **Identity Pool ID** of an application (should be hardcoded on it) you can obtain new credentials and therefore privesc (inside an AWS account where you probably didn't even have any credential previously).
 
-For more information [**check this page**](../aws-unauthenticated-enum-access/#cognito).
+For more information [**check this page**](../aws-unauthenticated-enum-access/index.html#cognito).
 
 **Potential Impact:** Direct privesc to the services role attached to unauth users (and probably to the one attached to auth users).
 
@@ -269,7 +269,7 @@ aws cognito-idp create-identity-provider \
 This is a very common permission by default in roles of Cognito Identity Pools. Even if a wildcard in a permissions always looks bad (specially coming from AWS), the **given permissions aren't super useful from an attackers perspective**.
 
 This permission allows to read use information of Identity Pools and Identity IDs inside Identity Pools (which isn't sensitive info).\
-Identity IDs might have [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assigned to them, which are information of the sessions (AWS define it like a **saved game**). It might be possible that this contain some kind of sensitive information (but the probability is pretty low). You can find in the [**enumeration page**](../aws-services/aws-cognito-enum/) how to access this information.
+Identity IDs might have [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assigned to them, which are information of the sessions (AWS define it like a **saved game**). It might be possible that this contain some kind of sensitive information (but the probability is pretty low). You can find in the [**enumeration page**](../aws-services/aws-cognito-enum/index.html) how to access this information.
 
 An attacker could also use these permissions to **enroll himself to a Cognito stream that publish changes** on these datases or a **lambda that triggers on cognito events**. I haven't seen this being used, and I wouldn't expect sensitive information here, but it isn't impossible.
 

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md

@@ -13,7 +13,7 @@ For more information check:
 ## From management Account to children accounts
 
 If you compromise the root/management account, chances are you can compromise all the children accounts.\
-To [**learn how check this page**](../#compromising-the-organization).
+To [**learn how check this page**](../index.html#compromising-the-organization).
 
 {{#include ../../../banners/hacktricks-training.md}}
 

src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md

@@ -130,7 +130,7 @@ aws cognito-identity get-credentials-for-identity --identity-id <identity_id> --
 
 ### Enhanced vs Basic Authentication flow
 
-The previous section followed the **default enhanced authentication flow**. This flow sets a **restrictive** [**session policy**](../../aws-basic-information/#session-policies) to the IAM role session generated. This policy will only allow the session to [**use the services from this list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (even if the role had access to other services).
+The previous section followed the **default enhanced authentication flow**. This flow sets a **restrictive** [**session policy**](../../aws-basic-information/index.html#session-policies) to the IAM role session generated. This policy will only allow the session to [**use the services from this list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (even if the role had access to other services).
 
 However, there is a way to bypass this, if the **Identity pool has "Basic (Classic) Flow" enabled**, the user will be able to obtain a session using that flow which **won't have that restrictive session policy**.
 
@@ -151,7 +151,7 @@ aws sts assume-role-with-web-identity --role-arn "arn:aws:iam::<acc_id>:role/<ro
 
 > `An error occurred (InvalidParameterException) when calling the GetOpenIdToken operation: Basic (classic) flow is not enabled, please use enhanced flow.`
 
-Having a set of IAM credentials you should check [which access you have](../../#whoami) and try to [escalate privileges](../../aws-privilege-escalation/).
+Having a set of IAM credentials you should check [which access you have](../../index.html#whoami) and try to [escalate privileges](../../aws-privilege-escalation/index.html).
 
 ### Authenticated
 

src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md

@@ -32,7 +32,7 @@ aws lightsail get-key-pairs
 
 ### Analyse Snapshots
 
-It's possible to generate **instance and relational database snapshots from lightsail**. Therefore you can check those the same way you can check [**EC2 snapshots**](aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/#ebs) and [**RDS snapshots**](aws-relational-database-rds-enum.md#enumeration).
+It's possible to generate **instance and relational database snapshots from lightsail**. Therefore you can check those the same way you can check [**EC2 snapshots**](aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/index.html#ebs) and [**RDS snapshots**](aws-relational-database-rds-enum.md#enumeration).
 
 ### Metadata
 

src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md

@@ -140,7 +140,7 @@ Using this mechanism, you are able to utilize your own provided keys and use an
 
 ### **Enumeration**
 
-One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/#s3-buckets)**.**
+One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
 
 ```bash
 # Get buckets ACLs

src/pentesting-cloud/azure-security/README.md

@@ -132,7 +132,7 @@ Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com # For current user
 
 ### ENtra ID Enumeration
 
-By default, any user should have **enough permissions to enumerate** things such us, users, groups, roles, service principals... (check [default AzureAD permissions](az-basic-information/#default-user-permissions)).\
+By default, any user should have **enough permissions to enumerate** things such us, users, groups, roles, service principals... (check [default AzureAD permissions](az-basic-information/index.html#default-user-permissions)).\
 You can find here a guide:
 
 {{#ref}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md

@@ -51,7 +51,7 @@ From the **compromised machine to the cloud**:
 
 From compromising **AD** to compromising the **Cloud** and from compromising the **Cloud to** compromising **AD**:
 
-- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
+- [**Azure AD Connect**](azure-ad-connect-hybrid-identity/index.html)
 - **Another way to pivot from could to On-Prem is** [**abusing Intune**](../az-services/intune.md)
 
 #### [Roadtx](https://github.com/dirkjanm/ROADtools)

src/pentesting-cloud/azure-security/az-privilege-escalation/az-virtual-machines-and-network-privesc.md

@@ -171,7 +171,7 @@ Set-AzVMDscExtension `
 
 <summary>Hybrid Runbook Worker</summary>
 
-This is a VM extension that would allow to execute runbooks in VMs from an automation account. For more information check the [Automation Accounts service](../az-services/az-automation-account/).
+This is a VM extension that would allow to execute runbooks in VMs from an automation account. For more information check the [Automation Accounts service](../az-services/az-automation-account/index.html).
 
 </details>
 

src/pentesting-cloud/azure-security/az-services/az-azuread.md

@@ -1015,7 +1015,7 @@ It allows the admin to configure it to **block** attempts when the risk is "Low
 
 ### Entra Password Protection
 
-Entra Password Protection ([https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade](https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade)) is a security feature that **helps prevent the abuse of weak passwords in by locking out accounts when several unsuccessful login attempts happen**.\
+Entra Password Protection ([https://portal.azure.com/index.html#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade](https://portal.azure.com/#view/Microsoft_AAD_ConditionalAccess/PasswordProtectionBlade)) is a security feature that **helps prevent the abuse of weak passwords in by locking out accounts when several unsuccessful login attempts happen**.\
 It also allows to **ban a custom password list** that you need to provide.
 
 It can be **applied both** at the cloud level and on-premises Active Directory.

src/pentesting-cloud/azure-security/az-services/az-function-apps.md

@@ -56,12 +56,12 @@ In a **Windows** function using NodeJS the code was located in **`C:\home\site\w
 
 ### **Managed Identities & Metadata**
 
-Just like [**VMs**](vms/), Functions can have **Managed Identities** of 2 types: System assigned and User assigned.
+Just like [**VMs**](vms/index.html), Functions can have **Managed Identities** of 2 types: System assigned and User assigned.
 
 The **system assigned** one will be a managed identity that **only the function** that has it assigned would be able to use, while the **user assigned** managed identities are managed identities that **any other Azure service will be able to use**.
 
 > [!NOTE]
-> Just like in [**VMs**](vms/), Functions can have **1 system assigned** managed identity and **several user assigned** ones, so it's always important to try to find all of them if you compromise the function because you might be able to escalate privileges to several managed identities from just one Function.
+> Just like in [**VMs**](vms/index.html), Functions can have **1 system assigned** managed identity and **several user assigned** ones, so it's always important to try to find all of them if you compromise the function because you might be able to escalate privileges to several managed identities from just one Function.
 >
 > If a no system managed identity is used but one or more user managed identities are attached to a function, by default you won’t be able to get any token.
 

src/pentesting-cloud/azure-security/az-services/vms/README.md

@@ -635,7 +635,7 @@ Set-AzVMDscExtension `
 
 <summary>Hybrid Runbook Worker</summary>
 
-This is a VM extension that would allow to execute runbooks in VMs from an automation account. For more information check the [Automation Accounts service](../az-automation-account/).
+This is a VM extension that would allow to execute runbooks in VMs from an automation account. For more information check the [Automation Accounts service](../az-automation-account/index.html).
 
 </details>
 

src/pentesting-cloud/gcp-security/README.md

@@ -26,7 +26,7 @@ In order to audit a GCP environment it's very important to know: which **service
 From a Red Team point of view, the **first step to compromise a GCP environment** is to manage to obtain some **credentials**. Here you have some ideas on how to do that:
 
 - **Leaks** in github (or similar) - OSINT
-- **Social** Engineering (Check the page [**Workspace Security**](../workspace-security/))
+- **Social** Engineering (Check the page [**Workspace Security**](../workspace-security/index.html))
 - **Password** reuse (password leaks)
 - Vulnerabilities in GCP-Hosted Applications
   - [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) with access to metadata endpoint
@@ -115,7 +115,7 @@ GCP has an astonishing amount of services, in the following page you will find *
 gcp-services/
 {{#endref}}
 
-Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](./#automatic-tools).
+Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](#automatic-tools).
 
 Moreover, in this stage you might discovered **more services exposed to unauthenticated users,** you might be able to exploit them:
 

src/pentesting-cloud/gcp-security/gcp-persistence/gcp-non-svc-persistance.md

@@ -81,7 +81,7 @@ https://www.googleapis.com/auth/userinfo.email
 
 it's interesting to see how this app supports the **`drive`** scope, which could allow a user to escalate from GCP to Workspace if an attacker manages to force the user to generate a token with this scope.
 
-**Check how to** [**abuse this here**](../gcp-to-workspace-pivoting/#abusing-gcloud)**.**
+**Check how to** [**abuse this here**](../gcp-to-workspace-pivoting/index.html#abusing-gcloud)**.**
 
 ### Service Accounts
 

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md

@@ -101,7 +101,7 @@ def injection():
 
         # Get relevant function names
         handler_fname = os.environ.get("FUNCTION_TARGET") # Cloud Function env variable indicating the name of the function to habdle requests
-        source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (./main.py by default)
+        source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (main.py by default)
         realpath = os.path.realpath(source_path) # Get full path
 
         # Get the modules representations

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md

@@ -133,7 +133,7 @@ The tool [patchy](https://github.com/rek7/patchy) could been used in the past fo
 
 ### Bypass Access Scopes
 
-Following this link you find some [**ideas to try to bypass access scopes**](../).
+Following this link you find some [**ideas to try to bypass access scopes**](../index.html).
 
 ### Local Privilege Escalation in GCP Compute instance
 

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-container-privesc.md

@@ -69,7 +69,7 @@ As we are in a GCP environment, you will also be able to **get the nodepool GCP
 
 ### `container.secrets.get` | `container.secrets.list`
 
-As [**explained in this page**, ](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#listing-secrets)with these permissions you can **read** the **tokens** of all the **SAs of kubernetes**, so you can escalate to them.
+As [**explained in this page**, ](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#listing-secrets)with these permissions you can **read** the **tokens** of all the **SAs of kubernetes**, so you can escalate to them.
 
 ### `container.pods.exec`
 
@@ -86,7 +86,7 @@ Because of the **name** of the **permission**, it **looks like that it will allo
 ### `container.mutatingWebhookConfigurations.create` | `container.mutatingWebhookConfigurations.update`
 
 These permissions might allow you to escalate privileges in Kubernetes, but more probably, you could abuse them to **persist in the cluster**.\
-For more information [**follow this link**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#malicious-admission-controller).
+For more information [**follow this link**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#malicious-admission-controller).
 
 {{#include ../../../banners/hacktricks-training.md}}
 

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-local-privilege-escalation-ssh-pivoting.md

@@ -36,11 +36,11 @@ Most of the following proposed permissions are **given to the default Compute SA
 
 Check the following permissions:
 
-- [**compute.instances.osLogin**](gcp-compute-privesc/#compute.instances.oslogin)
-- [**compute.instances.osAdminLogin**](gcp-compute-privesc/#compute.instances.osadminlogin)
-- [**compute.projects.setCommonInstanceMetadata**](gcp-compute-privesc/#compute.projects.setcommoninstancemetadata)
-- [**compute.instances.setMetadata**](gcp-compute-privesc/#compute.instances.setmetadata)
-- [**compute.instances.setIamPolicy**](gcp-compute-privesc/#compute.instances.setiampolicy)
+- [**compute.instances.osLogin**](gcp-compute-privesc/index.html#compute.instances.oslogin)
+- [**compute.instances.osAdminLogin**](gcp-compute-privesc/index.html#compute.instances.osadminlogin)
+- [**compute.projects.setCommonInstanceMetadata**](gcp-compute-privesc/index.html#compute.projects.setcommoninstancemetadata)
+- [**compute.instances.setMetadata**](gcp-compute-privesc/index.html#compute.instances.setmetadata)
+- [**compute.instances.setIamPolicy**](gcp-compute-privesc/index.html#compute.instances.setiampolicy)
 
 ## Search for Keys in the filesystem
 

src/pentesting-cloud/gcp-security/gcp-services/gcp-iam-and-org-policies-enum.md

@@ -70,7 +70,7 @@ Even with the admin service enable, it's possible that you get an error enumerat
 
 ## IAM
 
-Check [**this for basic information about IAM**](../gcp-basic-information/#iam-roles).
+Check [**this for basic information about IAM**](../gcp-basic-information/index.html#iam-roles).
 
 ### Default Permissions
 

src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-understanding-domain-wide-delegation.md

@@ -11,7 +11,7 @@ Google Workspace's Domain-Wide delegation allows an identity object, either an *
 Google Workspace allows the creation of two main types of global delegated object identities:
 
 - **GWS Applications:** Applications from the Workspace Marketplace can be set up as a delegated identity. Before being made available in the marketplace, each Workspace application undergoes a review by Google to minimize potential misuse. While this does not entirely eliminate the risk of abuse, it significantly increases the difficulty for such incidents to occur.
-- **GCP Service Account:** Learn more about [**GCP Service Accounts here**](../gcp-basic-information/#service-accounts).
+- **GCP Service Account:** Learn more about [**GCP Service Accounts here**](../gcp-basic-information/index.html#service-accounts).
 
 ### **Domain-Wide Delegation: Under the Hood**
 

src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -484,11 +484,11 @@ Principals that can **`update`** or **`patch`** **`pods/ephemeralcontainers`** c
 
 Principals with any of the verbs `create`, `update` or `patch` over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` might be able to **create one of such webhookconfigurations** in order to be able to **escalate privileges**.
 
-For a [`mutatingwebhookconfigurations` example check this section of this post](./#malicious-admission-controller).
+For a [`mutatingwebhookconfigurations` example check this section of this post](#malicious-admission-controller).
 
 ### Escalate
 
-As you can read in the next section: [**Built-in Privileged Escalation Prevention**](./#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate`** over **`roles`** or **`clusterroles`.**\
+As you can read in the next section: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate`** over **`roles`** or **`clusterroles`.**\
 Then he can update/create new roles, clusterroles with better permissions than the ones he has.
 
 ### Nodes proxy
@@ -499,7 +499,7 @@ Principals with access to the **`nodes/proxy`** subresource can **execute code o
 ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
 {{#endref}}
 
-You have an example of how to get [**RCE talking authorized to a Kubelet API here**](../pentesting-kubernetes-services/#kubelet-rce).
+You have an example of how to get [**RCE talking authorized to a Kubelet API here**](../pentesting-kubernetes-services/index.html#kubelet-rce).
 
 ### Delete pods + unschedulable nodes
 

src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md

@@ -286,7 +286,7 @@ If you are inside the node host you can make it create a **static pod inside its
 
 In order to create a static pod, the [**docs are a great help**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). You basically need 2 things:
 
-- Configure the param **`--pod-manifest-path=/etc/kubernetes/manifests`** in the **kubelet service**, or in the **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) and restart the service
+- Configure the param **`--pod-manifest-path=/etc/kubernetes/manifests`** in the **kubelet service**, or in the **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) and restart the service
 - Create the definition on the **pod definition** in **`/etc/kubernetes/manifests`**
 
 **Another more stealth way would be to:**
@@ -324,7 +324,7 @@ spec:
 ### Delete pods + unschedulable nodes
 
 If an attacker has **compromised a node** and he can **delete pods** from other nodes and **make other nodes not able to execute pods**, the pods will be rerun in the compromised node and he will be able to **steal the tokens** run in them.\
-For [**more info follow this links**](abusing-roles-clusterroles-in-kubernetes/#delete-pods-+-unschedulable-nodes).
+For [**more info follow this links**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes).
 
 ## Automatic Tools
 

src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md

@@ -36,7 +36,7 @@ In the template of a **Role** or a **ClusterRole** you will need to indicate the
 
 ### Rules Verbs
 
-(_This info was taken from_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb))
+(_This info was taken from_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/index.html#determine-the-request-verb))
 
 | HTTP verb | request verb                                                                                                                                                  |
 | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |

src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md

@@ -6,7 +6,7 @@ This page gives some pointers onto how you can attack a Jenkins instance running
 
 ## Disclaimer
 
-A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../pentesting-ci-cd/jenkins-security/)
+A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../pentesting-ci-cd/jenkins-security/index.html)
 
 ## Prerequisites