Socks Proxy
What is it?
Socks proxy capabilities are a way to tunnel other traffic through another protocol. Within Mythic, this means tunneling other proxy-aware traffic through your normal C2 traffic. Mythic specifically leverages a modified Socks5 protocol without authentication (it's going through your C2 traffic afterall).
Where is it?
From the "Active Callbacks" page, click any callback's dropdown menu and select "Socks". This will open a small pane on the bottom of the screen with basic socks information.
When you issue a command to start a socks proxy with Mythic, you specify an action "start/stop" and a port number. Mythic opens two ports (the port number and the port number + 1).
The port number you specify is the one you access remotely and leverage with your external tooling (such as proxychains). The other port is only accessed by the Mythic server.
How does it work?
An operator issues a command to start socks on port 3333. This command goes to the associated payload type's container which does an RPC call to Mythic to open that port for Socks.
Mythic opens port 3333 and 3334 via a helper Golang binary and spins off a thread to connect to port 3334.
An operator configures proxychains to point to the Mythic server on port 3333.
An operator runs a tool through proxychains (ex:
proxychains curl https://www.google.com)Proxychains connects to Mythic on port 3333 and starts the Socks protocol negotiations.
The helper Golang binary gets the connection from proxychains, and spins off a Golang channel (like a thread). This new channel gets a random ID. The helper binary sends this ID and the socks data off to port 3334.
Mythic gets the data on 3334 and holds onto it.
The next time the agent checks in, Mythic takes this socks data and hands it off to the agent as part of the normal Action: get_tasking process.
The agent checks if it's seen that random ID before. If it has, it looks up the appropriate TCP connection and sends off the data. If it hasn't, it parses the Socks data to see where to open the connection. Then sends the resulting data and same randomID back to Mythic via Action: post_response.
Mythic gets the response, parses out the Socks specific data, and sends it back to port 3334.
The helper Golang binary gets the data from 3334 and feeds it back to the originating connection.
The above is a general scenario for how data is sent through for Socks. The Mythic server itself doesn't look at any of the data that's flowing - it simply tracks port to Callback mappings and shuttles data appropriately. The helper Golang binary and the agent are the ones tracking the "random ID" values so that the threaded connections from proxychains can be correlated across the C2 channel.
Your proxy connections are at the mercy of the latency of your C2 channel. If your checkin time is every 10s, then you'll get one message of traffic sent every 20s (round trip time). This breaks a LOT of protocols. Therefore, it's recommended that you change the sleep of your agent down to something very low (0 or as close to it).
Don't forget to change the sleep interval of your agent back to your normal intervals when you're done with Socks so that you reduce the burden on both the server and your agent.
Last updated