diff --git a/.gitbook/assets/image (628) (1) (1) (1).png b/.gitbook/assets/image (628) (1) (1) (1).png
new file mode 100644
index 000000000..e146bcdd2
Binary files /dev/null and b/.gitbook/assets/image (628) (1) (1) (1).png differ
diff --git a/.gitbook/assets/image (628) (1) (1).png b/.gitbook/assets/image (628) (1) (1).png
index e146bcdd2..cfef5b39f 100644
Binary files a/.gitbook/assets/image (628) (1) (1).png and b/.gitbook/assets/image (628) (1) (1).png differ
diff --git a/.gitbook/assets/image (628) (1).png b/.gitbook/assets/image (628) (1).png
index cfef5b39f..409779817 100644
Binary files a/.gitbook/assets/image (628) (1).png and b/.gitbook/assets/image (628) (1).png differ
diff --git a/.gitbook/assets/image (628).png b/.gitbook/assets/image (628).png
index 409779817..811b2066d 100644
Binary files a/.gitbook/assets/image (628).png and b/.gitbook/assets/image (628).png differ
diff --git a/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png
new file mode 100644
index 000000000..47a9e657a
Binary files /dev/null and b/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png differ
diff --git a/.gitbook/assets/image (651) (1) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1) (1).png
index 47a9e657a..4d79f5764 100644
Binary files a/.gitbook/assets/image (651) (1) (1) (1) (1).png and b/.gitbook/assets/image (651) (1) (1) (1) (1).png differ
diff --git a/.gitbook/assets/image (651) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1).png
index 4d79f5764..fcb7c18a6 100644
Binary files a/.gitbook/assets/image (651) (1) (1) (1).png and b/.gitbook/assets/image (651) (1) (1) (1).png differ
diff --git a/.gitbook/assets/image (651) (1) (1).png b/.gitbook/assets/image (651) (1) (1).png
index fcb7c18a6..5c11c2d01 100644
Binary files a/.gitbook/assets/image (651) (1) (1).png and b/.gitbook/assets/image (651) (1) (1).png differ
diff --git a/.gitbook/assets/image (651) (1).png b/.gitbook/assets/image (651) (1).png
index 5c11c2d01..3f14c6127 100644
Binary files a/.gitbook/assets/image (651) (1).png and b/.gitbook/assets/image (651) (1).png differ
diff --git a/.gitbook/assets/image (651).png b/.gitbook/assets/image (651).png
index 3f14c6127..20c8def05 100644
Binary files a/.gitbook/assets/image (651).png and b/.gitbook/assets/image (651).png differ
diff --git a/.gitbook/assets/image (654) (1) (1) (1) (1).png b/.gitbook/assets/image (654) (1) (1) (1) (1).png
new file mode 100644
index 000000000..c6f279eca
Binary files /dev/null and b/.gitbook/assets/image (654) (1) (1) (1) (1).png differ
diff --git a/.gitbook/assets/image (654) (1) (1) (1).png b/.gitbook/assets/image (654) (1) (1) (1).png
index c6f279eca..ed00c78eb 100644
Binary files a/.gitbook/assets/image (654) (1) (1) (1).png and b/.gitbook/assets/image (654) (1) (1) (1).png differ
diff --git a/.gitbook/assets/image (654) (1) (1).png b/.gitbook/assets/image (654) (1) (1).png
index ed00c78eb..bf9170aac 100644
Binary files a/.gitbook/assets/image (654) (1) (1).png and b/.gitbook/assets/image (654) (1) (1).png differ
diff --git a/.gitbook/assets/image (654) (1).png b/.gitbook/assets/image (654) (1).png
index bf9170aac..a194b1613 100644
Binary files a/.gitbook/assets/image (654) (1).png and b/.gitbook/assets/image (654) (1).png differ
diff --git a/.gitbook/assets/image (654).png b/.gitbook/assets/image (654).png
index a194b1613..adc81a7a7 100644
Binary files a/.gitbook/assets/image (654).png and b/.gitbook/assets/image (654).png differ
diff --git a/cloud-security/concourse/concourse-architecture.md b/cloud-security/concourse/concourse-architecture.md
index 4ebf2cbb4..9ca2cb87a 100644
--- a/cloud-security/concourse/concourse-architecture.md
+++ b/cloud-security/concourse/concourse-architecture.md
@@ -2,7 +2,7 @@
 
 ## Architecture
 
-![](<../../.gitbook/assets/image (651).png>)
+![](<../../.gitbook/assets/image (651) (1).png>)
 
 ### ATC: web UI & build scheduler
 
diff --git a/cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation.md b/cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation.md
index 37b916134..a0e143ff2 100644
--- a/cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation.md
+++ b/cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation.md
@@ -17,7 +17,7 @@ Note that other cloud resources could be searched for and that some times these
 
 As other clouds, GCP also offers Buckets to its users. These buckets might be  (to list the content, read, write...).
 
-![](<../../.gitbook/assets/image (628) (1) (1).png>)
+![](<../../.gitbook/assets/image (628) (1) (1) (1).png>)
 
 The following tools can be used to generate variations of the name given and search for miss-configured buckets with that names:
 
diff --git a/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md b/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md
index 4d2091991..4e7ed9d7e 100644
--- a/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md
+++ b/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md
@@ -537,7 +537,7 @@ More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security
 
 An admission controller is a piece of code that **intercepts requests to the Kubernetes API server** before the persistence of the object, but **after the request is authenticated** **and authorized**.
 
-![](<../../../.gitbook/assets/image (651) (1) (1) (1).png>)
+![](<../../../.gitbook/assets/image (651) (1) (1) (1) (1).png>)
 
 If an attacker somehow manages to **inject a Mutationg Adminssion Controller**, he will be able to **modify already authenticated requests**. Being able to potentially privesc, and more usually persist in the cluster.
 
diff --git a/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md b/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md
index bd613bb23..c53b16f40 100644
--- a/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md
+++ b/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md
@@ -75,7 +75,7 @@ In case you can **make an app resolve a JNDI LDAP UR**L, you can control the LDA
 
 #### Deserialization exploit
 
-![](<../../.gitbook/assets/image (654) (1) (1).png>)
+![](<../../.gitbook/assets/image (654) (1) (1) (1).png>)
 
 The **exploit is serialized** and will be deserialized.\
 In case `trustURLCodebase` is `true`, an attacker can provide his own classes in the codebase if not, he will need to abuse gadgets in the classpath.
diff --git a/pentesting-web/deserialization/python-yaml-deserialization.md b/pentesting-web/deserialization/python-yaml-deserialization.md
index 716a67d37..9c70c6ff5 100644
--- a/pentesting-web/deserialization/python-yaml-deserialization.md
+++ b/pentesting-web/deserialization/python-yaml-deserialization.md
@@ -24,7 +24,7 @@ print(yaml.dump(range(1,10)))
 
 Check how the **tuple** isn’t a raw type of data and therefore it was **serialized**. And the same happened with the **range** (taken from the builtins).
 
-![](<../../.gitbook/assets/image (628).png>)
+![](<../../.gitbook/assets/image (628) (1).png>)
 
 **safe\_load()** or **safe\_load\_all()** uses SafeLoader and **don’t support class object deserialization**. Class object deserialization example:
 
diff --git a/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md b/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md
index 7038b0ff7..d6aa4d70b 100644
--- a/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md
+++ b/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md
@@ -92,7 +92,7 @@ There could be another problem, if the **response** to the legit request **conta
 
 However, the **HEAD** request **doesn't contain a body** but it usually **contains** the **Content-Length** as if the request was a GET request. Therefore, sending a **HEAD** request **instead of a POST** request you can **read the HEAD Content-Length** bytes of the smuggled request response.
 
-![](<../../.gitbook/assets/image (628) (1).png>)
+![](<../../.gitbook/assets/image (628) (1) (1).png>)
 
 ### Leaking Internal Headers via Tunneling
 
diff --git a/pentesting-web/http-response-smuggling-desync.md b/pentesting-web/http-response-smuggling-desync.md
index 64866ae15..181f883f3 100644
--- a/pentesting-web/http-response-smuggling-desync.md
+++ b/pentesting-web/http-response-smuggling-desync.md
@@ -70,7 +70,7 @@ Therefore, if an attacker **injects** a **HEAD** request, like in this images:
 
 Then, **once the blue one is responded to the attacker**, the next victims request is going to be introduced in the queue:
 
-![](<../.gitbook/assets/image (651) (1) (1) (1) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (1) (1) (1) (1).png>)
 
 Then, the **victim** will **receive** the **response** from the **HEAD** request, which is **going to contain a Content-Length but no content at all**. Therefore, the proxy **won't send this response** to the victim, but will **wait** for some **content**, which actually is going to be **response to the yellow request** (also injected by the attacker):
 
@@ -80,7 +80,7 @@ Then, the **victim** will **receive** the **response** from the **HEAD** request
 
 Following the previous example, knowing that you can **control the body** of the request whose response is going to receive the victim and that a **HEAD** **response** usually contains in its headers the **Content-Type and the Content-Length**, you can **send a request like the following** one to **cause XSS** in the victim without the page being vulnerable to XSS:
 
-![](<../.gitbook/assets/image (654) (1) (1) (1).png>)
+![](<../.gitbook/assets/image (654) (1) (1) (1) (1).png>)
 
 ### Cache Poisoning
 
diff --git a/pentesting/5353-udp-multicast-dns-mdns.md b/pentesting/5353-udp-multicast-dns-mdns.md
index 7b32b3274..7838779bd 100644
--- a/pentesting/5353-udp-multicast-dns-mdns.md
+++ b/pentesting/5353-udp-multicast-dns-mdns.md
@@ -29,7 +29,7 @@ To request a PTR record, clients use the name form "\<Service>.\<Domain>". The *
 
 The part of the PTR record to the **left** of the colon is its **name**, and the part on the **right** is the **SRV** **record** to which the PTR record points. The **SRV** record lists the target **host** and **port** where the **service** instance can be reached. For example, the next image shows a "test.\_ipps.\_tcp.local" SRV record in Wireshark in host ubuntu.local and port 8000:
 
-![](<../.gitbook/assets/image (651) (1) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (1) (1).png>)
 
 Therefore, the **name of the SRV** record is **like** the **PTR** record **preceded** by the **\<Instance>** name (test in this case). The **TXT** has the **same** **name** as the **SRV** record and contains the information needed when the IP address and port number (contained in the SRV record) for a service aren’t sufficient to identify it.
 
diff --git a/pentesting/pentesting-kubernetes/exposing-services-in-kubernetes.md b/pentesting/pentesting-kubernetes/exposing-services-in-kubernetes.md
index e11c7668e..1104ef07f 100644
--- a/pentesting/pentesting-kubernetes/exposing-services-in-kubernetes.md
+++ b/pentesting/pentesting-kubernetes/exposing-services-in-kubernetes.md
@@ -87,7 +87,7 @@ If you **don't specify** the **nodePort** in the yaml (it's the port that will b
 
 Exposes the Service externally **using a cloud provider's load balancer**. On GKE, this will spin up a [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) that will give you a single IP address that will forward all traffic to your service.
 
-![](<../../.gitbook/assets/image (654) (1).png>)
+![](<../../.gitbook/assets/image (654) (1) (1).png>)
 
 You have to pay for a LoadBalancer per exposed service, which can get expensive.
 
diff --git a/todo/hardware-hacking/jtag.md b/todo/hardware-hacking/jtag.md
index 6c898af42..37e89d652 100644
--- a/todo/hardware-hacking/jtag.md
+++ b/todo/hardware-hacking/jtag.md
@@ -17,6 +17,6 @@ In Arduino, after connecting the cables (pin 2 to 11 to JTAG pins and Arduino GN
 Configure **"No line ending" and 115200baud**.\
 Send the command s to start scanning:
 
-![](<../../.gitbook/assets/image (651) (1).png>)
+![](<../../.gitbook/assets/image (651) (1) (1).png>)
 
 If you are contacting a JTAG, you will find one or several **lines starting by FOUND!** indicating the pins of JTAG.
diff --git a/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md b/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md
index cd9680f0b..ab0a0d7b4 100644
--- a/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md
+++ b/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md
@@ -35,10 +35,46 @@ In [**this excellent article**](http://dronesec.pw/blog/2019/08/22/exploiting-le
 * THREAD\_DIRECT\_IMPERSONATION
 * THREAD\_SET\_CONTEXT
 
-### File & Key
+### File, Key & Section Handles
 
 If an **unprivileged process inherits** a **handle** with **write** equivalent **permissions** over a **privileged file or registry**, it will be able to **overwrite** the file/registry (and with a lot of **luck**, **escalate privileged**).
 
+**Section Handles** are similar to file handles, the common name of this kinds of [objects is **"File Mapping"**](https://docs.microsoft.com/en-us/windows/win32/memory/file-mapping). They are used to work with **big files without keeping the entire** file in memory. That makes the exploitation kind of "similar" to the exploitation of a File Handle.
+
+## How to see handles of processes
+
+### Process Hacker
+
+****[**Process Hacker**](https://github.com/processhacker/processhacker) is a tool you can download for free. It has several amazing options to inspect processes and one of them is the **capability to see the handles of each process**.
+
+Note that in order to **see all the handles of all the processes, the SeDebugPrivilege is needed** (so you need to run Process Hacker as administrator).
+
+To see the handles of a process, right click in the process and select Handles:
+
+![](<../../.gitbook/assets/image (651).png>)
+
+You can then right click on the handle and **check the permissions**:
+
+![](<../../.gitbook/assets/image (628).png>)
+
+### Sysinternals Handles
+
+The [**Handles** ](https://docs.microsoft.com/en-us/sysinternals/downloads/handle)binary from Sysinternals will also list the handles per process in the console:
+
+![](<../../.gitbook/assets/image (654).png>)
+
+### Methodology
+
+Now that you know how to find handles of processes what you need to check is if any **unprivileged process is having access to privileged handles**. In that case, the user of the process could be able to obtain the handle and abuse it to escalate privileges.
+
+{% hint style="warning" %}
+It was mentioned before that you need the SeDebugPrivilege to access all the handles. But a **user can still access the handles of his processes**, so it might be useful if you want to privesc just from that user to **execute the tools with the user regular permissions**.
+
+```bash
+handle64.exe /a | findstr /r /i "process thread file key pid:"
+```
+{% endhint %}
+
 ## Vulnerable Example
 
 For example, the following code belongs to a **Windows service** that would be vulnerable. The vulnerable code of this service binary is located inside the **`Exploit`** function. This function is starts **creating a new handle process with full access**. Then, it's **creating a low privileged process** (by copying the low privileged token of _explorer.exe_) executing _C:\users\username\desktop\client.exe_. The **vulnerability resides in the fact it's creating the low privileged process with `bInheritHandles` as `TRUE`**.