Cribl Exec-source reverse shells.

Context

Cribl Edge supports Exec sources: configurations that execute commands and collect their output. That is useful product functionality, but authorized access to create and deploy one also creates a direct code-execution primitive on the target node.

The method is similar in spirit to reverse-shell paths in other management and observability products. The goal of this lab was to document the control boundary and produce a shell in a contained environment.

Requirements

1. Authorized access to create Exec sources through the Cribl management interface.
2. A controlled listener or attack box.
3. A target node isolated from unrelated fleet members.
4. A payload appropriate for the lab environment.

Fleet isolation matters. Applying an Exec source to a broad group can create callbacks from every grouped server, turning a controlled test into noise.

Process

1. Isolate the target

In the Edge management interface, map the target host into its own fleet. This limits the deployment to the intended node and makes the resulting traffic easier to reason about.

2. Create the Exec source

Add a new source and switch to the JSON management view. The original repository contains the example configuration; update the attack-box address and port for the authorized lab.

3. Stage the callback

Prepare a PowerShell callback in the controlled environment, serve it from the attack box, and open the matching listener. In this test, staging the script separately was less scrutinized by Windows Defender than some direct one-liners.

$ scope --fleet isolated-target
$ stage --source authorized-exec
[+] configuration ready
[+] listener active
[*] deployment pending

4. Review, commit, deploy

Use the pending-change view to confirm that only the intended source and fleet are affected. Commit and deploy the controlled configuration, then observe the listener.

On the tested default installation, the Edge node service ran as LocalSystem. Deployments can be configured differently, so the resulting execution context must be verified rather than assumed.

Observations

• This is feature abuse, not an authentication bypass. The attack path begins with authorized management capability.
• Fleet boundaries are safety boundaries during testing. Isolation prevents a proof-of-concept from broadcasting across grouped nodes.
• Execution context changes impact. A default LocalSystem service makes the same management permission considerably more consequential.
• Deployment review is part of the exploit path. Product workflows can both enable and constrain what reaches the node.

Takeaway

Administrative features that intentionally execute code should be modeled as privileged execution interfaces. The security question is not simply whether the feature “works as designed,” but who can reach it, how changes are reviewed, what targets inherit them, and which identity performs the execution.

For defenders, the useful controls are tight management authorization, narrow fleet mappings, change review, deployment auditing, and a deliberately constrained service account where operationally possible.