I’ve been working in the hacking team at Hadrian for a while now, and in that time, we’ve seen where businesses are placing their attention and resources when it comes to their cybersecurity posture. Of course, on the other hand, we’ve also seen the exposures they aren’t prioritizing.

I wanted to share a fascinating finding from a recent client engagement that serves as a great reminder about tool choice and digging into unexpected observations. It involves an SSRF, a seemingly innocuous log entry, and ultimately, administrative credentials.

The Initial Vulnerability: A Standard SSRF

Hadrian’s Orchestrator AI identified a Server-Side Request Forgery (SSRF) vulnerability in an application endpoint. This endpoint functioned as a proxy, taking a URL provided by the user and fetching its content.

Our standard approach in such cases is to attempt access to internal network resources, cloud metadata services (like 169.254.169.254), or localhost endpoints. The system tried directing the vulnerable endpoint towards these common targets, but without success. It seemed that network or application controls were preventing the SSRF from reaching internal services directly.

Shifting Focus: Analyzing the Outbound Request

Since internal pivoting wasn't working, the system flagged the issue to our team for manual investigation and we started analyzing the characteristics of the outbound request itself. Could the application be adding interesting headers or data when it made the request via the SSRF?

To check this, we set up an external listening server using Apache HTTP Server. We then triggered the SSRF, pointing the application toward my listener. When we analyzed the Apache access and error logs, we found only standard HTTP headers (User-Agent, Host, etc.) – nothing out of the ordinary or particularly useful.

A Different Listener: Trying Caddy

To ensure thoroughness and because I personally often prefer Caddy for quick setups, we decided to repeat the test using Caddy as the listener instead of Apache. I already configured Caddy for basic request handling before and, crucially, enabled JSON-formatted logging for easier parsing.

I triggered the SSRF towards my Caddy listener and checked the logs. This time, we noticed something significant that hadn't appeared in the Apache logs:

{
  // ... other standard log fields ...
  "headers": {
    "Proxy-Authorization": [
      "REDACTED"
    ],
    // ... other standard headers ...
  }
  // ... other standard log fields ...
}

‍

The presence of a Proxy-Authorization header immediately caught our attention. This header is typically meant for an intermediary proxy. Even more intriguing was that Caddy explicitly logged it as REDACTED. This suggested Caddy recognized it as potentially sensitive, unlike Apache's default logging behavior in my test.

The "Aha!" Moment: Caddy's log_credentials

That REDACTED value was the key clue. I dove into the Caddy documentation and after some time found the global log_credentials option. By default, Caddy redacts Authorization and Proxy-Authorization headers for security, whereas Apache removes them entirely. Enabling log_credentials would reveal the actual value.

I immediately modified my Caddyfile:

{
        # Global server options
        servers {
                # Disable redaction of Authorization/Proxy-Authorization headers
                log_credentials
        }
}

# Listener configuration
listener.example.com {
        log {
                output file /var/log/caddy/access.log {
                        roll_size 100mb
                        roll_keep 10
                }
                format json
        }

        respond "Request Received" 200
}

‍

I restarted Caddy and triggered the SSRF one last time.

From Redacted to Admin

Checking the Caddy logs again confirmed my suspicion. The REDACTED value was gone, replaced by the actual header content:

{
  // ... other fields ...
  "headers": {
    "Proxy-Authorization": [
      "Basic BASE64ENCODEDSTRING=="
    ],
    // ... other headers ...
  }
  // ... other fields ...
}

‍

I took the Base64 encoded string, decoded it (echo 'BASE64ENCODEDSTRING==' | base64 -d), and found plaintext credentials.

These credentials belonged to the target application environment. Testing them against the main login portal confirmed they granted administrative-level access. This discovery significantly increased the impact of the original SSRF vulnerability, providing extensive control and access to sensitive data.

Lessons Learned From This Engagement

This experience highlighted several key takeaways:

1. SSRF isn't just an internal pivot: Always consider that the vulnerable application might leak information about itself or its configuration in the requests it generates, not just provide access to other systems.
2. Apache's default logging didn't reveal the header anomaly in my setup. Caddy's explicit redaction provided the hint, and its configuration options enabled the exploit. It's a stark reminder that the tools we use, and their specific defaults, can significantly impact what we observe.
3. That REDACTED log entry wasn't noise; it was a signal. Digging into why a tool behaves a certain way (like redacting specific headers) can lead to critical findings.

It was a rewarding find that reinforced the importance of log analysis, understanding the nuances of different tools, and chasing down those oddities that just don't feel quite right.