The default interactsh servers can rotate, and the page tells you to self-host

You generate a hostname and wait for someone to call it

The one line definition is that interactsh is an open source tool for detecting out-of-band interactions, designed to detect vulnerabilities that cause external interactions. In practice the client generates a unique payload hostname and then reports what came back. The page's own default run shows the shape of the output, with one payload listed for OOB testing and then interactions arriving against it:

[INF] Listing 1 payload for OOB Testing
[c23b2la0kl1krjcrdj10cndmnioyyyyyn] Received DNS interaction (A) from 172.253.226.100 at 2021-26-26 12:26

The interaction types the server handles are DNS, HTTP(S), SMTP(S) and LDAP, with IPv4 and IPv6 support, and a DNS interaction is reported per record type, so an A lookup and an AAAA lookup arrive as separate lines. The page also notes the default run keeps interaction information minimal in the output, which is a deliberate choice for a tool where the payload string may end up pasted into a report.

The default server list is infrastructure you do not control

Out of the box the client talks to six public servers, and the page is direct about the risk. The maintained list is oast.pro, oast.live, oast.site, oast.online, oast.fun and oast.me, and the sentence underneath says default servers are subject to change, rotate or go down at any time, so a self-hosted server is recommended if you hit problems. The flag that changes this is -server, which accepts a single server or several separated by comma:

interactsh-client -server hackwithautomation.com

For a server protected with authentication there is a second flag:

interactsh-client -server hackwithautomation.com -token XXX

So there are three ways to be hosted: the shared public servers, your own open server, and your own server with a token. The choice is not about features, which the page ties to self-hosting in general, but about whether the endpoint your payload points at will still exist tomorrow.

Session files and verbose mode cover long tests

Two flags exist for tests that do not fit in one terminal session. The session file flag, -sf and -session-file, stores and reads the current session information from a user defined file, which the page says is useful to resume the same session and poll interactions even after the client gets stopped or closed:

interactsh-client -sf interact.session

Verbose mode is the other one, and it is for evidence rather than for monitoring. Run in verbose mode, the client shows the whole request and response and writes an output file to analyse afterwards:

interactsh-client -v -o interactsh-logs.txt

The sample output for that mode shows an HTTPS interaction followed by a request dump beginning with an HTTP Request heading. Together these two flags are the difference between a client you can leave running for a long scan and one you cannot, which is why they are the two worth remembering before anything else on the page.

Self-hosting is where most of the feature list lives

The feature list has two halves and only the first half applies to the public servers. Always available: DNS, HTTP(S), SMTP(S) and LDAP interaction, IPv4 and IPv6, the CLI, web, Burp, ZAP and Docker clients, AES encryption with zero logging, automatic ACME based wildcard TLS with auto renewal, DNS entries for the cloud metadata service, dynamic HTTP response control and a self-hosted server option. Self-hosted only: multiple domain support, an NTLM, SMB, FTP(S) and RESPONDER listener, wildcard and protected interactions, customizable index and file hosting, client file hosting for second stage OOB payloads, customizable payload length and a custom SSL certificate. Read that as a pricing of convenience. The public service gives you a working channel in one command; everything about owning your own domain, certificates and extra protocols sits on the other side of that line.

The client asks for a ProjectDiscovery Cloud key by default

The flag block is short and one default deserves attention. Alongside -server and -file there is -config pointing at a configuration file under $HOME/.config/interactsh-client/config.yaml, -number for how many payloads to generate, which defaults to 1, and -auth, described as configuring the ProjectDiscovery Cloud, or pdcp, API key, and defaulting to true:

Flags:
INPUT:
   -s, -server string   interactsh server(s) to use (default "oast.pro,oast.live,oast.site,oast.online,oast.fun,oast.me")
   -fl, -file string[]  local file(s) to upload and host on the interactsh server

CONFIG:
   -config string                           flag configuration file (default "$HOME/.config/interactsh-client/config.yaml")
   -auth                                    configure projectdiscovery cloud (pdcp) api key (default true)
   -n, -number int                          number of interactsh payload to generate (default 1)

A free key comes from signing up at cloud.projectdiscovery.io, and it can be set either interactively with `./interactsh-client -auth` or inline with `./interactsh-client -auth=<pdcp-api-key>`.

The page says go1.20 while go.mod says 1.26

Here is a discrepancy worth knowing before you hit it. The installation section states that the Interactsh CLI client requires go1.20 or later to install successfully, and the install command is a normal Go tool install:

go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest

The module file disagrees. go.mod declares the module as github.com/projectdiscovery/interactsh with a Go directive of 1.26.0, which is far above the documented floor. So a machine on an older Go that satisfies the page's requirement can still fail to build, because the module itself now requires a newer toolchain. That is a normal consequence of a pre-1.21 style go directive being raised over time, and it means the documented minimum is a floor for the client as it was written, not for the module as it stands today.

One module, thirty five direct dependencies

go.mod lists thirty two direct requirements for a project that ships a client and a server. The ones that explain the feature list are readable: miekg/dns for the DNS listener, caddyserver/certmagic for the ACME based wildcard TLS with auto renewal, emersion/go-smtp for SMTP, projectdiscovery's own asnmap, goflags, gologger, ldapserver, retryabledns, retryablehttp-go and utils, plus goftp.io/server, libdns and Mzack9999/goimpacket for the other protocol listeners. Storage appears three times over, with redis, goleveldb and miniredis for tests. The consequence is that the client and the server share a module, so installing the client still resolves the server's protocol and storage dependencies. The repository layout follows the same split, with cmd/, internal/ and pkg/ for the code, deploy/ for deployment, examples/client.go for library use and a .goreleaser.yml for builds.

Four clients share one interaction stream

The page treats the client as one of several ways to read the same interactions. The feature list names a CLI, web, Burp and ZAP client plus a Docker client. The web client, interactsh-web, is called out separately as free and open source, displaying interactions in a dashboard in the browser and using the browser's local storage to store and show everything that arrives, which means the data stays in the browser rather than on a server. It defaults to oast.fun as its interactsh server and also accepts other self-hosted public or authenticated servers. For notifications there is an integration with projectdiscovery/notify, which pipes client output into a notifier:

interactsh-client | notify

The homepage of the project is app.interactsh.com, so there is also a hosted interface to compare the self-hosted dashboard against.

Editorial conclusion

interactsh fits a security tester who needs a callback channel to confirm a blind vulnerability and who can run a domain with wildcard TLS, because the public servers are explicitly described as rotatable and the self-hosted path is what unlocks the extra listeners, protected interactions and second stage payload hosting. It does not fit a CI job that needs a stable, guaranteed endpoint without operating that infrastructure itself. Before you rely on it, read the flag list, because the client enables ProjectDiscovery Cloud authentication by default and expects an API key, and check the toolchain: the page says go1.20 or later while go.mod declares a much newer Go directive, so build failures on an older Go are expected rather than surprising.

Frequently asked questions

Official sources

1. License: MIT
2. projectdiscovery/interactsh on GitHub
3. Project website
4. README
5. Releases