Authorised security scanner
If traffic from one of the addresses below reached your infrastructure, it came from a security assessment that was authorised by the organisation responsible for that infrastructure.
Machine-readable: /ips.txt (one per line) · /ips.json. These are generated from the infrastructure that assigns them, so they are current rather than transcribed. If you allowlist by address, read one of those rather than this page.
Ranges, not single addresses: Azure assigns individual IPv6 addresses
out of these and they can change without the range changing, so
allowlist the range. There is no reverse DNS here — Azure
publishes none for IPv6, so a PTR lookup on a v6 source returns
nothing. Both the user-agent above and the header
X-Security-Scan: Aevyra are sent on every request over
IPv6, so an application log identifies this scanner even where a
firewall log cannot.
X-Security-Scan header above, and
-random-agent is explicitly disabledDiscovery — DNS, HTTP requests, certificates — runs against anything in an authorised scope. Port scanning and vulnerability checks are treated differently: they require a signed authorisation from the organisation that owns the systems and a separate, per-host decision to enable them. Both default to off. A scope being in the platform is not an instruction to scan it.
Contact your own security team first. The assessment is commissioned by your organisation, and they can tell you which engagement this is and whether it is in scope — faster than we can, because we will not discuss a client's engagement with a third party.
If you believe the traffic is not authorised, or you need it stopped immediately, email abuse@aevyrascan.com with the source address, the destination, and a timestamp with its timezone. We will identify the scan and stop it.
If it is authorised and the problem is alert noise rather than load, allowlist the addresses above in your detection rules rather than blocking them at the perimeter. Blocking produces a clean report of a closed door, which is the one outcome that helps nobody: your security team pays for an assessment and receives findings from a scanner that could not reach anything. If the problem is load rather than alerting, see below.
A different question from whether it should be running, and one with a straightforward answer: the rate can be lowered for your estate specifically. The limit is on how many checks run against your hosts at the same time, across every tool an assessment uses, and it can be set for a whole estate or for a named set of hosts within it — the fragile appliance, the busy origin behind a CDN, whatever is actually feeling it.
A lower limit means the same estate is covered more slowly, not less thoroughly. Nothing is skipped or sampled to make a scan quieter.
Ask your own security team to request it; they hold the engagement. If you are telling us directly at abuse@aevyrascan.com, three things let us act without a round trip: the hostname or address that is under load, the times you saw it with the timezone, and what your monitoring actually measured — concurrent connections, requests per second, or whichever threshold fired. A graph is ideal.
Worth knowing when you read those numbers: one hostname is not one server, and one server is often many hostnames. Where a CDN fronts an estate, a great many names can resolve to one edge and land on one origin, so the load a single machine feels may come from names you would not have grouped together. Telling us what the machine saw, rather than which name you expected it to come from, is what makes it actionable.