Xenon is a Windows implant agent for the Mythic C2 framework, written in C, offering BOF execution, malleable C2 profiles and peer-to-peer linking for authorized red team engagements.
| Tool | MythicAgents/Xenon — a Cobalt Strike-like Windows agent for the Mythic C2 framework, written in C |
| Category | Command and control agent / post-exploitation framework |
| Primary Use | Running authorized red team and purple team engagements on Windows targets through Mythic, with BOF execution, token manipulation and malleable C2 over httpx, smb and tcp |
| Safe Use | Strictly for authorized penetration tests, lab environments and engagements with written permission; the README itself warns it is early-release, not OPSEC safe, and should be tested thoroughly before any live use |
| Telemetry Note | The project claims no evasion; default builds will be noisy to EDR. httpx traffic uses configurable transforms (base64, xor, netbios) and placement in cookies, headers or body — useful signatures for defenders studying Mythic-family egress |
Xenon positions itself in a crowded niche: it is a Windows agent for the Mythic command-and-control framework, written in C by @c0rnbread, and it deliberately borrows the interaction model of Cobalt Strike. The repository describes it bluntly as a "Cobalt Strike-like Windows agent," which tells you the intended operator experience: token manipulation, fork & run post-exploitation, Beacon Object File (BOF) execution, and peer-to-peer linking between implants. This is documentary analysis of a publicly documented dual-use framework, relevant to authorized red teamers and equally to defenders who need to understand what a Mythic-infested Windows host looks like from the inside.
The most striking thing about the README is its honesty. A prominent warning states that Xenon is in an early state of release, is "not opsec safe," and could contain memory issues causing crashes — the author explicitly recommends thorough testing before any live environment use. A separate OPSEC disclaimer reinforces this: Xenon makes no claims about evasion, and the default configuration will not be OPSEC safe. The stated design goal is not stealth out of the box but extensibility, letting the operator customize features to accomplish their goals. That framing matters: this is a builder's toolkit more than a turnkey implant, and the project's Wiki is where the customization and evasion guidance lives.
Installation follows the standard Mythic agent pattern, which keeps the barrier low if you already run a Mythic server. From the Mythic install directory, ./mythic-cli install github https://github.com/MythicAgents/Xenon.git installs the agent as root; the non-root variant is sudo -E ./mythic-cli install github https://github.com/MythicAgents/Xenon.git. The agent is licensed under BSD-3-Clause, which permits study and modification — relevant for teams that want to audit the C source before ever generating a payload. The repo sits at 183 stars with recent activity, and contributions are organized around versioned branches named like v1.2.3, with contributors including @dstepanov for TCP transport support.
Architecturally, the feature list reads like a checklist of modern implant engineering. Xenon supports modular command inclusion at build time, malleable C2 profiles, and three communication transports: httpx, smb, and tcp. It uses forge, a separate Mythic container project, as a command augmentation layer for BOF modules and SharpCollections. It supports asynchronous BOF execution against the async BeaconAPIs, user-defined reflective DLL loaders based on Crystal Palace, and compatibility with Cobalt Strike process injection kits — the register_process_inject_kit command even pops a modal in the Mythic UI to register a custom injection BOF. That CS compatibility is a deliberate design decision that lowers migration cost for operators coming from Cobalt Strike.
The command surface is broad and maps closely onto what you would expect from an adversary-emulation implant. Filesystem primitives include pwd, ls, cd, cp, rm, mkdir, download (including UNC paths), and upload via a modal dialog. Identity and token operations include getuid, make_token with plaintext credentials and an optional logon type, steal_token by PID, and rev2self to revert — the classic Cobalt Strike token workflow. Host situational awareness comes from ps and process termination via kill. remote_exec can execute commands on remote machines through WMI, WinRM, or SCShell with optional credentials. sleep adjusts callback interval and jitter, and exit tasks the implant to terminate.
Where Xenon gets interesting technically is its BOF subsystem. inline_execute runs a Beacon Object File (COFF.o) on the current process thread — with a warning that incorrect argument types can crash the agent — while async_execute pushes long-running BOFs into a background thread, streaming output via Mythic task updates and honoring BeaconWakeup and BeaconGetStopJobEvent. A job control layer backs this: jobs lists running async BOFs with their Mythic task UUIDs, and jobkill signals the stop event. The README gives keylogger -Interval 30000 followed by jobs and jobkill as the canonical lifecycle example, illustrating how live-collectors are meant to be started, observed, and cleanly stopped.
The .NET side is well covered. inline_execute_assembly executes a .NET assembly in the current process using @EricEsquivel's "Inline-EA" BOF, with flags --patchexit, --amsi, and --etw to neutralize the usual exits and telemetry before loading the assembly. execute_assembly takes the classic fork & run route, running the assembly in a remote process — the README uses SharpUp.exe with an audit argument as its illustration, a fitting choice since SharpUp is an audit-oriented privesc tool. execute_dll loads a DLL as position-independent code, powerchell runs PowerShell through a PowerChell post-ex DLL, and powershell_import caches scripts for later use. A dedicated mimikatz post-ex command exists, running in a remote process.
Pivoting and network traversal are first-class. link and unlink connect or disconnect SMB/TCP peer agents, enabling chained implants that egress through a single compromised host. socks stands up a SOCKS 5-compliant proxy into the target network, rportfwd provides reverse port forwarding, and status lists all C2 connection hosts and their state. spawnto sets the sacrificial process path (the README's example is svchost.exe) used by spawn-and-inject commands, and usermon polls WTS sessions as an async login monitor with live-streamed alerts. The roadmap shows remaining gaps: DNS transport is still unchecked, and Mythic-native features like the process browser and TTPs view are planned, while SOCKS5, the file browser UI, and powerchell are marked done.
C2 flexibility is one of Xenon's stronger selling points. Over the httpx profile it supports callback domain arrays with fail-over, round-robin, and random rotation, a fallback threshold controlling when to move to the next domain, and per-build message configuration in JSON or TOML. Messages can be placed in cookies, headers, query parameters, or the body, and transformed with base64, base64url, append, prepend, xor, and netbios/netbiosu encodings, plus custom client headers and query parameters. A websocket profile can serve as the main egress channel in push style, and smb and tcp profiles generate peer-to-peer builds. From a defensive perspective this transform matrix is exactly the kind of thing threat hunters should study, because malleable traffic shaping is only as good as its configuration discipline.
The forge integration deserves its own note because it changes the economics of capability delivery. Forge is described by the author as a command augmentation container that he highly recommends, shipping with out-of-the-box support for Flangvik's SharpCollection and Sliver's Armory BOF collections. After installing the forge container, the operator enables commands per callback and pulls in tooling with forge_collections -collectionName SharpCollection or -collectionName SliverArmory. In practice this means Xenon does not need to bundle its own arsenal — it can lean on two large, actively maintained collections of compiled .NET tooling and BOFs at run time.
The bug history in the README is unusually transparent and instructive. Fixed items include duplicate-buffer memory issues, initial install files not being found, random named pipes per payload generation, problems executing BOFs compiled with MSVC, and execute_assembly causing PIPE_BUSY when an assembly does not exit cleanly. Still open: general weirdness in the file browser UI with remote hosts. For anyone deploying this in an authorized lab, that ledger is a useful map of where the code has been fragile — memory handling in a C implant is exactly where crashes and detectable artifacts come from.
Taken as a whole, Xenon is a credible, fast-moving entry in the Mythic agent ecosystem: Cobalt Strike ergonomics, native C implementation, async BOF job control, malleable httpx egress, and a large borrowed arsenal through forge. Its documented rough edges and explicit no-evasion disclaimer make it best suited to authorized engagement infrastructure, adversary-emulation labs, and detection engineering, where operators and defenders alike benefit from a tool whose trade-offs are stated plainly rather than marketed away. As with every implant framework, the ethical boundary is the engagement scope — Xenon is a tool for systems you are contractually permitted to test, nothing more.
MythicAgents/Xenon.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.