Subject: [mile] Watchlist/malware example

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Jul 2015 15:46:46 -0400

Hello,

As promised, I am sending a few examples with descriptions that were
supposed to be added to the Guidance draft.  I think the XML made it into
the draft, but not the descriptions.  I'll break this out into a few emails
by attack type.  The schema version used was somewhere between 1-2, so
updates to the examples will be necessary, but should be pretty easy.

** This example appears to correspond with the IODEF Guidance XML included
for "A.1  Malware"

The IODEF guidance document needs to be updated to use example.com, IP
addresses ok for RFCs, and remove company names (emccirt).

Watchlist Scenarios Scenario #1

Sharing of Malware Data Related to an Incident.  This use case describes
CIRT to CIRT sharing.

Background Information
Organization 1 provides a mirror copy of current knowledge via process not
covered by proof of concept.  Organization 1 detects an incident, and puts
data about malware found during incident into backend system. Organization
1 decides to share incident information with Organization 2 about malware
discovered.  This could be a human decision or part of an automated
process. How this actually happens is out of scope of the PoC.
Use Case Steps:

1.     Organization 1 has a sharing agreement with Organization 2, and has
already been configured with the IP address of Organization 2’s RID Agent

2.     Organization 1’s RID Agent connects to Organization 2’s RID Agent,
and mutual authentication occurs using PKI certificates.

3.     Organization 1 uses pushes out a document that has the following
data for N pieces of discovered malware using the a RID Report Message:

a.     Md5, Sha1, and Sha256 hash of file

b.     Registry Settings Changed

c.     C&C Information

4.     Organization 2 receives RID Report message, sends RID
Acknowledgement message

5.     Organization 2 stores the data in a format that makes it possible
for the back end to know which source the data came from.

This scenario consists of one RID Report message and an Acknowledgement for
the RID Report Message.
Example Data Shared

The example data below gives sample data that would be exchanged in this
watch list. The data is derived from multiple ThreatExpert and VirusTotal
data points. The URLs that the data is derived from is in the comments for
the JSON below. As mentioned earlier, the purpose of the 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 exchange between 2 CIRTs of data about three
malware families. The first malware family is identified by a single
executable, and the md5 and sha1 hashes are given. The analysis performed
shows 2 registry values created by that sample, and a single C&C domain.
The second entry in our example has two different malicious files of a
malware strain that is different from the first entry. Therefore there are
two hash sections for that malware family in the second entry. The third
entry is a synthetic example. It is given to show different enumerations
for registry actions, as well as a sample with multiple C&C callbacks.

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. Part of the role in the JSON
comments is to reference where the ‘real’ data came from, in order to
assuage any concerns that real company data was used in these examples
without being properly vetted for disclosure. A backslash followed by quote
(“) is used to escape a quote character in the value being represented.

{

Indicators =

  [

    //Simple Zbot/Zeus Sample

    {

      comment : “Zeus. See
http://www.threatexpert.com/report.aspx?md5=e2710ceb088dacdcb03678db250742b7
for more details”

      hashes  : [ { md5: 0x2E8880980D62447E9790AFA89513F0A4, sha1:
0x6751A253483A67D86E0F84760F61F10BBCC2EDFF } ]

      regKeys : [ { hive: HKLM, key:
"Software\Microsoft\Windows\CurrentVersion\Run",

                      action: ADD_VALUE, value: { name: "tamg", value:
“\”\”%System%\wins\mc.exe\”\”” } },

                  { hive: HKLM, key:
"Software\Microsoft\Windows\CurrentVersion\Run",

                      action: ADD_VALUE, value: { name: "dqo", value:
"\"\"%Windir%\Resources\Themes\Luna\km.exe\”\”" } } ]

      C&C     : [ { url: "
http://zeus.556677889900.com/log-bin/lunch_install.php?aff_id=1&lunch_id=1&maddr=&action=install"
} ]

    },

    // Cridex sample with two different hashes for malware with same
behavior

    {

      comment : “Cridex samples. See
http://www.threatexpert.com/report.aspx?md5=c3c528c939f9b176c883ae0ce5df0001

                      and
http://www.threatexpert.com/report.aspx?md5=43cd850fcdade4330a5bea6f16ee971c
for more

                      information”

      hashes  : [ { md5: 0x43CD850FCDADE4330A5BEA6F16EE971C, sha1:
0x7263FE0D3A095D59C8E0C895A9C585E343E7141C },

                  { md5: 0xC3C528C939F9B176C883AE0CE5DF0001, sha1:
0x4295D0711321899E310CCD8A12EC024AB345D8F4 } ]

      regKeys : [ { hive: HKCU, key:
"Software\Microsoft\Windows\CurrentVersion\Run",

                      action: ADD_VALUE, value: { name: "KB00121600.exe",
value: "\”\”%AppData%\KB00121600.exe\”\”" }]

      C&C     : [ { ipv4=87.204.199.100 proto=”tcp” port=8080 } ]

    },

    // Synthetic sample – Really to show the types of registry enumerations
we should probably

    // be able to support, as well as showing SHA-256 hash

    {

      // hash comes from

      //
https://www.virustotal.com/file/141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184/analysis/

      comment  : “Synthetic sample “

      hashes   : [ { sha256:
141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184 } ]

      // reg keys derived from
http://www.threatexpert.com/report.aspx?md5=1b25ef9be4fcf11ef56b7048d522739f

      regKeys : [ { hive: HKLM, key:
"SYSTEM\CurrentControlSet\Services\.Net CLR",

                      action: ADD_KEY },

                  { hive: HKLM, key:
"SYSTEM\CurrentControlSet\Services\.Net CLR\Parameters",

                      action: ADD_KEY },

                   { hive: HKLM, key:
"SYSTEM\CurrentControlSet\Services\.Net CLR\Parameters",

                      action: ADD_VALUE, value: { name: "ServiceDll",
value: "C:\bad.exe" } ]

                  { hive: HKLM, key:
"SYSTEM\CurrentControlSet\Services\.Net CLR\Parameters",

                      action: MODIFY_VALUE, value: { name: "Bar", value:
“baz”} ]

                   // See future considerations section to see why these
two are no longer part of

                   // The use case

                  //{ hive: HKLM, key:
"SYSTEM\CurrentControlSet\Services\.Net CLR\Parameters",

                  //    action: DELETE_VALUE, value: { name: "Foo"} ]

                   //{ hive: HKLM, key:
"SYSTEM\CurrentControlSet\Services\.Net CLR\Parameters\DeleteMe",

                   //   action: DELETE_KEY },

      // The rest of this data is synthetic,

      C&C     : [ { url: “http://foo.com:12345/evil/cc.php” },

     { domain: “evil.com” },

     { ipv4: 1.2.3.4 },

                   { ipv4: 5.6.7.8 },

                  { ipv6: 2001:dead:beef:: } ]

    }

  ]

}
Scenario #2

Sharing of Intelligence Feed from a threat intelligence provider to a
consumer.

Background Information
Organization 1 is a provider of threat intelligence, and Organization 2 is
a customer. Organization 1 provides a mirror copy of current knowledge via
process not covered by this proof of concept. Organization 1’s Agent has
been pre-configured with the IP address of each of its customers.
Use Case Steps:

1.     Organization 1 provides batch updates on a daily basis of hundreds
of data elements. Organization 1 connects to Organization 2’s RID Agent.

2.     The comment field for each of these is used to notate if the threat
is part of a malware campaign tracked by the threat intelligence
organization.

3.     Also, sharing of each kind of data type is optional. For example one
day they may only distribute a few URLs, and no Malware, Registry Entries,
etc.

a.     Malware (for each malware entity, multiple fields may be included,
for example multiple MD5 hashes describing variants of the same piece of
malware. Look at example representation for details).

                                               i.     Hash of malware

                                             ii.     Command and Control
callback domain/IP address/ and Port if known

                                            iii.     Registry entries
created/deleted/modified by the malware

b.     URL’s of known malware distributions

c.     IPv4, IPv6, and/or domain names of malware distribution or other
command and control sites

4.     Organization 2 stores the data in a format that makes it possible
for the back end to know which source the data came from.

5.     New data is shared each day.
Example Shared Data

In this example, a Threat Intelligence provider is sharing a large amount
of indicators with its customer. While some of the indicators might “in
reality” be related, the provider is listing each indicator separately and
not showing any relationship between indicators.

{

Indicators =

    [

        {   hashes    : [ { md5: 0x12341 } ] },

         // The closing of the outer brace above indicates that the
previous indicator is completely distinct and

         // unrelated to any of the following indicators. This is true for
each of the indicators

        {   hashes    : [ { md5: 0x12346 } ] },

         // Independent from next indicator...

        {   c&C       : [ { url: "http://www.bad2.com/bad.jsp" } ] },

         // etc..

        {   c&c       : [ { ipv4: 1.2.3.4 } ] },

        {   c&c       : [ { ipv6: 2001:0Db8:AC10:FE01:: } ] },

        {   regKeys   : [ { hive: HKLM, key:
"Software\Microsoft\Windows\CurrentVersion\Run",

                            type: ADD_VALUE, value: { name: "MALWR", value:
"C:\Bad.exe" } } ] },

        {   regKeys   : [ { hive: HKLM, key:
"Software\Microsoft\Windows\CurrentVersion\Run",

                            type: ADD_VALUE, value: { name: "121ds2",
value: "C:\adware.exe" } } ] },

        {   malEmails : [ { domain: smtp.spear-phisher.com } ] },

        {   malDistrib: [ { url: www.takenOverFamilyFlowers.com/good.html }
] },

        {   malDistrib: [ { ipv4: 1.2.3.0/24 } ] },

        {   malDNS    : [ { ipv4: 4.5.6.7 } ] },

        {   malOther  : [ { ipv6: 2001:DEAD:BEEF:: } ] }

    ]

}

-- 

Best regards,
Kathleen