Extensions to the IODEF-Document Class for Reporting Phishing
draft-cain-post-inch-phishingextns-07
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5901.
|
|
|---|---|---|---|
| Authors | David Jevans , Patrick Cain | ||
| Last updated | 2015-10-14 (Latest revision 2009-11-24) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5901 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Tim Polk | ||
| Send notices to | (None) |
draft-cain-post-inch-phishingextns-07
Network Working Group P. Cain
Internet-Draft The Cooper-Cain Group, Inc.
Intended status: Standards Track D. Jevans
Expires: May 27, 2010 The Anti-Phishing Working Group
November 23, 2009
Extensions to the IODEF-Document Class for Reporting Phishing
draft-cain-post-inch-phishingextns-07
Abstract
This document extends the Incident Object Description Exchange Format
(IODEF) defined in RFC5070 to support the reporting of phishing
events, which is a particular type of fraud. These extensions are
flexible enough to support information gleaned from activities
throughout the entire electronic fraud cycle - from receipt of the
phishing lure to the disablement of the collection site. Both simple
reporting and complete forensic reporting are possible, as is
consolidating multiple incidents .
Cain & Jevans Expires May 27, 2010 [Page 1]
Internet-Draft IODEF Phishing Extensions November 2009
RFC 2129 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 May 27, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Cain & Jevans Expires May 27, 2010 [Page 2]
Internet-Draft IODEF Phishing Extensions November 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Why a Common Report Format is Needed . . . . . . . . . . . 5
1.2. Processing of Exchanged Data not Defined . . . . . . . . . 6
1.3. Relation to the INCH IODEF Data Model . . . . . . . . . . 6
2. Terminology Used in This Document . . . . . . . . . . . . . . 7
3. Interesting Fraud Event Data . . . . . . . . . . . . . . . . . 8
3.1. The Elements of a Phishing/Fraud Event . . . . . . . . . . 8
3.2. Useful Data Items In a Fraud Event . . . . . . . . . . . . 9
4. Fraud Activity Reporting via IODEF-Documents . . . . . . . . . 11
4.1. Fraud Report Types . . . . . . . . . . . . . . . . . . . . 11
4.2. Fraud Report XML Representation . . . . . . . . . . . . . 11
4.3. Syntactical Correctness of Fraud Activity Reports . . . . 12
5. PhraudReport Element Definitions . . . . . . . . . . . . . . . 13
5.1. PhraudReport Structure . . . . . . . . . . . . . . . . . . 13
5.2. Reuse of IODEF-defined Elements . . . . . . . . . . . . . 14
5.3. Element and Attribute Specification Format . . . . . . . . 14
5.4. Version attribute . . . . . . . . . . . . . . . . . . . . 15
5.5. FraudType attribute . . . . . . . . . . . . . . . . . . . 15
5.6. PhishNameRef element . . . . . . . . . . . . . . . . . . . 16
5.7. PhishNameLocalRef element . . . . . . . . . . . . . . . . 16
5.8. FraudedBrandName element . . . . . . . . . . . . . . . . . 16
5.9. LureSource element . . . . . . . . . . . . . . . . . . . . 16
5.10. OriginatingSensor Element . . . . . . . . . . . . . . . . 25
5.11. The DCSite element . . . . . . . . . . . . . . . . . . . . 26
5.12. TakeDownInfo element . . . . . . . . . . . . . . . . . . . 28
5.13. ArchivedData element . . . . . . . . . . . . . . . . . . . 29
5.14. RelatedData element . . . . . . . . . . . . . . . . . . . 31
5.15. CorrelationData element . . . . . . . . . . . . . . . . . 31
5.16. PRComments element . . . . . . . . . . . . . . . . . . . . 31
5.17. EmailRecord element . . . . . . . . . . . . . . . . . . . 31
6. Mandatory IODEF and PhraudReport Elements . . . . . . . . . . 33
6.1. Guidance on Usage . . . . . . . . . . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
7.1. Transport-specific concerns . . . . . . . . . . . . . . . 35
7.2. Using the iodef:restriction attribute . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Appendix A. Phishing Extensions XML Schema . . . . . 39
Appendix B. Example Virus Report . . . . . . . . . . . . . . . . 49
B.1. Received Email . . . . . . . . . . . . . . . . . . . . . . 49
B.2. Generated Report . . . . . . . . . . . . . . . . . . . . . 49
Appendix C. Sample Phishing Report . . . . . . . . . . . . . . . 52
C.1. Received Lure . . . . . . . . . . . . . . . . . . . . . . 52
Cain & Jevans Expires May 27, 2010 [Page 3]
Internet-Draft IODEF Phishing Extensions November 2009
C.2. Phishing Report . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
Cain & Jevans Expires May 27, 2010 [Page 4]
Internet-Draft IODEF Phishing Extensions November 2009
1. Introduction
Deception activities, such as receiving an email purportedly from a
bank requesting you to confirm your account information, are an
expanding attack type on the Internet. The terms phishing and fraud
are used interchangeably in this document to characterize broadly-
launched social engineering attacks in which an electronic identity
is misrepresented in an attempt to trick individuals into revealing
their personal credentials ( e.g., passwords, account numbers,
personal information, ATM PINs, etc.). A successful phishing attack
on an individual allows the phisher (i.e., the attacker) to exploit
the individual's credentials for financial or other gain. Phishing
attacks have morphed from directed email messages from alleged
financial institutions to more sophisticated lures that may also
include malware.
This document defines a data format extension to the Incident Object
Description Exchange Format (IODEF) [RFC5070] that can be used to
describe information about a phishing or other type of fraudulent
incident. Sections 2 of this document provide an overview of the
terminology and process of a phishing event. Section3 introduces the
high-level report format and how to use it. Sections 4 and 5
describe the data elements of the fraud extensions. The appendices
includes an XML schema for the extensions and a few example fraud
reports.
The extensions defined in this document may be used to report the
social engineering victim lure, the collections site, and credential
targeted ('spear') phishing, broad multi-recipient phishing, and
other evolving Internet-based fraud attempts. Malware and other
malicious software included within the lure may also be included
within the report
1.1. Why a Common Report Format is Needed
To combat the rise in malicious activity on the Internet, service
providers and investigative agencies are sharing more and more
network and event data in a coordinated effort to identify
perpetrators and compromised accounts, coordinate responses, and
prosecute attackers. As the number of data sharing parties increases
the number of party-specific tools, formats, and definitions multiply
rapidly until it overwhelms the investigative and coordination
abilities of those parties.
By using a common format, it becomes easier for an organization to
engage in this coordination as well as correlation of information
from multiple data sources or products into a cohesive view. As the
number of data sources increases, a common format becomes even more
Cain & Jevans Expires May 27, 2010 [Page 5]
Internet-Draft IODEF Phishing Extensions November 2009
important, since multiple tools would be needed to interpret the
different sources of data. A big win in a common format is the
ability to automate many of the analysis tasks an significantly speed
up the response and persecution activities.
1.2. Processing of Exchanged Data not Defined
While the intended use of this specification is to facilitate data
sharing between parties, the mechanics of this sharing process and
its related political challenges are out of scope for this document.
1.3. Relation to the INCH IODEF Data Model
Instead of defining a new report format, this draft defines an
extension to [RFC5070]. The IODEF defines a flexible and extensible
format and supports a granular level of specificity. These phishing
and fraud extensions reuse subsets of the IODEF data model and, where
appropriate, specifies new data elements. Leveraging an existing
specification allows for more rapid adoption and reuse of existing
tools in organizations. For clarity, and in order to eliminate
duplication, only the additional structures necessary for describing
the exchange of phishing and e-crime activity are provided.
Cain & Jevans Expires May 27, 2010 [Page 6]
Internet-Draft IODEF Phishing Extensions November 2009
2. Terminology Used in This Document
Since many people use different but similar terms to mean the same
thing, we use the following terminology in this document.
a. Phishing
The overall process of identifying victims, contacting them
via a lure, causing a victim to send a set of private
credentials to a collection site, and storing those
credentials is called phishing.
b. Fraud event
A fraud event is the combination of Phishing and subsequent
fraudulent use of the private credentials.
c. Lure
A lure is the decoy used to trick a victim into performing
some activity such as providing their private credentials.
The lure relies on social engineering concepts to convince the
victim that the lure is genuine and its instructions should be
followed. A lure includes a pointer or link to a collection
site.
d. Collection Site
The web site, email box, SMS number, phone number, or other
place where a phished victim sends their private credentials
for later fraudulent use by a criminal.
e. Credentials
A credential is data that is transferred or presented to
establish either a claimed identity or the authorizations of a
system entity. Many websites requires a user name and
password -- combined they are a credential -- to access
sensitive content.
f. Message
Although primarily email, a Lure can be transported via any
messaging medium such as Instant message, Voice Over IP, or
text via an SMS service. The term message is used as a
generic term for any of these transport mediums.
Cain & Jevans Expires May 27, 2010 [Page 7]
Internet-Draft IODEF Phishing Extensions November 2009
3. Interesting Fraud Event Data
Before defining the structure of the IODEF extensions we identify the
'interesting' data in phishing and other fraudulent activities.
3.1. The Elements of a Phishing/Fraud Event
+-----------+ +------------------+
| Fraudster |<---<-- | Collection Site |<---O--<----<----+
+----+------+ +------------------+ | |
| | |
| +--|-----+ ^
| | Sensor | Credentials
| +-|------+ |
| +---------------+ | +-------+
\--->--| Attack Source |--Lure--->-----O------> | User/ |
+---------------+ |Victim |
+-------+
Figure 3.1: The Components of Internet Fraud
Internet-based Phishing and Fraud activities are normally comprised
of at least six components:
1. The Phisher, Fraudster, or party perpetrating the fraudulent
activity. Most times this party is not readily identifiable.
2. The Attack Source, the source of the phishing email, virus,
trojan, or other attack is masked in an enticing manner.
3. The Lure used to trick the victim into responding.
4. The User, Victim, or intended target of the fraud or phish.
5. The credentials, personal data, or other information the victim
has surrendered to the phisher.
6. The collection site, where the victim sends their credentials or
personal data if they have been duped by the lure of the phisher.
This may be a website, mailbox, phone operator, or a database.
If we take a holistic view of the attack, there are some additional
components:
o The sensor, the means by which the phish is detected. This
element may be an intrusion detection system, firewall, filter,
email gateway, or human analyst.
Cain & Jevans Expires May 27, 2010 [Page 8]
Internet-Draft IODEF Phishing Extensions November 2009
o A forensic or archive site (not pictured) where an investigator
has copied or otherwise retained the data used for the fraud
attempt or credential collection.
3.1.1. Fraudulent Activity Extensions to the IODEF-Document
Fraud events are reported in a Fraud Activity Report which is an
instance of an XML IODEF-Document Incident element with added
EventData and AdditionalData elements. The additional fields in the
EventData specific to phishing and fraud are enclosed into a
PhraudReport XML element. Fraudulent activity may include multiple
emails, instant messages, or network messages, scattered over various
times, locations, and methodologies. The PhraudReport within an
EventData may include information about the email header and body,
details of the actual phishing lure, correlation to other attacks,
and details of the removal of the web server or credential collector.
As a phishing attack may generate multiple reports to an incident
team, multiple PhraudReports may be combined into one EventData
structure and multiple EventData structures may be combined into one
Incident Report. One IODEF Incident report may record one or more
individual phishing events and may include multiple EventData
elements.
This document defines new extension elements for the EventData and
Record Item IODEF XML elements and identifies those required in a
PhraudReport. The Appendices contain sample Fraud Activity Reports
and a complete Schema.
The IODEF Extensions defined in this document comply with section 4,
"Extending the IODEF Format" in [RFC5070].
3.2. Useful Data Items In a Fraud Event
There are a number of subtle and non-obvious datum to capture from a
fraud event that makes the event analysis and correlation with other
events more useful. These datum can be grouped into categories:
3.2.1. Data about the Lure
If a lure was presented as part of the fraud event, this category
includes the original received lure, the means that the lure was
received ( e.g., email, phone, or SMS), and the source addresses that
sent the lure. Other useful data includes DNS data about the lure
source, identification of any accompanying malware, and the Brand
name defrauded.
Cain & Jevans Expires May 27, 2010 [Page 9]
Internet-Draft IODEF Phishing Extensions November 2009
3.2.2. Credential Collection Site Data
The collection site contains victim identifications along with copies
of data supplied by the victims such as account names or numbers,
passwords, date of birth, etc. This category of useful data includes
these credentials along with information about the collections site
itself such as its type, site DNS data, DNS registrant data, and site
physical location. The location and registrant information is
particularly important if law enforcement assistance is expected.
Additionally, an entire site archive can be gathered to allow a
collector on a shared web site to be disabled without impacting other
users.
3.2.3. Detection Information
This is a non-obvious data category and contains data on how the lure
or collection site was detected. Understanding how the lure was
detected allows us to design and implement better detection systems.
3.2.4. Analysis Output
In an environment where time is critical, it is imperative that
analysis from one party can be reliably explained and shared to other
investigative parties. This grouping includes data that an
investigator found interesting or could be useful to others.
Cain & Jevans Expires May 27, 2010 [Page 10]
Internet-Draft IODEF Phishing Extensions November 2009
4. Fraud Activity Reporting via IODEF-Documents
A Fraud Activity Report is an instance of an XML IODEF-Document with
additional extensions and usage guidance as specified in Section 4 of
this document. These additional extensions are implemented through
the PhraudReport XML element.
As described in the following sections, reporting Fraud Activity has
three primary components: choosing a report type; a format for the
data; and how to check correctness of the format.
4.1. Fraud Report Types
There are three actions relating to reporting phishing events.
First, a reporter may *create* and exchange a new report on a new
event. Secondly, a reporter may *update* a previously exchanged
report to indicate new collection sites, site take down information,
or related activities. Lastly, a reporter may have realized that the
report is in error or contain significant incorrect data and the
prudent reaction is to *delete* the report.
The three types of reports are denoted through the use of the ext-
purpose attribute of an Incident element. A new report contains an
empty or a "create" ext-purpose value; an updated report contains a
ext-value value of "update"; a request for deletion contains a
"delete" ext-purpose value. Note that this is actually an advisory
marking for the report originator or recipient as operating
procedures in a report life cycle is very environment specific.
4.2. Fraud Report XML Representation
The IODEF Incident element [RFC5070, Section 3.2] is summarized
below. It and the rest of the data model presented in Section 4 is
expressed in Unified Modeling Language (UML) syntax as used in the
IODEF specification. The UML representations is for illustrative
purposes only; elements are specified in XML as defined in Appendix A
Cain & Jevans Expires May 27, 2010 [Page 11]
Internet-Draft IODEF Phishing Extensions November 2009
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| | |<>--[ AdditionalData ]
| | |<>--[ PhraudReport ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 4.1: The IODEF XML Incident Element (modified)
A Fraud Activity Report is composed of one iodef:Incident element
that contains one or more related PhraudReport elements embedded in
iodef:AdditionalData element of iodef:EventData. The PhraudReport
element is added to the IODEF using its defined extension procedure
documented in Section 5 of [RFC5070].
One IODEF-Document may contain information on multiple incidents with
information for each incident contained within an iodef:Incident
element [RFC5070], Section 3.12].
4.3. Syntactical Correctness of Fraud Activity Reports
The Fraud Activity Report MUST pass XML validation using the schema
defined in [RFC5070] and the extensions defined in<AppendixA> of this
document.
Cain & Jevans Expires May 27, 2010 [Page 12]
Internet-Draft IODEF Phishing Extensions November 2009
5. PhraudReport Element Definitions
A PhraudReport consists of an extension to the
Incident.EventData.AdditionalData element with a dtype of "xml". The
elements of the PhraudReport will specify information about the six
components of fraud activity identified in Section 2. Additional
forensic information and commentary can be added by the reporter as
necessary to show relation to other events, to show the output of an
investigation, or for archival purposes.
5.1. PhraudReport Structure
A PhraudReport element is structured as follows. The components of a
PhraudReport are introduced in functional grouping as some parameters
are related and some elements may not make sense individually.
+------------------+
| PhraudReport |
+------------------+
| STRING Version |<>--{0..1}--[ PhishNameRef ]
| ENUM FraudType |<>--{0..1}--[ PhishNameLocalRef ]
| STRING ext-value |<>--{0..1}--[ FraudParameter ]
| |<>--{0..*}--[ FraudedBrandName ]
| |<>--{1..*}--[ LureSource ]
| |<>--{1..*}--[ OriginatingSensor ]
| |<>--{0..1}--[ EmailRecord ]
| |<>--{0..*}--[ DCSite ]
| |<>--{0..*}--[ TakeDownInfo ]
| |<>--{0..*}--[ ArchivedData ]
| |<>--{0..*}--[ RelatedData ]
| |<>--{0..*}--[ CorrelationData ]
| |<>--{0..1}--[ PRComments ]
+------------------+
Figure 5.1: The PhraudReport Element
Relevant information about a phishing or fraud event can be encoded
by encoding the six components as follows:
a. The PhishNameRef and PhishNameLocalRef elements identify the
fraud or class of fraud.
b. The LureSource element describes the source of the attack or
phishing lure, including host information and any included
malware.
c. The DCSite describes the technical details of the credential
collection site.
Cain & Jevans Expires May 27, 2010 [Page 13]
Internet-Draft IODEF Phishing Extensions November 2009
d. The Originating Sensor element describes the means of detection.
The RelatedData, ArchivedData, and TakeDownInfo fields allow optional
forensics and history data to be included.
A specific phish/fraud activity can be identified using a combination
of the FraudType, FraudParameter, FraudedBrandName, LureSource, and
PhishNameRef elements.
5.2. Reuse of IODEF-defined Elements
Elements, attributes, and parameters defined in the base IODEF
specification were used whenever possible in the definition of the
PhraudReport XML element. This specification does not introduce any
new variable types or encodings to the IODEF data model, but extends
the IODEF Contact and System elements.
The data model schema contains a copy of the iodef:System element.
Although we would like to just extend the System element, it is
defined in RFC5070 with an unable-to-extend anonymous type so we
copied the element, named its underlying type, and then generated the
extension to it.
Note: Elements that are imported from the base IODEF specification
are prefaced with an "iodef" XML namespace and are noted with the
section defining that element in [RFC5070]. Each element in a
PhraudReport is used as described in the following sections.
5.3. Element and Attribute Specification Format
The following sections describe the components of a PhraudReport XML
element. Each description is structured as follows.
1. A terse XML-type identifier for the element or attribute.
2. An indication of whether the element or attribute is REQUIRED or
optional. Mandatory items are noted as REQUIRED. If not
specified, elements are optional. Note that when optional
elements are included, they may REQUIRE specific sub-elements.
3. A description of the element or attribute and its intended use.
Elements that contain sub-elements or enumerated values are further
sub-sectioned. Note that there is no 'trickle-up' effect in
elements. That is, the required elements of a sub-element are only
populated if the sub-element is used.
Cain & Jevans Expires May 27, 2010 [Page 14]
Internet-Draft IODEF Phishing Extensions November 2009
5.4. Version attribute
REQUIRED. STRING. The version shall be the value 0.06 to be
compliant with this document.
5.5. FraudType attribute
REQUIRED. One ENUM. The FraudType attribute describes the type of
fraudulent activity described in this PhraudReport. The FraudType
chosen determines the value of the FraudParameter filed. This field
contains one of the following values:
1. phishing. The FraudParameter should be the subject line of the
phishing lure email or value of a lure IM or VoIP message. This
type is a standard phishing lure, usually sent as email, and is
intended to derive financial loss to the recipient.
2. recruiting. The FraudParameter is the subject line of the
recruit, or mule, email or message.
3. malware distribution. 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. fraudulent site. This identifies a known fraudulent site that
does not necessarily send spam but is used to show lures. The
FraudParameter may be used to identify the website.
5. dnsspoof. This choice does not have a related FraudParameter.
This value is used when a DNS system component responses with an
untrue IP address for the requested domain name due to either
cache poisoning, ID spoofing, or other manipulation of the DNS
system.
6. archive. There is no required FraudParameter for this choice,
although the FraudParameter of the original phish could be
entered. The data archived from the phishing server is placed in
the ArchiveInfo element.
7. other. This is used to identify not-yet-enumerated fraud types.
8. unknown. This choice may have an associated FraudParameter. It
is used to cover confused cases.
9. ext-value. This choice identifies an unidentified FraudType.
The FraudType should be captured in the ext-value attribute.
Cain & Jevans Expires May 27, 2010 [Page 15]
Internet-Draft IODEF Phishing Extensions November 2009
5.5.1. ext-value attribute
OPTIONAL. This STRING may be populated with a FraudType that has not
been predefined.
5.5.2. FraudParameter element
Zero or one value of iodef:MLStringType. The contents of this
element are dependent on the FraudType choice. It may be an email
subject line, VoIP lure, link in an IM message, or a web URL. Note
that some phishers add a number of random characters onto the end of
a phish email subject line for uniqueness; reporters should delete
those characters before insertion into the FraudParameter field.
5.6. PhishNameRef element
Zero or one value of iodef:MLStringType. The PhishNameRef element is
the common name used to identify this fraud event. It is often the
name agreed upon by involved parties or vendors. Using this name can
be a convenient way to reference the activity collaborating with
other parties, the media, or engaging in public education.
5.7. PhishNameLocalRef element
Zero or one value of iodef:MLStringType. The PhishNameLocalRef
element describes a local name or Unique-IDentifier (UID) that is
used by various parties before a commonly agreed term is adopted.
This field allows a cross-reference from the submitting
organization's system to a central repository.
5.8. FraudedBrandName element
Zero or more values of iodef:MLStringType. This is the identifier of
the recognized brand name or company name used in the phishing
activity (e.g., XYZ Semiconductor Corp).
5.9. LureSource element
REQUIRED. One or more values. The LureSource element describes the
source of the PhraudReport lure. It allows the specification of IP
Addresses, DNS names, domain registry information, and rudimentary
support for the files that might be downloaded or registry keys
modified by the crimeware.
Cain & Jevans Expires May 27, 2010 [Page 16]
Internet-Draft IODEF Phishing Extensions November 2009
+-------------+
| LureSource |
+-------------+
| |<>--(1..*)--[ System ]
| |<>--(0..*)--[ DomainData ]
| |<>--(0..1)--[ IncludedMalware ]
| |<>--(0..1)--[ FilesDownloaded ]
| |<>--(0..1)--[ WindowsRegistryKeysModified ]
+-------------+
Figure 5.2: The LureSource element
5.9.1. System element
REQUIRED. One or more values of the iodef:System [RFC5070, Section
3.15]. The system element describes a particular host involved in
the phishing activity. If the real IP Address can be ascertained, it
should be populated. A spoofed address may also be entered and the
spoofed attribute SHALL be set.
Multiple System elements may be used to identify the DNS Name, IP
Address(es) of the lure source.
5.9.2. DomainData element
Zero or more element values. The DomainData element describes the
registration, delegation, and control of a domain used to source the
lure and can identify the IP address associated with the System
element URI. Capturing the domain data is very useful when
investigating or correlating events.
The structure of a DomainData element is as follows:
+--------------------+
| DomainData |
+--------------------+
| |<>----------[ Name ]
| |<>--(0..1)--[ DateDomainWasChecked ]
| ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ]
| ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ]
| |<>--(0..*)--[ Nameservers ]
| |<>--(0..1)--[ DomainContacts ]
+--------------------+
Figure 5.3 The DomainData element
Cain & Jevans Expires May 27, 2010 [Page 17]
Internet-Draft IODEF Phishing Extensions November 2009
5.9.2.1. Name
REQUIRED. One value of iodef:MLStringType. The Name element
contains the host DNS name used in this event. Its value should be
the complete DNS host address, e.g., if an event targeted
www.example.com the value would be www.example.com.
5.9.2.2. DateDomainWasChecked
Zero or One value of DATETIME. This element includes the timestamp
of when this domain data was checked and entered into this report as
many phishers modify their domain data at various stages of a
phishing event.
5.9.2.3. RegistrationDate element
Zero or one value of DATETIME. The RegistrationDate element shows
the date of registration for a domain.
5.9.2.4. ExpirationDate element
Zero or one value of DATETIME. The ExpirationDate element shows the
date the domain will expire.
5.9.2.5. Nameservers element
Zero or more values. These fields hold name servers identified for
this domain. Each entry is a sequence of DNSNameType and iodef:
Address pairs as specified below.
+--------------------+
| Nameservers |
+--------------------+
| |<>----------[ Server]
| |<>--(1..*)--[ iodef:Address ]
+--------------------+
Figure 5.4 The Nameservers element
The use of one Server value and multiple Address values is used to
note multiple IPAddreses associated with one DNS entry for the domain
nameserver.
5.9.2.5.1. Server element
One value of iodef:MLStringType. This field contains the DNS name of
the domain nameserver.
Cain & Jevans Expires May 27, 2010 [Page 18]
Internet-Draft IODEF Phishing Extensions November 2009
5.9.2.5.2. iodef:Address element
One or more values of iodef:Address. This field lists the IP
Address(es) associated with this Server element.
5.9.2.6. DomainContacts element
REQUIRED. Choice of either a SameDomainContact or one or more
Contact elements. The DomainContacts element allows the reporter to
enter contact information supplied by the registrar or returned by
Whois queries. For efficiency of the reporting party, the domain
contact information may be marked to be the same as another domain
already reported using the SameDomainContact element.
+----------------+
| DomainContacts |
+----------------+
| |<>--(0..1)--[ SameDomainContact ]
| |<>--(1..*)--[ Contact ]
+----------------|
Figure 5.5 The DomainContacts element
5.9.2.6.1. SameDomainContact
REQUIRED. One iodef:MLStringType. The SameDomainContact element is
populated with a domain name if the contact information for this
domain is identical to that name in this or another report.
Implementors are cautioned to only use this element when the domain
contact data returned by a registrar or registry is identical.
5.9.2.6.2. Contact Element
REQUIRED. One or more iodef:Contact elements. This element reuses
and extends the iodef:Contact elements for its components. Each
component may have zero or more values. If only the role attribute
and the ContactName component are populated, the same (identical)
information is listed for multiple roles.
Cain & Jevans Expires May 27, 2010 [Page 19]
Internet-Draft IODEF Phishing Extensions November 2009
+--------------------+
| Contact |
+--------------------+
| |<>----------[ iodef:ContactName ]
| |<>--(0..*)--[ iodef:Description ]
| ENUM role |<>--(0..*)--[ iodef:RegistryHandle ]
| |<>--(0..1)--[ iodef:PostalAdress ]
| ENUM Restriction |<>--(0..*)--[ iodef:Email ]
| ENUM ext-role |<>--(0..*)--[ iodef:Telephone ]
| ENUM type |<>--(0..1)--[ iodef:Fax ]
| ENUM ext-type |<>--(0..1)--[ iodef:Timezone ]
| |<->----------[ AdditionalData ]
| | +<-> [ Confidence ]
+--------------------+
Figure 5.6: The Contact element
Each Contact has optional attributes to capture the sensitivity and
role for which the contact is listed. Elements reused from [RFC5070]
are not discussed in this document.
5.9.2.6.2.1. Confidence element
REQUIRED. ENUM. The Confidence element describes a qualitative
assessment of the veracity of the contact information. This
attribute is an extension to the iodef:Contact element and is defined
in this document. There are five possible confidence values as
follows.
1. known-fraudulent. This contact information has been previously
determined to be fraudulent, either as non-existent physical
information or containing real information not associated with
this domain registration.
2. looks-fraudulent. The contact information has suspicious
information included.
3. known-real. The contact information has been previously
investigated or determined to be correct.
4. looks-real. The contact information does not arouse suspicion
but has not been previously validated.
5. unknown. The reporter cannot make a value judgment on the
contact data.
Cain & Jevans Expires May 27, 2010 [Page 20]
Internet-Draft IODEF Phishing Extensions November 2009
5.9.2.6.2.2. Ext-role attribute
REQUIRED. ENUM. The ext-role attribute is extended from the iodef:
ext-role attribute with values identified in RFC3982 [RFC3982]. The
ext-value value of the role attribute should be used, with the ext-
role attribute value chosen from one of the following values:
1. billingContacts
2. technicalContacts
3. administrativeContacts
4. legalContacts
5. zoneContacts
6. abuseContacts
7. securityContacts
8. otherContacts
9. hostingProvider. This contact is the hosting provider of this
server. Although not in RFC3982, it is useful in investigations
to note where the server is located and who operates it. Load
balanced, multicast or anycast servers may have multiple
hostingProvider contact entries.
5.9.3. SystemStatus attribute
REQUIRED. ENUM. The SystemStatus attribute assesses a system's
involvement in this event. The value is chosen from this list:
1. spoofed. This domain or system did not participate in this
event, but its address space or DNS name was simply used by
another party.
2. fraudulent. The system is operated with fraudulent intentions,
e.g., the domain name is a homophone.
3. innocent-hacked. The system was compromised by a third party and
used in this event.
4. innocent-hijacked. The IP Address or domain name was
deliberately hijacked via BGP or DNS and used in this event to
source the lure or host the collection site.
Cain & Jevans Expires May 27, 2010 [Page 21]
Internet-Draft IODEF Phishing Extensions November 2009
5. unknown. No conclusions are inferred from this event.
5.9.4. DomainStatus attribute
ENUM. The DomainStatus attribute describes the registry status of a
domain at the time of the report. The below enumerated list is taken
from the 'domainStatusType' of `[RFC3982]. An extra 'unknown' value
was added in case the Status is undeterminable.
1. reservedDelegation
2. assignedAndActive
3. assignedAndInactive
4. assignedAndOnHold
5. revoked
6. transferPending
7. registryLock
8. registrarLock
9. other
10. unknown
5.9.5. IncludedMalware element
Zero or One Value. The IncludedMalware element allows for the
identification and optional inclusion of the actual malware that was
part of the lure. The goal of this element is not to detail the
characteristics of the malware but rather to allow for a convenient
element to link malware to a phishing campaign.
Cain & Jevans Expires May 27, 2010 [Page 22]
Internet-Draft IODEF Phishing Extensions November 2009
+------------------+
| IncludedMalware |
+------------------+
| |<>--(1..*)--[ Name ]
| |<>--(0..1)--[ ds:Reference ]
| |<>--(0..1)--[ Data ]
+------------------+
+-----------------------+
| Data |
+-----------------------+
| hexBinary XORPattern |
+-----------------------+
Figure 5.7: The Included Malware element
5.9.5.1. Name element
REQUIRED. One or more value of iodef:MLStringType. This field is
used to identify the lure malware by its known name. Unnamed malware
may be identified by a value of 'unknown'.
5.9.5.2. Reference element
Zero or one value of the Reference. This optional field is used to
hold the Algorithm identification and value of a hash computed over
the malware executable. This entire element is imported from
[RFC3275]. Implementations SHOULD support the use of SHA-1 [SHA] as
a DigestMethod.
5.9.5.3. Data element
Zero or one value. The optional Data element is used to include the
lure malware, which is encoded as a hexBinary type and XORed with a
pattern to render it harmless.
5.9.5.3.1. XORPattern attribute
One value of hexBinary. The Data Element includes a 16 hexadecimal
character XOR Pattern attribute to support disabling the included
malware to bypass anti-virus filters. The default value is
0x55AA55AA55AA55BB which would be XOR-ed with the malware datastring
to recover the actual malware.
Cain & Jevans Expires May 27, 2010 [Page 23]
Internet-Draft IODEF Phishing Extensions November 2009
5.9.6. FilesDownloaded element
Zero or One value of a sequence of File elements.
+---------------------+
| FilesDownloaded |
+---------------------+
| |<>--(1..*)--[ File ]
+---------------------+
Figure 5.8: The FilesDownloaded element
5.9.6.1. File element
One or more values of iodef:MLStringType. The File element value is
the name of a file downloaded by this lure.
5.9.7. WindowsRegistryKeysModified element
One or more valuev of the Key sequence. The contents of the
WindowsRegistryKeysModified element are sequences of Key elements.
+------------------------------+
| WindowsRegistryKeysModified |
+------------------------------+
| |<>--(1..*)--[ Key ]
+------------------------------+
+--------------+
| Key |
+--------------+
| |<>-----[ Name ]
| |<>-----[ Value ]
+--------------+
Figure 5.9: The WindowsRegistryKeysModified element
5.9.7.1. Key element
One or more Sequences. The key element is a sequence of Name and
Value pairs representing an operating system registry key and its
value. The key and value are encoded as in Microsoft .reg files.
[KB310516]
Cain & Jevans Expires May 27, 2010 [Page 24]
Internet-Draft IODEF Phishing Extensions November 2009
5.9.7.1.1. Name element
One STRING, representing the WINDOWS Operating System Registry Key
Name. The value is encoded as in Microsoft .reg files, e.g.,
[HKEY_LOCAL_MACHINE\Software\Test\KeyName].
5.9.7.1.2. Value element
One STRING, representing the value of the associated Key encoded as
in Microsoft .reg files, e.g., REG_BINARY:01.
5.10. OriginatingSensor Element
REQUIRED. The OriginatingSensor element contains the identification
and cognizant data of the network element that detected this fraud
activity. Note that the network element does not have to be on the
Internet itself (i.e., it may be a local IDS system) nor is it
required to be mechanical (e.g., humans are allowed).
Multiple OriginatingSensor Elements are allowed to support detection
at multiple locations.
+---------------------+
| OriginatingSensor |
+---------------------+
| ENUM OrigSensorType |<>------------[ DateFirstSeen ]
| |<>------------[ iodef:System ]
+---------------------+
Figure 5.10: The OriginatingSensor element
The OriginatingSensor requires a type value and identification of the
entity that detected this fraudulent event.
5.10.1. OrigSensorType attribute
REQUIRED. ENUM. The value is chosen from the following list,
categorizing the function of this sensor:
1. web. A web server or service detected this event.
2. webgateway. A proxy, firewall, or other network gateway
detected this event.
3. mailgateway. The event was detected via a mail gateway or
filter
Cain & Jevans Expires May 27, 2010 [Page 25]
Internet-Draft IODEF Phishing Extensions November 2009
4. browser. The event was detected at the user web interface or
browser-type element..
5. ispsensor. The event was detected by an automated system in
the network such as Intrusion Detection System, Intrusion
Protection System, or other Internet Service Provider device.
6. human. A non-automated system (e.g., a human, manual
analysis, etc) detected this event.
7. honeypot. The event was detected by receipt at a decoy
device.
8. other. The detection was performed via a non-listed method.
5.10.2. DateFirstSeen element
REQUIRED. DATETIME. This is the date and time that this sensor
first saw this phishing activity.
5.10.3. iodef:System element
REQUIRED. One or more iodef:System. This is identification
information (such as the IPVersion, IPAddress, etc) of the entity
that detected this event. The ability to identify multiple
detectors is supported.
5.11. The DCSite element
Zero or more DCSite elements. The DCSite captures the type,
identifier, location, and other pertinent information about the
credential gathering process, or data collection site, used in the
phishing incident. The data collection site is identified by four
elements: the type of collector, the network location, information
about its DNS Domain, and a confidence factor. Further details about
the domain, system, or owner of the DCSite can be inserted into the
DomainData sub-element.
If the DCSite element is present, a value is required. Multiple
DCSite elements are allowed to indicate multiple collection sites for
a single collector. Multiple URLs pointing to the same DNS entry can
be identified with multiple SiteURL elements.
Cain & Jevans Expires May 27, 2010 [Page 26]
Internet-Draft IODEF Phishing Extensions November 2009
+--------------+
| DCSite |
+--------------+
| ENUM DCType |<>--+--------[ SiteURL ]
| | +--------[ Domain ]
| | +--------[ EmailSite ]
| | +--------[ System ]
| | +--------[ Unknown ]
| |<>--(0..*)---[ iodef:Node ]
| |<>--(0..1)---[ DomainData ]
| |<>--(0..1)---[ iodef:Assessment ]
+--------------+
Figure 5.11: The DCSite element
5.11.1. DCType attribute
REQUIRED. ENUM. The DCType attribute identifies the method of data
collection as determined through the analysis of the victim computer,
lure, or malware. This attribute coupled with the DCSite content
identifies the data collection site.
1. web. The user is redirected to a website to collect the data.
2. email. The victim sends an email with credentials enclosed.
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 on the
user's machine.
5. unspecified.
5.11.2. DCSite values
REQUIRED. The DCSite element contains the IPAddress, URL, emailsite,
or other identifier of the credentail or data collection site. The
Domain choice may be used to identify entire 'phishy' domains like
those used for the RockPhish and related malware. Each DCSite
element also includes a confidence attribute to convey the reporter's
assessment of their confidence that this DCSite element is valid, and
involved with this event. The confidence value is a per-DCSite value
as multiple-site data collectors may have different confidence
values.
The DCSite element is a choice of:
Cain & Jevans Expires May 27, 2010 [Page 27]
Internet-Draft IODEF Phishing Extensions November 2009
1. SiteURL. One value of iodef:MLStringType. This choice supports
URIs and other web-based identifiers.
2. Domain. One value of iodef:MLStringType. This choice allows the
entry of a DNS Domain name.
3. EmailSite. One value of iodef:MLStringType. This choice
includes an email address if the site used email communications.
4. iodef:Address. One value of iodef:Address element. This choice
is used to capture the IP Address of a site.
5. Unknown. One value of iodef:MLStringType. The unknown entry is
used for exception to the preceding choices.
5.11.2.1. Confidence attribute
One Value of STRING. The confidence attribute is a value between 0
and 100 representing the reporter's certainty that this is a genuine
phishing site. A value of 0 represents a false positive; a value of
100 signifies that the reporter has independently verified this site.
5.11.3. iodef:Node
Zero or more values of iodef:Node. This element is used to identify
the IP Address(es) or DNS Names associated with the DCSite element
value.
5.11.4. DomainData element
Zero or One value of DomainData Section 5.9.2. This element allows
for the identification of data associated with the data collection
site.
5.11.5. iodef:Assessment element
Zero or One value of iodef:Assessment. This element is used to
designate different confidence levels of multiple-site data
collectors.
5.12. TakeDownInfo element
Zero or more TakeDownInfo elements. This element identifies the
agent or agency that performed the removal, DNS domain disablement,
or ISP-blockage of the phish or fraud collector site. A PhraudReport
may have multiple TakeDownInfo elements to support activities where
multiple take down activities are involved on different dates. Note
that the term "Agency" is used to identify any party performing the
Cain & Jevans Expires May 27, 2010 [Page 28]
Internet-Draft IODEF Phishing Extensions November 2009
blocking or removal such as ISPs or private parties, not just
government entities.
The TakeDownInfo element allows one date element with multiple
TakeDownAgency and Comment elements to support operations using
multiple agencies.
+-------------------+
| TakeDownInfo |
+-------------------+
| |<>---(0..1)--[ TakeDownDate ]
| |<>---(0..*)--[ TakeDownAgency ]
| |<>---(0..*)--[ TakeDownComments ]
+-------------------+
Figure 5.12: The TakeDownInfo element
5.12.1. TakeDownDate
Zero or one DATETIME. This is the date and time that take down of
the collector site occurred.
5.12.2. TakeDownAgency
Zero or more iodef:MLStringType elements. This is a free form string
identifying the agency, corporation, or cooperative that performed
the take down.
5.12.3. TakeDownComments
Zero or more iodef:MLStringType elements. A free form field to add
any additional details of this take down effort or to identify
parties that assisted in the effort at an ISP, CERT, or DNS Registry.
5.13. ArchivedData element
Zero or more values of the ArchivedData element are allowed.
+-------------------+
| ArchivedData |
+-------------------+
| ENUM type |<>---(0..1)--[ URL ]
| |<>---(0..1)--[ Comments ]
| |<>---(0..1)--[ Data ]
+-------------------+
Figure 5.13: The ArchivedData element
Cain & Jevans Expires May 27, 2010 [Page 29]
Internet-Draft IODEF Phishing Extensions November 2009
The ArchivedData element is populated with a pointer to the contents
of a data collection site, base camp (i.e., development site), or
other site used by a phisher. The ArchivedDataInfo may also include
a copy of the archived data recovered from a phishing system. This
element will be populated when, for example, an ISP takes down a
phisher's web site and has copied the site data into an archive file.
There are four types of archives currently supported, as specified in
the type field.
5.13.1. type attribute
REQUIRED. This parameter specifies the type of site data pointed to
by the ArchivedDataURL, from the following list:
1. collectionsite. The archive is a set of files from the
collection site.
2. basecamp. The contents of a criminal development site are
included in the archive.
3. sendersite. The archive is a set of files or data from a
phishing lure sending site.
4. credentialInfo. The included archive are recovered private
credentials.
5. unspecified. The archive contents does not fit into one of the
above categories and will be described in the DataComments
element.
5.13.2. URL element
Zero or one value of anyURL. As the archive of an entire site can be
quite large, the URL element points to an Internet-based server where
the actual content of the site archive can be retrieved. Note that
this element just points out where the archive is and does not
include the entire archive in the report. This is the URL where the
archive file is located.
5.13.3. Comments element
Zero or one value of iodef:MLStringType. This field is a free form
area for comments on the archive and/or URL.
Cain & Jevans Expires May 27, 2010 [Page 30]
Internet-Draft IODEF Phishing Extensions November 2009
5.13.4. Data element
Zero or one value of xs:Base64Binary. This field contains a base64
encoded version of the data described in the comment field above.
5.14. RelatedData element
Zero or more value of anyURI. This element allows the listing of
other web or net sites that are related to this incident (e.g.,
victim site, etc.).
5.15. CorrelationData element
Zero or more value of iodef:MLStringType. Any information that
correlates this incident to other incidents can be entered here.
5.16. PRComments element
Zero or one value of iodef:MLStringType. This field allows for any
comments specific to this PhraudReport that does not fit in any other
field.
5.17. EmailRecord element
This element supports the inclusion of the actual email message
received as a phishing lure. Inclusion of the actual mail message is
supported by two methods; either the message may be included as one
large string, or the header and body components may be dissected and
included as a series of strings.
+--------------------+
| EmailRecord |
+--------------------+
| |<>--------------[ EmailCount ]
| |<>--(0..1)------[ EmailMessage ]
| |<>--(0..1)------[ EmailComments ]
+--------------------+
Figure 5.14: The EmailRecord element
5.17.1. EmailCount element
REQUIRED. INTEGER. This field enumerates the number of email
messages identified in this record as detected by the reporter.
Cain & Jevans Expires May 27, 2010 [Page 31]
Internet-Draft IODEF Phishing Extensions November 2009
5.17.2. EmailMessage element
Zero of one value of iodef:MLStringType. The entire SMTP mail
message - RFC822 header followed by body as specified in [RFC5322] -
should be inserted as one large text string. In some communities
this combination is known as the message contents and full headers.
5.17.3. EmailComments element
Zero or one value of iodef:MLStringType elements. This field
contains comments or relevant data not placed elsewhere about the
phishing email.
Cain & Jevans Expires May 27, 2010 [Page 32]
Internet-Draft IODEF Phishing Extensions November 2009
6. Mandatory IODEF and PhraudReport Elements
A report about fraud or phishing requires certain identifying
information which is contained within the standard IODEF Incident
data structure and the PhraudReport extensions. The following table
identifies attributes required to be present in a compliant
PhraudReport to report phishing or fraud. The required attributes
are a combination of those required by the base IODEF element, as
shown in figure 6.1, and those required by this document, shown in
figure 6.2. Attributes identified as required SHALL be populated in
conforming phishing activity reports.
A compliant IODEF PhraudReport SHALL contain the following elements
and attributes:
+--------------+
| Incident |
+--------------+
| ENUM Purpose |---[ IncidentID ]
| |---[ ReportTime ]
| |---[ Assessment ]
| | ---> [ Impact ]
| |---[ Contact ]
| | ---> [ @type ]
| | ---> [ @role ]
| | ---> [ * ]
| |---[ EventData ]
| | ---> [ DetectTime ]
| | ---> [ AdditionalData ]
| | ---> [ PhraudReport ]
+--------------+
Figure 6.1. IODEF Required classes for a PhraudReport
+----------------+
| PhraudReport |
+----------------+
| ENUM FraudType |---[ LureSource ]
| STRING Version | ---> [ iodef:System ]
| |---[ OriginatingSensor ]
| | --> [ DateFirstSeen ]
| | --> [ iodef:System ]
| | --> [ iodef:Node ]
| |
+----------------+
Figure 6.2 PhraudReport Required Elements.
Cain & Jevans Expires May 27, 2010 [Page 33]
Internet-Draft IODEF Phishing Extensions November 2009
* Note that the iodef:Contact element is required, but none of its
sub-elements are required. For proper XML correctness, one of the
sub-elements is required; pick one.
6.1. Guidance on Usage
It may be apparent that the mandatory attributes for a PhraudReport
make for a quite sparse report. As incident forensics and data
analysis require detailed information, the originator of a
PhraudReport SHOULD include any tidbit of information gleaned from
the attack analysis. Information that is considered sensitive can be
marked as such using the restriction parameter of each data element.
The reporting party is encouraged to provide more than just the
minimally required data elements about an event in a PhraudReport.
The additional information may be volatile and not recoverable in the
future, and may be useful in answering investigation questions or in
performing correlation with other reported events.
Cain & Jevans Expires May 27, 2010 [Page 34]
Internet-Draft IODEF Phishing Extensions November 2009
7. Security Considerations
This document specifies a format for encoding a particular class of
security incidents appropriate for exchange across organizations. As
merely a data representation, it does not directly introduce security
issues. However, it is guaranteed that parties exchanging instances
of this specification will have certain concerns. For this reason,
the underlying message format and transport protocol used MUST ensure
the appropriate degree of confidentiality, integrity, and
authenticity for the specific environment.
Organizations that exchange data using this document are URGED to
develop operating procedures that document the following areas of
concern.
7.1. Transport-specific concerns
The critical security concerns are that phishing activity reports may
be falsified or the PhraudReport may become corrupt during transit.
In areas where transmission security or secrecy is questionable, the
application of a digital signature and/or message encryption on each
report will counteract both of these concerns. We expect that each
exchanging organization will determine the need, and mechanism, for
transport protection..
7.2. Using the iodef:restriction attribute
In some instances data values in particular elements may contain data
deemed sensitive by the reporter. Although there are no general-
purpose rules on when to mark certain values as "private" or "need-
to-know" via the iodef:restriction attribute, the reporter is
cautioned to not apply element-level sensitivity markings unless they
believe the receiving party (i.e., the party they are exchanging the
event report data with) has a mechanism to adequately safeguard and
process the data as marked. For example, if the PhraudReport element
is marked private and contains a phishing collector URL in the
DCSite/SiteURL element, can that URL be included within a block list
distributed to other parties? No guidance is provided here except to
urge exchanging parties to review the IODEF and PhraudReport
documents to decide on common marking rules.
Cain & Jevans Expires May 27, 2010 [Page 35]
Internet-Draft IODEF Phishing Extensions November 2009
8. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in "RFC3688".
Registration request for the IODEF phishing namespace:
URI: urn:ietf:params:xml:ns:iodef-phish-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None.
Registration request for the IODEF phishing extension XML schema:
URI: urn:ietf:params:xml:schema:iodef-phish-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: See the "Phishing Extensions Schema Definition" in the
<Appendix A> section of this document.
Cain & Jevans Expires May 27, 2010 [Page 36]
Internet-Draft IODEF Phishing Extensions November 2009
9. 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. (The APWG has no relationship to an IETF working
group.)
This document has received significant assistance from members of the
IETF INCH working group and two groups addressing the phishing
problem: members of the APWG and participants in the Financial
Services Technology Consortium's Counter-Phishing project. A special
thanks goes to the hardy people who supplied valuable feedback after
using this format to report phishing.
Cain & Jevans Expires May 27, 2010 [Page 37]
Internet-Draft IODEF Phishing Extensions November 2009
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[RFC3982] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg)
Type for the Internet Registry Information Service
(IRIS)", RFC 3982, January 2005.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070,
December 2007.
[SHA] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard",
FIPS 180-2, August 2002.
10.2. Informative References
[KB310516]
Microsoft Corporation, "How to add, modify, or delete
registry subkeys and values by using a registration
entries (.reg) file", December 2007.
[RFC3688] Mealing, M., "The IETF XML Registry", RFC 3688,
January 2004.
Cain & Jevans Expires May 27, 2010 [Page 38]
Internet-Draft IODEF Phishing Extensions November 2009
Appendix A. Appendix A. Phishing Extensions XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212
/xmldsig-core-schema.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/>
<!--
This Schema complies with draft-cain-post-inch-phishingextns-07.txt
==========================================================
=== Top Level Class: PhraudReport ===
==========================================================
It is incorporated within an
IODEF.Incident.EventData.AdditionalData element.
All the top-level or major elements are defined as xs:types to make
future extension easier.
-->
<xs:element name="PhraudReport">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="PhishNameRef"
type="iodef:MLStringType"/>
<xs:element minOccurs="0" name="PhishNameLocalRef"
type="iodef:MLStringType"/>
<xs:element minOccurs="0" name="FraudParameter"
type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="FraudedBrandName" type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
Cain & Jevans Expires May 27, 2010 [Page 39]
Internet-Draft IODEF Phishing Extensions November 2009
name="LureSource" type="phish:LureSource.type"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
name="OriginatingSensor"
type="phish:OriginatingSensor.type"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailRecord"
type="phish:EmailRecord.type"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="DCSite" type="phish:DCSite.type"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:TakeDownInfo"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:ArchivedData"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="RelatedData" type="xs:anyURI"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="CorrelationData" type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="PRComments"
type="iodef:MLStringType"/>
</xs:sequence>
<xs:attribute default="1.0" name="Version" use="optional"/>
<xs:attribute name="FraudType" type="phish:FraudType.type"
use="required"/>
<xs:attribute name="ext-value" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="FraudType.type">
<xs:restriction base="xs:string">
<xs:enumeration value="phishing"/>
<xs:enumeration value="recruiting"/>
<xs:enumeration value="malware distribution"/>
<xs:enumeration value="fraudulent site"/>
<xs:enumeration value="dnsspoof"/>
<xs:enumeration value="archive"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
<!--
==========================================================
=== End of the Top-Level Element ===
==========================================================
Cain & Jevans Expires May 27, 2010 [Page 40]
Internet-Draft IODEF Phishing Extensions November 2009
-->
<!--
==========================================================
=== The Lure Source Element ===
==========================================================
-->
<xs:complexType mixed="false" name="LureSource.type">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
<xs:element minOccurs="0" maxOccurs="unbounded"
ref="phish:DomainData"/>
<xs:element minOccurs="0" name="IncludedMalware"
type="phish:IncludedMalware.type"/>
<xs:element minOccurs="0" name="FilesDownloaded">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" name="File"
type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="WindowsRegistryKeysModified">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Key">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Value" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
=== LureSource sub-elements ===
-->
Cain & Jevans Expires May 27, 2010 [Page 41]
Internet-Draft IODEF Phishing Extensions November 2009
<xs:complexType name="IncludedMalware.type">
<xs:sequence>
<xs:element name="Name"
maxOccurs="unbounded" type="iodef:MLStringType"/>
<xs:element minOccurs="0" ref="ds:Reference"/>
<xs:element minOccurs="0" name="Data">
<xs:complexType >
<xs:simpleContent>
<xs:extension base="xs:hexBinary">
<xs:attribute default="55AA55AA55AA55BB"
name="XORPattern" type="xs:hexBinary"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
===========================================================
=== The EmailRecord Element ===
===========================================================
-->
<xs:complexType name="EmailRecord.type">
<xs:sequence>
<xs:element name="EmailCount" type="xs:integer"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailMessage"
type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailComments"
type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
<!--
===========================================================
=== The Data Collection Site (DCSite) Info Element ===
===========================================================
-->
<xs:complexType name="DCSite.type">
<xs:sequence>
<xs:choice>
<xs:element name="SiteURL">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
Cain & Jevans Expires May 27, 2010 [Page 42]
Internet-Draft IODEF Phishing Extensions November 2009
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Domain">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="EmailSite">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="System">
<xs:complexType id="SystemType">
<xs:sequence>
<xs:element ref="iodef:Address"/>
</xs:sequence>
<xs:attribute ref="phish:confidence"/>
</xs:complexType>
</xs:element>
<xs:element name="Unknown">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:choice>
<xs:element ref="iodef:Node" minOccurs="0" maxOccurs="unbounded"/>
<xs:element minOccurs="0" ref="phish:DomainData"/>
<xs:element minOccurs="0" ref="iodef:Assessment"/>
Cain & Jevans Expires May 27, 2010 [Page 43]
Internet-Draft IODEF Phishing Extensions November 2009
</xs:sequence>
<xs:attribute name="DCType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
<xs:enumeration value="email"/>
<xs:enumeration value="keylogger"/>
<xs:enumeration value="automation"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!--
==============================================
==== The Domain Data Element used in System =====
==============================================
-->
<xs:element name="DomainData">
<xs:complexType id="DomainData.type">
<xs:sequence>
<xs:element maxOccurs="1"
name="Name" type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="DateDomainWasChecked" type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="RegistrationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="Nameservers">
<xs:complexType id="Nameservers.type">
<xs:sequence>
<xs:element name="Server" type="iodef:MLStringType"/>
<xs:element ref="iodef:Address" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice id="DomainContacts" maxOccurs="1" minOccurs="0">
<xs:element name="SameDomainContact"
type="iodef:MLStringType"/>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:Contact"/>
</xs:sequence>
Cain & Jevans Expires May 27, 2010 [Page 44]
Internet-Draft IODEF Phishing Extensions November 2009
</xs:choice>
</xs:sequence>
<xs:attribute name="SystemStatus">
<xs:simpleType id="SystemStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="spoofed"/>
<xs:enumeration value="fraudulent"/>
<xs:enumeration value="innocent-hacked"/>
<xs:enumeration value="innocent-hijacked"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="DomainStatus">
<xs:simpleType id="DomainStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="reservedDelegation"/>
<xs:enumeration value="assignedAndActive"/>
<xs:enumeration value="assignedAndInactive"/>
<xs:enumeration value="assignedAndOnHold"/>
<xs:enumeration value="revoked"/>
<xs:enumeration value="transferPending"/>
<xs:enumeration value="registryLock"/>
<xs:enumeration value="registrarLock"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="Confidence">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:attribute name="confidence">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
Cain & Jevans Expires May 27, 2010 [Page 45]
Internet-Draft IODEF Phishing Extensions November 2009
</xs:simpleType>
</xs:attribute>
<!--
=========================================================
= ext-role Values for use within the DomainContact Contacts element ==
=========================================================
-->
<xs:simpleType name="ext-role">
<xs:restriction base="xs:string">
<xs:enumeration value="billingContacts"/>
<xs:enumeration value="technicalContacts"/>
<xs:enumeration value="administrativeContacts"/>
<xs:enumeration value="legalContacts"/>
<xs:enumeration value="zoneContacts"/>
<xs:enumeration value="abuseContacts"/>
<xs:enumeration value="securityContacts"/>
<xs:enumeration value="otherContacts"/>
<xs:enumeration value="hostingProvider"/>
</xs:restriction>
</xs:simpleType>
<!--
=================================================
=== The Originating Sensor Data Element ===
=================================================
-->
<xs:complexType name="OriginatingSensor.type">
<xs:sequence>
<xs:element name="DateFirstSeen" type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
</xs:sequence>
<xs:attribute name="OriginatingSensorType" use="required">
<xs:simpleType id="OriginatingSensorType.type">
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="web"/>
<xs:enumeration value="webgateway"/>
<xs:enumeration value="mailgateway"/>
<xs:enumeration value="browser"/>
<xs:enumeration value="ispsensor"/>
<xs:enumeration value="human"/>
<xs:enumeration value="honeypot"/>
<xs:enumeration value="other"/>
</xs:restriction>
Cain & Jevans Expires May 27, 2010 [Page 46]
Internet-Draft IODEF Phishing Extensions November 2009
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!--
======================================================
=== The Take Down Data structure. ===
======================================================
-->
<xs:element name="TakeDownInfo" type="phish:TakeDownInfo.type"/>
<xs:complexType name="TakeDownInfo.type">
<xs:sequence>
<xs:element maxOccurs="1" minOccurs="0" name="TakeDownDate"
type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownAgency" type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownComments" type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
<!--
=========================================================
=== The Archived Data Element ===
=========================================================
-->
<xs:element name="ArchivedData" type="phish:ArchivedData.type"/>
<xs:complexType name="ArchivedData.type">
<xs:sequence>
<xs:element minOccurs="0" name="URL" type="xs:anyURI"/>
<xs:element minOccurs="0" name="Comments"
type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="Data"
type="xs:base64Binary"/>
</xs:sequence>
<xs:attribute name="type" use="required">
<xs:simpleType id="ArchivedDataType.type">
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="collectionsite"/>
<xs:enumeration value="basecamp"/>
<xs:enumeration value="sendersite"/>
Cain & Jevans Expires May 27, 2010 [Page 47]
Internet-Draft IODEF Phishing Extensions November 2009
<xs:enumeration value="credentialInfo"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:schema>
Cain & Jevans Expires May 27, 2010 [Page 48]
Internet-Draft IODEF Phishing Extensions November 2009
Appendix B. Example Virus Report
This section shows a received electronic mail message that included a
virus in a zipped attachment and a report that was generated for that
message.
B.1. Received Email
From: support@example.com
Sent: Friday, June 10, 2005 3:52 PM
To: someone@example.com
Subject: Account update
To: someone@example.com
Date: Sun, 10 May 2005 3:52:44 +0200
We would like to inform you that we have released a new version of our
Customer Form. This form is required to be completed by all customers.
Please follow these steps:
1.Open the form at http://www.example.com/customerservice/cform.php
<http://www.2.example.com/customerservice/cform.php
&email=(someone@example.com)> .
2.Follow given instructions.
Thank you,
Our Support Team
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 lang="en-US"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<Incident purpose="reporting" ext-purpose="create">
<IncidentID name="example.com">PAT2005-06</IncidentID>
<ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
<Description>This is a test report from actual data.
</Description>
<Assessment>
Cain & Jevans Expires May 27, 2010 [Page 49]
Internet-Draft IODEF Phishing Extensions November 2009
<Impact type="social-engineering"/>
<Confidence rating="high"/>
</Assessment>
<Contact role="creator" type="person">
<ContactName>patcain</ContactName>
<Email>pcain@coopercain.com</Email>
</Contact>
<EventData>
<DetectTime>2005-06-21T18:22:02-05:00</DetectTime>
<AdditionalData dtype="xml">
<phish:PhraudReport FraudType="phishing">
<phish:FraudParameter>
Subject: You have successfully updated your password
</phish:FraudParameter>
<phish:FraudedBrandName>Cooper-Cain
</phish:FraudedBrandName>
<phish:LureSource>
<System category="source">
<Node>
<Address>192.0.2.18</Address>
</Node>
</System>
<phish:IncludedMalware>
<phish:Name>W32.Mytob.EA@mm</phish:Name>
</phish:IncludedMalware>
</phish:LureSource>
<phish:OriginatingSensor OriginatingSensorType="human">
<phish:DateFirstSeen>2005-06-10T15:52:11-05:00
</phish:DateFirstSeen>
<System>
<Node>
<Address>192.0.2.13</Address>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:EmailMessage>
Return-path: <support@example.com>
to: pcain@example.com
Delivery-date: Fri, 10 Jun 2005:52:11-0400
Received: from dsl18-2-0-192.dsl.example.net([192.0.2.18]
helo=example.com) by mail06.example.com esmtp (Exim) id
1DgpXy-0002Ua-IR for pcain@example.com;,
10 Jun 2005 15:52:10-0400
From: support@example.com
To: pcain@example.com
Subject: You have successfully updated your password
Cain & Jevans Expires May 27, 2010 [Page 50]
Internet-Draft IODEF Phishing Extensions November 2009
Date: Fri, 10 Jun 2005 12:52:00 -0700
MIME-Version: 1.0
Type: multipart/mixed;
="----=_NextPart_000_0008_0911068B.E7EB6D2A"
X-Priority: 3MSMail-Priority: Normal
X-EN-OrigIP: 192.0.2.18
EN-OrigHost: dsl18-2-0-192.dsl.example.net
Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16)
on.example.net
X-Spam-Level: ***** X-Spam-Status: No,
score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30,
HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE,
NO_REAL_NAME,
PRIORITY_NO_NAME autolearn=disabled version=3.0.2
From:support@example.com
Sent: Friday, June 10, 2005 3:52 PM
Subject: Account update
To: someone@example.com
Date: Sun, 10 June 2005 3:52:44 +0200
We would like to inform you that we have released a new version of our
Customer Form. This form is required to be completed by all customers.
Please follow these steps:
1.Open the form at http://www.example.com/customerservice/cform.php
<http://www.2.example.com/customerservice/cform.php
&email=(someone@example.com)> .
2.Follow given instructions.
Thank you,
Our Support Team
</phish:EmailMessage>
</phish:EmailRecord>
</phish:PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
Cain & Jevans Expires May 27, 2010 [Page 51]
Internet-Draft IODEF Phishing Extensions November 2009
Appendix C. Sample Phishing Report
A sample report generated from a received electronic mail phishing
message in shown in this section.
C.1. Received Lure
Return-path: <service@example.com>
Envelope-to: pcain@example.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.example.com ([10.1.1.161]
helo=mail15.example.com)
by mailscan38.example.com with esmtp (Exim)
id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006
05:37:21 -0400
Received: from [192.0.2.61] (helo=TSI)
by mail15.example.com with
esmtp (Exim) id 1Fq5Bj-0006dv-6b
for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400
Received: from User ([192.0.2.157]) by TSI with
Microsoft SMTPSVC(5.0.2195.6713);
Tue, 13 Jun 2006 02:24:30 -0400
Reply-To: <nospam@example.org>
From: "company"<service@example.com>
Subject: * * * Update & Verify Your Example Company Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@example.com
X-EN-OrigIP: 192.0.2.1
X-EN-OrigHost: unknown
Company<http://www.example.com/images/company_logo.gif>
<http://www.example.com/images/pixel.gif>
<http://www.example.com/images/pixel.gif>
<http://www.example.com/images/pixel.gif>
Account Update Request
Cain & Jevans Expires May 27, 2010 [Page 52]
Internet-Draft IODEF Phishing Extensions November 2009
Dear Example. member:,
You are receiving this notification because company is required by
law to notify you, that you urgently need to update your online
account statement, due to high risks of fraud intentions.
The updating of your example account can be done at any time by
clicking on the link shown below
http://www.example.com/cgi-bin/webscr?cmd=_login-run
<http://192.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20/%20/.payp
al.com/index.htm>
Once you log in,update your account information.
After updating your account click on the History sub tab of your
Account Overview page to see your most recent statement.
If you need help with your password, click the Help link which is at
the upper right hand side of the company website. To report errors
in your statement or make inquiries, click the Contact Us link in the
footer on any page of the company website, call our Customer Service
center at (999) 555-0167, or write us at:
Company, Inc.
P.O. Box 0
Anytown, MA 00000
Sincerely,
Big Example Company
<http://www.example.com/images/dot_row_long.gif>
C.2. Phishing Report
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" lang="en-US">
<Incident purpose="mitigation" ext-purpose="create"
restriction="private">
<IncidentID name="example.com">CC200600000002</IncidentID>
<ReportTime>2006-06-13T21:14:56-05:00</ReportTime>
<Description>This is a sample phishing email received report.
Cain & Jevans Expires May 27, 2010 [Page 53]
Internet-Draft IODEF Phishing Extensions November 2009
The phish was actually received as is.</Description>
<Assessment>
<Impact severity="high" type="social-engineering"/>
<Confidence rating="numeric">85</Confidence>
</Assessment>
<Contact role="creator" type="person">
<ContactName>patcain</ContactName>
<Email>pcain@example.com</Email>
</Contact>
<EventData>
<DetectTime>2006-06-13T05:37:21-04:00</DetectTime>
<AdditionalData dtype="xml">
<phish:PhraudReport FraudType="phishing">
<phish:FraudParameter>
* * * Update & Verify Your Company Account * * *
</phish:FraudParameter>
<phish:FraudedBrandName>company</phish:FraudedBrandName>
<phish:LureSource>
<System category="source">
<Node>
<Address>192.0.2.4</Address>
</Node>
</System>
</phish:LureSource>
<phish:OriginatingSensor OriginatingSensorType="mailgateway">
<phish:DateFirstSeen>
2006-06-13T05:37:22-04:00</phish:DateFirstSeen>
<System>
<Node>
<NodeRole category="mail"/>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:EmailMessage>
Return-path: <service@example.com>
Envelope-to: pcain@example.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.example.com ([10.1.1.161]
helo=mail15.example.com)
by mailscan38.example.com with esmtp (Exim)
id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006
05:37:21 -0400
Received: from [192.0.2.61] (helo=TSI)
by mail15.example.com with
esmtp (Exim) id 1Fq5Bj-0006dv-6b
for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400
Cain & Jevans Expires May 27, 2010 [Page 54]
Internet-Draft IODEF Phishing Extensions November 2009
Received: from User ([192.0.2.157]) by TSI with
Microsoft SMTPSVC(5.0.2195.6713);
Tue, 13 Jun 2006 02:24:30 -0400
Reply-To: <nospam@example.org>
From: "company"<service@example.com>
Subject: * * * Update & Verify Your Example Company Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@example.com
X-EN-OrigIP: 192.0.2.1
X-EN-OrigHost: unknown
<img src="http://www.example.com/images/company_logo.gif">
<img src="http://www.example.com/images/pixel.gif">
<img src="http://www.example.com/images/pixel.gif">
<img src="http://www.example.com/im/pixel.gif">
Account Update Request
Dear Example. member:,
You are receiving this notification because company is required by
law to notify you, that you urgently need to update your online
account statement, due to high risks of fraud intentions.
The updating of your example account can be done at any time by
clicking on the link shown below
<a href="http://192.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20/%20/.example.com/index.htm">
http://www.example.com/cgi-bin/webscr?cmd=_login-run </a>
Once you log in,update your account information.
After updating your account click on the History sub tab of your
Account Overview page to see your most recent statement.
If you need help with your password, click the Help link which is at
the upper right hand side of the company website. To report errors in
your statement or make inquiries, click the Contact Us link in the
Cain & Jevans Expires May 27, 2010 [Page 55]
Internet-Draft IODEF Phishing Extensions November 2009
footer on any page of the company website, call our Customer Service
center at (999) 555-0167, or write us at:
Company, Inc.
P.O. Box 0
Anytown, MA 00000
Sincerely,
Big Example Company
<img src="http://www.example.com/images/dot_row_long.gif">
</phish:EmailMessage>
</phish:EmailRecord>
<phish:DCSite DCType="web">
<phish:SiteURL>http://190.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20%20/.company.com/index.htm</phish:SiteURL>
<phish:DomainData DomainStatus="assignedAndActive"
SystemStatus="unknown">
<phish:Name>bad.example.com</phish:Name>
<phish:DateDomainWasChecked>2006-06-14T13:05:00-05:00
</phish:DateDomainWasChecked>
<phish:RegistrationDate>
2000-12-13T00:00:00</phish:RegistrationDate>
<phish:Nameservers>
<phish:Server>ns1.example.net</phish:Server>
<Address>192.0.2.18</Address>
</phish:Nameservers>
</phish:DomainData>
</phish:DCSite>
</phish:PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
Cain & Jevans Expires May 27, 2010 [Page 56]
Internet-Draft IODEF Phishing Extensions November 2009
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 May 27, 2010 [Page 57]