False positive using Nuclei OOB DNS?

[aphroph]

Hello,

Good day. Anyone has experience when testing OOB DNS with Nuclei? I hosted my own interactsh server and client. The target is vulnerable to OOB DNS using nuclei tool and configure my hosted interactsh server/client and it is working as I am receiving DNS [d3u70klndrldsdis0ql04xpfjo88h1hdg] Received DNS interaction from xxx.xxx.xx.xxx at 2025-10-25 14:38:12 / [external-service-interaction:word-1] [http] [info] http://xx.xxx.xxx.xx.

Using default Nuclei settings using interactsh server oast.com also works. However replicating it using curl or manual method it doesn't work. Is this false positive?

Thank you

[aphroph]

Just an additional information, it maybe nuclei is doing a dig / nslookup reason why interaction is showing up in my interactsh-client. Seems initiated by Nuclei attackers side but not the target as it is reproducible only using Nuclei.

[bad-antics]

This isn't necessarily a false positive — it depends on the specific template and what's triggering the DNS lookup. Here's how to determine if it's real:

Why nuclei detects it but manual curl doesn't:

1. Nuclei templates use unique OOB tokens per request — the {{interactsh-url}} placeholder generates a unique subdomain for each test. When the target resolves that domain, interactsh catches it. The key question is: who is making the DNS query?

2. Common legitimate triggers (NOT the target):

   • Your DNS resolver caching/forwarding the query
   • WAF/IDS on the target network inspecting and resolving URLs in your payload
   • Proxy servers between you and the target
   • Antivirus/EDR on the target scanning the payload content

3. How to confirm it's real:

# Run with -debug to see the full interaction chain
nuclei -u http://target -t template.yaml -interactsh-server your-server -debug

# Check the interaction source IP
# If the DNS query comes from the TARGET's IP = likely real
# If it comes from your resolver or a CDN IP = likely false positive

4. Why curl doesn't reproduce it:

   • The template may inject the interactsh URL into a specific parameter/header that triggers async processing on the server side (queued jobs, webhook callbacks, PDF generators, email notifications, etc.)
   • curl with a simple GET won't trigger the same code path
   • Try replicating the exact nuclei request — check the template to see where it injects the OOB URL

5. To verify manually:

   • Look at the template YAML to see the exact injection point
   • Replicate that exact request with curl including all headers/params
   • Check your interactsh server logs for the source IP of the DNS query

If the DNS lookup is coming from the target server's IP, it's a true positive. If it's from your own resolver or a third-party, it's a false positive caused by intermediate infrastructure resolving the domain.

[aphroph]

Hello,

Thanks for your suggestions, but yes this is a false positive issue and has been fixed already.

Details here:
https://github.com/projectdiscovery/nuclei/issues/6613#issuecomment-3538128152
https://github.com/projectdiscovery/nuclei/pull/6614

Best regards