[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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. <reservedDelegation> - permanently inactive

      2. <assignedAndActive> - normal state

      3. <assignedAndInactive> - registration assigned but delegation
      inactive

      4. <assignedAndOnHold> - dispute

      5. <revoked> - database purge pending

      6. <transferPending> - change of authority pending

      7. <registryLock> - on hold by registry

      8. <registrarLock> - on hold by registrar

4.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"
           <Appendix A>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 .

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema attributeFormDefault="unqualified"
           elementFormDefault="qualified"
           targetNamespace="draft-ietf-inch-phishingextns-033.xsd"
           xmlns="draft-ietf-inch-iodef-070.xsd"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:phish="draft-ietf-inch-phishingextns-033.xsd"
           xmlns:iodef="draft-ietf-inch-iodef-070.xsd">
     <xs:import namespace="draft-ietf-inch-iodef-070.xsd"
                schemaLocation="draft-ietf-inch-iodef-070.xsd"/>

     <!--

   This Schema complies with draft-ietf-inch-phishingextns-03.txt

   ===================================================================
   ===  Top Level Class:  PhraudReport                             ===
   ===================================================================

    -->

    <xs:element name="PhraudReport">
      <xs:complexType>
        <xs:sequence>
          <xs:annotation>
            <xs:documentation>
               This is an EventData.AdditionalData structure for
               an IODEF Incident class.</xs:documentation>
          </xs:annotation>

          <xs:element minOccurs="0" name="PhishNameRef"
                 type="xs:string"/>

          <xs:element minOccurs="0" name="PhishNameLocalRef"
                 type="xs:string"/>

          <xs:element minOccurs="0" name="FraudParameter"
                       type="iodef:MLStringType"/>

          <xs:element maxOccurs="unbounded" minOccurs="0"
                       name="FraudedBrandName" type="xs:string"/>




Cain & Jevans           Expires December 16, 2006              [Page 35]


Internet-Draft          IODEF Phishing Extensions              June 2006


          <xs:element maxOccurs="unbounded" name="LureSource">
            <xs:complexType mixed="false">
               <xs:sequence>
                 <xs:element maxOccurs="unbounded" minOccurs="1"
                             ref="iodef:System"/>

                 <xs:element minOccurs="0" ref="phish:DomainData"/>

                 <xs:element minOccurs="0" name="IncludedMalware">
                   <xs:complexType>
                     <xs:sequence>
                       <xs:element name="Name"/>

                       <xs:element minOccurs="0" name="Hashvalue">
                         <xs:complexType>
                           <xs:simpleContent>
                             <xs:extension base="xs:string">
                               <xs:attribute name="Algorithm"
                                    use="required">
                                 <xs:simpleType>
                                   <xs:restriction base="xs:string">
                                     <xs:enumeration value="SHA1"/>
                                   </xs:restriction>
                                 </xs:simpleType>
                               </xs:attribute>
                             </xs:extension>
                           </xs:simpleContent>
                         </xs:complexType>
                       </xs:element>

                       <xs:element minOccurs="0" name="Data">
                         <xs:complexType>
                           <xs:attribute default="55AA55AA55AA55BB"
                                name="XORPattern" type="xs:string"/>
                         </xs:complexType>
                       </xs:element>
                     </xs:sequence>
                   </xs:complexType>
                 </xs:element>

                 <xs:element minOccurs="0" name="FilesDownloaded">
                   <xs:simpleType>
                     <xs:list itemType="xs:string"/>
                   </xs:simpleType>
                 </xs:element>

                 <xs:element minOccurs="0" name="RegistryKeysModified">
                   <xs:complexType>



Cain & Jevans           Expires December 16, 2006              [Page 36]


Internet-Draft          IODEF Phishing Extensions              June 2006


                     <xs:sequence>
                       <xs:element maxOccurs="32" name="Key"
                                   type="phish:RegistryKeyItemType"/>
                     </xs:sequence>
                   </xs:complexType>
                 </xs:element>
               </xs:sequence>
             </xs:complexType>
           </xs:element>

           <xs:element minOccurs="1" ref="phish:OriginatingSensor"/>

           <xs:element maxOccurs="1" minOccurs="0"
                       ref="phish:EmailRecord"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                       ref="phish:DCSite"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                       ref="phish:TakeDownInfo"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                       ref="phish:ArchivedData"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                       name="RelatedData" type="xs:string"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                       name="CorrelationData" type="xs:string"/>

           <xs:element maxOccurs="1" minOccurs="0" name="PRComments"
                       type="xs:string"/>
         </xs:sequence>

         <xs:attribute default="0.33" name="Version" use="optional"/>

         <xs:attribute name="FraudType" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:string">
               <xs:enumeration value="phishemail"/>
               <xs:enumeration value="recruitemail"/>
               <xs:enumeration value="malwareemail"/>
               <xs:enumeration value="fraudsite"/>
               <xs:enumeration value="dnsspoof"/>
               <xs:enumeration value="keylogger"/>
               <xs:enumeration value="ole"/>
               <xs:enumeration value="im"/>
               <xs:enumeration value="cve"/>



Cain & Jevans           Expires December 16, 2006              [Page 37]


Internet-Draft          IODEF Phishing Extensions              June 2006


               <xs:enumeration value="archive"/>
               <xs:enumeration value="spamreport"/>
               <xs:enumeration value="voip"/>
               <xs:enumeration value="other"/>
               <xs:enumeration value="unknown"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>

     <xs:complexType name="RegistryKeyItemType">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="Value"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <!--
    ==================================================================
    ===  Top Level Class:  EmailRecord                             ===
    ==================================================================
     -->

     <xs:element name="EmailRecord">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="EmailCount" type="xs:integer"/>

           <xs:choice>
             <xs:sequence>
               <xs:element name="EmailHeader">
                  <!-- This is an ugly way to deal
                       with multi-line header info. -->

                 <xs:complexType>
                   <xs:sequence>
                     <xs:element maxOccurs="unbounded" minOccurs="1"
                                 name="Header" type="xs:string"/>
                   </xs:sequence>
                 </xs:complexType>
               </xs:element>

               <xs:element maxOccurs="1" minOccurs="0" name="EmailBody"
                           type="xs:string"/>
             </xs:sequence>




Cain & Jevans           Expires December 16, 2006              [Page 38]


Internet-Draft          IODEF Phishing Extensions              June 2006


             <xs:element minOccurs="0" name="Message"
                           type="iodef:MLStringType"/>

             <xs:element minOccurs="0" name="ARFText" type="xs:string"/>
           </xs:choice>

           <xs:element maxOccurs="1" minOccurs="0" name="EmailComments"
                       type="xs:string"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

     <!--
    ==================================================================
    ===  Data Collection Site Info                                 ===
    ==================================================================
     -->

     <xs:element name="DCSite">
       <xs:complexType>
         <xs:sequence>
           <xs:element maxOccurs="unbounded" name="DCSiteData">
             <xs:complexType>
               <xs:sequence>
                 <xs:choice>
                   <xs:element name="siteurl" type="xs:anyURI"/>

                   <xs:element name="emailsite" type="xs:string"/>

                   <xs:element ref="iodef:System"/>

                   <xs:element name="unknown" type="xs:string"/>
                 </xs:choice>

                 <xs:element minOccurs="0" ref="phish:DomainData"/>
               </xs:sequence>

               <xs:attribute name="DCSitetype" use="required">
                 <xs:simpleType>
                   <xs:restriction base="xs:string">
                     <xs:enumeration value="web"/>

                     <xs:enumeration value="email"/>

                     <xs:enumeration value="ipaddress"/>

                     <xs:enumeration value="unknown"/>
                   </xs:restriction>



Cain & Jevans           Expires December 16, 2006              [Page 39]


Internet-Draft          IODEF Phishing Extensions              June 2006


                 </xs:simpleType>
               </xs:attribute>
             </xs:complexType>
           </xs:element>
         </xs:sequence>

         <xs:attribute name="DCType" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:string">
               <xs:enumeration value="web"/>

               <xs:enumeration value="email"/>

               <xs:enumeration value="keylogger"/>

               <xs:enumeration value="automation"/>

               <xs:enumeration value="unspecified"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>

     <xs:element name="DomainData">
       <xs:complexType>
         <xs:sequence>
           <xs:element maxOccurs="1" minOccurs="1" name="Name"
                       type="iodef:MLStringType">
             <xs:annotation>
               <xs:documentation>Multiple domains with equal contact and
               registraton data can be referenced with the "sameas"
               entry.</xs:documentation>
             </xs:annotation>
           </xs:element>

           <xs:element maxOccurs="1" minOccurs="0"
                   name="DateDomainWasChecked" type="xs:dateTime"/>

           <xs:element maxOccurs="1" minOccurs="0"
                   name="RegistrationDate" type="xs:dateTime"/>

           <xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate"
                   type="xs:dateTime"/>

           <xs:element maxOccurs="16" minOccurs="0" name="Nameserver">
             <xs:complexType>
               <xs:sequence>



Cain & Jevans           Expires December 16, 2006              [Page 40]


Internet-Draft          IODEF Phishing Extensions              June 2006


                 <xs:element name="Server" type="phish:DNSNameType"/>

                 <xs:element ref="iodef:Address"/>
               </xs:sequence>
             </xs:complexType>
           </xs:element>

           <xs:choice id="DomainContacts">
             <xs:element name="SameDomainContact"
                    type="phish:DNSNameType"/>

             <xs:sequence>
               <xs:element maxOccurs="unbounded" minOccurs="0"
                           ref="phish:DomainContact"/>
             </xs:sequence>
           </xs:choice>
         </xs:sequence>

         <xs:attribute name="SystemStatus">
           <xs:simpleType>
             <xs:restriction base="xs:string">
               <xs:enumeration value="spoofed"/>

               <xs:enumeration value="fraudulent"/>

               <xs:enumeration value="innocent-hacked"/>

               <xs:enumeration value="innocent-hijacked"/>

               <xs:enumeration value="unknown"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>

         <xs:attribute name="DomainStatus">
           <xs:simpleType>
             <xs:restriction base="xs:string">
               <xs:enumeration
                   value="&lt;reservedDelegation&gt; - permanently
                          inactive"/>
               <xs:enumeration
                   value="&lt;assignedAndActive&gt; - normal state"/>
               <xs:enumeration
                   value="&lt;assignedAndInactive&gt; - registration
                          assigned but delegation inactive"/>
               <xs:enumeration
                   value="&lt;assignedAndOnHold&gt; - dispute"/>
               <xs:enumeration



Cain & Jevans           Expires December 16, 2006              [Page 41]


Internet-Draft          IODEF Phishing Extensions              June 2006


                   value="&lt;revoked&gt; - database purge pending"/>
               <xs:enumeration
                   value="&lt;transferPending&gt; - change of
                          authority pending"/>
               <xs:enumeration
                  value="&lt;registryLock&gt; - on hold by registry"/>
               <xs:enumeration
                  value="&lt;registrarLock&gt; - on hold by registrar"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>

     <xs:complexType name="DNSNameType">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="lang" type="xs:language"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <xs:element name="DomainContact">
       <xs:complexType>
         <xs:sequence>
           <xs:element minOccurs="0" ref="iodef:ContactName"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                   ref="iodef:Description"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                   ref="iodef:RegistryHandle"/>

           <xs:element minOccurs="0" ref="iodef:PostalAddress"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                   ref="iodef:Email"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                   ref="iodef:Telephone"/>

           <xs:element minOccurs="0" ref="iodef:Fax"/>

           <xs:element minOccurs="0" ref="iodef:Timezone"/>
         </xs:sequence>

         <xs:attribute name="role">
           <xs:simpleType>



Cain & Jevans           Expires December 16, 2006              [Page 42]


Internet-Draft          IODEF Phishing Extensions              June 2006


             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="registrant"/>
               <xs:enumeration value="registrar"/>
               <xs:enumeration value="billing"/>
               <xs:enumeration value="technical"/>
               <xs:enumeration value="administrative"/>
               <xs:enumeration value="legal"/>
               <xs:enumeration value="zone"/>
               <xs:enumeration value="abuse"/>
               <xs:enumeration value="security"/>
               <xs:enumeration value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>

         <xs:attribute name="confidence">
           <xs:simpleType>
             <xs:restriction base="xs:string">
               <xs:enumeration value="known-fraudulent"/>
               <xs:enumeration value="looks-fraudulent"/>
               <xs:enumeration value="known-real"/>
               <xs:enumeration value="looks-real"/>
               <xs:enumeration value="unknown"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>

         <xs:attribute name="restriction"
                 type="iodef:restriction-type"/>
       </xs:complexType>
     </xs:element>

     <!--
   ===================================================================
   ===  The Originating Sensor Data Element                        ===
   ===================================================================
   -->

     <xs:element name="OriginatingSensor">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="FirstSeen" type="xs:dateTime"/>

           <xs:element minOccurs="0" name="name"
                   type="iodef:MLStringType"/>

           <xs:element maxOccurs="unbounded" minOccurs="1"
                   ref="iodef:System"/>



Cain & Jevans           Expires December 16, 2006              [Page 43]


Internet-Draft          IODEF Phishing Extensions              June 2006


           <xs:element minOccurs="0" ref="iodef:Location"/>
         </xs:sequence>

         <xs:attribute name="OriginatingSensorType" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKENS">
               <xs:enumeration value="web"/>

               <xs:enumeration value="webgateway"/>

               <xs:enumeration value="mailgateway"/>

               <xs:enumeration value="browser"/>

               <xs:enumeration value="ispsensor"/>

               <xs:enumeration value="human"/>

               <xs:enumeration value="honeypot"/>

               <xs:enumeration value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>

     <!--
   ===================================================================
   ===     The Take Down Data structure.                           ===
   ===================================================================
   -->

     <xs:element name="TakeDownInfo">
       <xs:complexType>
         <xs:sequence>
           <xs:element minOccurs="0" name="TakeDownDate"
                      type="xs:dateTime"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                       name="TakeDownAgency" type="xs:string"/>

           <xs:element maxOccurs="unbounded" minOccurs="0"
                       name="TakeDownComments" type="xs:string"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>




Cain & Jevans           Expires December 16, 2006              [Page 44]


Internet-Draft          IODEF Phishing Extensions              June 2006


     <!--
   ===================================================================
   ===     The Archived Data Element                               ===
   ===================================================================
   -->

     <xs:element name="ArchivedData">
       <xs:complexType>
         <xs:sequence>
           <xs:element minOccurs="0" name="ArchivedDataURL"
                   type="xs:anyURI"/>

           <xs:element minOccurs="0" name="ArchivedDataComments"
                   type="xs:string"/>
         </xs:sequence>

         <xs:attribute name="ArchivedDataType" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKENS">
               <xs:enumeration value="collectionsite"/>

               <xs:enumeration value="basecamp"/>

               <xs:enumeration value="sendersite"/>

               <xs:enumeration value="unspecified"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>

     <!--
   ===================================================================
   ===     The Related Data Element                                ===
   ===================================================================
   -->

     <xs:element name="RelatedData">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="URLs" type="xs:anyURI"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

     <!-- Elements and pieces that are used in many places.-->




Cain & Jevans           Expires December 16, 2006              [Page 45]


Internet-Draft          IODEF Phishing Extensions              June 2006


     <xs:element name="url" type="xs:anyURI"/>

     <xs:element name="email">
       <xs:simpleType>
         <xs:restriction base="xs:string">
           <xs:pattern value="\S@\S"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:element>
   </xs:schema>









































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.

   <?xml version="1.0" encoding="UTF-8"?>
   <IODEF-Document
          xsi:schemaLocation="draft-ietf-inch-phishingextns-033.xsd
              draft-ietf-inch-phishingextns-033.xsd"
          xmlns="draft-ietf-inch-iodef-070.xsd"
          xmlns:phish="draft-ietf-inch-phishingextns-033.xsd"
          xmlns:iodef="draft-ietf-inch-iodef-070.xsd"
          xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <Incident purpose="other">
     <IncidentID name="Pat">PAT2005-06</IncidentID>
     <ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
     <Description>This is a test report from actual data.
        </Description>
     <Assessment>
       <Confidence rating="high"></Confidence>
     </Assessment>



Cain & Jevans           Expires December 16, 2006              [Page 47]


Internet-Draft          IODEF Phishing Extensions              June 2006


     <Contact role="creator" type="person">
       <ContactName>patcain</ContactName>
       <Email>pcain@coopercain.com</Email>
     </Contact>
     <EventData>
       <DetectTime>2005-06-21T18:22:02-05:00</DetectTime>
        <AdditionalData dtype="xml">
        <phish:PhraudReport FraudType="phishemail">
         <phish:FraudParameter>
           Subject: You have successfully updated your password
         </phish:FraudParameter>

         <phish:FraudedBrandName>Cooper-Cain</phish:FraudedBrandName>
         <phish:LureSource>
          <System category="source">
           <Node>
            <Address>216.231.63.162</Address>
           </Node>
          </System>

          <phish:IncludedMalware>
           <phish:Name>W32.Mytob.EA@mm</phish:Name>
          </phish:IncludedMalware>
         </phish:LureSource>

         <phish:OriginatingSensor OriginatingSensorType="human">
          <phish:FirstSeen>2005-06-10T15:52:11-05:00</phish:FirstSeen>

          <System>
           <Node>
            <Address>10.0.0.4</Address>
           </Node>
          </System>
         </phish:OriginatingSensor>

         <phish:EmailRecord>
          <phish:EmailCount>1</phish:EmailCount>
          <phish:Message>"Return-path: &lt;support@coopercain.com&gt;"
           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</phish:Message>
          </phish:EmailRecord>
         </phish:PhraudReport></AdditionalData>
     </EventData>
    </Incident>
   </IODEF-Document>

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: <service@paypal.com>
   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





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
   <http://217.136.251.41:8080/.cgi-bin/.webscr/.secure-
   login/%20/%20/.payp
   al.com/index.htm>



   Once you log in,update your account information.
   After updating your account click on the 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>


C.2.  Phishing Report

   <?xml version="1.0" encoding="UTF-8"?>
   <IODEF-Document
         xsi:schemaLocation="draft-ietf-inch-phishingextns-033.xsd
           draft-ietf-inch-phishingextns-033.xsd"
         xmlns="draft-ietf-inch-iodef-070.xsd"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"
         xmlns:phish="draft-ietf-inch-phishingextns-033.xsd"
     <Incident purpose="mitigation" restriction="private">
       <IncidentID name="cooper-cain">CC200600000002</IncidentID>



Cain & Jevans           Expires December 16, 2006              [Page 51]


Internet-Draft          IODEF Phishing Extensions              June 2006


       <ReportTime>2006-06-13T21:14:56-05:00</ReportTime>

       <Description>
          This is a sample phishing email received report. The phish
          was actually received as is.
       </Description>

       <Assessment></Assessment>

       <Contact role="creator" type="person">
         <ContactName>patcain</ContactName>

         <Email>pcain@coopercain.com</Email>
       </Contact>

       <EventData>
         <DetectTime>2006-06-13T05:37:21-04:00</DetectTime>

         <AdditionalData dtype="xml">
           <phish:PhraudReport FraudType="phishemail">
             <phish:FraudParameter> * * * Update &amp; Verify Your
                     PayPal Account * * *</phish:FraudParameter>
             <phish:FraudedBrandName>PayPal</phish:FraudedBrandName>

             <phish:LureSource>
               <System category="source">
                 <Node>
                   <Address>24.147.114.61</Address>
                 </Node>
               </System>
             </phish:LureSource>

             <phish:OriginatingSensor
                     OriginatingSensorType="mailgateway">
               <phish:FirstSeen>2006-06-13T05:37:22-04:00
                     </phish:FirstSeen>

               <System>
                 <Node>
                   <NodeRole category="mail"></NodeRole>
                 </Node>
               </System>
             </phish:OriginatingSensor>

             <phish:EmailRecord>
               <phish:EmailCount>1</phish:EmailCount>

               <phish:Message>Return-path: &lt;service@paypal.com&gt;



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: &lt;nospa@nospa.us&gt;
               From: "PayPal"&lt;service@paypal.com&gt;
               Subject: * * * Update &amp; 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: &lt;TSIlYbvhBISmT6QcWY90000085f@TSI&gt;
               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&lt;http://www.paypal.com/images/paypal_logo.gif&gt;
               &lt;http://www.paypal.com/images/pixel.gif&gt;
               &lt;http://www.paypal.com/images/pixel.gif&gt;
               &lt;http://www.paypal.com/images/pixel.gif&gt;
               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
               &lt;http://217.136.251.41:8080/.cgi-bin/.webscr/.secure-
               login/%20/%20/.paypal.com/index.htm&gt;
               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
               &lt;http://www.paypal.com/images/dot_row_long.gif&gt;
              </phish:Message>
             </phish:EmailRecord>

             <phish:DCSite DCType="web">
               <phish:DCSiteData DCSitetype="web">
                 <phish:siteurl>http://217.136.251.41:8080/.cgi-bin/.web
                         scr/.secure-login/%20%20/.paypal.com/index.htm
                 </phish:siteurl>

                 <phish:DomainData
                 DomainStatus="&lt;assignedAndActive&gt; - normal state"
                                   SystemStatus="unknown">
                   <phish:Name>adsl.skynet.be</phish:Name>

                   <phish:DateDomainWasChecked>
                           2006-06-14T13:05:00-05:00
                   </phish:DateDomainWasChecked>

                   <phish:RegistrationDate>
                           2000-12-13T00:00:00
                   </phish:RegistrationDate>

                   <phish:Nameserver>
                     <phish:Server>ns1.skynet.be</phish:Server>

                     <Address>195.238.3.17</Address>
                   </phish:Nameserver>
                 </phish:DomainData>
               </phish:DCSiteData>
             </phish:DCSite>
           </phish:PhraudReport></AdditionalData>
       </EventData>
     </Incident>
   </IODEF-Document>






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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/