---
title: DNS query to OAST/callback-domain infrastructure
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > OOTB Rules > DNS query to OAST/callback-domain
  infrastructure
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# DNS query to OAST/callback-domain infrastructure
Classification:attackTactic:[TA0010-exfiltration](https://attack.mitre.org/tactics/TA0010)Technique:[T1048-exfiltration-over-alternative-protocol](https://attack.mitre.org/techniques/T1048) 
## Goal{% #goal %}

Detects a DNS query to a known out-of-band application security testing (OAST) or callback-domain service. This activity can indicate exploitation of a blind SSRF, XXE, or RCE vulnerability, but can also result from authorized testing or defensive canary tokens.

## Strategy{% #strategy %}

This rule monitors DNS queries where `@ocsf.query.hostname` matches a known OAST or callback-domain provider, such as `burpcollaborator.net`, `oastify.com`, `oast.*`, `canarytokens.com`, `bxss.me`, or `pipedream.net`.

OAST services provide attacker- or tester-controlled subdomains to embed in injection payloads, such as SSRF parameters, XXE entity references, or JNDI lookups. If an application resolves the subdomain, the OAST service records the DNS callback. This callback can reveal an interaction even when the application returns no response to the original request or logs no distinctive scanner activity.

Authorized vulnerability scans and penetration tests also generate these queries. Defensive canary tokens can trigger similar DNS activity.

## Triage and Response{% #triage-and-response %}

- Identify the source host at `{{@ocsf.src_endpoint.ip}}` and determine what service or application is running on it.
- Check whether the queried domain at `{{@ocsf.query.hostname}}` corresponds to a known, authorized penetration test, red team engagement, or bug bounty program.
- Determine if the domain is a canary token that the organization itself deployed defensively as a tripwire, rather than an attacker-controlled indicator.
- Review recent inbound HTTP and application logs for the host around the same time window for injection patterns, such as SSRF, XXE, JNDI/Log4Shell, or insecure deserialization, that would explain an out-of-band callback confirmation.
- Determine what public-facing service is exposed on the source host and whether it has any known unpatched vulnerability capable of triggering a blind out-of-band DNS interaction.
- Examine whether the same source host has queried multiple distinct OAST/callback domains or repeated the query for the same hostname, which can indicate automated scanning rather than a one-off manual test.
- Isolate the host and capture forensic artifacts if the activity cannot be attributed to authorized testing.