socat is a general-purpose networking tool that allows the creation of two bidirectional streams. It has a large amount of support for different protocols and data sources, including OPENSSL, SOCKS4, TCP, UDP, TAP, SCTP and more. When performing a penetration test this tool can be leveraged to bypass basic firewall restrictions and transfer files across the network. Statically compiled socatThere is a cool project called static-toolbox which provides statically compiled networking and debugging tools. This project includes a statically compiled versions of socat for x86/x86_64 and allows the tool to have a lot more portability between differing Linux distributions and major library versions for a small cost of ~2MB. Simple Listening ShellOn the client run:
On the attacker machine run
This shell works great, but there are two obvious problems:
We can get around this by using the outbound technique that I will show later. Simple File TransferThere are two methods of doing file transfers:
Overall, the better of these two methods is when a client connects to a listening port to download a file, as this is less likely to be blocked by firewalls. To do this you need to run these two commands. On the attacker:
On the client:
Encrypted Listening ShellWe can generate an encrypted reverse shell with client and server keys to allow only our chosen attacker machine to connect to the server.
socat reverse shellSometimes the network will be configured in such a way that only certain ports will be able to host a listening service, such as 80 and 443 on a web host for example. In this case, unless we have sudo privileges, establishing a listening shell with socat is not possible. To mitigate this we can instead forward a shell or service through an outbound connection. We can also establish a PTY shell in a similar fashion On the attacker machine run:
On the client run:
Forwarding a service through an outbound connection Sometimes we want to be able to access a local service on the machine, for example if we want to access the SSH service running on our host we need to be able to use the ssh command or to be able to use our browser to interact with a local web server. We can achieve this by instead creating a second listening port on the attacker machine that will allows our different programs to connect and interact with the client's service. On the attacker machine we create two listening ports, it will wait for a connection from our client on port 80 and then wait for a suitable
On the client run:
This will allow you to connect to the service (In this case SSH) by connecting to local port 10023.
socat encrypted reverse shellOn the attacker machine we create a listening port, it will wait for a connection from our client on port 80 and then allow us to interact with it from stdin.
On the client machine we need to run:
Forwarding a service through an encrypted outbound connection After following the key generation steps listed in the encrypted reverse shell section we can wrap our outbound reverse shell in openssl using the following commands. On the attacker machine we need to run:
On the client machine we need to run:
Finally, we can create a connection by running the final connect command on the attacker machine.
Forwarding packets through a web proxy with socatSometimes a service or program will not allow the user to set a HTTP proxy. For example, if you wanted to inspect the HTTP connections a browser is making but the proxy settings are broken. The command to do so follows the general form:
In your browser you would point to
0 Comments
Leave a Reply. |
AuthorRed Cursor ArchivesCategories |