idnits 2.17.1 draft-ietf-inch-phishingextns-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2292. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 14, 2006) is 6519 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) == Unused Reference: 'RFC3733' is defined on line 1343, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IODEF' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' -- Obsolete informational reference (is this intentional?): RFC 3733 (Obsoleted by RFC 4933) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INCH P. Cain 3 Internet-Draft The Cooper-Cain Group, Inc. 4 Expires: December 16, 2006 D. Jevans 5 The Anti-Phishing Working Group 6 June 14, 2006 8 Extensions to the IODEF-Document Class for Phishing, Fraud, and Other 9 Crimeware 10 draft-ietf-inch-phishingextns-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 16, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document extends the INCH WG's IODEF XML incident reporting 44 format for reporting phishing, fraud, other types of electronic 45 crime, and widespread spam incidents. Although the term "phishing 46 attack" is used, the data format extensions are flexible enough to 47 support information gleaned from activities throughout the entire 48 electronic fraud life cycle and extensible enough to be used for 49 other types of electronic crime incidents, along with simple spam. 50 The extensions support very simple reporting as well as optional 51 fields for detailed forensic reports, and support single phish/fraud 52 incidents as well as consolidated reports of multiple phish 53 incidents. 55 Sections 1 and 2 of this document introduce the high-level report 56 format. Sections 3 and 4 describe the data elements of the fraud 57 extensions. This document includes an XML schema for the extensions 58 and a few example fraud reports. 60 RFC 2129 Keywords 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described inRFC 2119 [RFC2119]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Why a Common Report Format is Needed . . . . . . . . . . . 4 70 1.2. Relation to the INCH IODEF Data Model . . . . . . . . . . 5 71 2. The Elements of Phishing/Fraud Activity . . . . . . . . . . . 7 72 3. Fraud Actvitiy Reporting via an IODEF-Document Incident . . . 8 73 4. PhraudReport Element Definitions . . . . . . . . . . . . . . . 10 74 4.1. Version parameter . . . . . . . . . . . . . . . . . . . . 11 75 4.2. Identifying A Fraud campaign . . . . . . . . . . . . . . . 11 76 4.3. FraudedBrandName Element . . . . . . . . . . . . . . . . . 13 77 4.4. LureSource Element . . . . . . . . . . . . . . . . . . . . 13 78 4.5. OriginatingSensor Element . . . . . . . . . . . . . . . . 20 79 4.6. The Data Collection Site Element (DCSite) . . . . . . . . 22 80 4.7. TakeDownInfo Element . . . . . . . . . . . . . . . . . . . 23 81 4.8. ArchivedData Element . . . . . . . . . . . . . . . . . . . 24 82 4.9. RelatedData Element . . . . . . . . . . . . . . . . . . . 25 83 4.10. CorrelationData Element . . . . . . . . . . . . . . . . . 25 84 4.11. PRComments Element . . . . . . . . . . . . . . . . . . . . 25 85 4.12. EmailRecord Element . . . . . . . . . . . . . . . . . . . 25 86 5. IODEF Required Elements . . . . . . . . . . . . . . . . . . . 28 87 5.1. Fraud or Phishing Report . . . . . . . . . . . . . . . . . 28 88 5.2. Wide-Spread Spam Report . . . . . . . . . . . . . . . . . 29 89 5.3. Guidance on Usage . . . . . . . . . . . . . . . . . . . . 30 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 92 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 34 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 34 96 Appendix A. Phishing Extensions XML Schema . . . . . . . . . . . 35 97 Appendix B. Sample Malware Email Report . . . . . . . . . . . . . 47 98 B.1. Received Email . . . . . . . . . . . . . . . . . . . . . . 47 99 B.2. Generated Report . . . . . . . . . . . . . . . . . . . . . 47 100 B.3. Notes and Commentary . . . . . . . . . . . . . . . . . . . 49 101 Appendix C. Sample Phish Email Report . . . . . . . . . . . . . . 50 102 C.1. Received Lure . . . . . . . . . . . . . . . . . . . . . . 50 103 C.2. Phishing Report . . . . . . . . . . . . . . . . . . . . . 51 104 C.3. Notes and Commentary . . . . . . . . . . . . . . . . . . . 55 105 Appendix D. Sample Spam Report . . . . . . . . . . . . . . . . . 56 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 107 Intellectual Property and Copyright Statements . . . . . . . . . . 58 109 1. Introduction 111 Deception activities on the Internet, such as receiving an email 112 purportedly from a bank requesting you to confirm your account 113 information, are an expanding attack type in the Internet. For this 114 document, the two terms phishing and fraud are used interchangeably 115 and characterize as broadly-launched social engineering attacks in 116 which an electronic identity is misrepresented in an attempt to trick 117 individuals into revealing their personal credentials ( e.g., 118 passwords, account numbers, personal information, ATM PINs). A 119 successful phishing attack on an individual allows the phisher (i.e., 120 attacker) to exploit the individual's credentials for financial or 121 other gain. Early phishing attacks were directed at individuals via 122 email as a ruse from a bank security department, requesting the 123 user's ATM number and PIN. Once phished, the bank account could be 124 used by the phisher to perpetrate additional fraud, money laundering, 125 or plain emptying of the account. As individuals became more aware 126 of phishing tactics, the phishers have evolved into using more 127 complex and stealthier technologies targeting institutions such as 128 ISPs and corporations other than banks. These attacks have now 129 morphed to use the lure to deliver all types of malware and other 130 crimeware onto users' computers. Other miscreants are also using 131 these same techniques for other types of Internet attacks. 133 1.1. Why a Common Report Format is Needed 135 The rise in phishing and fraud activities via e-mail, instant 136 message, DNS corruption, and malicious code insertion has driven 137 corporations, Internet Service Providers, consumer agencies, and 138 financial institutions to begin to collect and correlate phishing 139 attack information. The data collected allows them to better plan 140 out mitigation activities and to initiate or assist in prosecution of 141 the attacker. Early on it became obvious that a common format for 142 the data reported or exchanged between these parties was necessary. 143 The IETF INCH XML format was selected for this use as it was already 144 becoming a standard way of sharing this type of information. 145 Although originally designed for network-layer incident sharing 146 (e.g., DoS attacks, compromised computers) the INCH format can be 147 extended quite easily to support other incident profiles, as we show 148 in this document. 150 The use of a common format will help organizations integrate multiple 151 product outputs into a cohesive single attack view. It will also 152 allow for the introduction of advanced services such as wholly 153 automatic local notifications and usable data mining. 155 The accumulation and correlation of information is very important 156 when dealing with security incidents. In phishing attacks 157 specifically, the attack source may be misrepresented or forged. The 158 targeted organization may not even be aware of the ongoing attack. 159 Third parties aware of the attack may wish to notify the targeted 160 organization or a central notification service. The targeted 161 organization's internal monitoring systems may also detect the attack 162 and wish to take mitigation steps. Without this document, there is 163 no recognized standard format to express the detection of a phishing 164 attack or to exchange detailed information about it. For an 165 organization that employs multi anti-phishing technologies, 166 correlating data from multiple vendors or products is close to 167 impossible as the data is reported in multiple, mostly incompatible, 168 formats. 170 This document defines a data format extension to IODEF that is used 171 to capture relevant information from a phishing attack and shared, 172 correlated, or to populate a database. Additionally, the use of 173 products that export information in this format will allow an 174 organization to correlate and analyze phishing information across 175 their organization. Although targeted at both the accumulation of 176 phishing attack information from a single institution and a means of 177 sharing attack information between cooperating parties, the actual 178 information sharing process and related political challenges are not 179 covered in this document. 181 1.2. Relation to the INCH IODEF Data Model 183 Instead of defining report format and language from scratch, the 184 phishing activities information is encoded as XML extensions to the 185 Incident Object Description Exchange Format Data Model[IODEF]. The 186 use of this already existent and operational format, based on the 187 Intrusion Detection Message Exchange Format[IDMEF], allows for 188 quicker vendor adoption and reuse of existing tools in organizations. 189 To reduce duplication and to be compatible with forward modifications 190 to the base IODEF definitions, this document only identifies 191 additional structures necessary for exchanging phishing and e-crime 192 information. 194 The goal of using a common format is to be simple and efficient, and 195 to support additional data to be included to provide a complete 196 picture of the event, when necessary. One criticism of the IODEF 197 format is that it is too cumbersome (i.e., large and complex) to be 198 used in an efficient manner for something as simple as fraud events. 199 The IODEF format has very few required elements to allow for 200 efficiency, but allows extremely verbose elements to be used if 201 supporting data is available. This flexibility allows the IODEF 202 formats to be used in a wide range of event reports but only requires 203 the product developer to support one format standard. 205 1.2.1. The IODEF Extensions for Fraud 207 In general, an IODEF incident report contains detailed incident- 208 specific data which populates an EventData Structure. That data is 209 then incorporated, either singularly or in aggregation, with 210 additional summary and contact data, into an Incident structure. 212 A Fraud Activity Report is an instance of an XML IODEF-Document with 213 added EventData and AdditionalData elements. It contains the 214 Incident structure and additional fields in the EventData specific to 215 phishing and fraud (the PhraudReport). Phishing activity may include 216 multiple email, instant message, or network messages, scattered over 217 various times, locations, and methodologies. The new EventData 218 fields are combined into a Fraud Activity Report and include 219 information about the email header and body, details of the actual 220 phishing lure, correlation to other attacks, and details of the 221 removal of the web server or credential collector. As a phishing 222 attack may generate multiple reports to an incident team, the Fraud 223 Activity Reports may be combined into one EventData structure. 224 Multiple EventData structures may be combined into one Incident 225 Report. One IODEF Incident report may record one or more individual 226 phishing events and may include multiple EventData elements. 228 This document defines new elements for the EventData and Record Item 229 IODEF XML elements and identifies the Fraud Activity Report required 230 attributes. The Appendices contain sample Fraud Activity Reports and 231 a complete Schema. 233 The IODEF Extensions defined in this document comply with section4, 234 "Extending the IODEF Format" in[IODEF]. 236 As both the IODEF-Document and PhraudReport documents have many 237 options a companion implementer's guide and report examples document 238 is being developed to assist implementers with consistency. 240 2. The Elements of Phishing/Fraud Activity 242 +-----------+ +------------------+ 243 | Fraudster |<---<-- | Collection Point |<---O--<----<----+ 244 +----+------+ +------------------+ | | 245 ^ | | 246 | +--|-----+ ^ 247 | | Sensor | Credentials 248 | +-|------+ | 249 | +---------------+ | +-------+ 250 \--->--| Attack Source |--Phish-->-----O------> | User/ | 251 +---------------+ |Victim | 252 +-------+ 254 Internet-based Phishing and Fraud activities are normally comprised 255 of at least four components. 257 1. The Phisher, Fraudster, or party perpetrating the fraudulent 258 activity. Most times this party is not readily identifiable. 260 2. The Attack Source, where the phishing email, virus, trojan, or 261 other attack is generated. 263 3. The User, Victim, or intended target of the fraud/phish. 265 4. The collection point, where the victim sends their credentials 266 or personal data if they have been duped by the phisher. 268 If we take a holistic view of the attack, there are some additional 269 components: 271 5. The sensor, which is something that detects the fraud/phish 272 attempt or success. This element may be an intrusion detection 273 system, firewall, filter, email gateway, or human. 275 6. A forensic or archive site where an investigator has copied or 276 otherwise retained the data used for the fraud attempt or 277 credential collection. 279 3. Fraud Actvitiy Reporting via an IODEF-Document Incident 281 A Fraud Activity Report is an instance of an XML IODEF-Document with 282 added EventData, AdditionalData elements. The added elements compose 283 a PhraudReport Element. Required information with many optional 284 items is populated into the PhraudReport structure to form a Fraud 285 Activity Report. To facilitate usefulness, the report originator 286 should fill out all mandatory items and as many as necessary optional 287 Incident element fields, to stay consistent with the IODEF-Document 288 structure. 290 This document defines new EventData IODEF XML elements; then 291 identifies attributes that are required in a compliant Fraud Activity 292 Report. The Appendices contain sample Fraud Activity Reports and the 293 complete XML Document Type Definition and schema. 295 The Incident element with fraud extensions is summarized below. It 296 provides a standardized representation for commonly exchanged 297 incident data and associates a CSIRT assigned unique identifier with 298 the described activity. The data elements in this document are 299 expressed in Unified Modeling Language (UML) syntax. 301 +-------------------+ 302 | Incident | 303 +-------------------+ 304 | ENUM purpose |<>----------[ IncidentID ] 305 | ENUM restriction |<>--{0..1}--[ AlternativeID ] 306 | |<>--{0..1}--[ RelatedActivity ] 307 | |<>--{0..*}--[ Description ] 308 | |<>--{1..*}--[ Assessment ] 309 | |<>--{0..*}--[ Method ] 310 | |<>--{0..1}--[ DetectTime ] 311 | |<>--{0..1}--[ StartTime ] 312 | |<>--{0..1}--[ EndTime ] 313 | |<>----------[ ReportTime ] 314 | |<>--{1..*}--[ Contact ] 315 | |<>--{0..*}--[ Expectation ] 316 | |<>--{0..1}--[ History ] 317 | |<>--{0..*}--[ EventData ] 318 | | --> [ AdditionalData ] 319 | | --> PhraudReport (added) 320 +------------------+ 321 Figure 1. The IODEF XML Incident Element (modified) 323 A Fraud Activity Report is composed of one IODEF Incident element, 324 containing one or more EventData elements that contain one or more 325 PhraudReport elements. This document defines the PhraudReport 326 element for the Incident.EventData.AdditionalData element comprising 327 of phishing and fraud-related information that does not map to 328 existing Incident or EventData attributes. Some additional 329 attributes are defined to capture electronic mail header and routing 330 information. 332 One Incident report may contain information on multiple incidents. 333 After the report identification information listed in the Incident 334 element, each individual event is detailed within a single EventData 335 structure. 337 4. PhraudReport Element Definitions 339 A PhraudReport consists of an extension to the Incident 340 AdditionalData Element. The elements of the PhraudReport will 341 identify and capture information related to the six components of 342 fraud activity identified earlier. Other forensic information and 343 commentary can be added by the reporter as necessary to show relation 344 to other events, the output of an investigation, or for archival 345 purposes. A PhraudReport accommodates the six elements this way: 347 Identification fields (PhishNameRef and LocalPhishName Ref) exist 348 to identify the fraudster or class of fraudster. 350 The LureSource element contains information about the source of 351 the attack or phishing lure, including host information and any 352 included malware. Fields exist to include the entire email, web, 353 IM, or other-based lure. 355 There are elements to identify the targeted brand name(s). 357 The DCData holds a description and technical details on the 358 credential collection point. 360 The means of detection is described in the Originating Sensor 361 element. 363 AdditonalData, RelatedData, ArchivedData and TakeDownInfo fields 364 allow optional forensics and history data. 366 A PhraudReport element is structured as follows. 368 +--------------------------+ 369 | EventData.AdditionalData | 370 +--------------------------+ 371 | ENUM type (9 = xml) |<>---------[ PhraudReport ] 372 | STRING meaning (xml) | 373 +--------------------------+ 375 +-----------------+ 376 | PhraudReport | 377 +-----------------+ 378 | ENUM Version |<>--(0..1)--[ PhishNameRef ] 379 | ENUM FraudType |<>--(0..1)--[ PhishNameLocalRef ] 380 | |<>--(0..1)--[ FraudParameter ] 381 | |<>--(0..*)--[ FraudedBrandName ] 382 | |<>--(1..*)--[ LureSource ] 383 | |<>----------[ OriginatingSensor ] 384 | |<>--(0..1)--[ EmailRecord ] 385 | |<>--(0..*)--[ DCSite ] 386 | |<>--(0..*)--[ TakeDownInfo ] 387 | |<>--(0..*)--[ ArchivedData ] 388 | |<>--(0..*)--[ RelatedData ] 389 | |<>--(0..*)--[ CorrelationData ] 390 | |<>--(0..1)--[ PRComments ] 391 +-----------------+ 392 Figure 2. The PhraudReport Extensions to the INCH XML 393 Incident.AdditionalData Element 395 The components of a PhraudReport are introduced in functional 396 grouping as some parameters are related and some elements may not 397 make sense individually. 399 4.1. Version parameter 401 One value of STRING. The version shall be the value 0.3 to be 402 compliant with this document. 404 4.2. Identifying A Fraud campaign 406 At times it may be useful to identify a specific phish or fraud for 407 future analysis, much like the anti-virus vendors identify certain 408 viruses. A specific phish/fraud activity can be identified using a 409 combination of the FraudType, FraudParameter, FraudedBrandName, 410 LureSource, and PhishRefName elements. 412 4.2.1. PhishNameRef Element 414 Zero or one value of STRING. This value is a friendly-name for this 415 fraud event. It may be agreed upon by vendor collaboration to note a 416 common name for a given phish attack or "campaign". The agreed upon 417 identifier could be useful in collaboration, support, media and 418 public education. 420 4.2.2. PhishNameLocalRef Element 422 Zero or one value of STRING. Many contributors will have a local 423 reference name or Unique-IDentifier (UID) that will be used before a 424 commonly agreed term is adopted in PhishNameRef. This field allows a 425 cross-reference from the submitting organization's system to the 426 central repository. 428 4.2.3. FraudType Parameter 430 One required value of ENUM from this list. The FraudType attribute 431 contains a number representing the type of fraud attempted. The 432 Email element has been separated into multiple numbers to support the 433 primary types of lure email. The value of the FraudParameter is 434 dependent on the choice of the FraudType Parameter. 436 1. PhishEmail, and the FraudParameter is the email subject line 437 of the phishing email. This type is a standard email phish, 438 usually sent as spam, and is intended to derive financial loss to 439 the recipient. 441 2. RecruitEmail, and the FraudParameter is the email subject line 442 of the phishing email. This type of email phish does not pose a 443 potential financial loss to the recipient, but covers other cases 444 of the phish and fraud lifecycle. 446 3. MalwareEmail, and the FraudParameter is the email subject line 447 of the phishing email. This type of email phish does not pose a 448 potential financial loss to the recipient, but lures the recipient 449 to an infected site. 451 4. Fraudsite, with no FraudParameter. This identifies a known 452 fraudulent site that does not necessarily send spam but is used 453 for lures. 455 5. DNSspoof, with no FraudParameter. This is used for a spoofed 456 DNS (e.g., malware changes localhost file so visits to 457 www.example.com go to another IP address). 459 6. Keylogger downloaded with lure, with no FraudParameter. 461 7. OLE, no FraudParameter. This identifies background Microsoft 462 Object Linking and Embedding (OLE) information that comes as part 463 of a lure. 465 8. IM. The FraudParameter should be the malicious instant 466 message (IM) link supplied to the user. 468 9. CVE-known malware, with the Common Vulnerability and Exposures 469 project (CVE) number as the FraudParameter. 471 10. SiteArchive, with the data archived from the phishing server 472 placed in the ArchiveInfo element. 474 11. Spamreport. This type is used when the PhraudReport is 475 reporting a large-scale spam activity. The FraudParameter should 476 be the spam email subject line. 478 12, VoIP. The lure was received via a voice-over-IP connection 479 identified by the information in the FraudParameter field. 481 13. Other, to identify as-yet-enumerated fraud types. 483 14. Unknown. 485 4.2.3.1. FraudParameter Element 487 One value of a multilingual STRING. This is the lure used to attract 488 victims. It may be the email subject line, the VoIP lure, the link 489 in IM; the CVE or malware identifier, or a web URL. Note that some 490 phishers add a number of random characters onto the end of a phish 491 email subject line for uniqueness; reporters should delete those 492 characters before insertion into the PhishParameter field. 494 4.3. FraudedBrandName Element 496 Zero or more values of STRING. This is the identifier of the 497 recognized brand name or company name used in the phishing activity. 498 Some schemes, such as those enticing "mules" for money laundering or 499 related activities, may use a lesser known or fictitious brand [e.g., 500 xyz semiconductor company]. Those brand identifiers should also 501 populate this field. 503 4.4. LureSource Element 505 This element describes the source of the phishing or crimeware lure. 506 Elements are included to allow for entering the IP Addresses, 507 DNSNames, and Domain Registry information of the source of the lure 508 and some rudimentary information about the files downloaded and 509 Windows registry keys modified by the crimeware. 511 +-------------+ 512 | LureSource | 513 +-------------+ 514 | |<>--(1..*)--[ System ] 515 | |<>--(0..*)--[ DomainData ] 516 | |<>--(0..1)--[ IncludedMalware ] 517 | |<>--(0..1)--[ FilesDownloaded ] 518 | |<>--(0..1)--[ RegistryKeysModified ] 519 +-------------+ 521 4.4.1. System Element 523 One or more values of IODEF:SYSTEM. Many times the phishing, spam, 524 or fraud lure email is received from a spoofed IP address. If the 525 real IP Address can be ascertained it should be populated into this 526 field. A spoofed address may also be entered, but the spoofed 527 attribute SHALL be set. The field uses the IODEF System element to 528 capture the Address and to allow for support of IPv6 and port 529 numbers. 531 4.4.2. DomainData Element 533 The DomainData element holds information about the registration, 534 delegation, and control of the IPAddress used to source the lure. 535 Many phishers use the DNS system to their advantage moving domain 536 names and addresses repeatedly to avoid disruption. A DomainData 537 element can be used to (repeatedly) capture detailed domain data to 538 detect fraudster patterns and to allow for the quick updating of 539 network filters. There may be multiple values of this element to 540 track the Domain data as the lure DNS entry changes. The structure 541 of a DomainData element is as follows. 543 +--------------------+ 544 | DomainData | 545 +--------------------+ 546 | |<>----------[ Name ] 547 | |<>--(0..1)--[ DateDomainWasChecked ] 548 | ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ] 549 | ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ] 550 | |<>--(0..16)-[ Nameservers ] 551 | |<>--(0..*)--[ DomainContacts ] 552 +--------------------+ 554 +----------------+ 555 | DomainContacts | 556 +----------------+ 557 | |<>--(0..1)--[ SameDomainContact ] 558 | |<>--(0..1)--[ Contact ] 559 +----------------+ 561 4.4.3. Name 563 One value of MLStringType. This field should contain the domain 564 Name. 566 4.4.4. DateDomainWasChecked 568 Zero or One value of DATETIME to show when this domain data was 569 checked and entered into this report. 571 4.4.5. RegistrationDate 573 Zero or one value of DATETIME to note when this domain was 574 registered. 576 4.4.6. ExpirationDate 578 Zero or one value of DATETIME to note when this domain registration 579 will expire. 581 4.4.7. Nameservers 583 Zero or multiple sets of DNSNAME and ADDRESS elements. These fields 584 hold nameservers identified for this domain. The element is 585 artificially limited to 16 nameserver entries. 587 4.4.8. DomainContacts 589 Choice of either a SAMEDOMAINCONTACT or an unbounded set of 590 DOMAINCONTACT values. The DomainContacts element allows the reporter 591 to enter contact information supplied by the registrar or returned by 592 Whois. For efficiency of the reporting party, the domain contact 593 information may be marked to be the same as another domain already 594 reported. 596 +--------------------+ 597 | Contact | 598 +--------------------+ 599 | |<>----------[ ContactName ] 600 | |<>--(0..*)--[ Description ] 601 | ENUM Role |<>--(0..*)--[ RegistryHandle ] 602 | ENUM Confidence |<>--(0..1)--[ PostalAdress ] 603 | ENUM Restriction |<>--(0..*)--[ Email ] 604 | |<>--(0..*)--[ Telephone ] 605 | |<>--(0..1)--[ Fax ] 606 | |<>--(0..1)--[ Timezone ] 607 +--------------------+ 609 4.4.8.1. SameDomainContact 611 One DNSNAME. This field is populated if the contact information for 612 this domain is identical to another DNSNAME element in this or 613 another report. 615 4.4.8.2. DomainContact Element 617 This element reuses the iodef:Contact elements for its components. 618 Each component may have zero or more values. If only the role 619 attribute and the ContactName component are populated, the same 620 (identical) information is listed for multiple roles. The 621 permissible elements are: 623 ContactName. 625 Description. 627 RegistryHandle. 629 PostalAddress. 631 Email. 633 Telephone. 635 Fax. 637 Timezone. 639 Each Contact has three attributes to capture the sensitivity, 640 confidence, and role that the contact is listed for. 642 4.4.8.2.1. Role Attribute 644 ENUM. The role values are imported from [CRISP]. They may be valued 645 as follows. 647 Registrant. 649 Registrar. 651 Billing. 653 Technical. 655 Administrative. 657 Legal. 659 Zone. 661 Abuse. 663 Security. 665 Other. 667 4.4.8.2.2. Confidence Attribute 669 One ENUM value. The Confidence attribute allows a reporter to value- 670 judge the information provided in this report. There are five 671 possible values as follows. 673 Known-fraudulent. This contact information has been previously 674 determined to be fraudulent, either as non-existent physical 675 information or containing real information not associated with 676 this domain registration. 678 Looks-fraudulent. The contact information has suspicious 679 information included. 681 Known-real. The contact information has been previously 682 investigated or determined to be correct. 684 Looks-real. The contact information does not arise suspicion but 685 has not been previously validated. 687 Unknown. The reporter cannot make a value judgment on the 688 contact data. 690 4.4.8.2.3. Restriction Attribute 692 Zero or one value of iodef:RESTRICTION element, to allow sensitive 693 information to be adequately marked. 695 4.4.9. SystemStatus Attribute 697 ENUM. This attribute allows a report to note their estimation of 698 this domain involved in this event. After investigation, a reporter 699 may be able to assess the likelihood that this domain contributed 700 willingly, knowingly, inadvertently, or was not involved in the 701 reported event. 703 1. Spoofed. This domain or system did not participate but its 704 address space or DNS name was forged in this event. 706 2. Fraudulent. The system is fraudulently operated. 708 3. Innocent-Hacked. The system was compromised and used to 709 source the lure. 711 4. Innocent-Hijacked. The IP Address or domain name was hijacked 712 and used as the source of the lure. 714 5. Unknown. No conclusions are inferred from this event. 716 4.4.10. DomainStatus Attribute 718 ENUM. This attribute allows a reported to note the registry status 719 of this domain at the time of the report. The enumerated list is 720 taken verbose from the 'domainStatusType' of the Extensible 721 Provisioning Protocol[RFC3733]and "Domain Registry Version 2 for the 722 Internet Registry Information Service" internet-draft[CRISP]. 724 1. - permanently inactive 726 2. - normal state 728 3. - registration assigned but delegation 729 inactive 731 4. - dispute 733 5. - database purge pending 735 6. - change of authority pending 737 7. - on hold by registry 739 8. - on hold by registrar 741 4.4.11. IncludedMalware Element 743 This elelment allows for the identification and optional inclusion of 744 the actual malware that was part of the lure. The goal of this 745 element is not to detail the characteristics of the malware but 746 rather to allow for a convenient element to link malware to a 747 phishing campaign. 749 +------------------+ 750 | IncludedMalware | 751 +------------------+ 752 | |<>--(1..*)--[ Name ] 753 | |<>--(0..1)--[ Hashvalue ] 754 | |<>--(0..1)--[ Data ] 755 +------------------+ 757 +--------------+ 758 | Data | 759 +--------------+ 760 | STRING | 761 | | 762 | XORPattern | 763 +--------------+ 765 4.4.11.1. Name 767 One or more value of MLSTRINGTYPE. This optional field is used to 768 identify the lure malware. 770 4.4.11.2. Hashvalue 772 Zero or one value of STRING. This optional field is used to hold a 773 hashvalue computed over the malware executable. 775 4.4.11.2.1. Algorithm Parameter 777 REQUIRED ENUM. This field from the following list identifies the 778 algorithm used to create this hashvalue. 780 SHA1. Hashvalue as defined in[SHA] 782 . 784 4.4.11.3. Data 786 Zero or one value of STRING. This optional field is used to include 787 the lure malware. [Note that STRING is a reasonably way to encode 788 byte data.] 790 The Data Element includes an optional 16 hexadecimal character 791 XORPattern attribute to support disabling the included malware to 792 bypass anti-virus filters. The default value is 0x55AA55AA55AA55BB 793 which would be XOR-ed with the malware datastring to revocer the 794 actual malware. 796 4.4.12. FilesDownloaded Element 798 Zero or One value of STRING. The contents of this element are a 799 collection of space-separated filenames downloaded by this lure. 801 4.4.13. RegistryKeysModified Element 803 One value of the Keys sequence. 805 The contents of the RegistryKeysModified element are sets of Keys and 806 an optional Value as attribute. The structure is artificially 807 limited to 32 entries. 809 +-----------------------+ 810 | RegistryKeysModified | 811 +-----------------------+ 812 | |<>--(1..32)--[ Keys ] 813 +-----------------------+ 815 +--------------+ 816 | Keys | 817 +--------------+ 818 | STRING | 819 | | 820 | STRING Value | 821 +--------------+ 823 4.4.13.1. Keys 825 One STRING, representing the WINDOWS Operating System Registry Key 826 Name. 828 4.4.13.2. Value Attribute 830 One STRING, representing the value of the associated Key. 832 4.5. OriginatingSensor Element 834 The OriginatingSensor element contains the identification and 835 cognizant data of the network element that detected this fraud 836 activity. Note that the network element does not have to be in the 837 Internet itself (i.e., it may be a local IDS system) nor is it 838 required to be mechanical (e.g., humans are allowed). 840 Multiple Originating Sensor Elements are allowed. 842 +---------------------+ 843 | OriginatingSensor | 844 +---------------------+ 845 | ENUM OrigSensorType |<>------------[ DateFirstSeen ] 846 | |<>---(0..1)---[ Name ] 847 | |<>---(1..*)---[ System ] 848 | |<>---(0..1)---[ Location ] 849 +---------------------+ 851 The OriginatingSensor requires a type value and identification of the 852 entity that generated this report. 854 4.5.1. OrigSensorType Parameter 856 A REQUIRED ENUM value from the following list, categorizing the 857 function of this sensor: 859 1. Web. A web server or service. 861 2. WebGateway, as in a proxy or firewall. 863 3. MailGateway. 865 4. Browser, or browser-type element. 867 5. ISP-resident or network sensor. 869 6. Human or manual analysis. 871 7. Honeypot or other decoy device. 873 8. Other. 875 4.5.2. FirstSeen Element 877 REQUIRED. DATETIME. This is the date and time that this sensor 878 first saw this phishing activity. 880 4.5.3. Name Element 882 MLSTRINGTYPE. This is the DNS name or other identifier of the 883 entity that detected this event. 885 4.5.4. Address Element 887 IODEF.SOURCE. This is the IPVersion, IPAddress, and optionally, 888 port number of the entity that generated this report. 890 4.5.5. Location Element 892 STRING. This is an optional location of the sensor. 894 4.6. The Data Collection Site Element (DCSite) 896 Zero or more DCSITEDATA elements. This section captures the type, 897 identifier, collection location, and other pertinent information 898 about the credential gathering process by the fraudster. The data 899 collection site is identified by three elements: the type of 900 collector activity, what type of collector site, and the network 901 location (i.e., URL, IP address, etc). 903 Details about the domain, system, or owner of the DCSite can be 904 inserted into the DomainData element. 906 If the DCSite element is present, the DCSiteType element is required. 907 Multiple DCSiteData elements are allowed. 909 +-------------+ 910 | DCSite | 911 +-------------+ 912 | ENUM DCType |<>--(0..*)---[ DCSiteData ] 913 +-------------+ 915 +------------------+ 916 | DCSiteData | 917 +------------------+ 918 | ENUM DCSiteType |<>--+--------[ SiteURL ] 919 | | +--------[ Emailsite ] 920 | | +--------[ System ] 921 | | +--------[ Unknown ] 922 | |<>-----------[ DomainData ] 923 +------------------+ 925 4.6.1. DCType Parameter 927 ENUM. This element identifies the method of data collection, as 928 determined by analyzing the victim computer, lure, or malware, and 929 are selected from the following list. This element is coupled with 930 the DCSiteData element to identify the data collection site. 932 1. Web. The user is redirected to a website to collect the data. 934 2. Email Form. The victim sends an email with credentials 935 enclosed. 937 3. Keylogger. Some form of keylogger is downloaded to the 938 victim. 940 4. Automation. Other forms of automatic data collection, such 941 as background OLE automation, are used to capture information. 943 5. Unspecified. 945 4.6.2. DCSiteData Element 947 This element contains the IPAddress, URL, or other identification of 948 the data collection site as selected by the DCType Parameter. 950 4.6.2.1. DCSiteType Parameter 952 ENUM. This parameter tags the network address and other information 953 in the DataCollectionSiteData element. 955 1. Web. Data from the victim is collected on a website. The 956 website URL is included in the DCSitePointer. 958 2. Email. The victim emails credentials to the collection site. 959 The email server DNS name is in the DCSitePointer. 961 3. IODEF.SYSTEM Element. This collection site uses other 962 protocols to gather data from the victim. The DCSitePointer 963 field is an IODEF System Element, holding the IP Version 964 Protocol, IPAddress, and Port number of the collection site. The 965 Protocol field defaults to TCP, if absent. 967 4. Unknown. The DCSitePointer data should be verbose to 968 describe this type of site. 970 4.7. TakeDownInfo Element 972 This element identifies the agency(s) that performed the removal or 973 ISP-blockage of the phish or fraud collector site. A PhraudReport 974 may have multiple TakeDownInfo elements to support activities where 975 multiple agencies are active. Note that the term "Agency" is used to 976 identify any party performing the blocking or removal such as ISPs or 977 private parties, not just government entities. 979 +-------------------+ 980 | TakeDownInfo | 981 +-------------------+ 982 | |<>---(0..1)--[ TakeDownDate ] 983 | |<>---(0..*)--[ TakeDownAgency ] 984 | |<>---(0..*)--[ TakeDownComments ] 985 +-------------------+ 987 4.7.1. TakeDownDate Element 989 Zero or one DATETIME. This is the date and time that takedown of 990 the collector site occurred. 992 4.7.2. TakeDownAgency Element 994 Zero or more STRING. This is a free form string identifying the 995 agency that performed the takedown 997 4.7.3. TakeDownComments Element 999 Zero or more STRING. A free form field to add any additional 1000 details of this takedown effort. 1002 4.8. ArchivedData Element 1004 Zero or more values of the ArchivedData element are allowed. 1006 +-------------------+ 1007 | ArchivedData | 1008 +-------------------+ 1009 | ENUM Type |<>---(0..1)--[ ArchivedDataURL ] 1010 | |<>---(0..1)--[ ArchivedDataComments ] 1011 +-------------------+ 1013 The ArchivedData element is used to typecast and include a gzip 1014 archive file of a data collection site, base camp, or other site 1015 where the phisher developed their code. This element will be 1016 populated when, for example, an ISP takes down a phisher's web site 1017 and has copied the site data into an archive file. There are three 1018 types of archives currently supported, as specified in the type 1019 field. 1021 4.8.1. Type Parameter 1023 This parameter specifies the contents of the archive. 1025 1. Data Collection Site. 1027 2. Basecamp Site. 1029 3. Sender Site. 1031 4. Unspecified. 1033 4.8.2. ArchivedDataURL Element 1035 Zero or one value of URL. Many times an investigator may want to 1036 include a copy of the actual malware, lure, or program 1037 executables that were received by the victim. As the executables 1038 can be quite large, this element will point to an Internet-based 1039 server where the executables can be retrieved from, a Fraud 1040 Report just points out where the archive is, and does not include 1041 it in the report. This is the URL where the gzip archive file is 1042 located. 1044 4.8.3. ArchivedDataComments Element 1046 Zero or one value of STRING. This field is a free form area for 1047 comments on the archive and/or URL. 1049 4.9. RelatedData Element 1051 Zero or more value of STRING. This element allows the listing of 1052 other web or net sites that are related to this incident (e.g., 1053 victim site, etc). 1055 4.10. CorrelationData Element 1057 Zero or more value of STRING. Any information that correlates this 1058 incident to other incidents can be entered here. 1060 4.11. PRComments Element 1062 Zero or more value of STRING. This field allows for any comments 1063 specific to this PhraudReport that does not fit in any other field. 1065 4.12. EmailRecord Element 1067 Extensions are also made to the INCH IODEF Incident EventData element 1068 to support descriptive information received in phishing lure or spam 1069 emails. The ability to report spam is included within a PhraudReport 1070 to support exchanging information about large-scale spam activities, 1071 not necessarily a single spam message to a user. As such the spam 1072 reporting mechanism was not designed to minimize overhead and 1073 processing and to support other widely-used spam reporting formats 1074 such as the MAAWG's ARF. 1076 Information related to the overall fraudulent activity is contained 1077 within the PhraudReport, while the EmailRecord element is used to 1078 capture forensic or detailed technical information about a specific 1079 attack. Incident Reports may have none, one, or multiple 1080 EmailRecords as its goal is to accumulate pertinent technical data 1081 associated with a specific attack as an investigation continues. 1083 Reporting of the actual mail message is supported by choosing one of 1084 three methods. First, an AR message may be included. Second, the 1085 message may be included as one large string. Third, the header and 1086 body components may be dissected and included as a series of strings. 1088 +--------------------+ 1089 | EmailRecord | 1090 +--------------------+ 1091 | |<>--------------[ EmailCount ] 1092 | |<>-+-+----------[ EmailHeader ] 1093 | | | |--(0..1)--[ EmailBody ] 1094 | | +----(0..1)--[ Message ] 1095 | | +----(0..1)--[ ARFText ] 1096 | |<>--(0..1)------[ EmailComments ] 1097 +--------------------+ 1099 4.12.1. EmailCount Element 1101 REQUIRED NUMBER. This field enumerates the number of email 1102 messages identified in this record detected by the reporter. 1104 4.12.2. ARFText Element 1106 Zero or one value of STRING. The Messaging Anti-Abuse Working 1107 Group (MAAWG) defined a format for sending abuse and list control 1108 traffic to other parties. Since many of these reports will get 1109 integrated into incident processes, the raw Abuse Reporting 1110 Format (ARF) may be inserted into this element. 1112 The ARF should be encoded as a character string. 1114 4.12.3. Message Element 1116 Zero or one value of STRING. The complete received email message 1117 is included within this element. 1119 4.12.4. EmailHeader Element 1121 One value of STRING. The headers of the phish email are included 1122 in this element as a sequence of one-line text strings. There 1123 SHALL be one EmailHeader element per mailRecord 1125 4.12.5. EmailBody Element 1126 Zero or one value of STRING. This element contains the body of 1127 the phish email. If present, there should be at most one 1128 EmailBody element per EmailRecord 1130 4.12.6. EmailComments Element 1132 Zero or one value of STRING. This field contains comments or 1133 relevant data not placed elsewhere about the phishing or spam 1134 email. 1136 5. IODEF Required Elements 1138 A report about fraud, spam, or phishing requires certain identifying 1139 information which is contained within the standard IODEF Incident 1140 data structure. The following table identifies attributes required 1141 to be present in a compliant PhraudReport. The required attributes 1142 are a combination of those required by the base IODEF element and 1143 those required by this document. Attributes identified as required 1144 SHALL be populated in conforming phishing activity reports. 1146 The following table is a visual description of the IODEF and 1147 PhraudReport required fields. 1149 +--------------+ 1150 | Incident | 1151 +--------------+ 1152 | ENUM Purpose |---[ IncidentID ] 1153 | |---[ Assessment ] 1154 | | ---> [ Confidence ] 1155 | |---[ ReportTime ] 1156 | |---[ Contact ] 1157 | | ---> [ Role ] 1158 | | ---> [ Type ] 1159 | | ---> [ Name ] 1160 | |---[ EventData ] 1161 | | ---> [ AdditionalData] 1162 | | ---> [ FraudReport ] 1163 | | ---> [ FraudType ] 1164 | | ---> [ FraudParameter ] 1165 | | ---> [ FraudedBrandName ] 1166 | | ---> [ LureSource ] 1167 | | ---> [ OriginatingSensor ] 1168 | | 1169 +--------------+ 1171 5.1. Fraud or Phishing Report 1173 A compliant IODEF PhraudReport is required to contain the following 1174 fields: 1176 Purpose 1178 IncidentID 1180 ReportTime 1182 Contact -> Role 1183 Contact -> Type 1185 Contact -> Name 1187 Assessment 1189 EventData 1191 DetectTime 1193 AdditionalData 1195 PhraudReport 1197 FraudType 1199 FraudedBrandName 1201 LureSource 1203 OriginatingSensor 1205 5.2. Wide-Spread Spam Report 1207 These following fields MUST be populated in an IODEF PhraudReport 1208 compliant Spam Activity Report: 1210 Incident Structure: 1212 IncidentID 1214 Purpose 1216 ReportTime 1218 Contact -> Role 1220 Contact -> Type 1222 Contact -> Name 1223 Assessment 1225 EventData 1227 DetectTime 1229 AdditionalData 1231 PhraudReport 1233 FraudType == spamreport 1235 LureSource 1237 OriginatingSensor 1239 EmailRecord 1241 EmailCount 1243 EmailHeader or Message 1245 5.3. Guidance on Usage 1247 It may be apparent that the mandatory attributes for a phishing 1248 activity report make for a quite sparse report. As incident 1249 forensics and data analysis require detailed information, the 1250 originator of a PhraudReport should include any tidbit of information 1251 gleaned from the attack analysis. Information that is considered 1252 sensitive can be marked as such using the restriction parameter of 1253 each data element. 1255 6. Security Considerations 1257 This document specifies the format of security incident data. As 1258 such, the security of transactions containing the incident report 1259 will vary from organization to organization. We do not want to 1260 burden the information exchange with unnecessary encryption 1261 requirements, as the transport service for the data exchange may 1262 provide adequate protections, or even encryption. The use of 1263 encryption is expected to be agreed upon on originator-recipient 1264 agreement. 1266 The critical security concern is that phishing activity reports may 1267 be falsified or the report may become corrupt during transit. In 1268 areas where transmission security or secrecy is necessary the 1269 application of a digital signature and/or message encryption on each 1270 report will counteract both of these concerns, the digital signature 1271 may be overkill for most activity report users as the goal is to 1272 notify others of the event. For this reason, phishing activity 1273 reports MAY be digitally signed with the optional IODEF XML 1274 signature, although we expect that each receiving entity will 1275 determine the need for this signature independently. 1277 Recipients of fraud reports SHALL be prepared to accept XML digitally 1278 signed reports and SHOULD support receiving encrypted reports. 1280 7. IANA Considerations 1282 [This section will change before publication.] 1284 This document uses URNs to describe XML namespaces and XML schemas 1285 conforming to a registry mechanism described in . [XML] 1287 Registration request for the iodef namespace: 1289 URI: urn:ietf:params:xml:ns:iodef-phish-1.0 1291 Registrant Contact: See the "Author's Address" section of this 1292 document. 1294 XML: None. 1296 Registration request for the iodef XML schema: 1298 URI: urn:ietf:params:xml:schema:iodef-phish-1.0 1300 Registrant Contact: See the "Author's Address" section of 1301 this document. 1303 XML: See the "Phishing Extensions Schema Definition" 1304 section of this document. 1306 8. Contributors 1308 The extensions are an outgrowth of the Anti-Phishing Working Group 1309 (APWG) activities in data collection and sharing of phishing and 1310 other ecrime-ware. 1312 This document has received significant assistance from two groups 1313 addressing the phishing problem: members of the Anti-Phishing Working 1314 Group and participants in the Financial Services Technology 1315 Consortium's Counter-Phishing project. 1317 9. References 1319 9.1. Normative References 1321 [IODEF] Meijer, J., Danyliw, and Demchenko, "The Incident Object 1322 Description Exchange Format Data Model and XML 1323 Implementation", October 2005. 1325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1326 Requirement Levels", BCP 14, RFC 2119, March 1997. 1328 [SHA] National Institute of Standards and Technology, U.S. 1329 Department of Commerce, "Secure Hash Standard", 1330 FIPS 180-1, May 1994. 1332 [XML] Mealing, M., "The IETF XML Registry", RFC 3688, 1333 January 2004. 1335 9.2. Informative References 1337 [CRISP] Newton, L. and A. Neves, "Domain Registry Version 2 for 1338 the Internet Registry Information Service", May 2006. 1340 [IDMEF] Curry, D. and H. Debar, "The Intrusion Detection Message 1341 Exchange Format", July 2004. 1343 [RFC3733] Hollenbeck, "Extensible Provisioning Protocol (EPP) 1344 Contact Mapping", RFC 3733", RFC 3733, March 2004. 1346 Appendix A. Phishing Extensions XML Schema 1348 A digital copy of this file is available to prevent errors when re- 1349 entering text. See www.coopercain.com/incidents . 1351 1352 1360 1363 1373 1374 1375 1376 1377 1378 This is an EventData.AdditionalData structure for 1379 an IODEF Incident class. 1380 1382 1385 1388 1391 1394 1395 1396 1397 1400 1402 1403 1404 1405 1407 1408 1409 1410 1411 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1424 1425 1426 1428 1429 1430 1431 1432 1434 1435 1436 1437 1438 1440 1441 1442 1443 1445 1446 1447 1448 1449 1450 1452 1454 1457 1460 1463 1466 1469 1472 1474 1476 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1501 1502 1503 1504 1505 1506 1507 1509 1515 1516 1517 1518 1520 1521 1522 1523 1526 1527 1528 1530 1531 1532 1534 1536 1537 1540 1541 1543 1545 1546 1547 1549 1555 1556 1557 1558 1559 1560 1561 1562 1564 1566 1568 1569 1571 1572 1574 1575 1576 1577 1579 1581 1583 1584 1586 1587 1588 1589 1590 1592 1593 1594 1595 1597 1599 1601 1603 1604 1605 1606 1607 1608 1610 1611 1612 1613 1615 1616 Multiple domains with equal contact and 1617 registraton data can be referenced with the "sameas" 1618 entry. 1619 1620 1622 1625 1628 1631 1632 1633 1634 1636 1637 1638 1639 1641 1642 1645 1646 1648 1649 1650 1652 1653 1654 1655 1657 1659 1661 1663 1664 1665 1666 1668 1669 1670 1671 1674 1676 1679 1681 1683 1686 1688 1690 1691 1692 1693 1694 1696 1697 1698 1699 1700 1701 1702 1704 1705 1706 1707 1709 1712 1715 1717 1720 1723 1725 1726 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1757 1759 1760 1762 1768 1769 1770 1771 1773 1776 1779 1780 1782 1783 1784 1785 1787 1789 1791 1793 1795 1797 1799 1800 1801 1802 1803 1804 1806 1812 1813 1814 1815 1818 1821 1823 1824 1825 1826 1832 1833 1834 1835 1838 1840 1842 1843 1844 1845 1847 1849 1851 1852 1853 1854 1855 1856 1858 1864 1865 1866 1867 1868 1869 1870 1872 1873 1875 1876 1877 1878 1879 1880 1881 1882 1884 Appendix B. Sample Malware Email Report 1886 This section shows a received electronic mail message that included a 1887 virus in a zipped attachment and a report that was generated for that 1888 message. 1890 B.1. Received Email 1892 From: support@coopercain.com 1893 Sent: Friday, June 10, 2005 3:52 PM 1894 To: pcain@coopercain.com 1895 Subject: You have successfully updated your password 1896 Attachments: updated-password.zip 1898 Dear user pcain, 1900 You have successfully updated the password of your Coopercain 1901 account. If you did not authorize this change or if you need 1902 assistance with your account, please contact Coopercain customer 1903 service at: support@coopercain.com 1905 Thank you for using Coopercain! 1906 The Coopercain Support Team 1908 +++ Attachment: No Virus (Clean) +++ 1909 Coopercain Antivirus - www.coopercain.com 1911 B.2. Generated Report 1913 NOTE: Some wrapping and folding liberties have been applied to fit it 1914 into the margins. 1916 1917 1924 1925 PAT2005-06 1926 2005-06-22T08:30:00-05:00 1927 This is a test report from actual data. 1928 1929 1930 1931 1932 1933 patcain 1934 pcain@coopercain.com 1935 1936 1937 2005-06-21T18:22:02-05:00 1938 1939 1940 1941 Subject: You have successfully updated your password 1942 1944 Cooper-Cain 1945 1946 1947 1948
216.231.63.162
1949 1950 1952 1953 W32.Mytob.EA@mm 1954 1955 1957 1958 2005-06-10T15:52:11-05:00 1960 1961 1962
10.0.0.4
1963 1964 1965 1967 1968 1 1969 "Return-path: <support@coopercain.com>" 1970 Envelope-to: pcain@coopercain.com 1971 Delivery-date: Fri, 10 Jun 2005 15:52:11-0400 1972 Received: from dsl231-063-162.sea1.dsl.speakeasy.net 1973 ([216.231.63.162] helo=coopercain.com) by 1974 mail06.coopercain.com with esmtp 1975 (Exim) id 1DgpXy-0002Ua-IR for pcain@coopercain.com; 1976 Fri, 10 Jun 2005 15:52:10-0400 1977 From: support@coopercain.com 1978 To: pcain@coopercain.com 1979 Subject: You have successfully updated yourn password 1980 Date: Fri, 10 Jun 2005 12:52:00 -0700 MIME-Version: 1.0 1981 Content-Type: multipart/mixed; 1982 boundary="----=_NextPart_000_0008_0911068B.E7EB6D2A" 1983 X-Priority: 3 1984 X-MSMail-Priority: Normal X-EN-OrigIP: 216.231.63.162 1985 X-EN-OrigHost: dsl231-063-162.sea1.dsl.speakeasy.net 1986 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on 1987 Scan18.int.bizland.net X-Spam-Level: ***** X-Spam-Status: No, 1988 score=5.6 required=6.0 tests=BAYES_95,CABLEDSL,HTML_20_30, 1989 HTML_MESSAGE,MIME_HTML_ONLY,MISSING_MIMEOLE,NO_REAL_NAME, 1990 PRIORITY_NO_NAME autolearn=disabled version=3.0.2 1991 From: support@coopercain.com 1992 Sent: Friday, June 10, 2005 3:52 PM 1993 To:pcain@coopercain.com 1994 Subject: You have successfully updated your password 1995 Attachments: updated-password.zip 1996 Dear user pcain, 1997 You have successfully updated the password of your 1998 Coopercain account. 1999 If you did not authorize this change or if you need 2000 assistance with your account, please contact Coopercain 2001 customer service at: 2002 support@coopercain.com 2003 Thank you for using Coopercain! 2004 The Coopercain Support Team 2005 +++ Attachment: No Virus (Clean) +++ 2006 Coopercain Antivirus - www.coopercain.com 2007 2008 2009 2010 2011 2013 B.3. Notes and Commentary 2014 Appendix C. Sample Phish Email Report 2016 A sample report generated from a received electronic mail phishing 2017 message in shoen in this section. 2019 C.1. Received Lure 2021 Return-path: 2022 Envelope-to: pcain@coopercain.com 2023 Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400 2024 Received: from mail15.yourhostingaccount.com ([10.1.1.161] 2025 helo=mail15.yourhostingaccount.com) 2026 by mailscan38.yourhostingaccount.com with esmtp (Exim) 2027 id 1Fq5Kr-0005wU-LT for pcain@coopercain.com; Tue, 13 Jun 2006 2028 05:37:21 -0400 2029 Received: from [24.147.114.61] (helo=TSI) 2030 by mail15.yourhostingaccount.com with 2031 esmtp (Exim) id 1Fq5Bj-0006dv-6b 2032 for pcain@coopercain.com; Tue, 13 Jun 2006 05:37:21 -0400 2033 Received: from User ([66.59.189.157]) by TSI with 2034 Microsoft SMTPSVC(5.0.2195.6713); 2035 Tue, 13 Jun 2006 02:24:30 -0400 2036 Reply-To: 2037 From: "PayPal" 2038 Subject: * * * Update & Verify Your PayPal Account * * * 2039 Date: Tue, 13 Jun 2006 02:36:34 -0400 2040 MIME-Version: 1.0 2041 Content-Type: text/html; charset="Windows-1251" 2042 Content-Transfer-Encoding: 7bit 2043 X-Priority: 1 2044 X-MSMail-Priority: High 2045 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 2046 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 2047 Bcc: 2048 Message-ID: 2049 X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC) 2050 FILETIME=[072A66A0:01C68EB2] 2051 X-EN-OrigSender: service@paypal.com 2052 X-EN-OrigIP: 24.147.114.61 2053 X-EN-OrigHost: unknown 2055 PayPal 2056 2057 2058 2059 Account Update Request 2060 Dear PayPal. member:, 2062 You are receiving this notification because PayPal is required by 2063 law to notify you, that you urgently need to update your online 2064 account statement, due to high risks of fraud intentions. 2066 The updating of your PayPal account can be done at any time by 2067 clicking on the link shown below 2068 http://www.paypal.com/cgi-bin/webscr?cmd=_login-run 2069 2073 Once you log in,update your account information. 2074 After updating your account click on the History sub tab of your 2075 Account Overview page to see your most recent statement. 2077 If you need help with your password, click the Help link which is at 2078 the upper right hand side of the PayPal website. To report errors in 2079 your statement or make inquiries, click the Contact Us link in the 2080 footer on any page of the PayPal website, call our Customer Service 2081 center at (402) 938-3630, or write us at: 2083 PayPal, Inc. 2084 P.O. Box 45950 2085 Omaha, NE 68145 2087 Sincerely, 2089 PayPal 2091 2093 C.2. Phishing Report 2095 2096 2104 CC200600000002 2105 2006-06-13T21:14:56-05:00 2107 2108 This is a sample phishing email received report. The phish 2109 was actually received as is. 2110 2112 2114 2115 patcain 2117 pcain@coopercain.com 2118 2120 2121 2006-06-13T05:37:21-04:00 2123 2124 2125 * * * Update & Verify Your 2126 PayPal Account * * * 2127 PayPal 2129 2130 2131 2132
24.147.114.61
2133 2134 2135 2137 2139 2006-06-13T05:37:22-04:00 2140 2142 2143 2144 2145 2146 2147 2149 2150 1 2152 Return-path: <service@paypal.com> 2153 Envelope-to: pcain@coopercain.com 2154 Delivery-date: Tue, 13 Jun 2006 05:37:22 -0400 2155 Received: from mail15.yourhostingaccount.com 2156 ([10.1.1.161] helo=mail15.yourhostingaccount.com) by 2157 mailscan38.yourhostingaccount.com with esmtp (Exim) id 2158 1Fq5Kr-0005wU-LT for pcain@coopercain.com; Tue, 13 2159 Jun 2006 05:37:21 -0400 2160 Received: from [24.147.114.61] (helo=TSI) by 2161 mail15.yourhostingaccount.com with esmtp (Exim) id 2162 1Fq5Bj-0006dv-6b for pcain@coopercain.com; Tue, 13 2163 Jun 2006 05:37:21 -0400 2164 Received: from User ([66.59.189.157]) by TSI with 2165 Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 2166 Jun 2006 02:24:30 -0400 2167 Reply-To: <nospa@nospa.us> 2168 From: "PayPal"<service@paypal.com> 2169 Subject: * * * Update & Verify Your 2170 PayPal Account * * * 2171 Date: Tue, 13 Jun 2006 02:36:34-0400 2172 MIME-Version: 1.0 Content-Type: text/html; 2173 charset="Windows-1251" 2174 Content-Transfer-Encoding: 7bit 2175 X-Priority: 1 2176 X-MSMail-Priority: High 2177 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 2178 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 2179 Bcc: 2180 Message-ID: <TSIlYbvhBISmT6QcWY90000085f@TSI> 2181 X-OriginalArrivalTime: 13 Jun 2006 06:24:30.0218 (UTC) 2182 FILETIME=[072A66A0:01C68EB2] 2183 X-EN-OrigSender: service@paypal.com 2184 X-EN-OrigIP: 24.147.114.61 2185 X-EN-OrigHost: unknown 2186 PayPal<http://www.paypal.com/images/paypal_logo.gif> 2187 <http://www.paypal.com/images/pixel.gif> 2188 <http://www.paypal.com/images/pixel.gif> 2189 <http://www.paypal.com/images/pixel.gif> 2190 Account Update 2191 Request Dear PayPal. member:, You are receiving this 2192 notification because PayPal is required by law to notify 2193 you, that you urgently need to update your online account 2194 statement, due to high risks of fraud intentions. The 2195 updating of your PayPal account can be done 2196 at any time by clicking on the link shown below 2197 http://www.paypal.com/cgi-bin/webscr?cmd=_login-run 2198 <http://217.136.251.41:8080/.cgi-bin/.webscr/.secure- 2199 login/%20/%20/.paypal.com/index.htm> 2200 Once you log in,update your account information. After 2201 updating your account click on the History sub 2202 tab of your Account Overview page to see your most recent 2203 statement. If you need help with your password, click the 2204 Help link which is at the upper right hand side of the 2205 PayPal website. 2206 To report errors in your statement or make inquiries, 2207 click the Contact Us link in the footer on any page of 2208 the PayPal website, call our Customer Service center at 2209 (402) 938-3630, or write us at: PayPal, Inc. P.O. 2210 Box 45950 Omaha, NE 68145 Sincerely, PayPal 2211 <http://www.paypal.com/images/dot_row_long.gif> 2212 2213 2215 2216 2217 http://217.136.251.41:8080/.cgi-bin/.web 2218 scr/.secure-login/%20%20/.paypal.com/index.htm 2219 2221 2224 adsl.skynet.be 2226 2227 2006-06-14T13:05:00-05:00 2228 2230 2231 2000-12-13T00:00:00 2232 2234 2235 ns1.skynet.be 2237
195.238.3.17
2238 2239 2240 2241 2242 2243 2244 2245 2247 C.3. Notes and Commentary 2248 Appendix D. Sample Spam Report 2250 [ ed.To be supplied, but it looks a lot like the fraud report] 2252 Authors' Addresses 2254 Patrick Cain 2255 The Cooper-Cain Group, Inc. 2256 P.O. Box 400992 2257 Cambridge, MA 2258 USA 2260 Email: pcain@coopercain.com 2262 David Jevans 2263 The Anti-Phishing Working Group 2264 5150 El Camino Real, Suite A20 2265 Los Altos, CA 94022 2266 USA 2268 Email: dave.jevans@antiphishing.org 2270 Intellectual Property Statement 2272 The IETF takes no position regarding the validity or scope of any 2273 Intellectual Property Rights or other rights that might be claimed to 2274 pertain to the implementation or use of the technology described in 2275 this document or the extent to which any license under such rights 2276 might or might not be available; nor does it represent that it has 2277 made any independent effort to identify any such rights. Information 2278 on the procedures with respect to rights in RFC documents can be 2279 found in BCP 78 and BCP 79. 2281 Copies of IPR disclosures made to the IETF Secretariat and any 2282 assurances of licenses to be made available, or the result of an 2283 attempt made to obtain a general license or permission for the use of 2284 such proprietary rights by implementers or users of this 2285 specification can be obtained from the IETF on-line IPR repository at 2286 http://www.ietf.org/ipr. 2288 The IETF invites any interested party to bring to its attention any 2289 copyrights, patents or patent applications, or other proprietary 2290 rights that may cover technology that may be required to implement 2291 this standard. Please address the information to the IETF at 2292 ietf-ipr@ietf.org. 2294 Disclaimer of Validity 2296 This document and the information contained herein are provided on an 2297 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2298 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2299 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2300 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2301 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2302 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2304 Copyright Statement 2306 Copyright (C) The Internet Society (2006). This document is subject 2307 to the rights, licenses and restrictions contained in BCP 78, and 2308 except as set forth therein, the authors retain all their rights. 2310 Acknowledgment 2312 Funding for the RFC Editor function is currently provided by the 2313 Internet Society.