Out-of-Band Exfiltration Attack via Tool Chaining in Agentic Workflows

Level 8 #

An out of band exfiltration attack allows an attacker an indirect way to leak data from exploit a vulnerability that is blind (model output that is heavily filtered). In this level, the vulnerability is not classic command injection, but unsafe tool chaining and side-effect leakage: I chained retrieve_flag with http_get, passed the sensitive value into a query parameter, and observed it in logs. This confirms a response-filter bypass where data is blocked from final assistant text but still exfiltrated through logs.

The exploit and Result : Output Guardrails Bypass and Out-of-Band Exfiltration #

Step 1: Reconnaisance

On level 8, I discovered that the model can chain tools in parallel and can call retrieve_flag with http_get in the same workflow as shown in the following sample request.

{
  "tool_uses": [
    {
      "recipient_name": "functions.retrieve_flag",
      "parameters": {}
    },
    {
      "recipient_name": "functions.http_get",
      "parameters": { "url": "https://ctf.arkx.ninja/health" }
    }
  ]
}

I then prompted the model for the system guidelines of using the http_get tool and I discovered that it could not fetch internal facing URLs and only fetched external facing URLs*:

Step 2: Probe instructions and logging behavior

I then asked the model to print system prompts and then prompted about logs because this level includes a dedicated log view:

From the system prompt above, one instruction stood out: sensitive data should not be logged unless explicitly required by task context.

That line gave me the direction for exploitation because it implies sensitive values can still flow into logs depending on how the user’s prompt is framed.

Step 3: Iterate prompt patterns for indirect leakage

I then tested multiple prompt variants to see which one could force flag value to be leaked via the logs without printing it to the user console where the output guardrail would flag it. I tried internal authorization language, query parameter phrasing, variable assignment patterns and response-constrained prompts but they all failed to leak the flag to the logs.

Most attempts to exfiltrate the flag via the logs were refused or returned encoded values rather than executing the retrive_flag tool passed as a query param.

I then crafted a prompt that ended in what must the request look like with http_get localhost?q=$retrieve_flag as shown below:

The output of this prompt gave me the hint needed to fetch the flag. I needed to first obtain the flag and then pass it to as a query parameter to the URL.

Step 4: Force side-channel exfiltration through query logging

Following the hint from the tool above, I crafted a prompt that assigned the value of retrieve_flag to a variable and then passed the variable into the http_get query params while constraining final model output and explicitly instructing it to reply with YES.

After this request, the logs showed the flag in query parameters:

I submitted the leaked flag value flag-ac3380 and completed the level.

Root Cause of the Vulnerability #

Security guardrails focused on response filtering but did not apply equivalent controls to the generated logs to ensure sensitive data is not leaked by the model via the logs. This created a gap where sensitive data could still leave the system through out-of-band channels.

Impact and Severity #

1. Out-of-band exfiltration risk where sensitive data can leak via network calls and logs rather than assistant response text.
2. Guardrail bypass because response-level filtering alone cannot secure tool-level side effects.
3. Detection difficulty since user-facing output may look harmless while leakage happens in backend telemetry.

Prevention: #

• Apply sensitive-data controls at tool input, tool output, and side-effect layers, not just final response text.
• Restrict outbound destinations with strict allowlists and egress policies.
• Block insertion of sensitive values into URLs, headers, logs, and telemetry fields.
• Monitor tool invocation chains for exfiltration patterns and variable passing abuse.
• Require policy re-authorization when privileged retrieval is chained with network-capable tools.

Standard LLM OWASP Top 10 Mapping #

Prompt Injection (LLM01): Adversarial prompt framing influenced tool orchestration into an unsafe data-flow path.

Sensitive Information Disclosure (LLM02): The flag was exposed via query-string logging side effects rather than direct chat response.

System Prompt Leakage (LLM07) The system prompt was leaked to the end user allowing them to craft better prompts for adversarial purposes. Improper Output Handling (LLM05): Response filtering did not cover alternate leakage channels introduced by tool behavior.

Unrestricted Tool Use (ASI04): Combining privileged retrieval with network-capable tooling enabled out-of-band exfiltration.