RFC 5901
Extensions to the IODEF-Document Class for Reporting Phishing
RFC 5901: Extensions to the IODEF-Document Class for Reporting Phishing 🎀
okay bestie, let's start with the title block because it's giving official paperwork 📜
- Stream: Internet Engineering Task Force (IETF)
- Who wrote it: P. Cain from The Cooper-Cain Group, Inc., and D. Jevans from The Anti-Phishing Working Group
- Category: Standards Track
- Date: July 2010
- ISSN: 2070-1721
- Obsoletes / updates: the title block doesn't list any RFCs that this one obsoletes or updates
Abstract ✨
This doc extends the Incident Object Description Exchange Format (IODEF) from RFC 5070 so you can report phishing, which is a specific kind of fraud 🎣. The extensions are flexible enough to capture info from the whole electronic fraud cycle, from the moment the phishing lure lands in your inbox all the way to the point where the collection site gets shut down 💀. You can do a quick, simple report or a full forensic one, and you can also bundle multiple incidents together 🧩.
Status of This Memo 📝
This one's an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741.
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5901 🔗
Copyright Notice ©️
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🧾
Table of Contents 🗺️
1. Introduction ....................................................3
1.1. Why a Common Report Format Is Needed .......................3
1.2. Processing of Exchanged Data Not Defined ...................4
1.3. Relation to the INCH IODEF Data Model ......................4
2. Terminology Used in This Document ...............................4
2.1. Requirements Language ......................................5
3. Interesting Fraud Event Data ....................................5
3.1. The Elements of a Phishing/Fraud Event .....................6
3.2. Useful Data Items in a Fraud Event .........................7
4. Fraud Activity Reporting via IODEF-Documents ....................8
4.1. Fraud Report Types .........................................8
4.2. Fraud Report XML Representation ............................9
4.3. Syntactical Correctness of Fraud Activity Reports ..........9
5. PhraudReport Element Definitions ...............................10
5.1. PhraudReport Structure ....................................10
5.2. Reuse of IODEF-Defined Elements ...........................11
5.3. Element and Attribute Specification Format ................11
5.4. Version Attribute .........................................12
5.5. FraudType Attribute .......................................12
5.6. PhishNameRef Element ......................................13
5.7. PhishNameLocalRef Element .................................13
5.8. FraudedBrandName Element ..................................13
5.9. LureSource Element ........................................14
5.10. OriginatingSensor Element ................................22
5.11. The DCSite Element .......................................23
5.12. TakeDownInfo Element .....................................25
5.13. ArchivedData Element .....................................27
5.14. RelatedData Element ......................................28
5.15. CorrelationData Element ..................................28
5.16. PRComments Element .......................................28
5.17. EmailRecord Element ......................................28
6. Mandatory IODEF and PhraudReport Elements ......................29
6.1. Guidance on Usage .........................................30
7. Security Considerations ........................................31
7.1. Transport-Specific Concerns ...............................31
7.2. Using the iodef:restriction Attribute .....................31
8. IANA Considerations ............................................32
9. Contributors ...................................................32
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................33
Appendix A. Phishing Extensions XML Schema .......................34
Appendix B. Example Virus Report .................................43
B.1. Received Email ...........................................43
B.2. Generated Report .........................................44
Appendix C. Sample Phishing Report ...............................46
C.1. Received Lure ............................................46
C.2. Phishing Report ..........................................481. Introduction 🌸
Okay so, deception is a whole thing. Think of an email that pretends to come from your bank and asks you to "confirm" your account info. That kind of attack is showing up more and more on the Internet 😤. In this doc, "phishing" and "fraud" mean the same thing. Both describe broad social engineering attacks where someone fakes an electronic identity to trick people into handing over their personal credentials (like passwords, account numbers, personal info, ATM PINs, and so on) 🔐. Once the phisher (the attacker) has those, they can use the victim's credentials to make money or get other benefits. And phishing has glowed up a lot 💅. It went from direct emails pretending to be banks to super sophisticated lures that can also carry malware 🦠.
This document defines a data format extension to the Incident Object Description Exchange Format (IODEF) [RFC5070]. It's built to describe info about a phishing event or any other kind of fraudulent incident 🎀. Sections 2 and 3 of this document provides an overview of the terminology and process of a phishing event. Section 4 introduces the high-level report format and how to use it. Sections 5 and 6 describe the data elements of the fraud extensions. The appendices include an XML schema for the extensions and a few example fraud reports 📚.
The extensions in this document can be used to report the social engineering victim lure, the collection site, credential targeted ("spear") phishing, broad multi-recipient phishing, and other evolving Internet-based fraud attempts 🎣🦋. If malware or other malicious software is included in the lure, it can also be included in the report 👾.
1.1. Why a Common Report Format Is Needed 🤝
Okay so the internet is getting more and more chaotic 😭. Service providers and investigative agencies are sharing more network and event data than ever, all to figure out who the bad actors are, which accounts got compromised, how to respond, and how to prosecute attackers ⚖️. The problem is that every new party brings its own tools, formats, and definitions, and those multiply really fast until they totally overwhelm the investigators and coordinators 🌀.
A common format fixes that. It makes it way easier for an organization to coordinate, and to correlate info from multiple data sources or products into one cohesive view ✨. And the more data sources you have, the more you need a common format, because otherwise you'd need a bunch of different tools just to read the different sources. The big win is that you can automate lots of analysis tasks and speed up response and prosecution a lot 🚀.
1.2. Processing of Exchanged Data Not Defined 🙅♀️
The whole point of this spec is to help parties share data with each other. But the mechanics of that sharing process, and its related political challenges, are out of scope for this document 🏛️.
1.3. Relation to the INCH IODEF Data Model 🧩
This doc doesn't invent a brand-new report format. Instead, it's an extension to [RFC5070] 💡. IODEF is flexible, extensible, and lets you be really granular about details. These phishing and fraud extensions reuse subsets of the IODEF data model and, where it makes sense, add new data elements. Building on something that already exists means organizations can adopt it faster and reuse their existing tools 🛠️. For clarity, and to avoid duplication, only the extra structures needed to describe the exchange of phishing and e-crime activity are provided 🫶.
2. Terminology Used in This Document 📖
Different people use different but similar terms for the same thing, so this doc sticks to one set of terms 🙃.
a. Phishing
Phishing is the whole overall process: identifying victims, contacting them with a lure, getting a victim to send a set of private credentials to a collection site, and storing those credentials 🎣.
b. Fraud Event
A fraud event is phishing combined with the later fraudulent use of those private credentials 💸.
c. Lure
A lure is the decoy used to trick a victim into doing something, like handing over their private credentials. It works by using social engineering to convince the victim that it's genuine and its instructions should be followed 🪤. A lure includes a pointer or link to a collection site 🔗.
d. Collection Site
The collection site is the website, email box, SMS number, phone number, or other place where a phished victim sends their private credentials so a criminal can use them later 😈.
e. Credentials
A credential is data that gets transferred or presented to establish either a claimed identity or the authorizations of a system entity 🔑. Lots of websites ask for a user name and password to get into sensitive content, and together those two are a credential 💜.
f. Message
Email is the main one, but a lure can travel through any messaging medium, like instant messages, Voice over IP (VoIP), or text via an SMS service 📱. The term "message" is used as a generic word for any of these transport mediums 🌈.
2.1. Requirements Language 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Those are the official requirement words, so pay close attention to them 👀.
3. Interesting Fraud Event Data 🔍
Before we get into the structure of the IODEF extensions, we first figure out what the "interesting" data is in phishing and other fraudulent activities. Let's dig in 🕵️♀️✨
3.1. The Elements of a Phishing/Fraud Event ✨
+-----------+ +------------------+
| Fraudster |<---<-- | Collection Site |<---O--<----<----+
+----+------+ +------------------+ | |
| | |
| +--|-----+ ^
| | Sensor | Credentials
| +-|------+ |
| +---------------+ | +-------+
\--->--| Attack Source |--Lure--->-----O------> | User/ |
+---------------+ |Victim |
+-------+
Figure 3.1. The Components of Internet FraudOkay so, phishing and fraud are usually made up of at least six components 💅. Here they are:
- The phisher, fraudster, or party behind the scam 🕵️♀️. Most of the time, this party is not easy to identify.
- The attack source (the phishing email, virus, trojan, or other attack) 🎭. It's disguised in a tempting way.
- The lure 🍓. This is what tricks the victim into responding.
- The user, victim, or intended target of the fraud or phish 🫶.
- The credentials, personal data, or other information the victim has handed over to the phisher 🔑.
- The collection site 🕸️. This is where the victim sends their credentials or personal data once the lure has duped them. It can be a website, a mailbox, a phone operator, or a database.
If we look at the whole attack from a holistic view, there are some extra components too 👀:
- The sensor: the means by which the phish is detected. This could be an intrusion detection system, firewall, filter, email gateway, or human analyst 🛡️.
- A forensic or archive site (not pictured) 📦, where an investigator has copied or otherwise kept the data used for the fraud attempt or credential collection.
3.1.1. Fraudulent Activity Extensions to the IODEF-Document 💖
Fraud events get reported in a fraud activity report 📝. It's an instance of an XML IODEF-Document Incident element, with extra EventData and AdditionalData elements added on. The extra fields in EventData that are specific to phishing and fraud are wrapped up in a PhraudReport XML element 🎀.
Fraud activity can involve multiple emails, instant messages, or network messages, spread across different times, locations, and methods, so it's a lot 😭. The PhraudReport inside an EventData can include info about the email header and body, details of the actual phishing lure, correlation to other attacks, and details of the removal of the web server or credential collector 🧹. Since one phishing attack can create multiple reports to an incident team, multiple PhraudReports can be combined into one EventData structure, and multiple EventData structures can be combined into one incident report 🧩. So one IODEF incident report can record one or more individual phishing events and can include multiple EventData elements. Iconic, right? 🌈
This document defines new extension elements for the IODEF EventData XML elements and identifies the ones required in a PhraudReport 🦋. The appendices hold sample fraud activity reports and a complete schema 📚.
The IODEF Extensions defined in this document comply with Section 4, "Extending the IODEF Format" in [RFC5070] ✅.
3.2. Useful Data Items in a Fraud Event 🔍
There are a bunch of subtle, non-obvious bits of data you can capture from a fraud event, and they make event analysis and correlation with other events way more useful 🧠. They sort into these categories:
3.2.1. Data about the Lure 🍓
If a lure was part of the fraud event, this category covers the original received lure, the way the lure was received (e.g., email, phone, or SMS 📱), and the source addresses that sent the lure. Other useful data includes DNS data about the lure source, identification of any accompanying malware 🦠, and the brand name that got defrauded.
3.2.2. Credential Collection Site Data 🕸️
The collection site holds victim identifications, plus copies of the data victims handed over, like account names or numbers, passwords, dates of birth, etc. 😬 This category includes those credentials, along with info about the collection site itself, such as its type, site DNS data, DNS registrant data, and site physical location 📍. The location and registrant info is especially important if law enforcement help is expected 👮♀️. Also, an entire site archive can be gathered so a collector on a shared website can be disabled without messing up other users 🙌.
3.2.3. Detection Information 🔎
This one's a non-obvious data category, and it covers how the lure or collection site got detected 👀. Understanding how the lure was detected lets us design and build better detection systems 🛠️✨.
3.2.4. Analysis Output 🧁
When time is critical, it's imperative that one party's analysis can be reliably explained to and shared with other investigative parties ⏰. This group holds data that an investigator found interesting or that could be useful to others 💜.
4. Fraud Activity Reporting via IODEF-Documents 👑
A fraud activity report is an instance of an XML IODEF-Document with extra extensions and usage guidance, as specified in Section 4 of this document 💅. These extensions are implemented through the PhraudReport XML element.
As the following subsections explain, reporting fraud activity has three primary components 🌸: choosing a report type, a format for the data, and a way to check that the format is correct.
4.1. Fraud Report Types 🦋
There are three actions for reporting phishing events 📣. First, a reporter may create and exchange a new report on a new event 🆕. Second, a reporter may update a previously exchanged report to add new collection sites, site takedown info, or related activities 🔄. Lastly, a reporter may realize the report is in error or has significant incorrect data, and the prudent move is to delete it 🗑️.
The three report types are marked with the ext-purpose attribute of an Incident element. A new report has an empty or a "create" ext-purpose value 🌱. An updated report has an ext-value value of "update" 🔁. A request for deletion has a "delete" ext-purpose value 🚫. Note that this is actually an advisory marking for the report originator or recipient, since operating procedures in a report life cycle are very environment specific 🌍.
4.2. Fraud Report XML Representation 🧩
The IODEF Incident element ([RFC5070], Section 3.2) is summarized below 📋. It and the rest of the data model presented in Section 4 are expressed in Unified Modeling Language (UML) syntax, as used in the IODEF specification. The UML representation is for illustrative purposes only, and elements are specified in XML as defined in Appendix A 💖.
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| | |<>--[ AdditionalData ]
| | |<>--[ PhraudReport ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 4.1. The IODEF XML Incident Element (Modified)A fraud activity report is made up of one iodef:Incident element that contains one or more related PhraudReport elements, embedded in the iodef:AdditionalData element of iodef:EventData 🎁. The PhraudReport element is added to the IODEF using its defined extension procedure, documented in Section 5 of [RFC5070] 🙌.
One IODEF-Document can hold information on multiple incidents, with the info for each incident contained within an iodef:Incident element ([RFC5070], Section 3.12) 🌟.
4.3. Syntactical Correctness of Fraud Activity Reports 🧐
The fraud activity report MUST pass XML validation using the schema defined in [RFC5070] and the extensions defined in Appendix A of this document 🔥. No skipping this step, bestie 💀.
5. PhraudReport Element Definitions 💜
A PhraudReport is an extension to the Incident.EventData.AdditionalData element, with a dtype of "xml" 🎀. Its elements specify info about the six components of fraud activity from Section 3.1. The reporter can add extra forensic info and commentary when needed, like to show how it relates to other events, to show the output of an investigation, or for archival purposes 📂✨.
5.1. PhraudReport Structure 🏗️
A PhraudReport element is structured as follows. Its components are introduced in functional groupings, since some parameters are related and some elements may not make sense on their own 🧃.
+------------------+
| PhraudReport |
+------------------+
| STRING Version |<>--{0..1}--[ PhishNameRef ]
| ENUM FraudType |<>--{0..1}--[ PhishNameLocalRef ]
| STRING ext-value |<>--{0..1}--[ FraudParameter ]
| |<>--{0..*}--[ FraudedBrandName ]
| |<>--{1..*}--[ LureSource ]
| |<>--{1..*}--[ OriginatingSensor ]
| |<>--{0..1}--[ EmailRecord ]
| |<>--{0..*}--[ DCSite ]
| |<>--{0..*}--[ TakeDownInfo ]
| |<>--{0..*}--[ ArchivedData ]
| |<>--{0..*}--[ RelatedData ]
| |<>--{0..*}--[ CorrelationData ]
| |<>--{0..1}--[ PRComments ]
+------------------+
Figure 5.1. The PhraudReport ElementRelevant info about a phishing or fraud event gets encoded into six components, like so 🧠:
a. The PhishNameRef and PhishNameLocalRef elements identify the fraud or class of fraud 🏷️.
b. The LureSource element describes the source of the attack or phishing lure, including host info and any included malware 🦠.
c. The DCSite element describes the technical details of the credential collection site 🕸️.
d. The OriginatingSensor element describes the means of detection 🔭.
The RelatedData, ArchivedData, and TakeDownInfo fields let you include optional forensics and history data 🗂️.
A specific phish or fraud activity can be identified using a combination of the FraudType, FraudParameter, FraudedBrandName, LureSource, and PhishNameRef elements 🎯💖.
5.2. Reuse of IODEF-Defined Elements ✨
okay so we did NOT reinvent the wheel here 🙈 wherever we could, we reused the elements, attributes, and parameters from the base IODEF spec 💅 this spec doesn't add any new variable types or encodings to the IODEF data model. it just extends the IODEF Contact and System elements 🫶
the data model schema has a copy of the iodef:System element 🥹 we would've loved to just extend System, but it's defined in [RFC5070] with an unable-to-extend anonymous type 😭 so we copied the element, named its underlying type, and then generated the extension to it.
📝 note: elements imported from the base IODEF spec get an "iodef" XML namespace prefix, and each one is noted with the section that defines it in [RFC5070]. every element in a PhraudReport gets used as described in the sections below. 🦋
5.3. Element and Attribute Specification Format 🎀
each element and attribute description is set up like this:
- a terse XML-type identifier for the element or attribute.
- whether the element or attribute is REQUIRED or optional. mandatory items get marked REQUIRED, and if nothing is specified, elements are optional. when optional elements do show up, they may REQUIRE specific sub-elements, so keep an eye out 👀
- a description of the element or attribute and what it's meant to be used for.
elements with sub-elements or enumerated values get their own sub-sections 🌈 also, there's no "trickle-up" effect. a sub-element's required pieces only need to be filled in if that sub-element is actually used 💖
5.4. Version Attribute 🦋
REQUIRED. STRING. the version shall be the value 0.06, so it's compliant with this document ✨
5.5. FraudType Attribute 🎣
REQUIRED. One ENUM. the FraudType attribute tells you what kind of fraud this PhraudReport is about 🔍 whichever FraudType you pick decides what goes in the FraudParameter field. here are the options:
phishing. the FraudParameter should be the subject line of the phishing lure email, or the value of a lure IM or VoIP message. this is a standard phishing lure, usually sent as email, and it's meant to exploit the recipient's credentials for financial gain 💸recruiting. the FraudParameter is the subject line of the recruit (aka mule) email or message 🕵️♀️malware distribution. the FraudParameter is the email subject line of the phishing email. this kind of email phish doesn't risk financial loss for the recipient, but it lures them to an infected site 🦠fraudulent site. this identifies a known fraudulent site that doesn't necessarily send spam, but gets used to show lures 🌐 the FraudParameter may be used to identify the website.dnsspoof. this choice doesn't have a related FraudParameter. it's used when a DNS system component responds with an untrue IP address for the requested domain name, because of cache poisoning, ID spoofing, or other manipulation of the DNS system 🙃archive. there's no required FraudParameter for this choice, although the FraudParameter of the original phish could be entered. the data archived from the phishing server goes in the ArchivedData element 📦other. this is for fraud types that haven't been enumerated yet 🧩unknown. this choice may have an associated FraudParameter. it covers the confused cases 😵💫ext-value. this choice identifies a FraudType that's unidentified. the FraudType should be captured in the ext-value attribute 🌸
5.5.1. ext-value Attribute 🧚
OPTIONAL. this STRING may be populated with a FraudType that hasn't been predefined yet.
5.5.2. FraudParameter Element 💅
Zero or one value of iodef:MLStringType. what goes in here depends on the FraudType choice 🎀 it could be an email subject line, a VoIP lure, a link in an IM message, or a web URL. ngl, some phishers stick a bunch of random characters on the end of a phish email subject line so every copy is unique 🙄 reporters should delete those characters before inserting the subject into the FraudParameter field.
6. Fraud Activity Reporting via IODEF-Documents ✨
<!-- placeholder removed -->
5.6. PhishNameRef Element 🏷️
Zero or one value of iodef:MLStringType. the PhishNameRef element is the common name used to identify this fraud event 💜 it's often the name agreed on by the involved parties or vendors. using this name is a super convenient way to reference the activity when you're collaborating with other parties, talking to the media, or doing public education 📣
5.7. PhishNameLocalRef Element 🗂️
Zero or one value of iodef:MLStringType. the PhishNameLocalRef element describes a local name or Unique-IDentifier (UID) that various parties use before everyone agrees on a common term 🤝 this field lets you cross-reference from the submitting organization's system to a central repository.
5.8. FraudedBrandName Element 👑
Zero or more values of iodef:MLStringType. this is the identifier of the recognized brand name or company name used in the phishing activity (e.g., XYZ Semiconductor Corp) 💼
5.9. LureSource Element 🦋
REQUIRED. One or more values. the LureSource element describes where the PhraudReport lure came from 🎯 it lets you specify IP addresses, DNS names, domain registry info, and a little bit of support for files that might get downloaded or registry keys modified by the crimeware 😈
+-------------+
| LureSource |
+-------------+
| |<>--(1..*)--[ System ]
| |<>--(0..*)--[ DomainData ]
| |<>--(0..1)--[ IncludedMalware ]
| |<>--(0..1)--[ FilesDownloaded ]
| |<>--(0..1)--[ WindowsRegistryKeysModified ]
+-------------+
Figure 5.2. The LureSource Element5.9.1. System Element 🖥️
REQUIRED. One or more values of the iodef:System ([RFC5070], Section 3.15). the System element describes a particular host involved in the phishing activity 🕸️ if the real IP address can be ascertained, it should be populated. a spoofed address may also be entered, and when it is, the spoofed attribute SHALL be set 🚨
multiple System elements can be used to identify the DNS name and IP address(es) of the lure source 💖
5.9.2. DomainData Element 🌐
Zero or more element values. the DomainData element describes the registration, delegation, and control of a domain used to source the lure, and it can identify the IP address associated with the System element URI 🔎 capturing the domain data is seriously useful when you're investigating or correlating events 🧠
the structure of a DomainData element looks like this:
+--------------------+
| DomainData |
+--------------------+
| |<>----------[ Name ]
| |<>--(0..1)--[ DateDomainWasChecked ]
| ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ]
| ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ]
| |<>--(0..*)--[ Nameservers ]
| |<>--(0..1)--[ DomainContacts ]
+--------------------+
Figure 5.3. The DomainData Element5.9.2.1. Name Element 🏠
REQUIRED. One value of iodef:MLStringType. the Name element holds the host DNS name used in this event 📛 its value should be the complete DNS host address. for example, if an event targeted www.example.com, the value would be www.example.com ✨
5.9.2.2. DateDomainWasChecked Element ⏰
Zero or one value of DATETIME. this is the timestamp for when this domain data was checked and entered into this report 📅 it matters because a lot of phishers change their domain data at different stages of a phishing event 🫠
5.9.2.3. RegistrationDate Element 🎂
Zero or one value of DATETIME. the RegistrationDate element shows the date a domain was registered 🥳
5.9.2.4. ExpirationDate Element 🪦
Zero or one value of DATETIME. the ExpirationDate element shows the date the domain will expire 📆
5.9.2.5. Nameservers Element 🧭
Zero or more values. these fields hold the nameservers identified for this domain 🗺️ each entry is a sequence of DNSNameType and iodef:Address pairs, as specified below.
+--------------------+
| Nameservers |
+--------------------+
| |<>----------[ Server]
| |<>--(1..*)--[ iodef:Address ]
+--------------------+
Figure 5.4. The Nameservers Elementusing one Server value with multiple Address values is how you note multiple IP addresses associated with one DNS entry for the domain nameserver 🫶
5.9.2.5.1. Server Element 🖧
One value of iodef:MLStringType. this field contains the DNS name of the domain nameserver 💻
5.9.2.5.2. iodef:Address Element 📍
One or more values of iodef:Address. this field lists the IP address(es) associated with this Server element 🌟
5.9.2.6. DomainContacts Element 📇
REQUIRED. Choice of either a SameDomainContact or one or more Contact elements. the DomainContacts element lets the reporter enter contact info supplied by the registrar or returned by whois queries 🕵️ for the reporting party's efficiency, the domain contact info can be marked as the same as another domain already reported, using the SameDomainContact element 🙌
+----------------+
| DomainContacts |
+----------------+
| |<>--(0..1)--[ SameDomainContact ]
| |<>--(1..*)--[ Contact ]
+----------------|
Figure 5.5. The DomainContacts Element5.9.2.6.1. SameDomainContact Element 👯
REQUIRED. One iodef:MLStringType. the SameDomainContact element gets populated with a domain name if the contact info for this domain is identical to that name's info, in this report or another one 🪞 implementors are cautioned to only use this element when the domain contact data returned by a registrar or registry is identical. no shortcuts, bestie 🚫
5.9.2.6.2. Contact Element 🧑💻
REQUIRED. One or more iodef:Contact elements. this element reuses and extends the iodef:Contact elements for its components 🧩 each component may have zero or more values. if only the role attribute and the ContactName component are populated, the same (identical) info gets listed for multiple roles 🎭
+--------------------+
| Contact |
+--------------------+
| |<>----------[ iodef:ContactName ]
| |<>--(0..*)--[ iodef:Description ]
| ENUM role |<>--(0..*)--[ iodef:RegistryHandle ]
| |<>--(0..1)--[ iodef:PostalAddress ]
| ENUM restriction |<>--(0..*)--[ iodef:Email ]
| STRING ext-role |<>--(0..*)--[ iodef:Telephone ]
| ENUM type |<>--(0..1)--[ iodef:Fax ]
| STRING ext-type |<>--(0..1)--[ iodef:Timezone ]
| |<->----------[ AdditionalData ]
| | +<-> [ Confidence ]
+--------------------+
Figure 5.6. The Contact Elementeach Contact has optional attributes to capture the sensitivity and the role it's listed for 🌷 elements reused from [RFC5070] aren't discussed in this document 💜
5.9.2.6.2.1. Confidence Element 🔍
REQUIRED. ENUM. okay so the Confidence element is basically the vibe check on the contact info 🫶 It's a qualitative read on how legit the contact details are. It's an extension to the iodef:Contact element and it's defined in this document. There are five possible values:
- known-fraudulent. This contact info has already been determined to be fraudulent, either because the physical info doesn't exist or because it's real info that isn't connected to this domain registration 💀
- looks-fraudulent. The contact info has suspicious stuff in it 🙈
- known-real. The contact info has been investigated or determined to be correct before ✨
- looks-real. Nothing about it raises suspicion, but nobody has validated it yet 🌸
- unknown. The reporter can't make a value judgment on the contact data 🤷♀️
5.9.2.6.2.2. ext-role Attribute 🎀
REQUIRED. ENUM. the ext-role attribute extends the iodef:ext-role attribute, using the values from RFC 3982 [RFC3982]. The ext-value value of the role attribute should be used, and the ext-role attribute value is picked from this list:
- billingContacts 💰
- technicalContacts 🖥️
- administrativeContacts 📋
- legalContacts ⚖️
- zoneContacts 🌐
- abuseContacts 🚨
- securityContacts 🔐
- otherContacts 🫧
- hostingProvider. This contact is the hosting provider for this server. It's not in RFC 3982, but it's super useful in investigations to know where the server lives and who runs it 🧚 Load-balanced, multicast, or anycast servers may have multiple hostingProvider contact entries.
5.9.3. SystemStatus Attribute 🦋
REQUIRED. ENUM. the SystemStatus attribute is the tea on a system's involvement in this event ☕ The value comes from this list:
- spoofed. This domain or system didn't take part in this event. Another party just used its address space or DNS name 🙃
- fraudulent. The system is run with fraudulent intentions, e.g., the domain name is a homophone 👀
- innocent-hacked. A third party compromised the system and used it in this event. It's the victim arc 😭
- innocent-hijacked. The IP address or domain name was deliberately hijacked via BGP or DNS and then used in this event to source the lure or host the collection site 💅
- unknown. No conclusions are inferred from this event 🌫️
5.9.4. DomainStatus Attribute 🌈
ENUM. the DomainStatus attribute describes the registry status of a domain at the time of the report 📝 The list below is taken from the "domainStatusType" in [RFC3982]. An extra "unknown" value was added in case the status can't be figured out.
- reservedDelegation
- assignedAndActive
- assignedAndInactive
- assignedAndOnHold
- revoked
- transferPending
- registryLock
- registrarLock
- other
- unknown
5.9.5. IncludedMalware Element 🦠
Zero or one value. okay the IncludedMalware element is how you identify (and optionally include) the actual malware that came with the lure 😤 The point isn't to detail how the malware behaves. It's a handy element for linking malware to a phishing campaign 🔗
+------------------+
| IncludedMalware |
+------------------+
| |<>--(1..*)--[ Name ]
| |<>--(0..1)--[ ds:Reference ]
| |<>--(0..1)--[ Data ]
+------------------+
+-----------------------+
| Data |
+-----------------------+
| hexBinary XORPattern |
+-----------------------+Figure 5.7. The IncludedMalware Element
5.9.5.1. Name Element 🏷️
REQUIRED. One or more values of iodef:MLStringType. This field identifies the lure malware by its known name. Unnamed malware can be identified with the value "unknown".
5.9.5.2. Reference Element 🔐
Zero or one value of the Reference. This optional field holds the algorithm identification and value of a hash computed over the malware executable. This entire element is imported from [RFC3275]. Implementations SHOULD support the use of SHA-1 [SHA] as a DigestMethod. bestie, this part is important 🫶
5.9.5.3. Data Element 📦
Zero or one value. The optional Data element is used to include the lure malware. It's encoded as a hexBinary type and XORed with a pattern so it's rendered harmless 🧯
5.9.5.3.1. XORPattern Attribute 🧩
One value of hexBinary. The Data element includes a 16-hexadecimal-character XORPattern attribute, which supports disabling the included malware so it can get past anti-virus filters 🙊 The default value is 0x55AA55AA55AA55BB, which gets XORed with the malware datastring to recover the actual malware.
5.9.6. FilesDownloaded Element 📁
Zero or one value of a sequence of File elements.
+---------------------+
| FilesDownloaded |
+---------------------+
| |<>--(1..*)--[ File ]
+---------------------+Figure 5.8. The FilesDownloaded Element
5.9.6.1. File Element 📄
One or more values of iodef:MLStringType. The File element value is the name of a file that this lure downloaded 💾
5.9.7. WindowsRegistryKeysModified Element 🪟
One or more values of the Key sequence. The contents of the WindowsRegistryKeysModified element are sequences of Key elements. it's giving registry drama 😩
+------------------------------+
| WindowsRegistryKeysModified |
+------------------------------+
| |<>--(1..*)--[ Key ]
+------------------------------+
+--------------+
| Key |
+--------------+
| |<>-----[ Name ]
| |<>-----[ Value ]
+--------------+Figure 5.9. The WindowsRegistryKeysModified Element
5.9.7.1. Key Element 🔑
One or more sequences. The Key element is a sequence of Name and Value pairs representing an operating system registry key and its value. The key and value are encoded as in Microsoft .reg files [KB310516].
5.9.7.1.1. Name Element 🏷️
One STRING, representing the Windows Operating System Registry Key Name. The value is encoded as in Microsoft .reg files, e.g., [HKEY_LOCAL_MACHINE\Software\Test\KeyName].
5.9.7.1.2. Value Element 💎
One STRING, representing the value of the associated Key, encoded as in Microsoft .reg files, e.g., REG_BINARY:01.
5.10. OriginatingSensor Element 👀
REQUIRED. The OriginatingSensor element contains the identification and cognizant data of the network element that detected this fraud activity. The network element doesn't have to be on the Internet itself (it can be a local Intrusion Detection System (IDS)), and it isn't required to be mechanical either (humans are allowed) 🧠
Multiple OriginatingSensor elements are allowed, so detection at multiple locations can be supported 🌍
+----------------------------+
| OriginatingSensor |
+----------------------------+
| ENUM OriginatingSensorType |<>------------[ DateFirstSeen ]
| |<>--(1..*)----[ iodef:System ]
+----------------------------+Figure 5.10. The OriginatingSensor Element
The OriginatingSensor requires a type value and the identification of the entity that detected this fraudulent event.
5.10.1. OriginatingSensorType Attribute 🛰️
REQUIRED. ENUM. The value comes from this list, which sorts the sensor by its function:
- web. A web server or service detected this event.
- webgateway. A proxy, firewall, or other network gateway detected this event.
- mailgateway. The event was detected via a mail gateway or filter 📬
- browser. The event was detected at the user web interface or a browser-type element 🌐
- ispsensor. An automated system in the network detected the event, such as an Intrusion Detection System, Intrusion Protection System, or other Internet Service Provider device 🤖
- human. A non-automated system (e.g., a human, manual analysis, etc.) detected this event 🙋♀️
- honeypot. The event was detected by receipt at a decoy device 🍯
- other. The detection was done via a method that isn't listed 🫠
5.10.2. DateFirstSeen Element 📅
REQUIRED. DATETIME. This is the date and time that this sensor first saw this phishing activity.
5.10.3. iodef:System Element 🖥️
REQUIRED. One or more values of iodef:System. This is identification information (such as the IP version, IP address, etc.) for the entity that detected this event. Identifying multiple detectors is supported ✨
5.11. The DCSite Element 🕸️
Zero or more DCSite elements. The DCSite captures the type, identifier, location, and other pertinent info about the credential gathering process, or data collection site, used in the phishing incident. The data collection site is identified by four elements: the type of collector, the network location, info about its DNS domain, and a confidence factor. More details about the domain, system, or owner of the DCSite can go inside the DomainData sub-element 💖
If the DCSite element is present, a value is required. Multiple DCSite elements are allowed to show multiple collection sites for a single collector. Multiple URLs pointing to the same DNS entry can be identified with multiple SiteURL elements 🧚
+--------------+
| DCSite |
+--------------+
| ENUM DCType |<>--+--------[ SiteURL ]
| | +--------[ Domain ]
| | +--------[ EmailSite ]
| | +--------[ System ]
| | +--------[ Unknown ]
| |<>--(0..*)---[ iodef:Node ]
| |<>--(0..1)---[ DomainData ]
| |<>--(0..1)---[ iodef:Assessment ]
+--------------+Figure 5.11. The DCSite Element
5.11.1. DCType Attribute 🎯
REQUIRED. ENUM. The DCType attribute identifies the method of data collection, as figured out by analyzing the victim computer, lure, or malware 🔎 This attribute together with the DCSite content identifies the data collection site.
- web. The user is redirected to a website to collect the data 🌸
- email. The victim sends an email with credentials enclosed 📧
- keylogger. Some form of keylogger is downloaded to the victim ⌨️
- automation. Other forms of automatic data collection, such as background Object Linking and Embedding (OLE) automation, are used to capture information on the user's machine 🤖
- unspecified.
5.11.2. DCSite Values 💖
REQUIRED. okay bestie, the DCSite element holds the IP address, URL, email site, or other identifier of the credential or data collection site 🕸️ The Domain choice is giving "block the whole phishy domain" energy 🎣, and it's perfect for stuff like RockPhish and related malware 💀 Every DCSite element also has a confidence attribute, which is basically the reporter's vibe check on whether this DCSite is legit and actually involved in this event ✨ That confidence value is per-DCSite, because a multi-site data collector might be more sure about one site than another 🫶
The DCSite element is a choice of these, so pick one:
SiteURL. One value ofiodef:MLStringType. This choice supports URIs and other web-based identifiers 🌐Domain. One value ofiodef:MLStringType. This choice lets you enter a DNS domain name 🍓EmailSite. One value ofiodef:MLStringType. This choice includes an email address if the site used email communications 📧iodef:Address. One value ofiodef:Addresselement. This choice captures the IP address of a site 🧚Unknown. One value ofiodef:MLStringType. The unknown entry is for the exceptions that don't fit the choices above 🙈
5.11.2.1. Confidence Attribute 🎀
One value of INTEGER. The confidence attribute is a value between 0 and 100, showing how sure the reporter is that this is a genuine phishing site 🎣 A value of 0 means a false positive 🙅♀️, and a value of 100 means the reporter has independently verified this site 💯
5.11.3. iodef:Node Element 🗺️
Zero or more values of iodef:Node. This element identifies the IP address(es) or DNS names associated with the DCSite element value 📍
5.11.4. DomainData Element 📦
Zero or one value of DomainData (Section 5.9.2). This element lets you identify data associated with the data collection site 🔍
5.11.5. iodef:Assessment Element 📊
Zero or one value of iodef:Assessment. This element is used to label the different confidence levels of multiple-site data collectors 🏷️
5.12. TakeDownInfo Element ✨
Zero or more TakeDownInfo elements. This element identifies the agent or agency that performed the removal, DNS domain disablement, or ISP-blockage of the phish or fraud collector site 🚫 A PhraudReport can have multiple TakeDownInfo elements for when several takedowns happened on different dates 📅 Also, the term "agency" is used for ANY party doing the blocking or removal, like ISPs or private parties, not just government entities 🏛️
The TakeDownInfo element allows one date element with multiple TakeDownAgency and Comment elements to support operations using multiple agencies 🤝
+-------------------+
| TakeDownInfo |
+-------------------+
| |<>---(0..1)--[ TakeDownDate ]
| |<>---(0..*)--[ TakeDownAgency ]
| |<>---(0..*)--[ TakeDownComments ]
+-------------------+
Figure 5.12. The TakeDownInfo Element5.12.1. TakeDownDate ⏰
Zero or one value of DATETIME. This is the date and time that takedown of the collector site happened 🗓️
5.12.2. TakeDownAgency 🏢
Zero or more iodef:MLStringType elements. This is a free-form string naming the agency, corporation, or cooperative that did the takedown 💼
5.12.3. TakeDownComments 🗒️
Zero or more iodef:MLStringType elements. This is a free-form field for any extra details on the takedown effort, or for naming parties who helped at an Internet Service Provider (ISP), Computer Emergency Response Team (CERT), or DNS registry 🤓
5.13. ArchivedData Element 🗄️
Zero or more values of the ArchivedData element are allowed 💅
+-------------------+
| ArchivedData |
+-------------------+
| ENUM type |<>---(0..1)--[ URL ]
| |<>---(0..1)--[ Comments ]
| |<>---(0..1)--[ Data ]
+-------------------+
Figure 5.13. The ArchivedData ElementThe ArchivedData URL element is populated with a pointer to the contents of a data collection site, base camp (i.e., development site), or other site used by a phisher 🎯 The ArchivedData Data element may also include a copy of the archived data recovered from a phishing system 💾 This element gets populated when, for example, an ISP takes down a phisher's website and has copied the site data into an archive file 🫣
There are four types of archives currently supported, as specified in the type field 🎀
5.13.1. type Attribute 🏷️
REQUIRED. This parameter specifies the type of site data pointed to by the ArchivedData URL element, from the following list:
collectionsite. The archive is a set of files from the collection site.basecamp. The contents of a criminal development site are included in the archive.sendersite. The archive is a set of files or data from a phishing lure sending site.credentialInfo. The included archives are recovered private credentials.unspecified. The archive contents do not fit into one of the above categories and will be described in the DataComments element.
5.13.2. URL Element 📍
Zero or one value of anyURL. As the archive of an entire site can be quite large, the URL element points to an Internet-based server where the actual content of the site archive can be retrieved 🌍 Note that this element just points out where the archive is and does not include the entire archive in the report 🙅♀️ This is the URL where the archive file is located.
5.13.3. Comments Element 💬
Zero or one value of iodef:MLStringType. This field is a free-form area for comments on the archive and/or URL 📝
5.13.4. Data Element 🔐
Zero or one value of xs:Base64Binary. This field contains a base64-encoded version of the data described in the comment field above 🧃
5.14. RelatedData Element 🔗
Zero or more values of anyURI. This element lets you list other websites or net sites related to this incident (e.g., victim site, etc.) 🕸️
5.15. CorrelationData Element 🧩
Zero or more values of iodef:MLStringType. Any info that correlates this incident to other incidents can go here 💜
5.16. PRComments Element 🌸
Zero or one value of iodef:MLStringType. This field is for any comments specific to this PhraudReport that don't fit in any other field 📌
5.17. EmailRecord Element 📨
This element supports including the actual email message received as a phishing lure 💌 There are two ways to include it: the message can be one large string, or the header and body can be split up and included as a series of strings 🧩
+--------------------+
| EmailRecord |
+--------------------+
| |<>--------------[ EmailCount ]
| |<>--(0..1)------[ EmailMessage ]
| |<>--(0..1)------[ EmailComments ]
+--------------------+
Figure 5.14. The EmailRecord Element5.17.1. EmailCount Element 🔢
REQUIRED. INTEGER. This field counts the number of email messages identified in this record, as detected by the reporter 👀
5.17.2. EmailMessage Element ✉️
Zero or one value of iodef:MLStringType. The entire SMTP mail message -- rfc822 header followed by body, as specified in [RFC5322] -- should be inserted as one large text string 💖 In some communities, this combo is known as the message contents and full headers 🫶
5.17.3. EmailComments Element 🗯️
Zero or one value of iodef:MLStringType elements. This field holds comments or relevant data about the phishing email that aren't placed anywhere else 🧐
6. Mandatory IODEF and PhraudReport Elements 🎀
A report about fraud or phishing needs certain identifying info, and that info lives in the standard IODEF Incident data structure plus the PhraudReport extensions 🧾 The table below shows the attributes that have to be present in a compliant PhraudReport for phishing or fraud reporting. The required attributes are a mix of the ones the base IODEF element needs (Figure 6.1) and the ones this document needs (Figure 6.2). Attributes identified as required SHALL be populated in conforming phishing activity reports 🔥
A compliant IODEF PhraudReport SHALL contain the following elements and attributes:
+--------------+
| Incident |
+--------------+
| ENUM Purpose |---[ IncidentID ]
| |---[ ReportTime ]
| |---[ Assessment ]
| | ---> [ Impact ]
| |---[ Contact ]
| | ---> [ @type ]
| | ---> [ @role ]
| | ---> [ * ]
| |---[ EventData ]
| | ---> [ DetectTime ]
| | ---> [ AdditionalData ]
| | ---> [ PhraudReport ]
+--------------+
Figure 6.1. IODEF Required Classes for a PhraudReport+----------------+
| PhraudReport |
+----------------+
| ENUM FraudType |---[ LureSource ]
| STRING Version | ---> [ iodef:System ]
| |---[ OriginatingSensor ]
| | --> [ DateFirstSeen ]
| | --> [ iodef:System ]
| | --> [ iodef:Node ]
| |
+----------------+
Figure 6.2. PhraudReport Required Elements(*) Note that the iodef:Contact element is required, but none of its sub-elements are required. For proper XML correctness, one of the sub-elements is required; pick one 🧷
6.1. Guidance on Usage 🔍
It might be obvious that the mandatory attributes for a PhraudReport make for a pretty sparse report 🥹 Since incident forensics and data analysis need detailed info, the originator of a PhraudReport SHOULD include any tidbit of information gleaned from the attack analysis ✨ Info that's considered sensitive can be marked as such using the restriction parameter of each data element 🔒
The reporting party is encouraged to provide more than just the minimally required data elements about an event in a PhraudReport 💅 The additional info may be volatile and not recoverable in the future, and may be useful for answering investigation questions or for correlating with other reported events 🕵️♀️
7. Security Considerations 🚨
Okay bestie, this part is SERIOUS 😭 Don't skip it.
This document specifies a format for encoding a particular class of security incidents, one that's appropriate for exchange across organizations 📦 As merely a data representation, it does not directly introduce security issues 🤍 However, it is guaranteed that parties exchanging instances of this specification will have certain concerns 😬 For this reason, the underlying message format and transport protocol used MUST ensure the appropriate degree of confidentiality, integrity, and authenticity for the specific environment 🔐
Organizations that exchange data using this document are urged to develop operating procedures that document the following areas of concern 📋
7.1. Transport-Specific Concerns 🛡️
The critical security concerns are that phishing activity reports may be falsified, or the PhraudReport may become corrupt during transit 💀 In areas where transmission security or secrecy is questionable, applying a digital signature and/or message encryption on each report will counteract both of these concerns 🫡 We expect that each exchanging organization will determine the need, and mechanism, for transport protection 🦋
7.2. Using the iodef:restriction Attribute ✨
Sometimes the data in a particular element is sensitive, and the reporter knows it. There's no one-size-fits-all rule for when to slap a "private" or "need-to-know" label on something using the iodef:restriction attribute, so this is a judgment call. 🫣 The reporter is gently warned not to use element-level sensitivity markings unless they're confident the receiving party (the one they're swapping event report data with) has a way to properly protect and process the data the way it's been marked. 🔒
Let's say the PhraudReport element is marked private and has a phishing collector URL in the DCSite/SiteURL element. Can that URL end up in a block list that gets shared with other parties? 😳 The document doesn't answer that one. The only advice is that exchanging parties should go through the IODEF and PhraudReport documents and agree on common marking rules together. 🤝
8. IANA Considerations 🌸
This document uses URNs to describe XML namespaces and XML schemas that follow a registry mechanism described in [RFC3688]. Basically, the URNs are how the namespace and schema get their official names. 🧚
Registration request for the IODEF phishing namespace:
- URI:
urn:ietf:params:xml:ns:iodef-phish-1.0 - Registrant Contact: See the "Authors' Addresses" section of this document.
- XML: None.
Registration request for the IODEF phishing extension XML schema:
- URI:
urn:ietf:params:xml:schema:iodef-phish-1.0 - Registrant Contact: See the "Authors' Addresses" section of this document.
- XML: See Appendix A, "Phishing Extensions XML Schema", of this document.
9. Contributors 🫶
The extensions grew out of the Anti-Phishing Working Group (APWG) work on collecting and sharing data about phishing and other e-crimeware. 🕵️♀️ Quick clarification: the APWG has no relationship to an IETF working group, so don't mix them up! 🙈
This document got tons of help from members of the IETF INCH working group, plus two groups tackling the phishing problem: members of the APWG and participants in the Financial Services Technology Consortium's Counter-Phishing project. 💖 Huge thanks to the brave people who gave valuable feedback after trying this format out to report phishing. 👑
10. References 📚
10.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3275]Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.[RFC3982]Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", RFC 3982, January 2005.[RFC5070]Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.[SHA]National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", FIPS 180-2, August 2002.
10.2. Informative References
[KB310516]Microsoft Corporation, "How to add, modify, or delete registry subkeys and values by using a registration entries (.reg) file", December 2007.[RFC3688]Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.[RFC5322]Resnick, P., "Internet Message Format", RFC 5322, October 2008.
Appendix A. Phishing Extensions XML Schema 💅
Here's the full schema, so the namespaces, types, and everything else are all in one place. Don't change a single character, bestie! 🤓
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212
/xmldsig-core-schema.xsd"/>
<!--
==========================================================
=== Top-Level Class: PhraudReport ===
==========================================================
It is incorporated within an
IODEF.Incident.EventData.AdditionalData element.
All the top-level or major elements are defined as xs:types to make
future extension easier.
-->
<xs:element name="PhraudReport">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="PhishNameRef"
type="iodef:MLStringType"/>
<xs:element minOccurs="0" name="PhishNameLocalRef"
type="iodef:MLStringType"/>
<xs:element minOccurs="0" name="FraudParameter"
type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="FraudedBrandName" type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
name="LureSource" type="phish:LureSource.type"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
name="OriginatingSensor"
type="phish:OriginatingSensor.type"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailRecord"
type="phish:EmailRecord.type"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="DCSite" type="phish:DCSite.type"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:TakeDownInfo"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:ArchivedData"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="RelatedData" type="xs:anyURI"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="CorrelationData" type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="PRComments"
type="iodef:MLStringType"/>
</xs:sequence>
<xs:attribute default="1.0" name="Version" use="optional"/>
<xs:attribute name="FraudType" type="phish:FraudType.type"
use="required"/>
<xs:attribute name="ext-value" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="FraudType.type">
<xs:restriction base="xs:string">
<xs:enumeration value="phishing"/>
<xs:enumeration value="recruiting"/>
<xs:enumeration value="malware distribution"/>
<xs:enumeration value="fraudulent site"/>
<xs:enumeration value="dnsspoof"/>
<xs:enumeration value="archive"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
<!--
==========================================================
=== End of the Top-Level Element ===
==========================================================
-->Okay bestie, the schema keeps going and it's giving LureSource energy 🎀💖 Here's the next chunk 💅
-->
<!--
==========================================================
=== The LureSource Element ===
==========================================================
-->
<xs:complexType mixed="false" name="LureSource.type">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
<xs:element minOccurs="0" maxOccurs="unbounded"
ref="phish:DomainData"/>
<xs:element minOccurs="0" name="IncludedMalware"
type="phish:IncludedMalware.type"/>
<xs:element minOccurs="0" name="FilesDownloaded">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" name="File"
type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="WindowsRegistryKeysModified">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Key">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Value" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
=== LureSource sub-elements ===
-->
<xs:complexType name="IncludedMalware.type">
<xs:sequence>
<xs:element name="Name"
maxOccurs="unbounded" type="iodef:MLStringType"/>
<xs:element minOccurs="0" ref="ds:Reference"/>
<xs:element minOccurs="0" name="Data">
<xs:complexType >
<xs:simpleContent>
<xs:extension base="xs:hexBinary">
<xs:attribute default="55AA55AA55AA55BB"
name="XORPattern" type="xs:hexBinary"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
===========================================================
=== The EmailRecord Element ===
===========================================================
-->
<xs:complexType name="EmailRecord.type">
<xs:sequence>
<xs:element name="EmailCount" type="xs:integer"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailMessage"
type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailComments"
type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
<!--
===========================================================
=== The Data Collection Site (DCSite) Info Element ===
===========================================================
-->
<xs:complexType name="DCSite.type">
<xs:sequence>
<xs:choice>
<xs:element name="SiteURL">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Domain">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="EmailSite">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="System">
<xs:complexType id="SystemType">
<xs:sequence>
<xs:element ref="iodef:Address"/>
</xs:sequence>
<xs:attribute ref="phish:confidence"/>
</xs:complexType>
</xs:element>
<xs:element name="Unknown">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:choice>
<xs:element ref="iodef:Node" minOccurs="0" maxOccurs="unbounded"/>
<xs:element minOccurs="0" ref="phish:DomainData"/>
<xs:element minOccurs="0" ref="iodef:Assessment"/>
</xs:sequence>
<xs:attribute name="DCType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
<xs:enumeration value="email"/>
<xs:enumeration value="keylogger"/>
<xs:enumeration value="automation"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!--
=================================================
==== The Domain Data Element used in System =====
=================================================
-->
<xs:element name="DomainData">
<xs:complexType id="DomainData.type">
<xs:sequence>
<xs:element maxOccurs="1"
name="Name" type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="DateDomainWasChecked" type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="RegistrationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="Nameservers">
<xs:complexType id="Nameservers.type">
<xs:sequence>
<xs:element name="Server" type="iodef:MLStringType"/>
<xs:element ref="iodef:Address" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice id="DomainContacts" maxOccurs="1" minOccurs="0">
<xs:element name="SameDomainContact"
type="iodef:MLStringType"/>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:Contact"/>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attribute name="SystemStatus">
<xs:simpleType id="SystemStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="spoofed"/>
<xs:enumeration value="fraudulent"/>
<xs:enumeration value="innocent-hacked"/>
<xs:enumeration value="innocent-hijacked"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="DomainStatus">
<xs:simpleType id="DomainStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="reservedDelegation"/>
<xs:enumeration value="assignedAndActive"/>
<xs:enumeration value="assignedAndInactive"/>
<xs:enumeration value="assignedAndOnHold"/>
<xs:enumeration value="revoked"/>
<xs:enumeration value="transferPending"/>
<xs:enumeration value="registryLock"/>
<xs:enumeration value="registrarLock"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="Confidence">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:attribute name="confidence">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<!--
=====================================================================
= ext-role Values for use within the DomainContact Contacts Element =
=====================================================================
-->
<xs:simpleType name="ext-role">
<xs:restriction base="xs:string">
<xs:enumeration value="billingContacts"/>
<xs:enumeration value="technicalContacts"/>
<xs:enumeration value="administrativeContacts"/>
<xs:enumeration value="legalContacts"/>
<xs:enumeration value="zoneContacts"/>
<xs:enumeration value="abuseContacts"/>
<xs:enumeration value="securityContacts"/>
<xs:enumeration value="otherContacts"/>
<xs:enumeration value="hostingProvider"/>
</xs:restriction>
</xs:simpleType>
<!--
=================================================
=== The OriginatingSensor Data Element ===
=================================================
-->
<xs:complexType name="OriginatingSensor.type">
<xs:sequence>
<xs:element name="DateFirstSeen" type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
</xs:sequence>
<xs:attribute name="OriginatingSensorType" use="required">
<xs:simpleType id="OriginatingSensorType.type">
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="web"/>
<xs:enumeration value="webgateway"/>
<xs:enumeration value="mailgateway"/>
<xs:enumeration value="browser"/>
<xs:enumeration value="ispsensor"/>
<xs:enumeration value="human"/>
<xs:enumeration value="honeypot"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!--
======================================================
=== The TakeDown Data Structure ===
======================================================
-->
<xs:element name="TakeDownInfo" type="phish:TakeDownInfo.type"/>
<xs:complexType name="TakeDownInfo.type">
<xs:sequence>
<xs:element maxOccurs="1" minOccurs="0" name="TakeDownDate"
type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownAgency" type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownComments" type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
<!--
=========================================================
=== The ArchivedData Element ===
=========================================================
-->
<xs:element name="ArchivedData" type="phish:ArchivedData.type"/>
<xs:complexType name="ArchivedData.type">
<xs:sequence>
<xs:element minOccurs="0" name="URL" type="xs:anyURI"/>
<xs:element minOccurs="0" name="Comments"
type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="Data"
type="xs:base64Binary"/>
</xs:sequence>
<xs:attribute name="type" use="required">
<xs:simpleType id="ArchivedDataType.type">
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="collectionsite"/>
<xs:enumeration value="basecamp"/>
<xs:enumeration value="sendersite"/>
<xs:enumeration value="credentialInfo"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:schema>Appendix B. Example Virus Report 🦠
okay so this section is a real-ish example of an email that snuck a virus in a zipped attachment 💀, plus the report that got generated for that message. it's giving detective energy 🕵️♀️
B.1. Received Email
the email is below, exactly as it came in:
From: support@example.com
Sent: Friday, June 10, 2005 3:52 PM
To: someone@example.com
Subject: Account update
To: someone@example.com
Date: Sun, 10 June 2005 3:52:44 +0200
We would like to inform you that we have released a new version of our
Customer Form. This form is required to be completed by all customers.
Please follow these steps:
1.Open the form at http://www.example.com/customerservice/cform.php
<http://www.2.example.com/customerservice/cform.php
&email=(someone@example.com)> .
2.Follow given instructions.
Thank you,
Our Support TeamB.2. Generated Report
heads up 🎀 the report below has been wrapped and folded a little so it fits the margins. the vibe is still 100% intact ✨
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document lang="en-US"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<Incident purpose="reporting" ext-purpose="create">
<IncidentID name="example.com">PAT2005-06</IncidentID>
<ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
<Description>This is a test report from actual data.
</Description>
<Assessment>
<Impact type="social-engineering"/>
<Confidence rating="high"/>
</Assessment>
<Contact role="creator" type="person">
<ContactName>patcain</ContactName>
<Email>pcain@coopercain.com</Email>
</Contact>
<EventData>
<DetectTime>2005-06-21T18:22:02-05:00</DetectTime>
<AdditionalData dtype="xml">
<phish:PhraudReport FraudType="phishing">
<phish:FraudParameter>
Subject: Account Update
</phish:FraudParameter>
<phish:FraudedBrandName>Cooper-Cain
</phish:FraudedBrandName>
<phish:LureSource>
<System category="source">
<Node>
<Address>192.0.2.18</Address>
</Node>
</System>
<phish:IncludedMalware>
<phish:Name>W32.Mytob.EA@mm</phish:Name>
</phish:IncludedMalware>
</phish:LureSource>
<phish:OriginatingSensor OriginatingSensorType="human">
<phish:DateFirstSeen>2005-06-10T15:52:11-05:00
</phish:DateFirstSeen>
<System>
<Node>
<Address>192.0.2.13</Address>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:EmailMessage>
Return-path: <support@example.com>
Envelope-to: someone@example.com
Delivery-date: Fri, 10 Jun 2005:52:11-0400
Received: from dsl18-2-0-192.dsl.example.net([192.0.2.18]
helo=example.com) by mail06.example.com esmtp (Exim) id
1DgpXy-0002Ua-IR for someone@example.com;,
10 Jun 2005 15:52:10-0400
From: support@example.com
To: someone@example.com
Subject: Account Update
Date: Fri, 10 Jun 2005 12:52:00 -0700
MIME-Version: 1.0
Content Type: text/plain;
charset="Windows-1251"
X-Priority: 3MSMail-Priority: Normal
X-EN-OrigIP: 192.0.2.18
EN-OrigHost: dsl18-2-0-192.dsl.example.net
Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16)
on.example.net
X-Spam-Level: ***** X-Spam-Status: No,
score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30,
HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE,
NO_REAL_NAME,
PRIORITY_NO_NAME autolearn=disabled version=3.0.2
From:support@example.com
Sent: Friday, June 10, 2005 3:52 PM
Subject: Account update
To: someone@example.com
Date: Sun, 10 June 2005 3:52:44 +0200
We would like to inform you that we have released a new version of our
Customer Form. This form is required to be completed by all customers.
Please follow these steps:
1.Open the form at http://www.example.com/customerservice/cform.php
<http://www.2.example.com/customerservice/cform.php
&email=(someone@example.com)> .
2.Follow given instructions.
Thank you,
Our Support Team
</phish:EmailMessage>
</phish:EmailRecord>
</phish:PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>Appendix C. Sample Phishing Report 🎣
this section shows a sample report that got generated from a phishing email. it's lowkey the most "why would anyone fall for this" thing ever 🙈
C.1. Received Lure
here's the lure exactly as it arrived 👀
Return-path: <service@example.com>
Envelope-to: pcain@example.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.example.com ([10.1.1.161]
helo=mail15.example.com)
by mailscan38.example.com with esmtp (Exim)
id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006
05:37:21 -0400
Received: from [192.0.2.61] (helo=TSI)
by mail15.example.com with
esmtp (Exim) id 1Fq5Bj-0006dv-6b
for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400
Received: from User ([192.0.2.157]) by TSI with
Microsoft SMTPSVC(5.0.2195.6713);
Tue, 13 Jun 2006 02:24:30 -0400
Reply-To: <nospam@example.org>
From: "company"<service@example.com>
Subject: * * * Update & Verify Your Example Company Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@example.com
X-EN-OrigIP: 192.0.2.1
X-EN-OrigHost: unknown
Company<http://www.example.com/images/company_logo.gif>
<http://www.example.com/images/pixel.gif>
<http://www.example.com/images/pixel.gif>
<http://www.example.com/images/pixel.gif>
Account Update Request
Dear Example. member:,
You are receiving this notification because company is required by
law to notify you, that you urgently need to update your online
account statement, due to high risks of fraud intentions.
The updating of your example account can be done at any time by
clicking on the link shown below
http://www.example.com/cgi-bin/webscr?cmd=_login-run
<http://192.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20/%20/.payp
al.com/index.htm>
Once you log in, update your account information.
After updating your account, click on the History sub tab of your
Account Overview page to see your most recent statement.
If you need help with your password, click the Help link that is at
the upper righthand side of the company website. To report errors
in your statement or make inquiries, click the Contact Us link in the
footer on any page of the company website, call our Customer Service
center at (999) 555-0167, or write us at:
Company, Inc.
P.O. Box 0
Anytown, MA 00000
Sincerely,
Big Example Company
<http://www.example.com/images/dot_row_long.gif>
C.2. Phishing Report ✨
okay so this one is a full phishing report, and it's giving detective energy 🕵️♀️🎀 Someone got a sketchy "Update & Verify Your Company Account" email, and the report wraps the whole thing up in IODEF XML with the phish extension. It has the incident details, the risk assessment, the contact, the timestamps, the raw email headers and body, and info on the fake website. Lowkey the most complete example in the whole appendix 💅
Here's the full report, verbatim:
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" lang="en-US">
<Incident purpose="mitigation" ext-purpose="create"
restriction="private">
<IncidentID name="example.com">CC200600000002</IncidentID>
<ReportTime>2006-06-13T21:14:56-05:00</ReportTime>
<Description>This is a sample phishing email received report.
The phish was actually received as is.</Description>
<Assessment>
<Impact severity="high" type="social-engineering"/>
<Confidence rating="numeric">85</Confidence>
</Assessment>
<Contact role="creator" type="person">
<ContactName>patcain</ContactName>
<Email>pcain@example.com</Email>
</Contact>
<EventData>
<DetectTime>2006-06-13T05:37:21-04:00</DetectTime>
<AdditionalData dtype="xml">
<phish:PhraudReport FraudType="phishing">
<phish:FraudParameter>
* * * Update & Verify Your Company Account * * *
</phish:FraudParameter>
<phish:FraudedBrandName>company</phish:FraudedBrandName>
<phish:LureSource>
<System category="source">
<Node>
<Address>192.0.2.4</Address>
</Node>
</System>
</phish:LureSource>
<phish:OriginatingSensor OriginatingSensorType="mailgateway">
<phish:DateFirstSeen>
2006-06-13T05:37:22-04:00</phish:DateFirstSeen>
<System>
<Node>
<NodeRole category="mail"/>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:EmailMessage>
Return-path: <service@example.com>
Envelope-to: pcain@example.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.example.com ([10.1.1.161]
helo=mail15.example.com)
by mailscan38.example.com with esmtp (Exim)
id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006
05:37:21 -0400
Received: from [192.0.2.61] (helo=TSI)
by mail15.example.com with
esmtp (Exim) id 1Fq5Bj-0006dv-6b
for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400
Received: from User ([192.0.2.157]) by TSI with
Microsoft SMTPSVC(5.0.2195.6713);
Tue, 13 Jun 2006 02:24:30 -0400
Reply-To: <nospam@example.org>
From: "company"<service@example.com>
Subject: * * * Update & Verify Your Example Company Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@example.com
X-EN-OrigIP: 192.0.2.1
X-EN-OrigHost: unknown
<img src="http://www.example.com/images/company_logo.gif">
<img src="http://www.example.com/images/pixel.gif">
<img src="http://www.example.com/images/pixel.gif">
<img src="http://www.example.com/im/pixel.gif">
Account Update Request
Dear Example. member:,
You are receiving this notification because company is required by
law to notify you, that you urgently need to update your online
account statement, due to high risks of fraud intentions.
The updating of your example account can be done at any time by
clicking on the link shown below
<a href="http://192.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20/%20/.example.com/index.htm">
http://www.example.com/cgi-bin/webscr?cmd=_login-run </a>
Once you log in,update your account information.
After updating your account click on the History sub tab of your
Account Overview page to see your most recent statement.
If you need help with your password, click the Help link which is at
the upper right hand side of the company website. To report errors in
your statement or make inquiries, click the Contact Us link in the
footer on any page of the company website, call our Customer Service
center at (999) 555-0167, or write us at:
Company, Inc.
P.O. Box 0
Anytown, MA 00000
Sincerely,
Big Example Company
<img src="http://www.example.com/images/dot_row_long.gif">
</phish:EmailMessage>
</phish:EmailRecord>
<phish:DCSite DCType="web">
<phish:SiteURL>http://190.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20%20/.example.com/index.htm</phish:SiteURL>
<phish:DomainData DomainStatus="assignedAndActive"
SystemStatus="unknown">
<phish:Name>bad.example.com</phish:Name>
<phish:DateDomainWasChecked>2006-06-14T13:05:00-05:00
</phish:DateDomainWasChecked>
<phish:RegistrationDate>
2000-12-13T00:00:00</phish:RegistrationDate>
<phish:Nameservers>
<phish:Server>ns1.example.net</phish:Server>
<Address>192.0.2.18</Address>
</phish:Nameservers>
</phish:DomainData>
</phish:DCSite>
</phish:PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
Authors' Addresses 🎀
Meet the humans behind the spec 🫶
Patrick Cain
The Cooper-Cain Group, Inc.
P.O. Box 400992
Cambridge, MA 02140
USA
EMail: pcain@coopercain.com
David Jevans
The Anti-Phishing Working Group
5150 El Camino Real, Suite A20
Los Altos, CA 94022
USA
EMail: dave.jevans@antiphishing.org📦 where this page comes from
- ietf: rfc5901 2010-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms