idnits 2.17.1 draft-cain-post-inch-phishingextns-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1711 has weird spacing: '...tribute ref="...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 23, 2009) is 5261 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5322' is mentioned on line 1295, but not defined == Unused Reference: 'RFC3688' is defined on line 1479, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Cain 3 Internet-Draft The Cooper-Cain Group, Inc. 4 Intended status: Standards Track D. Jevans 5 Expires: May 27, 2010 The Anti-Phishing Working Group 6 November 23, 2009 8 Extensions to the IODEF-Document Class for Reporting Phishing 9 draft-cain-post-inch-phishingextns-07 11 Abstract 13 This document extends the Incident Object Description Exchange Format 14 (IODEF) defined in RFC5070 to support the reporting of phishing 15 events, which is a particular type of fraud. These extensions are 16 flexible enough to support information gleaned from activities 17 throughout the entire electronic fraud cycle - from receipt of the 18 phishing lure to the disablement of the collection site. Both simple 19 reporting and complete forensic reporting are possible, as is 20 consolidating multiple incidents . 22 RFC 2129 Keywords 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on May 27, 2010. 51 Copyright Notice 53 Copyright (c) 2009 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.1. Why a Common Report Format is Needed . . . . . . . . . . . 5 70 1.2. Processing of Exchanged Data not Defined . . . . . . . . . 6 71 1.3. Relation to the INCH IODEF Data Model . . . . . . . . . . 6 72 2. Terminology Used in This Document . . . . . . . . . . . . . . 7 73 3. Interesting Fraud Event Data . . . . . . . . . . . . . . . . . 8 74 3.1. The Elements of a Phishing/Fraud Event . . . . . . . . . . 8 75 3.2. Useful Data Items In a Fraud Event . . . . . . . . . . . . 9 76 4. Fraud Activity Reporting via IODEF-Documents . . . . . . . . . 11 77 4.1. Fraud Report Types . . . . . . . . . . . . . . . . . . . . 11 78 4.2. Fraud Report XML Representation . . . . . . . . . . . . . 11 79 4.3. Syntactical Correctness of Fraud Activity Reports . . . . 12 80 5. PhraudReport Element Definitions . . . . . . . . . . . . . . . 13 81 5.1. PhraudReport Structure . . . . . . . . . . . . . . . . . . 13 82 5.2. Reuse of IODEF-defined Elements . . . . . . . . . . . . . 14 83 5.3. Element and Attribute Specification Format . . . . . . . . 14 84 5.4. Version attribute . . . . . . . . . . . . . . . . . . . . 15 85 5.5. FraudType attribute . . . . . . . . . . . . . . . . . . . 15 86 5.6. PhishNameRef element . . . . . . . . . . . . . . . . . . . 16 87 5.7. PhishNameLocalRef element . . . . . . . . . . . . . . . . 16 88 5.8. FraudedBrandName element . . . . . . . . . . . . . . . . . 16 89 5.9. LureSource element . . . . . . . . . . . . . . . . . . . . 16 90 5.10. OriginatingSensor Element . . . . . . . . . . . . . . . . 25 91 5.11. The DCSite element . . . . . . . . . . . . . . . . . . . . 26 92 5.12. TakeDownInfo element . . . . . . . . . . . . . . . . . . . 28 93 5.13. ArchivedData element . . . . . . . . . . . . . . . . . . . 29 94 5.14. RelatedData element . . . . . . . . . . . . . . . . . . . 31 95 5.15. CorrelationData element . . . . . . . . . . . . . . . . . 31 96 5.16. PRComments element . . . . . . . . . . . . . . . . . . . . 31 97 5.17. EmailRecord element . . . . . . . . . . . . . . . . . . . 31 98 6. Mandatory IODEF and PhraudReport Elements . . . . . . . . . . 33 99 6.1. Guidance on Usage . . . . . . . . . . . . . . . . . . . . 34 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 101 7.1. Transport-specific concerns . . . . . . . . . . . . . . . 35 102 7.2. Using the iodef:restriction attribute . . . . . . . . . . 35 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 104 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 106 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 107 10.2. Informative References . . . . . . . . . . . . . . . . . . 38 108 Appendix A. Appendix A. Phishing Extensions XML Schema . . . . . 39 109 Appendix B. Example Virus Report . . . . . . . . . . . . . . . . 49 110 B.1. Received Email . . . . . . . . . . . . . . . . . . . . . . 49 111 B.2. Generated Report . . . . . . . . . . . . . . . . . . . . . 49 112 Appendix C. Sample Phishing Report . . . . . . . . . . . . . . . 52 113 C.1. Received Lure . . . . . . . . . . . . . . . . . . . . . . 52 114 C.2. Phishing Report . . . . . . . . . . . . . . . . . . . . . 53 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 117 1. Introduction 119 Deception activities, such as receiving an email purportedly from a 120 bank requesting you to confirm your account information, are an 121 expanding attack type on the Internet. The terms phishing and fraud 122 are used interchangeably in this document to characterize broadly- 123 launched social engineering attacks in which an electronic identity 124 is misrepresented in an attempt to trick individuals into revealing 125 their personal credentials ( e.g., passwords, account numbers, 126 personal information, ATM PINs, etc.). A successful phishing attack 127 on an individual allows the phisher (i.e., the attacker) to exploit 128 the individual's credentials for financial or other gain. Phishing 129 attacks have morphed from directed email messages from alleged 130 financial institutions to more sophisticated lures that may also 131 include malware. 133 This document defines a data format extension to the Incident Object 134 Description Exchange Format (IODEF) [RFC5070] that can be used to 135 describe information about a phishing or other type of fraudulent 136 incident. Sections 2 of this document provide an overview of the 137 terminology and process of a phishing event. Section3 introduces the 138 high-level report format and how to use it. Sections 4 and 5 139 describe the data elements of the fraud extensions. The appendices 140 includes an XML schema for the extensions and a few example fraud 141 reports. 143 The extensions defined in this document may be used to report the 144 social engineering victim lure, the collections site, and credential 145 targeted ('spear') phishing, broad multi-recipient phishing, and 146 other evolving Internet-based fraud attempts. Malware and other 147 malicious software included within the lure may also be included 148 within the report 150 1.1. Why a Common Report Format is Needed 152 To combat the rise in malicious activity on the Internet, service 153 providers and investigative agencies are sharing more and more 154 network and event data in a coordinated effort to identify 155 perpetrators and compromised accounts, coordinate responses, and 156 prosecute attackers. As the number of data sharing parties increases 157 the number of party-specific tools, formats, and definitions multiply 158 rapidly until it overwhelms the investigative and coordination 159 abilities of those parties. 161 By using a common format, it becomes easier for an organization to 162 engage in this coordination as well as correlation of information 163 from multiple data sources or products into a cohesive view. As the 164 number of data sources increases, a common format becomes even more 165 important, since multiple tools would be needed to interpret the 166 different sources of data. A big win in a common format is the 167 ability to automate many of the analysis tasks an significantly speed 168 up the response and persecution activities. 170 1.2. Processing of Exchanged Data not Defined 172 While the intended use of this specification is to facilitate data 173 sharing between parties, the mechanics of this sharing process and 174 its related political challenges are out of scope for this document. 176 1.3. Relation to the INCH IODEF Data Model 178 Instead of defining a new report format, this draft defines an 179 extension to [RFC5070]. The IODEF defines a flexible and extensible 180 format and supports a granular level of specificity. These phishing 181 and fraud extensions reuse subsets of the IODEF data model and, where 182 appropriate, specifies new data elements. Leveraging an existing 183 specification allows for more rapid adoption and reuse of existing 184 tools in organizations. For clarity, and in order to eliminate 185 duplication, only the additional structures necessary for describing 186 the exchange of phishing and e-crime activity are provided. 188 2. Terminology Used in This Document 190 Since many people use different but similar terms to mean the same 191 thing, we use the following terminology in this document. 193 a. Phishing 195 The overall process of identifying victims, contacting them 196 via a lure, causing a victim to send a set of private 197 credentials to a collection site, and storing those 198 credentials is called phishing. 200 b. Fraud event 202 A fraud event is the combination of Phishing and subsequent 203 fraudulent use of the private credentials. 205 c. Lure 207 A lure is the decoy used to trick a victim into performing 208 some activity such as providing their private credentials. 209 The lure relies on social engineering concepts to convince the 210 victim that the lure is genuine and its instructions should be 211 followed. A lure includes a pointer or link to a collection 212 site. 214 d. Collection Site 216 The web site, email box, SMS number, phone number, or other 217 place where a phished victim sends their private credentials 218 for later fraudulent use by a criminal. 220 e. Credentials 222 A credential is data that is transferred or presented to 223 establish either a claimed identity or the authorizations of a 224 system entity. Many websites requires a user name and 225 password -- combined they are a credential -- to access 226 sensitive content. 228 f. Message 230 Although primarily email, a Lure can be transported via any 231 messaging medium such as Instant message, Voice Over IP, or 232 text via an SMS service. The term message is used as a 233 generic term for any of these transport mediums. 235 3. Interesting Fraud Event Data 237 Before defining the structure of the IODEF extensions we identify the 238 'interesting' data in phishing and other fraudulent activities. 240 3.1. The Elements of a Phishing/Fraud Event 242 +-----------+ +------------------+ 243 | Fraudster |<---<-- | Collection Site |<---O--<----<----+ 244 +----+------+ +------------------+ | | 245 | | | 246 | +--|-----+ ^ 247 | | Sensor | Credentials 248 | +-|------+ | 249 | +---------------+ | +-------+ 250 \--->--| Attack Source |--Lure--->-----O------> | User/ | 251 +---------------+ |Victim | 252 +-------+ 254 Figure 3.1: The Components of Internet Fraud 256 Internet-based Phishing and Fraud activities are normally comprised 257 of at least six components: 259 1. The Phisher, Fraudster, or party perpetrating the fraudulent 260 activity. Most times this party is not readily identifiable. 262 2. The Attack Source, the source of the phishing email, virus, 263 trojan, or other attack is masked in an enticing manner. 265 3. The Lure used to trick the victim into responding. 267 4. The User, Victim, or intended target of the fraud or phish. 269 5. The credentials, personal data, or other information the victim 270 has surrendered to the phisher. 272 6. The collection site, where the victim sends their credentials or 273 personal data if they have been duped by the lure of the phisher. 274 This may be a website, mailbox, phone operator, or a database. 276 If we take a holistic view of the attack, there are some additional 277 components: 279 o The sensor, the means by which the phish is detected. This 280 element may be an intrusion detection system, firewall, filter, 281 email gateway, or human analyst. 283 o A forensic or archive site (not pictured) where an investigator 284 has copied or otherwise retained the data used for the fraud 285 attempt or credential collection. 287 3.1.1. Fraudulent Activity Extensions to the IODEF-Document 289 Fraud events are reported in a Fraud Activity Report which is an 290 instance of an XML IODEF-Document Incident element with added 291 EventData and AdditionalData elements. The additional fields in the 292 EventData specific to phishing and fraud are enclosed into a 293 PhraudReport XML element. Fraudulent activity may include multiple 294 emails, instant messages, or network messages, scattered over various 295 times, locations, and methodologies. The PhraudReport within an 296 EventData may include information about the email header and body, 297 details of the actual phishing lure, correlation to other attacks, 298 and details of the removal of the web server or credential collector. 299 As a phishing attack may generate multiple reports to an incident 300 team, multiple PhraudReports may be combined into one EventData 301 structure and multiple EventData structures may be combined into one 302 Incident Report. One IODEF Incident report may record one or more 303 individual phishing events and may include multiple EventData 304 elements. 306 This document defines new extension elements for the EventData and 307 Record Item IODEF XML elements and identifies those required in a 308 PhraudReport. The Appendices contain sample Fraud Activity Reports 309 and a complete Schema. 311 The IODEF Extensions defined in this document comply with section 4, 312 "Extending the IODEF Format" in [RFC5070]. 314 3.2. Useful Data Items In a Fraud Event 316 There are a number of subtle and non-obvious datum to capture from a 317 fraud event that makes the event analysis and correlation with other 318 events more useful. These datum can be grouped into categories: 320 3.2.1. Data about the Lure 322 If a lure was presented as part of the fraud event, this category 323 includes the original received lure, the means that the lure was 324 received ( e.g., email, phone, or SMS), and the source addresses that 325 sent the lure. Other useful data includes DNS data about the lure 326 source, identification of any accompanying malware, and the Brand 327 name defrauded. 329 3.2.2. Credential Collection Site Data 331 The collection site contains victim identifications along with copies 332 of data supplied by the victims such as account names or numbers, 333 passwords, date of birth, etc. This category of useful data includes 334 these credentials along with information about the collections site 335 itself such as its type, site DNS data, DNS registrant data, and site 336 physical location. The location and registrant information is 337 particularly important if law enforcement assistance is expected. 338 Additionally, an entire site archive can be gathered to allow a 339 collector on a shared web site to be disabled without impacting other 340 users. 342 3.2.3. Detection Information 344 This is a non-obvious data category and contains data on how the lure 345 or collection site was detected. Understanding how the lure was 346 detected allows us to design and implement better detection systems. 348 3.2.4. Analysis Output 350 In an environment where time is critical, it is imperative that 351 analysis from one party can be reliably explained and shared to other 352 investigative parties. This grouping includes data that an 353 investigator found interesting or could be useful to others. 355 4. Fraud Activity Reporting via IODEF-Documents 357 A Fraud Activity Report is an instance of an XML IODEF-Document with 358 additional extensions and usage guidance as specified in Section 4 of 359 this document. These additional extensions are implemented through 360 the PhraudReport XML element. 362 As described in the following sections, reporting Fraud Activity has 363 three primary components: choosing a report type; a format for the 364 data; and how to check correctness of the format. 366 4.1. Fraud Report Types 368 There are three actions relating to reporting phishing events. 369 First, a reporter may *create* and exchange a new report on a new 370 event. Secondly, a reporter may *update* a previously exchanged 371 report to indicate new collection sites, site take down information, 372 or related activities. Lastly, a reporter may have realized that the 373 report is in error or contain significant incorrect data and the 374 prudent reaction is to *delete* the report. 376 The three types of reports are denoted through the use of the ext- 377 purpose attribute of an Incident element. A new report contains an 378 empty or a "create" ext-purpose value; an updated report contains a 379 ext-value value of "update"; a request for deletion contains a 380 "delete" ext-purpose value. Note that this is actually an advisory 381 marking for the report originator or recipient as operating 382 procedures in a report life cycle is very environment specific. 384 4.2. Fraud Report XML Representation 386 The IODEF Incident element [RFC5070, Section 3.2] is summarized 387 below. It and the rest of the data model presented in Section 4 is 388 expressed in Unified Modeling Language (UML) syntax as used in the 389 IODEF specification. The UML representations is for illustrative 390 purposes only; elements are specified in XML as defined in Appendix A 391 +--------------------+ 392 | Incident | 393 +--------------------+ 394 | ENUM purpose |<>----------[ IncidentID ] 395 | STRING ext-purpose |<>--{0..1}--[ AlternativeID ] 396 | ENUM lang |<>--{0..1}--[ RelatedActivity ] 397 | ENUM restriction |<>--{0..1}--[ DetectTime ] 398 | |<>--{0..1}--[ StartTime ] 399 | |<>--{0..1}--[ EndTime ] 400 | |<>----------[ ReportTime ] 401 | |<>--{0..*}--[ Description ] 402 | |<>--{1..*}--[ Assessment ] 403 | |<>--{0..*}--[ Method ] 404 | |<>--{1..*}--[ Contact ] 405 | |<>--{0..*}--[ EventData ] 406 | | |<>--[ AdditionalData ] 407 | | |<>--[ PhraudReport ] 408 | |<>--{0..1}--[ History ] 409 | |<>--{0..*}--[ AdditionalData ] 410 +------------------+ 412 Figure 4.1: The IODEF XML Incident Element (modified) 414 A Fraud Activity Report is composed of one iodef:Incident element 415 that contains one or more related PhraudReport elements embedded in 416 iodef:AdditionalData element of iodef:EventData. The PhraudReport 417 element is added to the IODEF using its defined extension procedure 418 documented in Section 5 of [RFC5070]. 420 One IODEF-Document may contain information on multiple incidents with 421 information for each incident contained within an iodef:Incident 422 element [RFC5070], Section 3.12]. 424 4.3. Syntactical Correctness of Fraud Activity Reports 426 The Fraud Activity Report MUST pass XML validation using the schema 427 defined in [RFC5070] and the extensions defined in of this 428 document. 430 5. PhraudReport Element Definitions 432 A PhraudReport consists of an extension to the 433 Incident.EventData.AdditionalData element with a dtype of "xml". The 434 elements of the PhraudReport will specify information about the six 435 components of fraud activity identified in Section 2. Additional 436 forensic information and commentary can be added by the reporter as 437 necessary to show relation to other events, to show the output of an 438 investigation, or for archival purposes. 440 5.1. PhraudReport Structure 442 A PhraudReport element is structured as follows. The components of a 443 PhraudReport are introduced in functional grouping as some parameters 444 are related and some elements may not make sense individually. 445 +------------------+ 446 | PhraudReport | 447 +------------------+ 448 | STRING Version |<>--{0..1}--[ PhishNameRef ] 449 | ENUM FraudType |<>--{0..1}--[ PhishNameLocalRef ] 450 | STRING ext-value |<>--{0..1}--[ FraudParameter ] 451 | |<>--{0..*}--[ FraudedBrandName ] 452 | |<>--{1..*}--[ LureSource ] 453 | |<>--{1..*}--[ OriginatingSensor ] 454 | |<>--{0..1}--[ EmailRecord ] 455 | |<>--{0..*}--[ DCSite ] 456 | |<>--{0..*}--[ TakeDownInfo ] 457 | |<>--{0..*}--[ ArchivedData ] 458 | |<>--{0..*}--[ RelatedData ] 459 | |<>--{0..*}--[ CorrelationData ] 460 | |<>--{0..1}--[ PRComments ] 461 +------------------+ 463 Figure 5.1: The PhraudReport Element 465 Relevant information about a phishing or fraud event can be encoded 466 by encoding the six components as follows: 468 a. The PhishNameRef and PhishNameLocalRef elements identify the 469 fraud or class of fraud. 471 b. The LureSource element describes the source of the attack or 472 phishing lure, including host information and any included 473 malware. 475 c. The DCSite describes the technical details of the credential 476 collection site. 478 d. The Originating Sensor element describes the means of detection. 480 The RelatedData, ArchivedData, and TakeDownInfo fields allow optional 481 forensics and history data to be included. 483 A specific phish/fraud activity can be identified using a combination 484 of the FraudType, FraudParameter, FraudedBrandName, LureSource, and 485 PhishNameRef elements. 487 5.2. Reuse of IODEF-defined Elements 489 Elements, attributes, and parameters defined in the base IODEF 490 specification were used whenever possible in the definition of the 491 PhraudReport XML element. This specification does not introduce any 492 new variable types or encodings to the IODEF data model, but extends 493 the IODEF Contact and System elements. 495 The data model schema contains a copy of the iodef:System element. 496 Although we would like to just extend the System element, it is 497 defined in RFC5070 with an unable-to-extend anonymous type so we 498 copied the element, named its underlying type, and then generated the 499 extension to it. 501 Note: Elements that are imported from the base IODEF specification 502 are prefaced with an "iodef" XML namespace and are noted with the 503 section defining that element in [RFC5070]. Each element in a 504 PhraudReport is used as described in the following sections. 506 5.3. Element and Attribute Specification Format 508 The following sections describe the components of a PhraudReport XML 509 element. Each description is structured as follows. 511 1. A terse XML-type identifier for the element or attribute. 513 2. An indication of whether the element or attribute is REQUIRED or 514 optional. Mandatory items are noted as REQUIRED. If not 515 specified, elements are optional. Note that when optional 516 elements are included, they may REQUIRE specific sub-elements. 518 3. A description of the element or attribute and its intended use. 520 Elements that contain sub-elements or enumerated values are further 521 sub-sectioned. Note that there is no 'trickle-up' effect in 522 elements. That is, the required elements of a sub-element are only 523 populated if the sub-element is used. 525 5.4. Version attribute 527 REQUIRED. STRING. The version shall be the value 0.06 to be 528 compliant with this document. 530 5.5. FraudType attribute 532 REQUIRED. One ENUM. The FraudType attribute describes the type of 533 fraudulent activity described in this PhraudReport. The FraudType 534 chosen determines the value of the FraudParameter filed. This field 535 contains one of the following values: 537 1. phishing. The FraudParameter should be the subject line of the 538 phishing lure email or value of a lure IM or VoIP message. This 539 type is a standard phishing lure, usually sent as email, and is 540 intended to derive financial loss to the recipient. 542 2. recruiting. The FraudParameter is the subject line of the 543 recruit, or mule, email or message. 545 3. malware distribution. The FraudParameter is the email subject 546 line of the phishing email. This type of email phish does not 547 pose a potential financial loss to the recipient, but lures the 548 recipient to an infected site. 550 4. fraudulent site. This identifies a known fraudulent site that 551 does not necessarily send spam but is used to show lures. The 552 FraudParameter may be used to identify the website. 554 5. dnsspoof. This choice does not have a related FraudParameter. 555 This value is used when a DNS system component responses with an 556 untrue IP address for the requested domain name due to either 557 cache poisoning, ID spoofing, or other manipulation of the DNS 558 system. 560 6. archive. There is no required FraudParameter for this choice, 561 although the FraudParameter of the original phish could be 562 entered. The data archived from the phishing server is placed in 563 the ArchiveInfo element. 565 7. other. This is used to identify not-yet-enumerated fraud types. 567 8. unknown. This choice may have an associated FraudParameter. It 568 is used to cover confused cases. 570 9. ext-value. This choice identifies an unidentified FraudType. 571 The FraudType should be captured in the ext-value attribute. 573 5.5.1. ext-value attribute 575 OPTIONAL. This STRING may be populated with a FraudType that has not 576 been predefined. 578 5.5.2. FraudParameter element 580 Zero or one value of iodef:MLStringType. The contents of this 581 element are dependent on the FraudType choice. It may be an email 582 subject line, VoIP lure, link in an IM message, or a web URL. Note 583 that some phishers add a number of random characters onto the end of 584 a phish email subject line for uniqueness; reporters should delete 585 those characters before insertion into the FraudParameter field. 587 5.6. PhishNameRef element 589 Zero or one value of iodef:MLStringType. The PhishNameRef element is 590 the common name used to identify this fraud event. It is often the 591 name agreed upon by involved parties or vendors. Using this name can 592 be a convenient way to reference the activity collaborating with 593 other parties, the media, or engaging in public education. 595 5.7. PhishNameLocalRef element 597 Zero or one value of iodef:MLStringType. The PhishNameLocalRef 598 element describes a local name or Unique-IDentifier (UID) that is 599 used by various parties before a commonly agreed term is adopted. 600 This field allows a cross-reference from the submitting 601 organization's system to a central repository. 603 5.8. FraudedBrandName element 605 Zero or more values of iodef:MLStringType. This is the identifier of 606 the recognized brand name or company name used in the phishing 607 activity (e.g., XYZ Semiconductor Corp). 609 5.9. LureSource element 611 REQUIRED. One or more values. The LureSource element describes the 612 source of the PhraudReport lure. It allows the specification of IP 613 Addresses, DNS names, domain registry information, and rudimentary 614 support for the files that might be downloaded or registry keys 615 modified by the crimeware. 617 +-------------+ 618 | LureSource | 619 +-------------+ 620 | |<>--(1..*)--[ System ] 621 | |<>--(0..*)--[ DomainData ] 622 | |<>--(0..1)--[ IncludedMalware ] 623 | |<>--(0..1)--[ FilesDownloaded ] 624 | |<>--(0..1)--[ WindowsRegistryKeysModified ] 625 +-------------+ 627 Figure 5.2: The LureSource element 629 5.9.1. System element 631 REQUIRED. One or more values of the iodef:System [RFC5070, Section 632 3.15]. The system element describes a particular host involved in 633 the phishing activity. If the real IP Address can be ascertained, it 634 should be populated. A spoofed address may also be entered and the 635 spoofed attribute SHALL be set. 637 Multiple System elements may be used to identify the DNS Name, IP 638 Address(es) of the lure source. 640 5.9.2. DomainData element 642 Zero or more element values. The DomainData element describes the 643 registration, delegation, and control of a domain used to source the 644 lure and can identify the IP address associated with the System 645 element URI. Capturing the domain data is very useful when 646 investigating or correlating events. 648 The structure of a DomainData element is as follows: 650 +--------------------+ 651 | DomainData | 652 +--------------------+ 653 | |<>----------[ Name ] 654 | |<>--(0..1)--[ DateDomainWasChecked ] 655 | ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ] 656 | ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ] 657 | |<>--(0..*)--[ Nameservers ] 658 | |<>--(0..1)--[ DomainContacts ] 659 +--------------------+ 661 Figure 5.3 The DomainData element 663 5.9.2.1. Name 665 REQUIRED. One value of iodef:MLStringType. The Name element 666 contains the host DNS name used in this event. Its value should be 667 the complete DNS host address, e.g., if an event targeted 668 www.example.com the value would be www.example.com. 670 5.9.2.2. DateDomainWasChecked 672 Zero or One value of DATETIME. This element includes the timestamp 673 of when this domain data was checked and entered into this report as 674 many phishers modify their domain data at various stages of a 675 phishing event. 677 5.9.2.3. RegistrationDate element 679 Zero or one value of DATETIME. The RegistrationDate element shows 680 the date of registration for a domain. 682 5.9.2.4. ExpirationDate element 684 Zero or one value of DATETIME. The ExpirationDate element shows the 685 date the domain will expire. 687 5.9.2.5. Nameservers element 689 Zero or more values. These fields hold name servers identified for 690 this domain. Each entry is a sequence of DNSNameType and iodef: 691 Address pairs as specified below. 693 +--------------------+ 694 | Nameservers | 695 +--------------------+ 696 | |<>----------[ Server] 697 | |<>--(1..*)--[ iodef:Address ] 698 +--------------------+ 700 Figure 5.4 The Nameservers element 702 The use of one Server value and multiple Address values is used to 703 note multiple IPAddreses associated with one DNS entry for the domain 704 nameserver. 706 5.9.2.5.1. Server element 708 One value of iodef:MLStringType. This field contains the DNS name of 709 the domain nameserver. 711 5.9.2.5.2. iodef:Address element 713 One or more values of iodef:Address. This field lists the IP 714 Address(es) associated with this Server element. 716 5.9.2.6. DomainContacts element 718 REQUIRED. Choice of either a SameDomainContact or one or more 719 Contact elements. The DomainContacts element allows the reporter to 720 enter contact information supplied by the registrar or returned by 721 Whois queries. For efficiency of the reporting party, the domain 722 contact information may be marked to be the same as another domain 723 already reported using the SameDomainContact element. 725 +----------------+ 726 | DomainContacts | 727 +----------------+ 728 | |<>--(0..1)--[ SameDomainContact ] 729 | |<>--(1..*)--[ Contact ] 730 +----------------| 732 Figure 5.5 The DomainContacts element 734 5.9.2.6.1. SameDomainContact 736 REQUIRED. One iodef:MLStringType. The SameDomainContact element is 737 populated with a domain name if the contact information for this 738 domain is identical to that name in this or another report. 739 Implementors are cautioned to only use this element when the domain 740 contact data returned by a registrar or registry is identical. 742 5.9.2.6.2. Contact Element 744 REQUIRED. One or more iodef:Contact elements. This element reuses 745 and extends the iodef:Contact elements for its components. Each 746 component may have zero or more values. If only the role attribute 747 and the ContactName component are populated, the same (identical) 748 information is listed for multiple roles. 750 +--------------------+ 751 | Contact | 752 +--------------------+ 753 | |<>----------[ iodef:ContactName ] 754 | |<>--(0..*)--[ iodef:Description ] 755 | ENUM role |<>--(0..*)--[ iodef:RegistryHandle ] 756 | |<>--(0..1)--[ iodef:PostalAdress ] 757 | ENUM Restriction |<>--(0..*)--[ iodef:Email ] 758 | ENUM ext-role |<>--(0..*)--[ iodef:Telephone ] 759 | ENUM type |<>--(0..1)--[ iodef:Fax ] 760 | ENUM ext-type |<>--(0..1)--[ iodef:Timezone ] 761 | |<->----------[ AdditionalData ] 762 | | +<-> [ Confidence ] 763 +--------------------+ 765 Figure 5.6: The Contact element 767 Each Contact has optional attributes to capture the sensitivity and 768 role for which the contact is listed. Elements reused from [RFC5070] 769 are not discussed in this document. 771 5.9.2.6.2.1. Confidence element 773 REQUIRED. ENUM. The Confidence element describes a qualitative 774 assessment of the veracity of the contact information. This 775 attribute is an extension to the iodef:Contact element and is defined 776 in this document. There are five possible confidence values as 777 follows. 779 1. known-fraudulent. This contact information has been previously 780 determined to be fraudulent, either as non-existent physical 781 information or containing real information not associated with 782 this domain registration. 784 2. looks-fraudulent. The contact information has suspicious 785 information included. 787 3. known-real. The contact information has been previously 788 investigated or determined to be correct. 790 4. looks-real. The contact information does not arouse suspicion 791 but has not been previously validated. 793 5. unknown. The reporter cannot make a value judgment on the 794 contact data. 796 5.9.2.6.2.2. Ext-role attribute 798 REQUIRED. ENUM. The ext-role attribute is extended from the iodef: 799 ext-role attribute with values identified in RFC3982 [RFC3982]. The 800 ext-value value of the role attribute should be used, with the ext- 801 role attribute value chosen from one of the following values: 803 1. billingContacts 805 2. technicalContacts 807 3. administrativeContacts 809 4. legalContacts 811 5. zoneContacts 813 6. abuseContacts 815 7. securityContacts 817 8. otherContacts 819 9. hostingProvider. This contact is the hosting provider of this 820 server. Although not in RFC3982, it is useful in investigations 821 to note where the server is located and who operates it. Load 822 balanced, multicast or anycast servers may have multiple 823 hostingProvider contact entries. 825 5.9.3. SystemStatus attribute 827 REQUIRED. ENUM. The SystemStatus attribute assesses a system's 828 involvement in this event. The value is chosen from this list: 830 1. spoofed. This domain or system did not participate in this 831 event, but its address space or DNS name was simply used by 832 another party. 834 2. fraudulent. The system is operated with fraudulent intentions, 835 e.g., the domain name is a homophone. 837 3. innocent-hacked. The system was compromised by a third party and 838 used in this event. 840 4. innocent-hijacked. The IP Address or domain name was 841 deliberately hijacked via BGP or DNS and used in this event to 842 source the lure or host the collection site. 844 5. unknown. No conclusions are inferred from this event. 846 5.9.4. DomainStatus attribute 848 ENUM. The DomainStatus attribute describes the registry status of a 849 domain at the time of the report. The below enumerated list is taken 850 from the 'domainStatusType' of `[RFC3982]. An extra 'unknown' value 851 was added in case the Status is undeterminable. 853 1. reservedDelegation 855 2. assignedAndActive 857 3. assignedAndInactive 859 4. assignedAndOnHold 861 5. revoked 863 6. transferPending 865 7. registryLock 867 8. registrarLock 869 9. other 871 10. unknown 873 5.9.5. IncludedMalware element 875 Zero or One Value. The IncludedMalware element allows for the 876 identification and optional inclusion of the actual malware that was 877 part of the lure. The goal of this element is not to detail the 878 characteristics of the malware but rather to allow for a convenient 879 element to link malware to a phishing campaign. 881 +------------------+ 882 | IncludedMalware | 883 +------------------+ 884 | |<>--(1..*)--[ Name ] 885 | |<>--(0..1)--[ ds:Reference ] 886 | |<>--(0..1)--[ Data ] 887 +------------------+ 889 +-----------------------+ 890 | Data | 891 +-----------------------+ 892 | hexBinary XORPattern | 893 +-----------------------+ 895 Figure 5.7: The Included Malware element 897 5.9.5.1. Name element 899 REQUIRED. One or more value of iodef:MLStringType. This field is 900 used to identify the lure malware by its known name. Unnamed malware 901 may be identified by a value of 'unknown'. 903 5.9.5.2. Reference element 905 Zero or one value of the Reference. This optional field is used to 906 hold the Algorithm identification and value of a hash computed over 907 the malware executable. This entire element is imported from 908 [RFC3275]. Implementations SHOULD support the use of SHA-1 [SHA] as 909 a DigestMethod. 911 5.9.5.3. Data element 913 Zero or one value. The optional Data element is used to include the 914 lure malware, which is encoded as a hexBinary type and XORed with a 915 pattern to render it harmless. 917 5.9.5.3.1. XORPattern attribute 919 One value of hexBinary. The Data Element includes a 16 hexadecimal 920 character XOR Pattern attribute to support disabling the included 921 malware to bypass anti-virus filters. The default value is 922 0x55AA55AA55AA55BB which would be XOR-ed with the malware datastring 923 to recover the actual malware. 925 5.9.6. FilesDownloaded element 927 Zero or One value of a sequence of File elements. 929 +---------------------+ 930 | FilesDownloaded | 931 +---------------------+ 932 | |<>--(1..*)--[ File ] 933 +---------------------+ 935 Figure 5.8: The FilesDownloaded element 937 5.9.6.1. File element 939 One or more values of iodef:MLStringType. The File element value is 940 the name of a file downloaded by this lure. 942 5.9.7. WindowsRegistryKeysModified element 944 One or more valuev of the Key sequence. The contents of the 945 WindowsRegistryKeysModified element are sequences of Key elements. 947 +------------------------------+ 948 | WindowsRegistryKeysModified | 949 +------------------------------+ 950 | |<>--(1..*)--[ Key ] 951 +------------------------------+ 953 +--------------+ 954 | Key | 955 +--------------+ 956 | |<>-----[ Name ] 957 | |<>-----[ Value ] 958 +--------------+ 960 Figure 5.9: The WindowsRegistryKeysModified element 962 5.9.7.1. Key element 964 One or more Sequences. The key element is a sequence of Name and 965 Value pairs representing an operating system registry key and its 966 value. The key and value are encoded as in Microsoft .reg files. 967 [KB310516] 969 5.9.7.1.1. Name element 971 One STRING, representing the WINDOWS Operating System Registry Key 972 Name. The value is encoded as in Microsoft .reg files, e.g., 973 [HKEY_LOCAL_MACHINE\Software\Test\KeyName]. 975 5.9.7.1.2. Value element 977 One STRING, representing the value of the associated Key encoded as 978 in Microsoft .reg files, e.g., REG_BINARY:01. 980 5.10. OriginatingSensor Element 982 REQUIRED. The OriginatingSensor element contains the identification 983 and cognizant data of the network element that detected this fraud 984 activity. Note that the network element does not have to be on the 985 Internet itself (i.e., it may be a local IDS system) nor is it 986 required to be mechanical (e.g., humans are allowed). 988 Multiple OriginatingSensor Elements are allowed to support detection 989 at multiple locations. 991 +---------------------+ 992 | OriginatingSensor | 993 +---------------------+ 994 | ENUM OrigSensorType |<>------------[ DateFirstSeen ] 995 | |<>------------[ iodef:System ] 996 +---------------------+ 998 Figure 5.10: The OriginatingSensor element 1000 The OriginatingSensor requires a type value and identification of the 1001 entity that detected this fraudulent event. 1003 5.10.1. OrigSensorType attribute 1005 REQUIRED. ENUM. The value is chosen from the following list, 1006 categorizing the function of this sensor: 1008 1. web. A web server or service detected this event. 1010 2. webgateway. A proxy, firewall, or other network gateway 1011 detected this event. 1013 3. mailgateway. The event was detected via a mail gateway or 1014 filter 1015 4. browser. The event was detected at the user web interface or 1016 browser-type element.. 1018 5. ispsensor. The event was detected by an automated system in 1019 the network such as Intrusion Detection System, Intrusion 1020 Protection System, or other Internet Service Provider device. 1022 6. human. A non-automated system (e.g., a human, manual 1023 analysis, etc) detected this event. 1025 7. honeypot. The event was detected by receipt at a decoy 1026 device. 1028 8. other. The detection was performed via a non-listed method. 1030 5.10.2. DateFirstSeen element 1032 REQUIRED. DATETIME. This is the date and time that this sensor 1033 first saw this phishing activity. 1035 5.10.3. iodef:System element 1037 REQUIRED. One or more iodef:System. This is identification 1038 information (such as the IPVersion, IPAddress, etc) of the entity 1039 that detected this event. The ability to identify multiple 1040 detectors is supported. 1042 5.11. The DCSite element 1044 Zero or more DCSite elements. The DCSite captures the type, 1045 identifier, location, and other pertinent information about the 1046 credential gathering process, or data collection site, used in the 1047 phishing incident. The data collection site is identified by four 1048 elements: the type of collector, the network location, information 1049 about its DNS Domain, and a confidence factor. Further details about 1050 the domain, system, or owner of the DCSite can be inserted into the 1051 DomainData sub-element. 1053 If the DCSite element is present, a value is required. Multiple 1054 DCSite elements are allowed to indicate multiple collection sites for 1055 a single collector. Multiple URLs pointing to the same DNS entry can 1056 be identified with multiple SiteURL elements. 1058 +--------------+ 1059 | DCSite | 1060 +--------------+ 1061 | ENUM DCType |<>--+--------[ SiteURL ] 1062 | | +--------[ Domain ] 1063 | | +--------[ EmailSite ] 1064 | | +--------[ System ] 1065 | | +--------[ Unknown ] 1066 | |<>--(0..*)---[ iodef:Node ] 1067 | |<>--(0..1)---[ DomainData ] 1068 | |<>--(0..1)---[ iodef:Assessment ] 1069 +--------------+ 1071 Figure 5.11: The DCSite element 1073 5.11.1. DCType attribute 1075 REQUIRED. ENUM. The DCType attribute identifies the method of data 1076 collection as determined through the analysis of the victim computer, 1077 lure, or malware. This attribute coupled with the DCSite content 1078 identifies the data collection site. 1080 1. web. The user is redirected to a website to collect the data. 1082 2. email. The victim sends an email with credentials enclosed. 1084 3. keylogger. Some form of keylogger is downloaded to the victim. 1086 4. automation. Other forms of automatic data collection, such as 1087 background OLE automation, are used to capture information on the 1088 user's machine. 1090 5. unspecified. 1092 5.11.2. DCSite values 1094 REQUIRED. The DCSite element contains the IPAddress, URL, emailsite, 1095 or other identifier of the credentail or data collection site. The 1096 Domain choice may be used to identify entire 'phishy' domains like 1097 those used for the RockPhish and related malware. Each DCSite 1098 element also includes a confidence attribute to convey the reporter's 1099 assessment of their confidence that this DCSite element is valid, and 1100 involved with this event. The confidence value is a per-DCSite value 1101 as multiple-site data collectors may have different confidence 1102 values. 1104 The DCSite element is a choice of: 1106 1. SiteURL. One value of iodef:MLStringType. This choice supports 1107 URIs and other web-based identifiers. 1109 2. Domain. One value of iodef:MLStringType. This choice allows the 1110 entry of a DNS Domain name. 1112 3. EmailSite. One value of iodef:MLStringType. This choice 1113 includes an email address if the site used email communications. 1115 4. iodef:Address. One value of iodef:Address element. This choice 1116 is used to capture the IP Address of a site. 1118 5. Unknown. One value of iodef:MLStringType. The unknown entry is 1119 used for exception to the preceding choices. 1121 5.11.2.1. Confidence attribute 1123 One Value of STRING. The confidence attribute is a value between 0 1124 and 100 representing the reporter's certainty that this is a genuine 1125 phishing site. A value of 0 represents a false positive; a value of 1126 100 signifies that the reporter has independently verified this site. 1128 5.11.3. iodef:Node 1130 Zero or more values of iodef:Node. This element is used to identify 1131 the IP Address(es) or DNS Names associated with the DCSite element 1132 value. 1134 5.11.4. DomainData element 1136 Zero or One value of DomainData Section 5.9.2. This element allows 1137 for the identification of data associated with the data collection 1138 site. 1140 5.11.5. iodef:Assessment element 1142 Zero or One value of iodef:Assessment. This element is used to 1143 designate different confidence levels of multiple-site data 1144 collectors. 1146 5.12. TakeDownInfo element 1148 Zero or more TakeDownInfo elements. This element identifies the 1149 agent or agency that performed the removal, DNS domain disablement, 1150 or ISP-blockage of the phish or fraud collector site. A PhraudReport 1151 may have multiple TakeDownInfo elements to support activities where 1152 multiple take down activities are involved on different dates. Note 1153 that the term "Agency" is used to identify any party performing the 1154 blocking or removal such as ISPs or private parties, not just 1155 government entities. 1157 The TakeDownInfo element allows one date element with multiple 1158 TakeDownAgency and Comment elements to support operations using 1159 multiple agencies. 1161 +-------------------+ 1162 | TakeDownInfo | 1163 +-------------------+ 1164 | |<>---(0..1)--[ TakeDownDate ] 1165 | |<>---(0..*)--[ TakeDownAgency ] 1166 | |<>---(0..*)--[ TakeDownComments ] 1167 +-------------------+ 1169 Figure 5.12: The TakeDownInfo element 1171 5.12.1. TakeDownDate 1173 Zero or one DATETIME. This is the date and time that take down of 1174 the collector site occurred. 1176 5.12.2. TakeDownAgency 1178 Zero or more iodef:MLStringType elements. This is a free form string 1179 identifying the agency, corporation, or cooperative that performed 1180 the take down. 1182 5.12.3. TakeDownComments 1184 Zero or more iodef:MLStringType elements. A free form field to add 1185 any additional details of this take down effort or to identify 1186 parties that assisted in the effort at an ISP, CERT, or DNS Registry. 1188 5.13. ArchivedData element 1190 Zero or more values of the ArchivedData element are allowed. 1192 +-------------------+ 1193 | ArchivedData | 1194 +-------------------+ 1195 | ENUM type |<>---(0..1)--[ URL ] 1196 | |<>---(0..1)--[ Comments ] 1197 | |<>---(0..1)--[ Data ] 1198 +-------------------+ 1200 Figure 5.13: The ArchivedData element 1202 The ArchivedData element is populated with a pointer to the contents 1203 of a data collection site, base camp (i.e., development site), or 1204 other site used by a phisher. The ArchivedDataInfo may also include 1205 a copy of the archived data recovered from a phishing system. This 1206 element will be populated when, for example, an ISP takes down a 1207 phisher's web site and has copied the site data into an archive file. 1209 There are four types of archives currently supported, as specified in 1210 the type field. 1212 5.13.1. type attribute 1214 REQUIRED. This parameter specifies the type of site data pointed to 1215 by the ArchivedDataURL, from the following list: 1217 1. collectionsite. The archive is a set of files from the 1218 collection site. 1220 2. basecamp. The contents of a criminal development site are 1221 included in the archive. 1223 3. sendersite. The archive is a set of files or data from a 1224 phishing lure sending site. 1226 4. credentialInfo. The included archive are recovered private 1227 credentials. 1229 5. unspecified. The archive contents does not fit into one of the 1230 above categories and will be described in the DataComments 1231 element. 1233 5.13.2. URL element 1235 Zero or one value of anyURL. As the archive of an entire site can be 1236 quite large, the URL element points to an Internet-based server where 1237 the actual content of the site archive can be retrieved. Note that 1238 this element just points out where the archive is and does not 1239 include the entire archive in the report. This is the URL where the 1240 archive file is located. 1242 5.13.3. Comments element 1244 Zero or one value of iodef:MLStringType. This field is a free form 1245 area for comments on the archive and/or URL. 1247 5.13.4. Data element 1249 Zero or one value of xs:Base64Binary. This field contains a base64 1250 encoded version of the data described in the comment field above. 1252 5.14. RelatedData element 1254 Zero or more value of anyURI. This element allows the listing of 1255 other web or net sites that are related to this incident (e.g., 1256 victim site, etc.). 1258 5.15. CorrelationData element 1260 Zero or more value of iodef:MLStringType. Any information that 1261 correlates this incident to other incidents can be entered here. 1263 5.16. PRComments element 1265 Zero or one value of iodef:MLStringType. This field allows for any 1266 comments specific to this PhraudReport that does not fit in any other 1267 field. 1269 5.17. EmailRecord element 1271 This element supports the inclusion of the actual email message 1272 received as a phishing lure. Inclusion of the actual mail message is 1273 supported by two methods; either the message may be included as one 1274 large string, or the header and body components may be dissected and 1275 included as a series of strings. 1277 +--------------------+ 1278 | EmailRecord | 1279 +--------------------+ 1280 | |<>--------------[ EmailCount ] 1281 | |<>--(0..1)------[ EmailMessage ] 1282 | |<>--(0..1)------[ EmailComments ] 1283 +--------------------+ 1285 Figure 5.14: The EmailRecord element 1287 5.17.1. EmailCount element 1289 REQUIRED. INTEGER. This field enumerates the number of email 1290 messages identified in this record as detected by the reporter. 1292 5.17.2. EmailMessage element 1294 Zero of one value of iodef:MLStringType. The entire SMTP mail 1295 message - RFC822 header followed by body as specified in [RFC5322] - 1296 should be inserted as one large text string. In some communities 1297 this combination is known as the message contents and full headers. 1299 5.17.3. EmailComments element 1301 Zero or one value of iodef:MLStringType elements. This field 1302 contains comments or relevant data not placed elsewhere about the 1303 phishing email. 1305 6. Mandatory IODEF and PhraudReport Elements 1307 A report about fraud or phishing requires certain identifying 1308 information which is contained within the standard IODEF Incident 1309 data structure and the PhraudReport extensions. The following table 1310 identifies attributes required to be present in a compliant 1311 PhraudReport to report phishing or fraud. The required attributes 1312 are a combination of those required by the base IODEF element, as 1313 shown in figure 6.1, and those required by this document, shown in 1314 figure 6.2. Attributes identified as required SHALL be populated in 1315 conforming phishing activity reports. 1317 A compliant IODEF PhraudReport SHALL contain the following elements 1318 and attributes: 1319 +--------------+ 1320 | Incident | 1321 +--------------+ 1322 | ENUM Purpose |---[ IncidentID ] 1323 | |---[ ReportTime ] 1324 | |---[ Assessment ] 1325 | | ---> [ Impact ] 1326 | |---[ Contact ] 1327 | | ---> [ @type ] 1328 | | ---> [ @role ] 1329 | | ---> [ * ] 1330 | |---[ EventData ] 1331 | | ---> [ DetectTime ] 1332 | | ---> [ AdditionalData ] 1333 | | ---> [ PhraudReport ] 1334 +--------------+ 1335 Figure 6.1. IODEF Required classes for a PhraudReport 1337 +----------------+ 1338 | PhraudReport | 1339 +----------------+ 1340 | ENUM FraudType |---[ LureSource ] 1341 | STRING Version | ---> [ iodef:System ] 1342 | |---[ OriginatingSensor ] 1343 | | --> [ DateFirstSeen ] 1344 | | --> [ iodef:System ] 1345 | | --> [ iodef:Node ] 1346 | | 1347 +----------------+ 1349 Figure 6.2 PhraudReport Required Elements. 1351 * Note that the iodef:Contact element is required, but none of its 1352 sub-elements are required. For proper XML correctness, one of the 1353 sub-elements is required; pick one. 1355 6.1. Guidance on Usage 1357 It may be apparent that the mandatory attributes for a PhraudReport 1358 make for a quite sparse report. As incident forensics and data 1359 analysis require detailed information, the originator of a 1360 PhraudReport SHOULD include any tidbit of information gleaned from 1361 the attack analysis. Information that is considered sensitive can be 1362 marked as such using the restriction parameter of each data element. 1364 The reporting party is encouraged to provide more than just the 1365 minimally required data elements about an event in a PhraudReport. 1366 The additional information may be volatile and not recoverable in the 1367 future, and may be useful in answering investigation questions or in 1368 performing correlation with other reported events. 1370 7. Security Considerations 1372 This document specifies a format for encoding a particular class of 1373 security incidents appropriate for exchange across organizations. As 1374 merely a data representation, it does not directly introduce security 1375 issues. However, it is guaranteed that parties exchanging instances 1376 of this specification will have certain concerns. For this reason, 1377 the underlying message format and transport protocol used MUST ensure 1378 the appropriate degree of confidentiality, integrity, and 1379 authenticity for the specific environment. 1381 Organizations that exchange data using this document are URGED to 1382 develop operating procedures that document the following areas of 1383 concern. 1385 7.1. Transport-specific concerns 1387 The critical security concerns are that phishing activity reports may 1388 be falsified or the PhraudReport may become corrupt during transit. 1389 In areas where transmission security or secrecy is questionable, the 1390 application of a digital signature and/or message encryption on each 1391 report will counteract both of these concerns. We expect that each 1392 exchanging organization will determine the need, and mechanism, for 1393 transport protection.. 1395 7.2. Using the iodef:restriction attribute 1397 In some instances data values in particular elements may contain data 1398 deemed sensitive by the reporter. Although there are no general- 1399 purpose rules on when to mark certain values as "private" or "need- 1400 to-know" via the iodef:restriction attribute, the reporter is 1401 cautioned to not apply element-level sensitivity markings unless they 1402 believe the receiving party (i.e., the party they are exchanging the 1403 event report data with) has a mechanism to adequately safeguard and 1404 process the data as marked. For example, if the PhraudReport element 1405 is marked private and contains a phishing collector URL in the 1406 DCSite/SiteURL element, can that URL be included within a block list 1407 distributed to other parties? No guidance is provided here except to 1408 urge exchanging parties to review the IODEF and PhraudReport 1409 documents to decide on common marking rules. 1411 8. IANA Considerations 1413 This document uses URNs to describe XML namespaces and XML schemas 1414 conforming to a registry mechanism described in "RFC3688". 1416 Registration request for the IODEF phishing namespace: 1418 URI: urn:ietf:params:xml:ns:iodef-phish-1.0 1420 Registrant Contact: See the "Author's Address" section of this 1421 document. 1423 XML: None. 1425 Registration request for the IODEF phishing extension XML schema: 1427 URI: urn:ietf:params:xml:schema:iodef-phish-1.0 1429 Registrant Contact: See the "Author's Address" section of this 1430 document. 1432 XML: See the "Phishing Extensions Schema Definition" in the 1433 section of this document. 1435 9. Contributors 1437 The extensions are an outgrowth of the Anti-Phishing Working Group 1438 (APWG) activities in data collection and sharing of phishing and 1439 other ecrime-ware. (The APWG has no relationship to an IETF working 1440 group.) 1442 This document has received significant assistance from members of the 1443 IETF INCH working group and two groups addressing the phishing 1444 problem: members of the APWG and participants in the Financial 1445 Services Technology Consortium's Counter-Phishing project. A special 1446 thanks goes to the hardy people who supplied valuable feedback after 1447 using this format to report phishing. 1449 10. References 1451 10.1. Normative References 1453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1454 Requirement Levels", BCP 14, RFC 2119, March 1997. 1456 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1457 Language) XML-Signature Syntax and Processing", RFC 3275, 1458 March 2002. 1460 [RFC3982] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) 1461 Type for the Internet Registry Information Service 1462 (IRIS)", RFC 3982, January 2005. 1464 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1465 Object Description Exchange Format", RFC 5070, 1466 December 2007. 1468 [SHA] National Institute of Standards and Technology, U.S. 1469 Department of Commerce, "Secure Hash Standard", 1470 FIPS 180-2, August 2002. 1472 10.2. Informative References 1474 [KB310516] 1475 Microsoft Corporation, "How to add, modify, or delete 1476 registry subkeys and values by using a registration 1477 entries (.reg) file", December 2007. 1479 [RFC3688] Mealing, M., "The IETF XML Registry", RFC 3688, 1480 January 2004. 1482 Appendix A. Appendix A. Phishing Extensions XML Schema 1484 1485 1493 1497 1501 1517 1518 1519 1520 1522 1524 1526 1528 1530 1533 1535 1537 1539 1541 1543 1545 1547 1549 1551 1554 1555 1556 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1572 1578 1584 1585 1586 1589 1592 1595 1596 1597 1598 1600 1601 1602 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1621 1624 1625 1626 1628 1629 1630 1631 1632 1633 1635 1636 1637 1638 1639 1640 1642 1648 1649 1650 1651 1653 1655 1656 1658 1664 1665 1666 1667 1668 1669 1670 1671 1673 1674 1675 1676 1678 1679 1680 1681 1682 1683 1684 1685 1686 1688 1689 1690 1691 1692 1693 1694 1695 1696 1698 1699 1700 1701 1702 1703 1704 1705 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1720 1722 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1737 1743 1744 1745 1746 1748 1750 1752 1754 1756 1757 1758 1759 1760 1761 1762 1763 1764 1766 1767 1769 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1804 1805 1806 1807 1808 1809 1810 1811 1813 1814 1815 1816 1817 1818 1820 1821 1823 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1843 1849 1850 1851 1852 1854 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1869 1870 1871 1873 1879 1881 1882 1883 1886 1889 1891 1892 1894 1900 1902 1903 1904 1905 1907 1909 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1924 1925 Appendix B. Example Virus Report 1927 This section shows a received electronic mail message that included a 1928 virus in a zipped attachment and a report that was generated for that 1929 message. 1931 B.1. Received Email 1933 From: support@example.com 1934 Sent: Friday, June 10, 2005 3:52 PM 1935 To: someone@example.com 1936 Subject: Account update 1938 To: someone@example.com 1939 Date: Sun, 10 May 2005 3:52:44 +0200 1941 We would like to inform you that we have released a new version of our 1942 Customer Form. This form is required to be completed by all customers. 1944 Please follow these steps: 1946 1.Open the form at http://www.example.com/customerservice/cform.php 1947 . 1949 2.Follow given instructions. 1951 Thank you, 1952 Our Support Team 1954 B.2. Generated Report 1956 NOTE: Some wrapping and folding liberties have been applied to fit it 1957 into the margins. 1959 1960 1964 1965 PAT2005-06 1966 2005-06-22T08:30:00-05:00 1967 This is a test report from actual data. 1968 1969 1970 1971 1972 1973 1974 patcain 1975 pcain@coopercain.com 1976 1977 1978 2005-06-21T18:22:02-05:00 1979 1980 1981 1982 Subject: You have successfully updated your password 1983 1984 Cooper-Cain 1985 1986 1987 1988 1989
192.0.2.18
1990 1991 1992 1993 W32.Mytob.EA@mm 1994 1995 1996 1997 2005-06-10T15:52:11-05:00 1998 1999 2000 2001
192.0.2.13
2002 2003 2004 2005 2006 1 2007 2008 Return-path: <support@example.com> 2009 to: pcain@example.com 2010 Delivery-date: Fri, 10 Jun 2005:52:11-0400 2011 Received: from dsl18-2-0-192.dsl.example.net([192.0.2.18] 2012 helo=example.com) by mail06.example.com esmtp (Exim) id 2013 1DgpXy-0002Ua-IR for pcain@example.com;, 2014 10 Jun 2005 15:52:10-0400 2015 From: support@example.com 2016 To: pcain@example.com 2017 Subject: You have successfully updated your password 2018 Date: Fri, 10 Jun 2005 12:52:00 -0700 2019 MIME-Version: 1.0 2020 Type: multipart/mixed; 2021 ="----=_NextPart_000_0008_0911068B.E7EB6D2A" 2022 X-Priority: 3MSMail-Priority: Normal 2023 X-EN-OrigIP: 192.0.2.18 2024 EN-OrigHost: dsl18-2-0-192.dsl.example.net 2025 Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) 2026 on.example.net 2027 X-Spam-Level: ***** X-Spam-Status: No, 2028 score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30, 2029 HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE, 2030 NO_REAL_NAME, 2031 PRIORITY_NO_NAME autolearn=disabled version=3.0.2 2033 From:support@example.com 2034 Sent: Friday, June 10, 2005 3:52 PM 2035 Subject: Account update 2037 To: someone@example.com 2038 Date: Sun, 10 June 2005 3:52:44 +0200 2040 We would like to inform you that we have released a new version of our 2041 Customer Form. This form is required to be completed by all customers. 2043 Please follow these steps: 2045 1.Open the form at http://www.example.com/customerservice/cform.php 2046 <http://www.2.example.com/customerservice/cform.php 2047 &email=(someone@example.com)> . 2048 2.Follow given instructions. 2050 Thank you, 2051 Our Support Team 2052 2053 2054 2055 2056 2057 2058 2060 Appendix C. Sample Phishing Report 2062 A sample report generated from a received electronic mail phishing 2063 message in shown in this section. 2065 C.1. Received Lure 2067 Return-path: 2068 Envelope-to: pcain@example.com 2069 Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400 2070 Received: from mail15.example.com ([10.1.1.161] 2071 helo=mail15.example.com) 2072 by mailscan38.example.com with esmtp (Exim) 2073 id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006 2074 05:37:21 -0400 2075 Received: from [192.0.2.61] (helo=TSI) 2076 by mail15.example.com with 2077 esmtp (Exim) id 1Fq5Bj-0006dv-6b 2078 for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400 2079 Received: from User ([192.0.2.157]) by TSI with 2080 Microsoft SMTPSVC(5.0.2195.6713); 2081 Tue, 13 Jun 2006 02:24:30 -0400 2082 Reply-To: 2083 From: "company" 2084 Subject: * * * Update & Verify Your Example Company Account * * * 2085 Date: Tue, 13 Jun 2006 02:36:34 -0400 2086 MIME-Version: 1.0 2087 Content-Type: text/html; charset="Windows-1251" 2088 Content-Transfer-Encoding: 7bit 2089 X-Priority: 1 2090 X-MSMail-Priority: High 2091 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 2092 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 2093 Bcc: 2094 Message-ID: 2095 X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC) 2096 FILETIME=[072A66A0:01C68EB2] 2097 X-EN-OrigSender: service@example.com 2098 X-EN-OrigIP: 192.0.2.1 2099 X-EN-OrigHost: unknown 2101 Company 2102 2103 2104 2105 Account Update Request 2106 Dear Example. member:, 2108 You are receiving this notification because company is required by 2109 law to notify you, that you urgently need to update your online 2110 account statement, due to high risks of fraud intentions. 2112 The updating of your example account can be done at any time by 2113 clicking on the link shown below 2114 http://www.example.com/cgi-bin/webscr?cmd=_login-run 2115 2119 Once you log in,update your account information. 2120 After updating your account click on the History sub tab of your 2121 Account Overview page to see your most recent statement. 2123 If you need help with your password, click the Help link which is at 2124 the upper right hand side of the company website. To report errors 2125 in your statement or make inquiries, click the Contact Us link in the 2126 footer on any page of the company website, call our Customer Service 2127 center at (999) 555-0167, or write us at: 2129 Company, Inc. 2130 P.O. Box 0 2131 Anytown, MA 00000 2133 Sincerely, 2135 Big Example Company 2137 2139 C.2. Phishing Report 2141 2142 2145 2147 CC200600000002 2148 2006-06-13T21:14:56-05:00 2149 This is a sample phishing email received report. 2151 The phish was actually received as is. 2152 2153 2154 85 2155 2156 2157 patcain 2158 pcain@example.com 2159 2160 2161 2006-06-13T05:37:21-04:00 2162 2163 2164 2165 * * * Update & Verify Your Company Account * * * 2166 2167 company 2168 2169 2170 2171
192.0.2.4
2172 2173 2174 2175 2176 2177 2006-06-13T05:37:22-04:00 2178 2179 2180 2181 2182 2183 2184 2185 1 2186 2187 Return-path: <service@example.com> 2188 Envelope-to: pcain@example.com 2189 Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400 2190 Received: from mail15.example.com ([10.1.1.161] 2191 helo=mail15.example.com) 2192 by mailscan38.example.com with esmtp (Exim) 2193 id 1Fq5Kr-0005wU-LT for pcain@example.com; Tue, 13 Jun 2006 2194 05:37:21 -0400 2195 Received: from [192.0.2.61] (helo=TSI) 2196 by mail15.example.com with 2197 esmtp (Exim) id 1Fq5Bj-0006dv-6b 2198 for pcain@example.com; Tue, 13 Jun 2006 05:37:21 -0400 2199 Received: from User ([192.0.2.157]) by TSI with 2200 Microsoft SMTPSVC(5.0.2195.6713); 2201 Tue, 13 Jun 2006 02:24:30 -0400 2202 Reply-To: <nospam@example.org> 2203 From: "company"<service@example.com> 2204 Subject: * * * Update & Verify Your Example Company Account * * * 2205 Date: Tue, 13 Jun 2006 02:36:34 -0400 2206 MIME-Version: 1.0 2207 Content-Type: text/html; charset="Windows-1251" 2208 Content-Transfer-Encoding: 7bit 2209 X-Priority: 1 2210 X-MSMail-Priority: High 2211 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 2212 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 2213 Bcc: 2214 Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI> 2215 X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC) 2216 FILETIME=[072A66A0:01C68EB2] 2217 X-EN-OrigSender: service@example.com 2218 X-EN-OrigIP: 192.0.2.1 2219 X-EN-OrigHost: unknown 2221 <img src="http://www.example.com/images/company_logo.gif"> 2222 <img src="http://www.example.com/images/pixel.gif"> 2223 <img src="http://www.example.com/images/pixel.gif"> 2224 <img src="http://www.example.com/im/pixel.gif"> 2225 Account Update Request 2227 Dear Example. member:, 2228 You are receiving this notification because company is required by 2229 law to notify you, that you urgently need to update your online 2230 account statement, due to high risks of fraud intentions. 2232 The updating of your example account can be done at any time by 2233 clicking on the link shown below 2234 <a href="http://192.0.2.41:8080/.cgi-bin/.webscr/.secure- 2235 login/%20/%20/.example.com/index.htm"> 2236 http://www.example.com/cgi-bin/webscr?cmd=_login-run </a> 2238 Once you log in,update your account information. 2239 After updating your account click on the History sub tab of your 2240 Account Overview page to see your most recent statement. 2242 If you need help with your password, click the Help link which is at 2243 the upper right hand side of the company website. To report errors in 2244 your statement or make inquiries, click the Contact Us link in the 2245 footer on any page of the company website, call our Customer Service 2246 center at (999) 555-0167, or write us at: 2248 Company, Inc. 2249 P.O. Box 0 2250 Anytown, MA 00000 2252 Sincerely, 2254 Big Example Company 2256 <img src="http://www.example.com/images/dot_row_long.gif"> 2257 2258 2259 2260 http://190.0.2.41:8080/.cgi-bin/.webscr/.secure- 2261 login/%20%20/.company.com/index.htm 2262 2264 bad.example.com 2265 2006-06-14T13:05:00-05:00 2266 2267 2268 2000-12-13T00:00:00 2269 2270 ns1.example.net 2271
192.0.2.18
2272 2273 2274 2275 2276 2277 2278 2279 2281 Authors' Addresses 2283 Patrick Cain 2284 The Cooper-Cain Group, Inc. 2285 P.O. Box 400992 2286 Cambridge, MA 2287 USA 2289 Email: pcain@coopercain.com 2291 David Jevans 2292 The Anti-Phishing Working Group 2293 5150 El Camino Real, Suite A20 2294 Los Altos, CA 94022 2295 USA 2297 Email: dave.jevans@antiphishing.org