Mythic Documentation
Version 2.3
Version 2.3
  • Mythic
  • Operators
  • Installation
    • Connecting
    • A note about containers
    • Offline Installation
    • Updating Mythic
  • Internal Documentation
  • Quick Usage
  • Operational Pieces
    • MITRE ATT&CK
    • Operations
    • Browser Scripts
    • Active Callbacks
    • Files
    • Search
    • File Browser
    • Socks Proxy
    • Credentials
    • Comments
    • Tags
    • Expanded Callbacks
    • Screenshots
    • Event Feed
    • API Tokens
  • Message Flow
    • Building Payloads
    • Agent Sends Message
    • File Upload Mythic->Agent
    • File Download Agent->Mythic
    • P2P Messages
    • Operator Submits Tasking
  • Database Schema
  • Understanding Commands
    • Basic Information
    • Parameters
    • MITRE ATT&CK in Commands
  • Payload Types
    • Configuration
    • Containers
  • C2 Profiles
    • C2 Server Utilities
    • Egress vs P2P
    • HTTP
    • dynamicHTTP
    • Save Parameters
  • Reporting
    • Artifacts
    • MITRE ATT&CK
    • Reports
  • Scripting
  • Presentations / Webinars
  • Common Errors
  • Customizing
    • Hooking Features
      • Actions
      • Linking Agents
      • P2P Connections
      • Process_List
      • Artifacts
      • Credentials
      • File Downloads (Agent -> Mythic)
      • File Uploads (Mythic -> Agent)
      • Screenshots
      • Commands
      • Keylog
      • File Browser
      • Tokens
      • Task Status
    • Payload Type Development
      • Translation Containers
      • First Steps
      • Container Syncing
      • Payload Type Info
      • Commands
      • Browser Scripting
      • Dynamic Parameter Values
      • Create_Tasking
      • MythicRPC
      • OPSEC Checking
      • Sub-tasking / Task Callbacks
      • Process Response
      • SOCKS
      • Reverse PortFwd
      • Adding Commands
    • C2 Related Development
      • C2 Profile Code
        • Agent Side Coding
          • Delegates (p2p)
          • Agent Message Format
          • Action: Checkin
          • Action: get_tasking
          • Action: post_response
          • SOCKS
          • RPFWD
        • Server Side Coding
          • OPSEC Checks For C2 Profiles
          • Configuration Checks
          • Redirect Rules
          • C2 Docker Containers
          • C2 Configuration Files
    • Mythic UI Development
  • Common Questions and Answers
    • FAQ / Troubleshooting Tips
    • Change Log
    • Next Release
    • Tip of the Week
  • Updating
    • Mythic 2.1 -> 2.2 Updates
      • Agents 2.1.* -> 2.2.8
        • MythicRPC
    • Mythic 2.2 -> 2.3 Updates
      • Agents 2.2 -> 2.3
    • Mythic 2.3 -> 3.0 Updates
      • Agents 2.3 -> 3.0
Powered by GitBook
On this page
  • What is it?
  • Where is it?
  • How does it work?

Was this helpful?

Export as PDF
  1. Operational Pieces

Socks Proxy

PreviousFile BrowserNextCredentials

Last updated 1 year ago

Was this helpful?

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).

The Mythic server runs within a Docker container, and as such, you have to define which ports to expose externally. Mythic/.env has a special environment variable you can use to expose a range of ports at a time for this exact reason - MYTHIC_SERVER_DYNAMIC_PORTS="7000-7010". By default this uses ports 7000-7010, but you can change this to any range you want and then simply restart Mythic to make the changes.

Where is it?

Click the main Search field at the top and click the "Socks" icon on the far right (or click the socks icon at the top bar).

When you issue a command to start a socks proxy with Mythic, you specify an action "start/stop" and a port number. The port number you specify is the one you access remotely and leverage with your external tooling (such as proxychains).

How does it work?

  1. 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.

  2. Mythic opens port 3333 in a go routine.

  3. An operator configures proxychains to point to the Mythic server on port 3333.

  4. An operator runs a tool through proxychains (ex: proxychains curl https://www.google.com)

  5. Proxychains connects to Mythic on port 3333 and starts the Socks protocol negotiations.

  6. The tool sends data through proxychains, and Mythic stores it in memory. In this temporary data, Mythic assigns each connection its own ID number.

  7. The next time the agent checks in, Mythic takes this socks data and hands it off to the agent as part of the normal or process.

  8. The agent checks if it's seen that 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 .

  9. Mythic gets the response, parses out the Socks specific data, and sends it back to proxychains

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.

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.

Action: get_tasking
post_response
Action: post_response