sliver-gui wraps the open-source Sliver adversary emulation framework in a cross-platform Electron desktop application for authorized red teams managing sessions, builds, and cloud deployments.
| Tool | sliverarmory/sliver-gui — cross-platform Electron GUI for the Sliver C2 framework |
| Category | Operator console / red team tooling interface |
| Primary Use | Managing authorized red team engagements: Sessions and Beacons dashboards, implant builds, listeners, loot, credentials, and cloud deployment from one desktop app |
| Safe Use | Intended for penetration testers and red teamers operating Sliver exclusively in authorized, contractually scoped assessments and lab environments; equally useful to defenders studying operator workflows |
| Telemetry Note | The GUI itself leaves operator-side artifacts (~/.sliver-client, gui/*.json settings); all server-side Sliver telemetry (mTLS operator connections, beacon callbacks) remains that of the underlying framework |
sliver-gui is the long-awaited graphical front end for Sliver, the open-source adversary emulation and C2 framework maintained under the sliverarmory organization. Written in TypeScript on top of Electron, with a React interface built from HeroUI, HeroUI Pro, and Font Awesome components, it packages the things operators normally juggle across a terminal multiplexer — server connections, session dashboards, implant builds, listener jobs, loot, and cloud infrastructure — into a single desktop application. The repository carries 93 stars, a GPL-3.0-or-later license, and a README that is unusually candid about its own coverage gaps, which immediately signals a project that takes engineering discipline seriously.
Architecturally, the application is organized around multiple windows with saved operator configurations. Connections are shared across windows that reference matching configurations, while each workspace keeps independent state, which is the right model for an operator running several parallel engagements or a single engagement with segregated client scopes. The core dashboards cover Sessions and Beacons, and dedicated interaction workspaces expose Files, Processes, Environment, Registry, and Activity panels per implant — the standard post-exploitation surfaces, presented as inspectable tables rather than raw console scrollback.
The generation side is equally well represented: dedicated views for implant generation, builds and profiles, jobs and listeners, plus Loot and Credentials management. This means an authorized operator can move through the full engagement lifecycle — configure a profile, stage a listener, generate a session implant, collect and catalog loot — without dropping to the CLI, though a native Sliver console remains embedded for anything the panels don't cover. That console, along with managed SSH windows, runs in tabbed Ghostty terminals, with terminal appearance configured under Settings → Terminal and persisted to gui/ghostty/config.
What distinguishes this project from a thin wrapper is its infrastructure tooling. Separate Armory, Network, and Cloud Deployment windows include AWS and Azure account integration, and a Cloud Deployment DNS manager handles Route 53 and Azure DNS with zone views, all-zones record views, and record editing. This maps directly to how Sliver operators typically manage callback domains during scoped engagements, consolidating what would otherwise be a browser tab full of cloud consoles. Documentation for AWS authentication, Azure authentication, and cloud DNS is maintained as separate docs in the repository.
The README is refreshingly honest about parity: the GUI does not implement every upstream Sliver command or option. Operator connections use mTLS; WireGuard operator configurations are recognized but cannot connect. A tracked operator parity report at docs/operator-parity.md documents coverage, and a beacon command roadmap lays out what's still coming. For teams evaluating the tool, that report should be the first read — it tells you exactly where the GUI will force you back to the embedded console.
Security engineering is a highlight. The Electron main process owns backend clients, operator configuration secrets, native processes, and filesystem access, while sandboxed renderers communicate through narrowly scoped, typed preload APIs; IPC validates the calling document and owning window. The production CSP blocks inline scripts and renderer network connections, application documents are served from sliver://app, and external documentation or cloud sign-in flows are pushed to the system browser rather than opened in-app. Destructive operations retain main-process validation and review flows. This is a textbook Electron threat model executed properly.
Development requirements are strict: Node.js 24.15+ on the 24.x line or 26+, npm 11.19+, and a HeroUI Pro license with authentication for its package artifacts — a commercial dependency worth noting for anyone planning forks, since third-party components like HeroUI Pro retain their own terms. The local workflow is pinned down to exact commands: npm ci --strict-allow-scripts, an authenticated npx heroui-pro install, then npm run dev, which builds and launches at sliver://app/index.html with no hot reload — you restart after source changes. Client code installs from the pinned sliver-script npm package, so no Sliver source checkout is needed for ordinary development.
Configuration layout follows the upstream convention. The default client root is ~/.sliver-client, overridable via SLIVER_CLIENT_ROOT_DIR. Application preferences live in gui/application-settings.json, workspace zoom in gui/workspace-zoom.json, text editor settings in gui/text-editor-settings.json, and imported operator configs are stored as private file references in gui/operator-configs.json. The GUI discovers existing configs in configs/ and, notably, Import and Forget operations neither copy nor delete the source files — a small detail that avoids surprise mutations of an operator's config directory.
Packaging and release engineering are thorough for a v0.0.1-era project. The CI matrix produces macOS universal DMG and ZIP, Windows x64 NSIS and portable EXE, and Linux x64 AppImage and DEB, with automatic updates wired through GitHub Releases for most formats (portable and DEB builds update manually). The initial release uses persistent self-signed code-signing certificates — macOS users will hit the native certificate trust dialog on first update check, and Windows machines need the public signing certificate trusted — with documented fingerprints and a release key policy. The npm run protocol:check command verifies the pinned client, upstream baseline, and parity artifacts, fetching the pinned upstream source into a temporary directory using Go, and console builds validate source provenance against protocol/sliver-console-provenance.json without modifying the checkout.
From a defensive perspective, sliver-gui doesn't change what blue teams detect — all network telemetry remains that of Sliver itself: mTLS operator sessions, implant callbacks, and beacon check-ins behave identically whether driven from a GUI or a raw terminal. What the tool does change is the operational tempo and consistency of the red side, which indirectly matters to purple teams: more structured operators produce more reproducible activity, which sharpens detection validation. For authorized professionals already invested in the Sliver ecosystem, sliver-gui is shaping into a serious operator console; just read the parity report before retiring your terminal.
sliverarmory/sliver-gui.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.