The useful thing about out-of-band application security testing is that it listens for the bugs that do not answer directly. A target application may not print an error, return a stack trace, or expose a visible page change. It may simply make a DNS lookup, fetch a URL, parse an external XML entity, or execute a delayed browser callback somewhere else. If the tester owns the place it calls back to, that quiet behavior becomes evidence.

4sysops highlighted Microsoft's newly open-source Dusseldorf project on July 20. The project is a private, customizable OAST platform: it captures inbound DNS, HTTP, and HTTPS traffic across a domain and its subdomains, gives operators a protected UI and REST API for reviewing captures, and lets them configure custom responses and filters. Microsoft's README frames it for security researchers, operators, developers, and platform engineers who need controlled infrastructure for validating SSRF, XSS, SSTI, XXE, and related out-of-band flaws.

test payload -> target app
                 |
                 v
          *.yourdomain.net
                 |
                 v
Dusseldorf: DNS + HTTP + HTTPS capture
             UI + API + response rules
OAST is about turning a target's external callback into observable, operator-owned evidence.

The Callback Is The Finding

Classic dynamic testing is strongest when the result comes back through the same request path. You send input, the application responds, and the scanner or tester can inspect that response. Out-of-band testing covers the awkward cases where the vulnerable behavior happens somewhere else. A server-side request forgery payload may cause the application to fetch an external URL. A blind XSS payload may execute later in another user's browser. An XML parser may resolve an external entity. A template engine may touch a network resource as a side effect.

In those cases, the callback is the signal. The security question becomes: did the system under test try to reach infrastructure controlled by the tester, and what did it send when it did? Dusseldorf's job is to receive that signal across common protocols and keep enough context around it that a human or automation workflow can decide whether it is real.

OAST is less about louder scanning and more about giving quiet bugs a place to leave receipts.

Private Infrastructure Changes The Trust Boundary

Plenty of teams already use public collaborator services, temporary domains, or hand-built callback receivers for this class of testing. That works until it does not. Application-security testing can touch sensitive URLs, internal hostnames, headers, tokens, tenant identifiers, request bodies, and timing data. Sending those callbacks through someone else's infrastructure may be unacceptable for regulated environments, private bug bashes, customer testing, or internal product security work.

Dusseldorf's core design choice is private control. The deployment guide says operators run it in their own environment, control identity integration, choose the infrastructure footprint, own the domains, and customize runtime policies. That makes the tool more than a receiver. It becomes part of the organization's security testing control plane.

  • DNS: capture name lookups that prove a target tried to resolve attacker-controlled input.
  • HTTP and HTTPS: receive callbacks with request metadata, headers, paths, and bodies.
  • Custom responses: let a test return payload-specific behavior instead of a generic endpoint.
  • Filters: help separate signal from internet background noise and repeated probes.
  • API access: makes callback evidence available to scanners, pipelines, and internal tooling.

It Is Not The Scanner

The cleanest way to understand Dusseldorf is to separate payload generation from callback capture. It does not need to be the scanner that finds every bug. It can be the infrastructure that scanners, researchers, CI jobs, red-team tools, or custom harnesses call home to. That separation is useful because different teams test different surfaces, but they all need a reliable way to answer the same question: did the application reach out?

This also makes the platform extensibility matter. Microsoft's repository describes developer paths for extending listener behavior, API features, and automation. The deployment guide points to local Docker Compose workflows for validation and Azure deployment paths using Helm. The prerequisites are operationally plain: public IPv4 address space, a domain with its nameserver pointed at the host, Docker or Docker Compose for local work, plus Azure CLI, OpenSSL, Python, jq, and Helm for the cloud path.

Those requirements are not incidental. OAST only works if the system under test can reach the listener. That means a real domain, public network paths, TLS handling, identity decisions, logging policy, and retention policy. Making that explicit is healthy. Callback infrastructure is security infrastructure, and it deserves the same operational treatment as scanners, artifact repositories, CI runners, and secrets systems.

Why This Is Useful

The value here is not that every organization should immediately deploy another security dashboard. The value is that out-of-band evidence becomes less ad hoc. A private OAST service gives application-security teams a stable callback address, central capture history, controlled response behavior, and an API surface that other tools can integrate with.

That matters because blind vulnerability classes are often messy to prove. A tester can suspect SSRF from timing or error behavior, but a captured callback with the right domain and metadata is stronger. A scanner can guess that an XML parser is resolving external entities, but a DNS and HTTP hit makes the behavior concrete. A delayed XSS callback can connect an injected payload to a later execution context. The finding becomes less speculative because the target left a network trail.

There is also a risk boundary to respect. Running OAST infrastructure means exposing listeners to the internet and collecting untrusted traffic by design. Teams need rate limits, isolation, access control, logs that do not become data spills, and cleanup rules for stale campaigns. Dusseldorf does not remove that responsibility. It gives teams a clearer place to apply it.

The Takeaway

Dusseldorf is interesting because it turns a common application-security side channel into owned infrastructure. DNS, HTTP, and HTTPS callbacks are not glamorous, but they are how many blind findings become defensible. Making that layer private, customizable, and API-addressable gives security teams a better primitive than a pile of temporary domains and one-off listeners.

For Tundrabit readers, the broader lesson is simple: good security tooling often lives in the boring boundary layer. The scanner may get the attention, but the callback plane decides whether a quiet bug can be observed, repeated, filtered, and handed to the people who need to fix it.

Sources