Subject: [mile] Example: Spear Phishing

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Jul 2015 16:08:04 -0400

Hello,

This text corresponds with the Spear phishing example in the IODEF Guidance
 (A.3) draft and also requires updating to use example.com, IP addresses
that are okay to include in RFCs, as well as AS numbers and names.  I see
the example got a little mangled in translation to use appropriate IPs and
example names.  For instance, there is just AS=225, when there were 2
originally.  Both need to be replaced with example AS numbers as these were
randomly selected, not associated with an attack and we'll need to use ones
that are OK for an RFC example.

We'll also need to update with how DNS is represented in the final IODEFv2.

I'll skip the DDoS one unless folks think that is useful for representation
in IODEF.  I should also have the breakdown of what we thought was useful
to exchange for the malware/watchlist example sent before if useful for the
Guidance draft.

Types of Data Shared

The Spear Phishing use case consists of several indicator types and
context.  The context of the indicator determines whether the originator
would want to share this information with a smaller, more select group of
partners (i.e. sensitive information could be included in the comment
field) or whether it is best shared with a larger community. The types of
data bulleted below are examples of relevant pieces of information
(indicator and contextual) that could be exchanged in a real spear phishing
incident, however they are not all seen in the scenario provided.
Italicized data types are used in the scenarios below.

·      *Target Description*

·      *Target Domain*

·      *Comment Field *

·      Originator’s Confidence Score

·      *URL*

o   *Malware Family*

·      *Date/Time*

o   *Time Zone*

o   *Start*

o   *Detect*

o   *Stop*

o   *Report*

·      *IP address* (source and destination)

o   *Source AS number*

o   *Source AS name*

o   *Prefix*

·      *From Address*

·      *Subject Line*

·      *Email Digital Signature Type* (S/MIME, PGP)

o   Meta data

§  *CA Name*

§  *Signed Name*

§  *Validity*

§  *Public Key Attached*

§  *Public Key Hash*

§  Certificate

·      *DKIM Signature*

o   Validity

o   Public Key Attached

·      *Sender Policy Framework DNS records*

·      *MIME Type*

·      *X-Mailer*

·      From Domain

·      DNS Reverse Lookup of PTR record for source IP address

o   Date/Time

o   PTR record

·      *DNS Forward Lookup of email domain*

o   *Date/Time*

o   *MX records*

o   Records associated with MX records

·      *Attachment*

o   *Name*

o   *File Type*

o   *Size*

o   *Hash*

o   *Malware Family*
Spear Phishing Scenario

Sharing a spear phishing event with a malware attachment.  This use case
describes CIRT to CIRT sharing.

Background Information
The board members of several defense contractors receive an email inviting
them to attend the Dummy Con in San Francisco. The board members are asked
to provide their personally identifiable information such as their home
address, phone number, corporate email, etc in an attached document which
came with the email.  The board members were also asked to click on a URL
which would allow them to reach the sign up page for the conference.  One
of the recipients believes the email to be a phishing attempt and forwards
the email to their corporate CIRT for analysis. The CIRT identifies the
email as an attempted spear phishing incident and distributes the
indicators to their sharing partners.

Example Data Shared

The example data below provides sample data that would be exchanged in this
spear phishing indicator exchange. The data is fictional. As mentioned
earlier, the purpose of the pseudo-JSON is to show the desired structure of
the solution, not to suggest using JSON as a format for the solution.

The scenario involves the indicator exchange from one CIRT to another about
a Spear Phishing email that was sent to the board members of several
defense contractors.  The malware family is identified by the URL and the
attached executable. The sha256 hashes are provided for the attachment and
the public key of the sender. Comments with a ‘//’ in front are for the
purposes of understanding this representation, and there is no need to
include them in the actual XML documents exchanged as part of the scenario.

{

Indicators:

  [

    //Simple Zbot/Zeus Sample

    {

      targetDescription: “Board members attending Dummy Con”

      targetDomain: “Defense Contractors”

      comment : “Zeus Spear Phishing E-mail with Malware Attachment”,

      phishingLink    : { url: www.zeusevil.com, malwareFamily: Zeus }  //URL
in the body of the email

                             ipAddress: “196.167.14.81”  //IP address of
the URL

                             sourceASNumber: “225”

                        sourceASName: “University of Example”

                            Prefix: “18.144.0.0/16”

timestamps : {

                             start : “08:01:34 1/4/13 UTC”

                             stop  : “08:31:27 1/4/13 UTC”

                             detect: “08:06:12 1/4/13 UTC”

                             report: “09:15:45 1/4/13 UTC” }

       sendingServer: {

                             ipAddress: “176.157.32.17”  //IP address where
the email was sent from

                             sourceASNumber: “774”

                        sourceASName: “University of Example2”

                            prefix” “186.134.0.0/14”

                             destination: “193.186.138.101” }  //IP address
of the recipient

       email: {

                             fromAddress: “[email-masked]”

                             fromDomain: “evildave.com”

                             subjectLine: “Join us at DummyCon”

                             digitalsignatureType: “X.509”

                                    {CAName: “FakeCA”

                                     signed: “EvilDave”

                                     valid: “No”

                                     publicKey: “Yes”

 publicKeyHash: “sha256:
352bddec13e4e5257ee63854cb1f05de48043d09f9076070845307b7ce76c185}}

       DKIMSignature: “No”

      senderpolicyFramework: “zuesevil.com. IN TXT \"v=spf1 a mx –all\””

       MIMEType: “text/plain”

       xMailer: “StormRider 4.0”

       nsLookup: {           date: “1/4/13”

Time: “09:10:24 UTC”

mailRecords: {“evildave.com MX preference = 10, mail exchanger =
mail1.evildave.com”

 “mail1.evildave.com internet address = 176.157.32.17”} //located mail
exchanger for //evildave.com

       attachment: {        name: “Dummy Con Sign Up Sheet”

                             fileType: “text document”

                             fileSize: “152kb”

                             fileHash: “sha256:
141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184”

                             malwareFamily: “Zues” }

      }

   ]

}

-- 

Best regards,
Kathleen

---

From: "Harrington, Christopher" <[email-masked]>
Date: Wed, 22 Jul 2015 16:20:41 -0400

Message ID is a critical field when dealing with phishing emails. It's probably the most important field when trying to determine if an email is a spoof/forgery. It's probably worth adding to the example.

URL is just as common as attachments for delivery mechanisms in phishing emails. In those we share the hyperlink and if it is different also the  hyperlink text. It's common to see the text of the link in the phishing email to be www.google.com<http://www.google.com> but the actual hyperlink will be www.badsite.com<http://www.badsite.com>.

On Jul 22, 2015, at 4:08 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

This text corresponds with the Spear phishing example in the IODEF Guidance  (A.3) draft and also requires updating to use example.com<http://example.com>, IP addresses that are okay to include in RFCs, as well as AS numbers and names.  I see the example got a little mangled in translation to use appropriate IPs and example names.  For instance, there is just AS=225, when there were 2 originally.  Both need to be replaced with example AS numbers as these were randomly selected, not associated with an attack and we'll need to use ones that are OK for an RFC example.

I'll skip the DDoS one unless folks think that is useful for representation in IODEF.  I should also have the breakdown of what we thought was useful to exchange for the malware/watchlist example sent before if useful for the Guidance draft.

Types of Data Shared
The Spear Phishing use case consists of several indicator types and context.  The context of the indicator determines whether the originator would want to share this information with a smaller, more select group of partners (i.e. sensitive information could be included in the comment field) or whether it is best shared with a larger community. The types of data bulleted below are examples of relevant pieces of information (indicator and contextual) that could be exchanged in a real spear phishing incident, however they are not all seen in the scenario provided. Italicized data types are used in the scenarios below.

•      Target Description

•      Target Domain

•      Comment Field

•      Originator’s Confidence Score

•      URL

o   Malware Family

•      Date/Time

o   Time Zone

o   Start

o   Detect

o   Stop

o   Report

•      IP address (source and destination)

o   Source AS number

o   Source AS name

o   Prefix

•      From Address

•      Subject Line

•      Email Digital Signature Type (S/MIME, PGP)

o   Meta data

•  CA Name

•  Signed Name

•  Validity

•  Public Key Attached

•  Public Key Hash

•  Certificate

•      DKIM Signature

o   Validity

o   Public Key Attached

•      Sender Policy Framework DNS records

•      MIME Type

•      X-Mailer

•      From Domain

•      DNS Reverse Lookup of PTR record for source IP address

o   Date/Time

o   PTR record

•      DNS Forward Lookup of email domain

o   Date/Time

o   MX records

•      Attachment

o   Name

o   File Type

o   Size

o   Hash

o   Malware Family

Spear Phishing Scenario
Sharing a spear phishing event with a malware attachment.  This use case describes CIRT to CIRT sharing.
Background Information
The board members of several defense contractors receive an email inviting them to attend the Dummy Con in San Francisco. The board members are asked to provide their personally identifiable information such as their home address, phone number, corporate email, etc in an attached document which came with the email.  The board members were also asked to click on a URL which would allow them to reach the sign up page for the conference.  One of the recipients believes the email to be a phishing attempt and forwards the email to their corporate CIRT for analysis. The CIRT identifies the email as an attempted spear phishing incident and distributes the indicators to their sharing partners.

Example Data Shared
The example data below provides sample data that would be exchanged in this spear phishing indicator exchange. The data is fictional. As mentioned earlier, the purpose of the pseudo-JSON is to show the desired structure of the solution, not to suggest using JSON as a format for the solution.
The scenario involves the indicator exchange from one CIRT to another about a Spear Phishing email that was sent to the board members of several defense contractors.  The malware family is identified by the URL and the attached executable. The sha256 hashes are provided for the attachment and the public key of the sender. Comments with a ‘//’ in front are for the purposes of understanding this representation, and there is no need to include them in the actual XML documents exchanged as part of the scenario.

{

Indicators:

  [

    {

      phishingLink    : { url: www.zeusevil.com<http://www.zeusevil.com>, malwareFamily: Zeus }  //URL in the body of the email

                             ipAddress: “196.167.14.81”  //IP address of the URL

                             sourceASNumber: “225”

                            Prefix: “18.144.0.0/16<http://18.144.0.0/16>”

timestamps : {

       sendingServer: {

                             ipAddress: “176.157.32.17”  //IP address where the email was sent from

                             sourceASNumber: “774”

                            prefix” “186.134.0.0/14<http://186.134.0.0/14>”

                             destination: “193.186.138.101” }  //IP address of the recipient

       email: {

                             fromAddress: “[email-masked]<mailto:[email-masked]>”

                             fromDomain: “evildave.com<http://evildave.com>”

                                    {CAName: “FakeCA”

                                     signed: “EvilDave”

                                     valid: “No”

                                     publicKey: “Yes”

 publicKeyHash: “sha256: 352bddec13e4e5257ee63854cb1f05de48043d09f9076070845307b7ce76c185}}

       DKIMSignature: “No”

      senderpolicyFramework: “zuesevil.com<http://zuesevil.com>. IN TXT \"v=spf1 a mx –all\””

       MIMEType: “text/plain”

Time: “09:10:24 UTC”

mailRecords: {“evildave.com MX preference = 10, mail exchanger = mail1.evildave.com<http://mail1.evildave.com>”

 “mail1.evildave.com<http://mail1.evildave.com> internet address = 176.157.32.17”} //located mail exchanger for //evildave.com<http://evildave.com>

                             fileSize: “152kb”

                             fileHash: “sha256: 141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184”

                             malwareFamily: “Zues” }

      }

   ]

}

--

Best regards,
Kathleen
_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile