One document matched: draft-cain-post-inch-phishingextns-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?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-07"
ipr="trust200902" obsoletes="" updates="">
<front>
<title abbrev="IODEF Phishing Extensions">Extensions to the IODEF-Document
Class for Reporting Phishing</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="23" month="November" year="2009" />
<area>Security</area>
<keyword>RFC</keyword>
<keyword>Request For Comments</keyword>
<abstract>
<t>This document extends the Incident Object Description Exchange Format
(IODEF) defined in RFC5070 to support the reporting of phishing events, which is a particular type of fraud. These
extensions are flexible enough to support information gleaned from
activities throughout the entire electronic fraud cycle - from receipt of the phishing lure to the disablement of the collection site. Both
simple reporting and complete forensic reporting are possible, as is
consolidating multiple incidents .</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"></xref> that
can be used to describe information about a phishing or other type of
fraudulent incident. Sections 2 of this document provide an overview of
the terminology and process of a phishing event. Section3 introduces the
high-level report format and how to use it. Sections 4 and 5 describe
the data elements of the fraud extensions. The appendices includes an
XML schema for the extensions and a few example fraud reports.</t>
<t>The extensions defined in this document may be used to report the
social engineering victim lure, the collections site, and credential
targeted ('spear') phishing, broad multi-recipient phishing, and other
evolving Internet-based fraud attempts. Malware and other malicious
software included within the lure may also be included within the report</t>
<section title="Why a Common Report Format is Needed">
<t>To combat the rise in malicious activity on the Internet, service
providers and investigative agencies are sharing more and more network
and event data in a coordinated effort to identify perpetrators and
compromised accounts, coordinate responses, and prosecute attackers.
As the number of data sharing parties increases the number of
party-specific tools, formats, and definitions multiply rapidly until
it overwhelms the investigative and coordination abilities of those
parties.</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. A big win in a common format is the ability
to automate many of the analysis tasks an significantly speed up the
response and persecution activities.</t>
</section>
<section title="Processing of Exchanged Data not Defined">
<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"></xref>. The
IODEF defines a flexible and extensible format and supports a granular
level of specificity. These phishing and fraud extensions reuse
subsets of the IODEF data model and, where appropriate, specifies new
data elements. Leveraging an existing specification allows for more
rapid adoption and reuse of existing tools in organizations. For
clarity, and in order to eliminate duplication, only the additional
structures necessary for describing the exchange of phishing and
e-crime activity are provided.</t>
</section>
</section>
<section title="Terminology Used in This Document">
<t>Since many people use different but similar terms to mean the same
thing, we use the following terminology in this document.</t>
<t><list style="letters">
<t>Phishing<list style="empty">
<t>The overall process of identifying victims, contacting them
via a lure, causing a victim to send a set of private
credentials to a collection site, and storing those credentials
is called phishing.</t>
</list></t>
<t>Fraud event<list style="empty">
<t>A fraud event is the combination of Phishing and subsequent
fraudulent use of the private credentials.</t>
</list></t>
<t>Lure<list style="empty">
<t>A lure is the decoy used to trick a victim into performing
some activity such as providing their private credentials. The
lure relies on social engineering concepts to convince the
victim that the lure is genuine and its instructions should be
followed. A lure includes a pointer or link to a collection
site.</t>
</list></t>
<t>Collection Site<list style="empty">
<t>The web site, email box, SMS number, phone number, or other
place where a phished victim sends their private credentials for
later fraudulent use by a criminal.</t>
</list></t>
<t>Credentials<list style="empty">
<t>A credential is data that is transferred or presented to
establish either a claimed identity or the authorizations of a
system entity. Many websites requires a user name and password
-- combined they are a credential -- to access sensitive
content.</t>
</list></t>
<t>Message<list style="empty">
<t>Although primarily email, a Lure can be transported via any
messaging medium such as Instant message, Voice Over IP, or text
via an SMS service. The term message is used as a generic term
for any of these transport mediums.</t>
</list></t>
</list></t>
</section>
<section title="Interesting Fraud Event Data">
<t>Before defining the structure of the IODEF extensions we identify the
'interesting' data in phishing and other fraudulent activities.</t>
<section title="The Elements of a Phishing/Fraud Event">
<figure>
<artwork height=""
name="Figure 2.0 The Components of Internet Phishing."
type="" width="" xml:space="preserve"><![CDATA[
+-----------+ +------------------+
| Fraudster |<---<-- | Collection Site |<---O--<----<----+
+----+------+ +------------------+ | |
| | |
| +--|-----+ ^
| | Sensor | Credentials
| +-|------+ |
| +---------------+ | +-------+
\--->--| Attack Source |--Lure--->-----O------> | User/ |
+---------------+ |Victim |
+-------+
Figure 3.1: The Components of Internet Fraud
]]></artwork>
</figure>
<t>Internet-based Phishing and Fraud activities are normally comprised
of at least six components:</t>
<t><list style="numbers">
<t>The Phisher, Fraudster, or party perpetrating the fraudulent
activity. Most times this party is not readily identifiable.</t>
<t>The Attack Source, the source of the phishing email, virus,
trojan, or other attack is masked in an enticing manner.</t>
<t>The Lure used to trick the victim into responding.</t>
<t>The User, Victim, or intended target of the fraud or phish.</t>
<t>The credentials, personal data, or other information the victim
has surrendered to the phisher.</t>
<t>The collection site, where the victim sends their credentials
or personal data if they have been duped by the lure of the
phisher. This may be a website, mailbox, phone operator, or a
database.</t>
</list>If we take a holistic view of the attack, there are some
additional components:</t>
<t><list counter="7" hangIndent="" style="symbols">
<t>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>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 title="Fraudulent Activity Extensions to the IODEF-Document">
<t>Fraud events are reported in a Fraud Activity Report which is an
instance of an XML IODEF-Document Incident element with added
EventData and AdditionalData elements. The additional fields in the
EventData specific to phishing and fraud are enclosed into a
PhraudReport XML element. Fraudulent activity may include multiple
emails, instant messages, or network messages, scattered over
various times, locations, and methodologies. The PhraudReport within
an EventData may include information about the email header and
body, details of the actual phishing lure, correlation to other
attacks, and details of the removal of the web server or credential
collector. As a phishing attack may generate multiple reports to an
incident team, multiple PhraudReports may be combined into one
EventData structure and multiple EventData structures may be
combined into one Incident Report. One IODEF Incident report may
record one or more individual phishing events and may include
multiple EventData elements.</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"></xref>.</t>
</section>
</section>
<section title="Useful Data Items In a Fraud Event">
<t>There are a number of subtle and non-obvious datum to capture from
a fraud event that makes the event analysis and correlation with other
events more useful. These datum can be grouped into categories:</t>
<section title="Data about the Lure">
<t>If a lure was presented as part of the fraud event, this category
includes the original received lure, the means that the lure was
received ( e.g., email, phone, or SMS), and the source addresses
that sent the lure. Other useful data includes DNS data about the
lure source, identification of any accompanying malware, and the
Brand name defrauded.</t>
</section>
<section title="Credential Collection Site Data">
<t>The collection site contains victim identifications along with
copies of data supplied by the victims such as account names or
numbers, passwords, date of birth, etc. This category of useful data
includes these credentials along with information about the
collections site itself such as its type, site DNS data, DNS
registrant data, and site physical location. The location and
registrant information is particularly important if law enforcement
assistance is expected. Additionally, an entire site archive can be
gathered to allow a collector on a shared web site to be disabled
without impacting other users.</t>
</section>
<section title="Detection Information">
<t>This is a non-obvious data category and contains data on how the
lure or collection site was detected. Understanding how the lure was
detected allows us to design and implement better detection
systems.</t>
</section>
<section title="Analysis Output">
<t>In an environment where time is critical, it is imperative that
analysis from one party can be reliably explained and shared to
other investigative parties. This grouping includes data that an
investigator found interesting or could be useful to others.</t>
</section>
</section>
</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-purpose attribute of an Incident element. A new report contains an
empty or a "create" ext-purpose value; an updated report contains a
ext-value value of "update"; a request for deletion contains a
"delete" ext-purpose value. Note that this is actually an advisory
marking for the report originator or recipient as operating procedures
in a report life cycle is very environment specific.</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 Appendix
<xref format="counter" target="AppendixA"></xref></t>
<figure title="">
<artwork height="" name="The IODEF Incident Element" type=""
width="" xml:space="preserve"><![CDATA[
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| | |<>--[ AdditionalData ]
| | |<>--[ PhraudReport ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 4.1: The IODEF XML Incident Element (modified)
]]></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="Syntactical Correctness of Fraud Activity Reports">
<t>The Fraud Activity Report MUST pass XML validation using the schema
defined in <xref target="RFC5070"></xref> and the extensions defined
in<eref target="AppendixA"></eref> 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"><![CDATA[+------------------+
| PhraudReport |
+------------------+
| STRING Version |<>--{0..1}--[ PhishNameRef ]
| ENUM FraudType |<>--{0..1}--[ PhishNameLocalRef ]
| STRING ext-value |<>--{0..1}--[ FraudParameter ]
| |<>--{0..*}--[ FraudedBrandName ]
| |<>--{1..*}--[ LureSource ]
| |<>--{1..*}--[ OriginatingSensor ]
| |<>--{0..1}--[ EmailRecord ]
| |<>--{0..*}--[ DCSite ]
| |<>--{0..*}--[ TakeDownInfo ]
| |<>--{0..*}--[ ArchivedData ]
| |<>--{0..*}--[ RelatedData ]
| |<>--{0..*}--[ CorrelationData ]
| |<>--{0..1}--[ PRComments ]
+------------------+
Figure 5.1: The PhraudReport Element ]]></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 site.</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>The data model schema contains a copy of the iodef:System element.
Although we would like to just extend the System element, it is
defined in RFC5070 with an unable-to-extend anonymous type so we
copied the element, named its underlying type, and then generated the
extension to it.</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"></xref>. 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 style="numbers">
<t>A terse XML-type identifier for the element or attribute.</t>
<t>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>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.06 to be
compliant with this document.</t>
<t><cref>NOTE: This value will be changed to "1.0" when this document
is approved.</cref></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. The FraudType
chosen determines the value of the FraudParameter filed. This field
contains one of the following values:</t>
<t><list style="numbers">
<t>phishing. The FraudParameter should be the subject line of the
phishing lure email or value of a lure IM or VoIP message. This
type is a standard phishing lure, usually sent as email, and is
intended to derive financial loss to the recipient.</t>
<t>recruiting. The FraudParameter is the subject line of the
recruit, or mule, email or message.</t>
<t>malware distribution. The FraudParameter is the email subject
line of the phishing email. This type of email phish does not pose
a potential financial loss to the recipient, but lures the
recipient to an infected site.</t>
<t>fraudulent site. This identifies a known fraudulent site that
does not necessarily send spam but is used to show lures. The
FraudParameter may be used to identify the website.</t>
<t>dnsspoof. This choice does not have a related FraudParameter.
This value is used when a DNS system component responses with an
untrue IP address for the requested domain name due to either
cache poisoning, ID spoofing, or other manipulation of the DNS
system.</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>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>
<t>ext-value. This choice identifies an unidentified FraudType.
The FraudType should be captured in the ext-value attribute.</t>
</list></t>
<section title="ext-value attribute">
<t>OPTIONAL. This STRING may be populated with a FraudType that has
not been predefined.</t>
</section>
<section title="FraudParameter element">
<t>Zero or one value of iodef:MLStringType. The contents of this
element are dependent on the FraudType choice. It may be an email
subject line, VoIP lure, link in an IM message, or a web URL. Note
that some phishers add a number of random characters onto the end of
a phish email subject line for uniqueness; reporters should delete
those characters before insertion into the FraudParameter field.</t>
</section>
</section>
<section title="PhishNameRef element">
<t>Zero or one value of iodef:MLStringType. The PhishNameRef element is the common
name used to identify this fraud event. It is often the name agreed
upon by involved parties or vendors. Using this name can be a
convenient way to reference the activity collaborating with other
parties, the media, or engaging in public education.</t>
</section>
<section title="PhishNameLocalRef element">
<t>Zero or one value of iodef:MLStringType. The PhishNameLocalRef element
describes a local name or Unique-IDentifier (UID) that is used by
various parties before a commonly agreed term is adopted. This field
allows a cross-reference from the submitting organization's system to
a central repository.</t>
</section>
<section title="FraudedBrandName element">
<t>Zero or more values of iodef:MLStringType. This is the identifier
of the recognized brand name or company name used in the phishing
activity (e.g., XYZ Semiconductor Corp).</t>
</section>
<section title="LureSource element">
<t>REQUIRED. One or more values. The LureSource element describes the
source of the PhraudReport lure. It allows the specification of IP
Addresses, DNS names, domain registry information, and rudimentary
support for the files that might be downloaded or registry keys
modified by the crimeware.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
+-------------+
| LureSource |
+-------------+
| |<>--(1..*)--[ System ]
| |<>--(0..*)--[ DomainData ]
| |<>--(0..1)--[ IncludedMalware ]
| |<>--(0..1)--[ FilesDownloaded ]
| |<>--(0..1)--[ WindowsRegistryKeysModified ]
+-------------+
Figure 5.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>
<t>Multiple System elements may be used to identify the DNS Name, IP Address(es) of the lure source.</t>
</section>
<section title="DomainData element" anchor="DomainData">
<t>Zero or more element values. The DomainData element describes the
registration, delegation, and control of a domain used to source the
lure and can identify the IP address associated with the System element URI.
Capturing the domain data is very useful when investigating or
correlating events.</t>
<t>The structure of a DomainData element is as follows:</t>
<figure>
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
+--------------------+
| DomainData |
+--------------------+
| |<>----------[ Name ]
| |<>--(0..1)--[ DateDomainWasChecked ]
| ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ]
| ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ]
| |<>--(0..*)--[ Nameservers ]
| |<>--(0..1)--[ DomainContacts ]
+--------------------+
Figure 5.3 The DomainData element
]]></artwork>
</figure>
<section title="Name">
<t>REQUIRED. One value of iodef:MLStringType. The Name element
contains the host DNS name used in this event. Its value should be
the complete DNS host address, e.g., if an event targeted
www.example.com the value would be www.example.com.</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 name servers identified
for this domain. Each entry is a sequence of DNSNameType and
iodef:Address pairs as specified below.</t>
<figure>
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
+--------------------+
| Nameservers |
+--------------------+
| |<>----------[ Server]
| |<>--(1..*)--[ iodef:Address ]
+--------------------+
Figure 5.4 The Nameservers element
]]></artwork>
</figure>
<t>The use of one Server value and multiple Address values is used
to note multiple IPAddreses associated with one DNS entry for the
domain nameserver.</t>
<section title="Server element">
<t>One value of iodef:MLStringType. This field contains the DNS
name of the domain nameserver.</t>
</section>
<section title="iodef:Address element">
<t>One or more values of iodef:Address. This field lists the IP Address(es) associated with this Server element.</t>
</section>
</section>
<section title="DomainContacts element">
<t>REQUIRED. Choice of either a SameDomainContact or one or more
Contact elements. The DomainContacts element allows the reporter
to enter contact information supplied by the registrar or returned
by Whois queries. For efficiency of the reporting party, the domain
contact information may be marked to be the same as another domain
already reported using the SameDomainContact element.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
+----------------+
| DomainContacts |
+----------------+
| |<>--(0..1)--[ SameDomainContact ]
| |<>--(1..*)--[ Contact ]
+----------------|
Figure 5.5 The DomainContacts element
]]></artwork>
</figure>
<section title="SameDomainContact">
<t>REQUIRED. One iodef:MLStringType. The SameDomainContact
element is populated with a domain name if the contact
information for this domain is identical to that name in this or
another report. Implementors are cautioned to only use this
element when the domain contact data returned by a registrar or
registry is identical.</t>
</section>
<section title="Contact 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"><![CDATA[
+--------------------+
| Contact |
+--------------------+
| |<>----------[ iodef:ContactName ]
| |<>--(0..*)--[ iodef:Description ]
| ENUM role |<>--(0..*)--[ iodef:RegistryHandle ]
| |<>--(0..1)--[ iodef:PostalAdress ]
| ENUM Restriction |<>--(0..*)--[ iodef:Email ]
| ENUM ext-role |<>--(0..*)--[ iodef:Telephone ]
| ENUM type |<>--(0..1)--[ iodef:Fax ]
| ENUM ext-type |<>--(0..1)--[ iodef:Timezone ]
| |<->----------[ AdditionalData ]
| | +<-> [ Confidence ]
+--------------------+
Figure 5.6: The Contact element
]]></artwork>
</figure>
<t>Each Contact has optional attributes to capture the sensitivity
and role for which the contact is listed. Elements
reused from <xref target="RFC5070"></xref> are not discussed in
this document.</t>
<section title="Confidence element">
<t>REQUIRED. ENUM. The Confidence element describes a
qualitative assessment of the veracity of the contact
information. This attribute is an extension to the
iodef:Contact element and is defined in this document. There
are five possible confidence values as follows.</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="Ext-role attribute" toc="exclude">
<t>REQUIRED. ENUM. The ext-role attribute is extended from the
iodef:ext-role attribute with values identified in <xref
target="RFC3982">RFC3982</xref>. The ext-value value of the
role attribute should be used, with the ext-role attribute
value chosen from one of the following values:</t>
<t><list hangIndent="4" style="numbers">
<t>billingContacts</t>
<t>technicalContacts</t>
<t>administrativeContacts</t>
<t>legalContacts</t>
<t>zoneContacts</t>
<t>abuseContacts</t>
<t>securityContacts</t>
<t>otherContacts</t>
<t>hostingProvider. This contact is the hosting provider
of this server. Although not in RFC3982, it is useful in
investigations to note where the server is located and who
operates it. Load balanced, multicast or anycast servers
may have multiple hostingProvider contact entries.</t>
</list></t>
</section>
</section>
</section>
</section>
<section title="SystemStatus attribute">
<t>REQUIRED. ENUM. The SystemStatus attribute assesses a system's
involvement in this event. The value is chosen from this list:</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 simply used by
another party.</t>
<t>fraudulent. The system is operated with fraudulent
intentions, e.g., the domain name is a homophone.</t>
<t>innocent-hacked. The system was compromised by a third party
and used in this event.</t>
<t>innocent-hijacked. The IP Address or domain name was
deliberately hijacked via BGP or DNS and used in this event to
source the lure or host the collection site.</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 from the 'domainStatusType' of `<xref
target="RFC3982"></xref>. An extra 'unknown' value was added in case the Status is undeterminable.</t>
<t><list style="numbers">
<t>reservedDelegation</t>
<t>assignedAndActive</t>
<t>assignedAndInactive</t>
<t>assignedAndOnHold</t>
<t>revoked</t>
<t>transferPending</t>
<t>registryLock</t>
<t>registrarLock</t>
<t>other</t>
<t>unknown</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"><![CDATA[
+------------------+
| IncludedMalware |
+------------------+
| |<>--(1..*)--[ Name ]
| |<>--(0..1)--[ ds:Reference ]
| |<>--(0..1)--[ Data ]
+------------------+
+-----------------------+
| Data |
+-----------------------+
| hexBinary XORPattern |
+-----------------------+
Figure 5.7: The Included Malware element
]]></artwork>
</figure>
<section title="Name element">
<t>REQUIRED. One or more value of iodef:MLStringType. This
field is used to identify the lure malware by its known name. Unnamed malware may be identified by a value of 'unknown'.</t>
</section>
<section title="Reference element">
<t>Zero or one value of the Reference. This optional field is used
to hold the Algorithm identification and value of a hash computed
over the malware executable. This entire element is imported from
<xref target="RFC3275"></xref>. Implementations SHOULD support the
use of SHA-1 <xref target="SHA"></xref> as a DigestMethod.</t>
</section>
<section title="Data element">
<t>Zero or one value. The optional Data element is used to include
the lure malware, which is encoded as a hexBinary type and XORed
with a pattern to render it harmless.</t>
<section title="XORPattern attribute">
<t>One value of hexBinary. The Data Element includes a 16
hexadecimal character XOR Pattern attribute to support disabling
the included malware to bypass anti-virus filters. The default
value is 0x55AA55AA55AA55BB which would be XOR-ed with the
malware datastring to recover the actual malware.</t>
</section>
</section>
</section>
<section title="FilesDownloaded element">
<t>Zero or One value of a sequence of File elements.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
+---------------------+
| FilesDownloaded |
+---------------------+
| |<>--(1..*)--[ File ]
+---------------------+
Figure 5.8: The FilesDownloaded element
]]></artwork>
</figure>
<section title="File element">
<t>One or more values of iodef:MLStringType. The File element value is the
name of a file downloaded by this lure.</t>
</section>
</section>
<section title="WindowsRegistryKeysModified element">
<t>One or more valuev of the Key sequence. The contents of the WindowsRegistryKeysModified element are sequences
of Key elements.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
+------------------------------+
| WindowsRegistryKeysModified |
+------------------------------+
| |<>--(1..*)--[ Key ]
+------------------------------+
+--------------+
| Key |
+--------------+
| |<>-----[ Name ]
| |<>-----[ Value ]
+--------------+
Figure 5.9: The WindowsRegistryKeysModified 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. The key and value are encoded as in Microsoft .reg
files. <xref target="KB310516"/></t>
<section title="Name element">
<t>One STRING, representing the WINDOWS Operating System
Registry Key Name. The value is encoded as in Microsoft .reg
files, e.g., [HKEY_LOCAL_MACHINE\Software\Test\KeyName].</t>
</section>
<section title="Value element">
<t>One STRING, representing the value of the associated Key
encoded as in Microsoft .reg files, e.g., REG_BINARY:01.</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 multiple locations.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
+---------------------+
| OriginatingSensor |
+---------------------+
| ENUM OrigSensorType |<>------------[ DateFirstSeen ]
| |<>------------[ iodef:System ]
+---------------------+
Figure 5.10: 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 Intrusion Detection System, Intrusion
Protection System, or other Internet Service Provider
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 or more iodef:System. This is identification information (such as the IPVersion, IPAddress,
etc) of the entity that detected this event. The ability to identify
multiple detectors is supported.</t>
</list></t>
</section>
</section>
<section title="The DCSite element">
<t>Zero or more DCSite elements. The DCSite captures the type,
identifier, location, and other pertinent information about the
credential gathering process, or data collection site, used in the
phishing incident. The data collection site is identified by four
elements: the type of collector, the network location, information
about its DNS Domain, and a confidence factor. Further details about
the domain, system, or owner of the DCSite can be inserted into the
DomainData sub-element.</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"><![CDATA[
+--------------+
| DCSite |
+--------------+
| ENUM DCType |<>--+--------[ SiteURL ]
| | +--------[ Domain ]
| | +--------[ EmailSite ]
| | +--------[ System ]
| | +--------[ Unknown ]
| |<>--(0..*)---[ iodef:Node ]
| |<>--(0..1)---[ DomainData ]
| |<>--(0..1)---[ iodef:Assessment ]
+--------------+
Figure 5.11: 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 on
the user's machine.</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 credentail or data collection site. The
Domain choice may be used to identify entire 'phishy' domains like
those used for the RockPhish and related malware. Each DCSite
element also includes a confidence attribute to convey the reporter's
assessment of their confidence that this DCSite element is valid,
and involved with this event. The confidence value is a per-DCSite
value as multiple-site data collectors may have different confidence
values.</t>
<t>The DCSite element is a choice of:</t>
<t><list hangIndent="4" style="numbers">
<t>SiteURL. One value of iodef:MLStringType. This choice supports URIs and other
web-based identifiers.</t>
<t>Domain. One value of iodef:MLStringType. This choice allows the entry of a DNS Domain
name.</t>
<t>EmailSite. One value of iodef:MLStringType. This choice includes an email address if
the site used email communications.</t>
<t>iodef:Address. One value of iodef:Address element. This choice is
used to capture the IP Address of a site.</t>
<t>Unknown. One value of iodef:MLStringType. The unknown entry is used for exception to
the preceding choices.</t>
</list></t>
<section title="Confidence attribute">
<t>One Value of STRING. The confidence attribute is a value between 0 and 100 representing the
reporter's certainty that this is a genuine phishing site. A value of 0 represents a false positive; a value of 100 signifies
that the reporter has independently verified this site.</t>
</section>
</section>
<section title="iodef:Node">
<t>Zero or more values of iodef:Node. This element is used to identify the IP Address(es) or DNS Names associated with the DCSite element value.</t>
</section>
<section title="DomainData element">
<t>Zero or One value of DomainData <xref target="DomainData" format="default" pageno="true"/>. 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 title="TakeDownInfo element" toc="default">
<t>Zero or more TakeDownInfo elements. This element identifies the
agent or agency that performed the removal, DNS domain disablement, or
ISP-blockage of the phish or fraud collector site. A PhraudReport may
have multiple TakeDownInfo elements to support activities where
multiple take down activities are involved on different dates. Note
that the term "Agency" is used to identify any party performing the
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"><![CDATA[
+-------------------+
| TakeDownInfo |
+-------------------+
| |<>---(0..1)--[ TakeDownDate ]
| |<>---(0..*)--[ TakeDownAgency ]
| |<>---(0..*)--[ TakeDownComments ]
+-------------------+
Figure 5.12: 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 iodef:MLStringType elements. 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 iodef:MLStringType elements. A free form field to add any additional
details of this take down effort or to identify parties that
assisted in the effort at an ISP, CERT, or DNS Registry.</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"><![CDATA[
+-------------------+
| ArchivedData |
+-------------------+
| ENUM type |<>---(0..1)--[ URL ]
| |<>---(0..1)--[ Comments ]
| |<>---(0..1)--[ Data ]
+-------------------+
Figure 5.13: 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. The archive is a set of files from the
collection site.</t>
<t>basecamp. The contents of a criminal development site are
included in the archive.</t>
<t>sendersite. The archive is a set of files or data from a
phishing lure sending site.</t>
<t>credentialInfo. The included archive are recovered private
credentials.</t>
<t>unspecified. The archive contents does not fit into one of
the above categories and will be described in the DataComments
element.</t>
</list></t>
</section>
<section title="URL element">
<t>Zero or one value of anyURL. As the archive of an entire site can
be quite large, the URL element points to an Internet-based server
where the actual content of the site archive can be retrieved. Note
that this element just points out where the archive is and does not
include the entire archive in the report. This is the URL where the
archive file is located.</t>
</section>
<section title="Comments element">
<t>Zero or one value of iodef:MLStringType. This field is a free
form area for comments on the archive and/or URL.</t>
</section>
<section title="Data element">
<t>Zero or one value of xs:Base64Binary. This field contains 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 iodef:MLStringType. 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 iodef:MLStringType. 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>This element supports the inclusion of the actual email message
received as a phishing lure. Inclusion of the actual mail message is
supported by two methods; either the message may be included as one
large string, or the header and body components may be dissected and
included as a series of strings.</t>
<figure title="">
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
+--------------------+
| EmailRecord |
+--------------------+
| |<>--------------[ EmailCount ]
| |<>--(0..1)------[ EmailMessage ]
| |<>--(0..1)------[ EmailComments ]
+--------------------+
Figure 5.14: The EmailRecord element
]]></artwork>
</figure>
<section title="EmailCount element">
<t>REQUIRED. INTEGER. This field enumerates the number of email
messages identified in this record as detected by the reporter.</t>
</section>
<section title="EmailMessage element">
<t>Zero of one value of iodef:MLStringType. The entire SMTP mail
message - RFC822 header followed by body as specified in [RFC5322] - should be inserted as one
large text string. In some communities this combination is known as the message contents
and full headers.</t>
</section>
<section title="EmailComments element">
<t>Zero or one value of iodef:MLStringType elements. This field contains comments or
relevant data not placed elsewhere about the phishing email.</t>
</section>
</section>
</section>
<section title="Mandatory IODEF and PhraudReport Elements" toc="default">
<t>A report about fraud or phishing requires certain identifying
information which is contained within the standard IODEF Incident data
structure and the PhraudReport extensions. The following table
identifies attributes required to be present in a compliant PhraudReport
to report phishing or fraud. The required attributes are a combination
of those required by the base IODEF element, as shown in figure 6.1, and those required by this
document, shown in figure 6.2. Attributes identified as required SHALL be populated in
conforming phishing activity reports.</t>
<t>A compliant IODEF PhraudReport SHALL contain the following
elements and attributes:</t>
<figure>
<artwork><![CDATA[+--------------+
| Incident |
+--------------+
| ENUM Purpose |---[ IncidentID ]
| |---[ ReportTime ]
| |---[ Assessment ]
| | ---> [ Impact ]
| |---[ Contact ]
| | ---> [ @type ]
| | ---> [ @role ]
| | ---> [ * ]
| |---[ EventData ]
| | ---> [ DetectTime ]
| | ---> [ AdditionalData ]
| | ---> [ PhraudReport ]
+--------------+
Figure 6.1. IODEF Required classes for a PhraudReport
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[+----------------+
| PhraudReport |
+----------------+
| ENUM FraudType |---[ LureSource ]
| STRING Version | ---> [ iodef:System ]
| |---[ OriginatingSensor ]
| | --> [ DateFirstSeen ]
| | --> [ iodef:System ]
| | --> [ iodef:Node ]
| |
+----------------+
Figure 6.2 PhraudReport Required Elements.
]]></artwork>
</figure>
<t>* Note that the iodef:Contact element is required, but none of its
sub-elements are required. For proper XML correctness, one of the
sub-elements is required; pick one.</t>
<section title="Guidance on Usage" toc="default">
<t>It may be apparent that the mandatory attributes for a PhraudReport
make for a quite sparse report. As incident forensics and data
analysis require detailed information, the originator of a
PhraudReport SHOULD include any tidbit of information gleaned from the
attack analysis. Information that is considered sensitive can be
marked as such using the restriction parameter of each data
element.</t>
<t>The reporting party is encouraged to provide more than just the minimally required data elements about
an event in a PhraudReport. The additional information may be
volatile and not recoverable in the future, and may be useful in answering investigation
questions or in performing correlation with other reported events.</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 "RFC3688".</t>
<t>Registration request for the IODEF phishing namespace:<list
hangIndent="4" style="empty">
<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" style="empty">
<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"></eref> 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. (The APWG has no relationship to an IETF working
group.)</t>
<t>This document has received significant assistance from members of the
IETF INCH working group and two groups addressing the phishing problem:
members of the APWG and participants in the Financial Services
Technology Consortium's Counter-Phishing project. A special thanks goes
to the hardy people who supplied valuable feedback after using this
format to report phishing.</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></organization>
</author>
<author fullname="J. Meijer" initials="J." surname="Meijer">
<organization></organization>
</author>
<author fullname="Y. Demchenko" initials="Y." surname="Demchenko">
<organization></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="August" year="2002" />
</front>
<seriesInfo name="FIPS" value="180-2" />
</reference>
<reference anchor="RFC3275">
<front>
<title>(Extensible Markup Language) XML-Signature Syntax and
Processing</title>
<author fullname="D. Eastlake" initials="D." surname="Eastlake">
<organization></organization>
</author>
<author fullname="J. Reagle" initials="J." surname="Reagle">
<organization></organization>
</author>
<author fullname="D. Solo" initials="D." surname="Solo">
<organization></organization>
</author>
<date month="March" year="2002" />
<abstract>
<t>This document specifies XML (Extensible Markup Language)
digital signature processing rules and syntax. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3275" />
<format octets="164198"
target="ftp://ftp.isi.edu/in-notes/rfc3275.txt" type="TXT" />
</reference>
<reference anchor="RFC3982">
<front>
<title>IRIS: A Domain Registry (dreg) Type for the Internet Registry
Information Service (IRIS)</title>
<author fullname="A. Newton" initials="A." surname="Newton">
<organization></organization>
</author>
<author fullname="M. Sanz" initials="M." surname="Sanz">
<organization></organization>
</author>
<date month="January" year="2005" />
<abstract>
<t>This document describes an Internet Registry Information
Service (IRIS) registry schema for registered DNS information. The
schema extends the necessary query and result operations of IRIS
to provide the functional information service needs for syntaxes
and results used by domain registries and registrars. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3982" />
<format octets="90901" target="ftp://ftp.isi.edu/in-notes/rfc3982.txt"
type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="KB310516">
<front>
<title>How to add, modify, or delete registry subkeys and values by
using a registration entries (.reg) file</title>
<author>
<organization>Microsoft Corporation</organization>
</author>
<date month="December" year="2007" />
</front>
<format target="http://support.microsoft.com/kb/310516" type="txt" />
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname=" Mealling, M." initials="M" surname="Mealing">
<organization></organization>
</author>
<date month="January" year="2004" />
</front>
<seriesInfo name="RFC" value="3688" />
</reference>
</references>
<section anchor="AppendixA"
title="Appendix A. Phishing Extensions XML Schema">
<t></t>
<figure><artwork
xml:space="preserve">
<![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212
/xmldsig-core-schema.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/>
<!--
This Schema complies with draft-cain-post-inch-phishingextns-07.txt
==========================================================
=== Top Level Class: PhraudReport ===
==========================================================
It is incorporated within an
IODEF.Incident.EventData.AdditionalData element.
All the top-level or major elements are defined as xs:types to make
future extension easier.
-->
<xs:element name="PhraudReport">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="PhishNameRef"
type="iodef:MLStringType"/>
<xs:element minOccurs="0" name="PhishNameLocalRef"
type="iodef:MLStringType"/>
<xs:element minOccurs="0" name="FraudParameter"
type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="FraudedBrandName" type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
name="LureSource" type="phish:LureSource.type"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
name="OriginatingSensor"
type="phish:OriginatingSensor.type"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailRecord"
type="phish:EmailRecord.type"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="DCSite" type="phish:DCSite.type"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:TakeDownInfo"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="phish:ArchivedData"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="RelatedData" type="xs:anyURI"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="CorrelationData" type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="PRComments"
type="iodef:MLStringType"/>
</xs:sequence>
<xs:attribute default="1.0" name="Version" use="optional"/>
<xs:attribute name="FraudType" type="phish:FraudType.type"
use="required"/>
<xs:attribute name="ext-value" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="FraudType.type">
<xs:restriction base="xs:string">
<xs:enumeration value="phishing"/>
<xs:enumeration value="recruiting"/>
<xs:enumeration value="malware distribution"/>
<xs:enumeration value="fraudulent site"/>
<xs:enumeration value="dnsspoof"/>
<xs:enumeration value="archive"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
<!--
==========================================================
=== End of the Top-Level Element ===
==========================================================
-->
<!--
==========================================================
=== The Lure Source Element ===
==========================================================
-->
<xs:complexType mixed="false" name="LureSource.type">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
<xs:element minOccurs="0" maxOccurs="unbounded"
ref="phish:DomainData"/>
<xs:element minOccurs="0" name="IncludedMalware"
type="phish:IncludedMalware.type"/>
<xs:element minOccurs="0" name="FilesDownloaded">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" name="File"
type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="WindowsRegistryKeysModified">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Key">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="Value" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
=== LureSource sub-elements ===
-->
<xs:complexType name="IncludedMalware.type">
<xs:sequence>
<xs:element name="Name"
maxOccurs="unbounded" type="iodef:MLStringType"/>
<xs:element minOccurs="0" ref="ds:Reference"/>
<xs:element minOccurs="0" name="Data">
<xs:complexType >
<xs:simpleContent>
<xs:extension base="xs:hexBinary">
<xs:attribute default="55AA55AA55AA55BB"
name="XORPattern" type="xs:hexBinary"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!--
===========================================================
=== The EmailRecord Element ===
===========================================================
-->
<xs:complexType name="EmailRecord.type">
<xs:sequence>
<xs:element name="EmailCount" type="xs:integer"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailMessage"
type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="EmailComments"
type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
<!--
===========================================================
=== The Data Collection Site (DCSite) Info Element ===
===========================================================
-->
<xs:complexType name="DCSite.type">
<xs:sequence>
<xs:choice>
<xs:element name="SiteURL">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Domain">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="EmailSite">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="System">
<xs:complexType id="SystemType">
<xs:sequence>
<xs:element ref="iodef:Address"/>
</xs:sequence>
<xs:attribute ref="phish:confidence"/>
</xs:complexType>
</xs:element>
<xs:element name="Unknown">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute ref="phish:confidence"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:choice>
<xs:element ref="iodef:Node" minOccurs="0" maxOccurs="unbounded"/>
<xs:element minOccurs="0" ref="phish:DomainData"/>
<xs:element minOccurs="0" ref="iodef:Assessment"/>
</xs:sequence>
<xs:attribute name="DCType" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="web"/>
<xs:enumeration value="email"/>
<xs:enumeration value="keylogger"/>
<xs:enumeration value="automation"/>
<xs:enumeration value="unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!--
==============================================
==== The Domain Data Element used in System =====
==============================================
-->
<xs:element name="DomainData">
<xs:complexType id="DomainData.type">
<xs:sequence>
<xs:element maxOccurs="1"
name="Name" type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0"
name="DateDomainWasChecked" type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="RegistrationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="1" minOccurs="0" name="ExpirationDate"
type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="Nameservers">
<xs:complexType id="Nameservers.type">
<xs:sequence>
<xs:element name="Server" type="iodef:MLStringType"/>
<xs:element ref="iodef:Address" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:choice id="DomainContacts" maxOccurs="1" minOccurs="0">
<xs:element name="SameDomainContact"
type="iodef:MLStringType"/>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:Contact"/>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attribute name="SystemStatus">
<xs:simpleType id="SystemStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="spoofed"/>
<xs:enumeration value="fraudulent"/>
<xs:enumeration value="innocent-hacked"/>
<xs:enumeration value="innocent-hijacked"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="DomainStatus">
<xs:simpleType id="DomainStatus.type">
<xs:restriction base="xs:string">
<xs:enumeration value="reservedDelegation"/>
<xs:enumeration value="assignedAndActive"/>
<xs:enumeration value="assignedAndInactive"/>
<xs:enumeration value="assignedAndOnHold"/>
<xs:enumeration value="revoked"/>
<xs:enumeration value="transferPending"/>
<xs:enumeration value="registryLock"/>
<xs:enumeration value="registrarLock"/>
<xs:enumeration value="other"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="Confidence">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:attribute name="confidence">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<!--
=========================================================
= ext-role Values for use within the DomainContact Contacts element ==
=========================================================
-->
<xs:simpleType name="ext-role">
<xs:restriction base="xs:string">
<xs:enumeration value="billingContacts"/>
<xs:enumeration value="technicalContacts"/>
<xs:enumeration value="administrativeContacts"/>
<xs:enumeration value="legalContacts"/>
<xs:enumeration value="zoneContacts"/>
<xs:enumeration value="abuseContacts"/>
<xs:enumeration value="securityContacts"/>
<xs:enumeration value="otherContacts"/>
<xs:enumeration value="hostingProvider"/>
</xs:restriction>
</xs:simpleType>
<!--
=================================================
=== The Originating Sensor Data Element ===
=================================================
-->
<xs:complexType name="OriginatingSensor.type">
<xs:sequence>
<xs:element name="DateFirstSeen" type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="1"
ref="iodef:System"/>
</xs:sequence>
<xs:attribute name="OriginatingSensorType" use="required">
<xs:simpleType id="OriginatingSensorType.type">
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="web"/>
<xs:enumeration value="webgateway"/>
<xs:enumeration value="mailgateway"/>
<xs:enumeration value="browser"/>
<xs:enumeration value="ispsensor"/>
<xs:enumeration value="human"/>
<xs:enumeration value="honeypot"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!--
======================================================
=== The Take Down Data structure. ===
======================================================
-->
<xs:element name="TakeDownInfo" type="phish:TakeDownInfo.type"/>
<xs:complexType name="TakeDownInfo.type">
<xs:sequence>
<xs:element maxOccurs="1" minOccurs="0" name="TakeDownDate"
type="xs:dateTime"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownAgency" type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownComments" type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
<!--
=========================================================
=== The Archived Data Element ===
=========================================================
-->
<xs:element name="ArchivedData" type="phish:ArchivedData.type"/>
<xs:complexType name="ArchivedData.type">
<xs:sequence>
<xs:element minOccurs="0" name="URL" type="xs:anyURI"/>
<xs:element minOccurs="0" name="Comments"
type="iodef:MLStringType"/>
<xs:element maxOccurs="1" minOccurs="0" name="Data"
type="xs:base64Binary"/>
</xs:sequence>
<xs:attribute name="type" use="required">
<xs:simpleType id="ArchivedDataType.type">
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="collectionsite"/>
<xs:enumeration value="basecamp"/>
<xs:enumeration value="sendersite"/>
<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 xml:space="preserve">
<![CDATA[
From: support@example.com
Sent: Friday, June 10, 2005 3:52 PM
To: someone@example.com
Subject: Account update
To: someone@example.com
Date: Sun, 10 May 2005 3:52:44 +0200
We would like to inform you that we have released a new version of our
Customer Form. This form is required to be completed by all customers.
Please follow these steps:
1.Open the form at http://www.example.com/customerservice/cform.php
<http://www.2.example.com/customerservice/cform.php
&email=(someone@example.com)> .
2.Follow given instructions.
Thank you,
Our Support Team
]]></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 xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document lang="en-US"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<Incident purpose="reporting" ext-purpose="create">
<IncidentID name="example.com">PAT2005-06</IncidentID>
<ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
<Description>This is a test report from actual data.
</Description>
<Assessment>
<Impact type="social-engineering"/>
<Confidence rating="high"/>
</Assessment>
<Contact role="creator" type="person">
<ContactName>patcain</ContactName>
<Email>pcain@coopercain.com</Email>
</Contact>
<EventData>
<DetectTime>2005-06-21T18:22:02-05:00</DetectTime>
<AdditionalData dtype="xml">
<phish:PhraudReport FraudType="phishing">
<phish:FraudParameter>
Subject: You have successfully updated your password
</phish:FraudParameter>
<phish:FraudedBrandName>Cooper-Cain
</phish:FraudedBrandName>
<phish:LureSource>
<System category="source">
<Node>
<Address>192.0.2.18</Address>
</Node>
</System>
<phish:IncludedMalware>
<phish:Name>W32.Mytob.EA@mm</phish:Name>
</phish:IncludedMalware>
</phish:LureSource>
<phish:OriginatingSensor OriginatingSensorType="human">
<phish:DateFirstSeen>2005-06-10T15:52:11-05:00
</phish:DateFirstSeen>
<System>
<Node>
<Address>192.0.2.13</Address>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:EmailMessage>
Return-path: <support@example.com>
to: pcain@example.com
Delivery-date: Fri, 10 Jun 2005:52:11-0400
Received: from dsl18-2-0-192.dsl.example.net([192.0.2.18]
helo=example.com) by mail06.example.com esmtp (Exim) id
1DgpXy-0002Ua-IR for pcain@example.com;,
10 Jun 2005 15:52:10-0400
From: support@example.com
To: pcain@example.com
Subject: You have successfully updated your password
Date: Fri, 10 Jun 2005 12:52:00 -0700
MIME-Version: 1.0
Type: multipart/mixed;
="----=_NextPart_000_0008_0911068B.E7EB6D2A"
X-Priority: 3MSMail-Priority: Normal
X-EN-OrigIP: 192.0.2.18
EN-OrigHost: dsl18-2-0-192.dsl.example.net
Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16)
on.example.net
X-Spam-Level: ***** X-Spam-Status: No,
score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30,
HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE,
NO_REAL_NAME,
PRIORITY_NO_NAME autolearn=disabled version=3.0.2
From:support@example.com
Sent: Friday, June 10, 2005 3:52 PM
Subject: Account update
To: someone@example.com
Date: Sun, 10 June 2005 3:52:44 +0200
We would like to inform you that we have released a new version of our
Customer Form. This form is required to be completed by all customers.
Please follow these steps:
1.Open the form at http://www.example.com/customerservice/cform.php
<http://www.2.example.com/customerservice/cform.php
&email=(someone@example.com)> .
2.Follow given instructions.
Thank you,
Our Support Team
</phish:EmailMessage>
</phish:EmailRecord>
</phish:PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>]]></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></preamble>
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
Return-path: <service@example.com>
Envelope-to: pcain@example.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.example.com ([10.1.1.161]
helo=mail15.example.com)
by mailscan38.example.com with esmtp (Exim)
id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006
05:37:21 -0400
Received: from [192.0.2.61] (helo=TSI)
by mail15.example.com with
esmtp (Exim) id 1Fq5Bj-0006dv-6b
for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400
Received: from User ([192.0.2.157]) by TSI with
Microsoft SMTPSVC(5.0.2195.6713);
Tue, 13 Jun 2006 02:24:30 -0400
Reply-To: <nospam@example.org>
From: "company"<service@example.com>
Subject: * * * Update & Verify Your Example Company Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@example.com
X-EN-OrigIP: 192.0.2.1
X-EN-OrigHost: unknown
Company<http://www.example.com/images/company_logo.gif>
<http://www.example.com/images/pixel.gif>
<http://www.example.com/images/pixel.gif>
<http://www.example.com/images/pixel.gif>
Account Update Request
Dear Example. member:,
You are receiving this notification because company is required by
law to notify you, that you urgently need to update your online
account statement, due to high risks of fraud intentions.
The updating of your example account can be done at any time by
clicking on the link shown below
http://www.example.com/cgi-bin/webscr?cmd=_login-run
<http://192.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20/%20/.payp
al.com/index.htm>
Once you log in,update your account information.
After updating your account click on the History sub tab of your
Account Overview page to see your most recent statement.
If you need help with your password, click the Help link which is at
the upper right hand side of the company website. To report errors
in your statement or make inquiries, click the Contact Us link in the
footer on any page of the company website, call our Customer Service
center at (999) 555-0167, or write us at:
Company, Inc.
P.O. Box 0
Anytown, MA 00000
Sincerely,
Big Example Company
<http://www.example.com/images/dot_row_long.gif>
]]></artwork>
</figure>
</section>
<section title="Phishing Report">
<t></t>
<figure>
<artwork height="" name="" type="" width="" xml:space="preserve"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" lang="en-US">
<Incident purpose="mitigation" ext-purpose="create"
restriction="private">
<IncidentID name="example.com">CC200600000002</IncidentID>
<ReportTime>2006-06-13T21:14:56-05:00</ReportTime>
<Description>This is a sample phishing email received report.
The phish was actually received as is.</Description>
<Assessment>
<Impact severity="high" type="social-engineering"/>
<Confidence rating="numeric">85</Confidence>
</Assessment>
<Contact role="creator" type="person">
<ContactName>patcain</ContactName>
<Email>pcain@example.com</Email>
</Contact>
<EventData>
<DetectTime>2006-06-13T05:37:21-04:00</DetectTime>
<AdditionalData dtype="xml">
<phish:PhraudReport FraudType="phishing">
<phish:FraudParameter>
* * * Update & Verify Your Company Account * * *
</phish:FraudParameter>
<phish:FraudedBrandName>company</phish:FraudedBrandName>
<phish:LureSource>
<System category="source">
<Node>
<Address>192.0.2.4</Address>
</Node>
</System>
</phish:LureSource>
<phish:OriginatingSensor OriginatingSensorType="mailgateway">
<phish:DateFirstSeen>
2006-06-13T05:37:22-04:00</phish:DateFirstSeen>
<System>
<Node>
<NodeRole category="mail"/>
</Node>
</System>
</phish:OriginatingSensor>
<phish:EmailRecord>
<phish:EmailCount>1</phish:EmailCount>
<phish:EmailMessage>
Return-path: <service@example.com>
Envelope-to: pcain@example.com
Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400
Received: from mail15.example.com ([10.1.1.161]
helo=mail15.example.com)
by mailscan38.example.com with esmtp (Exim)
id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006
05:37:21 -0400
Received: from [192.0.2.61] (helo=TSI)
by mail15.example.com with
esmtp (Exim) id 1Fq5Bj-0006dv-6b
for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400
Received: from User ([192.0.2.157]) by TSI with
Microsoft SMTPSVC(5.0.2195.6713);
Tue, 13 Jun 2006 02:24:30 -0400
Reply-To: <nospam@example.org>
From: "company"<service@example.com>
Subject: * * * Update & Verify Your Example Company Account * * *
Date: Tue, 13 Jun 2006 02:36:34 -0400
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Bcc:
Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI>
X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC)
FILETIME=[072A66A0:01C68EB2]
X-EN-OrigSender: service@example.com
X-EN-OrigIP: 192.0.2.1
X-EN-OrigHost: unknown
<img src="http://www.example.com/images/company_logo.gif">
<img src="http://www.example.com/images/pixel.gif">
<img src="http://www.example.com/images/pixel.gif">
<img src="http://www.example.com/im/pixel.gif">
Account Update Request
Dear Example. member:,
You are receiving this notification because company is required by
law to notify you, that you urgently need to update your online
account statement, due to high risks of fraud intentions.
The updating of your example account can be done at any time by
clicking on the link shown below
<a href="http://192.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20/%20/.example.com/index.htm">
http://www.example.com/cgi-bin/webscr?cmd=_login-run </a>
Once you log in,update your account information.
After updating your account click on the History sub tab of your
Account Overview page to see your most recent statement.
If you need help with your password, click the Help link which is at
the upper right hand side of the company website. To report errors in
your statement or make inquiries, click the Contact Us link in the
footer on any page of the company website, call our Customer Service
center at (999) 555-0167, or write us at:
Company, Inc.
P.O. Box 0
Anytown, MA 00000
Sincerely,
Big Example Company
<img src="http://www.example.com/images/dot_row_long.gif">
</phish:EmailMessage>
</phish:EmailRecord>
<phish:DCSite DCType="web">
<phish:SiteURL>http://190.0.2.41:8080/.cgi-bin/.webscr/.secure-
login/%20%20/.company.com/index.htm</phish:SiteURL>
<phish:DomainData DomainStatus="assignedAndActive"
SystemStatus="unknown">
<phish:Name>bad.example.com</phish:Name>
<phish:DateDomainWasChecked>2006-06-14T13:05:00-05:00
</phish:DateDomainWasChecked>
<phish:RegistrationDate>
2000-12-13T00:00:00</phish:RegistrationDate>
<phish:Nameservers>
<phish:Server>ns1.example.net</phish:Server>
<Address>192.0.2.18</Address>
</phish:Nameservers>
</phish:DomainData>
</phish:DCSite>
</phish:PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
]]></artwork>
</figure>
<t></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:12:03 |