Agent features on Goauld

Tunneling

Mon, 01 Jan 0001 00:00:00 +0000

The Goauld agent supports multiple transport mechanisms to communicate with the server. If a transport fails, the agent automatically falls back to the next available method.

The agent attempts to connect to the server using several transports:

Direct SSH connection
SSH over QUIC
SSH over TLS
SSH over WebSocket
SSH over HTTP
SSH over DNS

For each transport protocol, the agent tries establish a connection to the server, with a 60 seconds timeout (configurable using --ssh-timeout flag). If the connection is established, the agent finalizes the connection.

Exposed proxies

Mon, 01 Jan 0001 00:00:00 +0000

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

Note

Given that performing NTLM/Kerberos application-level authentication requires to intercept the traffic (MITM) to inject appropriate headers, this feature has been implemented in a dedicated proxy.

HTTP proxy

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

Relay

Mon, 01 Jan 0001 00:00:00 +0000

If an agent A cannot reach the Goauld server, but can reach anothe agent B that can reach the server, then agent B can be configured to run as a relay.

Configure an agent as a relay

--relay: Enable relay mode on the agent

Note

The agent listens on all interfaces using a randomly assigned port. This port is logged in the agent logs:

INF agent/agent.go:468 > Relay listening on port Port=57129

Or in the TUI (Press + to view details about the agent)

WireGuard

Mon, 01 Jan 0001 00:00:00 +0000

The agent exposes a virtual WireGuard interface, allowing TCP, UDP, and ICMP (ping) traffic without relying on a SOCKS proxy.

The virtual WireGuard interface uses the gVisor network stack (https://github.com/google/gvisor/tree/go).

The implementation works as follows:

The agent exposes a WireGuard server port on the host.
The agent forwards the WireGuard port to the server using UDP-over-TCP encapsulation to traverse the existing agent tunnel.
The client forwards the WireGuard port exposed on the server to the local machine.
The client decapsulates the UDP-over-TCP traffic to expose the WireGuard port.
The WireGuard client on the operator machine connects to the agent’s virtual WireGuard interface.

Note

This implementation uses TCP-over-TCP encapsulation, which reduces performance. However, this architecture was chosen because the server does not expose a WireGuard server common to all connected agents, which could result in unauthorized access between agents.

Password Management

Mon, 01 Jan 0001 00:00:00 +0000

For historical reasons, the agent password consists of two parts:

Part 1: Generated by the agent at each start and sent to the server through the control socket.
Part 2: It is stored only locally on the agent.

The second part can be generated through different methods:

1. At compile-time

When compiling an agent through the client (see client/compilation), the generated password is displayed either in the standard output during compilation or in the .env file that contains all the variables set for the agent.

Killswitch

Mon, 01 Jan 0001 00:00:00 +0000

To ensure that no agent runs indefinitely, a killswitch has been implemented. After a specified number of days, the agent automatically shuts down.

Flag

--kill-switch: Set the number of days before exiting

Note

The timer counts from the agent’s execution time. Consequently, if an external system (scheduled task, cron job, etc.) restarts the agent, the killswitch timer resets.

Connection flow

Mon, 01 Jan 0001 00:00:00 +0000

The agent separates orchestration (control) from operational traffic (data):

Control socket: A Socket.IO component, which is used to transmit agent metadata and receive control instructions from the server (reset/kill, etc.)
Data socket: An SSH channel, which may be encapsulated depending on egress filtering restrictions, which is used to tunnel operational traffic (proxies, SSH access, pivoting services, etc.)

If a connection is lost, the agent automatically attempts to reconnect to both channels using an exponential backoff strategy.

Working days

Mon, 01 Jan 0001 00:00:00 +0000

During assessments, it may be necessary to keep an agent running for several days (it can be difficult to execute).

To reduce the agent’s network footprint, a mechanism allows it to pause all network activity at a specified time and automatically resume later at a specified hour.

If the agent starts outside the working period, it will wait until the next start hour.

Flags

--only-working-days: to enable the working days feature
--working-day-start : the given hour when the agent resumes network connection (format: [HOURS]:[MINUTES], 24-hour format)
--working-day-end: the given hour when the agent stops all network connection (format: [HOURS]:[MINUTES], 24-hour format)
--working-day-timezone: the timezone to use