Jump to content

Recommended Posts

Posted

I successfully implemented the root payload on Mac and PC
I have a linux box waiting that connected successfully as root on both devices

My question is, how do I handle multiple machines? Give each one a different port? That seems obnoxious to have to port forward each one so I know that isnt right
Is there a "session manager" or a way for a webserver to catch those connection requests?

Posted (edited)

You're going to have to give us a bit more info to understand what your asking. Assuming you got a reverse shell on a machine, or, setting up a machine to be logged into as root from another machine, depending on the service used, it might already handle multiple client connections. The listening port is generally the only part required. The listener and the connecting machine will negotiate the traffic over TCP on ports of their choosing, so that isn't an issue. Only the listening node(port forwarded device that is) has to be accessible by the clients. All the clients should be able to connect short of a limit set by the server limits, if any. Example, an FTP sevice can set max concurrent clients to 1, 10, or 100 or infinite, although you probably wouldn't want that.

 

I should note, a netcat connection, is going to be one connection generally, and close after you disconnect. A real server/service that says up, would be needed for most client connections unless shared on something like a meterpreter session with Armitage clients sharing the victim node.

Edited by digip
Posted

@digip This is the payload I have run https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payload---OSX-Root-Backdoor

It writes a script in a hidden directory that sends out a connection request every so often. In other words reconnecting isn't the problem
I guess the appropriate approach would be set up an SSH server on the machine I am remotely connecting to? Then connect to that from my linux box, rather than continually running the script the payload injected?

Posted

The script is not connecting to SSH. Even if you pointed it at port 22 on your machine, it's sending a reverse shell to a listener at the other end, not initiating an SSH connection. If you wanted to do this, then use SSHpass to script the connection to you and then pass the reverse shell over. 

The daemon part is a service to keep restarting it. So first off, this connects to a single IP, where you would have(obviously) replaced /dev/tcp/mysite.com/1337 with both mysite.com and 1337 with your servers domain/ip and port you are listening on. If on the same network this is great. If behind NAT, then you have to port foward to the inner machine that is listening on port 1337 or whatever you changed it to be.

As for clients, essentially the sender is more or less sending a request to the client, like a salesman knocking on your front door. You on the listener side have to answer on the specific port and IP it's knocking at, and only the recipient set in the initial connect.sh script, can hear the door knock, so this is going to be a one way connection. However, once you are in, you can create a backdoor somewhere/somehow, that would then let you come back from any machine, given the right circumstances, like a PHP shell script on a web server that is not behind NAT and always at the same domain name, that you set up to run system commands, you can then instruct the machine to call any other IP and PORT via this PHP shell script. This is just an example, doesn't have to be a PHP shell script, could be a hidden perl/python script acting as a fake apache server and take commands from anyone/client connecting to it.

In the GIT script, it's going to be a one way conversation though, and until the daemon/service reloads the script, once you disconnect, the connection will be dead until it dials back at you, which you would then have to start another netcat listener, so there won't be multiple clients in this instance. If you want encrypting, use ncat, not nc or netcat, which you can setup to use SSL, but you would need to use ncat on the other end as well, instead of bash in order to use SSL between both systems. Basically start your listener in ncat with ssl switch, and then on victim, use ncat to connect to you with the SSL switch, and then pass /bin/bash over ncat, which will then be encrypted on both ends and much safer since no plain text data going across the wire to be inspected or filtered(does not bypass all firewalls or IDS/IPS systems though but can help).

A reverse shell on the system, seeing as this is probably a ducky script, if it sends a reverse shell as root, then you could then take control of the system to backdoor it and allow logging into remotely, like adding a new user with SSH access to the OSX machine(or whatever it is you were attacking) and then logging in remotely from anywhere. The issue then is, if THEY are behind NAT, you won't be able to reach it, which is why a reverse shell is always desired and more common. Bind shells die if you can't get past NAT or the external gateway and firewalls, so having the victim machine initiate to you, is preferred generally and a repeating service makes that possible, but also more easily detected. Using DynDNS helps alleviate your home IP being an issue if you want to do this on the move, which can then be assigned to any IP you are using or even forward to a jump server as a middle man to forward the traffic back and forth, but a bounce also requires more steps to setup the extra hops and requires another server to be worked out between each of the connections. Darren covered these a while back for IRC bouncers a while back, but same concept.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...