One document matched: draft-cain-post-inch-phishingextns-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="std" docName="draft-cain-post-inch-phishingextns-05"
ipr="full3978" obsoletes="" updates="">
<front>
<title abbrev="IODEF Phishing Extensions">Extensions to the IODEF-Document
Class for Reporting Phishing, Fraud, and Other Crimeware</title>
<author fullname="Patrick Cain" initials="P" surname="Cain">
<organization>The Cooper-Cain Group, Inc.</organization>
<address>
<postal>
<street>P.O. Box 400992</street>
<city>Cambridge</city>
<region>MA</region>
<country>USA</country>
</postal>
<email>pcain@coopercain.com</email>
</address>
</author>
<author fullname="David Jevans" initials="D" surname="Jevans">
<organization>The Anti-Phishing Working Group</organization>
<address>
<postal>
<street>5150 El Camino Real, Suite A20</street>
<city>Los Altos</city>
<region>CA 94022</region>
<country>USA</country>
</postal>
<email>dave.jevans@antiphishing.org</email>
</address>
</author>
<date day="30" month="July" year="2008" />
<area>Security</area>
<keyword>RFC</keyword>
<keyword>Request For Comments</keyword>
<abstract>
<t>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 reporting of
multiple phishing incidents.</t>
<t>The extensions defined in this document are used to generate two
different types of reports: a fraud and phishing report and a
wide-spread spam report. Although similar in structure, each report has
different required objects and intents.</t>
</abstract>
<note title="RFC 2129 Keywords">
<t>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 <xref format="default"
pageno="false" target="RFC2119"> RFC 2119 </xref>.</t>
</note>
</front>
<middle>
<section title="Introduction" toc="default">
<t>Deception activities, such as receiving an email purportedly from a
bank requesting you to confirm your account information, are an
expanding attack type on the Internet. The terms phishing and fraud are
used interchangeably in this document to characterize broadly-launched
social engineering attacks in which an electronic identity is
misrepresented in an attempt to trick individuals into revealing their
personal credentials ( e.g., passwords, account numbers, personal
information, ATM PINs, etc.). A successful phishing attack on an
individual allows the phisher (i.e., the attacker) to exploit the
individual's credentials for financial or other gain. Phishing attacks
have morphed from directed email messages from alleged financial
institutions to more sophisticated lures that may also include
malware.</t>
<t>This document defines a data format extension to the Incident Object
Description Exchange Format (IODEF) <xref target="RFC5070" /> that can
be used to describe information about a phishing incident or wide-spread
spam incident. Sections 2 and 3 of this document introduce the
high-level report format and how to use it. Sections 4 and 5 describe
the data elements of the fraud extensions. This document includes an XML
schema for the extensions and a few example fraud reports.</t>
<t>The extensions defined in this document may be used to report
targeted ('spear') phishing, broad multi-recipient phishing, wide-spread
spam events, the distribution of malware, and evolving Internet-based
fraud attempts. Receipt of single spam message MUST NOT be reported via
these extensions as these formats are for more general, widespread
events. </t>
<t />
<section title="Why a Common Report Format is Needed">
<t>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 pursuit and
prosecution of the attacker.</t>
<t>By using a common format, it becomes easier for an organization to
engage in this coordination as well as correlation of information from
multiple data sources or products into a cohesive view. As the number
of data sources increases, a common format becomes even more
important, since multiple tools would be needed to interpret the
different sources of data. </t>
<t>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.</t>
<t>While the intended use of this specification is to facilitate data
sharing between parties, the mechanics of this sharing process and its
related political challenges are out of scope for this document.</t>
</section>
<section title="Relation to the INCH IODEF Data Model">
<t>Instead of defining a new report format, this draft defines an
extension to <xref format="default" target="RFC5070" />. 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.</t>
<section title="Fraudulent Activity Extensions to the IODEF-Document">
<t>Fraudulent events are reported in a Fraud Activity Report which
is an instance of an XML IODEF-Document Incident element with added
EventData and AdditionalData elements. The additional fields in the
EventData specific to phishing and fraud are enclosed into a
PhraudReport XML element. Fraudulent activity may include multiple
emails, instant messages, or network messages, scattered over
various times, locations, and methodologies. The PhraudReport within
an EventData may include information about the email header and
body, details of the actual phishing lure, correlation to other
attacks, and details of the removal of the web server or credential
collector. As a phishing attack may generate multiple reports to an
incident team, multiple PhraudReports may be combined into one
EventData structure and multiple EventData structures may be
combined into one Incident Report. One IODEF Incident report may
record one or more individual phishing events and may include
multiple EventData elements.</t>
<t>This document defines new extension elements for the EventData
and Record Item IODEF XML elements and identifies those required in
a PhraudReport. The Appendices contain sample Fraud Activity Reports
and a complete Schema.</t>
<t>The IODEF Extensions defined in this document comply with section
4, "Extending the IODEF Format" in <xref format="default"
pageno="false" target="RFC5070" />.</t>
</section>
</section>
</section>
<section title="The Elements of Phishing/Fraud Activity">
<figure>
<artwork height=""
name="Figure 2.0 The Components of Internet Phishing."
type="" width="" xml:space="preserve">
+-----------+ +------------------+
| Fraudster |<---<-- | Collection Point |<---O--<----<----+
+----+------+ +------------------+ | |
| | |
| +--|-----+ ^
| | Sensor | Credentials
| +-|------+ |
| +---------------+ | +-------+
\--->--| Attack Source |--Phish-->-----O------> | User/ |
+---------------+ |Victim |
+-------+
Figure 2.1: The Components of Internet Phishing
</artwork>
</figure>
<t>Internet-based Phishing and Fraud activities are normally comprised
of at least four components:</t>
<t>
<list>
<t>1. The Phisher, Fraudster, or party perpetrating the fraudulent
activity. Most times this party is not readily identifiable.</t>
<t>2. The Attack Source, the source of the phishing email, virus,
trojan, or other attack is masked in an enticing manner.</t>
<t>3. The User, Victim, or intended target of the fraud/phish.</t>
<t>4. The collection point, where the victim sends their credentials
or personal data if they have been duped by the phisher.</t>
</list>
</t>
<t>If we take a holistic view of the attack, there are some additional
components:</t>
<t>
<list>
<t>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.</t>
<t>6. A forensic or archive site (not pictured) where an
investigator has copied or otherwise retained the data used for the
fraud attempt or credential collection.</t>
</list>
</t>
</section>
<section title="Fraud Activity Reporting via IODEF-Documents"
toc="default">
<t>A Fraud Activity Report is an instance of an XML IODEF-Document with
additional extensions and usage guidance as specified in Section 4 of
this document. These additional extensions are implemented through the
PhraudReport XML element.</t>
<t>As described in the following sections, reporting Fraud Activity has
three primary components: choosing a report type; a format for the data;
and how to check correctness of the format.</t>
<section title="Fraud Report Types">
<t>There are three actions relating to reporting phishing events.
First, a reporter may *create* and exchange a new report on a new
event. Secondly, a reporter may *update* a previously exchanged report
to indicate new collection sites, site take down information, or
related activities. Lastly, a reporter may have realized that the
report is in error or contain significant incorrect data and the
prudent reaction is to *delete* the report.</t>
<t>The three types of reports are denoted through the use of the
ext-pupose attribute of an Incident element. A new report contains an
empty or a "create" ext-purpose value; an updated report contains a
ext-value value of "update"; a request for deletion contains a
"delete" ext-purpose value. Note that this is actually an advisory
marking for the report originator or recipient as operating procedures
in a report lifecycle is very environment specific.</t>
</section>
<section title="Fraud Report XML Representation">
<t>The IODEF Incident element [RFC5070, Section 3.2] is summarized
below. It and the rest of the data model presented in Section 4 is
expressed in Unified Modeling Language (UML) syntax as used in the
IODEF specification. The UML representations is for illustrative
purposes only; elements are specified in XML as defined in <xref
format="counter" target="AppendixA" /></t>
<figure title="">
<artwork height="" name="The IODEF Incident Element" type=""
width="" xml:space="preserve">
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| | |<>--[ AdditionalData ]
| | |<>--[ PhraudReport ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 3.1: The IODEF XML Incident Element (modified)
</artwork>
</figure>
<t>A Fraud Activity Report is composed of one iodef:Incident element
that contains one or more related PhraudReport elements embedded in
iodef:AdditionalData element of iodef:EventData. The PhraudReport
element is added to the IODEF using its defined extension procedure
documented in Section 5 of [RFC5070].</t>
<t>One IODEF-Document may contain information on multiple incidents
with information for each incident contained within an iodef:Incident
element [RFC5070], Section 3.12].</t>
</section>
<section title="Correctness of Fraud Activity Reports">
<t>The Fraud Activity Report MUST pass XML validation using the schema
defined in <xref target="RFC5070" /> and the extensions defined in</t>
<t><eref target="AppendixA" /> of this document.</t>
</section>
</section>
<section title="PhraudReport Element Definitions" toc="default">
<t>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.</t>
<section title="PhraudReport Structure">
<t>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.</t>
<figure>
<artwork xml:space="preserve">+------------------+
| PhraudReport |
+------------------+
| STRING Version |<>--{0..1}--[ PhishNameRef ]
| ENUM FraudType |<>--{0..1}--[ PhishNameLocalRef ]
| |<>--{0..1}--[ FraudParameter ]
| |<>--{0..*}--[ FraudedBrandName ]
| |<>--{1..*}--[ LureSource ]
| |<>--{1..*}--[ OriginatingSensor ]
| |<>--{0..1}--[ EmailRecord ]
| |<>--{0..*}--[ DCSite ]
| |<>--{0..*}--[ TakeDownInfo ]
| |<>--{0..*}--[ ArchivedData ]
| |<>--{0..*}--[ RelatedData ]
| |<>--{0..*}--[ CorrelatedData ]
| |<>--{0..1}--[ PRComments ]
+------------------+
Figure 4.1: The PhraudReport Element </artwork>
</figure>
<t>Relevant information about a phishing or fraud event can be encoded
by encoding the six components as follows:<list style="letters">
<t>The PhishNameRef and PhishNameLocalRef elements identify the
fraud or class of fraud.</t>
<t>The LureSource element describes the source of the attack or
phishing lure, including host information and any included
malware.</t>
<t>The DCSite describes the technical details of the credential
collection point.</t>
<t>The Originating Sensor element describes the means of
detection.</t>
</list></t>
<t>The RelatedData, ArchivedData, and TakeDownInfo fields allow
optional forensics and history data to be included.</t>
<t>A specific phish/fraud activity can be identified using a
combination of the FraudType, FraudParameter, FraudedBrandName,
LureSource, and PhishNameRef elements.</t>
</section>
<section title="Reuse of IODEF-defined Elements">
<t>Elements, attributes, and parameters defined in the base IODEF
specification were used whenever possible in the definition of the
PhraudReport XML element. This specification does not introduce any
new variable types or encodings to the IODEF data model, but extends
the IODEF Contact and System elements. </t>
<t>Note: Elements that are imported from the base IODEF specification
are prefaced with an "iodef" XML namespace and are noted with the
section defining that element in <xref target="RFC5070" />. Each
element in a PhraudReport is used as described in the following
sections.</t>
</section>
<section title="Element and Attribute Specification Format">
<t>The following sections describe the components of a PhraudReport
XML element. Each description is structured as follows.</t>
<t><list>
<t>1. A terse XML-type identifier for the element or
attribute.</t>
<t>2. An indication of whether the element or attribute is
REQUIRED or optional. Mandatory items are noted as REQUIRED. If
not specified, elements are optional. Note that when optional
elements are included, they may REQUIRE specific sub-elements.</t>
<t>3. A description of the element or attribute and its intended
use.</t>
</list>Elements that contain sub-elements or enumerated values are
further sub-sectioned. Note that there is no 'trickle-up' effect in
elements. That is, the required elements of a sub-element are only
populated if the sub-element is used. </t>
</section>
<section title="Version attribute" toc="default">
<t>REQUIRED. STRING. The version shall be the value 0.04 to be
compliant with this document. [This value will be changed to "1.0"
when this document progresses.]</t>
</section>
<section title="FraudType attribute" toc="default">
<t>REQUIRED. One ENUM. The FraudType attribute describes the type of
fraudulent activity described in this PhraudReport and contains one of
the following values:</t>
<t>
<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
<t>keylogger. This choice does not have a FraudParameter and
specifies a keylogger downloaded with the lure.</t>
<t>ole. There is no FraudParameter. This identifies background
Microsoft Object Linking and Embedding (OLE) information that
comes as part of a lure.</t>
<t>im. The FraudParameter should be the malicious instant message
(IM) link supplied to the user.</t>
<t>cve. This choice identifies CVE-known malware, with the Common
Vulnerability and Exposures project (CVE) number as the
FraudParameter.</t>
<t>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.</t>
<t>spamreport. This type is used when the PhraudReport is
reporting a large-scale spam activity. The FraudParameter should
be the spam email subject line.</t>
<t>voip. The lure was received via a voice-over-IP connection
identified by the information in the FraudParameter field.</t>
<t>other. This is used to identify not-yet-enumerated fraud
types.</t>
<t>unknown. This choice may have an associated FraudParameter. It
is used to cover confused cases.</t>
</list>
</t>
<section title="FraudParameter element">
<t>REQUIRED. One value of iodef:MLStringType. 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.</t>
</section>
</section>
<section title="PhishNameRef element">
<t>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.</t>
</section>
<section title="PhishNameLocalRef element">
<t>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.</t>
</section>
<section title="FraudedBrandName element">
<t>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).</t>
</section>
<section title="LureSource element">
<t>REQUIRED. One value. 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.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+-------------+
| LureSource |
+-------------+
| |<>--(1..*)--[ System ]
| |<>--(0..*)--[ DomainData ]
| |<>--(0..1)--[ IncludedMalware ]
| |<>--(0..1)--[ FilesDownloaded ]
| |<>--(0..1)--[ RegistryKeysModified ]
+-------------+
Figure 4.2: The LureSource element
</artwork>
</figure>
<section title="System element">
<t>REQUIRED. One or more values of the iodef:System [RFC5070,
Section 3.15]. The system element describes a particular host
involved in the phishing activity. If the real IP Address can be
ascertained, it should be populated. A spoofed address may also be
entered and the spoofed attribute SHALL be set.</t>
</section>
<section title="DomainData element">
<t>Zero or more element values. The DomainData element describes the
registration, delegation, and control of a domain used to source the
lure. Capturing the domain data is very useful when investigating or
correlating events.</t>
<t>The structure of a DomainData element is as follows:</t>
<figure>
<artwork height="" name="" type="" width="" xml:space="preserve">
+--------------------+
| DomainData |
+--------------------+
| |<>----------[ Name ]
| |<>--(0..1)--[ DateDomainWasChecked ]
| ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ]
| ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ]
| |<>--(0..*)--[ Nameservers ]
| |<>--(0..*)--[ DNSRecord ]
| |<>--(0..*)--[ DomainContacts ]
+--------------------+
Figure 4.3 The DomainData element
</artwork>
</figure>
<section title="Name">
<t>REQUIRED. One value of iodef:MLStringType [RFC5070], Section
2.4]. The Name element is the domain name used in this event.</t>
</section>
<section title="DateDomainWasChecked">
<t>Zero or One value of DATETIME. This element includes the
timestamp of when this domain data was checked and entered into
this report as many phishers modify their domain data at various
stages of a phishing event.</t>
</section>
<section title="RegistrationDate element">
<t>Zero or one value of DATETIME. The RegistrationDate element
shows the date of registration for a domain.</t>
</section>
<section title="ExpirationDate element">
<t>Zero or one value of DATETIME. The ExpirationDate element shows
the date the domain will expire.</t>
</section>
<section title="Nameservers element">
<t>Zero or more values. These fields hold nameservers identified
for this domain. Each entry is a sequence of DNSNameType and
iodef:Address pairs as specified below.</t>
<t>The use of one Server value and one Address value, followed by
multiple empty Server values with Address values is allowable to
note multiple IPAddreses associated with one DNS entry for the
domain nameserver.</t>
<section title="Server element">
<t>Zero or more values of iodef:MLStringType. This field
contains the DNS name of the domain nameserver.</t>
</section>
<section title="iodef:Address element">
<t>REQUIRED. One Value of Address. This field contains the IP
address of the domain nameserver.</t>
</section>
</section>
<section title="DNSRecord element">
<t>Zero or more values. This element allows the reporter to
duplicate the DNS record data as defined by <xref
target="RFC1034" />, and returned by the DNS. Including this
information allows for tracking, trending, and identification of
the very transient DNS mapping and structure of crimeware
domains.</t>
<figure>
<artwork xml:space="preserve">
+----------------+
| DNSRecord |
+----------------+
| |<>--(1..1)--[ owner ]
| |<>--(1..1)--[ type ]
| |<>--(0..1)--[ class ]
| |<>--(0..1)--[ ttl ]
| |<>--(1..1)--[ rdata ]
+----------------+
Figure 4.4 The DomainContacts element</artwork>
</figure>
<section title="owner element">
<t>REQUIRED. One String Value. This element identifies the
superior node in the DNS hierarchy.</t>
</section>
<section title="type element">
<t>REQUIRED. One String Value. This field contains one value
from the IANA DNS Resource Record Type Registry.</t>
</section>
<section title="class element">
<t>Zero or one value of a STRING. This field contains one value
from the IANA DNS Domain System Class Registry. The value will
be the two character representation of class, instead of a
decimal number to ease data entry from standard DNS tools. The
default value for this field is "IN" to note the Internet.</t>
</section>
<section title="ttl element">
<t>Zero or one value of INTEGER. This value represents the
time-to-live (TTL) value for this record.</t>
</section>
<section title="rdata element">
<t>REQUIRED. One string value. The resource data for the record
is contained within this field.</t>
</section>
</section>
<section title="DomainContacts element">
<t>REQUIRED. Choice of either a SameDomainContact or one or more
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 using the SameDomainContact element.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+----------------+
| DomainContacts |
+----------------+
| |<>--(0..1)--[ SameDomainContact ]
| |<>--(1..*)--[ DomainContact ]
+----------------+
Figure 4.5 The DomainContacts element
</artwork>
</figure>
<section title="SameDomainContact">
<t>REQUIRED. One iodef: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.
Implementors are cautioned to only use this element when the
domain contact data returned by the registrar is identical.</t>
</section>
<section title="DomainContact Element">
<t>REQUIRED. One or more iodef:Contact elements. This element
reuses and extends the iodef:Contact elements for its
components. Each component may have zero or more values. If only
the role attribute and the ContactName component are populated,
the same (identical) information is listed for multiple
roles.</t>
<figure title="">
<artwork height="" name="" type="" width=""
xml:space="preserve">
+--------------------+
| 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.6: The DomainContact element
</artwork>
</figure>
<t />
<t>Each Contact has three attributes to capture the sensitivity,
confidence, and role for which the contact is listed.</t>
<section title="Role attribute">
<t>REQUIRED. ENUM. The role attribute is extended from the
iodef:role-ext attribute with values identified in <xref
target="CRISP" />. The role-ext value of the role attribute
should be used, with the role-ext attribute value chosen from
one of the following values:</t>
<t>
<list hangIndent="4" style="numbers">
<t>registrant. This identified Contact is the domain
registrant.</t>
<t>registrar. This contact identifies the registrar of
this domain.</t>
<t>billing. This entry is the billing or financial
contact.</t>
<t>technical. This contact deals with technical
issues.</t>
<t>administrative. This contact handles administrative
matters for this domain.</t>
<t>legal. This entry deals with legal issues for this
domain.</t>
<t>zone. This entry controls the DNS zone information.</t>
<t>abuse. This entry accepts abuse issues.</t>
<t>security. This entry accepts security issues.</t>
<t>domainOwner. This lists the owner of the domain.</t>
<t>ipAddressOwner. This entry identifies the assignee of
the IP address space.</t>
<t>hostingProvider. This contact is the hosting provider
of this domain.</t>
<t>other. This entry does not meet an enumerated
value.</t>
</list>
</t>
</section>
<section title="Confidence attribute">
<t>REQUIRED. ENUM. The Confidence attribute describes a
qualitative assessment of the veracity of the contact
information. This attribute is an extension to the
iodef:Contact element and is defined in this document. There
are five possible confidence values as follows.</t>
<t>
<list hangIndent="4" style="numbers">
<t>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.</t>
<t>looks-fraudulent. The contact information has
suspicious information included.</t>
<t>known-real. The contact information has been previously
investigated or determined to be correct.</t>
<t>looks-real. The contact information does not arouse
suspicion but has not been previously validated.</t>
<t>unknown. The reporter cannot make a value judgment on
the contact data.</t>
</list>
</t>
</section>
<section title="Restriction attribute">
<t>Zero or one iodef:restriction attribute [RFC5070, as part
of Section 3.2]. The restriction attribute is used to label
the sensitivity of included information.</t>
</section>
</section>
</section>
</section>
<section title="SystemStatus attribute">
<t>REQUIRED. ENUM. The SystemStatus attribute assesses a domain's
involvement in this event.</t>
<t>
<list style="numbers">
<t>spoofed. This domain or system did not participate in this
event, but its address space or DNS name was forged.</t>
<t>fraudulent. The system is fraudulently operated.</t>
<t>innocent-hacked. The system was compromised and used in this
event to source the lure.</t>
<t>innocent-hijacked. The IP Address or domain name was hijacked
and used in this event to source of the lure.</t>
<t>unknown. No conclusions are inferred from this event.</t>
</list>
</t>
</section>
<section title="DomainStatus attribute">
<t>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<xref target="RFC4933" /> and "Domain Registry
Version 2 for the Internet Registry Information Service"
internet-draft <xref target="CRISP" />.</t>
<t>
<list style="numbers">
<t>reservedDelegation - permanently inactive</t>
<t>assignedAndActive - normal state</t>
<t>assignedAndInactive - registration assigned but delegation
inactive</t>
<t>assignedAndOnHold - dispute</t>
<t>revoked - database purge pending</t>
<t>transferPending - change of authority pending</t>
<t>registryLock - on hold by registry</t>
<t>registrarLock - on hold by registrar</t>
</list>
</t>
</section>
<section title="IncludedMalware element">
<t>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.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+------------------+
| IncludedMalware |
+------------------+
| |<>--(1..*)--[ Name ]
| |<>--(0..1)--[ Hashvalue ]
| |<>--(0..1)--[ Data ]
+------------------+
+-----------------+
| Hashvalue |
+-----------------+
| ENUM Algorithm |
| |
| STRING |
+-----------------+
+---------------------+
| Data |
+---------------------+
| STRING XORPattern |<>--(0..1)-+-[ StringData ]
| | +-[ BinaryData ]
+---------------------+
Figure 4.7: The Included Malware element
</artwork>
</figure>
<section title="Name element">
<t>REQUIRED. One or more value of iodef:MLStringType. This
optional field is used to identify the lure malware.</t>
</section>
<section title="Hashvalue element">
<t>Zero or one value of STRING. This optional field is used to
hold the value of a hash computed over the malware executable.</t>
<section title="Algorithm attribute">
<t>REQUIRED ENUM. This field from the following list identifies
the algorithm used to create this hashvalue.</t>
<t>SHA1. Hashvalue as defined in<xref target="SHA" />.</t>
</section>
</section>
<section title="Data element">
<t>Zero or one value. Choice of two elements, below. The optional
Data element is used to describe the lure malware.</t>
<section title="StringData element">
<t>The lure malware is encoded as a String value.</t>
</section>
<section title="BinaryData element">
<t>The lure malware is encoded as a hexBinary encoded value, as
defined by the XML standard.</t>
</section>
<section title="XORPattern attribute">
<t>Zero or One value of 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.</t>
</section>
</section>
</section>
<section title="FilesDownloaded element">
<t>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.</t>
</section>
<section title="RegistryKeysModified element">
<t>One value of the Keys sequence.</t>
<t>The contents of the RegistryKeysModified element are sets of Key
elements.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+-----------------------+
| RegistryKeysModified |
+-----------------------+
| |<>--(1..*)--[ Key ]
+-----------------------+
+--------------+
| Key |
+--------------+
| |<>-----[ Name ]
| |<>-----[ Value ]
+--------------+
Figure 4.8: The RegistryKeysModified element
</artwork>
</figure>
<section title="Key element">
<t>One or more Sequences. The key element is a sequence of Name
and Value pairs representing an operating system registry key and
its value</t>
<section title="Name element">
<t>One STRING, representing the WINDOWS Operating System
Registry Key Name.</t>
</section>
<section title="Value element">
<t>One STRING, representing the value of the associated Key</t>
</section>
</section>
</section>
</section>
<section title="OriginatingSensor Element" toc="default">
<t>REQUIRED. The OriginatingSensor element contains the identification
and cognizant data of the network element that detected this fraud
activity. Note that the network element does not have to be on the
Internet itself (i.e., it may be a local IDS system) nor is it
required to be mechanical (e.g., humans are allowed).</t>
<t>Multiple OriginatingSensor Elements are allowed to support
detection at mutiple locations.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+---------------------+
| OriginatingSensor |
+---------------------+
| ENUM OrigSensorType |<>------------[ DateFirstSeen ]
| |<>---(1..*)---[ iodef:System ]
+---------------------+
Figure 4.9: The OriginatingSensor element
</artwork>
</figure>
<t>The OriginatingSensor requires a type value and identification of
the entity that detected this fraudulent event.</t>
<section title="OrigSensorType attribute">
<t>REQUIRED. ENUM. The value is chosen from the following list,
categorizing the function of this sensor:<list hangIndent="4"
style="empty">
<t>1. Web. A web server or service detected this event.</t>
<t>2. WebGateway. A proxy, firewall, or other network gateway
detected this event.</t>
<t>3. MailGateway. The event was detected via a mail gateway or
filter</t>
<t>4. Browser. The event was detected at the user web interface
or browser-type element..</t>
<t>5. ISPsensor. The event was detected by an automated system
in the network such as IDS, IPS, or ISP device.</t>
<t>6. Human. A non-automated system (e.g., a human, manual
analysis, etc) detected this event.</t>
<t>7. Honeypot. The event was detected by receipt at a decoy
device.</t>
<t>8. Other. The detection was performed via a non-listed
method.</t>
</list></t>
</section>
<section title="DateFirstSeen element">
<t>
<list hangIndent="4" style="empty">
<t>REQUIRED. DATETIME. This is the date and time that this
sensor first saw this phishing activity.</t>
</list>
</t>
</section>
<section title="iodef:System element">
<t>
<list hangIndent="4" style="empty">
<t>REQUIRED. One iodef:System. This is the IPVersion, IPAddress,
and optionally, port number of the entity that generated this
report.</t>
</list>
</t>
</section>
</section>
<section title="The DCSite element">
<t>Zero or more DCSite elements. The DCSite 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 four
elements: the type of collector site, the network location,
information about its DNS Domain, and a confidence factor. Further
details about the domain, system, or owner of the DCSite can be
inserted into the DomainData sub-element.</t>
<t>If the DCSite element is present, a value is required. Multiple
DCSite elements are allowed to indicate multiple collection sites for
a single collector. Multiple URLs pointing to the same DNS entry can
be identified with multiple SiteURL elements.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+--------------+
| DCSite |
+--------------+
| ENUM DCSite |<>--+--------[ SiteURL ]
| | +--------[ Domain ]
| | +--------[ EmailSite ]
| | +--------[ System ]
| | +--------[ Unknown ]
| |<>--(0..1)---[ DomainData ]
| |<>--(0..1)---[ iodef:Assessment ]
+--------------+
Figure 4.10: The DCSite element
</artwork>
</figure>
<section title="DCType attribute">
<t>REQUIRED. ENUM. The DCType attribute identifies the method of
data collection as determined through the analysis of the victim
computer, lure, or malware. This attribute coupled with the DCSite
content identifies the data collection site.</t>
<t>
<list hangIndent="4" style="numbers">
<t>web. The user is redirected to a website to collect the
data.</t>
<t>email. The victim sends an email with credentials
enclosed.</t>
<t>keylogger. Some form of keylogger is downloaded to the
victim.</t>
<t>automation. Other forms of automatic data collection, such as
background OLE automation, are used to capture information.</t>
<t>unspecified.</t>
</list>
</t>
</section>
<section title="DCSite values">
<t>REQUIRED. The DCSite element contains the IPAddress, URL,
emailsite, or other identifier of the data collection site. The
Domain choice may be used to identify entire 'phishy' domains like
those used for the RockPhish and related malware. Each DCSite
element also includes a confidence element to convey the reporter's
assessment of their confidence that this DCSite element is valid,
and involved with this event. The confidence value is a per-DCSite
value as multiple-site data collectors may have different confidence
values.</t>
<t>The DCSite element is a choice of:</t>
<t>
<list hangIndent="4" style="numbers">
<t>SiteURL. STRING. This choice supports URIs.</t>
<t>Domain. STRING. This choice allows the entry of a DNS Domain
name.</t>
<t>EmailSite. STRING. This choice captures either the email
address of the data collection site.</t>
<t>iodef:System element [RFC5070, Section 3.15]. This choice is
filled it to capture the IP Address of a site.</t>
<t>Unknown. STRING. The unknown entry is used for exception to
the preceding choices.</t>
</list>
</t>
<section title="DomainData element">
<t>Zero or One value of DomainData. This element allows for the
identification of data associated with the data collection
site.</t>
</section>
<section title="iodef:Assessment element">
<t>Zero or One value of iodef:Assessment. This element is used to
designate different confidence levels of multiple-site data
collectors.</t>
</section>
</section>
</section>
<section title="TakeDownInfo element" toc="default">
<t>Zero or more TakeDownInfo element. This element identifies the
agent or agency that performed the removal, DNS domain disablement, or
ISP-blockage of the phish or fraud collector site. A PhraudReport may
have multiple TakeDownInfo elements to support activities where
multiple take down activities are involved on different dates. Note
that the term "Agency" is used to identify any party performing the
blocking or removal such as ISPs or private parties, not just
government entities.</t>
<t>The TakeDownInfo element allows one date element with multiple
TakeDownAgency and Comment elements to support operations using
multiple agencies.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+-------------------+
| TakeDownInfo |
+-------------------+
| |<>---(0..1)--[ TakeDownDate ]
| |<>---(0..*)--[ TakeDownAgency ]
| |<>---(0..*)--[ TakeDownComments ]
+-------------------+
Figure 4.11: The TakeDownInfo element
</artwork>
</figure>
<section title="TakeDownDate">
<t>Zero or one DATETIME. This is the date and time that take down of
the collector site occurred.</t>
</section>
<section title="TakeDownAgency">
<t>Zero or more STRING. This is a free form string identifying the
agency, corporation, or cooperative that performed the take
down.</t>
</section>
<section title="TakeDownComments">
<t>Zero or more STRING. A free form field to add any additional
details of this take down effort or to identify parties that
assisted in the effort at an ISP, CERT, or DNS Registry.</t>
</section>
</section>
<section title="ArchivedData element" toc="default">
<t>Zero or more values of the ArchivedData element are allowed.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+-------------------+
| ArchivedData |
+-------------------+
| ENUM type |<>---(0..1)--[ ArchivedDataURL ]
| |<>---(0..1)--[ ArchivedDataComments ]
| |<>---(0..1)--[ ArchivedData ]
+-------------------+
Figure 4.12: The ArchivedData element
</artwork>
</figure>
<t>The ArchivedData element is populated with a pointer to the
contents of a data collection site, base camp (i.e., development
site), or other site used by a phisher. The ArchivedDataInfo may also
include a copy of the archived data recovered from a phishing system.
This element will be populated when, for example, an ISP takes down a
phisher's web site and has copied the site data into an archive
file.</t>
<t>There are four types of archives currently supported, as specified
in the type field.</t>
<section title="type attribute">
<t>REQUIRED. This parameter specifies the type of site data pointed
to by the ArchivedDataURL, from the following list:<list
hangIndent="4" style="numbers">
<t>collectionsite.</t>
<t>basecamp.</t>
<t>sendersite.</t>
<t>credentialInfo.</t>
<t>unspecified.</t>
</list></t>
</section>
<section title="ArchivedDataURL element">
<t>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 report. This is
the URL where the gzipped archive file is located.</t>
</section>
<section title="ArchivedDataComments element">
<t>Zero or one value of STRING. This field is a free form area for
comments on the archive and/or URL.</t>
</section>
<section title="ArchivedData element">
<t>Zero or one value of xs:Base64Binary. This field may contain a
base64 encoded version of the data described in the comment field
above.</t>
</section>
</section>
<section title="RelatedData element" toc="default">
<t>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.).</t>
</section>
<section title="CorrelationData element" toc="default">
<t>Zero or more value of STRING. Any information that correlates this
incident to other incidents can be entered here.</t>
</section>
<section title="PRComments element" toc="default">
<t>Zero or one value of STRING. This field allows for any comments
specific to this PhraudReport that does not fit in any other
field.</t>
</section>
<section title="EmailRecord element" toc="default">
<t>Extensions are also made to the iodef:Incident.EventData element 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 <xref target="ARF" />.</t>
<t>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.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
+--------------------+
| EmailRecord |
+--------------------+
| |<>--------------[ EmailCount ]
| |<>--(0..1)--+---[ Email ]
| | +---[ Message ]
| | +---[ ARFText ]
| |<>--(0..1)------[ EmailComments ]
+--------------------+
+---------------+
| Email |
+---------------+
| |<>---+----------[ EmailHeader ]
| |<>--(0..1)------[ EmailBody ]
+---------------+
+-------------+
| EmailHeader |
+-------------+
| |<>--(1..*)--[ Header ]
+-------------+
Figure 4.13: The EmailRecord element
</artwork>
</figure>
<section title="EmailCount">
<t>REQUIRED. INTEGER. This field enumerates the number of email
messages identified in this record detected by the reporter.</t>
</section>
<section title="Email Message Inclusion">
<t>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.</t>
<section title="Message">
<t>Zero of one value of iodef:MLStringType. The entire mail
message can be inserted as one large string.</t>
</section>
<section title="ARFText ">
<t>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
<xref target="ARF" /> may be inserted into this element.</t>
<t>The ARF should be encoded as a character string.</t>
</section>
<section title="Email element">
<t />
<section title="EmailHeader Element">
<t>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.</t>
<section title="Header">
<t>iodef:MLStringType. The header element contains a sequence
of email header lines, one line per header element.</t>
</section>
</section>
<section title="EmailBody Element">
<t>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</t>
</section>
</section>
<section title="Message">
<t>iodef:MLStringType. The entire mail message can be inserted as
one large string.</t>
</section>
</section>
<section title="EmailComments Element">
<t>Zero or one value of STRING. This field contains comments or
relevant data not placed elsewhere about the phishing or spam
email.</t>
</section>
</section>
</section>
<section title="IODEF Required Elements" toc="default">
<t>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.</t>
<t>The following table is a visual description of the IODEF-Document
required fields.</t>
<section title="Fraud or Phishing Report">
<t>A compliant IODEF PhraudReport is SHALL contain the following
element and attributes:</t>
<t>
<list>
<t><iodef:Incident></t>
</list>
<list hangIndent="8">
<t><iodef:incident/@purpose></t>
<t><iodef:IncidentID></t>
<t><iodef:ReportTime></t>
<t><iodef:Assessment/iodef:Confidence></t>
<t><iodef:Contact/@Role></t>
<t><iodef:Contact/@Type></t>
<t><iodef:Contact/iodef:Name></t>
<t><iodef:EventData></t>
</list>
<list hangIndent="12">
<t><iodef:DetectTime></t>
<t><iodef:AdditionalData></t>
</list>
<list hangIndent="16">
<t><PhraudReport></t>
</list>
<list counter="" hangIndent="20">
<t><PhraudReport/@Version></t>
<t><PhraudReport/@FraudType></t>
<t><FraudedBrandName></t>
<t><LureSource></t>
<t><OriginatingSensor></t>
</list>
</t>
</section>
<section title=" Wide-Spread Spam Report">
<t>An IODEF PhraudReport compliant Spam Activity Report SHALL contain
the following elements and attributes:</t>
<t>
<list>
<t><iodef:Incdent></t>
</list>
<list hangIndent="8">
<t><iodef:Incident/@purpose></t>
<t><iodef:IncidentID></t>
<t><iodef:ReportTime></t>
<t><iodef:Assessment/iodef:Confidence></t>
<t><iodef:Contact/@Role></t>
<t><iodef:Contact/@Type></t>
<t><iodef:Contact/iodef:Name></t>
<t><iodef:EventData></t>
</list>
<list hangIndent="12">
<t><iodef:DetectTime></t>
<t><iodef:AdditionalData></t>
</list>
<list hangIndent="16">
<t><PhraudReport></t>
</list>
<list counter="" hangIndent="20">
<t><PhraudReport/@Version></t>
<t><PhraudReport/@FraudType> = spamreport</t>
<t><LureSource></t>
<t><OriginatingSensor></t>
<t><EmailRecord></t>
</list>
</t>
</section>
<section title="Guidance on Usage" toc="default">
<t>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.</t>
<t>The reporting party is advised to supply as much information abut
the event as possible -- or even more -- as the information may be
volatile and not recoverable in the future to answer investigation
questions or to perform correlation with other events.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document specifies a format for encoding a particular class of
security incidents appropriate for exchange across organizations. As
merely a data representation, it does not directly introduce security
issues. However, it is guaranteed that parties exchanging instances of
this specification will have certain concerns. For this reason, the
underlying message format and transport protocol used MUST ensure the
appropriate degree of confidentiality, integrity, and authenticity for
the specific environment.</t>
<t>Organizations that exchange data using this document are URGED to
develop operating procedures that document the following areas of
concern.</t>
<section title="Transport-specific concerns">
<t>The critical security concerns are that phishing activity reports
may be falsified or the PhraudReport may become corrupt during
transit. In areas where transmission security or secrecy is
questionable, the application of a digital signature and/or message
encryption on each report will counteract both of these concerns. We
expect that each exchanging organization will determine the need, and
mechanism, for transport protection..</t>
</section>
<section title="Using the iodef:restriction attribute">
<t>In some instances data values in particular elements may contain
data deemed sensitive by the reporter. Although there are no
general-purpose rules on when to mark certain values as "private" or
"need-to-know" via the iodef:restriction attribute, the reporter is
cautioned to not apply element-level sensitivity markings unless they
believe the receiving party (i.e., the party they are exchanging the
event report data with) has a mechanism to adequately safeguard and
process the data as marked. For example, if the PhraudReport element
is marked private and contains a phishing collector URL in the
DCSite/SiteURL element, can that URL be included within a block list
distributed to other parties? No guidance is provided here except to
urge exchanging parties to review the IODEF and PhraudReport documents
to decide on common marking rules.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in <xref
target="RFC3688" /></t>
<t>Registration request for the IODEF phishing namespace:<list
hangIndent="4">
<t>URI: urn:ietf:params:xml:ns:iodef-phish-1.0</t>
<t>Registrant Contact: See the "Author's Address" section of this
document.</t>
<t>XML: None.</t>
</list></t>
<t>Registration request for the IODEF phishing extension XML schema:
<list hangIndent="4">
<t>URI: urn:ietf:params:xml:schema:iodef-phish-1.0</t>
<t>Registrant Contact: See the "Author's Address" section of this
document.</t>
<t>XML: See the "Phishing Extensions Schema Definition" in the <eref
target="Appendix A" /> section of this document.</t>
</list></t>
</section>
<section title="Contributors" toc="default">
<t>The extensions are an outgrowth of the Anti-Phishing Working Group
(APWG) activities in data collection and sharing of phishing and other
ecrime-ware.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC5070">
<front>
<title>The Incident Object Description Exchange Format</title>
<author fullname="R. Danyliw" initials="R." surname="Danyliw">
<organization />
</author>
<author fullname="J. Meijer" initials="J." surname="Meijer">
<organization />
</author>
<author fullname="Y. Demchenko" initials="Y." surname="Demchenko">
<organization />
</author>
<date month="December" year="2007" />
<abstract>
<t>The Incident Object Description Exchange Format (IODEF) defines
a data representation that provides a framework for sharing
information commonly exchanged by Computer Security Incident
Response Teams (CSIRTs) about computer security incidents. This
document describes the information model for the IODEF and
provides an associated data model specified with XML Schema.
[STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5070" />
<format octets="171529"
target="ftp://ftp.isi.edu/in-notes/rfc5070.txt" type="TXT" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"
type="TXT" />
<format octets="14486"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
</reference>
<reference anchor="SHA">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>National Institute of Standards and Technology, U.S.
Department of Commerce</organization>
</author>
<date month="May" year="1994" />
</front>
<seriesInfo name="FIPS" value="180-1" />
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname=" Mealling, M." initials="M" surname="Mealing">
<organization />
</author>
<date month="January" year="2004" />
</front>
<seriesInfo name="RFC" value="3688" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC1034">
<front>
<title abbrev="Domain Concepts and Facilities">Domain names -
concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P."
surname="Mockapetris">
<organization>Information Sciences Institute (ISI)</organization>
</author>
<date day="1" month="November" year="1987" />
</front>
<seriesInfo name="STD" value="13" />
<seriesInfo name="RFC" value="1034" />
<format octets="129180"
target="ftp://ftp.isi.edu/in-notes/rfc1034.txt" type="TXT" />
</reference>
<reference anchor="RFC4933">
<front>
<title>Extensible Provisioning Protocol (EPP) Contact
Mapping</title>
<author fullname="S. Hollenbeck" initials="S." surname="Hollenbeck">
<organization />
</author>
<date month="May" year="2007" />
<abstract>
<t>This document describes an Extensible Provisioning Protocol
(EPP) mapping for the provisioning and management of individual or
organizational social information identifiers (known as
"contacts") stored in a shared central repository. Specified in
Extensible Markup Language (XML), the mapping defines EPP command
syntax and semantics as applied to contacts. This document
obsoletes RFC 3733. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4933" />
<format octets="82254" target="ftp://ftp.isi.edu/in-notes/rfc4933.txt"
type="TXT" />
</reference>
<reference anchor="CRISP">
<front>
<title>Domain Registry Version 2 for the Internet Registry
Information Service</title>
<author fullname="Andrew" initials="L" surname="Newton">
<organization />
</author>
<author fullname="Frederico" initials="A. C." surname="Neves">
<organization />
</author>
<date day="" month="January" year="2005" />
</front>
<seriesInfo name="RFC" value="3982" />
</reference>
<reference anchor="ARF">
<front>
<title>Abuse Reporting Format</title>
<author>
<organization>The Messaging Anti-Abuse Working Group
(MAAWG)</organization>
</author>
<date month="May" year="2005" />
</front>
<format target="http://mipassoc.org/arf/draft-shafranovich-feedback-report-01.txt"
type="txt" />
</reference>
</references>
<section anchor="AppendixA"
title="Appendix A. Phishing Extensions XML Schema">
<t />
<figure>
<artwork height="" name="" type="" xml:space="preserve">
<?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#">
<!--
==========================================================
=== Top Level Class: PhraudReport ===
==========================================================
It is incorporated within an
IODEF.Incident.EventData.AdditionalData element.
All the top-level or major elements are defined as xs:types to make
future extension easier.
-->
<xs:element name="PhraudReport">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="PhishNameRef" type="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"/>
<xs:element name="LureSource" maxOccurs="unbounded" minOccurs="1"
type="phish:LureSource.type" />
<xs:element name="OriginatingSensor" maxOccurs="unbounded"
minOccurs="1" type="phish:OriginatingSensor.type" />
<xs:element name="EmailRecord" maxOccurs="1" minOccurs="0"
type="phish:EmailRecord.type"/>
<xs:element name="DCSite" maxOccurs="unbounded" minOccurs="0"
type="phish:DCSite.type"/>
<xs:element name="TakeDownInfo" minOccurs="0"
maxOccurs="unbounded" type="phish:TakeDownInfo.type"/>
<xs:element name="ArchivedData" minOccurs="0"
maxOccurs="unbounded" type="phish:ArchivedData.type"/>
<xs:element name="RelatedData" maxOccurs="unbounded"
minOccurs="0" type="xs:anyURI"/>
<xs:element minOccurs="0" name="CorrelationData"
type="xs:string" maxOccurs="unbounded"/>
<xs:element maxOccurs="1" minOccurs="0" name="PRComments"
type="xs:string"/>
</xs:sequence>
<xs:attribute default="1.0" name="Version" use="optional"/>
<xs:attribute name="FraudType" type="phish:FraudType.type"
use="required"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="FraudType.type" >
<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>
<!--
==========================================================
=== End of the Top-Level Element ===
==========================================================
-->
<!--
==========================================================
=== The Lure Source Element ===
==========================================================
-->
<xs:complexType name="LureSource.type" mixed="false">
<xs:sequence>
<xs:element maxOccurs="unbounded"
minOccurs="1" ref="iodef:System"/>
<xs:element minOccurs="0" ref="phish:DomainData"/>
<xs:element name="IncludedMalware" minOccurs="0"
type="phish:IncludedMalware.type"/>
<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="unbounded" name="Key">
<xs:complexType>
<xs:sequence>
<xs:element name="Name"/>
<xs:element name="Value"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
=== LureSource sub-elements ===
-->
<xs:complexType name="IncludedMalware.type" >
<xs:sequence>
<xs:element name="Name" type="iodef:MLStringType" />
<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>
<!--
==========================================================
== The EmailRecord Element ===
==========================================================
-->
<xs:complexType name="EmailRecord.type" >
<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="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" maxOccurs="1" />
<xs:element minOccurs="0" name="ARFText"
type="xs:string" maxOccurs="1" />
</xs:choice>
<xs:element maxOccurs="1" minOccurs="0" name="EmailComments"
type="xs:string"/>
</xs:sequence>
</xs:complexType>
<!--
===========================================================
=== The Data Collection Site (DCSite) Info Element ===
===========================================================
-->
<xs:complexType name="DCSite.type" >
<xs:sequence>
<xs:choice>
<xs:element name="SiteURL">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="confidence" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Domain">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="confidence" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="EmailSite">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="confidence" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element ref="phish:System"/>
<xs:element name="Unknown">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="confidence" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:choice>
<xs:element minOccurs="0" ref="phish:DomainData"/>
<xs:element minOccurs="0" ref="iodef:Assessment"/>
</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>
<!--
=== DCSite sub-elements ===
-->
<!-- Redefine iodef:System to include a confidence value -->
<xs:element name="System">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Node"/>
<xs:element ref="iodef:Service"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:OperatingSystem"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<xs:attribute name="interface" type="xs:string"/>
<xs:attribute name="category">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="source"/>
<xs:enumeration value="target"/>
<xs:enumeration value="intermediate"/>
<xs:enumeration value="sensor"/>
<xs:enumeration value="infrastructure"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<xs:attribute name="spoofed" default="unknown">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="unknown"/>
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="confidence" type="xs:string"/>
</xs:complexType>
</xs:element>
<xs:element name="DomainData">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="1" name="Name" type="iodef:MLStringType"/>
<xs:element minOccurs="0" name="DateDomainWasChecked"
maxOccurs="1" type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="RegistrationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="0" name="Nameserver">
<xs:complexType>
<xs:sequence>
<xs:element name="Server" type="iodef:MLStringType"/>
<xs:element ref="iodef:Address"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DNSRecord" maxOccurs="unbounded" minOccurs="0"
type="phish:DNSRecord.type"/>
<xs:choice id="DomainContacts" minOccurs="0" maxOccurs="1" >
<xs:element name="SameDomainContact" type="iodef:MLStringType"/>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
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>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="DomainContact" type="phish:DomainContact.type"/>
<!--
<xs:redefine schemaLocation="urn:ietf:params:xml:ns:iodef-1.0" >
<xs:element name="iodef:Contact"> -->
<xs:complexType name="DomainContact.type" >
<xs:sequence>
<xs:element ref="iodef:ContactName" minOccurs="0"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:RegistryHandle"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:PostalAddress" minOccurs="0"/>
<xs:element ref="iodef:Email" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Telephone"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Fax" minOccurs="0"/>
<xs:element ref="iodef:Timezone" minOccurs="0"/>
<xs:element ref="iodef:Contact"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="role" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="creator"/>
<xs:enumeration value="admin"/>
<xs:enumeration value="tech"/>
<xs:enumeration value="irt"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="ext-value"/>
<!-- Identified by phish extensions -->
<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="ext-role" type="xs:string" use="optional"/>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="person"/>
<xs:enumeration value="organization"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type" type="xs:string" use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
<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:complexType>
<!--
=================================================================
=== DNS Record types ===
=================================================================
- The format of this field is from RFC1035
- The allowed 'type' values are from the
IANA registered DNS Resource Record.
-->
<xs:complexType name="DNSRecord.type">
<xs:sequence>
<xs:element name="owner" type="xs:string"/>
<xs:element name="type" type="xs:string"/>
<xs:element name="class" type="xs:string" default="IN"/>
<xs:element name="ttl" type="xs:integer" minOccurs="0"/>
<xs:element name="rdata" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<!--
===================================================================
=== The Originating Sensor Data Element ===
===================================================================
-->
<xs:complexType name="OriginatingSensor.type" >
<xs:sequence>
<xs:element name="DateFirstSeen" type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="1" ref="iodef:System"/>
</xs:sequence>
<xs:attribute name="OriginatingSensorType" use="required">
<xs:simpleType>
<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>
<!--
===================================================
=== The Take Down Data structure. ===
===================================================
-->
<xs:complexType name="TakeDownInfo.type" >
<xs:sequence>
<xs:element name="TakeDownDate" type="xs:dateTime"
minOccurs="0" maxOccurs="1" />
<xs:element name="TakeDownAgency" type="xs:string"
maxOccurs="unbounded" minOccurs="0" />
<xs:element name="TakeDownComments" type="xs:string"
maxOccurs="unbounded" minOccurs="0" />
</xs:sequence>
</xs:complexType>
<!--
====================================================
=== The Archived Data Element ===
====================================================
-->
<xs:complexType name="ArchivedData.type" >
<xs:sequence>
<xs:element name="ArchivedDataURL" type="xs:anyURI" minOccurs="0"/>
<xs:element name="ArchivedDataComments" type="xs:string"
minOccurs="0" />
<xs:element name="ArchivedData" type="xs:base64Binary"
minOccurs="0" maxOccurs="1"/>
</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="credentialInfo"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:schema>
</artwork>
</figure>
</section>
<section title="Example Virus Report">
<t>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.</t>
<section title="Received Email">
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
From: support@example.com
Sent: Friday, June 10, 2005 3:52 PM
To: pcain@example.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.example.com </artwork>
</figure>
</section>
<section title="Generated Report">
<t>NOTE: Some wrapping and folding liberties have been applied to fit
it into the margins.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve">
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document lang="en-US" xmlns:ns="http://www.w3.org/1999/xhtml"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0" >
<Incident ext-purpose="create">
<IncidentID name="example.com">PAT2005-06</IncidentID>
<ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
<Description>This is a test report from actual data.
</Description>
<Assessment>
<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">
<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>192.0.2.18</Address>
</Node>
</System>
<phish:IncludedMalware>
<phish:Name>W32.Mytob.EA@mm</phish:Name>
</phish:IncludedMalware>
</phish:LureSource>
<phish:OriginatingSensor OriginatingSensorType="human">
<phish:DateFirstSeen>2005-06-10T15:52:11-05:00
</phish:DateFirstSeen>
<System>
<Node>
<Address>192.0.2.18</Address>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:Message>
"Return-path: <support@coopercain.com>"
Envelope-to: pcain@example.com Delivery-date: Fri, 10 Jun 2005
15:52:11-0400 Received: from dsl231-063-162.sea1.dsl.example.net
([192.0.2.18] helo=example.com) by mail06.example.com
with esmtp (Exim) id 1DgpXy-0002Ua-IR for pcain@example.com;
Fri, 10 Jun 2005 15:52:10-0400 From: support@example.com To:
pcain@example.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;
boundary="----=_NextPart_000_0008_0911068B.E7EB6D2A" X-Priority: 3
X-MSMail-Priority: Normal X-EN-OrigIP: 192.0.2.18
X-EN-OrigHost: dsl231-063-162.sea1.dsl.example.net
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on
Scan18.example.net X-Spam-Level: ***** X-Spam-Status: No,
score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30,
HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE,NO_REAL_NAME,
PRIORITY_NO_NAME autolearn=disabled version=3.0.2 From:
support@example.com Sent: Friday, June 10, 2005 3:52 PM
To:pcain@example.com Subject: You have successfully updated
your password Attachments: updated-password.zip
Dear user pcain,
You have successfully updated the password of your example
account. If you did not authorize this change or if you need
assistance with your account, please contact example customer
service at: support@example.com Thank you for using example!
The Example Support Team +++ Attachment: No Virus (Clean) +++
example Antivirus - www.example.com
</phish:Message>
</phish:EmailRecord>
</phish:PhraudReport></AdditionalData>
</EventData>
</Incident>
</IODEF-Document></artwork>
</figure>
</section>
</section>
<section title="Sample Phishing Report" toc="include">
<t>A sample report generated from a received electronic mail phishing
message in shown in this section.</t>
<section title="Received Lure">
<figure>
<preamble />
<artwork height="" name="" type="" width="" xml:space="preserve">
Return-path: <service@company.com>
Envelope-to: pcain@example.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@example.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@example.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: "company"<service@company.com>
Subject: * * * Update & Verify Your Company Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@company.com
X-EN-OrigIP: 192.0.2.1
X-EN-OrigHost: unknown
Company<http://www.company.com/images/company_logo.gif>
<http://www.company.com/images/pixel.gif>
<http://www.company.com/images/pixel.gif>
<http://www.company.com/images/pixel.gif>
Account Update Request
Dear Company. member:,
You are receiving this notification because company is required by
law to notify you, that you urgently need to update your online
account statement, due to high risks of fraud intentions.
The updating of your company account can be done at any time by
clicking on the link shown below
http://www.company.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 company website. To report errors in
your statement or make inquiries, click the Contact Us link in the
footer on any page of the company website, call our Customer Service
center at (401) 938-3600, or write us at:
Company, Inc.
P.O. Box 0
Anytown, MA 98765
Sincerely,
Big Company
<http://www.company.com/images/dot_row_long.gif>
</artwork>
</figure>
</section>
<section title="Phishing Report">
<t />
<figure>
<artwork height="" name="" type="" width="" xml:space="preserve">
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:ns="http://www.w3.org/1999/xhtml"
xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" lang="">
<Incident purpose="mitigation" ext-purpose="create"
restriction="private">
<IncidentID name="example.com">CC200600000002</IncidentID>
<ReportTime>2006-06-13T21:14:56-05:00</ReportTime>
<Description>This is a sample phishing email received report.
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@example.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 Company Account * * *
</phish:FraudParameter>
<phish:FraudedBrandName>company</phish:FraudedBrandName>
<phish:LureSource>
<System category="source">
<Node>
<Address>192.0.2.2</Address>
</Node>
</System>
</phish:LureSource>
<phish:OriginatingSensor
OriginatingSensorType="mailgateway">
<phish:DateFirstSeen>
2006-06-13T05:37:22-04:00</phish:DateFirstSeen>
<System>
<Node>
<NodeRole category="mail"></NodeRole>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:Message>Return-path: <service@company.com>
Envelope-to: pcain@example.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.example.com ([10.1.1.161]
helo=mail15.example.com) by mailscan38.example.com
with esmtp (Exim) id 1Fq5Kr-0005wU-LT for pcain@example.com;
Tue, 13 Jun 2006 05:37:21 -0400
Received: from [192.0.2.2] (helo=bob) by mail15.example.com
with esmtp (Exim) id 1Fq5Bj-0006dv-6b for pcain@coopercai
n.com; Tue, 13 Jun 2006 05:37:21 -0400
Received: from User ([192.0.2.4]) by Bob with Microsoft SMTPSV
C(5.0.2195.6713); Tue, 13 Jun 2006 02:24:30 -0400 Reply-To: <no
spa@nospa.us>
From: "company"<service@company.com>
Subject: * * * Update & Verify Your company Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1 X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC) FILETIME=[07
2A66A0:01C68EB2]
X-EN-OrigSender: service@company.com X-EN-OrigIP: 192.0.2.4
X-EN-OrigHost: unknown company<http://www.company.com/images/company
_logo.gif> <http://www.company.com/images/pixel.gif> <htt
p://www.company.com/images/pixel.gif> <http://www.company.com/im
ages/pixel.gif> Account Update Request Dear company. member:, You
are receiving this notification because company 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 company account can be done at any time by click
ing on the link shown below http://www.company.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 company website. To report
errors in your statement or make inquiries, click the Contact Us lin
k in the footer on any page of the company website, call our Customer
Service center at (402) 938-3630, or write us at: company, Inc. P.O.
Box 45950 Omaha, NE 68145 Sincerely, company <http://www.company.c
om/images/dot_row_long.gif></phish:Message>
</phish:EmailRecord>
<phish:DCSite DCType="web">
<phish:SiteURL>
http://217.136.251.41:8080/.cgi-bin/.webscr/.secure-
login/%20%20/.company.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.example.net</phish:Server>
<Address>192.0.2.18</Address>
</phish:Nameserver>
</phish:DomainData>
</phish:DCSite>
</phish:PhraudReport></AdditionalData>
</EventData>
</Incident>
</IODEF-Document></artwork>
</figure>
<t />
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 03:12:54 |