# Realizando Pivoting sobre un EC2
{% hint style="danger" %}
¿Crees tener lo que se necesita para ser un experto en Pentesting contra AWS? Si nuestro libro te abrió los ojos a las posibilidades de la ciberseguridad ofensiva o si ya cuentas con habilidades en este campo, es momento de subir de nivel. Te retamos a certificarte en el [CPNA - Curso Profesional de Pentesting Contra AWS](https://spartan-cybersec.com/cursos/pentesting-contra-la-nube-de-aws/). No será fácil: te enfrentarás a un examen riguroso de 12 horas donde deberás hackear una infraestructura completa alojada en AWS. ¿Listo para el desafío? Acepta el reto y demuestra tu verdadero potencial.
{% endhint %}
Después de desplegar el laboratorio, ejecutamos el siguiente comando:
Como podemos apreciar hemos encontrado dos conexiones de VPC y son:
* 10.1.0.0/16 – (vpc-0788a2b695ffbf6ae)
* 10.2.0.0/16 – (vpc-075cb81f5ac4a4d20)
A continuación, se enumeran las subredes de dichos VPC que hemos encontrado previamente:
```
aws ec2 describe-subnets --filters "Name=vpc-id, Values=vpc-075cb81f5ac4a4d20"
```
Ahora que hemos identificado las subredes para cada VPC, vamos a identificar las tablas de enrutamiento de networking configuradas para cada VPC:
```
aws ec2 describe-route-tables --filters "Name=vpc-id, Values=vpc-075cb81f5ac4a4d20"
```
En la evidencia previa, podemos identificar que la subred 10.1.0.0/16 tiene acceso a la otra subred 10.2.0.0/16
Algo que también puede ser importante, es revisar los ACL para el VPC:
Algo que hemos conseguido información relacionada a los VPC, vamos a identificar que EC2 hace parte de dichos VPC:
```
aws ec2 describe-instances --filters "Name=vpc-id, Values=vpc-075cb81f5ac4a4d20"
```
En el VPC **vpc-075cb81f5ac4a4d20**, Vemos que la instancia NO tiene una IP publica y por lo tanto no tenemos acceso directo a esta desde internet.
```
aws ec2 describe-instances --filters "Name=vpc-id, Values= vpc-0788a2b695ffbf6ae"
```
En el VPC **vpc-0788a2b695ffbf6ae**, Vemos que la instancia tiene una IP publica y por lo tanto SI tenemos acceso directo a esta desde internet.
Si durante un pentesting se logra comprometer una EC2, es recomendable revisar si existen otros servidores a los que se tenga alcance con el objetivo de intentar movernos lateralmente contra el servidor identificado.
En los pasos previos, hemos enumerado los diferentes VPC y sus subredes e incluyendo las tablas de enrutamiento para cada una.
Ahora sabiendo que tenemos acceso a una instancia (i-0f96192e594ab7200); y hemos identificado la existencia de otra instancia (i-07076437e17354e9f) en otra VPC a la que tenemos alcance desde nuestra EC2 comprometida; vamos a validar si podemos realizar una conexión SSH.
Primero nos conectamos a la primera instancia utilizando su dirección IP Publica:
```
ssh -i id_rsa ec2-user@52.91.127.106
```
En ciertas ocasiones, los arquitectos de AWS o los desarrolladores otorgan acceso internamente a sus instancias por medio de la misma llave SSH y como pudimos apreciar en el retorno de los comandos previos ambas instancias pueden ser accedidas por medio de la llave privada llamada id\_rsa.
Desde nuestra Shell inicial, vamos a ingresar el siguiente comando para conectarnos a la otra instancia por medio de SSH:
```
ssh -i id_rsa 10.2.1.83
```
En la evidencia previa, se puede apreciar la conexión por SSH contra el otro equipo desde nuestra primera instancia.
Ahora suponiendo que identificamos el puerto 80 corriendo el servicio HTTP en la instancia inaccesible con IP 10.2.1.83 y queremos acceder desde nuestro navegador obtendremos un error debido a que no tenemos alcance.
Para este ejercicio, vamos a iniciar el servicio de HTTP por medio de Python:
```
python3 -m http.server 80
```
Es importante tener en nuestro grupo de seguridad para la instancia inalcanzable la siguiente configuración:
Luego de la configuración previa, podríamos hacer una petición GET solo desde la instancia inicial.
Vamos a realizar un Port Forwading con SSH dinámico utilizando proxychains.
Primero ejecutamos el siguiente comando para que nuestro tráfico utilice el puerto por defecto de proxychains:
```
ssh -D 127.0.0.1:9050 ec2-user@52.91.127.106 -i id_rsa
```
Luego de lo anterior, ya tenemos alcance contra el servidor de una manera directa desde nuestra maquina atacante por medio de proxychains:
```
proxychains nmap -sT -sV 10.2.1.83 -p 80
```
En la evidencia previa, podemos apreciar que Nmap tiene alcance y detecto el puerto 80 que está corriendo en la instancia 10.2.1.83.
Cabe resaltar, que este análisis de puertos fue realizado desde nuestra maquina atacante.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://books.spartan-cybersec.com/cpna/introduccion-a-vpc/realizando-pivoting-sobre-un-ec2.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.