INCH D. Jevans Internet-Draft The Anti-Phishing Working Group Expires: June 14, 2005 P. Cain, Ed. The Cooper-Cain Group December 14, 2004 Extension to IODEF-Document Class for Phishing Reports draft-jevans-phishing-xml-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 June 14, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Phishing, a broadly-launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing credentials, is expanding on the Internet. Corporations, Service Providers, consumer agencies, and financial institutions have started to collect and correlate phishing attack information to better plan out mitigation activities and to assist in Jevans & Cain Expires June 14, 2005 [Page 1] Internet-Draft IODEF Phishing Reports December 2004 prosecution. Early on it became obvious that a common format for the data reported or exchanged between this parties was necessary. This document defines a data format for reporting phishing attacks and sharing data between repositories of phishing attacks. The format is an outgrowth of the Anti-Phishing Working Group (APWG) activities in data sharing and is based upon the Incident Handling Working Group's (INCH) XML-based format for sharing incident data. Although we use the term "phishing attack", the data format is flexible enough to support information gleaned from activities throughout the entire phishing life cycle. The attack format is also extensible enough to be used for other related reporting such as DNS spoofs (eg. localhost file takeover on PCs) and keyloggers typically related to the phishing attack. The format shall also support very simple reporting as well as optional fields for detailed reports and supports single phish reports as well as consolidated reports of multiple phish 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 in [RFC2119]. Jevans & Cain Expires June 14, 2005 [Page 2] Internet-Draft IODEF Phishing Reports December 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 INCH Dependencies . . . . . . . . . . . . . . . . . . . . 5 2. Phishing Actvitiy Reporting via an IODEF-Document Incident . 6 3. PhishingReport Class Definition . . . . . . . . . . . . . . 8 3.1 Version parameter . . . . . . . . . . . . . . . . . . . . 8 3.2 PhishType parameter . . . . . . . . . . . . . . . . . . . 8 3.3 PhishedBrandName element . . . . . . . . . . . . . . . . . 9 3.4 DataCollectionType element . . . . . . . . . . . . . . . . 9 3.5 DataCollectionSite class . . . . . . . . . . . . . . . . . 9 3.6 OriginatingSensor class . . . . . . . . . . . . . . . . . 10 3.7 TakeDownInfo class . . . . . . . . . . . . . . . . . . . . 11 3.8 ArchivedData element . . . . . . . . . . . . . . . . . . . 11 3.9 RelatedSites element . . . . . . . . . . . . . . . . . . . 12 3.10 CorrelationData element . . . . . . . . . . . . . . . . 12 3.11 Comments element . . . . . . . . . . . . . . . . . . . . 12 4. Definition of PhishRecord class . . . . . . . . . . . . . . 13 4.1 PhishRecord class . . . . . . . . . . . . . . . . . . . . 13 5. IODEF Required Elements . . . . . . . . . . . . . . . . . . 14 6. Guidance on Usage . . . . . . . . . . . . . . . . . . . . . 15 7. Sample Phishing Report . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Normative References . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 A. Phishing Data DTD . . . . . . . . . . . . . . . . . . . . . 20 B. Example of a Complete Phishing Activity Report . . . . . . . 26 C. Mapping from the APWG work into this Document . . . . . . . 27 C.1 Overall Format . . . . . . . . . . . . . . . . . . . . . . 29 C.2 Header Format . . . . . . . . . . . . . . . . . . . . . . 29 C.3 Individual Report Format . . . . . . . . . . . . . . . . . 30 D. Still To Do in This Document . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . 37 Jevans & Cain Expires June 14, 2005 [Page 3] Internet-Draft IODEF Phishing Reports December 2004 1. Introduction The accumulation and correlation of information is very important when dealing with security incidents. In phishing attacks the source of the attack may be forged and it's quite possible that the targeted organization may not even be aware of the ongoing attack. Parties aware of the attack may wish to notify the target, or an organization's internal monitoring systems may detect the attack and wish to take mitigation steps. Unfortunately, there is no recognized standard way of expressing the detection of a phishing attack nor an acceptable way to exchange the required information. 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 that should be 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, in effect information sharing with themselves. 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. Instead of defining report format and language from scratch, the phishing activities information is encoded as an extension to the INCH incident exchange format.[INCH] The use of an already existent and operational format allows for quicker vendor adoption and reuse of existing tools in organizations. To reduce duplication and to be compatible with modifications to the base IODEF definitions, this document only identifies additional structures; The reader is expected to have a copy of the IODEF documents handy while reading this one. In general, an incident report contains detailed incident-specific data which populates an EventData Structure. That EventData structure is then incorporated, either singularly or in aggregation, with additional summary and contact data, into an Incident structure. The populated Incident structure is what is reported as a Phishing Activity Report. Unsavory phishing activity may include multiple email messages, attacks, or events, scattered over various times, locations, and methodoligies. As each of these activities may generate multiple reports to an incident team, the Phishing Activity Report is composed Jevans & Cain Expires June 14, 2005 [Page 4] Internet-Draft IODEF Phishing Reports December 2004 of multiple XML Incident classes. Each Incident class is used to report one or more individual phishing reports and may include multiple RecordData elelments. This document defines new attributes for the EventData and Record Item IODEF XML classes, then identifies attributes that are required in a compliant Phishing Activity Report. The Appendices contain sample Phishing Activity Reports and the complete Document Type Definition. 1.1 INCH Dependencies As discussions started to define a format for this information, it became apparent that the output needed two things: include cognizant data, and be supported by large numbers of vendors and products. Instead of reinventing a basic reporting formula, we selected the IETF IncidentHandling Working Group's (INCH) already-defined XML-based attack data exchange models and formats. The IODEF Extensions defined in this document comply with section4, "Extending the IODEF Format" in [INCH]. Jevans & Cain Expires June 14, 2005 [Page 5] Internet-Draft IODEF Phishing Reports December 2004 2. Phishing Actvitiy Reporting via an IODEF-Document Incident A Phishing Activity Report is an instance of a IODEF-Document XML Incident class [INCH] with added EventData and AdditionalData classes. Some required information with many optional items are populated into the new structure to form a Phishing Activity Report. To facilitate completeness, the report originator should fill out as much as possible of the optional Incident fields, but SHALL stay consistent with the IODEF-Document structure. This document defines the new Incident classes for the AdditionalData, EventData, and Record Item IODEF XML classes; then identifies attributes that are required in a compliant Phishing Activity Report. The Appendices contain sample Phishing Activity Reports and the complete XML Document Type Definition and schema. The Incident class is summarized below and provides a standardized representation for commonly exchanged incident data and associates a CSIRT assigned unique identifier with the described activity. +-------------------+ | 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 ] --> RecordData --> RecordItem --> PhishRecord added | |<>--{0..*}--[ AdditionalData ] --> PhishingReport added +-------------------+ Figure 1. The INCH XML Incident class (modified) A Phishing Activity Report is composed of one Incident class, containing one or more EventData attributes. This document defines a PhishingReport class for the Incident.EventData.AdditionalData comprising of phishing-related information that does not map to existing Incident or EventData attributes. The following section defines the new extensions specific to the Incident class EventData Jevans & Cain Expires June 14, 2005 [Page 6] Internet-Draft IODEF Phishing Reports December 2004 and AdditionalData classes Jevans & Cain Expires June 14, 2005 [Page 7] Internet-Draft IODEF Phishing Reports December 2004 3. PhishingReport Class Definition A PhishingReport consists of an Extension to the Incident AdditionalData class, and is structured as follows. +---------------------------+ | EventData.AdditionalData | +---------------------------+ | ENUM type (9 = xml) |<>---------[ PhishingReport ] | STRING meaning (xml) | +---------------------------+ +------------------------+ | PhishingReport | +------------------------+ | ENUM Version |<>--(0..*)--[ PhishParameter ] | ENUM PhishType |----(0..*)--[ PhishedBrandName ] | |<>--(0..*)--[ DataCollectionType ] | |<>--(0..*)--[ DataCollectionSite ] | |<>----------[ OriginatingSensor ] | |<>--(0..*)--[ TakeDownInfo ] | |<>--(0..*)--[ ArchivedData ] | |<>--(0..*)--[ RelatedSites ] | |<>--(0..*)--[ CorrelationData ] | |----(0..1)--[ Comments ] +------------------------+ Figure 2. The PhishingReport Extensions to the INCH XML Incident.AdditionalData class 3.1 Version parameter STRING. The version shall be the value 1.0 to be compliant with this document. 3.2 PhishType parameter ENUM. The PhishType attribute contains one of the following numbers representing these types: 1. Email, and the PhishParameter is the email subject line of the phishing email. This is a standard email phish, usually sent by spam. 2. Fraudsite, no PhishParamerter. This identifies a known fraudulent site that does not necessarily send spam lures. 3. DNSspoof, with the malware name as a parameter. This is used for a spoofed DNS (e.g., malware changes localhost file so visits to www.example.com go to another IP address). Jevans & Cain Expires June 14, 2005 [Page 8] Internet-Draft IODEF Phishing Reports December 2004 4. Keylogger, with the malware name as the PhishParameter. 5. OLE, no parameter. This identifies background OLE information. 6. IM, no parameter. 7. CVE, with the CVEnumber as the PhishParameter. 8. SiteArchive, with the data archived from the phishing server placed in the ArchiveInfo class. 9. Unknown. When a PhishParameter is required, it is one of the following values: SubjectLine element STRING. This is the subject line of the email lure. MalwareName element STRING. This is the name of the malware that installed the keylogger or DNSspoofer. CVENumber element STRING. This is the CVEidentifier of this exploit used to phish. 3.3 PhishedBrandName element STRING. This is the identifier of the recognized brandname or company name used to launch the phishing activity. 3.4 DataCollectionType element ENUM. This is the method of data collection, as determined by analysing the victim computer, lure, or malware. 1. Web. The user is redirected to a website to collects the data. 2. Email Form. A form is embedded in the email lure. 3. Keylogger. Some form of keylogger was offered. 4. Automation. Other forms of automation such as background OLE automation. 5. Unspecified. 3.5 DataCollectionSite class This is the collection site where phished data is sent. +-----------------------+ | DataCollectionSite | +-----------------------+ | ENUM Type |<>--(0..*)---[ SiteData ] +-----------------------+ Jevans & Cain Expires June 14, 2005 [Page 9] Internet-Draft IODEF Phishing Reports December 2004 Type parameter 1. Web, no parameter. Data is collected on a website. 2. Email, with email site(es), comma separated, as parameter(s). Data is sent to one or more email addresses. 3. IP Address, with protocol and comma separated IP address(es) as parameter(s). Data is sent to one or more IP addresses using the identified protocol. 4. Unknown. SiteData is one of the following, depending on the type. STRING Site URL. STRING Email Site ADDRESS site IP 3.6 OriginatingSensor class +--------------------+ | OriginatingSensor | +--------------------+ | ENUM Type |<>---(0..*)---[ OriginatingSensorName ] | |<>---(0..*)---[ OriginatingSensorIPAddress ] | |<>------------[ OriginatingSensorFirstSeen ] +--------------------+ The OriginatingSensor requires a type value and identification of the entity that generated this report. Type parameter is an ENUM from the following: 1. Web Server/Service. 2. Web Gateway (Proxy or Firewall). 3. Mail Gateway. 4. Browser Element. 5. ISP sensor. 6. Human 7. Other. OriginatingSensorName element STRING. This is the DNS name of the entity that generated this report. OriginatingSensorIPAddress element ADDRESS. This is the IPAddress of the entity that generated this report. OriginatingSensorFirstSeen element DATETIME. This is the date and time that this sensor first saw this phishing activity. Jevans & Cain Expires June 14, 2005 [Page 10] Internet-Draft IODEF Phishing Reports December 2004 3.7 TakeDownInfo class +-------------------+ | TakeDownInfo | +-------------------+ | |<>---(0..1)--[ TakeDownDate ] | |<>---(0..1)--[ TakeDownAgency ] | |<>---(0..1)--[ TakeDownComments ] +------------------------------+ This class identifies information regarding the disablement of the phish collector site. A PhishingReport may have multiple TakeDownInfo classes. TakeDownDate element DATETIME. This is the date and time that takedown occurred. TakeDownAgency element STRING. This is a freeform string identifying the agency that performed the takedown TakeDownComments element STRING. A free form field to add any exciting details of the this takedown effort. 3.8 ArchivedData element +-------------------+ | ArchivedData | +-------------------+ | ENUM Type |<>---(0..1)--[ ArchivedDataURL ] | |<>---(0..1)--[ ArchivedDataComments ] +------------------------------+ The element is used to type and include a gzip archive file o a datacolection site , basecamp, 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 filed. Type parameter 1. Data Collection Site. 2. Basecamp Site. 3. Sender Site ArchivedDataURL Jevans & Cain Expires June 14, 2005 [Page 11] Internet-Draft IODEF Phishing Reports December 2004 URL. This is the URL where the gzip archive file is located. [As archives are quite large, a Phishing Report just points out where the archive is, and doe snot include it in the report.] ArchivedDataComments STRING. This field is a free form area where one can comment on the archive and/or URL, if they so please. 3.9 RelatedSites element URL. These are non-phish web sites that are related to this incident (e.g., victim site, etc). 3.10 CorrelationData element STRING. Any information that correlates this incident to other incidents can be entered here. 3.11 Comments element STRING. Comments specific to this phishing activity that does not fit in any other field. Jevans & Cain Expires June 14, 2005 [Page 12] Internet-Draft IODEF Phishing Reports December 2004 4. Definition of PhishRecord class Extensions are also made to the Incident EventData Additional Data class, to support descriptive information received in phish emails. 4.1 PhishRecord class Data specific to this phishing activity is represented within a new extenxion to the RecordItem class of the RecordData class of an EventData class in an Incident class. +-----------------------+ | RecordItem | +-----------------------+ | ANY (PhishRecord) | | ENUM Type (xml) | +-----------------------+ +-----------------------+ | PhishRecord | +-----------------------+ | |<>--(0..*)---[ EmailOriginatorIP ] | |<>--(0..*)---[ EmailHeader ] | |<>--(0..*)---[ EmailBody ] | |<>--(0..*)---[ EmailComments ] +-----------------------+ EmailOriginatorIP element ADDRESS. This is the IP Address of the site originating the phish email. EmailHeader element STRING. The headers of the phish email are included in this class. EmailBody element STRING. The body of the phish email is included here. EmailComments element STRING. Data not placed elsewhere about this email may be added in this field. Jevans & Cain Expires June 14, 2005 [Page 13] Internet-Draft IODEF Phishing Reports December 2004 5. IODEF Required Elements A Phishing Report requires certain identifying information, which is contained within the standard IODEF Incident data structure. The following table identifies attributes used in a Phishing Activity Report and their obligation. Note that the Required column notes attributes required by the base IODEF Incident class. Attributes identified as required SHALL be populated in conforming phishing activity reports. The following table is a visual description of the required fields. +--------------+ | Incident | +--------------+ | ENUM |---[ IncidentID ] | |---[ Assessment ]|---[ Confidence ] | |---[ ReportTime ] | |---[ Contact ]|---[ Role ] | | |---[ Type ]|---[ Name ] | |---[ AdditionalData ]|---[ PhishReport ]|---[ Version ] | | |---[ PhishType ] | | |---[ OriginatingSensor ]|---OriginatingSensorFirstSeen ] | | +------+ These following MUST be populated in a compliant Phishing Activity Report: IncidentID Assessment -> Confidence ReportTime Contact -> Role Contact -> Type Contact -> Name AdditionalData -> PhishReport -> Version AdditionalData -> PhishReport -> PhishType AdditionalData -> PhishReport -> OriginatingSensor -> OriginatingSensorFirstSeen Jevans & Cain Expires June 14, 2005 [Page 14] Internet-Draft IODEF Phishing Reports December 2004 6. 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 PhishingReport should include any tidbit of information gleaned from the attack. Information that is considered more sensitive than public can be marked to a higher sensitivity using the restriction paramater of each data class. Jevans & Cain Expires June 14, 2005 [Page 15] Internet-Draft IODEF Phishing Reports December 2004 7. Sample Phishing Report A sample (and useful) phishing activity report, that is one that has only the required and data items populated, is as follows: [ ed. To be supplied] Jevans & Cain Expires June 14, 2005 [Page 16] Internet-Draft IODEF Phishing Reports December 2004 8. 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. Applying a digital signature on each report will counteract both of these concerns, but again the signature may be overkill for most activity report users. For this reason, phishing activity reports SHOULD be digitally signed with the optional IODEF XML signature, although we expect that each receiving entity will determine the need for this signature independently. Generators of phishing activity reports SHOULD digitally sign each report. Originators of phishing activity reports SHOULD digitally sign their report with the XML signature as described in [INCH] . Recipients of phishing reports SHALL be prepared to accept XML digitally signed reports and SHOULD support receiving encrypted reports. Jevans & Cain Expires June 14, 2005 [Page 17] Internet-Draft IODEF Phishing Reports December 2004 9. IANA Considerations This document has no actions for IANA. Jevans & Cain Expires June 14, 2005 [Page 18] Internet-Draft IODEF Phishing Reports December 2004 10. Contributors 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. 11 Normative References [IDMEF] Curry, D. and H. Debar, "The Intrusion Detection Message Exchange Format", July 2004. [INCH] Meijer, J., Danyliw and Demchenko, "The Incident Object Description Exchange Format Data Model and XML Implementation", November 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses David Jevans The Anti-Phishing Working Group 38 Rice Street, Suites 2-0/2-2 Cambridge, MA, 02140 USA EMail: dave.jevans@antiphishing.org Patrick Cain (editor) The Cooper-Cain Group P.O. Box 400992 Cambridge, MA USA EMail: pcain@coopercain.com Jevans & Cain Expires June 14, 2005 [Page 19] Internet-Draft IODEF Phishing Reports December 2004 Appendix A. Phishing Data DTD Jevans & Cain Expires June 14, 2005 [Page 25] Internet-Draft IODEF Phishing Reports December 2004 Appendix B. Example of a Complete Phishing Activity Report pat_001 EST 2004-12-31:01:42 207.148.245.213 Empty header empty body This was fake email to keep the size of the sample report small. 2004-12-15:23:53:01 Jevans & Cain Expires June 14, 2005 [Page 26] Internet-Draft IODEF Phishing Reports December 2004 Appendix C. Mapping from the APWG work into this Document Note: This appendix is Informational and will be removed in the next version of the document. As this document incorporates some previous work done by the APWG, this section identifies where the APWG-required data items map into the INCH data structures. The following figure summarizes the APWG nomenclature as expressed as Incident classes/fields. +------------------+---------------------+--------------------------+ | APWG identifier | member | IODEF class | +------------------+---------------------+--------------------------+ | phishingreport | uniqueid | Incident.IncidentID | | | | | | Header | | Incident | | | | | | | format version | EventData.AdditionalData | | | | PhishingReport.Version | | | | | | | datecreated | Incident.ReportTime | | | | | | | reporterorg | IncidentID.UID | | | | | | | reportername | Incident.Contact | | | | | | | reporteremail | Incident.Contact.Email | | | | | | | reportersignature | (still under flux in | | | | Incident) | | | | | | | comments | Incident.Description or | | | | Incident.EventData.Descr | | | | ption | | | | | | | aggregateflag | Multiple EventData | | | | structures | | | | | | phish | | EventData. | | | | | | | datedetected | DetectTime | | | | | | | phishtype | EventData.AdditionalData | | | | PhishingReport.Eventtype | | | | | | | datacollectiontype | EventData.AdditionalData | | | | PhishingReport.DataColle | | | | tionType | Jevans & Cain Expires June 14, 2005 [Page 27] Internet-Draft IODEF Phishing Reports December 2004 | | | | | | datacollectionsite | EventData.AdditionalData | | | | PhishingReport.DataColle | | | | tionSite | | | | | | | originatingsensorty | EventData.AdditionalData | | | e | PhishingReport.Originato | | | | Sensor.Type | | | | | | | originatingsensorna | EventData.AdditionalData | | | e | PhishingReport.Originati | | | | gSensor.SensorName | | | | | | | originatingsensorIP | EventData.AdditionalData | | | ddress | PhishingReport.Originati | | | | gSensor.IPaddress | | | | | | | forensics | EventData.Record | | | | | | | emailsite-url | PhishReport.DataCollecto | | | | Site.SiteData | | | | | | | site-url | PhishReport.DataCollecto | | | | Site.SiteData | | | | | | | emailsubject | PhishReport.PhishParamet | | | | r | | | | | | | takedowndate | PhishingReport.TakedownI | | | | fo.Date | | | | | | | takedownagency | EventData.AdditionalData | | | | PhishingReport.TakedownI | | | | fo.Agency | | | | | | | site-ip | PhishReport.PhishParamet | | | | r and | | | | PhishReport.DataCollecto | | | | Site.SiteData | | | | | | | emailheaders | PhishRecord.EmailHeaders | | | | | | | emailbody | PhishRecord.EmailBody | | | | | | | brand | PhishReport.PhishedBrand | | | | ame | | | | | | | senderip | | Jevans & Cain Expires June 14, 2005 [Page 28] Internet-Draft IODEF Phishing Reports December 2004 | | | | | | otherlink | PhishingReport.RelatedSi | | | | es | | | | | | | correlations | PhishingReport.Correlati | | | | nData | | | | | | | comments | EventData. | +------------------+---------------------+--------------------------+ C.1 Overall Format Each phishing report is encapsulated in the phishingreport element header followed by one or more reports One or more phishing reports are included. C.2 Header Format Each report must have a header. Each header MUST have: >formatversion< version number>/formatversion< The version of the XML reporting format. Eg. 1.0 32-bit UNIX time This is the date that the phish report was created. organization who created the phish report Name or other id of who created the phish report (not the name of the person who submitted it). Do we need a unique database of reporternames? Eg. TMWD ‚Çô Tumbleweed Communications Corp. Each header MAY have: name of the person who created the report Name of an individual. email address of the person who created the report email address of the individual who created the report. digitalsignature An XML digital signature of the canonicalized file, everything between the . We need the hash of the document, the certs or URL to them, and the signature. What format should that be? XML-DSIG? This verifies the authenticity of the report. Jevans & Cain Expires June 14, 2005 [Page 29] Internet-Draft IODEF Phishing Reports December 2004 >ext Any comments that the reporter chooses to add to the individual phish report. 01 or nn This is a flag for whether this XML doc represents a single phish attack event; or it is an aggregated document that represents nn discrete events C.3 Individual Report Format Each individual report is encapsulated between phish. report fields Each individual report is encapsulated between the with the uniqueids. Each report MUST have: 32-bit UNIX time This is the date that the phish was reported by a consumer or detected by a trap or other means. phishtype optional_parameter One of the following. +----------------------+----------------------+---------------------+ | String | Parameter | Description | +----------------------+----------------------+---------------------+ | Email | | a standard email | | | | phish, usually sent | | | | by spam | | | | | | Fraudsite | a known fraudulent | DNSspoof | | | site that does not | | | | necessarily send | | | | spam lures | | | | | | | malwarename | spoofed DNS (eg. | Keylogger | | | Malware changes | | | | localhost file so | | | | visits to | | | | www.example.com go | | | | to an incorrect IP | | | | address) | | | | | | | malwarename | a keylogger site | OLE | | | | | | | Background OLE | IM | Jevans & Cain Expires June 14, 2005 [Page 30] Internet-Draft IODEF Phishing Reports December 2004 | | Automation | | | | | | | | Instant | CVE | | | message/NNTP/etc | | | | | | | CVEnumber | CVE number?? For | | | | malware exploits. Or | | | | is this the | | | | keylogger | | | | malwarename? | | +----------------------+----------------------+---------------------+ The optional parameter is a string, without whitespace, that may be used to name the malware that installed the keylogger or the DNSspoofer. Each report MAY have: type The method of data collection. This is derived from the victim‚ÇÖs computer (eg. By analyzing the email lure or malware sent to them). One of the following: +---------------------------------+---------------------------------+ | String | Description | +---------------------------------+---------------------------------+ | Web | User is redirected to a website | | | that collects the data | | | | | EmailForm | A form is embedded in the email | | | lure | | | | | Keylogger | Some form of keystroke logger | | | | | Automation | Other form of automation such | | | as a background OLE automation | +---------------------------------+---------------------------------+ NOTE: This is somewhat redundant with phishtype, especially if a keylogger. type optional_parameters Where the data is sent. This can be found by seizing a capture site and analyzing the code on the server. One of the following: Jevans & Cain Expires June 14, 2005 [Page 31] Internet-Draft IODEF Phishing Reports December 2004 +----------------------+----------------------+---------------------+ | String | Parameter | Description | +----------------------+----------------------+---------------------+ | Web | | Data is collected | | | | on a website. | | | | Emailsite-url and | | | | site-url fields are | | | | used to specify the | | | | location of the | | | | site. | | | | | | Email | addr, addr | Data is sent to one | | | | or more email | | | | address. List them. | | | | Comma separated. | | | | | | IP | ip, IP | Data is sent to one | | | | or more IP address, | | | | comma separated. | | | | (how to specify | | | | protocol e.g., | | | | IRC?) | +----------------------+----------------------+---------------------+ type The type of technology that generated this XML document. One of the following: +---------------------------------+---------------------------------+ | String | Description | +---------------------------------+---------------------------------+ | Web Server/Service | This XML doc was generated by a | | | web server or service | | | | | Web gateway | This XML doc was generated by a | | | web gateway | | | | | Mail gateway | This XML doc was generated by a | | | mail gateway | | | | | Browser element | This XML doc was generated by a | | | web browser element (i.e. | | | plugin) | | | | | ISP sensor | An ISP sensor generated this | | | XML document | | | | Jevans & Cain Expires June 14, 2005 [Page 32] Internet-Draft IODEF Phishing Reports December 2004 | Human | A Human generated this XML | | | doc/report (e.g.,. Discovered | | | phishing base camp) | | | | | Other technology | This XML doc was generated by | | | some other technology | +---------------------------------+---------------------------------+ name The DNS name of the entity that generated this XML document. name The IP address of the entity that generated this XML document. /forensics< Any length of strings of forensic information. Useful for law enforcement. This could be watermarks in images, comments in HTML fields, poisoned user data. URL This is the base URI of phishing site that is included in the email lure. This can be used by email spam filters to detect and filter out phishing emails by posting it to SURBL. This also can be used in a Web browser to access the phishing site. If the site is an SSL site, then the URL specifies https://URL URL This is the URI of the phishing data collection site that the browser actually goes to in order to post data. This may differ from the emailsite-url, because the URL included in the email might redirect users to the actual data collection site, which is the site-url. The emailsite-url is useful for spam filters, the site-url is useful for takedown, law enforcement, or web proxy filters to prevent users from visiting the collection site. If the site is an SSL site, then the URL specifies https://URL subject The subject of the email phish lure. UNIX 32-bit time Jevans & Cain Expires June 14, 2005 [Page 33] Internet-Draft IODEF Phishing Reports December 2004 If the site has been taken down, this is the date and time when that was effected. Which site? Redirector or data collection site? Multiples with designator? string Who took the site down. If more than one party took it down, you may list multiple parties as freeform text here, or have multiple takedownagency fields. >p address (port number optional if not 80) The IP address of the server hosting the phishing site in standard IP address format A.C.D.E:portnum. If no portnumber specified, then port 80 assumed. These IP addresses could be used by ISPs and web filters to block access to servers. However, this is dangerous if the sites are running on hacked servers or ISPs that are hosting legitimate sites as well. It can be very useful to filter out access to servers that have hijacked DNS through modifying localhosts files for example (e.g., 11.1.2004). body The body of the email. I think we need the uniqueid strings. What about when the body is an image only? Ex. GDI exploit to install keylogger or single image with hyperlink. headers The headers of the email Do we need to create xml records for each entry in a decomposed header? No, only the open relays and the apparent source and possibly a few others.. brand name The name of the company who‚ÇÖs brand is being used to launch the phishing attack IP address (optional port number) The IP address of the mail server or relay that delivered the phishing email. This can be used for RBLs. A single attack may have multiple senderips if the mail was sent from multiple relays. Jevans & Cain Expires June 14, 2005 [Page 34] Internet-Draft IODEF Phishing Reports December 2004 URL Links to non-phish sites that may be relevant (victim site, other sites) strings Any correlations to known phishing kits or groups. Freeform text. text Any freeform text comments that the reporter chooses to add to the individual phish report. e.g.,. "images sourced from victim online-banking site" or "background popup populated with victim privacy statement". Jevans & Cain Expires June 14, 2005 [Page 35] Internet-Draft IODEF Phishing Reports December 2004 Appendix D. Still To Do in This Document This appendix will be removed when it is empty. This list are the tasks that are still needed to be comleted withni this document. 1. Make a test report that verifies every possible option. 2. Finish and insert the schema. Add more detail on what the specific elements mean, Jevans & Cain Expires June 14, 2005 [Page 36] Internet-Draft IODEF Phishing Reports December 2004 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 (2004). 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. Jevans & Cain Expires June 14, 2005 [Page 37]