Network Working Group P. Cain
Internet-Draft The Cooper-Cain Group, Inc.
Expires: April 18, 2007 D. Jevans
The Anti-Phishing Working Group
October 15, 2006
Extensions to the IODEF-Document Class for Phishing, Fraud, and Other
Crimeware
draft-cain-post-inch-phishingextns-00
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 April 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document extends the Incident Object Description Exchange Format
(IODEF) to support the reporting of phishing, fraud, other types of
electronic crime, and widespread spam incidents. These extensions
are flexible enough to support information gleaned from activities
throughout the entire electronic fraud cycle. Both simple reporting
and complete forensic reports are possible, as is consolidated
Cain & Jevans Expires April 18, 2007 [Page 1]
Internet-Draft IODEF Phishing Extensions October 2006
reporting of multiple phishing incidents.
The extensions defined in this document are used to generate two
different reports: a fraud and phishing report and a wide-spread spam
report. Although similar in structure, each report has different
required objects and intents.
This document had completed working group last call and was in
revision when the INCH working group was disbanded.
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].
Cain & Jevans Expires April 18, 2007 [Page 2]
Internet-Draft IODEF Phishing Extensions October 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 Activity Reporting via IODEF-Documents . . . . . . . . . 8
4. PhraudReport Element Definitions . . . . . . . . . . . . . . . 9
4.1. Version attribute . . . . . . . . . . . . . . . . . . . . 9
4.2. FraudType attribute . . . . . . . . . . . . . . . . . . . 9
4.3. PhishNameRef element . . . . . . . . . . . . . . . . . . . 11
4.4. PhishNameLocalRef element . . . . . . . . . . . . . . . . 11
4.5. FraudedBrandName element . . . . . . . . . . . . . . . . . 11
4.6. LureSource element . . . . . . . . . . . . . . . . . . . . 11
4.7. OriginatingSensor Element . . . . . . . . . . . . . . . . 19
4.8. The DCSite element . . . . . . . . . . . . . . . . . . . . 21
4.9. TakeDownInfo element . . . . . . . . . . . . . . . . . . . 23
4.10. ArchivedData element . . . . . . . . . . . . . . . . . . . 24
4.11. RelatedData element . . . . . . . . . . . . . . . . . . . 25
4.12. CorrelationData element . . . . . . . . . . . . . . . . . 25
4.13. PRComments element . . . . . . . . . . . . . . . . . . . . 25
4.14. EmailRecord element . . . . . . . . . . . . . . . . . . . 25
5. IODEF Required Elements . . . . . . . . . . . . . . . . . . . 28
5.1. Fraud or Phishing Report . . . . . . . . . . . . . . . . . 28
5.2. Wide-Spread Spam Report . . . . . . . . . . . . . . . . . 28
5.3. Guidance on Usage . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Phishing Extensions XML Schema . . . . . . . . . . . 34
Appendix B. Sample Malware Email Repor . . . . . . . . . . . . . 44
B.1. Received Email . . . . . . . . . . . . . . . . . . . . . . 44
B.2. Generated Report . . . . . . . . . . . . . . . . . . . . . 44
Appendix C. Sample Phish Email Report . . . . . . . . . . . . . . 47
C.1. Received Lure . . . . . . . . . . . . . . . . . . . . . . 47
C.2. Phishing Report . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . . . . 53
Cain & Jevans Expires April 18, 2007 [Page 3]
Internet-Draft IODEF Phishing Extensions October 2006
1. Introduction
Deception-driven 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 on the Internet. The terms
phishing and fraud are used interchangeably in this document to
characterize a 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) that can be used to describe
information about a phishing incident or wide-spread spam incident.
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.
1.1. Why a Common Report Format is Needed
The rise in phishing and fraud activities via e-mail, instant
message, DNS corruption, and malicious code insertion has driven
corporations, Internet Service Providers, consumer agencies, and
financial institutions to begin to collect and correlate phishing
attack information. The collected data allows them to better
coordinate mitigation activities and support in the persuit and
prosecution of the attacker.
By using a common format, it becomes easier for an organization to
engage in this coordination as well as correlation of information
from multiple sources or products into a cohesive view.
The accumulation and correlation of information is also important in
resolving phishing incidents detected externally as the phished
organization may not even be aware of the attack. Third parties
aware of the attack may wish to notify the phished organization or a
central notification service so adequate responses could commence.
The targeted organization's internal monitoring systems may also
detect the attack and wish to take mitigation steps.
While the intended use of this specification is to facilitate data
sharing between parties, the mechanics of this sharing process and
Cain & Jevans Expires April 18, 2007 [Page 4]
Internet-Draft IODEF Phishing Extensions October 2006
its related political challenges are out of scope for this document.
1.2. Relation to the INCH IODEF Data Model
Instead of defining a new report format, this draft defines an
extension to the Incident Object Description Exchange Format Data
Model[IODEF]. The IODEF defines a flexible and extensible format and
supports a granular level of specificity. This phishing extension
reuses subsets of the IODEF data model and, where appropriate,
specifies new data elements. Leveraging an existing specification
allows for more rapid adoption and reuse of existing tools in
organizations. For clarity, and in order to eliminate duplication,
only the additional structures necessary for describing the exchange
of phishing and e-crime activity are provided.
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.
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 emails, instant messages, 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
Cain & Jevans Expires April 18, 2007 [Page 5]
Internet-Draft IODEF Phishing Extensions October 2006
attributes. 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[IODEF].
Cain & Jevans Expires April 18, 2007 [Page 6]
Internet-Draft IODEF Phishing Extensions October 2006
2. The Elements of Phishing/Fraud Activity
+-----------+ +------------------+
| Fraudster |<---<-- | Collection Point |<---O--<----<----+
+----+------+ +------------------+ | |
| | |
| +--|-----+ ^
| | Sensor | Credentials
| +-|------+ |
| +---------------+ | +-------+
\--->--| Attack Source |--Phish-->-----O------> | User/ |
+---------------+ |Victim |
+-------+
Figure 2.1: The Components of Internet Phishing
Internet-based Phishing and Fraud activities are normally comprised
of at least four components:
1. The Phisher, Fraudster, or party perpetrating the fraudulent
activity. Most times this party is not readily identifiable.
2. The Attack Source, the source of the phishing email, virus,
trojan, or other attack is masked in an enticing manner.
3. The User, Victim, or intended target of the fraud/phish.
4. The collection point, where the victim sends their credentials
or personal data if they have been duped by the phisher.
If we take a holistic view of the attack, there are some additional
components:
5. The sensor, the means by which the phish is detected. This
element may be an intrusion detection system, firewall, filter,
email gateway, or human analyst.
6. A forensic or archive site where an investigator has copied or
otherwise retained the data used for the fraud attempt or
credential collection.
Cain & Jevans Expires April 18, 2007 [Page 7]
Internet-Draft IODEF Phishing Extensions October 2006
3. Fraud Activity Reporting via IODEF-Documents
A Fraud Activity Report is an instance of an XML IODEF-Document with
additional extensions and usage guidance as specified in Section 4 of
this document. These additional extensions are implemented through
the PhraudReport Element.
The Appendices contain sample Fraud Activity Reports and the complete
XML Document Type Definition and schema.
The IODEF Incident element [IODEF, Section 3.2] with fraud extensions
is summarized below. It and the rest of the data model presented in
Section 4 is expressed in Unified Modeling Language (UML) syntax.
+--------------------+
| 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 (added)
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 3.1: The IODEF XML Incident Element (modified)
A Fraud Activity Report is composed of one iodef:Incident element
that contains one or more related PhraudReport elements embedded in
iodef:AdditionalData element of iodef:EventData. The PhraudReport
element is added to the IODEF using its defined extension procedure
documented in Section 5 of [IODEF].
One IODEF-Document may contain information on multiple incidents with
information for each incident contained within an iodef:Incident
element [IODEF, Section 3.12].
Cain & Jevans Expires April 18, 2007 [Page 8]
Internet-Draft IODEF Phishing Extensions October 2006
4. PhraudReport Element Definitions
A PhraudReport consists of an extension to the
Incident.EventData.AdditionalData element with a dtype of "xml". The
elements of the PhraudReport will specify information about the six
components of fraud activity identified in Section 2. Additional
forensic information and commentary can be added by the reporter as
necessary to show relation to other events, to show the output of an
investigation, or for archival purposes. A PhraudReport accommodates
the six elements this way:
a. The PhishNameRef and LocalPhishNameRef 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 DCData describes the technical details of the credential
collection point.
d. The Originating Sensor element describes the means of detection.
e. The RelatedData, ArchivedData, and TakeDownInfo fields allow
optional forensics and history data.
A specific phish/fraud activity can be identified using a combination
of the FraudType, FraudParameter, FraudedBrandName, LureSource, and
PhishRefName elements.
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.
Note: Elements that are imported from the base IODEF specification
are prefaced with an "iodef" namespace and are noted with the section
defining that element in [IODEF].
4.1. Version attribute
STRING. The version shall be the value 1.0 to be compliant with this
document.
4.2. FraudType attribute
One ENUM. The FraudType attribute describes the type of fraudlent
activity described in this PhraudReport.
Cain & Jevans Expires April 18, 2007 [Page 9]
Internet-Draft IODEF Phishing Extensions October 2006
1. phishemail. The FraudParameter should be the email subject line
of the phishing email. This type is a standard email phish,
usually sent as spam, and is intended to derive financial loss
to the recipient.
2. recruitemail. The FraudParameter is the email subject line of
the phishing email. This type of email phish does not pose a
potential financial loss to the recipient, but covers other
cases of the phish and fraud lifecycle.
3. malwareemail. The FraudParameter is the email subject line of
the phishing email. This type of email phish does not pose a
potential financial loss to the recipient, but lures the
recipient to an infected site.
4. fraudsite. This identifies a known fraudulent site that does
not necessarily send spam but is used for lures. The
FraudParameter may be used to identify the website.
5. dnsspoof. This choice does not have a related FraudParameter.
This is used for a spoofed DNS (e.g., malware changes localhost
file so visits to www.example.com go to another IP address
chosen by the fraudster).
6. keylogger. This choice does not have a FraudParameter and
specifies a keylogger downloaded with the lure.
7. ole. There is no FraudParameter. This identifies background
Microsoft Object Linking and Embedding (OLE) information that
comes as part of a lure.
8. im. The FraudParameter should be the malicious instant message
(IM) link supplied to the user.
9. cve. This choice identifies CVE-known malware, with the Common
Vulnerability and Exposures project (CVE) number as the
FraudParameter.
10. archive. There is no required FraudParameter for this choice,
although the FraudParameter of the original phish could be
entered. The data archived from the phishing server is placed
in the ArchiveInfo element.
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.
Cain & Jevans Expires April 18, 2007 [Page 10]
Internet-Draft IODEF Phishing Extensions October 2006
12. voip. The lure was received via a voice-over-IP connection
identified by the information in the FraudParameter field.
13. other. This is used to identify not-yet-enumerated fraud types.
14. unknown. This choice may have an associated FraudParameter. It
is used to cover confused cases.
4.2.1. FraudParameter element
One value of iodef:MLStringType [IODEF, Section 2.4]. This is the
lure used to attract victims. It may be an email subject line, VoIP
lure, link in an IM message, the CVE or malware identifier, or a web
URL. Note that some phishers add a number of random characters onto
the end of a phish email subject line for uniqueness; reporters
should delete those characters before insertion into the
FraudParameter field.
4.3. PhishNameRef element
Zero or one value of STRING. The PhishNameRef element is the common
name used to identify this fraud event. It is often the name agreed
upon by involved parties or vendors. Using this name can be a
convenient way to reference the activity collaborating with other
parties, the media, or engaging in public education.
4.4. PhishNameLocalRef element
Zero or one value of STRING. The PhishNameLocalRef element describes
a local name or Unique-IDentifier (UID) that is used by various
parties before a commonly agreed term is adopted. This field allows
a cross-reference from the submitting organization's system to a
central repository.
4.5. FraudedBrandName element
Zero or more values of STRING. This is the identifier of the
recognized brand name or company name used in the phishing activity
(e.g., XYZ Semiconductor Corp).
4.6. LureSource element
One value. REQUIRED. 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 April 18, 2007 [Page 11]
Internet-Draft IODEF Phishing Extensions October 2006
+-------------+
| LureSource |
+-------------+
| |<>--(1..*)--[ System ]
| |<>--(0..*)--[ DomainData ]
| |<>--(0..1)--[ IncludedMalware ]
| |<>--(0..1)--[ FilesDownloaded ]
| |<>--(0..1)--[ RegistryKeysModified ]
+-------------+
Figure 4.2: The LureSource element
4.6.1. System element
One or more values of iodef:System [IODEF, 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, but the spoofed
attribute SHALL be set.
4.6.2. DomainData element
Zero or more. The DomainData element describes the registration,
delegation, and control of a domain used to source the lure. 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 ]
+----------------+
Figure 4.3: The DomainData element
Cain & Jevans Expires April 18, 2007 [Page 12]
Internet-Draft IODEF Phishing Extensions October 2006
4.6.3. Name
One value of iodef:MLStringType [IODEF, Section 2.4]. The Name
element describes a domain name.
4.6.4. DateDomainWasChecked
Zero or One value of DATETIME. The DateDomainWasChecked element
describes the timestamp of when this domain data was checked and
entered into this report.
4.6.5. RegistrationDate
Zero or one value of DATETIME. The RegistrationData element
describes the date of registration for a domain.
4.6.6. ExpirationDate
Zero or one value of DATETIME. The ExpirationDate element describes
the date the domain will expire.
4.6.7. Nameservers
Zero or less than 16. These fields hold nameservers identified for
this domain. The element is artificially limited to 16 nameserver
entries. Each entry is a sequence of DNSNameType and iodef:Address
[IODEF, Section 3.16.2] pairs.
4.6.7.1. DNSNameType
iodef:MLStringType [IODEF, Section 2.4]. This field contains the DNS
name of the domain nameserver.
4.6.7.2. iodef:Address
This field contains the IP address of the domain nameserver.
4.6.8. DomainContacts element
Choice of either a SameDomainContact or an unbounded set of
DomainContact elements. 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.
Cain & Jevans Expires April 18, 2007 [Page 13]
Internet-Draft IODEF Phishing Extensions October 2006
+--------------------+
| DomainContact |
+--------------------+
| |<>----------[ iodef:ContactName ]
| |<>--(0..*)--[ iodef:Description ]
| ENUM Role |<>--(0..*)--[ iodef:RegistryHandle ]
| ENUM Confidence |<>--(0..1)--[ iodef:PostalAdress ]
| ENUM Restriction |<>--(0..*)--[ iodef:Email ]
| |<>--(0..*)--[ iodef:Telephone ]
| |<>--(0..1)--[ iodef:Fax ]
| |<>--(0..1)--[ iodef:Timezone ]
+--------------------+
Figure 4.4: The DomainContact element
4.6.8.1. SameDomainContact
One DNSNAME. The SameDomainContact element is populated with a
domain name if the contact information for this domain is identical
to that name in this or another report.
4.6.8.2. DomainContact Element
This element reuses the iodef:Contact elements [IODEF, Section 3.7]
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 equivalent to iodef:Contact values, listed
below, as defined in IODEF, Section 3.7 unless otherwise noted:
1. iodef:ContactName.
2. iodef:Description.
3. iodef:RegistryHandle [IODEF, Section 3.7.1].
4. iodef:PostalAddress.
5. iodef:Email.
6. iodef:Telephone.
7. iodef:Fax.
8. iodef:Timezone.
Each Contact has three attributes to capture the sensitivity,
Cain & Jevans Expires April 18, 2007 [Page 14]
Internet-Draft IODEF Phishing Extensions October 2006
confidence, and role for which the contact is listed.
4.6.8.2.1. Role attribute
ENUM. The role values are imported from [CRISP], with some
additions. The role attribute is one of the following values:
1. registrant. This identified Contact is the domain registrant.
2. registrar. This contact identifies the registrar of this
domain.
3. billing. This entry is the billing or financial contact.
4. technical. This contact deals with technical issues.
5. administrative. This contact handles administrative matters for
this domain.
6. legal. This entry deals with legal issues for this domain.
7. zone. This entry controls the DNS zone information.
8. abuse. This entry accepts abuse issues.
9. security. This entry accepts security issues.
10. domainOwner. This lists the owner of the domain.
11. ipAddressOwner. This entry identifes the assignee of the IP
address space.
12. hostingProvider. This contact is the hosting rovider of this
domain.
13. other. This entry does not meet an enumerated value.
4.6.8.2.2. Confidence attribute
ENUM. The Confidence attribute describes a qualitative assessment of
the veracity of the contact information. There are five possible
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.
Cain & Jevans Expires April 18, 2007 [Page 15]
Internet-Draft IODEF Phishing Extensions October 2006
2. looks-fraudulent. The contact information has suspicious
information included.
3. known-real. The contact information has been previously
investigated or determined to be correct.
4. looks-real. The contact information does not arouse suspicion
but has not been previously validated.
5. unknown. The reporter cannot make a value judgment on the
contact data.
4.6.8.2.3. Restriction attribute
Zero or one iodef:restriction attribute [IODEF, as part of Section
3.2]. The restriction attribute is used to label the sensitivity of
included information.
4.6.9. SystemStatus attribute
ENUM. The SystemStatus attribute assesses a domain's involvement in
this event.
1. spoofed. This domain or system did not participate in this
event, but its address space or DNS name was forged.
2. fraudulent. The system is fraudulently operated.
3. innocent-hacked. The system was compromised and used in this
event to source the lure.
4. innocent-hijacked. The IP Address or domain name was hijacked
and used in this event to source of the lure.
5. unknown. No conclusions are inferred from this event.
4.6.10. DomainStatus attribute
ENUM. The DomainStatus attribute describes the registry status of a
domain at the time of the report. The below enumerated list is taken
verbose from the 'domainStatusType' of the Extensible Provisioning
Protocol[RFC3733] and "Domain Registry Version 2 for the Internet
Registry Information Service" internet-draft [CRISP].
1. reservedDelegation - permanently inactive
2. assignedAndActive - normal state
Cain & Jevans Expires April 18, 2007 [Page 16]
Internet-Draft IODEF Phishing Extensions October 2006
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.6.11. IncludedMalware
Zero or One Value. The IncludedMalware element allows for the
identification and optional inclusion of the actual malware that was
part of the lure. The goal of this element is not to detail the
characteristics of the malware but rather to allow for a convenient
element to link malware to a phishing campaign.
+------------------+
| IncludedMalware |
+------------------+
| |<>--(1..*)--[ Name ]
| |<>--(0..1)--[ Hashvalue ]
| |<>--(0..1)--[ Data ]
+------------------+
+-----------------+
| Hashvalue |
+-----------------+
| ENUM Algorithm |
| |
| STRING |
+-----------------+
+---------------------+
| Data |
+---------------------+
| STRING XORPattern |<>--(0..1)-+-[ StringData ]
| | |
| | +-[ BinaryData ]
+---------------------+
Figure 4.5: The Included Malware element
Cain & Jevans Expires April 18, 2007 [Page 17]
Internet-Draft IODEF Phishing Extensions October 2006
4.6.11.1. Name
One or more value of iodef:MLStringType. This optional field is used
to identify the lure malware.
4.6.11.2. Hashvalue
Zero or one value of STRING. This optional field is used to hold the
value of a hash computed over the malware executable.
4.6.11.2.1. Algorithm attribute
REQUIRED ENUM. This field from the following list identifies the
algorithm used to create this hashvalue.
SHA1. Hashvalue as defined in[SHA].
4.6.11.3. Data
Zero or one value. Choice of two elements, below. The optional Data
element is used to describe the lure malware.
4.6.11.3.1. StringData
The lure malware is encoded as a String value.
4.6.11.3.2. BinaryData
The lure malware is encoded as a hexBinary, as defined by the XML
standard, encoded value
4.6.11.3.3. XORPattern attribute
STRING. The Data Element includes an optional 16 hexadecimal
character XORPattern attribute to support disabling the included
malware to bypass anti-virus filters. The default value is
0x55AA55AA55AA55BB which would be XOR-ed with the malware datastring
to recover the actual malware.
4.6.12. FilesDownloaded
Zero or One value of STRING. The FileDownloaded element is a comma-
separated list where each entry is the name of a file downloaded by
this lure. Although this element could be implemented as a sequence
of individual XML entries, the extra XML overhead was perceived to
not add any value, so the files are listed in one element.
Cain & Jevans Expires April 18, 2007 [Page 18]
Internet-Draft IODEF Phishing Extensions October 2006
4.6.13. RegistryKeysModified
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)--[ Key ]
+-----------------------+
+--------------+
| Key |
+--------------+
| STRING |
| |
| STRING Value |
+--------------+
Figure 4.6: The RegistryKeysModified element
4.6.13.1. Key element
One STRING, representing the WINDOWS Operating System Registry Key
Name.
4.6.13.2. Value attribute
One STRING, representing the value of the associated Key
4.7. 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 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 Originating Sensor Elements are allowed to support detection
at mutiple locations.
Cain & Jevans Expires April 18, 2007 [Page 19]
Internet-Draft IODEF Phishing Extensions October 2006
+---------------------+
| OriginatingSensor |
+---------------------+
| ENUM OrigSensorType |<>------------[ DateFirstSeen ]
| |<>---(1..*)---[ iodef:System ]
+---------------------+
Figure 4.7: The OriginatingSensor element
The OriginatingSensor requires a type value and identification of the
entity that detected this fraudulent event.
4.7.1. OrigSensorType attribute
ENUM. REQUIRED. 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
detcted this event.
3. MailGateway. The event was detected via a mail gateway or
filter
4. Browser, or browser-type element. Th event was detected at
the user web interface.
5. ISP-resident or network sensor. The event was detected by an
automated system in the network.
6. Human or manual analysis. A non-automated system detected
this event.
7. Honeypot or other decoy device. The event was detected by
receipt at a decoy device.
8. Other. The detection was performed via a non-listed method.
4.7.2. DateFirstSeen element
REQUIRED. DATETIME. This is the date and time that this sensor
first saw this phishing activity.
Cain & Jevans Expires April 18, 2007 [Page 20]
Internet-Draft IODEF Phishing Extensions October 2006
4.7.3. iodef:System element
iodef:System [IODEF, Section 3.15]. This is the IPVersion,
IPAddress, and optionally, port number of the entity that
generated this report.
4.8. The DCSite element
Zero or more DCSiteData elements. The DCSitedata captures the type,
identifier, collection location, and other pertinent information
about the credential gathering process, or data collection site, used
in the phishing incident. The data collection site is identified by
three elements: the type of collector activity, the type of collector
site, and the network location. Further 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 ]
| |<>--(0..1)---[ DomainData ]
| |<>--(0..1)---[ iodef:Assessment ]
+------------------+
Figure 4.8: The DCSite element
4.8.1. DCType attribute
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 DCSiteData element
identifies the data collection site.
Cain & Jevans Expires April 18, 2007 [Page 21]
Internet-Draft IODEF Phishing Extensions October 2006
1. web. The user is redirected to a website to collect the data.
2. email Form. 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.
5. unspecified.
4.8.2. DCSiteData element
The DCSiteData element contains the IPAddress, URL, or other
identifier of the data collection site as selected by the DCType
Parameter. Each DCSiteData element also includes an optional iodef:
Assessment element as a multiple-site data collector may have
different confidence or impact values.
The DCSiteData element is a choice of:
1. SiteURL. anyURI. This choice supports URIs.
2. EmailSite. STRING. This choice captures either the email
address of the data collection site.
3. iodef:System element [IODEF, Section 3.15]. This choice is
filled it to capture the IP Address of a site.
4. Unknown. STRING. The unknown entry is used for exception to the
preceding choices.
4.8.2.1. DomainData element
Zero or One value of DomainData. This element allows for the
identification of data associated with the data collection site.
4.8.2.2. iodef:Assessment element
Zero or One value of iodef:Assessment [IODEF, Section 3.10]. This
element is used to designate different confidence levels of multiple-
site data collectors.
4.8.2.3. DCSiteType attribute
ENUM. The DCSiteType attribute tags the network address and other
information in the DataCollectionSiteData element.
Cain & Jevans Expires April 18, 2007 [Page 22]
Internet-Draft IODEF Phishing Extensions October 2006
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 [IODEF, Section 3.15]. 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.9. TakeDownInfo element
This element identifies the agent or agency 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 ]
+-------------------+
Figure 4.9: The TakeDownInfo element
4.9.1. TakeDownDate
Zero or one DATETIME. This is the date and time that takedown of
the collector site occurred.
4.9.2. TakeDownAgency
Zero or more STRING. This is a free form string identifying the
agency that performed the takedown
Cain & Jevans Expires April 18, 2007 [Page 23]
Internet-Draft IODEF Phishing Extensions October 2006
4.9.3. TakeDownComments
Zero or more STRING. A free form field to add any additional
details of this takedown effort.
4.10. ArchivedData element
Zero or more values of the ArchivedData element are allowed.
+-------------------+
| ArchivedData |
+-------------------+
| ENUM type |<>---(0..1)--[ ArchivedDataURL ]
| |<>---(0..1)--[ ArchivedDataComments ]
+-------------------+
Figure 4.10: The ArchivedData element
The ArchivedData element is populated with a pointer to the contents
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.10.1. type attribute
This parameter specifies the type of site included in the archive.
1. collectionsite. The archived data contains a data collection
site.
2. basecamp. The archived data contains a development site.
3. sendersite. The archive data contains data from the lure
originating site.
4. unspecified. The archive data containd data as described in the
ArchivedDataComments field.
4.10.2. ArchivedDataURL
Zero or one value of URL. As the archive of an entire site can
be quite large, the ArchivedURL element points to an Internet-
based server where the actual gzipped content of the site archive
can be retrieved. Note that this element just points out where
the archive is and does not include the entire archive in the
Cain & Jevans Expires April 18, 2007 [Page 24]
Internet-Draft IODEF Phishing Extensions October 2006
report. This is the URL where the gzipped archive file is
located.
4.10.3. ArchivedDataComments
Zero or one value of STRING. This field is a free form area for
comments on the archive and/or URL.
4.11. RelatedData element
Zero or more value of anyURI. This element allows the listing of
other web or net sites that are related to this incident (e.g.,
victim site, etc.).
4.12. CorrelationData element
Zero or more value of STRING. Any information that correlates this
incident to other incidents can be entered here.
4.13. PRComments element
Zero or one value of STRING. This field allows for any comments
specific to this PhraudReport that does not fit in any other field.
4.14. EmailRecord element
Extensions are also made to the iodef:Incident.EventData element
[IODEF, Section 3.12] to include the actual email message received in
phishing lure or widespread spam emails. The ability to report spam
is included within a PhraudReport to support exchanging information
about large-scale spam activities related to phishing, not
necessarily a single spam message to a user. As such the spam
reporting mechanism was not designed to minimize overhead and
processing, but to support other widely-used spam reporting formats
such as the MAAWG's Abuse Reporting Format [ARF].
Reporting of the actual mail message is supported by choosing one of
three methods. First, an ARF message may be included. Second, the
message may be included as one large string. Third, the header and
body components may be dissected and included as a series of strings.
Cain & Jevans Expires April 18, 2007 [Page 25]
Internet-Draft IODEF Phishing Extensions October 2006
+--------------------+
| EmailRecord |
+--------------------+
| |<>--------------[ EmailCount ]
| |<>--(0..1)--+---[ Email ]
| | +---[ Message ]
| | +---[ ARFText ]
| |<>--(0..1)------[ EmailComments ]
+--------------------+
+---------------+
| Email |
+---------------+
| |<>---+----------[ EmailHeader ]
| |<>--(0..1)------[ EmailBody ]
+---------------+
+-------------+
| EmailHeader |
+-------------+
| |<>--(1..*)--[ Header ]
+-------------+
Figure 4.11: The EmailRecord element
4.14.1. EmailCount
INTEGER. REQUIRED. This field enumerates the number of email
messages identified in this record detected by the reporter.
4.14.2. Email Message Inclusion
The actual wide-spread spam message may be included in a report
via one of three encodings: an ARF message, one big text blob, or
a separate header and body element.
4.14.2.1. ARFText
Zero or one value of STRING. The Messaging Anti-Abuse Working
Group (MAAWG) defined a format for sending abuse and list control
traffic to other parties. Since many of these reports will get
integrated into incident processes, the raw Abuse Reporting
Format [ARF] may be inserted into this element.
The ARF should be encoded as a character string.
Cain & Jevans Expires April 18, 2007 [Page 26]
Internet-Draft IODEF Phishing Extensions October 2006
4.14.2.2. Email element
4.14.2.2.1. EmailHeader Element
Sequence of Header. The headers of the phish email are included
in this element as a sequence of one-line text strings. There
SHALL be one EmailHeader element per EmailRecord.
4.14.2.2.1.1. Header
iodef:MLStringType. The header element contains a sequence of
email header lines, one line per header element.
4.14.2.2.2. EmailBody Element
Zero or one value of iodef:MLStringType. This element contains
the body of the phish email. If present, there should be at most
one EmailBody element per EmailRecord
4.14.2.3. Message
iodef:MLStringType. The entire mail message can be inserted as
one large string.
4.14.3. EmailComments Element
Zero or one value of STRING. This field contains comments or
relevant data not placed elsewhere about the phishing or spam
email.
Cain & Jevans Expires April 18, 2007 [Page 27]
Internet-Draft IODEF Phishing Extensions October 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 and the PhraudReport extensions. The following table
identifies attributes required to be present in a compliant
PhraudReport to report phishing or fraud or to report widespread
spam. The required attributes are a combination of those required by
the base IODEF element and those required by this document.
Attributes identified as required SHALL be populated in conforming
phishing activity reports.
Note that the major difference between a widespread-spam report and a
phishing/fraud report is that a spam report does not require the
FraudParameter element and includes an EMailRecord element.
The following table is a visual description of the IODEF-Document
required fields.
5.1. Fraud or Phishing Report
A compliant IODEF PhraudReport is required to contain the following
fields:
Incident
@purpose
IncidentID
ReportTime
Assessment -> Confidence
Contact -> Role
Contact -> Type
Contact -> Name
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:
Cain & Jevans Expires April 18, 2007 [Page 28]
Internet-Draft IODEF Phishing Extensions October 2006
Incident
@purpose
IncidentID
ReportTime
Assessment -> Confidence
Contact -> Role
Contact -> Type
Contact -> Name
EventData
DetectTime
AdditionalData
PhraudReport
FraudType == spamreport
LureSource
OriginatingSensor
EmailRecord
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 April 18, 2007 [Page 29]
Internet-Draft IODEF Phishing Extensions October 2006
6. Security Considerations
This document specifies a format for encoding a particular class of
security incidents appropriate for exchange across organizations. As
merely a data representation, it does not directly introduce security
issues. However, it is guaranteed that parties exchanging instances
of this specification will have certain concerns. For this reason,
the underlying message format and transport protocol used must ensure
the appropriate degree of confidentiality, integrity, and
authenticity.
The critical security concern is that phishing activity reports may
be falsified or the PhraudReport 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. We expect that each
receiving entity will determine the need, and mechanism, for this
signature independently.
Cain & Jevans Expires April 18, 2007 [Page 30]
Internet-Draft IODEF Phishing Extensions October 2006
7. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]
Registration request for the IODEF phishing namespace:
URI: urn:ietf:params:xml:ns:iodef-phish-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None.
Registration request for the IODEF phishing extension XML schema:
URI: urn:ietf:params:xml:schema:iodef-phish-1.0
Registrant Contact: See the "Author's Address" section of
this document.
XML: See the "Phishing Extensions Schema Definition" in the
<Appendix A> section of this document.
Cain & Jevans Expires April 18, 2007 [Page 31]
Internet-Draft IODEF Phishing Extensions October 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 April 18, 2007 [Page 32]
Internet-Draft IODEF Phishing Extensions October 2006
9. References
9.1. Normative References
[IODEF] Meijer, J., Danyliw, and Demchenko, "The Incident Object
Description Exchange Format Data Model and XML
Implementation", September 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealing, M., "The IETF XML Registry", RFC 3688,
January 2004.
[SHA] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard",
FIPS 180-1, May 1994.
9.2. Informative References
[ARF] The Messaging Anti-Abuse Working Group (MAAWG), "Abuse
Reporting Format", May 2005.
[CRISP] Newton, L. and A. Neves, "Domain Registry Version 2 for
the Internet Registry Information Service", RFC 3982,
January 2005.
[IDMEF] Curry, D. and H. Debar, "The Intrusion Detection Message
Exchange Format", July 2004.
[RFC3733] Hollenbeck, "Extensible Provisioning Protocol (EPP)
Contact Mapping"", RFC 3733, March 2004.
Cain & Jevans Expires April 18, 2007 [Page 33]
Internet-Draft IODEF Phishing Extensions October 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="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns:ns="http://www.w3.org/1999/xhtml"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="draft-ietf-inch-iodef-100.xsd"/>
<!--
This Schema complies with draft-ietf-inch-phishingextns-04.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"/>
Cain & Jevans Expires April 18, 2007 [Page 34]
Internet-Draft IODEF Phishing Extensions October 2006
<xs:element maxOccurs="unbounded" minOccurs="0"
name="FraudedBrandName" type="xs:string"/>
<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:choice>
<xs:element name="StringData"
type="xs:string"/>
<xs:element name="BinaryData"
type="xs:hexBinary"/>
</xs:choice>
<xs:attribute default="55AA55AA55AA55BB"
name="XORPattern" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
Cain & Jevans Expires April 18, 2007 [Page 35]
Internet-Draft IODEF Phishing Extensions October 2006
</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>
<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 maxOccurs="unbounded" 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.4" name="Version" use="optional"/>
Cain & Jevans Expires April 18, 2007 [Page 36]
Internet-Draft IODEF Phishing Extensions October 2006
<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"/>
<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. -->
Cain & Jevans Expires April 18, 2007 [Page 37]
Internet-Draft IODEF Phishing Extensions October 2006
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
name="Header" type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="EmailBody"
type="iodef:MLStringType"/>
</xs:sequence>
<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.element minOccurs="0"
maxOccurs="1" ref="iodef:Assessment">
</xs:sequence>
<xs:attribute name="DCSiteType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
Cain & Jevans Expires April 18, 2007 [Page 38]
Internet-Draft IODEF Phishing Extensions October 2006
<xs:enumeration value="email"/>
<xs:enumeration value="ipaddress"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</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"
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>
<xs:element name="Server"
type="iodef:MLStringType"/>
<xs:element ref="iodef:Address"/>
Cain & Jevans Expires April 18, 2007 [Page 39]
Internet-Draft IODEF Phishing Extensions October 2006
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice id="DomainContacts">
<xs:element name="SameDomainContact"
type="iodef:MLStringType"/>
<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="reservedDelegation - permanently inactive"/>
<xs:enumeration
value="assignedAndActive - normal state"/>
<xs:enumeration
value="assignedAndInactive - registration assigned
but delegation inactive"/>
<xs:enumeration
value="assignedAndOnHold - dispute"/>
<xs:enumeration
value="revoked - database purge pending"/>
<xs:enumeration
value="transferPending - change of authority pending"/>
<xs:enumeration
value="registryLock - on hold by registry"/>
<xs:enumeration
value="registrarLock - on hold by registrar"/>
</xs:restriction>
</xs:simpleType>
Cain & Jevans Expires April 18, 2007 [Page 40]
Internet-Draft IODEF Phishing Extensions October 2006
</xs:attribute>
</xs:complexType>
</xs:element>
<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>
<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:enumeration value="domainOwner"/>
<xs:enumeration value="ipAddressOwner"/>
<xs:enumeration value="hostingProvider"/>
</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"/>
Cain & Jevans Expires April 18, 2007 [Page 41]
Internet-Draft IODEF Phishing Extensions October 2006
<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 maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
</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">
Cain & Jevans Expires April 18, 2007 [Page 42]
Internet-Draft IODEF Phishing Extensions October 2006
<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>
<!--
===================================================================
=== 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="type" 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>
</xs:schema>
Cain & Jevans Expires April 18, 2007 [Page 43]
Internet-Draft IODEF Phishing Extensions October 2006
Appendix B. Sample Malware Email Repor
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 lang="en-US"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish2="draft-ietf-inch-phishingextns-04.xsd"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns:ns4="draft-ietf-inch-phishingextns-033.xsd"
xmlns:ns2="http://www.w3.org/1999/xhtml"
xmlns:ns="draft-ietf-inch-iodef-100.xsd"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<Incident purpose="other">
<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.
Cain & Jevans Expires April 18, 2007 [Page 44]
Internet-Draft IODEF Phishing Extensions October 2006
</Description>
<Assessment>
<Impact type="social-engineering"></Impact>
<Confidence rating="high"></Confidence>
</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">
<ns2:PhraudReport FraudType="phishemail">
<ns2:FraudParameter>
Subject: You have successfully updated your password
</ns2:FraudParameter>
<ns2:FraudedBrandName>Cooper-Cain
</ns2:FraudedBrandName>
<ns2:LureSource>
<System category="source">
<Node>
<Address>216.231.63.162</Address>
</Node>
</System>
<ns2:IncludedMalware>
<ns2:Name>W32.Mytob.EA@mm</ns2:Name>
</ns2:IncludedMalware>
</ns2:LureSource>
<ns2:OriginatingSensor OriginatingSensorType="human">
<ns2:FirstSeen>2005-06-10T15:52:11-05:00</ns2:FirstSeen>
<System>
<Node>
<Address>10.0.0.4</Address>
</Node>
</System>
</ns2:OriginatingSensor>
<ns2:EmailRecord>
<ns2:EmailCount>1</ns2:EmailCount>
<ns2:Message>
"Return-path: <support@coopercain.com>"
Envelope-to: pcain@coopercain.com Delivery-date: Fri, 10 Jun 2005
15:52:11-0400 Received: from dsl231-063-162.sea1.dsl.speakeasy.net
([216.231.63.162] helo=coopercain.com) by mail06.coopercain.com
with esmtp (Exim) id 1DgpXy-0002Ua-IR for pcain@coopercain.com;
Fri, 10 Jun 2005 15:52:10-0400 From: support@coopercain.com To:
pcain@coopercain.com Subject: You have successfully updated yourn
password Date: Fri, 10 Jun 2005 12:52:00 -0700 MIME-Version: 1.0
Content-Type: multipart/mixed;
Cain & Jevans Expires April 18, 2007 [Page 45]
Internet-Draft IODEF Phishing Extensions October 2006
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
</ns2:Message>
</ns2:EmailRecord>
</ns2:PhraudReport></AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
Cain & Jevans Expires April 18, 2007 [Page 46]
Internet-Draft IODEF Phishing Extensions October 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 April 18, 2007 [Page 47]
Internet-Draft IODEF Phishing Extensions October 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 lang="en-US"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns:ns2="http://www.w3.org/1999/xhtml"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
Cain & Jevans Expires April 18, 2007 [Page 48]
Internet-Draft IODEF Phishing Extensions October 2006
<Incident purpose="mitigation" restriction="private">
<IncidentID name="coopercain.com">CC200600000002</IncidentID>
<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>
<Impact severity="high" type="social-engineering"></Impact>
<Confidence rating="numeric">85</Confidence>
</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 & 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: <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.yourhostingaccou
nt.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.yourhostingacc
Cain & Jevans Expires April 18, 2007 [Page 49]
Internet-Draft IODEF Phishing Extensions October 2006
ount.com with esmtp (Exim) id 1Fq5Bj-0006dv-6b for pcain@coopercai
n.com; Tue, 13 Jun 2006 05:37:21 -0400
Received: from User ([66.59.189.157]) by TSI with Microsoft SMTPSV
C(5.0.2195.6713); Tue, 13 Jun 2006 02:24:30 -0400 Reply-To: <no
spa@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=[07
2A66A0: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> <htt
p://www.paypal.com/images/pixel.gif> <http://www.paypal.com/im
ages/pixel.gif> Account Update Request Dear PayPal. member:, You
are receiving this notification because PayPal is required by law to
notify you, that you urgently need to update your online account st
atement, due to high risks of fraud intentions.
The updating of your PayPal account can be done at any time by click
ing 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 Histo
ry sub tab of your Account Overview page to see your most recent sta
tement. If you need help with your password, click the Help link whi
ch is at the upper right hand side of the PayPal website. To report
errors in your statement or make inquiries, click the Contact Us lin
k 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.c
om/images/dot_row_long.gif></phish:Message>
</phish:EmailRecord>
<phish:DCSite DCType="web">
<phish:DCSiteData DCSiteType="web">
<phish:SiteURL>
http://217.136.251.41:8080/.cgi-bin/.webscr/.secure-
login/%20%20/.paypal.com/index.htm
</phish:SiteURL>
<phish:DomainData
DomainStatus="assignedAndActive - normal state"
SystemStatus="unknown">
<phish:Name>adsl.skynet.be</phish:Name>
Cain & Jevans Expires April 18, 2007 [Page 50]
Internet-Draft IODEF Phishing Extensions October 2006
<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 April 18, 2007 [Page 51]
Internet-Draft IODEF Phishing Extensions October 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 April 18, 2007 [Page 52]
Internet-Draft IODEF Phishing Extensions October 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 April 18, 2007 [Page 53]