Out-of-band callback collector
If a system you are responsible for made a DNS query or an HTTP request to a name under oast.aevyraecho.com, it did so because a security assessment — authorised by the organisation responsible for that system — supplied input which your system then acted on.
Some classes of vulnerability produce no visible response. A server-side request forgery, a blind SQL injection, a template or log lookup that dereferences attacker-supplied text, a stored cross-site scripting payload — each can execute perfectly and return a page identical to the one a normal request returns. The only way to tell whether the input was interpreted is to make the interpretation itself observable, so the test supplies a unique, single-use hostname under oast.aevyraecho.com and then waits.
Nothing reaches this collector unless something resolved or requested that hostname. It is not a beacon and it cannot be triggered by accident: the name is random, exists for one test, and is never published or linked anywhere.
Your system contacting us is the finding. It is evidence that input supplied from outside was parsed and acted on by something inside your estate. Expect it in the assessment report as a confirmed out-of-band interaction, with a timestamp and protocol matching what you are looking at now.
Blocking the callback hides the symptom and leaves the cause. The vulnerability is in the system that made the request, not in the name it resolved.
These are destinations, not sources — the opposite direction from an allowlist of scanner addresses. Machine-readable: /echo.txt (one per line) · /echo.json. Generated from the infrastructure that assigns them, so they are current rather than transcribed.
Whatever your system sends. For a DNS query that is the resolver's source address, the timestamp and the queried name; for an HTTP request it is also the request line, the headers and the body. A payload proving it can move data out will move some, so that data arrives here too — which is why the retention window is short and the host holds nothing else.
v=spf1 -all and a
p=reject DMARC policy, so a message claiming to come
from it is a forgeryContact your own security team first. The assessment is commissioned by your organisation, and they can tell you which engagement it belongs to and whether the affected system is in scope — faster than we can, because we will not discuss a client's engagement with a third party.
If you are triaging it yourself, the useful next step is to find which of your systems made the request and what input it was processing at the time. That is the vulnerability. The callback is only how it became visible.
Email abuse@aevyrascan.com with the callback hostname, the source address inside your estate, and a timestamp with its timezone. We will identify the test that created that hostname and stop it.
If you believe the interaction was not authorised, say so in that message and it will be handled as an incident rather than as a request.