INCH P. Cain Internet-Draft The Cooper-Cain Group, Inc. Expires: December 16, 2006 D. Jevans The Anti-Phishing Working Group June 14, 2006 Extensions to the IODEF-Document Class for Phishing, Fraud, and Other Crimeware draft-ietf-inch-phishingextns-03 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 December 16, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document extends the INCH WG's IODEF XML incident reporting format for reporting phishing, fraud, other types of electronic crime, and widespread spam incidents. Although the term "phishing attack" is used, the data format extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud life cycle and extensible enough to be used for Cain & Jevans Expires December 16, 2006 [Page 1] Internet-Draft IODEF Phishing Extensions June 2006 other types of electronic crime incidents, along with simple spam. The extensions support very simple reporting as well as optional fields for detailed forensic reports, and support single phish/fraud incidents as well as consolidated reports of multiple phish incidents. Sections 1 and 2 of this document introduce the high-level report format. Sections 3 and 4 describe the data elements of the fraud extensions. This document includes an XML schema for the extensions and a few example fraud reports. 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 inRFC 2119 [RFC2119]. Cain & Jevans Expires December 16, 2006 [Page 2] Internet-Draft IODEF Phishing Extensions June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Why a Common Report Format is Needed . . . . . . . . . . . 4 1.2. Relation to the INCH IODEF Data Model . . . . . . . . . . 5 2. The Elements of Phishing/Fraud Activity . . . . . . . . . . . 7 3. Fraud Actvitiy Reporting via an IODEF-Document Incident . . . 8 4. PhraudReport Element Definitions . . . . . . . . . . . . . . . 10 4.1. Version parameter . . . . . . . . . . . . . . . . . . . . 11 4.2. Identifying A Fraud campaign . . . . . . . . . . . . . . . 11 4.3. FraudedBrandName Element . . . . . . . . . . . . . . . . . 13 4.4. LureSource Element . . . . . . . . . . . . . . . . . . . . 13 4.5. OriginatingSensor Element . . . . . . . . . . . . . . . . 20 4.6. The Data Collection Site Element (DCSite) . . . . . . . . 22 4.7. TakeDownInfo Element . . . . . . . . . . . . . . . . . . . 23 4.8. ArchivedData Element . . . . . . . . . . . . . . . . . . . 24 4.9. RelatedData Element . . . . . . . . . . . . . . . . . . . 25 4.10. CorrelationData Element . . . . . . . . . . . . . . . . . 25 4.11. PRComments Element . . . . . . . . . . . . . . . . . . . . 25 4.12. EmailRecord Element . . . . . . . . . . . . . . . . . . . 25 5. IODEF Required Elements . . . . . . . . . . . . . . . . . . . 28 5.1. Fraud or Phishing Report . . . . . . . . . . . . . . . . . 28 5.2. Wide-Spread Spam Report . . . . . . . . . . . . . . . . . 29 5.3. Guidance on Usage . . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . . 34 Appendix A. Phishing Extensions XML Schema . . . . . . . . . . . 35 Appendix B. Sample Malware Email Report . . . . . . . . . . . . . 47 B.1. Received Email . . . . . . . . . . . . . . . . . . . . . . 47 B.2. Generated Report . . . . . . . . . . . . . . . . . . . . . 47 B.3. Notes and Commentary . . . . . . . . . . . . . . . . . . . 49 Appendix C. Sample Phish Email Report . . . . . . . . . . . . . . 50 C.1. Received Lure . . . . . . . . . . . . . . . . . . . . . . 50 C.2. Phishing Report . . . . . . . . . . . . . . . . . . . . . 51 C.3. Notes and Commentary . . . . . . . . . . . . . . . . . . . 55 Appendix D. Sample Spam Report . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . . . 58 Cain & Jevans Expires December 16, 2006 [Page 3] Internet-Draft IODEF Phishing Extensions June 2006 1. Introduction Deception activities on the Internet, such as receiving an email purportedly from a bank requesting you to confirm your account information, are an expanding attack type in the Internet. For this document, the two terms phishing and fraud are used interchangeably and characterize as 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). A successful phishing attack on an individual allows the phisher (i.e., attacker) to exploit the individual's credentials for financial or other gain. Early phishing attacks were directed at individuals via email as a ruse from a bank security department, requesting the user's ATM number and PIN. Once phished, the bank account could be used by the phisher to perpetrate additional fraud, money laundering, or plain emptying of the account. As individuals became more aware of phishing tactics, the phishers have evolved into using more complex and stealthier technologies targeting institutions such as ISPs and corporations other than banks. These attacks have now morphed to use the lure to deliver all types of malware and other crimeware onto users' computers. Other miscreants are also using these same techniques for other types of Internet attacks. 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 data collected allows them to better plan out mitigation activities and to initiate or assist in prosecution of the attacker. Early on it became obvious that a common format for the data reported or exchanged between these parties was necessary. The IETF INCH XML format was selected for this use as it was already becoming a standard way of sharing this type of information. Although originally designed for network-layer incident sharing (e.g., DoS attacks, compromised computers) the INCH format can be extended quite easily to support other incident profiles, as we show in this document. The use of a common format will help organizations integrate multiple product outputs into a cohesive single attack view. It will also allow for the introduction of advanced services such as wholly automatic local notifications and usable data mining. The accumulation and correlation of information is very important when dealing with security incidents. In phishing attacks Cain & Jevans Expires December 16, 2006 [Page 4] Internet-Draft IODEF Phishing Extensions June 2006 specifically, the attack source may be misrepresented or forged. The targeted organization may not even be aware of the ongoing attack. Third parties aware of the attack may wish to notify the targeted organization or a central notification service. The targeted organization's internal monitoring systems may also detect the attack and wish to take mitigation steps. Without this document, there is no recognized standard format to express the detection of a phishing attack or to exchange detailed information about it. For an organization that employs multi anti-phishing technologies, correlating data from multiple vendors or products is close to impossible as the data is reported in multiple, mostly incompatible, formats. This document defines a data format extension to IODEF that is used to capture relevant information from a phishing attack and shared, correlated, or to populate a database. Additionally, the use of products that export information in this format will allow an organization to correlate and analyze phishing information across their organization. Although targeted at both the accumulation of phishing attack information from a single institution and a means of sharing attack information between cooperating parties, the actual information sharing process and related political challenges are not covered in this document. 1.2. Relation to the INCH IODEF Data Model Instead of defining report format and language from scratch, the phishing activities information is encoded as XML extensions to the Incident Object Description Exchange Format Data Model[IODEF]. The use of this already existent and operational format, based on the Intrusion Detection Message Exchange Format[IDMEF], allows for quicker vendor adoption and reuse of existing tools in organizations. To reduce duplication and to be compatible with forward modifications to the base IODEF definitions, this document only identifies additional structures necessary for exchanging phishing and e-crime information. The goal of using a common format is to be simple and efficient, and to support additional data to be included to provide a complete picture of the event, when necessary. One criticism of the IODEF format is that it is too cumbersome (i.e., large and complex) to be used in an efficient manner for something as simple as fraud events. The IODEF format has very few required elements to allow for efficiency, but allows extremely verbose elements to be used if supporting data is available. This flexibility allows the IODEF formats to be used in a wide range of event reports but only requires the product developer to support one format standard. Cain & Jevans Expires December 16, 2006 [Page 5] Internet-Draft IODEF Phishing Extensions June 2006 1.2.1. The IODEF Extensions for Fraud In general, an IODEF incident report contains detailed incident- specific data which populates an EventData Structure. That data is then incorporated, either singularly or in aggregation, with additional summary and contact data, into an Incident structure. A Fraud Activity Report is an instance of an XML IODEF-Document with added EventData and AdditionalData elements. It contains the Incident structure and additional fields in the EventData specific to phishing and fraud (the PhraudReport). Phishing activity may include multiple email, instant message, or network messages, scattered over various times, locations, and methodologies. The new EventData fields are combined into a Fraud Activity Report and 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, the Fraud Activity Reports may be combined into one EventData structure. 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 elements for the EventData and Record Item IODEF XML elements and identifies the Fraud Activity Report required attributes. The Appendices contain sample Fraud Activity Reports and a complete Schema. The IODEF Extensions defined in this document comply with section4, "Extending the IODEF Format" in[IODEF]. As both the IODEF-Document and PhraudReport documents have many options a companion implementer's guide and report examples document is being developed to assist implementers with consistency. Cain & Jevans Expires December 16, 2006 [Page 6] Internet-Draft IODEF Phishing Extensions June 2006 2. The Elements of Phishing/Fraud Activity +-----------+ +------------------+ | Fraudster |<---<-- | Collection Point |<---O--<----<----+ +----+------+ +------------------+ | | ^ | | | +--|-----+ ^ | | Sensor | Credentials | +-|------+ | | +---------------+ | +-------+ \--->--| Attack Source |--Phish-->-----O------> | User/ | +---------------+ |Victim | +-------+ 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, where the phishing email, virus, trojan, or other attack is generated. 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, which is something that detects the fraud/phish attempt or success. This element may be an intrusion detection system, firewall, filter, email gateway, or human. 6. A forensic or archive site where an investigator has copied or otherwise retained the data used for the fraud attempt or credential collection. Cain & Jevans Expires December 16, 2006 [Page 7] Internet-Draft IODEF Phishing Extensions June 2006 3. Fraud Actvitiy Reporting via an IODEF-Document Incident A Fraud Activity Report is an instance of an XML IODEF-Document with added EventData, AdditionalData elements. The added elements compose a PhraudReport Element. Required information with many optional items is populated into the PhraudReport structure to form a Fraud Activity Report. To facilitate usefulness, the report originator should fill out all mandatory items and as many as necessary optional Incident element fields, to stay consistent with the IODEF-Document structure. This document defines new EventData IODEF XML elements; then identifies attributes that are required in a compliant Fraud Activity Report. The Appendices contain sample Fraud Activity Reports and the complete XML Document Type Definition and schema. The Incident element with fraud extensions is summarized below. It provides a standardized representation for commonly exchanged incident data and associates a CSIRT assigned unique identifier with the described activity. The data elements in this document are expressed in Unified Modeling Language (UML) syntax. +-------------------+ | Incident | +-------------------+ | ENUM purpose |<>----------[ IncidentID ] | ENUM restriction |<>--{0..1}--[ AlternativeID ] | |<>--{0..1}--[ RelatedActivity ] | |<>--{0..*}--[ Description ] | |<>--{1..*}--[ Assessment ] | |<>--{0..*}--[ Method ] | |<>--{0..1}--[ DetectTime ] | |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ EndTime ] | |<>----------[ ReportTime ] | |<>--{1..*}--[ Contact ] | |<>--{0..*}--[ Expectation ] | |<>--{0..1}--[ History ] | |<>--{0..*}--[ EventData ] | | --> [ AdditionalData ] | | --> PhraudReport (added) +------------------+ Figure 1. The IODEF XML Incident Element (modified) A Fraud Activity Report is composed of one IODEF Incident element, containing one or more EventData elements that contain one or more PhraudReport elements. This document defines the PhraudReport element for the Incident.EventData.AdditionalData element comprising Cain & Jevans Expires December 16, 2006 [Page 8] Internet-Draft IODEF Phishing Extensions June 2006 of phishing and fraud-related information that does not map to existing Incident or EventData attributes. Some additional attributes are defined to capture electronic mail header and routing information. One Incident report may contain information on multiple incidents. After the report identification information listed in the Incident element, each individual event is detailed within a single EventData structure. Cain & Jevans Expires December 16, 2006 [Page 9] Internet-Draft IODEF Phishing Extensions June 2006 4. PhraudReport Element Definitions A PhraudReport consists of an extension to the Incident AdditionalData Element. The elements of the PhraudReport will identify and capture information related to the six components of fraud activity identified earlier. Other forensic information and commentary can be added by the reporter as necessary to show relation to other events, the output of an investigation, or for archival purposes. A PhraudReport accommodates the six elements this way: Identification fields (PhishNameRef and LocalPhishName Ref) exist to identify the fraudster or class of fraudster. The LureSource element contains information about the source of the attack or phishing lure, including host information and any included malware. Fields exist to include the entire email, web, IM, or other-based lure. There are elements to identify the targeted brand name(s). The DCData holds a description and technical details on the credential collection point. The means of detection is described in the Originating Sensor element. AdditonalData, RelatedData, ArchivedData and TakeDownInfo fields allow optional forensics and history data. A PhraudReport element is structured as follows. Cain & Jevans Expires December 16, 2006 [Page 10] Internet-Draft IODEF Phishing Extensions June 2006 +--------------------------+ | EventData.AdditionalData | +--------------------------+ | ENUM type (9 = xml) |<>---------[ PhraudReport ] | STRING meaning (xml) | +--------------------------+ +-----------------+ | PhraudReport | +-----------------+ | ENUM Version |<>--(0..1)--[ PhishNameRef ] | ENUM FraudType |<>--(0..1)--[ PhishNameLocalRef ] | |<>--(0..1)--[ FraudParameter ] | |<>--(0..*)--[ FraudedBrandName ] | |<>--(1..*)--[ LureSource ] | |<>----------[ OriginatingSensor ] | |<>--(0..1)--[ EmailRecord ] | |<>--(0..*)--[ DCSite ] | |<>--(0..*)--[ TakeDownInfo ] | |<>--(0..*)--[ ArchivedData ] | |<>--(0..*)--[ RelatedData ] | |<>--(0..*)--[ CorrelationData ] | |<>--(0..1)--[ PRComments ] +-----------------+ Figure 2. The PhraudReport Extensions to the INCH XML Incident.AdditionalData Element The components of a PhraudReport are introduced in functional grouping as some parameters are related and some elements may not make sense individually. 4.1. Version parameter One value of STRING. The version shall be the value 0.3 to be compliant with this document. 4.2. Identifying A Fraud campaign At times it may be useful to identify a specific phish or fraud for future analysis, much like the anti-virus vendors identify certain viruses. A specific phish/fraud activity can be identified using a combination of the FraudType, FraudParameter, FraudedBrandName, LureSource, and PhishRefName elements. 4.2.1. PhishNameRef Element Zero or one value of STRING. This value is a friendly-name for this fraud event. It may be agreed upon by vendor collaboration to note a Cain & Jevans Expires December 16, 2006 [Page 11] Internet-Draft IODEF Phishing Extensions June 2006 common name for a given phish attack or "campaign". The agreed upon identifier could be useful in collaboration, support, media and public education. 4.2.2. PhishNameLocalRef Element Zero or one value of STRING. Many contributors will have a local reference name or Unique-IDentifier (UID) that will be used before a commonly agreed term is adopted in PhishNameRef. This field allows a cross-reference from the submitting organization's system to the central repository. 4.2.3. FraudType Parameter One required value of ENUM from this list. The FraudType attribute contains a number representing the type of fraud attempted. The Email element has been separated into multiple numbers to support the primary types of lure email. The value of the FraudParameter is dependent on the choice of the FraudType Parameter. 1. PhishEmail, and the FraudParameter is 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, and 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, and 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, with no FraudParameter. This identifies a known fraudulent site that does not necessarily send spam but is used for lures. 5. DNSspoof, with no 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). 6. Keylogger downloaded with lure, with no FraudParameter. 7. OLE, no FraudParameter. This identifies background Microsoft Object Linking and Embedding (OLE) information that comes as part of a lure. Cain & Jevans Expires December 16, 2006 [Page 12] Internet-Draft IODEF Phishing Extensions June 2006 8. IM. The FraudParameter should be the malicious instant message (IM) link supplied to the user. 9. CVE-known malware, with the Common Vulnerability and Exposures project (CVE) number as the FraudParameter. 10. SiteArchive, with the data archived from the phishing server placed in the ArchiveInfo element. 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, to identify as-yet-enumerated fraud types. 14. Unknown. 4.2.3.1. FraudParameter Element One value of a multilingual STRING. This is the lure used to attract victims. It may be the email subject line, the VoIP lure, the link in IM; 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 PhishParameter field. 4.3. 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. Some schemes, such as those enticing "mules" for money laundering or related activities, may use a lesser known or fictitious brand [e.g., xyz semiconductor company]. Those brand identifiers should also populate this field. 4.4. LureSource Element This element describes the source of the phishing or crimeware lure. Elements are included to allow for entering the IP Addresses, DNSNames, and Domain Registry information of the source of the lure and some rudimentary information about the files downloaded and Windows registry keys modified by the crimeware. Cain & Jevans Expires December 16, 2006 [Page 13] Internet-Draft IODEF Phishing Extensions June 2006 +-------------+ | LureSource | +-------------+ | |<>--(1..*)--[ System ] | |<>--(0..*)--[ DomainData ] | |<>--(0..1)--[ IncludedMalware ] | |<>--(0..1)--[ FilesDownloaded ] | |<>--(0..1)--[ RegistryKeysModified ] +-------------+ 4.4.1. System Element One or more values of IODEF:SYSTEM. Many times the phishing, spam, or fraud lure email is received from a spoofed IP address. If the real IP Address can be ascertained it should be populated into this field. A spoofed address may also be entered, but the spoofed attribute SHALL be set. The field uses the IODEF System element to capture the Address and to allow for support of IPv6 and port numbers. 4.4.2. DomainData Element The DomainData element holds information about the registration, delegation, and control of the IPAddress used to source the lure. Many phishers use the DNS system to their advantage moving domain names and addresses repeatedly to avoid disruption. A DomainData element can be used to (repeatedly) capture detailed domain data to detect fraudster patterns and to allow for the quick updating of network filters. There may be multiple values of this element to track the Domain data as the lure DNS entry changes. 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..16)-[ Nameservers ] | |<>--(0..*)--[ DomainContacts ] +--------------------+ +----------------+ | DomainContacts | +----------------+ | |<>--(0..1)--[ SameDomainContact ] | |<>--(0..1)--[ Contact ] Cain & Jevans Expires December 16, 2006 [Page 14] Internet-Draft IODEF Phishing Extensions June 2006 +----------------+ 4.4.3. Name One value of MLStringType. This field should contain the domain Name. 4.4.4. DateDomainWasChecked Zero or One value of DATETIME to show when this domain data was checked and entered into this report. 4.4.5. RegistrationDate Zero or one value of DATETIME to note when this domain was registered. 4.4.6. ExpirationDate Zero or one value of DATETIME to note when this domain registration will expire. 4.4.7. Nameservers Zero or multiple sets of DNSNAME and ADDRESS elements. These fields hold nameservers identified for this domain. The element is artificially limited to 16 nameserver entries. 4.4.8. DomainContacts Choice of either a SAMEDOMAINCONTACT or an unbounded set of DOMAINCONTACT values. The DomainContacts element allows the reporter to enter contact information supplied by the registrar or 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. +--------------------+ | Contact | +--------------------+ | |<>----------[ ContactName ] | |<>--(0..*)--[ Description ] | ENUM Role |<>--(0..*)--[ RegistryHandle ] | ENUM Confidence |<>--(0..1)--[ PostalAdress ] | ENUM Restriction |<>--(0..*)--[ Email ] | |<>--(0..*)--[ Telephone ] | |<>--(0..1)--[ Fax ] | |<>--(0..1)--[ Timezone ] Cain & Jevans Expires December 16, 2006 [Page 15] Internet-Draft IODEF Phishing Extensions June 2006 +--------------------+ 4.4.8.1. SameDomainContact One DNSNAME. This field is populated if the contact information for this domain is identical to another DNSNAME element in this or another report. 4.4.8.2. DomainContact Element This element reuses 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. The permissible elements are: ContactName. Description. RegistryHandle. PostalAddress. Email. Telephone. Fax. Timezone. Each Contact has three attributes to capture the sensitivity, confidence, and role that the contact is listed for. 4.4.8.2.1. Role Attribute ENUM. The role values are imported from [CRISP]. They may be valued as follows. Registrant. Registrar. Billing. Technical. Cain & Jevans Expires December 16, 2006 [Page 16] Internet-Draft IODEF Phishing Extensions June 2006 Administrative. Legal. Zone. Abuse. Security. Other. 4.4.8.2.2. Confidence Attribute One ENUM value. The Confidence attribute allows a reporter to value- judge the information provided in this report. There are five possible values as follows. 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 this domain registration. Looks-fraudulent. The contact information has suspicious information included. Known-real. The contact information has been previously investigated or determined to be correct. Looks-real. The contact information does not arise suspicion but has not been previously validated. Unknown. The reporter cannot make a value judgment on the contact data. 4.4.8.2.3. Restriction Attribute Zero or one value of iodef:RESTRICTION element, to allow sensitive information to be adequately marked. 4.4.9. SystemStatus Attribute ENUM. This attribute allows a report to note their estimation of this domain involved in this event. After investigation, a reporter may be able to assess the likelihood that this domain contributed willingly, knowingly, inadvertently, or was not involved in the reported event. Cain & Jevans Expires December 16, 2006 [Page 17] Internet-Draft IODEF Phishing Extensions June 2006 1. Spoofed. This domain or system did not participate but its address space or DNS name was forged in this event. 2. Fraudulent. The system is fraudulently operated. 3. Innocent-Hacked. The system was compromised and used to source the lure. 4. Innocent-Hijacked. The IP Address or domain name was hijacked and used as the source of the lure. 5. Unknown. No conclusions are inferred from this event. 4.4.10. DomainStatus Attribute ENUM. This attribute allows a reported to note the registry status of this domain at the time of the report. The enumerated list is taken verbose from the 'domainStatusType' of the Extensible Provisioning Protocol[RFC3733]and "Domain Registry Version 2 for the Internet Registry Information Service" internet-draft[CRISP]. 1. - permanently inactive 2. - normal state 3. - registration assigned but delegation inactive 4. - dispute 5. - database purge pending 6. - change of authority pending 7. - on hold by registry 8. - on hold by registrar 4.4.11. IncludedMalware Element This elelment 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. Cain & Jevans Expires December 16, 2006 [Page 18] Internet-Draft IODEF Phishing Extensions June 2006 +------------------+ | IncludedMalware | +------------------+ | |<>--(1..*)--[ Name ] | |<>--(0..1)--[ Hashvalue ] | |<>--(0..1)--[ Data ] +------------------+ +--------------+ | Data | +--------------+ | STRING | | | | XORPattern | +--------------+ 4.4.11.1. Name One or more value of MLSTRINGTYPE. This optional field is used to identify the lure malware. 4.4.11.2. Hashvalue Zero or one value of STRING. This optional field is used to hold a hashvalue computed over the malware executable. 4.4.11.2.1. Algorithm Parameter REQUIRED ENUM. This field from the following list identifies the algorithm used to create this hashvalue. SHA1. Hashvalue as defined in[SHA] . 4.4.11.3. Data Zero or one value of STRING. This optional field is used to include the lure malware. [Note that STRING is a reasonably way to encode byte data.] 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 revocer the actual malware. Cain & Jevans Expires December 16, 2006 [Page 19] Internet-Draft IODEF Phishing Extensions June 2006 4.4.12. FilesDownloaded Element Zero or One value of STRING. The contents of this element are a collection of space-separated filenames downloaded by this lure. 4.4.13. RegistryKeysModified Element One value of the Keys sequence. The contents of the RegistryKeysModified element are sets of Keys and an optional Value as attribute. The structure is artificially limited to 32 entries. +-----------------------+ | RegistryKeysModified | +-----------------------+ | |<>--(1..32)--[ Keys ] +-----------------------+ +--------------+ | Keys | +--------------+ | STRING | | | | STRING Value | +--------------+ 4.4.13.1. Keys One STRING, representing the WINDOWS Operating System Registry Key Name. 4.4.13.2. Value Attribute One STRING, representing the value of the associated Key. 4.5. OriginatingSensor Element 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 in the Internet itself (i.e., it may be a local IDS system) nor is it required to be mechanical (e.g., humans are allowed). Multiple Originating Sensor Elements are allowed. Cain & Jevans Expires December 16, 2006 [Page 20] Internet-Draft IODEF Phishing Extensions June 2006 +---------------------+ | OriginatingSensor | +---------------------+ | ENUM OrigSensorType |<>------------[ DateFirstSeen ] | |<>---(0..1)---[ Name ] | |<>---(1..*)---[ System ] | |<>---(0..1)---[ Location ] +---------------------+ The OriginatingSensor requires a type value and identification of the entity that generated this report. 4.5.1. OrigSensorType Parameter A REQUIRED ENUM value from the following list, categorizing the function of this sensor: 1. Web. A web server or service. 2. WebGateway, as in a proxy or firewall. 3. MailGateway. 4. Browser, or browser-type element. 5. ISP-resident or network sensor. 6. Human or manual analysis. 7. Honeypot or other decoy device. 8. Other. 4.5.2. FirstSeen Element REQUIRED. DATETIME. This is the date and time that this sensor first saw this phishing activity. 4.5.3. Name Element MLSTRINGTYPE. This is the DNS name or other identifier of the entity that detected this event. 4.5.4. Address Element IODEF.SOURCE. This is the IPVersion, IPAddress, and optionally, port number of the entity that generated this report. Cain & Jevans Expires December 16, 2006 [Page 21] Internet-Draft IODEF Phishing Extensions June 2006 4.5.5. Location Element STRING. This is an optional location of the sensor. 4.6. The Data Collection Site Element (DCSite) Zero or more DCSITEDATA elements. This section captures the type, identifier, collection location, and other pertinent information about the credential gathering process by the fraudster. The data collection site is identified by three elements: the type of collector activity, what type of collector site, and the network location (i.e., URL, IP address, etc). Details about the domain, system, or owner of the DCSite can be inserted into the DomainData element. If the DCSite element is present, the DCSiteType element is required. Multiple DCSiteData elements are allowed. +-------------+ | DCSite | +-------------+ | ENUM DCType |<>--(0..*)---[ DCSiteData ] +-------------+ +------------------+ | DCSiteData | +------------------+ | ENUM DCSiteType |<>--+--------[ SiteURL ] | | +--------[ Emailsite ] | | +--------[ System ] | | +--------[ Unknown ] | |<>-----------[ DomainData ] +------------------+ 4.6.1. DCType Parameter ENUM. This element identifies the method of data collection, as determined by analyzing the victim computer, lure, or malware, and are selected from the following list. This element is coupled with the DCSiteData element to identify the data collection site. 1. Web. The user is redirected to a website to collect the data. 2. Email Form. The victim sends an email with credentials enclosed. Cain & Jevans Expires December 16, 2006 [Page 22] Internet-Draft IODEF Phishing Extensions June 2006 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.6.2. DCSiteData Element This element contains the IPAddress, URL, or other identification of the data collection site as selected by the DCType Parameter. 4.6.2.1. DCSiteType Parameter ENUM. This parameter tags the network address and other information in the DataCollectionSiteData element. 1. Web. Data from the victim is collected on a website. The website URL is included in the DCSitePointer. 2. Email. The victim emails credentials to the collection site. The email server DNS name is in the DCSitePointer. 3. IODEF.SYSTEM Element. This collection site uses other protocols to gather data from the victim. The DCSitePointer field is an IODEF System Element, holding the IP Version Protocol, IPAddress, and Port number of the collection site. The Protocol field defaults to TCP, if absent. 4. Unknown. The DCSitePointer data should be verbose to describe this type of site. 4.7. TakeDownInfo Element This element identifies the agency(s) that performed the removal or ISP-blockage of the phish or fraud collector site. A PhraudReport may have multiple TakeDownInfo elements to support activities where multiple agencies are active. 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. +-------------------+ | TakeDownInfo | +-------------------+ | |<>---(0..1)--[ TakeDownDate ] | |<>---(0..*)--[ TakeDownAgency ] | |<>---(0..*)--[ TakeDownComments ] Cain & Jevans Expires December 16, 2006 [Page 23] Internet-Draft IODEF Phishing Extensions June 2006 +-------------------+ 4.7.1. TakeDownDate Element Zero or one DATETIME. This is the date and time that takedown of the collector site occurred. 4.7.2. TakeDownAgency Element Zero or more STRING. This is a free form string identifying the agency that performed the takedown 4.7.3. TakeDownComments Element Zero or more STRING. A free form field to add any additional details of this takedown effort. 4.8. ArchivedData Element Zero or more values of the ArchivedData element are allowed. +-------------------+ | ArchivedData | +-------------------+ | ENUM Type |<>---(0..1)--[ ArchivedDataURL ] | |<>---(0..1)--[ ArchivedDataComments ] +-------------------+ The ArchivedData element is used to typecast and include a gzip archive file of a data collection site, base camp, or other site where the phisher developed their code. 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 three types of archives currently supported, as specified in the type field. 4.8.1. Type Parameter This parameter specifies the contents of the archive. 1. Data Collection Site. 2. Basecamp Site. 3. Sender Site. 4. Unspecified. Cain & Jevans Expires December 16, 2006 [Page 24] Internet-Draft IODEF Phishing Extensions June 2006 4.8.2. ArchivedDataURL Element Zero or one value of URL. Many times an investigator may want to include a copy of the actual malware, lure, or program executables that were received by the victim. As the executables can be quite large, this element will point to an Internet-based server where the executables can be retrieved from, a Fraud Report just points out where the archive is, and does not include it in the report. This is the URL where the gzip archive file is located. 4.8.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.9. RelatedData Element Zero or more value of STRING. This element allows the listing of other web or net sites that are related to this incident (e.g., victim site, etc). 4.10. CorrelationData Element Zero or more value of STRING. Any information that correlates this incident to other incidents can be entered here. 4.11. PRComments Element Zero or more value of STRING. This field allows for any comments specific to this PhraudReport that does not fit in any other field. 4.12. EmailRecord Element Extensions are also made to the INCH IODEF Incident EventData element to support descriptive information received in phishing lure or spam emails. The ability to report spam is included within a PhraudReport to support exchanging information about large-scale spam activities, not necessarily a single spam message to a user. As such the spam reporting mechanism was not designed to minimize overhead and processing and to support other widely-used spam reporting formats such as the MAAWG's ARF. Information related to the overall fraudulent activity is contained within the PhraudReport, while the EmailRecord element is used to capture forensic or detailed technical information about a specific attack. Incident Reports may have none, one, or multiple EmailRecords as its goal is to accumulate pertinent technical data Cain & Jevans Expires December 16, 2006 [Page 25] Internet-Draft IODEF Phishing Extensions June 2006 associated with a specific attack as an investigation continues. Reporting of the actual mail message is supported by choosing one of three methods. First, an AR 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. +--------------------+ | EmailRecord | +--------------------+ | |<>--------------[ EmailCount ] | |<>-+-+----------[ EmailHeader ] | | | |--(0..1)--[ EmailBody ] | | +----(0..1)--[ Message ] | | +----(0..1)--[ ARFText ] | |<>--(0..1)------[ EmailComments ] +--------------------+ 4.12.1. EmailCount Element REQUIRED NUMBER. This field enumerates the number of email messages identified in this record detected by the reporter. 4.12.2. ARFText Element 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 inserted into this element. The ARF should be encoded as a character string. 4.12.3. Message Element Zero or one value of STRING. The complete received email message is included within this element. 4.12.4. EmailHeader Element One value of STRING. 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 mailRecord 4.12.5. EmailBody Element Cain & Jevans Expires December 16, 2006 [Page 26] Internet-Draft IODEF Phishing Extensions June 2006 Zero or one value of STRING. This element contains the body of the phish email. If present, there should be at most one EmailBody element per EmailRecord 4.12.6. 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 December 16, 2006 [Page 27] Internet-Draft IODEF Phishing Extensions June 2006 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. The following table identifies attributes required to be present in a compliant PhraudReport. 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 and PhraudReport required fields. +--------------+ | Incident | +--------------+ | ENUM Purpose |---[ IncidentID ] | |---[ Assessment ] | | ---> [ Confidence ] | |---[ ReportTime ] | |---[ Contact ] | | ---> [ Role ] | | ---> [ Type ] | | ---> [ Name ] | |---[ EventData ] | | ---> [ AdditionalData] | | ---> [ FraudReport ] | | ---> [ FraudType ] | | ---> [ FraudParameter ] | | ---> [ FraudedBrandName ] | | ---> [ LureSource ] | | ---> [ OriginatingSensor ] | | +--------------+ 5.1. Fraud or Phishing Report A compliant IODEF PhraudReport is required to contain the following fields: Purpose IncidentID ReportTime Contact -> Role Cain & Jevans Expires December 16, 2006 [Page 28] Internet-Draft IODEF Phishing Extensions June 2006 Contact -> Type Contact -> Name Assessment EventData DetectTime AdditionalData PhraudReport FraudType FraudedBrandName LureSource OriginatingSensor 5.2. Wide-Spread Spam Report These following fields MUST be populated in an IODEF PhraudReport compliant Spam Activity Report: Incident Structure: IncidentID Purpose ReportTime Contact -> Role Contact -> Type Contact -> Name Cain & Jevans Expires December 16, 2006 [Page 29] Internet-Draft IODEF Phishing Extensions June 2006 Assessment EventData DetectTime AdditionalData PhraudReport FraudType == spamreport LureSource OriginatingSensor EmailRecord EmailCount EmailHeader or Message 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. Cain & Jevans Expires December 16, 2006 [Page 30] Internet-Draft IODEF Phishing Extensions June 2006 6. Security Considerations This document specifies the format of security incident data. As such, the security of transactions containing the incident report will vary from organization to organization. We do not want to burden the information exchange with unnecessary encryption requirements, as the transport service for the data exchange may provide adequate protections, or even encryption. The use of encryption is expected to be agreed upon on originator-recipient agreement. The critical security concern is that phishing activity reports may be falsified or the report may become corrupt during transit. In areas where transmission security or secrecy is necessary the application of a digital signature and/or message encryption on each report will counteract both of these concerns, the digital signature may be overkill for most activity report users as the goal is to notify others of the event. For this reason, phishing activity reports MAY be digitally signed with the optional IODEF XML signature, although we expect that each receiving entity will determine the need for this signature independently. Recipients of fraud reports SHALL be prepared to accept XML digitally signed reports and SHOULD support receiving encrypted reports. Cain & Jevans Expires December 16, 2006 [Page 31] Internet-Draft IODEF Phishing Extensions June 2006 7. IANA Considerations [This section will change before publication.] This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in . [XML] Registration request for the iodef 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 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" section of this document. Cain & Jevans Expires December 16, 2006 [Page 32] Internet-Draft IODEF Phishing Extensions June 2006 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 December 16, 2006 [Page 33] Internet-Draft IODEF Phishing Extensions June 2006 9. References 9.1. Normative References [IODEF] Meijer, J., Danyliw, and Demchenko, "The Incident Object Description Exchange Format Data Model and XML Implementation", October 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SHA] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", FIPS 180-1, May 1994. [XML] Mealing, M., "The IETF XML Registry", RFC 3688, January 2004. 9.2. Informative References [CRISP] Newton, L. and A. Neves, "Domain Registry Version 2 for the Internet Registry Information Service", May 2006. [IDMEF] Curry, D. and H. Debar, "The Intrusion Detection Message Exchange Format", July 2004. [RFC3733] Hollenbeck, "Extensible Provisioning Protocol (EPP) Contact Mapping", RFC 3733", RFC 3733, March 2004. Cain & Jevans Expires December 16, 2006 [Page 34] Internet-Draft IODEF Phishing Extensions June 2006 Appendix A. Phishing Extensions XML Schema A digital copy of this file is available to prevent errors when re- entering text. See www.coopercain.com/incidents . This is an EventData.AdditionalData structure for an IODEF Incident class. Cain & Jevans Expires December 16, 2006 [Page 35] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 36] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 37] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 38] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 39] Internet-Draft IODEF Phishing Extensions June 2006 Multiple domains with equal contact and registraton data can be referenced with the "sameas" entry. Cain & Jevans Expires December 16, 2006 [Page 40] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 42] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 43] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 44] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 45] Internet-Draft IODEF Phishing Extensions June 2006 Cain & Jevans Expires December 16, 2006 [Page 46] Internet-Draft IODEF Phishing Extensions June 2006 Appendix B. Sample Malware Email 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@coopercain.com Sent: Friday, June 10, 2005 3:52 PM To: pcain@coopercain.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.coopercain.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 December 16, 2006 [Page 47] Internet-Draft IODEF Phishing Extensions June 2006 patcain pcain@coopercain.com 2005-06-21T18:22:02-05:00 Subject: You have successfully updated your password Cooper-Cain
216.231.63.162
W32.Mytob.EA@mm
2005-06-10T15:52:11-05:00
10.0.0.4
1 "Return-path: <support@coopercain.com>" Envelope-to: pcain@coopercain.com Delivery-date: Fri, 10 Jun 2005 15:52:11-0400 Received: from dsl231-063-162.sea1.dsl.speakeasy.net ([216.231.63.162] helo=coopercain.com) by mail06.coopercain.com with esmtp (Exim) id 1DgpXy-0002Ua-IR for pcain@coopercain.com; Fri, 10 Jun 2005 15:52:10-0400 From: support@coopercain.com To: pcain@coopercain.com Subject: You have successfully updated yourn password Cain & Jevans Expires December 16, 2006 [Page 48] Internet-Draft IODEF Phishing Extensions June 2006 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: 216.231.63.162 X-EN-OrigHost: dsl231-063-162.sea1.dsl.speakeasy.net X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on Scan18.int.bizland.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@coopercain.com Sent: Friday, June 10, 2005 3:52 PM To:pcain@coopercain.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.coopercain.com
B.3. Notes and Commentary Cain & Jevans Expires December 16, 2006 [Page 49] Internet-Draft IODEF Phishing Extensions June 2006 Appendix C. Sample Phish Email Report A sample report generated from a received electronic mail phishing message in shoen in this section. C.1. Received Lure Return-path: Envelope-to: pcain@coopercain.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@coopercain.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@coopercain.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: "PayPal" Subject: * * * Update & Verify Your PayPal 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@paypal.com X-EN-OrigIP: 24.147.114.61 X-EN-OrigHost: unknown PayPal Account Update Request Cain & Jevans Expires December 16, 2006 [Page 50] Internet-Draft IODEF Phishing Extensions June 2006 Dear PayPal. member:, You are receiving this notification because PayPal 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 PayPal account can be done at any time by clicking on the link shown below http://www.paypal.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 PayPal website. To report errors in your statement or make inquiries, click the Contact Us link in the footer on any page of the PayPal website, call our Customer Service center at (402) 938-3630, or write us at: PayPal, Inc. P.O. Box 45950 Omaha, NE 68145 Sincerely, PayPal C.2. Phishing Report CC200600000002 Cain & Jevans Expires December 16, 2006 [Page 51] Internet-Draft IODEF Phishing Extensions June 2006 2006-06-13T21:14:56-05:00 This is a sample phishing email received report. The phish was actually received as is. patcain pcain@coopercain.com 2006-06-13T05:37:21-04:00 * * * Update & Verify Your PayPal Account * * * PayPal
24.147.114.61
2006-06-13T05:37:22-04:00 1 Return-path: <service@paypal.com> Cain & Jevans Expires December 16, 2006 [Page 52] Internet-Draft IODEF Phishing Extensions June 2006 Envelope-to: pcain@coopercain.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@coopercain.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@coopercain.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: <nospa@nospa.us> From: "PayPal"<service@paypal.com> Subject: * * * Update & Verify Your PayPal 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@paypal.com X-EN-OrigIP: 24.147.114.61 X-EN-OrigHost: unknown PayPal<http://www.paypal.com/images/paypal_logo.gif> <http://www.paypal.com/images/pixel.gif> <http://www.paypal.com/images/pixel.gif> <http://www.paypal.com/images/pixel.gif> Account Update Request Dear PayPal. member:, You are receiving this notification because PayPal 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 PayPal account can be done at any time by clicking on the link shown below http://www.paypal.com/cgi-bin/webscr?cmd=_login-run <http://217.136.251.41:8080/.cgi-bin/.webscr/.secure- login/%20/%20/.paypal.com/index.htm> Once you log in,update your account information. After Cain & Jevans Expires December 16, 2006 [Page 53] Internet-Draft IODEF Phishing Extensions June 2006 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 PayPal website. To report errors in your statement or make inquiries, click the Contact Us link in the footer on any page of the PayPal website, call our Customer Service center at (402) 938-3630, or write us at: PayPal, Inc. P.O. Box 45950 Omaha, NE 68145 Sincerely, PayPal <http://www.paypal.com/images/dot_row_long.gif> http://217.136.251.41:8080/.cgi-bin/.web scr/.secure-login/%20%20/.paypal.com/index.htm adsl.skynet.be 2006-06-14T13:05:00-05:00 2000-12-13T00:00:00 ns1.skynet.be
195.238.3.17
Cain & Jevans Expires December 16, 2006 [Page 54] Internet-Draft IODEF Phishing Extensions June 2006 C.3. Notes and Commentary Cain & Jevans Expires December 16, 2006 [Page 55] Internet-Draft IODEF Phishing Extensions June 2006 Appendix D. Sample Spam Report [ ed.To be supplied, but it looks a lot like the fraud report] Cain & Jevans Expires December 16, 2006 [Page 56] Internet-Draft IODEF Phishing Extensions June 2006 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 December 16, 2006 [Page 57] Internet-Draft IODEF Phishing Extensions June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cain & Jevans Expires December 16, 2006 [Page 58]