Internet DRAFT - draft-ietf-inch-phishingextns
draft-ietf-inch-phishingextns
INCH P. Cain
Internet-Draft The Cooper-Cain Group, Inc.
Expires: December 16, 2006 D. Jevans
The Anti-Phishing Working Group
June 14, 2006
Extensions to the IODEF-Document Class for Phishing, Fraud, and Other
Crimeware
draft-ietf-inch-phishingextns-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document extends the INCH WG's IODEF XML incident reporting
format for reporting phishing, fraud, other types of electronic
crime, and widespread spam incidents. Although the term "phishing
attack" is used, the data format extensions are flexible enough to
support information gleaned from activities throughout the entire
electronic fraud life cycle and extensible enough to be used for
Cain & Jevans Expires December 16, 2006 [Page 1]
Internet-Draft IODEF Phishing Extensions June 2006
other types of electronic crime incidents, along with simple spam.
The extensions support very simple reporting as well as optional
fields for detailed forensic reports, and support single phish/fraud
incidents as well as consolidated reports of multiple phish
incidents.
Sections 1 and 2 of this document introduce the high-level report
format. Sections 3 and 4 describe the data elements of the fraud
extensions. This document includes an XML schema for the extensions
and a few example fraud reports.
RFC 2129 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described inRFC 2119 [RFC2119].
Cain & Jevans Expires December 16, 2006 [Page 2]
Internet-Draft IODEF Phishing Extensions June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Why a Common Report Format is Needed . . . . . . . . . . . 4
1.2. Relation to the INCH IODEF Data Model . . . . . . . . . . 5
2. The Elements of Phishing/Fraud Activity . . . . . . . . . . . 7
3. Fraud Actvitiy Reporting via an IODEF-Document Incident . . . 8
4. PhraudReport Element Definitions . . . . . . . . . . . . . . . 10
4.1. Version parameter . . . . . . . . . . . . . . . . . . . . 11
4.2. Identifying A Fraud campaign . . . . . . . . . . . . . . . 11
4.3. FraudedBrandName Element . . . . . . . . . . . . . . . . . 13
4.4. LureSource Element . . . . . . . . . . . . . . . . . . . . 13
4.5. OriginatingSensor Element . . . . . . . . . . . . . . . . 20
4.6. The Data Collection Site Element (DCSite) . . . . . . . . 22
4.7. TakeDownInfo Element . . . . . . . . . . . . . . . . . . . 23
4.8. ArchivedData Element . . . . . . . . . . . . . . . . . . . 24
4.9. RelatedData Element . . . . . . . . . . . . . . . . . . . 25
4.10. CorrelationData Element . . . . . . . . . . . . . . . . . 25
4.11. PRComments Element . . . . . . . . . . . . . . . . . . . . 25
4.12. EmailRecord Element . . . . . . . . . . . . . . . . . . . 25
5. IODEF Required Elements . . . . . . . . . . . . . . . . . . . 28
5.1. Fraud or Phishing Report . . . . . . . . . . . . . . . . . 28
5.2. Wide-Spread Spam Report . . . . . . . . . . . . . . . . . 29
5.3. Guidance on Usage . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Phishing Extensions XML Schema . . . . . . . . . . . 35
Appendix B. Sample Malware Email Report . . . . . . . . . . . . . 47
B.1. Received Email . . . . . . . . . . . . . . . . . . . . . . 47
B.2. Generated Report . . . . . . . . . . . . . . . . . . . . . 47
B.3. Notes and Commentary . . . . . . . . . . . . . . . . . . . 49
Appendix C. Sample Phish Email Report . . . . . . . . . . . . . . 50
C.1. Received Lure . . . . . . . . . . . . . . . . . . . . . . 50
C.2. Phishing Report . . . . . . . . . . . . . . . . . . . . . 51
C.3. Notes and Commentary . . . . . . . . . . . . . . . . . . . 55
Appendix D. Sample Spam Report . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . . . . . 58
Cain & Jevans Expires December 16, 2006 [Page 3]
Internet-Draft IODEF Phishing Extensions June 2006
1. Introduction
Deception activities on the Internet, such as receiving an email
purportedly from a bank requesting you to confirm your account
information, are an expanding attack type in the Internet. For this
document, the two terms phishing and fraud are used interchangeably
and characterize as broadly-launched social engineering attacks in
which an electronic identity is misrepresented in an attempt to trick
individuals into revealing their personal credentials ( e.g.,
passwords, account numbers, personal information, ATM PINs). A
successful phishing attack on an individual allows the phisher (i.e.,
attacker) to exploit the individual's credentials for financial or
other gain. Early phishing attacks were directed at individuals via
email as a ruse from a bank security department, requesting the
user's ATM number and PIN. Once phished, the bank account could be
used by the phisher to perpetrate additional fraud, money laundering,
or plain emptying of the account. As individuals became more aware
of phishing tactics, the phishers have evolved into using more
complex and stealthier technologies targeting institutions such as
ISPs and corporations other than banks. These attacks have now
morphed to use the lure to deliver all types of malware and other
crimeware onto users' computers. Other miscreants are also using
these same techniques for other types of Internet attacks.
1.1. Why a Common Report Format is Needed
The rise in phishing and fraud activities via e-mail, instant
message, DNS corruption, and malicious code insertion has driven
corporations, Internet Service Providers, consumer agencies, and
financial institutions to begin to collect and correlate phishing
attack information. The data collected allows them to better plan
out mitigation activities and to initiate or assist in prosecution of
the attacker. Early on it became obvious that a common format for
the data reported or exchanged between these parties was necessary.
The IETF INCH XML format was selected for this use as it was already
becoming a standard way of sharing this type of information.
Although originally designed for network-layer incident sharing
(e.g., DoS attacks, compromised computers) the INCH format can be
extended quite easily to support other incident profiles, as we show
in this document.
The use of a common format will help organizations integrate multiple
product outputs into a cohesive single attack view. It will also
allow for the introduction of advanced services such as wholly
automatic local notifications and usable data mining.
The accumulation and correlation of information is very important
when dealing with security incidents. In phishing attacks
Cain & Jevans Expires December 16, 2006 [Page 4]
Internet-Draft IODEF Phishing Extensions June 2006
specifically, the attack source may be misrepresented or forged. The
targeted organization may not even be aware of the ongoing attack.
Third parties aware of the attack may wish to notify the targeted
organization or a central notification service. The targeted
organization's internal monitoring systems may also detect the attack
and wish to take mitigation steps. Without this document, there is
no recognized standard format to express the detection of a phishing
attack or to exchange detailed information about it. For an
organization that employs multi anti-phishing technologies,
correlating data from multiple vendors or products is close to
impossible as the data is reported in multiple, mostly incompatible,
formats.
This document defines a data format extension to IODEF that is used
to capture relevant information from a phishing attack and shared,
correlated, or to populate a database. Additionally, the use of
products that export information in this format will allow an
organization to correlate and analyze phishing information across
their organization. Although targeted at both the accumulation of
phishing attack information from a single institution and a means of
sharing attack information between cooperating parties, the actual
information sharing process and related political challenges are not
covered in this document.
1.2. Relation to the INCH IODEF Data Model
Instead of defining report format and language from scratch, the
phishing activities information is encoded as XML extensions to the
Incident Object Description Exchange Format Data Model[IODEF]. The
use of this already existent and operational format, based on the
Intrusion Detection Message Exchange Format[IDMEF], allows for
quicker vendor adoption and reuse of existing tools in organizations.
To reduce duplication and to be compatible with forward modifications
to the base IODEF definitions, this document only identifies
additional structures necessary for exchanging phishing and e-crime
information.
The goal of using a common format is to be simple and efficient, and
to support additional data to be included to provide a complete
picture of the event, when necessary. One criticism of the IODEF
format is that it is too cumbersome (i.e., large and complex) to be
used in an efficient manner for something as simple as fraud events.
The IODEF format has very few required elements to allow for
efficiency, but allows extremely verbose elements to be used if
supporting data is available. This flexibility allows the IODEF
formats to be used in a wide range of event reports but only requires
the product developer to support one format standard.
Cain & Jevans Expires December 16, 2006 [Page 5]
Internet-Draft IODEF Phishing Extensions June 2006
1.2.1. The IODEF Extensions for Fraud
In general, an IODEF incident report contains detailed incident-
specific data which populates an EventData Structure. That data is
then incorporated, either singularly or in aggregation, with
additional summary and contact data, into an Incident structure.
A Fraud Activity Report is an instance of an XML IODEF-Document with
added EventData and AdditionalData elements. It contains the
Incident structure and additional fields in the EventData specific to
phishing and fraud (the PhraudReport). Phishing activity may include
multiple email, instant message, or network messages, scattered over
various times, locations, and methodologies. The new EventData
fields are combined into a Fraud Activity Report and include
information about the email header and body, details of the actual
phishing lure, correlation to other attacks, and details of the
removal of the web server or credential collector. As a phishing
attack may generate multiple reports to an incident team, the Fraud
Activity Reports may be combined into one EventData structure.
Multiple EventData structures may be combined into one Incident
Report. One IODEF Incident report may record one or more individual
phishing events and may include multiple EventData elements.
This document defines new elements for the EventData and Record Item
IODEF XML elements and identifies the Fraud Activity Report required
attributes. The Appendices contain sample Fraud Activity Reports and
a complete Schema.
The IODEF Extensions defined in this document comply with section4,
"Extending the IODEF Format" in[IODEF].
As both the IODEF-Document and PhraudReport documents have many
options a companion implementer's guide and report examples document
is being developed to assist implementers with consistency.
Cain & Jevans Expires December 16, 2006 [Page 6]
Internet-Draft IODEF Phishing Extensions June 2006
2. The Elements of Phishing/Fraud Activity
+-----------+ +------------------+
| Fraudster |<---<-- | Collection Point |<---O--<----<----+
+----+------+ +------------------+ | |
^ | |
| +--|-----+ ^
| | Sensor | Credentials
| +-|------+ |
| +---------------+ | +-------+
\--->--| Attack Source |--Phish-->-----O------> | User/ |
+---------------+ |Victim |
+-------+
Internet-based Phishing and Fraud activities are normally comprised
of at least four components.
1. The Phisher, Fraudster, or party perpetrating the fraudulent
activity. Most times this party is not readily identifiable.
2. The Attack Source, where the phishing email, virus, trojan, or
other attack is generated.
3. The User, Victim, or intended target of the fraud/phish.
4. The collection point, where the victim sends their credentials
or personal data if they have been duped by the phisher.
If we take a holistic view of the attack, there are some additional
components:
5. The sensor, which is something that detects the fraud/phish
attempt or success. This element may be an intrusion detection
system, firewall, filter, email gateway, or human.
6. A forensic or archive site where an investigator has copied or
otherwise retained the data used for the fraud attempt or
credential collection.
Cain & Jevans Expires December 16, 2006 [Page 7]
Internet-Draft IODEF Phishing Extensions June 2006
3. Fraud Actvitiy Reporting via an IODEF-Document Incident
A Fraud Activity Report is an instance of an XML IODEF-Document with
added EventData, AdditionalData elements. The added elements compose
a PhraudReport Element. Required information with many optional
items is populated into the PhraudReport structure to form a Fraud
Activity Report. To facilitate usefulness, the report originator
should fill out all mandatory items and as many as necessary optional
Incident element fields, to stay consistent with the IODEF-Document
structure.
This document defines new EventData IODEF XML elements; then
identifies attributes that are required in a compliant Fraud Activity
Report. The Appendices contain sample Fraud Activity Reports and the
complete XML Document Type Definition and schema.
The Incident element with fraud extensions is summarized below. It
provides a standardized representation for commonly exchanged
incident data and associates a CSIRT assigned unique identifier with
the described activity. The data elements in this document are
expressed in Unified Modeling Language (UML) syntax.
+-------------------+
| Incident |
+-------------------+
| ENUM purpose |<>----------[ IncidentID ]
| ENUM restriction |<>--{0..1}--[ AlternativeID ]
| |<>--{0..1}--[ RelatedActivity ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ Expectation ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ EventData ]
| | --> [ AdditionalData ]
| | --> PhraudReport (added)
+------------------+
Figure 1. The IODEF XML Incident Element (modified)
A Fraud Activity Report is composed of one IODEF Incident element,
containing one or more EventData elements that contain one or more
PhraudReport elements. This document defines the PhraudReport
element for the Incident.EventData.AdditionalData element comprising
Cain & Jevans Expires December 16, 2006 [Page 8]
Internet-Draft IODEF Phishing Extensions June 2006
of phishing and fraud-related information that does not map to
existing Incident or EventData attributes. Some additional
attributes are defined to capture electronic mail header and routing
information.
One Incident report may contain information on multiple incidents.
After the report identification information listed in the Incident
element, each individual event is detailed within a single EventData
structure.
Cain & Jevans Expires December 16, 2006 [Page 9]
Internet-Draft IODEF Phishing Extensions June 2006
4. PhraudReport Element Definitions
A PhraudReport consists of an extension to the Incident
AdditionalData Element. The elements of the PhraudReport will
identify and capture information related to the six components of
fraud activity identified earlier. Other forensic information and
commentary can be added by the reporter as necessary to show relation
to other events, the output of an investigation, or for archival
purposes. A PhraudReport accommodates the six elements this way:
Identification fields (PhishNameRef and LocalPhishName Ref) exist
to identify the fraudster or class of fraudster.
The LureSource element contains information about the source of
the attack or phishing lure, including host information and any
included malware. Fields exist to include the entire email, web,
IM, or other-based lure.
There are elements to identify the targeted brand name(s).
The DCData holds a description and technical details on the
credential collection point.
The means of detection is described in the Originating Sensor
element.
AdditonalData, RelatedData, ArchivedData and TakeDownInfo fields
allow optional forensics and history data.
A PhraudReport element is structured as follows.
Cain & Jevans Expires December 16, 2006 [Page 10]
Internet-Draft IODEF Phishing Extensions June 2006
+--------------------------+
| EventData.AdditionalData |
+--------------------------+
| ENUM type (9 = xml) |<>---------[ PhraudReport ]
| STRING meaning (xml) |
+--------------------------+
+-----------------+
| PhraudReport |
+-----------------+
| ENUM Version |<>--(0..1)--[ PhishNameRef ]
| ENUM FraudType |<>--(0..1)--[ PhishNameLocalRef ]
| |<>--(0..1)--[ FraudParameter ]
| |<>--(0..*)--[ FraudedBrandName ]
| |<>--(1..*)--[ LureSource ]
| |<>----------[ OriginatingSensor ]
| |<>--(0..1)--[ EmailRecord ]
| |<>--(0..*)--[ DCSite ]
| |<>--(0..*)--[ TakeDownInfo ]
| |<>--(0..*)--[ ArchivedData ]
| |<>--(0..*)--[ RelatedData ]
| |<>--(0..*)--[ CorrelationData ]
| |<>--(0..1)--[ PRComments ]
+-----------------+
Figure 2. The PhraudReport Extensions to the INCH XML
Incident.AdditionalData Element
The components of a PhraudReport are introduced in functional
grouping as some parameters are related and some elements may not
make sense individually.
4.1. Version parameter
One value of STRING. The version shall be the value 0.3 to be
compliant with this document.
4.2. Identifying A Fraud campaign
At times it may be useful to identify a specific phish or fraud for
future analysis, much like the anti-virus vendors identify certain
viruses. A specific phish/fraud activity can be identified using a
combination of the FraudType, FraudParameter, FraudedBrandName,
LureSource, and PhishRefName elements.
4.2.1. PhishNameRef Element
Zero or one value of STRING. This value is a friendly-name for this
fraud event. It may be agreed upon by vendor collaboration to note a
Cain & Jevans Expires December 16, 2006 [Page 11]
Internet-Draft IODEF Phishing Extensions June 2006
common name for a given phish attack or "campaign". The agreed upon
identifier could be useful in collaboration, support, media and
public education.
4.2.2. PhishNameLocalRef Element
Zero or one value of STRING. Many contributors will have a local
reference name or Unique-IDentifier (UID) that will be used before a
commonly agreed term is adopted in PhishNameRef. This field allows a
cross-reference from the submitting organization's system to the
central repository.
4.2.3. FraudType Parameter
One required value of ENUM from this list. The FraudType attribute
contains a number representing the type of fraud attempted. The
Email element has been separated into multiple numbers to support the
primary types of lure email. The value of the FraudParameter is
dependent on the choice of the FraudType Parameter.
1. PhishEmail, and the FraudParameter is the email subject line
of the phishing email. This type is a standard email phish,
usually sent as spam, and is intended to derive financial loss to
the recipient.
2. RecruitEmail, and the FraudParameter is the email subject line
of the phishing email. This type of email phish does not pose a
potential financial loss to the recipient, but covers other cases
of the phish and fraud lifecycle.
3. MalwareEmail, and the FraudParameter is the email subject line
of the phishing email. This type of email phish does not pose a
potential financial loss to the recipient, but lures the recipient
to an infected site.
4. Fraudsite, with no FraudParameter. This identifies a known
fraudulent site that does not necessarily send spam but is used
for lures.
5. DNSspoof, with no FraudParameter. This is used for a spoofed
DNS (e.g., malware changes localhost file so visits to
www.example.com go to another IP address).
6. Keylogger downloaded with lure, with no FraudParameter.
7. OLE, no FraudParameter. This identifies background Microsoft
Object Linking and Embedding (OLE) information that comes as part
of a lure.
Cain & Jevans Expires December 16, 2006 [Page 12]
Internet-Draft IODEF Phishing Extensions June 2006
8. IM. The FraudParameter should be the malicious instant
message (IM) link supplied to the user.
9. CVE-known malware, with the Common Vulnerability and Exposures
project (CVE) number as the FraudParameter.
10. SiteArchive, with the data archived from the phishing server
placed in the ArchiveInfo element.
11. Spamreport. This type is used when the PhraudReport is
reporting a large-scale spam activity. The FraudParameter should
be the spam email subject line.
12, VoIP. The lure was received via a voice-over-IP connection
identified by the information in the FraudParameter field.
13. Other, to identify as-yet-enumerated fraud types.
14. Unknown.
4.2.3.1. FraudParameter Element
One value of a multilingual STRING. This is the lure used to attract
victims. It may be the email subject line, the VoIP lure, the link
in IM; the CVE or malware identifier, or a web URL. Note that some
phishers add a number of random characters onto the end of a phish
email subject line for uniqueness; reporters should delete those
characters before insertion into the PhishParameter field.
4.3. FraudedBrandName Element
Zero or more values of STRING. This is the identifier of the
recognized brand name or company name used in the phishing activity.
Some schemes, such as those enticing "mules" for money laundering or
related activities, may use a lesser known or fictitious brand [e.g.,
xyz semiconductor company]. Those brand identifiers should also
populate this field.
4.4. LureSource Element
This element describes the source of the phishing or crimeware lure.
Elements are included to allow for entering the IP Addresses,
DNSNames, and Domain Registry information of the source of the lure
and some rudimentary information about the files downloaded and
Windows registry keys modified by the crimeware.
Cain & Jevans Expires December 16, 2006 [Page 13]
Internet-Draft IODEF Phishing Extensions June 2006
+-------------+
| LureSource |
+-------------+
| |<>--(1..*)--[ System ]
| |<>--(0..*)--[ DomainData ]
| |<>--(0..1)--[ IncludedMalware ]
| |<>--(0..1)--[ FilesDownloaded ]
| |<>--(0..1)--[ RegistryKeysModified ]
+-------------+
4.4.1. System Element
One or more values of IODEF:SYSTEM. Many times the phishing, spam,
or fraud lure email is received from a spoofed IP address. If the
real IP Address can be ascertained it should be populated into this
field. A spoofed address may also be entered, but the spoofed
attribute SHALL be set. The field uses the IODEF System element to
capture the Address and to allow for support of IPv6 and port
numbers.
4.4.2. DomainData Element
The DomainData element holds information about the registration,
delegation, and control of the IPAddress used to source the lure.
Many phishers use the DNS system to their advantage moving domain
names and addresses repeatedly to avoid disruption. A DomainData
element can be used to (repeatedly) capture detailed domain data to
detect fraudster patterns and to allow for the quick updating of
network filters. There may be multiple values of this element to
track the Domain data as the lure DNS entry changes. The structure
of a DomainData element is as follows.
+--------------------+
| DomainData |
+--------------------+
| |<>----------[ Name ]
| |<>--(0..1)--[ DateDomainWasChecked ]
| ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ]
| ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ]
| |<>--(0..16)-[ Nameservers ]
| |<>--(0..*)--[ DomainContacts ]
+--------------------+
+----------------+
| DomainContacts |
+----------------+
| |<>--(0..1)--[ SameDomainContact ]
| |<>--(0..1)--[ Contact ]
Cain & Jevans Expires December 16, 2006 [Page 14]
Internet-Draft IODEF Phishing Extensions June 2006
+----------------+
4.4.3. Name
One value of MLStringType. This field should contain the domain
Name.
4.4.4. DateDomainWasChecked
Zero or One value of DATETIME to show when this domain data was
checked and entered into this report.
4.4.5. RegistrationDate
Zero or one value of DATETIME to note when this domain was
registered.
4.4.6. ExpirationDate
Zero or one value of DATETIME to note when this domain registration
will expire.
4.4.7. Nameservers
Zero or multiple sets of DNSNAME and ADDRESS elements. These fields
hold nameservers identified for this domain. The element is
artificially limited to 16 nameserver entries.
4.4.8. DomainContacts
Choice of either a SAMEDOMAINCONTACT or an unbounded set of
DOMAINCONTACT values. The DomainContacts element allows the reporter
to enter contact information supplied by the registrar or returned by
Whois. For efficiency of the reporting party, the domain contact
information may be marked to be the same as another domain already
reported.
+--------------------+
| Contact |
+--------------------+
| |<>----------[ ContactName ]
| |<>--(0..*)--[ Description ]
| ENUM Role |<>--(0..*)--[ RegistryHandle ]
| ENUM Confidence |<>--(0..1)--[ PostalAdress ]
| ENUM Restriction |<>--(0..*)--[ Email ]
| |<>--(0..*)--[ Telephone ]
| |<>--(0..1)--[ Fax ]
| |<>--(0..1)--[ Timezone ]
Cain & Jevans Expires December 16, 2006 [Page 15]
Internet-Draft IODEF Phishing Extensions June 2006
+--------------------+
4.4.8.1. SameDomainContact
One DNSNAME. This field is populated if the contact information for
this domain is identical to another DNSNAME element in this or
another report.
4.4.8.2. DomainContact Element
This element reuses the iodef:Contact elements for its components.
Each component may have zero or more values. If only the role
attribute and the ContactName component are populated, the same
(identical) information is listed for multiple roles. The
permissible elements are:
ContactName.
Description.
RegistryHandle.
PostalAddress.
Email.
Telephone.
Fax.
Timezone.
Each Contact has three attributes to capture the sensitivity,
confidence, and role that the contact is listed for.
4.4.8.2.1. Role Attribute
ENUM. The role values are imported from [CRISP]. They may be valued
as follows.
Registrant.
Registrar.
Billing.
Technical.
Cain & Jevans Expires December 16, 2006 [Page 16]
Internet-Draft IODEF Phishing Extensions June 2006
Administrative.
Legal.
Zone.
Abuse.
Security.
Other.
4.4.8.2.2. Confidence Attribute
One ENUM value. The Confidence attribute allows a reporter to value-
judge the information provided in this report. There are five
possible values as follows.
Known-fraudulent. This contact information has been previously
determined to be fraudulent, either as non-existent physical
information or containing real information not associated with
this domain registration.
Looks-fraudulent. The contact information has suspicious
information included.
Known-real. The contact information has been previously
investigated or determined to be correct.
Looks-real. The contact information does not arise suspicion but
has not been previously validated.
Unknown. The reporter cannot make a value judgment on the
contact data.
4.4.8.2.3. Restriction Attribute
Zero or one value of iodef:RESTRICTION element, to allow sensitive
information to be adequately marked.
4.4.9. SystemStatus Attribute
ENUM. This attribute allows a report to note their estimation of
this domain involved in this event. After investigation, a reporter
may be able to assess the likelihood that this domain contributed
willingly, knowingly, inadvertently, or was not involved in the
reported event.
Cain & Jevans Expires December 16, 2006 [Page 17]
Internet-Draft IODEF Phishing Extensions June 2006
1. Spoofed. This domain or system did not participate but its
address space or DNS name was forged in this event.
2. Fraudulent. The system is fraudulently operated.
3. Innocent-Hacked. The system was compromised and used to
source the lure.
4. Innocent-Hijacked. The IP Address or domain name was hijacked
and used as the source of the lure.
5. Unknown. No conclusions are inferred from this event.
4.4.10. DomainStatus Attribute
ENUM. This attribute allows a reported to note the registry status
of this domain at the time of the report. The enumerated list is
taken verbose from the 'domainStatusType' of the Extensible
Provisioning Protocol[RFC3733]and "Domain Registry Version 2 for the
Internet Registry Information Service" internet-draft[CRISP].
1. <reservedDelegation> - permanently inactive
2. <assignedAndActive> - normal state
3. <assignedAndInactive> - registration assigned but delegation
inactive
4. <assignedAndOnHold> - dispute
5. <revoked> - database purge pending
6. <transferPending> - change of authority pending
7. <registryLock> - on hold by registry
8. <registrarLock> - on hold by registrar
4.4.11. IncludedMalware Element
This elelment allows for the identification and optional inclusion of
the actual malware that was part of the lure. The goal of this
element is not to detail the characteristics of the malware but
rather to allow for a convenient element to link malware to a
phishing campaign.
Cain & Jevans Expires December 16, 2006 [Page 18]
Internet-Draft IODEF Phishing Extensions June 2006
+------------------+
| IncludedMalware |
+------------------+
| |<>--(1..*)--[ Name ]
| |<>--(0..1)--[ Hashvalue ]
| |<>--(0..1)--[ Data ]
+------------------+
+--------------+
| Data |
+--------------+
| STRING |
| |
| XORPattern |
+--------------+
4.4.11.1. Name
One or more value of MLSTRINGTYPE. This optional field is used to
identify the lure malware.
4.4.11.2. Hashvalue
Zero or one value of STRING. This optional field is used to hold a
hashvalue computed over the malware executable.
4.4.11.2.1. Algorithm Parameter
REQUIRED ENUM. This field from the following list identifies the
algorithm used to create this hashvalue.
SHA1. Hashvalue as defined in[SHA]
.
4.4.11.3. Data
Zero or one value of STRING. This optional field is used to include
the lure malware. [Note that STRING is a reasonably way to encode
byte data.]
The Data Element includes an optional 16 hexadecimal character
XORPattern attribute to support disabling the included malware to
bypass anti-virus filters. The default value is 0x55AA55AA55AA55BB
which would be XOR-ed with the malware datastring to revocer the
actual malware.
Cain & Jevans Expires December 16, 2006 [Page 19]
Internet-Draft IODEF Phishing Extensions June 2006
4.4.12. FilesDownloaded Element
Zero or One value of STRING. The contents of this element are a
collection of space-separated filenames downloaded by this lure.
4.4.13. RegistryKeysModified Element
One value of the Keys sequence.
The contents of the RegistryKeysModified element are sets of Keys and
an optional Value as attribute. The structure is artificially
limited to 32 entries.
+-----------------------+
| RegistryKeysModified |
+-----------------------+
| |<>--(1..32)--[ Keys ]
+-----------------------+
+--------------+
| Keys |
+--------------+
| STRING |
| |
| STRING Value |
+--------------+
4.4.13.1. Keys
One STRING, representing the WINDOWS Operating System Registry Key
Name.
4.4.13.2. Value Attribute
One STRING, representing the value of the associated Key.
4.5. OriginatingSensor Element
The OriginatingSensor element contains the identification and
cognizant data of the network element that detected this fraud
activity. Note that the network element does not have to be in the
Internet itself (i.e., it may be a local IDS system) nor is it
required to be mechanical (e.g., humans are allowed).
Multiple Originating Sensor Elements are allowed.
Cain & Jevans Expires December 16, 2006 [Page 20]
Internet-Draft IODEF Phishing Extensions June 2006
+---------------------+
| OriginatingSensor |
+---------------------+
| ENUM OrigSensorType |<>------------[ DateFirstSeen ]
| |<>---(0..1)---[ Name ]
| |<>---(1..*)---[ System ]
| |<>---(0..1)---[ Location ]
+---------------------+
The OriginatingSensor requires a type value and identification of the
entity that generated this report.
4.5.1. OrigSensorType Parameter
A REQUIRED ENUM value from the following list, categorizing the
function of this sensor:
1. Web. A web server or service.
2. WebGateway, as in a proxy or firewall.
3. MailGateway.
4. Browser, or browser-type element.
5. ISP-resident or network sensor.
6. Human or manual analysis.
7. Honeypot or other decoy device.
8. Other.
4.5.2. FirstSeen Element
REQUIRED. DATETIME. This is the date and time that this sensor
first saw this phishing activity.
4.5.3. Name Element
MLSTRINGTYPE. This is the DNS name or other identifier of the
entity that detected this event.
4.5.4. Address Element
IODEF.SOURCE. This is the IPVersion, IPAddress, and optionally,
port number of the entity that generated this report.
Cain & Jevans Expires December 16, 2006 [Page 21]
Internet-Draft IODEF Phishing Extensions June 2006
4.5.5. Location Element
STRING. This is an optional location of the sensor.
4.6. The Data Collection Site Element (DCSite)
Zero or more DCSITEDATA elements. This section captures the type,
identifier, collection location, and other pertinent information
about the credential gathering process by the fraudster. The data
collection site is identified by three elements: the type of
collector activity, what type of collector site, and the network
location (i.e., URL, IP address, etc).
Details about the domain, system, or owner of the DCSite can be
inserted into the DomainData element.
If the DCSite element is present, the DCSiteType element is required.
Multiple DCSiteData elements are allowed.
+-------------+
| DCSite |
+-------------+
| ENUM DCType |<>--(0..*)---[ DCSiteData ]
+-------------+
+------------------+
| DCSiteData |
+------------------+
| ENUM DCSiteType |<>--+--------[ SiteURL ]
| | +--------[ Emailsite ]
| | +--------[ System ]
| | +--------[ Unknown ]
| |<>-----------[ DomainData ]
+------------------+
4.6.1. DCType Parameter
ENUM. This element identifies the method of data collection, as
determined by analyzing the victim computer, lure, or malware, and
are selected from the following list. This element is coupled with
the DCSiteData element to identify the data collection site.
1. Web. The user is redirected to a website to collect the data.
2. Email Form. The victim sends an email with credentials
enclosed.
Cain & Jevans Expires December 16, 2006 [Page 22]
Internet-Draft IODEF Phishing Extensions June 2006
3. Keylogger. Some form of keylogger is downloaded to the
victim.
4. Automation. Other forms of automatic data collection, such
as background OLE automation, are used to capture information.
5. Unspecified.
4.6.2. DCSiteData Element
This element contains the IPAddress, URL, or other identification of
the data collection site as selected by the DCType Parameter.
4.6.2.1. DCSiteType Parameter
ENUM. This parameter tags the network address and other information
in the DataCollectionSiteData element.
1. Web. Data from the victim is collected on a website. The
website URL is included in the DCSitePointer.
2. Email. The victim emails credentials to the collection site.
The email server DNS name is in the DCSitePointer.
3. IODEF.SYSTEM Element. This collection site uses other
protocols to gather data from the victim. The DCSitePointer
field is an IODEF System Element, holding the IP Version
Protocol, IPAddress, and Port number of the collection site. The
Protocol field defaults to TCP, if absent.
4. Unknown. The DCSitePointer data should be verbose to
describe this type of site.
4.7. TakeDownInfo Element
This element identifies the agency(s) that performed the removal or
ISP-blockage of the phish or fraud collector site. A PhraudReport
may have multiple TakeDownInfo elements to support activities where
multiple agencies are active. Note that the term "Agency" is used to
identify any party performing the blocking or removal such as ISPs or
private parties, not just government entities.
+-------------------+
| TakeDownInfo |
+-------------------+
| |<>---(0..1)--[ TakeDownDate ]
| |<>---(0..*)--[ TakeDownAgency ]
| |<>---(0..*)--[ TakeDownComments ]
Cain & Jevans Expires December 16, 2006 [Page 23]
Internet-Draft IODEF Phishing Extensions June 2006
+-------------------+
4.7.1. TakeDownDate Element
Zero or one DATETIME. This is the date and time that takedown of
the collector site occurred.
4.7.2. TakeDownAgency Element
Zero or more STRING. This is a free form string identifying the
agency that performed the takedown
4.7.3. TakeDownComments Element
Zero or more STRING. A free form field to add any additional
details of this takedown effort.
4.8. ArchivedData Element
Zero or more values of the ArchivedData element are allowed.
+-------------------+
| ArchivedData |
+-------------------+
| ENUM Type |<>---(0..1)--[ ArchivedDataURL ]
| |<>---(0..1)--[ ArchivedDataComments ]
+-------------------+
The ArchivedData element is used to typecast and include a gzip
archive file of a data collection site, base camp, or other site
where the phisher developed their code. This element will be
populated when, for example, an ISP takes down a phisher's web site
and has copied the site data into an archive file. There are three
types of archives currently supported, as specified in the type
field.
4.8.1. Type Parameter
This parameter specifies the contents of the archive.
1. Data Collection Site.
2. Basecamp Site.
3. Sender Site.
4. Unspecified.
Cain & Jevans Expires December 16, 2006 [Page 24]
Internet-Draft IODEF Phishing Extensions June 2006
4.8.2. ArchivedDataURL Element
Zero or one value of URL. Many times an investigator may want to
include a copy of the actual malware, lure, or program
executables that were received by the victim. As the executables
can be quite large, this element will point to an Internet-based
server where the executables can be retrieved from, a Fraud
Report just points out where the archive is, and does not include
it in the report. This is the URL where the gzip archive file is
located.
4.8.3. ArchivedDataComments Element
Zero or one value of STRING. This field is a free form area for
comments on the archive and/or URL.
4.9. RelatedData Element
Zero or more value of STRING. This element allows the listing of
other web or net sites that are related to this incident (e.g.,
victim site, etc).
4.10. CorrelationData Element
Zero or more value of STRING. Any information that correlates this
incident to other incidents can be entered here.
4.11. PRComments Element
Zero or more value of STRING. This field allows for any comments
specific to this PhraudReport that does not fit in any other field.
4.12. EmailRecord Element
Extensions are also made to the INCH IODEF Incident EventData element
to support descriptive information received in phishing lure or spam
emails. The ability to report spam is included within a PhraudReport
to support exchanging information about large-scale spam activities,
not necessarily a single spam message to a user. As such the spam
reporting mechanism was not designed to minimize overhead and
processing and to support other widely-used spam reporting formats
such as the MAAWG's ARF.
Information related to the overall fraudulent activity is contained
within the PhraudReport, while the EmailRecord element is used to
capture forensic or detailed technical information about a specific
attack. Incident Reports may have none, one, or multiple
EmailRecords as its goal is to accumulate pertinent technical data
Cain & Jevans Expires December 16, 2006 [Page 25]
Internet-Draft IODEF Phishing Extensions June 2006
associated with a specific attack as an investigation continues.
Reporting of the actual mail message is supported by choosing one of
three methods. First, an AR message may be included. Second, the
message may be included as one large string. Third, the header and
body components may be dissected and included as a series of strings.
+--------------------+
| EmailRecord |
+--------------------+
| |<>--------------[ EmailCount ]
| |<>-+-+----------[ EmailHeader ]
| | | |--(0..1)--[ EmailBody ]
| | +----(0..1)--[ Message ]
| | +----(0..1)--[ ARFText ]
| |<>--(0..1)------[ EmailComments ]
+--------------------+
4.12.1. EmailCount Element
REQUIRED NUMBER. This field enumerates the number of email
messages identified in this record detected by the reporter.
4.12.2. ARFText Element
Zero or one value of STRING. The Messaging Anti-Abuse Working
Group (MAAWG) defined a format for sending abuse and list control
traffic to other parties. Since many of these reports will get
integrated into incident processes, the raw Abuse Reporting
Format (ARF) may be inserted into this element.
The ARF should be encoded as a character string.
4.12.3. Message Element
Zero or one value of STRING. The complete received email message
is included within this element.
4.12.4. EmailHeader Element
One value of STRING. The headers of the phish email are included
in this element as a sequence of one-line text strings. There
SHALL be one EmailHeader element per mailRecord
4.12.5. EmailBody Element
Cain & Jevans Expires December 16, 2006 [Page 26]
Internet-Draft IODEF Phishing Extensions June 2006
Zero or one value of STRING. This element contains the body of
the phish email. If present, there should be at most one
EmailBody element per EmailRecord
4.12.6. EmailComments Element
Zero or one value of STRING. This field contains comments or
relevant data not placed elsewhere about the phishing or spam
email.
Cain & Jevans Expires December 16, 2006 [Page 27]
Internet-Draft IODEF Phishing Extensions June 2006
5. IODEF Required Elements
A report about fraud, spam, or phishing requires certain identifying
information which is contained within the standard IODEF Incident
data structure. The following table identifies attributes required
to be present in a compliant PhraudReport. The required attributes
are a combination of those required by the base IODEF element and
those required by this document. Attributes identified as required
SHALL be populated in conforming phishing activity reports.
The following table is a visual description of the IODEF and
PhraudReport required fields.
+--------------+
| Incident |
+--------------+
| ENUM Purpose |---[ IncidentID ]
| |---[ Assessment ]
| | ---> [ Confidence ]
| |---[ ReportTime ]
| |---[ Contact ]
| | ---> [ Role ]
| | ---> [ Type ]
| | ---> [ Name ]
| |---[ EventData ]
| | ---> [ AdditionalData]
| | ---> [ FraudReport ]
| | ---> [ FraudType ]
| | ---> [ FraudParameter ]
| | ---> [ FraudedBrandName ]
| | ---> [ LureSource ]
| | ---> [ OriginatingSensor ]
| |
+--------------+
5.1. Fraud or Phishing Report
A compliant IODEF PhraudReport is required to contain the following
fields:
Purpose
IncidentID
ReportTime
Contact -> Role
Cain & Jevans Expires December 16, 2006 [Page 28]
Internet-Draft IODEF Phishing Extensions June 2006
Contact -> Type
Contact -> Name
Assessment
EventData
DetectTime
AdditionalData
PhraudReport
FraudType
FraudedBrandName
LureSource
OriginatingSensor
5.2. Wide-Spread Spam Report
These following fields MUST be populated in an IODEF PhraudReport
compliant Spam Activity Report:
Incident Structure:
IncidentID
Purpose
ReportTime
Contact -> Role
Contact -> Type
Contact -> Name
Cain & Jevans Expires December 16, 2006 [Page 29]
Internet-Draft IODEF Phishing Extensions June 2006
Assessment
EventData
DetectTime
AdditionalData
PhraudReport
FraudType == spamreport
LureSource
OriginatingSensor
EmailRecord
EmailCount
EmailHeader or Message
5.3. Guidance on Usage
It may be apparent that the mandatory attributes for a phishing
activity report make for a quite sparse report. As incident
forensics and data analysis require detailed information, the
originator of a PhraudReport should include any tidbit of information
gleaned from the attack analysis. Information that is considered
sensitive can be marked as such using the restriction parameter of
each data element.
Cain & Jevans Expires December 16, 2006 [Page 30]
Internet-Draft IODEF Phishing Extensions June 2006
6. Security Considerations
This document specifies the format of security incident data. As
such, the security of transactions containing the incident report
will vary from organization to organization. We do not want to
burden the information exchange with unnecessary encryption
requirements, as the transport service for the data exchange may
provide adequate protections, or even encryption. The use of
encryption is expected to be agreed upon on originator-recipient
agreement.
The critical security concern is that phishing activity reports may
be falsified or the report may become corrupt during transit. In
areas where transmission security or secrecy is necessary the
application of a digital signature and/or message encryption on each
report will counteract both of these concerns, the digital signature
may be overkill for most activity report users as the goal is to
notify others of the event. For this reason, phishing activity
reports MAY be digitally signed with the optional IODEF XML
signature, although we expect that each receiving entity will
determine the need for this signature independently.
Recipients of fraud reports SHALL be prepared to accept XML digitally
signed reports and SHOULD support receiving encrypted reports.
Cain & Jevans Expires December 16, 2006 [Page 31]
Internet-Draft IODEF Phishing Extensions June 2006
7. IANA Considerations
[This section will change before publication.]
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in . [XML]
Registration request for the iodef namespace:
URI: urn:ietf:params:xml:ns:iodef-phish-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None.
Registration request for the iodef XML schema:
URI: urn:ietf:params:xml:schema:iodef-phish-1.0
Registrant Contact: See the "Author's Address" section of
this document.
XML: See the "Phishing Extensions Schema Definition"
<Appendix A>section of this document.
Cain & Jevans Expires December 16, 2006 [Page 32]
Internet-Draft IODEF Phishing Extensions June 2006
8. Contributors
The extensions are an outgrowth of the Anti-Phishing Working Group
(APWG) activities in data collection and sharing of phishing and
other ecrime-ware.
This document has received significant assistance from two groups
addressing the phishing problem: members of the Anti-Phishing Working
Group and participants in the Financial Services Technology
Consortium's Counter-Phishing project.
Cain & Jevans Expires December 16, 2006 [Page 33]
Internet-Draft IODEF Phishing Extensions June 2006
9. References
9.1. Normative References
[IODEF] Meijer, J., Danyliw, and Demchenko, "The Incident Object
Description Exchange Format Data Model and XML
Implementation", October 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SHA] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard",
FIPS 180-1, May 1994.
[XML] Mealing, M., "The IETF XML Registry", RFC 3688,
January 2004.
9.2. Informative References
[CRISP] Newton, L. and A. Neves, "Domain Registry Version 2 for
the Internet Registry Information Service", May 2006.
[IDMEF] Curry, D. and H. Debar, "The Intrusion Detection Message
Exchange Format", July 2004.
[RFC3733] Hollenbeck, "Extensible Provisioning Protocol (EPP)
Contact Mapping", RFC 3733", RFC 3733, March 2004.
Cain & Jevans Expires December 16, 2006 [Page 34]
Internet-Draft IODEF Phishing Extensions June 2006
Appendix A. Phishing Extensions XML Schema
A digital copy of this file is available to prevent errors when re-
entering text. See www.coopercain.com/incidents .
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="draft-ietf-inch-phishingextns-033.xsd"
xmlns="draft-ietf-inch-iodef-070.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish="draft-ietf-inch-phishingextns-033.xsd"
xmlns:iodef="draft-ietf-inch-iodef-070.xsd">
<xs:import namespace="draft-ietf-inch-iodef-070.xsd"
schemaLocation="draft-ietf-inch-iodef-070.xsd"/>
<!--
This Schema complies with draft-ietf-inch-phishingextns-03.txt
===================================================================
=== Top Level Class: PhraudReport ===
===================================================================
-->
<xs:element name="PhraudReport">
<xs:complexType>
<xs:sequence>
<xs:annotation>
<xs:documentation>
This is an EventData.AdditionalData structure for
an IODEF Incident class.</xs:documentation>
</xs:annotation>
<xs:element minOccurs="0" name="PhishNameRef"
type="xs:string"/>
<xs:element minOccurs="0" name="PhishNameLocalRef"
type="xs:string"/>
<xs:element minOccurs="0" name="FraudParameter"
type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="FraudedBrandName" type="xs:string"/>
Cain & Jevans Expires December 16, 2006 [Page 35]
Internet-Draft IODEF Phishing Extensions June 2006
<xs:element maxOccurs="unbounded" name="LureSource">
<xs:complexType mixed="false">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
<xs:element minOccurs="0" ref="phish:DomainData"/>
<xs:element minOccurs="0" name="IncludedMalware">
<xs:complexType>
<xs:sequence>
<xs:element name="Name"/>
<xs:element minOccurs="0" name="Hashvalue">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Algorithm"
use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="SHA1"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="Data">
<xs:complexType>
<xs:attribute default="55AA55AA55AA55BB"
name="XORPattern" type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="FilesDownloaded">
<xs:simpleType>
<xs:list itemType="xs:string"/>
</xs:simpleType>
</xs:element>
<xs:element minOccurs="0" name="RegistryKeysModified">
<xs:complexType>
Cain & Jevans Expires December 16, 2006 [Page 36]
Internet-Draft IODEF Phishing Extensions June 2006
<xs:sequence>
<xs:element maxOccurs="32" name="Key"
type="phish:RegistryKeyItemType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="1" ref="phish:OriginatingSensor"/>
<xs:element maxOccurs="1" minOccurs="0"
ref="phish:EmailRecord"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:DCSite"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:TakeDownInfo"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:ArchivedData"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="RelatedData" type="xs:string"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="CorrelationData" type="xs:string"/>
<xs:element maxOccurs="1" minOccurs="0" name="PRComments"
type="xs:string"/>
</xs:sequence>
<xs:attribute default="0.33" name="Version" use="optional"/>
<xs:attribute name="FraudType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="phishemail"/>
<xs:enumeration value="recruitemail"/>
<xs:enumeration value="malwareemail"/>
<xs:enumeration value="fraudsite"/>
<xs:enumeration value="dnsspoof"/>
<xs:enumeration value="keylogger"/>
<xs:enumeration value="ole"/>
<xs:enumeration value="im"/>
<xs:enumeration value="cve"/>
Cain & Jevans Expires December 16, 2006 [Page 37]
Internet-Draft IODEF Phishing Extensions June 2006
<xs:enumeration value="archive"/>
<xs:enumeration value="spamreport"/>
<xs:enumeration value="voip"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType name="RegistryKeyItemType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Value"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!--
==================================================================
=== Top Level Class: EmailRecord ===
==================================================================
-->
<xs:element name="EmailRecord">
<xs:complexType>
<xs:sequence>
<xs:element name="EmailCount" type="xs:integer"/>
<xs:choice>
<xs:sequence>
<xs:element name="EmailHeader">
<!-- This is an ugly way to deal
with multi-line header info. -->
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
name="Header" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="EmailBody"
type="xs:string"/>
</xs:sequence>
Cain & Jevans Expires December 16, 2006 [Page 38]
Internet-Draft IODEF Phishing Extensions June 2006
<xs:element minOccurs="0" name="Message"
type="iodef:MLStringType"/>
<xs:element minOccurs="0" name="ARFText" type="xs:string"/>
</xs:choice>
<xs:element maxOccurs="1" minOccurs="0" name="EmailComments"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
==================================================================
=== Data Collection Site Info ===
==================================================================
-->
<xs:element name="DCSite">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="DCSiteData">
<xs:complexType>
<xs:sequence>
<xs:choice>
<xs:element name="siteurl" type="xs:anyURI"/>
<xs:element name="emailsite" type="xs:string"/>
<xs:element ref="iodef:System"/>
<xs:element name="unknown" type="xs:string"/>
</xs:choice>
<xs:element minOccurs="0" ref="phish:DomainData"/>
</xs:sequence>
<xs:attribute name="DCSitetype" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
<xs:enumeration value="email"/>
<xs:enumeration value="ipaddress"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
Cain & Jevans Expires December 16, 2006 [Page 39]
Internet-Draft IODEF Phishing Extensions June 2006
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="DCType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
<xs:enumeration value="email"/>
<xs:enumeration value="keylogger"/>
<xs:enumeration value="automation"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="DomainData">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="1" minOccurs="1" name="Name"
type="iodef:MLStringType">
<xs:annotation>
<xs:documentation>Multiple domains with equal contact and
registraton data can be referenced with the "sameas"
entry.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0"
name="DateDomainWasChecked" type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0"
name="RegistrationDate" type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="16" minOccurs="0" name="Nameserver">
<xs:complexType>
<xs:sequence>
Cain & Jevans Expires December 16, 2006 [Page 40]
Internet-Draft IODEF Phishing Extensions June 2006
<xs:element name="Server" type="phish:DNSNameType"/>
<xs:element ref="iodef:Address"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice id="DomainContacts">
<xs:element name="SameDomainContact"
type="phish:DNSNameType"/>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:DomainContact"/>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attribute name="SystemStatus">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="spoofed"/>
<xs:enumeration value="fraudulent"/>
<xs:enumeration value="innocent-hacked"/>
<xs:enumeration value="innocent-hijacked"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="DomainStatus">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration
value="<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
Cain & Jevans Expires December 16, 2006 [Page 41]
Internet-Draft IODEF Phishing Extensions June 2006
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>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType name="DNSNameType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="DomainContact">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" ref="iodef:ContactName"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:Description"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:RegistryHandle"/>
<xs:element minOccurs="0" ref="iodef:PostalAddress"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:Email"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:Telephone"/>
<xs:element minOccurs="0" ref="iodef:Fax"/>
<xs:element minOccurs="0" ref="iodef:Timezone"/>
</xs:sequence>
<xs:attribute name="role">
<xs:simpleType>
Cain & Jevans Expires December 16, 2006 [Page 42]
Internet-Draft IODEF Phishing Extensions June 2006
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="registrant"/>
<xs:enumeration value="registrar"/>
<xs:enumeration value="billing"/>
<xs:enumeration value="technical"/>
<xs:enumeration value="administrative"/>
<xs:enumeration value="legal"/>
<xs:enumeration value="zone"/>
<xs:enumeration value="abuse"/>
<xs:enumeration value="security"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="confidence">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="known-fraudulent"/>
<xs:enumeration value="looks-fraudulent"/>
<xs:enumeration value="known-real"/>
<xs:enumeration value="looks-real"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<!--
===================================================================
=== The Originating Sensor Data Element ===
===================================================================
-->
<xs:element name="OriginatingSensor">
<xs:complexType>
<xs:sequence>
<xs:element name="FirstSeen" type="xs:dateTime"/>
<xs:element minOccurs="0" name="name"
type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
Cain & Jevans Expires December 16, 2006 [Page 43]
Internet-Draft IODEF Phishing Extensions June 2006
<xs:element minOccurs="0" ref="iodef:Location"/>
</xs:sequence>
<xs:attribute name="OriginatingSensorType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="web"/>
<xs:enumeration value="webgateway"/>
<xs:enumeration value="mailgateway"/>
<xs:enumeration value="browser"/>
<xs:enumeration value="ispsensor"/>
<xs:enumeration value="human"/>
<xs:enumeration value="honeypot"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
===================================================================
=== The Take Down Data structure. ===
===================================================================
-->
<xs:element name="TakeDownInfo">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="TakeDownDate"
type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownAgency" type="xs:string"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownComments" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Cain & Jevans Expires December 16, 2006 [Page 44]
Internet-Draft IODEF Phishing Extensions June 2006
<!--
===================================================================
=== The Archived Data Element ===
===================================================================
-->
<xs:element name="ArchivedData">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="ArchivedDataURL"
type="xs:anyURI"/>
<xs:element minOccurs="0" name="ArchivedDataComments"
type="xs:string"/>
</xs:sequence>
<xs:attribute name="ArchivedDataType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="collectionsite"/>
<xs:enumeration value="basecamp"/>
<xs:enumeration value="sendersite"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
===================================================================
=== The Related Data Element ===
===================================================================
-->
<xs:element name="RelatedData">
<xs:complexType>
<xs:sequence>
<xs:element name="URLs" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Elements and pieces that are used in many places.-->
Cain & Jevans Expires December 16, 2006 [Page 45]
Internet-Draft IODEF Phishing Extensions June 2006
<xs:element name="url" type="xs:anyURI"/>
<xs:element name="email">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\S@\S"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:schema>
Cain & Jevans Expires December 16, 2006 [Page 46]
Internet-Draft IODEF Phishing Extensions June 2006
Appendix B. Sample Malware Email Report
This section shows a received electronic mail message that included a
virus in a zipped attachment and a report that was generated for that
message.
B.1. Received Email
From: support@coopercain.com
Sent: Friday, June 10, 2005 3:52 PM
To: pcain@coopercain.com
Subject: You have successfully updated your password
Attachments: updated-password.zip
Dear user pcain,
You have successfully updated the password of your Coopercain
account. If you did not authorize this change or if you need
assistance with your account, please contact Coopercain customer
service at: support@coopercain.com
Thank you for using Coopercain!
The Coopercain Support Team
+++ Attachment: No Virus (Clean) +++
Coopercain Antivirus - www.coopercain.com
B.2. Generated Report
NOTE: Some wrapping and folding liberties have been applied to fit it
into the margins.
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document
xsi:schemaLocation="draft-ietf-inch-phishingextns-033.xsd
draft-ietf-inch-phishingextns-033.xsd"
xmlns="draft-ietf-inch-iodef-070.xsd"
xmlns:phish="draft-ietf-inch-phishingextns-033.xsd"
xmlns:iodef="draft-ietf-inch-iodef-070.xsd"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<Incident purpose="other">
<IncidentID name="Pat">PAT2005-06</IncidentID>
<ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
<Description>This is a test report from actual data.
</Description>
<Assessment>
<Confidence rating="high"></Confidence>
</Assessment>
Cain & Jevans Expires December 16, 2006 [Page 47]
Internet-Draft IODEF Phishing Extensions June 2006
<Contact role="creator" type="person">
<ContactName>patcain</ContactName>
<Email>pcain@coopercain.com</Email>
</Contact>
<EventData>
<DetectTime>2005-06-21T18:22:02-05:00</DetectTime>
<AdditionalData dtype="xml">
<phish:PhraudReport FraudType="phishemail">
<phish:FraudParameter>
Subject: You have successfully updated your password
</phish:FraudParameter>
<phish:FraudedBrandName>Cooper-Cain</phish:FraudedBrandName>
<phish:LureSource>
<System category="source">
<Node>
<Address>216.231.63.162</Address>
</Node>
</System>
<phish:IncludedMalware>
<phish:Name>W32.Mytob.EA@mm</phish:Name>
</phish:IncludedMalware>
</phish:LureSource>
<phish:OriginatingSensor OriginatingSensorType="human">
<phish:FirstSeen>2005-06-10T15:52:11-05:00</phish:FirstSeen>
<System>
<Node>
<Address>10.0.0.4</Address>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:Message>"Return-path: <support@coopercain.com>"
Envelope-to: pcain@coopercain.com
Delivery-date: Fri, 10 Jun 2005 15:52:11-0400
Received: from dsl231-063-162.sea1.dsl.speakeasy.net
([216.231.63.162] helo=coopercain.com) by
mail06.coopercain.com with esmtp
(Exim) id 1DgpXy-0002Ua-IR for pcain@coopercain.com;
Fri, 10 Jun 2005 15:52:10-0400
From: support@coopercain.com
To: pcain@coopercain.com
Subject: You have successfully updated yourn password
Cain & Jevans Expires December 16, 2006 [Page 48]
Internet-Draft IODEF Phishing Extensions June 2006
Date: Fri, 10 Jun 2005 12:52:00 -0700 MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0008_0911068B.E7EB6D2A"
X-Priority: 3
X-MSMail-Priority: Normal X-EN-OrigIP: 216.231.63.162
X-EN-OrigHost: dsl231-063-162.sea1.dsl.speakeasy.net
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on
Scan18.int.bizland.net X-Spam-Level: ***** X-Spam-Status: No,
score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30,
HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE,NO_REAL_NAME,
PRIORITY_NO_NAME autolearn=disabled version=3.0.2
From: support@coopercain.com
Sent: Friday, June 10, 2005 3:52 PM
To:pcain@coopercain.com
Subject: You have successfully updated your password
Attachments: updated-password.zip
Dear user pcain,
You have successfully updated the password of your
Coopercain account.
If you did not authorize this change or if you need
assistance with your account, please contact Coopercain
customer service at:
support@coopercain.com
Thank you for using Coopercain!
The Coopercain Support Team
+++ Attachment: No Virus (Clean) +++
Coopercain Antivirus - www.coopercain.com</phish:Message>
</phish:EmailRecord>
</phish:PhraudReport></AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
B.3. Notes and Commentary
Cain & Jevans Expires December 16, 2006 [Page 49]
Internet-Draft IODEF Phishing Extensions June 2006
Appendix C. Sample Phish Email Report
A sample report generated from a received electronic mail phishing
message in shoen in this section.
C.1. Received Lure
Return-path: <service@paypal.com>
Envelope-to: pcain@coopercain.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.yourhostingaccount.com ([10.1.1.161]
helo=mail15.yourhostingaccount.com)
by mailscan38.yourhostingaccount.com with esmtp (Exim)
id 1Fq5Kr-0005wU-LT for pcain@coopercain.com; Tue, 13 Jun 2006
05:37:21 -0400
Received: from [24.147.114.61] (helo=TSI)
by mail15.yourhostingaccount.com with
esmtp (Exim) id 1Fq5Bj-0006dv-6b
for pcain@coopercain.com; Tue, 13 Jun 2006 05:37:21 -0400
Received: from User ([66.59.189.157]) by TSI with
Microsoft SMTPSVC(5.0.2195.6713);
Tue, 13 Jun 2006 02:24:30 -0400
Reply-To: <nospa@nospa.us>
From: "PayPal"<service@paypal.com>
Subject: * * * Update & Verify Your PayPal Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@paypal.com
X-EN-OrigIP: 24.147.114.61
X-EN-OrigHost: unknown
PayPal<http://www.paypal.com/images/paypal_logo.gif>
<http://www.paypal.com/images/pixel.gif>
<http://www.paypal.com/images/pixel.gif>
<http://www.paypal.com/images/pixel.gif>
Account Update Request
Cain & Jevans Expires December 16, 2006 [Page 50]
Internet-Draft IODEF Phishing Extensions June 2006
Dear PayPal. member:,
You are receiving this notification because PayPal is required by
law to notify you, that you urgently need to update your online
account statement, due to high risks of fraud intentions.
The updating of your PayPal account can be done at any time by
clicking on the link shown below
http://www.paypal.com/cgi-bin/webscr?cmd=_login-run
<http://217.136.251.41:8080/.cgi-bin/.webscr/.secure-
login/%20/%20/.payp
al.com/index.htm>
Once you log in,update your account information.
After updating your account click on the History sub tab of your
Account Overview page to see your most recent statement.
If you need help with your password, click the Help link which is at
the upper right hand side of the PayPal website. To report errors in
your statement or make inquiries, click the Contact Us link in the
footer on any page of the PayPal website, call our Customer Service
center at (402) 938-3630, or write us at:
PayPal, Inc.
P.O. Box 45950
Omaha, NE 68145
Sincerely,
PayPal
<http://www.paypal.com/images/dot_row_long.gif>
C.2. Phishing Report
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document
xsi:schemaLocation="draft-ietf-inch-phishingextns-033.xsd
draft-ietf-inch-phishingextns-033.xsd"
xmlns="draft-ietf-inch-iodef-070.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish="draft-ietf-inch-phishingextns-033.xsd"
<Incident purpose="mitigation" restriction="private">
<IncidentID name="cooper-cain">CC200600000002</IncidentID>
Cain & Jevans Expires December 16, 2006 [Page 51]
Internet-Draft IODEF Phishing Extensions June 2006
<ReportTime>2006-06-13T21:14:56-05:00</ReportTime>
<Description>
This is a sample phishing email received report. The phish
was actually received as is.
</Description>
<Assessment></Assessment>
<Contact role="creator" type="person">
<ContactName>patcain</ContactName>
<Email>pcain@coopercain.com</Email>
</Contact>
<EventData>
<DetectTime>2006-06-13T05:37:21-04:00</DetectTime>
<AdditionalData dtype="xml">
<phish:PhraudReport FraudType="phishemail">
<phish:FraudParameter> * * * Update & 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>
Cain & Jevans Expires December 16, 2006 [Page 52]
Internet-Draft IODEF Phishing Extensions June 2006
Envelope-to: pcain@coopercain.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.yourhostingaccount.com
([10.1.1.161] helo=mail15.yourhostingaccount.com) by
mailscan38.yourhostingaccount.com with esmtp (Exim) id
1Fq5Kr-0005wU-LT for pcain@coopercain.com; Tue, 13
Jun 2006 05:37:21 -0400
Received: from [24.147.114.61] (helo=TSI) by
mail15.yourhostingaccount.com with esmtp (Exim) id
1Fq5Bj-0006dv-6b for pcain@coopercain.com; Tue, 13
Jun 2006 05:37:21 -0400
Received: from User ([66.59.189.157]) by TSI with
Microsoft SMTPSVC(5.0.2195.6713); Tue, 13
Jun 2006 02:24:30 -0400
Reply-To: <nospa@nospa.us>
From: "PayPal"<service@paypal.com>
Subject: * * * Update & Verify Your
PayPal Account * * *
Date: Tue, 13 Jun 2006 02:36:34-0400
MIME-Version: 1.0 Content-Type: text/html;
charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@paypal.com
X-EN-OrigIP: 24.147.114.61
X-EN-OrigHost: unknown
PayPal<http://www.paypal.com/images/paypal_logo.gif>
<http://www.paypal.com/images/pixel.gif>
<http://www.paypal.com/images/pixel.gif>
<http://www.paypal.com/images/pixel.gif>
Account Update
Request Dear PayPal. member:, You are receiving this
notification because PayPal is required by law to notify
you, that you urgently need to update your online account
statement, due to high risks of fraud intentions. The
updating of your PayPal account can be done
at any time by clicking on the link shown below
http://www.paypal.com/cgi-bin/webscr?cmd=_login-run
<http://217.136.251.41:8080/.cgi-bin/.webscr/.secure-
login/%20/%20/.paypal.com/index.htm>
Once you log in,update your account information. After
Cain & Jevans Expires December 16, 2006 [Page 53]
Internet-Draft IODEF Phishing Extensions June 2006
updating your account click on the History sub
tab of your Account Overview page to see your most recent
statement. If you need help with your password, click the
Help link which is at the upper right hand side of the
PayPal website.
To report errors in your statement or make inquiries,
click the Contact Us link in the footer on any page of
the PayPal website, call our Customer Service center at
(402) 938-3630, or write us at: PayPal, Inc. P.O.
Box 45950 Omaha, NE 68145 Sincerely, PayPal
<http://www.paypal.com/images/dot_row_long.gif>
</phish:Message>
</phish:EmailRecord>
<phish:DCSite DCType="web">
<phish:DCSiteData DCSitetype="web">
<phish:siteurl>http://217.136.251.41:8080/.cgi-bin/.web
scr/.secure-login/%20%20/.paypal.com/index.htm
</phish:siteurl>
<phish:DomainData
DomainStatus="<assignedAndActive> - normal state"
SystemStatus="unknown">
<phish:Name>adsl.skynet.be</phish:Name>
<phish:DateDomainWasChecked>
2006-06-14T13:05:00-05:00
</phish:DateDomainWasChecked>
<phish:RegistrationDate>
2000-12-13T00:00:00
</phish:RegistrationDate>
<phish:Nameserver>
<phish:Server>ns1.skynet.be</phish:Server>
<Address>195.238.3.17</Address>
</phish:Nameserver>
</phish:DomainData>
</phish:DCSiteData>
</phish:DCSite>
</phish:PhraudReport></AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
Cain & Jevans Expires December 16, 2006 [Page 54]
Internet-Draft IODEF Phishing Extensions June 2006
C.3. Notes and Commentary
Cain & Jevans Expires December 16, 2006 [Page 55]
Internet-Draft IODEF Phishing Extensions June 2006
Appendix D. Sample Spam Report
[ ed.To be supplied, but it looks a lot like the fraud report]
Cain & Jevans Expires December 16, 2006 [Page 56]
Internet-Draft IODEF Phishing Extensions June 2006
Authors' Addresses
Patrick Cain
The Cooper-Cain Group, Inc.
P.O. Box 400992
Cambridge, MA
USA
Email: pcain@coopercain.com
David Jevans
The Anti-Phishing Working Group
5150 El Camino Real, Suite A20
Los Altos, CA 94022
USA
Email: dave.jevans@antiphishing.org
Cain & Jevans Expires December 16, 2006 [Page 57]
Internet-Draft IODEF Phishing Extensions June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Cain & Jevans Expires December 16, 2006 [Page 58]
