Exposed proxies

Goauld agent proxies

The agent exposes three proxies that allow interaction with the host’s network:

An HTTP proxy
An HTTP proxy that performs NTLM/Kerberos application-level authentication
A SOCKS proxy

Quick usage

Enable the proxy on the agent, then expose it locally from the client:

tealc socks AGENT_NAME

The client binds the local listener to loopback by default. Use the client proxy options to select a local port; use the agent options below to control the upstream proxy and authentication behavior.

Note

NTLM/Kerberos authentication requires intercepting traffic (MITM) to inject authentication headers. This is implemented in a dedicated proxy for isolation.

HTTP proxy

For each incoming request, the HTTP proxy determines whether an upstream proxy should be used and which one.

By default, it uses the same proxy selection priority as the agent (see Egress proxies). This behavior can be customized using:

Configuration

--http-custom-proxy: override the system proxy
--http-proxy-username: Username to authenticate on the proxy
--http-proxy-password: Password to authenticate on the proxy
--http-proxy-domain: Domain to authenticate on the proxy
--http-proxy-enabled/--no-http-proxy-enabled: Enable/Disable the HTTP proxy
--http-port: the virtual port identifying the HTTP proxy forward on the server (default: 0, meaning the server assigns one automatically).

Note

Despite the name, --http-port (like --http-mitm-port, --socks-port, and -R/--remote-port-forwarding’s REMOTE_PORT below) does not cause the server to open a real listening socket on its host. It is a virtual identifier, scoped to this agent, that the server resolves entirely in-process against the agent’s own SSH connection when a client (via tealc socks/tealc ssh’s proxy forwarding, see Client proxies) asks to reach it. No port is ever exposed on the server’s network interfaces for this traffic.

Note

This proxy is automatically enabled in these cases:

MITM HTTP proxy is enabled
SOCKS proxy is configured to use the HTTP proxy

HTTP proxy with NTLM/Kerberos authentication

Some applications require NTLM/Kerberos authentication.

This proxy transparently handles NTLM/Kerberos authentication requests, exposing network access to the client as if requests originated from the host.

It uses the previously described HTTP proxy as its upstream proxy to handle system proxy and proxy authentication requirements.

Warning

This proxy is only available on Windows.

Configuration

--mitm-http-proxy-enabled/--no-mitm-http-proxy-enabled: Enable/Disable the MITM HTTP proxy
--mitm-http-port: the virtual port identifying the MITM HTTP proxy forward on the server (default: 0, meaning the server assigns one automatically, see the note under HTTP proxy above).
--mitm-http-proxy-username: Username for the MITM HTTP upstream proxy
--mitm-http-proxy-password: Password for the MITM HTTP upstream proxy
--mitm-http-proxy-domain: Domain for the MITM HTTP upstream proxy

Note

This proxy is automatically enabled when SOCKS proxy is configured to use MITM mode.

SOCKS proxy

The SOCKS proxy can be configured to use different HTTP upstream proxies:

http: agent HTTP upstream proxy
mitm: agent HTTP with NTLM/Kerberos upstream proxy
system: the default HTTP proxy configured on the host (the proxy used by the agent to access the Goauld server)
custom: the custom proxy configured in the --socks-custom-proxy flag
none: no upstream proxy

Configuration

--socks-custom-proxy: Custom upstream HTTP proxy used within the SOCKS proxy
--socks-upstream-proxy: Configure the upstream HTTP proxy to use (none|system|http|mitm|custom)
--socks-proxy-username: Username for the SOCKS upstream proxy
--socks-proxy-password: Password for the SOCKS upstream proxy
--socks-proxy-domain: Domain for the SOCKS upstream proxy
--socks-enabled/--no-socks-enabled: Enable/Disable the SOCKS proxy
--socks-port: the virtual port identifying the SOCKS proxy forward on the server (default: 0, meaning the server assigns one automatically, see the note under HTTP proxy above).

Remote port forwarding

Independent of the three proxies above, the agent can forward specific ports on its host to the server, one at a time.

Configuration

-R/--remote-port-forwarding: REMOTE_PORT[:LOCAL_IP]:LOCAL_PORT: forwards LOCAL_IP:LOCAL_PORT (on the agent’s host) to REMOTE_PORT on the server. LOCAL_IP defaults to 127.0.0.1 if omitted. Use 0 for REMOTE_PORT to let the server assign one automatically. Can be repeated (or comma-separated) to forward multiple ports. REMOTE_PORT is a virtual identifier resolved in-process, the same as the proxy ports above; it is never a real listening socket on the server.

Example: --remote-port-forwarding 8080::3000 forwards 127.0.0.1:3000 on the agent to port 8080 on the server.