Spark (XZB-1248/Spark): a Go RAT with a browser dashboard

What Spark actually is, and who it is for

Spark is a self-hosted remote administration tool. The README describes it as "a free, safe, open-source, web-based, cross-platform, and full-featured RAT (Remote Administration Tool) that allows you to control all your devices via browser anywhere." The operative word is self-hosted: the README states that clients communicate exclusively with your server, that the server does not collect user information, and that it will not update itself. Nothing routes through a vendor.

The audience is narrow and technical. You need to run a binary on a host you control, write a JSON config, and generate a client binary for every machine you want to manage. In exchange you get one browser tab that shows process lists, network traffic, a file explorer with an editor, a remote terminal and a desktop view across Windows, Linux and macOS. The feature table in the README marks every one of those as available on all three platforms.

The disclaimer is not decoration. It says the project, its source code and its releases "SHOULD ONLY BE USED FOR EDUCATIONAL PURPOSES" and that illegal usage is strictly prohibited. A tool that gives a web page process-kill and shell access on a remote host is indistinguishable from malware when the host is not yours. Read that before anything else.

Client, server and embedded front end

The repository splits into three parts the README names explicitly: Client, Server and Front-end. The top-level directories match: client/, server/, web/, plus modules/, utils/ and scripts/.

The build order matters and reveals the architecture. The web front end is built first with npm, then its dist/ output is packed into Go source by statik and dropped into server/embed. So the server binary carries the UI inside it; there is no separate static file directory to serve or mount. The server is built by scripts/build.server.sh, and clients by scripts/build.client.sh.

Transport is websocket-based: go.mod lists github.com/gorilla/websocket v1.5.0, and the front end uses xterm.js for the terminal view, which is the usual pairing when a browser has to talk to a shell over a persistent socket. The HTTP layer is gin-gonic/gin v1.7.7. Host metrics come from shirou/gopsutil/v3, screenshots from kbinani/screenshot, and the terminal on Unix-like systems goes through github.com/creack/pty. The client identifies machines with denisbrodbeck/machineid.

The consequence for operators is that server and client are the same codebase compiled twice with different roles. There is no separate agent package to install from a registry.

Installing Spark and connecting a first client

The README offers two paths. The quick one is to download an executable from the releases page, follow the configuration section, run it, and open http://IP:Port in a browser. The other is to build from source. The build guide assumes Go 1.18 (the go.mod directive) and Node for the front end.

Building starts with the web UI, then embedding it:

cd ./web
npm install
npm run build-prod
cd ..
go install github.com/rakyll/statik
statik -m -src="./web/dist" -f -dest="./server/embed" -p web -ns web

After that, the client and server are compiled by the project's own scripts, which expect ./built and ./releases to exist:

mkdir ./built
mkdir ./releases
go mod tidy
go mod download
./scripts/build.client.sh
./scripts/build.server.sh

The server reads config.json from the same directory as the executable. A minimal file, following the README example, looks like this:

{
    "listen": ":8000",
    "salt": "123456abcdef123456",
    "auth": {
        "username": "password"
    }
}

listen and salt are both required. The README states the salt has a maximum length of 24 characters and that changing it means every client must be regenerated. auth is optional, and the README recommends hashed passwords in the form $algorithm$hashed-password, with sha256, sha512 and bcrypt supported. Once the server is up, you open the web interface, generate a client, run that client on the target device, and the device appears in the dashboard.

Logging is optional too, under a log object with level, path and days. Valid levels are disable, fatal, error, warn, info, debug; path defaults to ./logs and days to 7.

The salt is the deployment's real weak point

The salt is not a password you can rotate quietly. The README says plainly that after modifying it, all clients need to be regenerated. That makes the salt a long-lived shared secret baked into every deployed binary, and it means the cost of rotating it scales with your fleet.

That is a design trade-off, not a bug, and it has a second edge: if a client binary leaks, whoever holds it holds the salt. There is no documented mechanism for revoking a single client, and the README does not describe per-client credentials or a client allowlist. The auth object protects the web interface with a username and password, and the README recommends storing it hashed rather than in clear text, which is the minimum you should do. But the dashboard login and the client-to-server trust are separate concerns, and only the first one is documented as configurable.

The README also asks that security vulnerabilities not be filed as issues, and instead be mailed to the maintainer's address. That is a reasonable request for a tool like this, and it also means there is no public vulnerability tracker to watch.

Platform gaps in the power-control features

The feature table is honest about where the three platforms diverge. Process management, killing processes, network traffic, file explorer, file transfer, file editing, deletion, code highlighting, desktop monitor, screenshot, OS info and the remote terminal are all marked available on Windows, Linux and macOS.

The starred power controls are not. Log Off and Sleep are marked for Windows and macOS but not Linux. Hibernate and Lock Screen are Windows only. Shutdown and Reboot are the only two available everywhere. The README adds that functions marked with an asterisk may require administrator or root privileges.

So if your fleet is Linux and you were hoping to lock or hibernate those machines from the dashboard, the table says you cannot. You get shutdown and reboot. That is a real limit for anyone comparing Spark against a full remote management suite, and it is the kind of thing worth checking against your own machine list before you commit to a rollout.

Spark versus a conventional remote support stack

The closest comparison the README itself makes is natpass, listed under acknowledgements and licensed MIT. natpass is a remote terminal and file-transfer tool; Spark bundles a terminal and file transfer plus process control, screenshots and a desktop view. If all you need is a shell and file movement, natpass is a smaller surface to expose.

The wider comparison is against commercial remote support products, and the difference is architectural rather than a feature checklist. Commercial tools typically ship signed agents, an update channel, a hosted relay, session recording and an audit trail, and someone to call when they break. Spark deliberately has none of that: the README states there is no auto-update and that clients talk only to your server. That is a privacy property and an operational burden at the same time. You own patching, you own the certificate or reverse proxy in front of the dashboard, and you own the network exposure.

Spark's advantage is that you can read the whole thing. Go, BSD-2-Clause, dependencies listed in go.mod and package.json, no telemetry. If your requirement is a small, inspectable tool you host yourself, that trade is coherent. If your requirement is compliance evidence and a support contract, it is not.

Licence, maintenance and upgrade cost

Spark is BSD-2-Clause, a permissive licence that allows modification and redistribution with the copyright notice and disclaimer retained. The repository keeps a licenses/ directory alongside the main LICENSE file, and the README lists major dependencies with their own licences: gin, req, screenshot, concurrent-map, React, Ant-Design, axios, xterm.js and crypto-js under MIT; gorilla/websocket under BSD-2-Clause; gopsutil under its own terms. If you redistribute a built client or server, those notices travel with it. That is a packaging task, not a legal opinion, and it is worth having someone check the combined notice file before you ship binaries outside your organisation.

Maintenance is the harder question. The newest tagged release is v0.2.1, dated 2023-02-01, followed by v0.2.0 in 2022-11-01 and v0.1.9 in 2022-10-21. The repository is not archived, and the last push to master was on 2026-03-16. So work has continued on the branch, but the release channel has not produced a tag in years. That gap matters for upgrades: if you build from master to get current code, you are tracking a moving branch with no changelog entry for it, and CHANGELOG.md is the only place release notes live.

The upgrade cost is dominated by the salt rule. Any change that requires regenerating clients means re-deploying binaries across every managed machine. Plan for that before the first rollout, not after.

Editorial conclusion

Adopt Spark only for machines you own or are explicitly authorised to administer, and only after you have read the disclaimer and confirmed that a self-hosted RAT is acceptable in your jurisdiction and your organisation. Skip it if you need an audited, commercially supported remote support product, if you need macOS or Linux power controls, or if you cannot rebuild and redeploy clients every time you rotate the salt. Verify first that a current client builds on your Go toolchain, since the newest tagged release is v0.2.1 from 2023-02-01 while the master branch was last pushed on 2026-03-16, and check whether your build needs a C compiler for the target OS.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. README
4. Releases
5. XZB-1248/Spark on GitHub