Skip to content

Route WG device logs to Sliver log file, enable verbose via config#2262

Open
whitebyte0 wants to merge 9 commits into
BishopFox:masterfrom
whitebyte0:wg-device-logging
Open

Route WG device logs to Sliver log file, enable verbose via config#2262
whitebyte0 wants to merge 9 commits into
BishopFox:masterfrom
whitebyte0:wg-device-logging

Conversation

@whitebyte0
Copy link
Copy Markdown

Details

WG device logs were hardcoded to LogLevelSilent, making it impossible
to debug WireGuard peer/handshake issues on the server side.

  • Route device errors to wgLog.Errorf (always active)
  • Route device verbose to wgLog.Debugf when server log level >= 5
  • Controlled via existing server.yaml logs.level setting
  • No stdout pollution — all output goes to sliver.log

@whitebyte0 whitebyte0 requested a review from a team as a code owner May 11, 2026 12:09
@whitebyte0 whitebyte0 requested a review from precurse-bf May 11, 2026 12:09
Stores the gVisor virtual network (tNet) globally and starts a
TCP forwarder at WG startup: 100.64.0.1:9100 → 127.0.0.1:9100.

This allows the C implant's sniffer module to stream captured
packets to a collector running on localhost via the WG tunnel.
The forwarder is plain io.Copy in both directions.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@moloch--
Copy link
Copy Markdown
Collaborator

we probably need the forwarder to have a configurable host/port

@whitebyte0
Copy link
Copy Markdown
Author

Yes this was hardcoded test commit, I should not push that on this branch .
Okay I will update when I finish the tests on forwarder

   New command: tcp-fwd --wg-port 9100 --local 127.0.0.1:9100
   Forwards TCP from gVisor virtual network port to local address.
   Any implant can reach it through 100.64.0.1:<port>.

   Full Sliver job integration:
   - Shows in 'jobs' listing
   - Killable with 'jobs -k <id>'
   - Persists across server restarts (DB)
   - Auto-restores on server boot

   Implementation:
   - Protobuf: TCPFwdListenerReq message, StartTCPFwdListener RPC
   - Server: StartTCPFwdListenerJob in c2/jobs.go, RPC handler
   - Client: tcp-fwd command with --wg-port and --local flags
   - DB: TcpFwdListener model with WGPort + LocalAddr
   - Forwarder: semaphore (32 max), recoverAndLogPanic, TCP keepalive,
     OpError handling — matches project conventions
@whitebyte0
Copy link
Copy Markdown
Author

I did integration, but still testing,

I will notify when I finish testing process.

Also let me describe the goal.

  • the goal is to be able to run custom listener on host network which can have a persistent listener to get data from the implant actively, if you integrate traffic sniffer or data parser, or network scanner etc. which works long time and stream the output to analyzer or some other program to parse the output - this is what you use.
  • My use case is traffic sniffing from the target host, I will also publish a data collector which I use, and also will publish a tiny module which can be integrated (hope easily) to the implant as optional module to extract the unencrypted data from implant and send it to collector/analyzer so the feature picture will be complete.

@whitebyte0
Copy link
Copy Markdown
Author

Tests passed. Branch is ready to merge.

@whitebyte0
Copy link
Copy Markdown
Author

I forgot to mention, this is only useful if the implant uses wireguard, so need to forward traffic out of the isolated wireguard network, without breaking the network isolation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants