Extensions to the IODEF-Document Class for Reporting Phishing
Extracted elements (28)
A common phishing report format is justified because as the number of data-sharing parties increases, party-specific tools and formats overwhelm investigative capacity; a common format enables automation of analysis tasks and significantly speeds response and prosecution.
Rather than defining a new report format, this specification extends IODEF (RFC 5070), enabling more rapid adoption, reuse of existing tools, and leveraging IODEF's flexible and extensible data model without duplicating structures already defined there.
The IODEF iodef:System element was copied into the phishing schema rather than directly extended because RFC 5070 defined it with an anonymous type that cannot be extended in XML Schema; the copy was given a named type to allow extension.
The SameDomainContact element allows reuse of contact information already reported for another domain, avoiding redundant data entry when a registrar returns identical registrant data for multiple domains in the same phishing campaign.
The IODEF extensions defined in this document comply with the extension procedure in Section 5 of RFC 5070; PhraudReport is embedded in Incident.EventData.AdditionalData with dtype='xml', and no new variable types or encodings are introduced to the base IODEF data model.
A fraud activity report MUST pass XML validation using both the base IODEF schema defined in RFC 5070 and the phishing extensions schema defined in Appendix A of this document.
Attributes and elements identified as required in figures 6.1 and 6.2 SHALL be populated in conforming phishing activity reports; these include IODEF Incident mandatory fields plus PhraudReport's FraudType, Version, LureSource (with iodef:System), and OriginatingSensor (with DateFirstSeen and iodef:System/Node).
If the real IP address of a LureSource system can be ascertained it should be populated; a spoofed address may also be entered with the spoofed attribute set on the iodef:System element to indicate it did not actually originate the activity.
Implementations SHOULD support SHA-1 as the DigestMethod when providing the ds:Reference cryptographic hash of malware included in the IncludedMalware element.
The originator of a PhraudReport SHOULD include any information gleaned from the attack analysis beyond the mandatory minimum, as additional data may be volatile, non-recoverable, and useful for investigation or correlation with other reported events.
The underlying message format and transport protocol used to exchange PhraudReport instances MUST ensure the appropriate degree of confidentiality, integrity, and authenticity for the specific environment.
Fraud report lifecycle is managed via the IODEF Incident ext-purpose attribute: empty or 'create' denotes a new report, 'update' indicates revision, and 'delete' signals removal. These are advisory markers; operating procedures for the report lifecycle are environment-specific.
PhraudReport is an XML extension element embedded within IODEF Incident.EventData.AdditionalData (dtype='xml') that encodes phishing and fraud event data. It requires FraudType and Version attributes plus at least one LureSource and OriginatingSensor child element; all other sub-elements are optional.
The ArchivedData element holds or points to forensic copies of phishing-related sites; the required type attribute classifies the archive as collectionsite, basecamp, sendersite, credentialInfo, or unspecified. Content may be a URL pointer or inline xs:base64Binary data.
The Contact element within DomainContacts is extended with a required Confidence enumeration (known-fraudulent, looks-fraudulent, known-real, looks-real, unknown) assessing registrant contact veracity, and with ext-role values from RFC 3982 plus hostingProvider for identifying the server operator.
The DCSite Confidence attribute is an integer from 0 to 100 representing the reporter's certainty that a site is a genuine phishing collection site; 0 indicates a false positive and 100 indicates the reporter has independently verified the site.
The DCSite element describes the credential collection site, classified by DCType (web, email, keylogger, automation, unspecified) and holding a choice of SiteURL, Domain, EmailSite, iodef:Address, or Unknown — each carrying an integer confidence attribute (0–100). Multiple DCSite elements indicate multiple collection sites.
The DomainData element captures domain registration details for lure or collection sites: Name (required), DateDomainWasChecked, RegistrationDate, ExpirationDate, Nameservers, and DomainContacts (required). SystemStatus attribute (spoofed, fraudulent, innocent-hacked, innocent-hijacked, unknown) and DomainStatus (from RFC 3982 domainStatusType plus unknown) classify domain involvement.
The EmailRecord element supports inclusion of the original phishing lure email, with a required EmailCount integer, an optional EmailMessage string containing the full RFC 5322 message (header plus body), and optional EmailComments.
The FraudType attribute is a required enumeration classifying the fraud: phishing, recruiting, malware distribution, fraudulent site, dnsspoof, archive, other, unknown, and ext-value. The optional FraudParameter sub-element content depends on the chosen type (e.g., email subject line for phishing, website identifier for fraudulent site).
The IncludedMalware element links malware to a phishing campaign: Name (one or more, required), an optional XML Signature ds:Reference for a cryptographic hash of the malware executable, and an optional Data element containing the malware as hexBinary.
The LureSource element (one or more, required) describes the source of the phishing lure, containing one or more iodef:System elements plus optional DomainData, IncludedMalware, FilesDownloaded, and WindowsRegistryKeysModified sub-elements.
The OriginatingSensor element (one or more, required) identifies the detection mechanism via OriginatingSensorType (web, webgateway, mailgateway, browser, ispsensor, human, honeypot, other), a required DateFirstSeen datetime, and one or more iodef:System elements identifying the detecting entity.
The TakeDownInfo element records disablement of a collection site, with optional TakeDownDate, zero or more TakeDownAgency free-form strings, and TakeDownComments. Multiple TakeDownInfo elements per PhraudReport are permitted to support multi-agency or multi-date takedown activities.
This document registers two URIs in the IETF XML Registry (RFC 3688): the IODEF phishing namespace urn:ietf:params:xml:ns:iodef-phish-1.0 and the IODEF phishing XML schema urn:ietf:params:xml:schema:iodef-phish-1.0 (schema defined in Appendix A).
Phishing activity reports may be falsified or corrupted in transit; applying a digital signature and/or message encryption on each report counteracts both concerns. Each exchanging organization is expected to determine the need and mechanism for transport protection.
Reporters should not apply element-level restriction markings via iodef:restriction unless the receiving party has mechanisms to safeguard data as marked; for example, a PhraudReport element marked private containing a DCSite/SiteURL cannot then be redistributed in a public block list.
Malware in IncludedMalware/Data is encoded as hexBinary and XORed with a 16-hex-character XORPattern attribute (default 0x55AA55AA55AA55BB) to render it inert and bypass anti-virus filters. The XORPattern is stored alongside the data so recipients can recover the original malware.