If you have ever opened an abuse mailbox on a Monday morning, this scene will probably look familiar: hundreds of emails, each in a different format. Some include logs that have been pasted without context, others come with a PDF attachment. And mixed with all this, a truly important report that you didn’t have enough time to analyze.
The story is similar on the other side. We report an incident, receive no response, and never know whether the problem was the mailbox itself, the format, or simply that no one had time to read our message.
It must not require the use of a form to report abuse.
It must guarantee that abuse reports, logs, headers, examples, etc. relating to the case of abuse are received.
In other words, the mailbox must exist, its use is mandatory, and there is a formal requirement for someone to review the reports that are received. The problem, then, is something else.
Why a Person Cannot Handle It All
What is the problem, then? The problem is that there is no common language. Abusix, the company behind XARF, reports that it had to develop over 500 different parsers to process the reports its clients receive because each source invents its own format.
It must not require the use of a form to report abuse.
It must guarantee that abuse reports, logs, headers, examples, etc. relating to the case of abuse are received.
In other words, the mailbox must exist, its use is mandatory, and there is a formal requirement for someone to review the reports that are received. The problem, then, is something else.
Why a Person Cannot Handle It All
What is the problem, then? The problem is that there is no common language. Abusix, the company behind XARF, reports that it had to develop over 500 different parsers to process the reports its clients receive because each source invents its own format.
A free-form text report often fails to include the basics:
The date does not specify the corresponding time zone;
A source IP address without a port, failure to specify the protocol;
Evidence without a timestamp linking it to the event.
XARF: The Format Designed for This Scenario
XARF (eXtended Abuse Reporting Format) is a JSON-based format for reporting abuse maintained by the community at xarf.org. The current version, v4, organizes 32 incident types into seven categories, ranging from spam and phishing to network attacks and vulnerabilities, each with its own schema.
Version 4 requires a minimum of seven fields: the schema version, a unique identifier, the incident timestamp, the reporter, the abuse source, and the category-type pair. Be careful with the source: it refers to the offending IP or domain, not to the victim. Evidence is listed as recommended, although in practice it is what makes a report actionable. One detail is particularly useful for CSIRTs: v4 distinguishes between the ‘reporter’ (the organization that identified the abuse) and the ‘sender’ (the organization transmitting the report), specifically to accommodate scenarios where a national CERT reports on behalf of its members.
For email transmission, XARF relies on ARF (RFC 5965), a three-part multipart/report message consisting of a human-readable part, a machine-readable part, and a part containing the evidence. This allows the analyst to read the text while the system parses the JSON. No one has to choose.
Example of a DDoS attack report:
Correo electrónico:
From: Example ISP NOC <noc@example-isp.com>
To: abuse@upstream-provider.net
Subject: [XARF] ddos desde 192.0.2.100
Message-ID: <7d1e4f28-9b03-4a6c-8e51-c2f7a04b91d6@example-isp.com>
Date: Mon, 15 Jan 2024 10:00:32 +0000
1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="----=_Part_XARF_9f31a"
------=_Part_XARF_9f31a
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Automated abuse report.
Type: DDoS (UDP flood)
Source: 192.0.2.100:53
Destination: 203.0.113.50:53
First seen: 2024-01-15T09:52:00Z
Confidence: 0.95
See the attached XARF report for full details and evidence.
------=_Part_XARF_9f31a
Content-Type: message/feedback-report
Content-Disposition: inline
Feedback-Type: xarf
User-Agent: ExampleISP-AbuseReporter/2.0
Version: 1
------=_Part_XARF_9f31a
Content-Type: application/json; name="report.json"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.json"
ewogICJ4YXJmX3ZlcnNpb24iOiAiNC4yLjAiLAogICJyZXBvcnRfaWQiOiAiNTUw
ZTg0MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAwIiwKICAidGltZXN0YW1w
IjogIjIwMjQtMDEtMTVUMTA6MDA6MDBaIiwKICAicmVwb3J0ZXIiOiB7CiAgICAi
[... resto del JSON en base64 ...]
------=_Part_XARF_9f31a--
IODEF(RFC 7970) is the IETF standard for sharing security incident reports. It uses an XML format that is more detailed than XARF.
STIX and MISP are ideal for intelligence sharing between peers (e.g., indicators, campaigns, or TTPs). However, they were not designed to notify an operator that one of their customers is conducting scans or hosting phishing content.
Plain text remains valid as long as it meets the minimum information requirements: affected resource, UTC timestamp, abuse type, evidence, and a contact who can respond. A well-crafted plain text message beats a poorly structured JSON file.
What We Can Start Doing
If you are reporting an abuse: use a structured format, always include the time zone, and check the abuse-c field in WHOIS/RDAP before submitting.
If you are receiving the reports: validate your contact information when LACNIC asks you to and respond to the reports you receive.
