Now we mentioned in the previous section of the skill that one of the things that we want to do is have the ability to have multiple addresses, multiple queries to different portions of that private network inside of our pin testing targets organization and have it come back to our Kali system.
Well, that's a lot of different addresses to come back to one system and a lot of different one for ones to be able to create. But that's why we have dynamic forwarding through SSH.
And it's the exact same method in terms of thinking, but we're just instead of assigning it to an address to come back to, let's say like through our 127.0.0.1 for the web browser, we're just going to assign it a dynamic port and be able to work through that for our different request.
Now I've restarted Wireshark behind the scenes. We'll reference that here momentarily, but I do want to show you here real quick. We've changed up our SSH command here real quick, and we're changing it to dash D, which is dynamic.
And we've also assigned it port 9050 and still pivoting through Lerner at 0.51. So when we crank this up, one thing I want to point out here too after I do this is that now we have two concurrent tunnels going to 0.51. I did not kill the previous one.
And one way for us to be able to see right out the gate to see how many tunneling sessions we have just in case we lost track like me is just simply do a PS ox with a grep SSH.
So now you can see here that I have two tunneling sessions active right now. The first line being SSH going to 8080 locally for me under PID of 143812. Now if I wanted to get rid of that and reset 8080, I would just simply do a pseudo kill that PID number.
And you can see the next PID 145682 is where I have our dynamic SSH tunneling going through right now. And as soon as I started that, you saw the Ubuntu, the one right above me, start going nuts as far as the SSH or Wireshark was concerned.
We have a lot of traffic going back and forth. And if you decide to run Wireshark while you're doing these labs, you will see the connection to and from. And it is over TCP, so that also helps us ensure that the traffic we request is going to be able to come back through the three-way handshake instead of UDP and hoping for the best.
Now inside of our Kali terminal over here, we're going to try to do a curl real quick just to see if we can get an address to come back to us. We're still using 127.0.0.1 and our local port, this time 9050, but now we can start applying different things to this. And I'm using curl, for example, because I'm going to show you why here in just a second, but it does cause a problem when you're going to SSL sites.
So curl real quick. I want to use SOCKS5 and go to 127.0.0.1 9050, which is us, right? And I want to go and retrieve the google.com site HTTPS.
Now when I hit enter on this, I get the actual request of the site in text form in terminal. And over here, I can actually see my request actually go out to different Google sites for the 443 here.
And I can also see that it went over here as well. 142.251.163.106. And I'm going to zoom in so you can see this a little bit more clearly right there. It went from Kali.
Then it went to the Ubuntu, and then it went to the Google, and then back to me. And you can see here again, it's showing that the IP address is coming from 51 and not 53. 53 being our Kali box. Same thing inside of Wireshark on the Kali system.
It's showing that all web requests are being forced through 51. So if this were to be looked at by Google or let's say an IDS or IPS, the IP address that's going to be coming up under their alert system is the IP address of the system that we're pivoting through.
If this sounds familiar, it should. Because I want to take a side here for a second and explain this is essentially what commercial VPNs do out there on the interwebs. So it's not that they're protecting traffic or anything like that.
It's basically you're taking a point somewhere else in the world in a different geolocation and IP range that is registered through ICANN, through let's say Antarctica, and using them as a pivot. So this is something that we normally do when we're browsing the web and using VPNs to get into those sites that normally wouldn't be allowed in your region for whatever reason.
Not judging. I'm just saying. So this is already a practice of pivoting that we've been doing, and we may not have never known it. It's just there's a reason for it now. This is also why you hear of hackers out there in the commercial world using VPNs and tunneling methods to be able to attack those different systems.
Well, pause. You think I'm on a side here for a second. I'm actually explaining some theory for you. And that theory comes down to the fact that as we start doing this as pen testers, we're doing this from an approved IP address or IP range.
Hackers out there in the rest of the world are not doing so. And they're going to try to find systems to be able to tunnel through or VPN through to mask where they're actually coming from. And if you've been taking notes and keep paying close attention, you're starting to see that I'm also laying the notes down to where you can kind of reverse engineer this and know what to look for in terms of walking backwards from the attack.
Because we should be able to go to the BWAP system in this particular case and start tracing packets all the way back to the Ubuntu box from the Ubuntu box go back to us on the Kali system. And this is how we backwards figure out who attacked what over the Internet. Now, over the Internet in different regions based on jurisdictions, this is usually done through the legal purview of things and done through ISPs.
Now, even without the ISPs help, this information can still be obtained using records on the actual system or target system. And also through different arc tables for you know, because there's a whole seven different layers to the OSI model. We're going to use all seven to try to figure everything out.
But I did want to take an aside and explain all that to you because this set of the VPN mentality is exactly what we're using here to be able to do proper attacks and pivoting through the actual network itself. And as we go back over to our lab here, one of the things that I want to show here real quick is that whenever we do another curl, we can use not just one site, but we can also do another one.
Now, it may take a second to come back and retrieve the data. Too many requests. So this was an error on our protection method on somebody else's part. But let's say we want to go to HTTP.
And we can see there that the document has been moved. But guess what? We did get the BWAP site, which is on 0.13 internal to our network. So we're able to go through and check different things and different sites and get different pieces of information back.
Now, how do we know if we made it there or not? Well, at that point, we can just do another filter for IP dot destination equals equals 0.13. And you can see here that that's exactly what we did. And that's the connection that we just made. Remember, I restarted this Wireshark filter when we started this portion of this capture.
So you can go through and do multiple sites to that 9050 and have 9050 be your dynamic connection. Now, one thing to also keep in mind when this is going on is that it's not a static one to one assignment like our previous one was where it was 8080 to 80.
This is 9050 to whatever. So in our previous request for Google and Yahoo, it was 443 because it was an SSL request. Now here it's going to port 80 because it's HTTP. I wonder what else you could do.
You could pretty much do any request after that, like FTP, SFTP, sorry, I'm drawing blanks there for a second. But any other protocol that you could think of or any other ports that you want to address, you could use this way as well.
Because this is like dynamic one and it's not necessarily mapping one back and forth to the other. So keep this in mind as you're going through and doing your assignments for ports in your tunneling methods.