Project Dusseldorf: Finding Out-Of-Band Vulnerabilities At Cloud Scale - Michael

Project Dusseldorf: Finding Out-Of-Band Vulnerabilities At Cloud Scale

Speakers: Michael Hendricks, Principal Security Engineer, Microsoft

Conference: Nullcon

YouTube: https://www.youtube.com/watch?v=6cHduLAslXY

Overview

In this insightful talk from Nullcon, Michael Hendricks, a Principal Security Engineer at Microsoft, unveiled Project Dusseldorf, an internally developed and now open-source tool designed to detect out-of-band (OOB) vulnerabilities at an unprecedented scale. Hendricks, who runs a team focused on hardware and open-source research within Microsoft Security Response Center (MSRC) and is an OWASP Seattle chapter lead, shared the motivations and technical intricacies behind this powerful platform. Dusseldorf addresses the critical challenge of variant hunting within large organizations, where a single reported vulnerability can lead to dozens or even hundreds of related security issues across a vast codebase and infrastructure.

The core problem Dusseldorf aims to solve is the efficient identification of blind vulnerabilities that manifest through network egress, such as Server-Side Request Forgery (SSRF), XML External Entities (XXE), blind Cross-Site Scripting (XSS), and Remote Code Execution (RCE). Traditional methods for detecting these often rely on manual analysis or localized testing, which struggles to keep pace with the sheer volume of code and services deployed by a cloud-scale enterprise. By providing a self-hosted, scalable out-of-band interaction platform, Dusseldorf empowers security researchers to cast a wide net, detect subtle network interactions, and confirm vulnerabilities that would otherwise remain hidden or require painstaking manual investigation.

The open-sourcing of Project Dusseldorf represents a significant contribution to the broader security community. It offers a robust, enterprise-grade alternative to existing OOB interaction tools, allowing organizations and individual researchers to conduct large-scale, private vulnerability assessments without relying on third-party services. This initiative aligns with Microsoft's commitment to empowering researchers and fostering a more secure digital ecosystem, enabling faster and more comprehensive discovery of critical vulnerabilities.

Background

▶ Watch: Introduction and open-sourcing Project Dusseldorf (0:00)

The genesis of Project Dusseldorf lies in the operational realities of a large-scale security response team like Microsoft's MSRC. When a security bug is reported, the process typically involves four key stages: fixing the vulnerability, rewarding the reporter (if eligible for a bounty), building detections to identify similar attacks in the future, and critically, variant hunting. Variant hunting is the process of identifying all other instances or variations of a reported vulnerability across an organization's vast portfolio of products and services. For Microsoft, with its immense number of servers and lines of code, a single MSRC case can often explode into dozens of individual bugs that require separate fixes, detections, and further variant hunting. This exponential scaling problem highlighted the need for an automated, efficient solution.

The project's unusual name, "Dusseldorf," follows a common internal Microsoft practice of using place names as project code names, as they cannot be copyrighted. Famous examples include "Chicago" for Windows 95 and "Anaheim" for Microsoft Edge. The team specifically sought a place name containing the letters "SSRF," reflecting the initial focus of the tool. Dusseldorf emerged as one of the few viable options, offering ease of pronunciation and recognition.

At its heart, Dusseldorf tackles the challenge of Server-Side Request Forgery (SSRF). As explained by Hendricks, SSRF occurs when an attacker can trick a server into making an arbitrary network connection to a location of their choosing. In a cloud environment, SSRF is particularly dangerous as it can allow attackers to access internal services, metadata endpoints, or other protected resources, often with the server's own authentication tokens. The talk illustrated a common SSRF scenario where an application constructs a URL based on user-supplied input (e.g., an environment parameter), allowing an attacker to inject a forward slash (%2f) to redirect the server's request to an arbitrary external domain, like evil.net.

The crucial insight that expanded Dusseldorf's scope beyond just SSRF was the realization that many other vulnerability types share a common detection mechanism: an out-of-band network interaction. Hendricks demonstrated how XML External Entities (XXE), Cross-Site Scripting (XSS) (especially blind XSS where a payload executes in a browser but doesn't immediately show a visible alert), and even Remote Code Execution (RCE) can all be detected by observing DNS lookups. For instance, an XXE payload might try to fetch an external DTD, an XSS payload could attempt to load a remote JavaScript file, and an RCE payload might execute a command that performs a curl or wget to an attacker-controlled domain. In all these cases, the first step the vulnerable server or client takes is to resolve the attacker's domain name via DNS. By listening for these DNS requests, an attacker can detect the successful execution of their payload, even if no direct HTTP response is received. This commonality formed the foundation for Dusseldorf's versatile out-of-band detection capabilities.

Key Findings

▶ Watch: The scaling challenge of security vulnerability variants (4:00)

Project Dusseldorf is presented as an enterprise-grade, self-hosted platform for detecting out-of-band vulnerabilities. Its key findings and contributions can be summarized as follows:

• Scalable Out-of-Band Interaction Platform: Dusseldorf serves as a private, highly scalable alternative to public services like Burp Suite Collaborator or Interact.sh. It allows organizations to host their own OOB interaction server, ensuring full control over data and privacy, which is crucial for sensitive internal testing.
• Multi-Protocol Egress Detection: The platform actively listens for interactions across multiple network protocols, primarily focusing on DNS, HTTP, and HTTPS. Hendricks also mentioned ongoing research into supporting SSH, SMTP, and WebSockets, indicating its potential for broader application in the future. DNS, in particular, is highlighted as the most critical for initial detection of blind vulnerabilities.
• Custom Response Capabilities: A significant feature is the ability to configure custom responses for incoming requests. This allows researchers to not only detect an egress connection but also to influence the vulnerable system further. For example, an HTTP request could receive specific headers (like Set-Cookie or Location for redirects) or a crafted body, enabling more complex attack chains or deeper reconnaissance. Similarly, DNS responses can be customized to provide specific records.
• Unlimited, Unguessable Hostnames: Dusseldorf allows for the generation of virtually unlimited subdomains (referred to as "zones"). These zones can be generated with random, unguessable strings, ensuring that any observed DNS lookup or HTTP request to such a unique hostname is a direct result of a specific payload. This eliminates false positives from DNS caching or random internet scans and provides a precise signal for successful payload execution.
• Detection of Blind Vulnerabilities at Scale: By leveraging these unique hostnames and listening for DNS lookups, Dusseldorf can reliably detect blind SSRF, XXE, XSS, and RCE vulnerabilities across a massive attack surface. Researchers can "spray" applications with thousands or millions of unique payloads, and any subsequent DNS resolution to a Dusseldorf-controlled domain immediately signals a successful interaction, even if no direct feedback is provided by the application.
• Web UI and API for Automation and Collaboration: The platform offers both an intuitive web user interface (UI) for easy setup and analysis, and a comprehensive API for programmatic interaction. The API is crucial for integrating Dusseldorf into automated security testing pipelines, enabling large-scale, scripted vulnerability scanning and variant hunting without manual intervention. The UI also supports collaboration, allowing multiple team members to share and analyze results within the same "zone."
• Internal Validation and Open Sourcing: Developed and used internally at Microsoft for approximately three years by over 130 researchers and red teamers, Dusseldorf has proven its efficacy in a demanding enterprise environment. Its subsequent open-sourcing allows the broader security community to benefit from this battle-tested tool.

Technical Deep Dive

▶ Watch: The origin of 'Project Dusseldorf' name (4:20)

Project Dusseldorf's architecture is designed for scalability, flexibility, and ease of use, comprising several key building blocks. The entire application is primarily written in Python, ensuring readability and maintainability.

At its core, Dusseldorf features a set of listeners. These Python-based components are responsible for actively monitoring network traffic across various protocols. Currently, the primary listeners support:

• DNS: Crucial for detecting the initial resolution of attacker-controlled hostnames, which is often the first indication of a blind vulnerability.
• HTTP: For receiving standard web requests.
• HTTPS: For secure web requests, requiring a wildcard TLS certificate.

Hendricks also mentioned ongoing internal research into supporting additional protocols such as SSH, SMTP, and WebSockets, which could further expand the tool's utility.

Integrated within these listeners is a rule engine. This powerful feature allows users to define custom logic for how Dusseldorf should respond to incoming requests. For example, a rule can be configured to detect an HTTP PUT request and respond with specific headers (e.g., Date: yesterday) or a customized response body. This capability moves beyond simple detection, enabling more interactive exploitation scenarios, such as setting cookies, forcing redirects, or delivering staged payloads. For DNS, custom responses can include specific A, CNAME, or TXT records.

All incoming requests and their associated metadata are stored in a persistent storage backend. Internally at Microsoft, this leverages Cosmos DB for its global scalability and performance. However, for self-hosted instances, Dusseldorf supports MongoDB, providing a robust and fast database solution. The data is stored in an open format, giving users full visibility and control over their collected information.

To facilitate interaction, Dusseldorf provides both a Web UI and an API.

• The Web UI, built with React and Microsoft's Fluent UI framework, offers an intuitive interface for setting up domains, managing zones, creating rules, and analyzing incoming requests. It simplifies complex configurations, making the tool accessible to a wider range of users.
• The API is critical for automation and integration into existing security pipelines. It allows researchers to programmatically create zones, deploy payloads, and query for interactions at scale, eliminating the need for manual clicks in the UI for repetitive tasks.

The functional aspects of Dusseldorf are structured around four core building blocks:

1. Domains: This is the top-level entity, representing the user's primary "evil.net" domain. Setting this up involves configuring DNS NS records to point to the Dusseldorf server's IP address and, for HTTPS, deploying a wildcard TLS certificate. Hendricks noted that some domains, like .ms (Monserrat), might even require two IP addresses for policy-driven high availability.
2. Zones: These are subdomains created under the main domain (e.g., test.evil.net). The genius of Dusseldorf lies in its capacity for unlimited subdomains. Each DNS field can be up to 63 characters long, and with a character set of 37 (lowercase alphanumeric and dash), even a six-character subdomain allows for 2.5 billion unique combinations. This vast address space enables the generation of unguessable hostnames. By creating a unique, random subdomain for each payload (e.g., zzs99.a.evil.net), researchers can ensure that any observed DNS lookup to that specific, never-before-used hostname is a direct and unambiguous signal of their payload's execution. This approach effectively bypasses DNS caching issues and provides high-confidence detection even when "sloppily" spraying many payloads.
3. Requests: Every network interaction (DNS query, HTTP request, HTTPS request) received by the Dusseldorf server is captured and stored as a "request." This includes all relevant data, such as source IP, headers, body, and timestamps. This persistent logging ensures that even delayed or blind interactions are recorded and available for analysis long after the initial payload execution.
4. Rules: These define conditional responses based on the characteristics of an incoming request. Rules can be configured with filters (e.g., HTTP method is PUT, contains specific header) and then specify the desired response (e.g., add header, send custom body). This allows for dynamic interaction with the vulnerable system, enabling more sophisticated testing scenarios like triggering CORS preflight responses or delivering multi-stage RCE payloads.

The workflow for using Dusseldorf involves creating a zone, generating unique subdomains within that zone, embedding these subdomains into various payloads (e.g., XSS, SSRF, RCE), and then monitoring the Dusseldorf UI or API for incoming requests. A successful hit on a unique subdomain provides a clear indication of a vulnerability, which can then be further investigated and confirmed. This highly scalable and precise detection mechanism is a cornerstone of Dusseldorf's effectiveness in variant hunting and large-scale vulnerability discovery.

Demo / Proof of Concept

▶ Watch: Understanding Server-Side Request Forgery (SSRF) (6:00)

Michael Hendricks provided a practical demonstration of Project Dusseldorf's capabilities, emphasizing its user-friendly interface and collaborative features.

The demonstration began by showcasing the simplicity of creating a zone. Users are presented with a straightforward web UI, where they can click one of two prominent "Create Zone" buttons. They then simply provide a desired subdomain name (e.g., nullcon.dusseldorf.net), and the system provisions it, making it immediately ready to receive interactions. Hendricks highlighted that this process bypasses the complexities of manually setting up DNS servers and web hosts.

Next, the talk illustrated how requests are captured and displayed. When a payload containing a Dusseldorf-controlled hostname (e.g., nc25.dusseldorf.security.azure.ms) is triggered—whether by a ping command (which resolves the hostname via DNS), an HTTP request, or any other network egress—the Dusseldorf server records the interaction. The UI then populates with these incoming requests, showing details like the source IP address and the requested hostname. Clicking on an individual request reveals its full details, including HTTP headers, body, and other metadata, which are persistently stored until the zone is deleted.

A key aspect of the demo was the power of custom rules. Hendricks demonstrated how to create a rule that responds differently based on the HTTP method. For instance, a rule was set up to respond to a PUT request with an additional Date header (ironically, revealing a small bug in the demo where two Date headers were sent). This capability allows researchers to craft specific responses that can further exploit or interrogate a vulnerable system, such as setting cookies, issuing redirects, or providing tailored content for shell commands. The UI makes it easy to define these filters and responses without writing code.

Collaboration is another strong point, as demonstrated by the ability to add other users to a zone. Within the same Azure tenant, users can invite colleagues by typing their email or username. Different roles can be assigned:

• Read-only: Can view requests and responses.
• Read-write: Can create rules and manage settings.
• Owner: Has full administrative control, including deleting the zone.

This feature streamlines team-based vulnerability research, allowing multiple individuals to contribute to and analyze findings simultaneously.

Hendricks also detailed the requirements for self-hosting Dusseldorf:

• A machine with a public IP address.
• Open firewall ports for DNS (53), HTTP (80), and HTTPS (443).
• An NS record configured for the chosen domain to point to the Dusseldorf server's IP.
• A wildcard TLS certificate for HTTPS, which is essential to secure all dynamically generated subdomains. He mentioned that services like Let's Encrypt can provide these.

He humorously recounted discovering that certain domains, like .ms (for Montserrat), require two IP addresses for NS records due to high-availability policies, a detail learned during the setup for Nullcon.

To allow attendees to immediately experiment with the tool, a live instance for Nullcon 2025 was set up at nullcon25.dusseldorf.security.azure.com (for the UI) and nc25.dusseldorf.security.azure.ms (as the data plane/evil.net domain). Attendees were invited to sign up by sending an email to Michael Hendricks (me@microsoft.com) with "nullcon 2025" in the subject, after which they would receive an invitation to the Azure tenant. This hands-on access underscored the project's readiness for community adoption and testing. Crucially, Hendricks emphasized that no telemetry is sent back to Microsoft from self-hosted instances, ensuring user privacy and control over their testing data.

Defensive Implications

▶ Watch: SSRF's impact on cloud security and project's goal (6:30)

While Project Dusseldorf is primarily an offensive security tool designed for finding vulnerabilities, its underlying principles and capabilities offer significant defensive implications for security teams and organizations. Understanding how such tools operate can empower defenders to improve their security posture in several ways:

1. Proactive Vulnerability Discovery: Defenders can leverage Dusseldorf to proactively test their own applications and infrastructure for out-of-band vulnerabilities. By integrating Dusseldorf into internal security testing, CI/CD pipelines, or red team exercises, organizations can identify blind SSRF, XXE, XSS, and RCE vulnerabilities before attackers do. This shifts security from a reactive to a proactive stance, significantly reducing attack surface.

1. Enhanced Variant Hunting: For large enterprises, variant hunting is a critical defensive task. Dusseldorf provides an industrial-strength platform for this. When a vulnerability is discovered in one component, security teams can use Dusseldorf to quickly and comprehensively scan their entire codebase and deployed services for similar patterns. The ability to generate unlimited, unguessable subdomains allows for highly confident detection of even subtle variants across a vast ecosystem.

1. Improved Egress Filtering and Monitoring: The core mechanism of Dusseldorf relies on detecting unexpected outbound network connections (egress). Defenders can learn from this by:

• Implementing strict egress filtering: Knowing that OOB attacks rely on external communication, organizations should enforce strict firewall rules that only permit necessary outbound connections from internal systems.
• Monitoring DNS logs: Anomalous DNS queries from internal servers to suspicious or unknown domains can be a strong indicator of compromise or successful OOB exploitation. Defenders should actively log and analyze DNS traffic for unusual patterns, especially queries to recently generated or obscure domains.
• Monitoring HTTP/S proxy logs: Similarly, unexpected HTTP/S connections to external endpoints should be flagged and investigated.

1. Understanding Attack Techniques: By operating or experimenting with Dusseldorf, security teams gain a deeper understanding of how OOB attacks are orchestrated. This knowledge can then be applied to:

• Develop more effective detection rules: Knowing what an OOB interaction looks like at the network level helps in creating better intrusion detection system (IDS) and security information and event management (SIEM) rules.
• Design more resilient applications: Understanding the common points where SSRF, XXE, and blind XSS emerge can guide developers in building more secure code, implementing proper input validation, and sanitizing user-controlled data that might influence network requests.

1. Private and Controlled Testing: The self-hosted nature of Dusseldorf is a significant defensive advantage. Unlike public OOB services where sensitive tokens or internal information might inadvertently be leaked to a third party, Dusseldorf allows organizations to keep all testing data within their own controlled environment. This is paramount for maintaining data privacy and compliance during security assessments.

In essence, Project Dusseldorf, while an offensive tool, provides a blueprint for robust defensive strategies. By using it for internal assessments and understanding its operational mechanics, defenders can fortify their systems against the very types of sophisticated, blind attacks it is designed to uncover.

Key Takeaways

• Project Dusseldorf is an open-source, scalable out-of-band (OOB) interaction platform developed by Microsoft to detect blind vulnerabilities like SSRF, XXE, blind XSS, and RCE.
• It addresses the challenge of "variant hunting" in large organizations, enabling efficient discovery of widespread security issues stemming from a single reported bug.
• The tool primarily leverages DNS lookups as the first signal of a successful payload execution, offering high-confidence detection even when no direct HTTP response is received.
• Dusseldorf features unlimited, unguessable subdomains (zones), allowing researchers to generate unique hostnames for each payload, which helps in bypassing DNS caching and precisely attributing successful interactions.
• Custom response capabilities for HTTP and DNS enable more advanced exploitation and reconnaissance by allowing the server to deliver specific headers, bodies, or DNS records.
• It offers both a web UI and an API for ease of use, automation, and collaboration among security researchers, making it suitable for both manual and large-scale automated testing.

About the Speaker(s)

Michael Hendricks is a Principal Security Engineer at Microsoft. He leads a team within the Microsoft Security Response Center (MSRC) that focuses on research in hardware and open-source technologies. Beyond his work at Microsoft, Michael is also actively involved in the security community as one of the chapter leads for OWASP in Seattle. During his presentation, he noted that he represents the collective effort of the team internally known as the "Dusseldorf Dorks," highlighting the collaborative nature of the project. His expertise spans dynamic security testing and large-scale vulnerability discovery in cloud environments.