XRayC2 repurposes AWS X-Ray, a distributed tracing service, into a stealthy command and control channel by encoding instructions into trace annotations and reading responses via X-Ray APIs. This article unpacks what XRayC2 does, how to install and run it in a safe lab, a realistic offensive scenario, and detection and remediation advice for defenders. All installation and usage snippets are taken from the upstream project and associated analysis.

XRayC2 demonstrates a nonstandard C2 vector: using AWS X-Ray as a data transport. X-Ray is designed for distributed tracing and support teams use it to track requests through microservices. XRayC2 abuses that legitimate telemetry channel to exchange short commands and exfiltrate small outputs. The technique is notable because many monitoring and detection setups focus on classic Identity and Access Management events, not on tracing systems. The primary public writeups and proof of concept are the project repository and a detailed writeup titled Ghost in the Cloud.

Features

• Encodes C2 commands in X-Ray subsegment annotations and metadata.
• Fetches trace data via the X-Ray GetTrace/GetServiceGraph APIs to read responses.
• Minimal footprint because X-Ray traffic looks like normal telemetry calls to cloud operators.
• Designed for constrained command sizes and small outputs; not a full file exfiltration channel without chunking and patience.

Installation

The project provides a GitHub repository with build and run instructions. The steps below are reproduced from the repository. Follow them only in an authorized lab account.

If the repo includes compiled components, follow the included build script in the README. The original project README and the Ghost in the Cloud research post both show exact build/run examples and caveats. Do not run this against production or third party accounts.

Usage (validated help output)

The following usage/help text is taken verbatim from the public repository and the technical writeup. It shows the intended high level commands and modes and is included here so readers can see the real CLI shape before running anything. Use these flags only in authorized test environments.

Realistic Offensive Scenario

Objective: From a low privileged developer credential with X-Ray write permissions, obtain lateral visibility and create a covert short-command channel to an implanted process.

Steps (high level):

• Obtain credentials scoped to the target application (typical developer API key or compromised service role).
• Deploy the implant or convince a service to emit X-Ray subsegments with encoded commands. The implant reads annotations and executes allowed commands locally.
• Use small commands to enumerate environment and credentials, for example print environment variables or curl a local metadata service. Responses are encoded back into trace annotation fields and visible through X-Ray GetTrace APIs.
• Use the channel to fetch short configuration data or staging instructions for follow-on tools.

This flow is compact, low volume, and mixes with normal telemetry. The attack is constrained by X-Ray sampling and payload size. Channel reliability improves if the implant forces traces to be captured or if operators tune X-Ray sampling during tests. All of this should be tested only in lab environments.

Red Team Relevance

XRayC2 is relevant to red teams for three reasons.

• It expands the toolset for covert communications when traditional C2 ports or DNS channels are noisy or blocked.
• It allows testing of telemetry monitoring gaps: defenders often do not monitor or alert on unusual X-Ray usage patterns.
• It informs adversary emulation: including tracing telemetry abuse in purple-team exercises forces defenders to close gaps beyond IAM and network flows.

Pairing XRayC2 runs with standard post-compromise tooling can validate whether security teams detect lateral movement when telemetry channels are abused. See CloudConqueror for a related cloud API abuse angle and Autoswagger for API discovery and testing techniques that can expose unauthenticated endpoints to similar misuse.

Detection and Mitigation

Detection is feasible if defenders treat X-Ray telemetry as a first class data source.

• Log and alert on anomalous spikes in PutTraceSegments or GetTrace calls from unexpected principals.
• Correlate X-Ray activity with creation of short-lived roles, unusual environment variables, or new deployment artifacts.
• Detect unusual annotation patterns or repeated identical subsegment payloads which are unlikely in normal app telemetry.
• Enforce least privilege: avoid granting service roles direct unrestricted X-Ray write permissions where not required.
• Instrument sampling and retention policies so that suspicious traces are captured reliably for forensic review.

For rapid blue team testing, run controlled XRayC2 activity in a lab account and tune detection rules to raise a signal on the specific patterns above.

Limitations and Trade-offs

XRayC2 is not a high bandwidth channel. It is optimized for short commands and small responses. It depends on X-Ray sampling and retention configuration which can reduce reliability. Using X-Ray this way may leave telemetry artifacts that are detectable if defenders monitor these APIs.

Conclusion

XRayC2 is a practical proof of concept that highlights an overlooked telemetry abuse vector. It is valuable to red teams and purple teams that want to test defender coverage beyond traditional IAM and network channels. Defenders should add X-Ray and other tracing systems to their detection matrix and treat management APIs like CloudControl and X-Ray as potential attack surfaces. For related cloud abuse tooling and techniques see the CloudConqueror piece on CloudControl API abuse and Autoswagger for API spec discovery.

Risk and disclosure note: Do not run offensive tools or the examples above on production or third party accounts. Always obtain written authorization and sanitize any published examples to remove real account identifiers.

You can read more or download XRayC2 here: https://github.com/RootUp/XRayC2