diff --git a/src/pentesting-ci-cd/apache-airflow-security/README.md b/src/pentesting-ci-cd/apache-airflow-security/README.md
index 7d9e7b0a6..4835dcebc 100644
--- a/src/pentesting-ci-cd/apache-airflow-security/README.md
+++ b/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)
 
diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md
index f8205f9e0..97b6028a7 100644
--- a/src/pentesting-ci-cd/cloudflare-security/README.md
+++ b/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`**.
diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md
index bd4456e1f..d11fb1b19 100644
--- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md
+++ b/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
 
diff --git a/src/pentesting-ci-cd/gitea-security/README.md b/src/pentesting-ci-cd/gitea-security/README.md
index 5e60fb841..53a2fde55 100644
--- a/src/pentesting-ci-cd/gitea-security/README.md
+++ b/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.
 
diff --git a/src/pentesting-ci-cd/github-security/README.md b/src/pentesting-ci-cd/github-security/README.md
index 3000b5763..0d8d7580f 100644
--- a/src/pentesting-ci-cd/github-security/README.md
+++ b/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
 
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
index 9c72f93db..83fa1f7e1 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
+++ b/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**.
 
diff --git a/src/pentesting-ci-cd/jenkins-security/README.md b/src/pentesting-ci-cd/jenkins-security/README.md
index a9e7ff1e0..5a939499c 100644
--- a/src/pentesting-ci-cd/jenkins-security/README.md
+++ b/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
 
diff --git a/src/pentesting-cloud/aws-security/README.md b/src/pentesting-cloud/aws-security/README.md
index ad71de826..2b5321f9f 100644
--- a/src/pentesting-cloud/aws-security/README.md
+++ b/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:
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
index eb1f77f46..a638141e5 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
+++ b/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**.
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md
index be8cbbe77..da846a7c3 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md
+++ b/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 \
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
index 33010b881..6dfc671e2 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
+++ b/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.
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
index 7d43bbd3b..9919baa36 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
+++ b/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}}
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md
index 024c7ea91..927d026f0 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md
+++ b/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
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md
index 9f5ccb1ab..b74ed8845 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md
+++ b/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
 
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md
index 3133c0eac..f3a03a803 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md
+++ b/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
diff --git a/src/pentesting-cloud/azure-security/README.md b/src/pentesting-cloud/azure-security/README.md
index e7f9de3fd..fc7b3fd91 100644
--- a/src/pentesting-cloud/azure-security/README.md
+++ b/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}}
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md
index 93d7d49b3..fe236af29 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md
+++ b/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)
diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-virtual-machines-and-network-privesc.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-virtual-machines-and-network-privesc.md
index 3fe5cff1b..82263d1c0 100644
--- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-virtual-machines-and-network-privesc.md
+++ b/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>
 
diff --git a/src/pentesting-cloud/azure-security/az-services/az-azuread.md b/src/pentesting-cloud/azure-security/az-services/az-azuread.md
index 6aa2bb2b0..a8d1304d7 100644
--- a/src/pentesting-cloud/azure-security/az-services/az-azuread.md
+++ b/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.
diff --git a/src/pentesting-cloud/azure-security/az-services/az-function-apps.md b/src/pentesting-cloud/azure-security/az-services/az-function-apps.md
index fb15d42de..a7c040fff 100644
--- a/src/pentesting-cloud/azure-security/az-services/az-function-apps.md
+++ b/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.
 
diff --git a/src/pentesting-cloud/azure-security/az-services/vms/README.md b/src/pentesting-cloud/azure-security/az-services/vms/README.md
index 9e42f13ea..283d8bc13 100644
--- a/src/pentesting-cloud/azure-security/az-services/vms/README.md
+++ b/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>
 
diff --git a/src/pentesting-cloud/gcp-security/README.md b/src/pentesting-cloud/gcp-security/README.md
index 35d266403..e242a8d4b 100644
--- a/src/pentesting-cloud/gcp-security/README.md
+++ b/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:
 
diff --git a/src/pentesting-cloud/gcp-security/gcp-persistence/gcp-non-svc-persistance.md b/src/pentesting-cloud/gcp-security/gcp-persistence/gcp-non-svc-persistance.md
index c8e5c3e37..11141d543 100644
--- a/src/pentesting-cloud/gcp-security/gcp-persistence/gcp-non-svc-persistance.md
+++ b/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
 
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md
index 22e807679..ce93c049c 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md
+++ b/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
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md
index dc2155442..104bae5a6 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/README.md
+++ b/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
 
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-container-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
index 0c9542a41..18d1f2be8 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
+++ b/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}}
 
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-local-privilege-escalation-ssh-pivoting.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-local-privilege-escalation-ssh-pivoting.md
index baefccbf4..5583b3f9e 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-local-privilege-escalation-ssh-pivoting.md
+++ b/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
 
diff --git a/src/pentesting-cloud/gcp-security/gcp-services/gcp-iam-and-org-policies-enum.md b/src/pentesting-cloud/gcp-security/gcp-services/gcp-iam-and-org-policies-enum.md
index 847953cb8..f328395f8 100644
--- a/src/pentesting-cloud/gcp-security/gcp-services/gcp-iam-and-org-policies-enum.md
+++ b/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
 
diff --git a/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-understanding-domain-wide-delegation.md b/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-understanding-domain-wide-delegation.md
index 328d6b2df..a9fd27f97 100644
--- a/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-understanding-domain-wide-delegation.md
+++ b/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**
 
diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md
index 8b56153c6..ca277d590 100644
--- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md
+++ b/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
 
diff --git a/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md b/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
index 8f7a8c6c5..77848086d 100644
--- a/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
+++ b/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
 
diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md b/src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md
index 98c129ab8..8ab146a22 100644
--- a/src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md
+++ b/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                                                                                                                                                  |
 | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md b/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
index 32b2c5e19..306d8660a 100644
--- a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
+++ b/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