Reference

Methodology

how the data is produced

Abuse Radar publishes sanitized indicators from monitored infrastructure. It is built to help defenders prioritise, without disclosing private collector detail. This page states what the data is, how it is derived, and what it does not claim.

What is published

IP address, public reason label, first and last observation, detection count, contributing sensor count, status, approximate geolocation with ASN, and blocklist window.

What is removed

Raw logs, usernames, passwords, hostnames, mailboxes, real sensor names, request payloads and any internal infrastructure detail. Sensor names shown anywhere on this site are anonymised labels, not hostnames.

How risk is scored

A 0–100 triage hint, computed from four components. Every per-address report shows the breakdown, so the number can always be taken apart.

Detection volumeup to 45

Sensor corroborationup to 20

Signal classup to 18

Recencyup to 20

Lifecycle

Records with no new observation for 30 days become archived and drop out of the blocklists. Low-value archived records are purged after 180 days. Leak-trap signals are retained longer because they indicate exposed address data rather than a transient scan.

Signal types

Each indicator carries one reason code. These are the codes the platform accepts and what each one means.

Repeated authentication failuresRepeated failed logins from the same IP. This is commonly seen during password spraying or scripted login attempts.

Automated credential guessingAutomated attempts to guess valid usernames or passwords against a protected service.

Suspicious network scanningNetwork probing that matches scanner-like behavior. Treat this as an early warning signal.

Suspicious mail authentication attemptsSuspicious mail authentication attempts against monitored mail infrastructure.

Suspicious SSH authentication attemptsSuspicious SSH authentication attempts against monitored systems.

Leak trap address contactedA monitored leak-trap address was contacted. This suggests the sender may be using exposed or scraped address data.

Possible credential list abuseActivity resembles use of leaked credential material or exposed identity data.

Abuse of monitored exposed addressA monitored exposed address was abused or contacted unexpectedly.

Abuse pattern detectedBehavior matched an abuse pattern observed by monitored infrastructure.

Sensitive file probing over HTTPRequests for files that exist only to be stolen - .env, .git internals, configuration and database backups. A web sensor reports this after several distinct such paths from one address, never after a single 404.

Known exploit path probing over HTTPRequests aimed at a specific known vulnerability, such as a PHPUnit eval endpoint or a router administration form. The request was made; nothing here says it worked.

Path traversal attempted over HTTPA request target containing directory traversal, including percent-encoded and double-encoded forms, after normalisation.

Suspicious web authentication attemptsRepeated failed authentication against a web login endpoint from one address, above the measured threshold for that sensor.

Automated web path enumerationOne address requesting many distinct non-existent paths in a short window - the shape of an automated scanner rather than a person.

Limitations

These are the claims this data does not support. They matter as much as the rules above.

The score is not an attribution claim. It ranks how strongly this platform observed an address, not who was behind it or what they intended.
Geolocation is approximate and provider-derived. On the dashboard map, country markers sit at a country-level mean of observed coordinates, not at an attack origin, and some coordinates cannot be represented at that map's resolution at all.
Absence is not innocence. An address missing from the feed means these sensors did not observe it — nothing more.
A quiet sensor is not a broken one. Collector liveness and observation activity are tracked separately, and are described on sensors.
Counts are cumulative, not a time series. Detection counts accumulate on a record, so no per-hour detection history exists and none is shown.

Time handling

All timestamps are stored and compared in UTC. The API returns exact UTC ISO-8601 values; the interface renders them in Asia/Kuala_Lumpur (GMT+8) with relative age as a secondary hint, never as the only value.

Corrections

Network owners can submit a delist request. Submitting a request does not automatically remove an indicator; it queues it for review by a person. An address also leaves the blocklists on its own once it stops being observed, under the lifecycle rules above.