Network Working Group P. Cain Internet-Draft The Cooper-Cain Group, Inc. Intended status: Standards Track D. Jevans Expires: January 31, 2009 The Anti-Phishing Working Group July 30, 2008 Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware draft-cain-post-inch-phishingextns-05 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 31, 2009. Cain & Jevans Expires January 31, 2009 [Page 1] Internet-Draft IODEF Phishing Extensions July 2008 Abstract This document extends the Incident Object Description Exchange Format (IODEF) to support the reporting of phishing, fraud, other types of electronic crime, and widespread spam incidents. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle. Both simple reporting and complete forensic reports are possible, as is consolidated reporting of multiple phishing incidents. The extensions defined in this document are used to generate two different types of reports: a fraud and phishing report and a wide- spread spam report. Although similar in structure, each report has different required objects and intents. Cain & Jevans Expires January 31, 2009 [Page 2] Internet-Draft IODEF Phishing Extensions July 2008 RFC 2129 Keywords 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Why a Common Report Format is Needed . . . . . . . . . . . 5 1.2. Relation to the INCH IODEF Data Model . . . . . . . . . . 6 2. The Elements of Phishing/Fraud Activity . . . . . . . . . . . 8 3. Fraud Activity Reporting via IODEF-Documents . . . . . . . . . 9 3.1. Fraud Report Types . . . . . . . . . . . . . . . . . . . . 9 3.2. Fraud Report XML Representation . . . . . . . . . . . . . 9 3.3. Correctness of Fraud Activity Reports . . . . . . . . . . 10 4. PhraudReport Element Definitions . . . . . . . . . . . . . . . 11 4.1. PhraudReport Structure . . . . . . . . . . . . . . . . . . 11 4.2. Reuse of IODEF-defined Elements . . . . . . . . . . . . . 12 4.3. Element and Attribute Specification Format . . . . . . . . 12 4.4. Version attribute . . . . . . . . . . . . . . . . . . . . 12 4.5. FraudType attribute . . . . . . . . . . . . . . . . . . . 13 4.6. PhishNameRef element . . . . . . . . . . . . . . . . . . . 14 4.7. PhishNameLocalRef element . . . . . . . . . . . . . . . . 14 4.8. FraudedBrandName element . . . . . . . . . . . . . . . . . 14 4.9. LureSource element . . . . . . . . . . . . . . . . . . . . 14 4.10. OriginatingSensor Element . . . . . . . . . . . . . . . . 23 4.11. The DCSite element . . . . . . . . . . . . . . . . . . . . 25 4.12. TakeDownInfo element . . . . . . . . . . . . . . . . . . . 27 4.13. ArchivedData element . . . . . . . . . . . . . . . . . . . 27 4.14. RelatedData element . . . . . . . . . . . . . . . . . . . 29 4.15. CorrelationData element . . . . . . . . . . . . . . . . . 29 4.16. PRComments element . . . . . . . . . . . . . . . . . . . . 29 4.17. EmailRecord element . . . . . . . . . . . . . . . . . . . 29 5. IODEF Required Elements . . . . . . . . . . . . . . . . . . . 32 5.1. Fraud or Phishing Report . . . . . . . . . . . . . . . . . 32 5.2. Wide-Spread Spam Report . . . . . . . . . . . . . . . . . 33 5.3. Guidance on Usage . . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6.1. Transport-specific concerns . . . . . . . . . . . . . . . 35 6.2. Using the iodef:restriction attribute . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 9.2. Informative References . . . . . . . . . . . . . . . . . . 38 Appendix A. Appendix A. Phishing Extensions XML Schema . . . . . 39 Cain & Jevans Expires January 31, 2009 [Page 3] Internet-Draft IODEF Phishing Extensions July 2008 Appendix B. Example Virus Report . . . . . . . . . . . . . . . . 51 B.1. Received Email . . . . . . . . . . . . . . . . . . . . . . 51 B.2. Generated Report . . . . . . . . . . . . . . . . . . . . . 51 Appendix C. Sample Phishing Report . . . . . . . . . . . . . . . 54 C.1. Received Lure . . . . . . . . . . . . . . . . . . . . . . 54 C.2. Phishing Report . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 Intellectual Property and Copyright Statements . . . . . . . . . . 60 Cain & Jevans Expires January 31, 2009 [Page 4] Internet-Draft IODEF Phishing Extensions July 2008 1. Introduction Deception activities, such as receiving an email purportedly from a bank requesting you to confirm your account information, are an expanding attack type on the Internet. The terms phishing and fraud are used interchangeably in this document to characterize broadly- launched social engineering attacks in which an electronic identity is misrepresented in an attempt to trick individuals into revealing their personal credentials ( e.g., passwords, account numbers, personal information, ATM PINs, etc.). A successful phishing attack on an individual allows the phisher (i.e., the attacker) to exploit the individual's credentials for financial or other gain. Phishing attacks have morphed from directed email messages from alleged financial institutions to more sophisticated lures that may also include malware. This document defines a data format extension to the Incident Object Description Exchange Format (IODEF) [RFC5070] that can be used to describe information about a phishing incident or wide-spread spam incident. Sections 2 and 3 of this document introduce the high-level report format and how to use it. Sections 4 and 5 describe the data elements of the fraud extensions. This document includes an XML schema for the extensions and a few example fraud reports. The extensions defined in this document may be used to report targeted ('spear') phishing, broad multi-recipient phishing, wide- spread spam events, the distribution of malware, and evolving Internet-based fraud attempts. Receipt of single spam message MUST NOT be reported via these extensions as these formats are for more general, widespread events. 1.1. Why a Common Report Format is Needed The rise in phishing and fraud activities via e-mail, instant message, DNS corruption, and malicious code insertion has driven corporations, Internet Service Providers, consumer agencies, and financial institutions to begin to collect and correlate phishing attack information. The collected data allows them to better coordinate mitigation activities and support in the pursuit and prosecution of the attacker. By using a common format, it becomes easier for an organization to engage in this coordination as well as correlation of information from multiple data sources or products into a cohesive view. As the number of data sources increases, a common format becomes even more important, since multiple tools would be needed to interpret the different sources of data. Cain & Jevans Expires January 31, 2009 [Page 5] Internet-Draft IODEF Phishing Extensions July 2008 The accumulation and correlation of information is also important in resolving phishing incidents detected externally as the phished organization may not even be aware of the attack. Third parties aware of the attack may wish to notify the phished organization or a central notification service so adequate responses could commence. The targeted organization's internal monitoring systems may also detect the attack and wish to take mitigation steps. While the intended use of this specification is to facilitate data sharing between parties, the mechanics of this sharing process and its related political challenges are out of scope for this document. 1.2. Relation to the INCH IODEF Data Model Instead of defining a new report format, this draft defines an extension to [RFC5070]. The IODEF defines a flexible and extensible format and supports a granular level of specificity. This phishing extension reuses subsets of the IODEF data model and, where appropriate, specifies new data elements. Leveraging an existing specification allows for more rapid adoption and reuse of existing tools in organizations. For clarity, and in order to eliminate duplication, only the additional structures necessary for describing the exchange of phishing and e-crime activity are provided. 1.2.1. Fraudulent Activity Extensions to the IODEF-Document Fraudulent events are reported in a Fraud Activity Report which is an instance of an XML IODEF-Document Incident element with added EventData and AdditionalData elements. The additional fields in the EventData specific to phishing and fraud are enclosed into a PhraudReport XML element. Fraudulent activity may include multiple emails, instant messages, or network messages, scattered over various times, locations, and methodologies. The PhraudReport within an EventData may include information 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. As a phishing attack may generate multiple reports to an incident team, multiple PhraudReports may be combined into one EventData structure and multiple EventData structures may be combined into one Incident Report. One IODEF Incident report may record one or more individual phishing events and may include multiple EventData elements. This document defines new extension elements for the EventData and Record Item IODEF XML elements and identifies those required in a PhraudReport. The Appendices contain sample Fraud Activity Reports and a complete Schema. Cain & Jevans Expires January 31, 2009 [Page 6] Internet-Draft IODEF Phishing Extensions July 2008 The IODEF Extensions defined in this document comply with section 4, "Extending the IODEF Format" in [RFC5070]. Cain & Jevans Expires January 31, 2009 [Page 7] Internet-Draft IODEF Phishing Extensions July 2008 2. The Elements of Phishing/Fraud Activity +-----------+ +------------------+ | Fraudster |<---<-- | Collection Point |<---O--<----<----+ +----+------+ +------------------+ | | | | | | +--|-----+ ^ | | Sensor | Credentials | +-|------+ | | +---------------+ | +-------+ \--->--| Attack Source |--Phish-->-----O------> | User/ | +---------------+ |Victim | +-------+ Figure 2.1: The Components of Internet Phishing Internet-based Phishing and Fraud activities are normally comprised of at least four components: 1. The Phisher, Fraudster, or party perpetrating the fraudulent activity. Most times this party is not readily identifiable. 2. The Attack Source, the source of the phishing email, virus, trojan, or other attack is masked in an enticing manner. 3. The User, Victim, or intended target of the fraud/phish. 4. The collection point, where the victim sends their credentials or personal data if they have been duped by the phisher. If we take a holistic view of the attack, there are some additional components: 5. The sensor, the means by which the phish is detected. This element may be an intrusion detection system, firewall, filter, email gateway, or human analyst. 6. A forensic or archive site (not pictured) where an investigator has copied or otherwise retained the data used for the fraud attempt or credential collection. Cain & Jevans Expires January 31, 2009 [Page 8] Internet-Draft IODEF Phishing Extensions July 2008 3. Fraud Activity Reporting via IODEF-Documents A Fraud Activity Report is an instance of an XML IODEF-Document with additional extensions and usage guidance as specified in Section 4 of this document. These additional extensions are implemented through the PhraudReport XML element. As described in the following sections, reporting Fraud Activity has three primary components: choosing a report type; a format for the data; and how to check correctness of the format. 3.1. Fraud Report Types There are three actions relating to reporting phishing events. First, a reporter may *create* and exchange a new report on a new event. Secondly, a reporter may *update* a previously exchanged report to indicate new collection sites, site take down information, or related activities. Lastly, a reporter may have realized that the report is in error or contain significant incorrect data and the prudent reaction is to *delete* the report. The three types of reports are denoted through the use of the ext- pupose attribute of an Incident element. A new report contains an empty or a "create" ext-purpose value; an updated report contains a ext-value value of "update"; a request for deletion contains a "delete" ext-purpose value. Note that this is actually an advisory marking for the report originator or recipient as operating procedures in a report lifecycle is very environment specific. 3.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 is expressed in Unified Modeling Language (UML) syntax as used in the IODEF specification. The UML representations is for illustrative purposes only; elements are specified in XML as defined in A Cain & Jevans Expires January 31, 2009 [Page 9] Internet-Draft IODEF Phishing Extensions July 2008 +--------------------+ | 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 3.1: The IODEF XML Incident Element (modified) A Fraud Activity Report is composed of one iodef:Incident element that contains one or more related PhraudReport elements embedded in 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 may contain information on multiple incidents with information for each incident contained within an iodef:Incident element [RFC5070], Section 3.12]. 3.3. Correctness of Fraud Activity Reports The Fraud Activity Report MUST pass XML validation using the schema defined in [RFC5070] and the extensions defined in of this document. Cain & Jevans Expires January 31, 2009 [Page 10] Internet-Draft IODEF Phishing Extensions July 2008 4. PhraudReport Element Definitions A PhraudReport consists of an extension to the Incident.EventData.AdditionalData element with a dtype of "xml". The elements of the PhraudReport will specify information about the six components of fraud activity identified in Section 2. Additional forensic information and commentary can be added by the reporter as necessary to show relation to other events, to show the output of an investigation, or for archival purposes. 4.1. PhraudReport Structure A PhraudReport element is structured as follows. The components of a PhraudReport are introduced in functional grouping as some parameters are related and some elements may not make sense individually. +------------------+ | PhraudReport | +------------------+ | STRING Version |<>--{0..1}--[ PhishNameRef ] | ENUM FraudType |<>--{0..1}--[ PhishNameLocalRef ] | |<>--{0..1}--[ FraudParameter ] | |<>--{0..*}--[ FraudedBrandName ] | |<>--{1..*}--[ LureSource ] | |<>--{1..*}--[ OriginatingSensor ] | |<>--{0..1}--[ EmailRecord ] | |<>--{0..*}--[ DCSite ] | |<>--{0..*}--[ TakeDownInfo ] | |<>--{0..*}--[ ArchivedData ] | |<>--{0..*}--[ RelatedData ] | |<>--{0..*}--[ CorrelatedData ] | |<>--{0..1}--[ PRComments ] +------------------+ Figure 4.1: The PhraudReport Element Relevant information about a phishing or fraud event can be encoded by encoding the six components as follows: 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 information and any included malware. c. The DCSite describes the technical details of the credential collection point. Cain & Jevans Expires January 31, 2009 [Page 11] Internet-Draft IODEF Phishing Extensions July 2008 d. The Originating Sensor element describes the means of detection. The RelatedData, ArchivedData, and TakeDownInfo fields allow optional forensics and history data to be included. A specific phish/fraud activity can be identified using a combination of the FraudType, FraudParameter, FraudedBrandName, LureSource, and PhishNameRef elements. 4.2. Reuse of IODEF-defined Elements Elements, attributes, and parameters defined in the base IODEF specification were used whenever possible in the definition of the PhraudReport XML element. This specification does not introduce any new variable types or encodings to the IODEF data model, but extends the IODEF Contact and System elements. Note: Elements that are imported from the base IODEF specification are prefaced with an "iodef" XML namespace and are noted with the section defining that element in [RFC5070]. Each element in a PhraudReport is used as described in the following sections. 4.3. Element and Attribute Specification Format The following sections describe the components of a PhraudReport XML element. Each description is structured as follows. 1. A terse XML-type identifier for the element or attribute. 2. An indication of whether the element or attribute is REQUIRED or optional. Mandatory items are noted as REQUIRED. If not specified, elements are optional. Note that when optional elements are included, they may REQUIRE specific sub-elements. 3. A description of the element or attribute and its intended use. Elements that contain sub-elements or enumerated values are further sub-sectioned. Note that there is no 'trickle-up' effect in elements. That is, the required elements of a sub-element are only populated if the sub-element is used. 4.4. Version attribute REQUIRED. STRING. The version shall be the value 0.04 to be compliant with this document. [This value will be changed to "1.0" when this document progresses.] Cain & Jevans Expires January 31, 2009 [Page 12] Internet-Draft IODEF Phishing Extensions July 2008 4.5. FraudType attribute REQUIRED. One ENUM. The FraudType attribute describes the type of fraudulent activity described in this PhraudReport and contains one of the following values: 1. phishemail. The FraudParameter should be the email subject line of the phishing email. This type is a standard email phish, usually sent as spam, and is intended to derive financial loss to the recipient. 2. recruitemail. The FraudParameter is the email subject line of the phishing email. This type of email phish does not pose a potential financial loss to the recipient, but covers other cases of the phish and fraud lifecycle. 3. malwareemail. The FraudParameter is the email subject line of the phishing email. This type of email phish does not pose a potential financial loss to the recipient, but lures the recipient to an infected site. 4. fraudsite. This identifies a known fraudulent site that does not necessarily send spam but is used for lures. The FraudParameter may be used to identify the website. 5. dnsspoof. This choice does not have a related FraudParameter. This is used for a spoofed DNS (e.g., malware changes localhost file so visits to www.example.com go to another IP address chosen by the fraudster). 6. keylogger. This choice does not have a FraudParameter and specifies a keylogger downloaded with the lure. 7. ole. There is no FraudParameter. This identifies background Microsoft Object Linking and Embedding (OLE) information that comes as part of a lure. 8. im. The FraudParameter should be the malicious instant message (IM) link supplied to the user. 9. cve. This choice identifies CVE-known malware, with the Common Vulnerability and Exposures project (CVE) number as the FraudParameter. 10. archive. There is no required FraudParameter for this choice, although the FraudParameter of the original phish could be entered. The data archived from the phishing server is placed in the ArchiveInfo element. Cain & Jevans Expires January 31, 2009 [Page 13] Internet-Draft IODEF Phishing Extensions July 2008 11. spamreport. This type is used when the PhraudReport is reporting a large-scale spam activity. The FraudParameter should be the spam email subject line. 12. voip. The lure was received via a voice-over-IP connection identified by the information in the FraudParameter field. 13. other. This is used to identify not-yet-enumerated fraud types. 14. unknown. This choice may have an associated FraudParameter. It is used to cover confused cases. 4.5.1. FraudParameter element REQUIRED. One value of iodef:MLStringType. This is the lure used to attract victims. It may be an email subject line, VoIP lure, link in an IM message, the CVE or malware identifier, or a web URL. Note that some phishers add a number of random characters onto the end of a phish email subject line for uniqueness; reporters should delete those characters before insertion into the FraudParameter field. 4.6. PhishNameRef element Zero or one value of STRING. The PhishNameRef element is the common name used to identify this fraud event. It is often the name agreed upon by involved parties or vendors. Using this name can be a convenient way to reference the activity collaborating with other parties, the media, or engaging in public education. 4.7. PhishNameLocalRef element Zero or one value of STRING. The PhishNameLocalRef element describes a local name or Unique-IDentifier (UID) that is used by various parties before a commonly agreed term is adopted. This field allows a cross-reference from the submitting organization's system to a central repository. 4.8. FraudedBrandName element Zero or more values of STRING. This is the identifier of the recognized brand name or company name used in the phishing activity (e.g., XYZ Semiconductor Corp). 4.9. LureSource element REQUIRED. One value. The LureSource element describes the source of the PhraudReport lure. It allows the specification of IP Addresses, DNS names, domain registry information, and rudimentary support for Cain & Jevans Expires January 31, 2009 [Page 14] Internet-Draft IODEF Phishing Extensions July 2008 the files that might be downloaded or registry keys modified by the crimeware. +-------------+ | LureSource | +-------------+ | |<>--(1..*)--[ System ] | |<>--(0..*)--[ DomainData ] | |<>--(0..1)--[ IncludedMalware ] | |<>--(0..1)--[ FilesDownloaded ] | |<>--(0..1)--[ RegistryKeysModified ] +-------------+ Figure 4.2: The LureSource element 4.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 the spoofed attribute SHALL be set. 4.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. Capturing the domain data is very useful when investigating or correlating events. The structure of a DomainData element is as follows: +--------------------+ | DomainData | +--------------------+ | |<>----------[ Name ] | |<>--(0..1)--[ DateDomainWasChecked ] | ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ] | ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ] | |<>--(0..*)--[ Nameservers ] | |<>--(0..*)--[ DNSRecord ] | |<>--(0..*)--[ DomainContacts ] +--------------------+ Figure 4.3 The DomainData element Cain & Jevans Expires January 31, 2009 [Page 15] Internet-Draft IODEF Phishing Extensions July 2008 4.9.2.1. Name REQUIRED. One value of iodef:MLStringType [RFC5070], Section 2.4]. The Name element is the domain name used in this event. 4.9.2.2. DateDomainWasChecked Zero or One value of DATETIME. This element includes the timestamp of when this domain data was checked and entered into this report as many phishers modify their domain data at various stages of a phishing event. 4.9.2.3. RegistrationDate element Zero or one value of DATETIME. The RegistrationDate element shows the date of registration for a domain. 4.9.2.4. ExpirationDate element Zero or one value of DATETIME. The ExpirationDate element shows the date the domain will expire. 4.9.2.5. Nameservers element Zero or more values. These fields hold nameservers identified for this domain. Each entry is a sequence of DNSNameType and iodef: Address pairs as specified below. The use of one Server value and one Address value, followed by multiple empty Server values with Address values is allowable to note multiple IPAddreses associated with one DNS entry for the domain nameserver. 4.9.2.5.1. Server element Zero or more values of iodef:MLStringType. This field contains the DNS name of the domain nameserver. 4.9.2.5.2. iodef:Address element REQUIRED. One Value of Address. This field contains the IP address of the domain nameserver. 4.9.2.6. DNSRecord element Zero or more values. This element allows the reporter to duplicate the DNS record data as defined by [RFC1034], and returned by the DNS. Including this information allows for tracking, trending, and Cain & Jevans Expires January 31, 2009 [Page 16] Internet-Draft IODEF Phishing Extensions July 2008 identification of the very transient DNS mapping and structure of crimeware domains. +----------------+ | DNSRecord | +----------------+ | |<>--(1..1)--[ owner ] | |<>--(1..1)--[ type ] | |<>--(0..1)--[ class ] | |<>--(0..1)--[ ttl ] | |<>--(1..1)--[ rdata ] +----------------+ Figure 4.4 The DomainContacts element 4.9.2.6.1. owner element REQUIRED. One String Value. This element identifies the superior node in the DNS hierarchy. 4.9.2.6.2. type element REQUIRED. One String Value. This field contains one value from the IANA DNS Resource Record Type Registry. 4.9.2.6.3. class element Zero or one value of a STRING. This field contains one value from the IANA DNS Domain System Class Registry. The value will be the two character representation of class, instead of a decimal number to ease data entry from standard DNS tools. The default value for this field is "IN" to note the Internet. 4.9.2.6.4. ttl element Zero or one value of INTEGER. This value represents the time-to-live (TTL) value for this record. 4.9.2.6.5. rdata element REQUIRED. One string value. The resource data for the record is contained within this field. 4.9.2.7. DomainContacts element REQUIRED. Choice of either a SameDomainContact or one or more DomainContact elements. The DomainContacts element allows the reporter to enter contact information supplied by the registrar or Cain & Jevans Expires January 31, 2009 [Page 17] Internet-Draft IODEF Phishing Extensions July 2008 returned by Whois. For efficiency of the reporting party, the domain contact information may be marked to be the same as another domain already reported using the SameDomainContact element. +----------------+ | DomainContacts | +----------------+ | |<>--(0..1)--[ SameDomainContact ] | |<>--(1..*)--[ DomainContact ] +----------------+ Figure 4.5 The DomainContacts element 4.9.2.7.1. SameDomainContact REQUIRED. One iodef:DNSNAME. The SameDomainContact element is populated with a domain name if the contact information for this domain is identical to that name in this or another report. Implementors are cautioned to only use this element when the domain contact data returned by the registrar is identical. 4.9.2.7.2. DomainContact 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) information is listed for multiple roles. +--------------------+ | DomainContact | +--------------------+ | |<>----------[ iodef:ContactName ] | |<>--(0..*)--[ iodef:Description ] | ENUM Role |<>--(0..*)--[ iodef:RegistryHandle ] | ENUM Confidence |<>--(0..1)--[ iodef:PostalAdress ] | ENUM Restriction |<>--(0..*)--[ iodef:Email ] | |<>--(0..*)--[ iodef:Telephone ] | |<>--(0..1)--[ iodef:Fax ] | |<>--(0..1)--[ iodef:Timezone ] +--------------------+ Figure 4.6: The DomainContact element Each Contact has three attributes to capture the sensitivity, confidence, and role for which the contact is listed. Cain & Jevans Expires January 31, 2009 [Page 18] Internet-Draft IODEF Phishing Extensions July 2008 4.9.2.7.2.1. Role attribute REQUIRED. ENUM. The role attribute is extended from the iodef:role- ext attribute with values identified in [CRISP]. The role-ext value of the role attribute should be used, with the role-ext attribute value chosen from one of the following values: 1. registrant. This identified Contact is the domain registrant. 2. registrar. This contact identifies the registrar of this domain. 3. billing. This entry is the billing or financial contact. 4. technical. This contact deals with technical issues. 5. administrative. This contact handles administrative matters for this domain. 6. legal. This entry deals with legal issues for this domain. 7. zone. This entry controls the DNS zone information. 8. abuse. This entry accepts abuse issues. 9. security. This entry accepts security issues. 10. domainOwner. This lists the owner of the domain. 11. ipAddressOwner. This entry identifies the assignee of the IP address space. 12. hostingProvider. This contact is the hosting provider of this domain. 13. other. This entry does not meet an enumerated value. 4.9.2.7.2.2. Confidence attribute REQUIRED. ENUM. The Confidence attribute describes a qualitative assessment of the veracity of the contact information. This attribute is an extension to the iodef:Contact element and is defined in this document. There are five possible confidence values as follows. 1. known-fraudulent. This contact information has been previously determined to be fraudulent, either as non-existent physical information or containing real information not associated with Cain & Jevans Expires January 31, 2009 [Page 19] Internet-Draft IODEF Phishing Extensions July 2008 this domain registration. 2. looks-fraudulent. The contact information has suspicious information included. 3. known-real. The contact information has been previously investigated or determined to be correct. 4. looks-real. The contact information does not arouse suspicion but has not been previously validated. 5. unknown. The reporter cannot make a value judgment on the contact data. 4.9.2.7.2.3. Restriction attribute Zero or one iodef:restriction attribute [RFC5070, as part of Section 3.2]. The restriction attribute is used to label the sensitivity of included information. 4.9.3. SystemStatus attribute REQUIRED. ENUM. The SystemStatus attribute assesses a domain's involvement in this event. 1. spoofed. This domain or system did not participate in this event, but its address space or DNS name was forged. 2. fraudulent. The system is fraudulently operated. 3. innocent-hacked. The system was compromised and used in this event to source the lure. 4. innocent-hijacked. The IP Address or domain name was hijacked and used in this event to source of the lure. 5. unknown. No conclusions are inferred from this event. 4.9.4. DomainStatus attribute ENUM. The DomainStatus attribute describes the registry status of a domain at the time of the report. The below enumerated list is taken verbose from the 'domainStatusType' of the Extensible Provisioning Protocol[RFC4933] and "Domain Registry Version 2 for the Internet Registry Information Service" internet-draft [CRISP]. Cain & Jevans Expires January 31, 2009 [Page 20] Internet-Draft IODEF Phishing Extensions July 2008 1. reservedDelegation - permanently inactive 2. assignedAndActive - normal state 3. assignedAndInactive - registration assigned but delegation inactive 4. assignedAndOnHold - dispute 5. revoked - database purge pending 6. transferPending - change of authority pending 7. registryLock - on hold by registry 8. registrarLock - on hold by registrar 4.9.5. IncludedMalware element Zero or One Value. The IncludedMalware element allows for the identification and optional inclusion of the actual malware that was part of the lure. The goal of this element is not to detail the characteristics of the malware but rather to allow for a convenient element to link malware to a phishing campaign. +------------------+ | IncludedMalware | +------------------+ | |<>--(1..*)--[ Name ] | |<>--(0..1)--[ Hashvalue ] | |<>--(0..1)--[ Data ] +------------------+ +-----------------+ | Hashvalue | +-----------------+ | ENUM Algorithm | | | | STRING | +-----------------+ +---------------------+ | Data | +---------------------+ | STRING XORPattern |<>--(0..1)-+-[ StringData ] | | +-[ BinaryData ] +---------------------+ Cain & Jevans Expires January 31, 2009 [Page 21] Internet-Draft IODEF Phishing Extensions July 2008 Figure 4.7: The Included Malware element 4.9.5.1. Name element REQUIRED. One or more value of iodef:MLStringType. This optional field is used to identify the lure malware. 4.9.5.2. Hashvalue element Zero or one value of STRING. This optional field is used to hold the value of a hash computed over the malware executable. 4.9.5.2.1. Algorithm attribute REQUIRED ENUM. This field from the following list identifies the algorithm used to create this hashvalue. SHA1. Hashvalue as defined in[SHA]. 4.9.5.3. Data element Zero or one value. Choice of two elements, below. The optional Data element is used to describe the lure malware. 4.9.5.3.1. StringData element The lure malware is encoded as a String value. 4.9.5.3.2. BinaryData element The lure malware is encoded as a hexBinary encoded value, as defined by the XML standard. 4.9.5.3.3. XORPattern attribute Zero or One value of STRING. The Data Element includes an optional 16 hexadecimal character XORPattern attribute to support disabling the included malware to bypass anti-virus filters. The default value is 0x55AA55AA55AA55BB which would be XOR-ed with the malware datastring to recover the actual malware. 4.9.6. FilesDownloaded element Zero or One value of STRING. The FileDownloaded element is a comma- separated list where each entry is the name of a file downloaded by this lure. Although this element could be implemented as a sequence of individual XML entries, the extra XML overhead was perceived to Cain & Jevans Expires January 31, 2009 [Page 22] Internet-Draft IODEF Phishing Extensions July 2008 not add any value, so the files are listed in one element. 4.9.7. RegistryKeysModified element One value of the Keys sequence. The contents of the RegistryKeysModified element are sets of Key elements. +-----------------------+ | RegistryKeysModified | +-----------------------+ | |<>--(1..*)--[ Key ] +-----------------------+ +--------------+ | Key | +--------------+ | |<>-----[ Name ] | |<>-----[ Value ] +--------------+ Figure 4.8: The RegistryKeysModified element 4.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 4.9.7.1.1. Name element One STRING, representing the WINDOWS Operating System Registry Key Name. 4.9.7.1.2. Value element One STRING, representing the value of the associated Key 4.10. OriginatingSensor Element REQUIRED. The OriginatingSensor element contains the identification and cognizant data of the network element that detected this fraud activity. Note that the network element does not have to be on the Internet itself (i.e., it may be a local IDS system) nor is it required to be mechanical (e.g., humans are allowed). Cain & Jevans Expires January 31, 2009 [Page 23] Internet-Draft IODEF Phishing Extensions July 2008 Multiple OriginatingSensor Elements are allowed to support detection at mutiple locations. +---------------------+ | OriginatingSensor | +---------------------+ | ENUM OrigSensorType |<>------------[ DateFirstSeen ] | |<>---(1..*)---[ iodef:System ] +---------------------+ Figure 4.9: The OriginatingSensor element The OriginatingSensor requires a type value and identification of the entity that detected this fraudulent event. 4.10.1. OrigSensorType attribute REQUIRED. ENUM. The value is chosen from the following list, categorizing the function of this sensor: 1. Web. A web server or service detected this event. 2. WebGateway. A proxy, firewall, or other network gateway detected this event. 3. MailGateway. The event was detected via a mail gateway or filter 4. Browser. The event was detected at the user web interface or browser-type element.. 5. ISPsensor. The event was detected by an automated system in the network such as IDS, IPS, or ISP device. 6. Human. A non-automated system (e.g., a human, manual analysis, etc) detected this event. 7. Honeypot. The event was detected by receipt at a decoy device. 8. Other. The detection was performed via a non-listed method. 4.10.2. DateFirstSeen element REQUIRED. DATETIME. This is the date and time that this sensor first saw this phishing activity. Cain & Jevans Expires January 31, 2009 [Page 24] Internet-Draft IODEF Phishing Extensions July 2008 4.10.3. iodef:System element REQUIRED. One iodef:System. This is the IPVersion, IPAddress, and optionally, port number of the entity that generated this report. 4.11. The DCSite element Zero or more DCSite elements. The DCSite captures the type, identifier, collection location, and other pertinent information 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 site, the network location, information about its DNS Domain, and a confidence factor. Further details about the domain, system, or owner of the DCSite can be inserted into the DomainData sub-element. If the DCSite element is present, a value is required. Multiple DCSite elements are allowed to indicate multiple collection sites for a single collector. Multiple URLs pointing to the same DNS entry can be identified with multiple SiteURL elements. +--------------+ | DCSite | +--------------+ | ENUM DCSite |<>--+--------[ SiteURL ] | | +--------[ Domain ] | | +--------[ EmailSite ] | | +--------[ System ] | | +--------[ Unknown ] | |<>--(0..1)---[ DomainData ] | |<>--(0..1)---[ iodef:Assessment ] +--------------+ Figure 4.10: The DCSite element 4.11.1. DCType attribute REQUIRED. ENUM. The DCType attribute identifies the method of data collection as determined through the analysis of the victim computer, lure, or malware. This attribute coupled with the DCSite content identifies the data collection site. 1. web. The user is redirected to a website to collect the data. 2. email. The victim sends an email with credentials enclosed. Cain & Jevans Expires January 31, 2009 [Page 25] Internet-Draft IODEF Phishing Extensions July 2008 3. keylogger. Some form of keylogger is downloaded to the victim. 4. automation. Other forms of automatic data collection, such as background OLE automation, are used to capture information. 5. unspecified. 4.11.2. DCSite values REQUIRED. The DCSite element contains the IPAddress, URL, emailsite, or other identifier of the data collection site. The Domain choice may be used to identify entire 'phishy' domains like those used for the RockPhish and related malware. Each DCSite element also includes a confidence element to convey the reporter's assessment of their confidence that this DCSite element is valid, and involved with this event. The confidence value is a per-DCSite value as multiple-site data collectors may have different confidence values. The DCSite element is a choice of: 1. SiteURL. STRING. This choice supports URIs. 2. Domain. STRING. This choice allows the entry of a DNS Domain name. 3. EmailSite. STRING. This choice captures either the email address of the data collection site. 4. iodef:System element [RFC5070, Section 3.15]. This choice is filled it to capture the IP Address of a site. 5. Unknown. STRING. The unknown entry is used for exception to the preceding choices. 4.11.2.1. DomainData element Zero or One value of DomainData. This element allows for the identification of data associated with the data collection site. 4.11.2.2. iodef:Assessment element Zero or One value of iodef:Assessment. This element is used to designate different confidence levels of multiple-site data collectors. Cain & Jevans Expires January 31, 2009 [Page 26] Internet-Draft IODEF Phishing Extensions July 2008 4.12. TakeDownInfo element Zero or more TakeDownInfo element. 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 may have multiple TakeDownInfo elements to support activities where multiple take down activities are involved on different dates. Note that the term "Agency" is used to identify any party performing the blocking or removal such as 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 4.11: The TakeDownInfo element 4.12.1. TakeDownDate Zero or one DATETIME. This is the date and time that take down of the collector site occurred. 4.12.2. TakeDownAgency Zero or more STRING. This is a free form string identifying the agency, corporation, or cooperative that performed the take down. 4.12.3. TakeDownComments Zero or more STRING. A free form field to add any additional details of this take down effort or to identify parties that assisted in the effort at an ISP, CERT, or DNS Registry. 4.13. ArchivedData element Zero or more values of the ArchivedData element are allowed. Cain & Jevans Expires January 31, 2009 [Page 27] Internet-Draft IODEF Phishing Extensions July 2008 +-------------------+ | ArchivedData | +-------------------+ | ENUM type |<>---(0..1)--[ ArchivedDataURL ] | |<>---(0..1)--[ ArchivedDataComments ] | |<>---(0..1)--[ ArchivedData ] +-------------------+ Figure 4.12: The ArchivedData element The ArchivedData 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 ArchivedDataInfo may also include a copy of the archived data recovered from a phishing system. This element will be populated when, for example, an ISP takes down a phisher's web site and has copied the site data into an archive file. There are four types of archives currently supported, as specified in the type field. 4.13.1. type attribute REQUIRED. This parameter specifies the type of site data pointed to by the ArchivedDataURL, from the following list: 1. collectionsite. 2. basecamp. 3. sendersite. 4. credentialInfo. 5. unspecified. 4.13.2. ArchivedDataURL element Zero or one value of URL. As the archive of an entire site can be quite large, the ArchivedURL element points to an Internet-based server where the actual gzipped 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 gzipped archive file is located. Cain & Jevans Expires January 31, 2009 [Page 28] Internet-Draft IODEF Phishing Extensions July 2008 4.13.3. ArchivedDataComments element Zero or one value of STRING. This field is a free form area for comments on the archive and/or URL. 4.13.4. ArchivedData element Zero or one value of xs:Base64Binary. This field may contain a base64 encoded version of the data described in the comment field above. 4.14. RelatedData element Zero or more value of anyURI. This element allows the listing of other web or net sites that are related to this incident (e.g., victim site, etc.). 4.15. CorrelationData element Zero or more value of STRING. Any information that correlates this incident to other incidents can be entered here. 4.16. PRComments element Zero or one value of STRING. This field allows for any comments specific to this PhraudReport that does not fit in any other field. 4.17. EmailRecord element Extensions are also made to the iodef:Incident.EventData element to include the actual email message received in phishing lure or widespread spam emails. The ability to report spam is included within a PhraudReport to support exchanging information about large- scale spam activities related to phishing, not necessarily a single spam message to a user. As such the spam reporting mechanism was not designed to minimize overhead and processing, but to support other widely-used spam reporting formats such as the MAAWG's Abuse Reporting Format [ARF]. Reporting of the actual mail message is supported by choosing one of three methods. First, an ARF message may be included. Second, the message may be included as one large string. Third, the header and body components may be dissected and included as a series of strings. Cain & Jevans Expires January 31, 2009 [Page 29] Internet-Draft IODEF Phishing Extensions July 2008 +--------------------+ | EmailRecord | +--------------------+ | |<>--------------[ EmailCount ] | |<>--(0..1)--+---[ Email ] | | +---[ Message ] | | +---[ ARFText ] | |<>--(0..1)------[ EmailComments ] +--------------------+ +---------------+ | Email | +---------------+ | |<>---+----------[ EmailHeader ] | |<>--(0..1)------[ EmailBody ] +---------------+ +-------------+ | EmailHeader | +-------------+ | |<>--(1..*)--[ Header ] +-------------+ Figure 4.13: The EmailRecord element 4.17.1. EmailCount REQUIRED. INTEGER. This field enumerates the number of email messages identified in this record detected by the reporter. 4.17.2. Email Message Inclusion The actual wide-spread spam message may be included in a report via one of three encodings: an ARF message, one big text blob, or a separate header and body element. 4.17.2.1. Message Zero of one value of iodef:MLStringType. The entire mail message can be inserted as one large string. 4.17.2.2. ARFText Zero or one value of STRING. The Messaging Anti-Abuse Working Group (MAAWG) defined a format for sending abuse and list control traffic to other parties. Since many of these reports will get integrated into incident processes, the raw Abuse Reporting Format [ARF] may be Cain & Jevans Expires January 31, 2009 [Page 30] Internet-Draft IODEF Phishing Extensions July 2008 inserted into this element. The ARF should be encoded as a character string. 4.17.2.3. Email element 4.17.2.3.1. EmailHeader Element Sequence of Header. The headers of the phish email are included in this element as a sequence of one-line text strings. There SHALL be one EmailHeader element per EmailRecord. 4.17.2.3.1.1. Header iodef:MLStringType. The header element contains a sequence of email header lines, one line per header element. 4.17.2.3.2. EmailBody Element Zero or one value of iodef:MLStringType. This element contains the body of the phish email. If present, there should be at most one EmailBody element per EmailRecord 4.17.2.4. Message iodef:MLStringType. The entire mail message can be inserted as one large string. 4.17.3. EmailComments Element Zero or one value of STRING. This field contains comments or relevant data not placed elsewhere about the phishing or spam email. Cain & Jevans Expires January 31, 2009 [Page 31] Internet-Draft IODEF Phishing Extensions July 2008 5. IODEF Required Elements A report about fraud, spam, or phishing requires certain identifying information which is contained within the standard IODEF Incident data structure and the PhraudReport extensions. The following table identifies attributes required to be present in a compliant PhraudReport to report phishing or fraud or to report widespread spam. The required attributes are a combination of those required by the base IODEF element and those required by this document. Attributes identified as required SHALL be populated in conforming phishing activity reports. The following table is a visual description of the IODEF-Document required fields. 5.1. Fraud or Phishing Report A compliant IODEF PhraudReport is SHALL contain the following element and attributes: Cain & Jevans Expires January 31, 2009 [Page 32] Internet-Draft IODEF Phishing Extensions July 2008 5.2. Wide-Spread Spam Report An IODEF PhraudReport compliant Spam Activity Report SHALL contain the following elements and attributes: = spamreport Cain & Jevans Expires January 31, 2009 [Page 33] Internet-Draft IODEF Phishing Extensions July 2008 5.3. Guidance on Usage It may be apparent that the mandatory attributes for a phishing activity report make for a quite sparse report. As incident forensics and data analysis require detailed information, the originator of a PhraudReport SHOULD include any tidbit of information gleaned from the attack analysis. Information that is considered sensitive can be marked as such using the restriction parameter of each data element. The reporting party is advised to supply as much information abut the event as possible -- or even more -- as the information may be volatile and not recoverable in the future to answer investigation questions or to perform correlation with other events. Cain & Jevans Expires January 31, 2009 [Page 34] Internet-Draft IODEF Phishing Extensions July 2008 6. Security Considerations This document specifies a format for encoding a particular class of security incidents 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. 6.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, the application of 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.. 6.2. Using the iodef:restriction attribute In some instances data values in particular elements may contain data deemed sensitive by the reporter. Although there are no general- purpose rules on when to mark certain values as "private" or "need- to-know" via the iodef:restriction attribute, the reporter is cautioned to not apply element-level sensitivity markings unless they believe the receiving party (i.e., the party they are exchanging the event report data with) has a mechanism to adequately safeguard and process the data as marked. For example, if the PhraudReport element is marked private and contains a phishing collector URL in the DCSite/SiteURL element, can that URL be included within a block list distributed to other parties? No guidance is provided here except to urge exchanging parties to review the IODEF and PhraudReport documents to decide on common marking rules. Cain & Jevans Expires January 31, 2009 [Page 35] Internet-Draft IODEF Phishing Extensions July 2008 7. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688] Registration request for the IODEF phishing namespace: URI: urn:ietf:params:xml:ns:iodef-phish-1.0 Registrant Contact: See the "Author's Address" 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 "Author's Address" section of this document. XML: See the "Phishing Extensions Schema Definition" in the section of this document. Cain & Jevans Expires January 31, 2009 [Page 36] Internet-Draft IODEF Phishing Extensions July 2008 8. Contributors The extensions are an outgrowth of the Anti-Phishing Working Group (APWG) activities in data collection and sharing of phishing and other ecrime-ware. This document has received significant assistance from two groups addressing the phishing problem: members of the Anti-Phishing Working Group and participants in the Financial Services Technology Consortium's Counter-Phishing project. Cain & Jevans Expires January 31, 2009 [Page 37] Internet-Draft IODEF Phishing Extensions July 2008 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealing, M., "The IETF XML Registry", RFC 3688, January 2004. [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-1, May 1994. 9.2. Informative References [ARF] The Messaging Anti-Abuse Working Group (MAAWG), "Abuse Reporting Format", May 2005. [CRISP] Newton, L. and A. Neves, "Domain Registry Version 2 for the Internet Registry Information Service", RFC 3982, January 2005. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", RFC 4933, May 2007. Cain & Jevans Expires January 31, 2009 [Page 38] Internet-Draft IODEF Phishing Extensions July 2008 Appendix A. Appendix A. Phishing Extensions XML Schema Cain & Jevans Expires January 31, 2009 [Page 40] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 41] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 42] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 43] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 44] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 46] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 47] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 48] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 49] Internet-Draft IODEF Phishing Extensions July 2008 Cain & Jevans Expires January 31, 2009 [Page 50] Internet-Draft IODEF Phishing Extensions July 2008 Appendix B. Example Virus Report This section shows a received electronic mail message that included a virus in a zipped attachment and a report that was generated for that message. B.1. Received Email From: support@example.com Sent: Friday, June 10, 2005 3:52 PM To: pcain@example.com Subject: You have successfully updated your password Attachments: updated-password.zip Dear user pcain, You have successfully updated the password of your Coopercain account. If you did not authorize this change or if you need assistance with your account, please contact Coopercain customer service at: support@coopercain.com Thank you for using Coopercain! The Coopercain Support Team +++ Attachment: No Virus (Clean) +++ Coopercain Antivirus - www.example.com B.2. Generated Report NOTE: Some wrapping and folding liberties have been applied to fit it into the margins. PAT2005-06 2005-06-22T08:30:00-05:00 This is a test report from actual data. Cain & Jevans Expires January 31, 2009 [Page 51] Internet-Draft IODEF Phishing Extensions July 2008 patcain pcain@coopercain.com 2005-06-21T18:22:02-05:00 Subject: You have successfully updated your password Cooper-Cain
192.0.2.18
 W32.Mytob.EA@mm 2005-06-10T15:52:11-05:00
192.0.2.18
 1 "Return-path: <support@coopercain.com>" Envelope-to: pcain@example.com Delivery-date: Fri, 10 Jun 2005 15:52:11-0400 Received: from dsl231-063-162.sea1.dsl.example.net ([192.0.2.18] helo=example.com) by mail06.example.com with esmtp (Exim) id 1DgpXy-0002Ua-IR for pcain@example.com; Fri, 10 Jun 2005 15:52:10-0400 From: support@example.com To: pcain@example.com Subject: You have successfully updated yourn password Date: Fri, 10 Jun 2005 12:52:00 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_0911068B.E7EB6D2A" X-Priority: 3 X-MSMail-Priority: Normal X-EN-OrigIP: 192.0.2.18 X-EN-OrigHost: dsl231-063-162.sea1.dsl.example.net X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on Cain & Jevans Expires January 31, 2009 [Page 52] Internet-Draft IODEF Phishing Extensions July 2008 Scan18.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 To:pcain@example.com Subject: You have successfully updated your password Attachments: updated-password.zip Dear user pcain, You have successfully updated the password of your example account. If you did not authorize this change or if you need assistance with your account, please contact example customer service at: support@example.com Thank you for using example! The Example Support Team +++ Attachment: No Virus (Clean) +++ example Antivirus - www.example.com Cain & Jevans Expires January 31, 2009 [Page 53] Internet-Draft IODEF Phishing Extensions July 2008 Appendix C. Sample Phishing Report A sample report generated from a received electronic mail phishing message in shown in this section. C.1. Received Lure Return-path: Envelope-to: pcain@example.com Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400 Received: from mail15.yourhostingaccount.com ([10.1.1.161] helo=mail15.yourhostingaccount.com) by mailscan38.yourhostingaccount.com with esmtp (Exim) id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400 Received: from [24.147.114.61] (helo=TSI) by mail15.yourhostingaccount.com with esmtp (Exim) id 1Fq5Bj-0006dv-6b for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400 Received: from User ([66.59.189.157]) by TSI with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jun 2006 02:24:30 -0400 Reply-To: From: "company" Subject: * * * Update & Verify Your 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: X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC) FILETIME=[072A66A0:01C68EB2] X-EN-OrigSender: service@company.com X-EN-OrigIP: 192.0.2.1 X-EN-OrigHost: unknown Company Account Update Request Cain & Jevans Expires January 31, 2009 [Page 54] Internet-Draft IODEF Phishing Extensions July 2008 Dear Company. 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 company account can be done at any time by clicking on the link shown below http://www.company.com/cgi-bin/webscr?cmd=_login-run 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 (401) 938-3600, or write us at: Company, Inc. P.O. Box 0 Anytown, MA 98765 Sincerely, Big Company C.2. Phishing Report CC200600000002 2006-06-13T21:14:56-05:00 This is a sample phishing email received report. The phish was actually received as is. 85 patcain pcain@example.com 2006-06-13T05:37:21-04:00 * * * Update & Verify Your Company Account * * * company
192.0.2.2
 2006-06-13T05:37:22-04:00 1 Return-path: <service@company.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; Cain & Jevans Expires January 31, 2009 [Page 56] Internet-Draft IODEF Phishing Extensions July 2008 Tue, 13 Jun 2006 05:37:21 -0400 Received: from [192.0.2.2] (helo=bob) by mail15.example.com with esmtp (Exim) id 1Fq5Bj-0006dv-6b for pcain@coopercai n.com; Tue, 13 Jun 2006 05:37:21 -0400 Received: from User ([192.0.2.4]) by Bob with Microsoft SMTPSV C(5.0.2195.6713); Tue, 13 Jun 2006 02:24:30 -0400 Reply-To: <no spa@nospa.us> From: "company"<service@company.com> Subject: * * * Update & Verify Your 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=[07 2A66A0:01C68EB2] X-EN-OrigSender: service@company.com X-EN-OrigIP: 192.0.2.4 X-EN-OrigHost: unknown company<http://www.company.com/images/company _logo.gif> <http://www.company.com/images/pixel.gif> <htt p://www.company.com/images/pixel.gif> <http://www.company.com/im ages/pixel.gif> Account Update Request Dear company. member:, You are receiving this notification because company is required by law to notify you, that you urgently need to update your online account st atement, due to high risks of fraud intentions. The updating of your company account can be done at any time by click ing on the link shown below http://www.company.com/cgi-bin/webscr?cmd =_login-run <http://217.136.251.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 Histo ry sub tab of your Account Overview page to see your most recent sta tement. If you need help with your password, click the Help link whi ch is at the upper right hand side of the company website. To report errors in your statement or make inquiries, click the Contact Us lin k in the footer on any page of the company website, call our Customer Service center at (402) 938-3630, or write us at: company, Inc. P.O. Box 45950 Omaha, NE 68145 Sincerely, company <http://www.company.c om/images/dot_row_long.gif> http://217.136.251.41:8080/.cgi-bin/.webscr/.secure- login/%20%20/.company.com/index.htm Cain & Jevans Expires January 31, 2009 [Page 57] Internet-Draft IODEF Phishing Extensions July 2008 adsl.skynet.be 2006-06-14T13:05:00-05:00 2000-12-13T00:00:00 ns1.example.net
192.0.2.18
 Cain & Jevans Expires January 31, 2009 [Page 58] Internet-Draft IODEF Phishing Extensions July 2008 Authors' Addresses Patrick Cain The Cooper-Cain Group, Inc. P.O. Box 400992 Cambridge, MA 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 Cain & Jevans Expires January 31, 2009 [Page 59] Internet-Draft IODEF Phishing Extensions July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Cain & Jevans Expires January 31, 2009 [Page 60]