| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2010.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC5070 to support the reporting of phishing, fraud, other types of electronic crime. The extensions also support the exchange on information about widespread spam incidents. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud or spam cycle. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents .
The extensions defined in this document are used to generate two different types of reports: a fraud report and a wide-spread spam report. Although similar in structure, each report has different required objects and intentions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Introduction
1.1.
Why a Common Report Format is Needed
1.2.
Processing of Exchanged Data not Defined
1.3.
Relation to the INCH IODEF Data Model
2.
Terminology Used in This Document
3.
Interesting Fraud Event Data
3.1.
The Elements of a Phishing/Fraud Event
3.2.
Useful Data Items In a Fraud Event
4.
Fraud Activity Reporting via IODEF-Documents
4.1.
Fraud Report Types
4.2.
Fraud Report XML Representation
4.3.
Syntactical Correctness of Fraud Activity Reports
5.
PhraudReport Element Definitions
5.1.
PhraudReport Structure
5.2.
Reuse of IODEF-defined Elements
5.3.
Element and Attribute Specification Format
5.4.
Version attribute
5.5.
FraudType attribute
5.6.
PhishNameRef element
5.7.
PhishNameLocalRef element
5.8.
FraudedBrandName element
5.9.
LureSource element
5.10.
OriginatingSensor Element
5.11.
The DCSite element
5.12.
TakeDownInfo element
5.13.
ArchivedData element
5.14.
RelatedData element
5.15.
CorrelationData element
5.16.
PRComments element
5.17.
EmailRecord element
6.
Mandatory IODEF and PhraudReport Elements
6.1.
Guidance on Usage
7.
Security Considerations
7.1.
Transport-specific concerns
7.2.
Using the iodef:restriction attribute
8.
IANA Considerations
9.
Contributors
10.
References
10.1.
Normative References
10.2.
Informative References
Appendix A.
Appendix A. Phishing Extensions XML Schema
Appendix B.
Example Virus Report
B.1.
Received Email
B.2.
Generated Report
Appendix C.
Sample Phishing Report
C.1.
Received Lure
C.2.
Phishing Report
§
Authors' Addresses
| TOC |
Deception activities, such as receiving an email purportedly from a bank requesting you to confirm your account information, are an expanding attack type on the Internet. The terms phishing and fraud are used interchangeably in this document to characterize broadly-launched social engineering attacks in which an electronic identity is misrepresented in an attempt to trick individuals into revealing their personal credentials ( e.g., passwords, account numbers, personal information, ATM PINs, etc.). A successful phishing attack on an individual allows the phisher (i.e., the attacker) to exploit the individual's credentials for financial or other gain. Phishing attacks have morphed from directed email messages from alleged financial institutions to more sophisticated lures that may also include malware.
This document defines a data format extension to the Incident Object Description Exchange Format (IODEF) [RFC5070] (Danyliw, R., Meijer, J., and Y. Demchenko, “The Incident Object Description Exchange Format,” December 2007.) that can be used to describe information about a phishing or other type of fraudulent incident. Sections 2 of this document provide an overview of the terminology and process of a phishing event. Section3 introduces the high-level report format and how to use it. Sections 4 and 5 describe the data elements of the fraud extensions. The appendices includes an XML schema for the extensions and a few example fraud reports.
The extensions defined in this document may be used to report the social engineering victim lure, the collections site, and credential targeted ('spear') phishing, broad multi-recipient phishing, and other evolving Internet-based fraud attempts. Malware and other malicious software included within the
| TOC |
To combat the rise in malicious activity on the Internet, service providers and investigative agencies are sharing more and more network and event data in a coordinated effort to identify perpetrators and compromised accounts, coordinate responses, and prosecute attackers. As the number of data sharing parties increases the number of party-specific tools, formats, and definitions multiply rapidly until it overwhelms the investigative and coordination abilities of those parties.
By using a common format, it becomes easier for an organization to engage in this coordination as well as correlation of information from multiple data sources or products into a cohesive view. As the number of data sources increases, a common format becomes even more 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.
| TOC |
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.
| TOC |
Instead of defining a new report format, this draft defines an extension to [RFC5070] (Danyliw, R., Meijer, J., and Y. Demchenko, “The Incident Object Description Exchange Format,” December 2007.). 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.
| TOC |
Since many people use different but similar terms to mean the same thing, we use the following terminology in this document.
- a.
- Phishing
The overall process of identifying victims, contacting them via a lure, causing a victim to send a set of private credentials to a collection site, and storing those credentials is called phishing.
- b.
- Fraud event
A fraud event is the combination of Phishing and subsequent fraudulent use of the private credentials.
- c.
- Lure
A lure is the decoy used to trick a victim into performing some activity such as providing their private credentials. The lure relies on social engineering concepts to convince the victim that the lure is genuine and its instructions should be followed. A lure includes a pointer or link to a collection site.
- d.
- Collection Site
The web site, email box, SMS number, phone number, or other place where a phished victim sends their private credentials for later fraudulent use by a criminal.
- e.
- Credentials
A credential is data that is transferred or presented to establish either a claimed identity or the authorizations of a system entity. Many websites requires a user name and password -- combined they are a credential -- to access sensitive content.
- f.
- Message
Although primarily email, a Lure can be transported via any messaging medium such as Instant message, Voice Over IP, or text via an SMS service. The term message is used as a generic term for any of these transport mediums.
| TOC |
Before defining the structure of the IODEF extensions we identify the 'interesting' data in phishing and other fraudulent activities.
| TOC |
+-----------+ +------------------+
| Fraudster |<---<-- | Collection Site |<---O--<----<----+
+----+------+ +------------------+ | |
| | |
| +--|-----+ ^
| | Sensor | Credentials
| +-|------+ |
| +---------------+ | +-------+
\--->--| Attack Source |--Lure--->-----O------> | User/ |
+---------------+ |Victim |
+-------+
Figure 3.1: The Components of Internet Fraud
Internet-based Phishing and Fraud activities are normally comprised of at least six components:
If we take a holistic view of the attack, there are some additional components:
| TOC |
Fraud events are reported in a Fraud Activity Report which is an instance of an XML IODEF-Document Incident element with added EventData and AdditionalData elements. The additional fields in the EventData specific to phishing and fraud are enclosed into a PhraudReport XML element. Fraudulent activity may include multiple emails, instant messages, or network messages, scattered over various times, locations, and methodologies. The PhraudReport within an EventData may include information about the email header and body, details of the actual phishing lure, correlation to other attacks, and details of the removal of the web server or credential collector. As a phishing attack may generate multiple reports to an incident team, multiple PhraudReports may be combined into one EventData structure and multiple EventData structures may be combined into one Incident Report. One IODEF Incident report may record one or more individual phishing events and may include multiple EventData elements.
This document defines new extension elements for the EventData and Record Item IODEF XML elements and identifies those required in a PhraudReport. The Appendices contain sample Fraud Activity Reports and a complete Schema.
The IODEF Extensions defined in this document comply with section 4, "Extending the IODEF Format" in [RFC5070] (Danyliw, R., Meijer, J., and Y. Demchenko, “The Incident Object Description Exchange Format,” December 2007.).
| TOC |
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:
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
A Fraud Activity Report is an instance of an XML IODEF-Document with additional extensions and usage guidance as specified in Section 4 of this document. These additional extensions are implemented through the PhraudReport XML element.
As described in the following sections, reporting Fraud Activity has three primary components: choosing a report type; a format for the data; and how to check correctness of the format.
| TOC |
There are three actions relating to reporting phishing events. First, a reporter may *create* and exchange a new report on a new event. Secondly, a reporter may *update* a previously exchanged report to indicate new collection sites, site take down information, or related activities. Lastly, a reporter may have realized that the report is in error or contain significant incorrect data and the prudent reaction is to *delete* the report.
The three types of reports are denoted through the use of the ext-purpose attribute of an Incident element. A new report contains an empty or a "create" ext-purpose value; an updated report contains a ext-value value of "update"; a request for deletion contains a "delete" ext-purpose value. Note that this is actually an advisory marking for the report originator or recipient as operating procedures in a report life cycle is very environment specific.
| TOC |
The IODEF Incident element [RFC5070, Section 3.2] is summarized below. It and the rest of the data model presented in Section 4 is expressed in Unified Modeling Language (UML) syntax as used in the IODEF specification. The UML representations is for illustrative purposes only; elements are specified in XML as defined in Appendix A (Appendix A. Phishing Extensions XML Schema)
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| | |<>--[ AdditionalData ]
| | |<>--[ PhraudReport ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 4.1: The IODEF XML Incident Element (modified)
A Fraud Activity Report is composed of one iodef:Incident element that contains one or more related PhraudReport elements embedded in iodef:AdditionalData element of iodef:EventData. The PhraudReport element is added to the IODEF using its defined extension procedure documented in Section 5 of [RFC5070].
One IODEF-Document may contain information on multiple incidents with information for each incident contained within an iodef:Incident element [RFC5070], Section 3.12].
| TOC |
The Fraud Activity Report MUST pass XML validation using the schema defined in [RFC5070] (Danyliw, R., Meijer, J., and Y. Demchenko, “The Incident Object Description Exchange Format,” December 2007.) and the extensions defined inAppendixA of this document.
| TOC |
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.
| TOC |
A PhraudReport element is structured as follows. The components of a PhraudReport are introduced in functional grouping as some parameters are related and some elements may not make sense individually.
+------------------+
| PhraudReport |
+------------------+
| STRING Version |<>--{0..1}--[ PhishNameRef ]
| ENUM FraudType |<>--{0..1}--[ PhishNameLocalRef ]
| STRING ext-value |<>--{0..1}--[ FraudParameter ]
| |<>--{0..*}--[ FraudedBrandName ]
| |<>--{1..*}--[ LureSource ]
| |<>--{1..*}--[ OriginatingSensor ]
| |<>--{0..1}--[ EmailRecord ]
| |<>--{0..*}--[ DCSite ]
| |<>--{0..*}--[ TakeDownInfo ]
| |<>--{0..*}--[ ArchivedData ]
| |<>--{0..*}--[ RelatedData ]
| |<>--{0..*}--[ CorrelationData ]
| |<>--{0..1}--[ PRComments ]
+------------------+
Figure 5.1: The PhraudReport ElementRelevant information about a phishing or fraud event can be encoded by encoding the six components as follows:
- a.
- The PhishNameRef and PhishNameLocalRef elements identify the fraud or class of fraud.
- b.
- The LureSource element describes the source of the attack or phishing lure, including host information and any included malware.
- c.
- The DCSite describes the technical details of the credential collection site.
- d.
- The Originating Sensor element describes the means of detection.
The RelatedData, ArchivedData, and TakeDownInfo fields allow optional forensics and history data to be included.
A specific phish/fraud activity can be identified using a combination of the FraudType, FraudParameter, FraudedBrandName, LureSource, and PhishNameRef elements.
| TOC |
Elements, attributes, and parameters defined in the base IODEF specification were used whenever possible in the definition of the PhraudReport XML element. This specification does not introduce any new variable types or encodings to the IODEF data model, but extends the IODEF Contact and System elements.
The data model schema contains a copy of the iodef:System element. Although we would like to just extend the System element, it is defined in RFC5070 with an unable-to-extend anonymous type so we copied the element, named its underlying type, and then generated the extension to it.
Note: Elements that are imported from the base IODEF specification are prefaced with an "iodef" XML namespace and are noted with the section defining that element in [RFC5070] (Danyliw, R., Meijer, J., and Y. Demchenko, “The Incident Object Description Exchange Format,” December 2007.). Each element in a PhraudReport is used as described in the following sections.
| TOC |
The following sections describe the components of a PhraudReport XML element. Each description is structured as follows.
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.
| TOC |
REQUIRED. STRING. The version shall be the value 0.06 to be compliant with this document.
| TOC |
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:
| TOC |
OPTIONAL. This STRING may be populated with a FraudType that has not been predefined.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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).
| TOC |
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.
+-------------+
| LureSource |
+-------------+
| |<>--(1..*)--[ System ]
| |<>--(0..*)--[ DomainData ]
| |<>--(0..1)--[ IncludedMalware ]
| |<>--(0..1)--[ FilesDownloaded ]
| |<>--(0..1)--[ WindowsRegistryKeysModified ]
+-------------+
Figure 5.2: The LureSource element
| TOC |
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.
| TOC |
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.
The structure of a DomainData element is as follows:
+--------------------+
| DomainData |
+--------------------+
| |<>----------[ Name ]
| |<>--(0..1)--[ DateDomainWasChecked ]
| ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ]
| ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ]
| |<>--(0..*)--[ Nameservers ]
| |<>--(0..*)--[ DNSRecord ]
| |<>--(0..*)--[ DomainContacts ]
+--------------------+
Figure 5.3 The DomainData element
| TOC |
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.
| TOC |
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.
| TOC |
Zero or one value of DATETIME. The RegistrationDate element shows the date of registration for a domain.
| TOC |
Zero or one value of DATETIME. The ExpirationDate element shows the date the domain will expire.
| TOC |
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.
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.
| TOC |
One value of iodef:MLStringType. This field contains the DNS name of the domain nameserver.
| TOC |
One or more values of iodef:Address. This field contains the IP address of the domain nameserver.
| TOC |
Zero or more values of iodef:MLStringType. This element allows the reporter to duplicate the DNS record data as defined by [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.), and returned by various DNS query tools. The values of this element Including this information allows for tracking, trending, and identification of the very transient DNS mapping and structure of crimeware domains.
| TOC |
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. For efficiency of the reporting party, the domain contact information may be marked to be the same as another domain already reported using the SameDomainContact element.
+----------------+
| DomainContacts |
+----------------+
| |<>--(0..1)--[ SameDomainContact ]
| |<>--(1..*)--[ Contact ]
+----------------|
Figure 5.5 The DomainContacts element
| TOC |
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.
| TOC |
REQUIRED. One or more 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.
+--------------------+
| Contact |
+--------------------+
| |<>----------[ iodef:ContactName ]
| |<>--(0..*)--[ iodef:Description ]
| ENUM role |<>--(0..*)--[ iodef:RegistryHandle ]
| ENUM Confidence |<>--(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 ]
+--------------------+
Figure 5.6: The Contact element
Each Contact has three attributes to capture the sensitivity, confidence, and role for which the contact is listed. Elements reused from [RFC5070] (Danyliw, R., Meijer, J., and Y. Demchenko, “The Incident Object Description Exchange Format,” December 2007.) are not discussed in this document.
| TOC |
REQUIRED. ENUM. The ext-role attribute is extended from the iodef:ext-role attribute with values identified in RFC3982 (Newton, A. and M. Sanz, “IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS),” January 2005.) [RFC3982]. The ext-value value of the role attribute should be used, with the ext-role attribute value chosen from one of the following values:
| TOC |
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.
| TOC |
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.
| TOC |
REQUIRED. ENUM. The SystemStatus attribute assesses a system's involvement in this event. The value is chosen from this list:
| TOC |
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 RFC3982[RFC3982] (Newton, A. and M. Sanz, “IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS),” January 2005.).
| TOC |
Zero or One Value. The IncludedMalware element allows for the identification and optional inclusion of the actual malware that was part of the lure. The goal of this element is not to detail the characteristics of the malware but rather to allow for a convenient element to link malware to a phishing campaign.
+------------------+
| IncludedMalware |
+------------------+
| |<>--(1..*)--[ Name ]
| |<>--(0..1)--[ ds:Reference ]
| |<>--(0..1)--[ Data ]
+------------------+
+-----------------+
| ds:Reference |
+-----------------+
| ID Id |<>--(0..1)--[ ds:Transforms
| anyURI URI |<>----------[ ds:DigestMethod
| anyURI Type |<>----------[ ds:DigestValue
| |
+-----------------+
+-----------------------+
| Data |
+-----------------------+
| hexBinary XORPattern |
+-----------------------+
Figure 5.7: The Included Malware element
| TOC |
REQUIRED. One or more value of iodef:MLStringType. This optional field is used to identify the lure malware.
| TOC |
Zero or one value of the Reference. This optional field is used to hold the Algorithm identification and value of a hash computed over the malware executable. This entire element is imported from [RFC3275] (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” March 2002.). Implementations SHOULD support the use of SHA-1 [SHA] (National Institute of Standards and Technology, U.S. Department of Commerce, “Secure Hash Standard,” August 2002.) as a DigestMethod.
| TOC |
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.
| TOC |
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.
| TOC |
Zero or One value of a sequence.
+---------------------+
| FilesDownloaded |
+---------------------+
| |<>--(1..*)--[ File ]
+---------------------+
Figure 5.8: The FilesDownloaded element
| TOC |
One or more values of STRING. The File element value is the name of a file downloaded by this lure.
| TOC |
One value of the Keys sequence.
The contents of the WindowsRegistryKeysModified element are sets of Key elements.
+------------------------------+
| WindowsRegistryKeysModified |
+------------------------------+
| |<>--(1..*)--[ Key ]
+------------------------------+
+--------------+
| Key |
+--------------+
| |<>-----[ Name ]
| |<>-----[ Value ]
+--------------+
Figure 5.9: The WindowsRegistryKeysModified element
| TOC |
One or more Sequences. The key element is a sequence of Name and Value pairs representing an operating system registry key and its value. The key and value are encoded as in Microsoft .reg files. [KB310516] (Microsoft Corporation, “How to add, modify, or delete registry subkeys and values by using a registration entries (.reg) file,” December 2007.) [KB310516]
| TOC |
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].
| TOC |
One STRING, representing the value of the associated Key encoded as in Microsoft .reg files, e.g., REG_BINARY:01.
| TOC |
REQUIRED. The OriginatingSensor element contains the identification and cognizant data of the network element that detected this fraud activity. Note that the network element does not have to be on the Internet itself (i.e., it may be a local IDS system) nor is it required to be mechanical (e.g., humans are allowed).
Multiple OriginatingSensor Elements are allowed to support detection at multiple locations.
+---------------------+
| OriginatingSensor |
+---------------------+
| ENUM OrigSensorType |<>------------[ DateFirstSeen ]
| |<>---(1..*)---[ iodef:System ]
+---------------------+
Figure 5.10: The OriginatingSensor element
The OriginatingSensor requires a type value and identification of the entity that detected this fraudulent event.
| TOC |
REQUIRED. ENUM. The value is chosen from the following list, categorizing the function of this sensor:
1. Web. A web server or service detected this event.
2. WebGateway. A proxy, firewall, or other network gateway detected this event.
3. MailGateway. The event was detected via a mail gateway or filter
4. Browser. The event was detected at the user web interface or browser-type element..
5. ISPsensor. The event was detected by an automated system in the network such as Intrusion Detection System, Intrusion Protection System, or other Internet Service Provider device.
6. Human. A non-automated system (e.g., a human, manual analysis, etc) detected this event.
7. Honeypot. The event was detected by receipt at a decoy device.
8. Other. The detection was performed via a non-listed method.
| TOC |
REQUIRED. DATETIME. This is the date and time that this sensor first saw this phishing activity.
| TOC |
REQUIRED. One iodef:System. This is the IPVersion, IPAddress, and optionally, port number of the entity that generated this report.
| TOC |
Zero or more DCSite elements. The DCSite captures the type, identifier, location, and other pertinent information about the credential gathering process, or data collection site, used in the phishing incident. The data collection site is identified by four elements: the type of collector, the network location, information about its DNS Domain, and a confidence factor. Further details about the domain, system, or owner of the DCSite can be inserted into the DomainData sub-element.
If the DCSite element is present, a value is required. Multiple DCSite elements are allowed to indicate multiple collection sites for a single collector. Multiple URLs pointing to the same DNS entry can be identified with multiple SiteURL elements.
+--------------+
| DCSite |
+--------------+
| ENUM DCSite |<>--+--------[ SiteURL ]
| | +--------[ Domain ]
| | +--------[ EmailSite ]
| | +--------[ System ]
| | +--------[ Unknown ]
| |<>--(0..1)---[ DomainData ]
| |<>--(0..1)---[ iodef:Assessment ]
+--------------+
Figure 5.11: The DCSite element
| TOC |
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.
| TOC |
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.
The DCSite element is a choice of:
| TOC |
Zero or One value of DomainData. This element allows for the identification of data associated with the data collection site.
| TOC |
Zero or One value of iodef:Assessment. This element is used to designate different confidence levels of multiple-site data collectors.
| TOC |
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.
The TakeDownInfo element allows one date element with multiple TakeDownAgency and Comment elements to support operations using multiple agencies.
+-------------------+ | TakeDownInfo | +-------------------+ | |<>---(0..1)--[ TakeDownDate ] | |<>---(0..*)--[ TakeDownAgency ] | |<>---(0..*)--[ TakeDownComments ] +-------------------+ Figure 5.12: The TakeDownInfo element
| TOC |
Zero or one DATETIME. This is the date and time that take down of the collector site occurred.
| TOC |
Zero or more STRING. This is a free form string identifying the agency, corporation, or cooperative that performed the take down.
| TOC |
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.
| TOC |
Zero or more values of the ArchivedData element are allowed.
+-------------------+
| ArchivedData |
+-------------------+
| ENUM type |<>---(0..1)--[ URL ]
| |<>---(0..1)--[ Comments ]
| |<>---(0..1)--[ Data ]
+-------------------+
Figure 5.13: The ArchivedData element
The ArchivedData element is populated with a pointer to the contents of a data collection site, base camp (i.e., development site), or other site used by a phisher. The ArchivedDataInfo may also include a copy of the archived data recovered from a phishing system. This element will be populated when, for example, an ISP takes down a phisher's web site and has copied the site data into an archive file.
There are four types of archives currently supported, as specified in the type field.
| TOC |
REQUIRED. This parameter specifies the type of site data pointed to by the ArchivedDataURL, from the following list:
| TOC |
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.
| TOC |
Zero or one value of iodef:MLStringType. This field is a free form area for comments on the archive and/or URL.
| TOC |
Zero or one value of xs:Base64Binary. This field contains a base64 encoded version of the data described in the comment field above.
| TOC |
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.).
| TOC |
Zero or more value of iodef:MLStringType. Any information that correlates this incident to other incidents can be entered here.
| TOC |
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.
| TOC |
This element supports the inclusion of the actual email message received as a phishing lure. Inclusion of the actual mail message is supported by two methods; either the message may be included as one large string, or the header and body components may be dissected and included as a series of strings.
+--------------------+
| EmailRecord |
+--------------------+
| |<>--------------[ EmailCount ]
| |<>--(0..1)--+---[ Email ]
| |<>--(0..1)------[ EmailComments ]
+--------------------+
Figure 5.14: The EmailRecord element
| TOC |
REQUIRED. INTEGER. This field enumerates the number of email messages identified in this record detected by the reporter.
| TOC |
Zero of one value of iodef:MLStringType. The entire SMTP mail message - header, body and envelope data - should be inserted as one large string.
| TOC |
Zero or one value of STRING. This field contains comments or relevant data not placed elsewhere about the phishing or spam email.
| TOC |
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. 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.
A compliant IODEF PhraudReport is SHALL contain the following elements and attributes:
+--------------+
| Incident |
+--------------+
| ENUM Purpose |---[ IncidentID ]
| |---[ ReportTime ]
| |---[ Assessment ]
| | ---> [ Impact ]
| |---[ Contact ]
| | ---> [ @type ]
| | ---> [ @role ]
| | ---> [ * ]
| |---[ EventData ]
| | ---> [ DetectTime ]
| | ---> [ AdditionalData ]
| | ---> [ PhraudReport ]
+--------------+
Figure 6.1. IODEF Required classes for a PhraudReport
* 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.
+----------------+
| PhraudReport |
+----------------+
| ENUM FraudType |---[ LureSource ]
| STRING Version | ---> [ iodef:System ]
| |---[ OriginatingSensor ]
| | --> [ DateFirstSeen ]
| | --> [ iodef:System ]
| | --> [ iodef:Node ]
| |
+----------------+
Figure 6.2 PhraudReport Required Elements.
| TOC |
It may be apparent that the mandatory attributes for a PhraudReport make for a quite sparse report. As incident forensics and data analysis require detailed information, the originator of a PhraudReport SHOULD include any tidbit of information gleaned from the attack analysis. Information that is considered sensitive can be marked as such using the restriction parameter of each data element.
The reporting party is 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.
| TOC |
This document specifies a format for encoding a particular class of security incidents appropriate for exchange across organizations. As merely a data representation, it does not directly introduce security issues. However, it is guaranteed that parties exchanging instances of this specification will have certain concerns. For this reason, the underlying message format and transport protocol used MUST ensure the appropriate degree of confidentiality, integrity, and authenticity for the specific environment.
Organizations that exchange data using this document are URGED to develop operating procedures that document the following areas of concern.
| TOC |
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..
| TOC |
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.
| TOC |
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688] (Mealing, M., “The IETF XML Registry,” January 2004.)
Registration request for the IODEF phishing namespace:
URI: urn:ietf:params:xml:ns:iodef-phish-1.0
Registrant Contact: See the "Author's Address" section of this document.
XML: None.
Registration request for the IODEF phishing extension XML schema:
URI: urn:ietf:params:xml:schema:iodef-phish-1.0
Registrant Contact: See the "Author's Address" section of this document.
XML: See the "Phishing Extensions Schema Definition" in the Appendix A section of this document.
| TOC |
The extensions are an outgrowth of the Anti-Phishing Working Group (APWG) activities in data collection and sharing of phishing and other ecrime-ware. (The APWG has no relationship to an IETF working group.)
This document has received significant assistance from members of the IETF INCH working group and two groups addressing the phishing problem: members of the APWG and participants in the Financial Services Technology Consortium's Counter-Phishing project. A special thanks goes to the hardy people who supplied valuable feedback after using this format to report phishing.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML). |
| [RFC3275] | Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” RFC 3275, March 2002 (TXT). |
| [RFC3688] | Mealing, M., “The IETF XML Registry,” RFC 3688, January 2004. |
| [RFC3982] | Newton, A. and M. Sanz, “IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS),” RFC 3982, January 2005 (TXT). |
| [RFC5070] | Danyliw, R., Meijer, J., and Y. Demchenko, “The Incident Object Description Exchange Format,” RFC 5070, December 2007 (TXT). |
| [SHA] | National Institute of Standards and Technology, U.S. Department of Commerce, “Secure Hash Standard,” FIPS 180-2, August 2002. |
| TOC |
| [KB310516] | Microsoft Corporation, “How to add, modify, or delete registry subkeys and values by using a registration entries (.reg) file,” December 2007. |
| [RFC1034] | Mockapetris, P., “Domain names - concepts and facilities,” STD 13, RFC 1034, November 1987 (TXT). |
| TOC |
<?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-06.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="xs:string"/>
<xs:element minOccurs="0" name="PhishNameLocalRef"
type="xs:string"/>
<xs:element minOccurs="0" name="FraudParameter"
type="iodef:MLStringType"/>
<xs:element maxOccurs="unbounded" name="FraudedBrandName"
minOccurs="0" 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" use="required"
type="phish:FraudType.type" />
<xs:attribute fixed="" 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" 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="xs:string"/>
</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"/>
<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" 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="Message"
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="xs:string">
<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="xs:string">
<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="xs:string">
<xs:attribute name="confidence"
type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="System" type="phish:SystemType"/>
<xs:element name="Unknown">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<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 =====
=============================================
-->
<!--
==============================================
Extend iodef:System to include a confidence value.
We have to copy the System structure form IODEF here because
it is defined as an anonymous type in the IODEF schema, which
means one cannot just use the extension mechanism to extend it.
==============================================
-->
<xs:complexType name="SystemType">
<xs:complexContent>
<xs:extension base="phish:pSystemType">
<xs:attribute name="confidence" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</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:element maxOccurs="unbounded" minOccurs="0"
name="DNSRecord" type="iodef:MLStringType"/>
<xs:choice id="DomainContacts" maxOccurs="1"
minOccurs="0">
<xs:element name="SameDomainContact"
type="iodef:MLStringType"/>
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="1"
name="Contact" type="phish:pContactType"/>
</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:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:complexType name="pContactType">
<xs:complexContent>
<xs:extension base="phish:ContactType">
<xs:attribute name="Confidence" type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!--
====================================================
==== 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="xs:string"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="TakeDownComments" type="xs:string"/>
</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="xs:string"/>
<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>
<!--===============================================================
===== A copy of the IODEF:System definition to facilitate =====
===== extending. Since the System element is defined in IODEF =====
===== as an anonymous type, it cannot be extended in place. =====
===================================================================
-->
<xs:complexType name="pSystemType">
<xs:sequence>
<xs:element ref="iodef:Node"/>
<xs:element maxOccurs="unbounded"
minOccurs="0" ref="iodef:Service"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:OperatingSystem"/>
<xs:element maxOccurs="unbounded"
minOccurs="0" ref="iodef:Counter"/>
<xs:element maxOccurs="unbounded"
minOccurs="0" ref="iodef:Description"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:AdditionalData"/>
</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:NMTOKENS">
<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 default="unknown" name="spoofed">
<xs:simpleType>
<xs:restriction base="xs:NMTOKENS">
<xs:enumeration value="unknown"/>
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!--
===================================================================
===== A copy of the IODEF:Contact definition to facilitate =====
===== extending it. Since the Contact element is defined in =====
===== IODEF as an anonymous type, it cannot be extended in =====
===== place. =====
===================================================================
-->
<xs:complexType name="ContactType">
<xs:sequence>
<xs:element minOccurs="0" ref="iodef:ContactName"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:Description"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:RegistryHandle"/>
<xs:element minOccurs="0" ref="iodef:PostalAddress"/>
<xs:element maxOccurs="unbounded"
minOccurs="0" ref="iodef:Email"/>
<xs:element maxOccurs="unbounded"
minOccurs="0" ref="iodef:Telephone"/>
<xs:element minOccurs="0" ref="iodef:Fax"/>
<xs:element minOccurs="0" ref="iodef:Timezone"/>
<xs:element maxOccurs="unbounded"
minOccurs="0" ref="iodef:Contact"/>
<xs:element maxOccurs="unbounded" minOccurs="0"
ref="iodef:AdditionalData"/>
</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"/>
</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:complexType>
</xs:schema>
| TOC |
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.
| TOC |
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
| TOC |
NOTE: Some wrapping and folding liberties have been applied to fit it into the margins.
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document lang="en-US"
xmlns:phish="urn:ietf:params:xml:ns:iodef-phish-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<Incident purpose="reporting" ext-purpose="create">
<IncidentID name="example.com">PAT2005-06</IncidentID>
<ReportTime>2005-06-22T08:30:00-05:00</ReportTime>
<Description>This is a test report from actual data.
</Description>
<Assessment>
<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:Message>
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
To:pcain@example.com
Subject: You have successfully updated your password
Attachments: updated-password.zip
user pcain,have successfully updated the password of your 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!
Example Support Team +++
Attachment: No Virus (Clean) +++Antivirus - www.example.com
</phish:Message>
</phish:EmailRecord>
</phish:PhraudReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>| TOC |
A sample report generated from a received electronic mail phishing message in shown in this section.
| TOC |
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.us> 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) 123-4567, or write us at: Company, Inc. P.O. Box 0 Anytown, MA 98765 Sincerely, Big Example Company <http://www.example.com/images/dot_row_long.gif>
| TOC |
<?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:Message>
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.us>
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.company.com/images/company_logo.gif">
<img src="http://www.company.com/images/pixel.gif">
<img src="http://www.company.com/images/pixel.gif">
<img src="http://www.company.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) 123-4567, or write us at:
Company, Inc.
P.O. Box 0
Anytown, MA 98765
Sincerely,
Big Example Company
<img src="http://www.example.com/images/dot_row_long.gif">
</phish:Message>
</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>
| TOC |
| Patrick Cain | |
| The Cooper-Cain Group, Inc. | |
| P.O. Box 400992 | |
| Cambridge, MA | |
| USA | |
| Email: | pcain@coopercain.com |
| David Jevans | |
| The Anti-Phishing Working Group | |
| 5150 El Camino Real, Suite A20 | |
| Los Altos, CA 94022 | |
| USA | |
| Email: | dave.jevans@antiphishing.org |