SECFORCE/Tunna

Reverse TCP Socket

Opened this issue · 6 comments

benpturner commented

Hi,

Could this be changed to support sending a local port using the proxy client to the webserver rather that the other way around. e.g. send my rdp 3389 to the webserver on 4444?

I presume the code is there just would need reversing slighly, it would still need to communicate over HTTP.

nvssks commented

Interesting idea,

I think there are two ways to approach this:

  1. Reverse http tunnel (ie. rdp->TunnaClient)
  2. Reverse http tunnel to the webserver, webserver holds the connection
    alive and then you connect to the webserver with a TunnaClient (essentially
    2 http tunnels - rdp->webserver<-TunnaClient)

Which one are you thinking of?

On 12 Oct 2016 9:24 p.m., "Ben Turner" notifications@github.com wrote:

Hi,

Could this be changed to support sending a local port using the proxy
client to the webserver rather that the other way around. e.g. send my rdp
3389 to the webserver on 4444?

I presume the code is there just would need reversing slighly, it would
still need to communicate over HTTP.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5, or mute the thread
https://github.com/notifications/unsubscribe-auth/AJZ6bSIEkMPB5wc6_0cbSH8xza8LeeSTks5qzUHmgaJpZM4KVLkI
.

benpturner commented

Yeah this would be a really good addition. 
Would this take alot of time to implement?

  From: nvssks <notifications@github.com>

To: SECFORCE/Tunna Tunna@noreply.github.com
Cc: Ben Turner benpturner@yahoo.com; Author author@noreply.github.com
Sent: Wednesday, 12 October 2016, 23:49
Subject: Re: [SECFORCE/Tunna] Reverse TCP Socket (#5)

Interesting idea,

I think there are two ways to approach this:

  1. Reverse http tunnel (ie. rdp->TunnaClient)
  2. Reverse http tunnel to the webserver, webserver holds the connection
    alive and then you connect to the webserver with a TunnaClient (essentially
    2 http tunnels - rdp->webserver<-TunnaClient)

Which one are you thinking of?

On 12 Oct 2016 9:24 p.m., "Ben Turner" notifications@github.com wrote:

Hi,

Could this be changed to support sending a local port using the proxy
client to the webserver rather that the other way around. e.g. send my rdp
3389 to the webserver on 4444?

I presume the code is there just would need reversing slighly, it would
still need to communicate over HTTP.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5, or mute the thread
https://github.com/notifications/unsubscribe-auth/AJZ6bSIEkMPB5wc6_0cbSH8xza8LeeSTks5qzUHmgaJpZM4KVLkI
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

nvssks commented

It's not as easy as it seems, it will need some refactoring of the code
base :/

On 14 Oct 2016 17:31, "Ben Turner" notifications@github.com wrote:

Yeah this would be a really good addition.
Would this take alot of time to implement?

From: nvssks notifications@github.com
To: SECFORCE/Tunna Tunna@noreply.github.com
Cc: Ben Turner benpturner@yahoo.com; Author author@noreply.github.com
Sent: Wednesday, 12 October 2016, 23:49
Subject: Re: [SECFORCE/Tunna] Reverse TCP Socket (#5)

Interesting idea,

I think there are two ways to approach this:

  1. Reverse http tunnel (ie. rdp->TunnaClient)
  2. Reverse http tunnel to the webserver, webserver holds the connection
    alive and then you connect to the webserver with a TunnaClient (essentially
    2 http tunnels - rdp->webserver<-TunnaClient)

Which one are you thinking of?

On 12 Oct 2016 9:24 p.m., "Ben Turner" notifications@github.com wrote:

Hi,

Could this be changed to support sending a local port using the proxy
client to the webserver rather that the other way around. e.g. send my rdp
3389 to the webserver on 4444?

I presume the code is there just would need reversing slighly, it would
still need to communicate over HTTP.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJZ6bSIEkMPB5wc6_
0cbSH8xza8LeeSTks5qzUHmgaJpZM4KVLkI>
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJZ6bWiUqFa93x1wyo1-bnDQxQgmREvoks5qz65XgaJpZM4KVLkI
.

s0rtega commented

Hi there,

Any improvements in this way? I'm trying to connect to an internal system trought a proxy and I'm thinking that this would be the best approach but I can't find any implemented tool with a reverse http-rdp connection. Maybe I could give you some help at this point...

nvssks commented

Only minimum progress so far but I'm still working on it :)

On 15 Nov 2016 6:36 p.m., "Sergio Ortega" notifications@github.com wrote:

Hi there,

Any improvements in this way? I'm trying to connect to an internal system
trought a proxy and I'm thinking that this would be the best approach but I
can't find any implemented tool with a reverse http-rdp connection. Maybe I
could give you some help at this point...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJZ6bUUjFLgv6nakamSWv_3Ie6Nf700kks5q-fusgaJpZM4KVLkI
.

nvssks commented

Hi there,

Although I'm close into releasing the code for this (still needs some serious night owling to be complete). I was pointed to a tool that might be good for your scenario.
Have a look at: https://github.com/khuevu/http-tunnel