OAST stands for Out-of-band Application Security Testing. As the name suggests, it is a security testing technique that identifies vulnerabilities through Out-of-Band (OOB) interactions. While an OOB interaction itself is not a vulnerability, it's a highly effective method for triggering outbound communication from a server. This allows for the detection of blind vulnerabilities (like Blind RCE, Blind XSS, and Blind SSRF) and the exfiltration of sensitive information.

This post covers the core principles of OAST, along with its offensive and defensive techniques.

What is OAST?

OAST works by confirming vulnerabilities based on whether an interaction occurs with an external, attacker-controlled server (the OAST server). An attacker injects a payload containing a unique address of their OAST server into a location where a vulnerability is suspected. If the application processes this payload and sends a network request (e.g., a DNS query or HTTP request) to the OAST server, the attacker can detect this interaction and confirm the vulnerability's existence.

Because of this capability, OAST is a core feature in DAST (Dynamic Application Security Testing) solutions like ZAP and Burp Suite, significantly improving their detection rates.

 sequenceDiagram
    participant Attacker
    participant Target Server
    participant OAST Server

    Attacker->>+Target Server: Sends payload with OAST domain<br>(e.g., 'ping unique-id.oast.server')
    Note right of Target Server: The application executes the command,<br>triggering an out-of-band interaction.
    Target Server->>+OAST Server: DNS Query for 'unique-id.oast.server'
    OAST Server-->>-Target Server: DNS Response
    Attacker->>OAST Server: Polls for interactions
    OAST Server-->>Attacker: Reports interaction from Target Server's IP

Core Reaction Methods

DNS Reaction

The most crucial interaction in OAST is achieved through DNS. Most production environments, as a security policy, block outbound traffic from servers by default and only allow it on an exceptional basis. This is why traditional HTTP callback methods are often blocked by firewalls.

However, a DNS query isn't typically sent directly from the server to the internet. Instead, it's propagated through internal or external DNS resolvers. This process often bypasses standard outbound firewall policies, making it a reliable channel for detecting interactions even in environments with restricted outbound access.

 graph TD
    subgraph Target Infrastructure
        A[Vulnerable Application] --> B{Outbound Request};
        B -->|HTTP/HTTPS Request| C[Firewall];
        C -->|DENY Default| D[Internet];
        B -->|DNS Query| E[Internal/External DNS Resolver];
    end

    subgraph Internet
      F[OAST Server];
    end

    E --> F;
    style D stroke:#f00,stroke-width:2px,stroke-dasharray: 5 5
    style C fill:#445,stroke:#333,stroke-width:2px

HTTP/Other Reaction

If interactions using other protocols like HTTP or SMTP are observed after the initial DNS query, it indicates that outbound communication is permitted for those protocols. While a DNS interaction primarily serves to "identify" the existence of a vulnerability, subsequent HTTP or other protocol interactions are directly related to actually "exploiting" it.

This channel can be used to exfiltrate information from internal systems or to pivot to more severe threats, such as using SSRF to scan the internal network.

Offensive techniques

Protocols

OAST supports various protocols to provide testers with richer information. While DNS and HTTP are fundamental, support for other protocols can be invaluable for identifying vulnerabilities in specific environments.

• HTTP/HTTPS
• DNS
• SMTP
• LDAP
• NTLM
• SMB
• FTP
• Etc..

Provider

Various public and private OAST services exist, each with slightly different features and tool support.

Interfaces

Caido

Caido does not offer OAST functionality by default, but you can enable it using the QuickSSRF plugin. If no other OAST clients are added, I plan to create one myself, share it, and update this document accordingly.

ZAP

In ZAP, OAST functionality is available through the OAST Add-on. You can get a unique domain and poll for interactions in the OAST tab. During an Active Scan, OAST payloads are automatically generated and used for testing. ZAP supports BOAST, Interactsh, and a simple IP-based callback service.

Burpsuite

Burp Suite Professional provides OAST capabilities through its Burp Collaborator client. Like ZAP, it automatically injects Collaborator payloads during an Active Scan to detect blind vulnerabilities.

CLI interface

For the CLI environment, ProjectDiscovery's Interactsh offers the most powerful feature set. You can use the public server or set up your own self-hosted server.

@@@bash

Public server

interactsh-client

Self-hosted server

interactsh-client -server -token @@@

OAST in DAST

The process of a DAST tool utilizing OAST generally follows these steps:

1. For each scan request, a unique subdomain is generated from the OAST service (e.g., o5rglw6hawoivfmeylovdxtqji.odiss.eu).
2. A payload containing the generated domain is sent to the target to perform the test.
3. The tool polls the OAST server for a set period to check if any interactions for that domain have been received.
4. If an interaction is detected, it confirms the existence of a blind vulnerability based on that request.

Bypass techniques

Following major events like the Log4Shell vulnerability, the domains and IP addresses of public OAST services are now frequently blocked by firewalls and security solutions. To bypass this, using a self-hosted OAST server or a lesser-known service can be effective.

• Bypassing System Hardening to Detect RCE via OOB Methods
• Self-Hosted Interactsh for Private OOB Testing

Defensive techniques

From a defender's perspective, the impact of OAST attacks can be minimized through system hardening.

• Minimize Outbound Traffic: Apply a Default Deny policy for all outbound traffic from servers. Only allow connections to essential domains and ports on an allowlist basis.
• Block Known OAST Services: Block the domains and IP addresses of known public OAST services at the firewall.

Known OAST Service Address

• ZAP: *.odiss.eu
• Burpsuite: *.oastify.com, *.burpcollaborator.net
• Interactsh: *.oast.pro, *.oast.live, *.oast.site, *.oast.online, *.oast.fun, *.oast.me
• CVSS Advisor: *.c5.rs, *.ssrf.cvssadvisor.com

Tools

• 🌐 ZAP OAST (public/private)
• 🌐 Burpsuite Collaborator (public/private)
• 🌐 CVSS Advisor's SSRF (public)
• 🔒 Interachsh (public/private)
• 🔒 boast (private)
• 🔒 tuktuk (private)