Monday, September 30, 2013

2014 Malware and Memory Forensics Training Schedule Part 1

After a SOLD OUT class in Amsterdam last month, we are back with the part 1 of our training schedule for 2014. We will be making our first appearance on the west coast of the United States as well as our second appearance in Europe.

* January 20th - 24th in San Diego, CA 
* June 9th - 13th in London, UK

Instructors: Michael Ligh (@iMHLv2), Andrew Case (@attrc), Jamie Levy (@gleeda)

To request a link to the online registration site or to receive a detailed course agenda/outline, please send an email voltraining [[ at ]] memoryanalysis.net.

Please note there is still seating available for our November 2013 class in Reston VA, but that will not last long.

Students in our Amsterdam class wanted to share some feedback with you:
An ultimate course to sharpen your forensic and reverse engineering skills and to get weaponized to track and combat the most sophisticated pieces of malware. - Anthony (Council of the EU) 
The course was exceptional.  The depth and scope of the research conducted by the trainers was remarkable.  The fact that the trainers were able to provide comprehensive answers to any question posed was refreshing. - Vafa (Cisco) 
This course gave me in depth knowledge of memory forensics and windows malware functioning as a starting point for a whole new level of forensic analysis. - Marco (Fox-IT) 
The Volatility training was the best memory fundamentals that exists anywhere.  In the labs they go through many memory images with malware I have see(n) in the wild.  Their practical approach to using malware, memory and disk forensics are excellent. - Anonymous 
This course was enriching on so many levels.  Taught by people who know the tool from every angle.  Presenting interesting reallife challenges and supporting you whenever you are lost.  Best training I've had in years! - Clement (Price Waterhouse Cooper)
This is the only memory forensics course officially designed, sponsored, and taught by the Volatility developers. One of the main reasons we made Volatility open-source is to encourage and facilitate a deeper understanding of how memory analysis works, where the evidence originates, and how to interpret the data collected by the framework's extensive set of plugins. Now you can learn about these benefits first hand from the developers of the most powerful, flexible, and innovative memory forensics tool.

If neither of the announced dates and locations jive with your schedule, keep an eye on our blog for Part 2 of our 2014 training schedule.

Thursday, September 5, 2013

Leveraging CybOX with Volatility

Lately I've been playing around with Cyber Observable eXpression, CybOX, and created a plugin to help check for threat indicators in memory samples. In case you don't know, CybOX provides a vendor neutral format for expressing indicator information. As of late, it has been gaining a lot of momentum among security/forensics vendors and government agencies.  It has python bindings and an extensive schema that supports various disk, network and memory artifacts. There are also scripts available for converting OpenIOC indicators to CybOX format. The project has a lot of potential and the developers are very responsive.  As a result, it has the potential to provide a powerful capability to the Volatility community.  The initial release of the Volatility plugin currently supports the following observable artifacts:
  • Process names
  • IP addresses/domains
  • Mutexes
  • Open(ed) files
  • Services
  • Registry Keys/Values
These artifacts will be expanded as the need arises.

Obtaining Python-CybOX

Make sure to install the dependencies before downloading CybOX. If you are on Mac OSX, you can find newer versions of lxml in macport:
$ port search lxml
[snip]
py-lxml @2.3.2 (python, devel)
    Powerful and Pythonic XML processing library

py24-lxml @2.3.2 (python, devel)
    Powerful and Pythonic XML processing library

py25-lxml @2.3.2 (python, devel)
    Powerful and Pythonic XML processing library

py26-lxml @2.3.2 (python, devel)
    Powerful and Pythonic XML processing library

py27-lxml @2.3.2 (python, devel)
    Powerful and Pythonic XML processing library
Since I'm running Python 2.6, I chose py26-lxml. After getting all the dependencies installed, you can now install CybOX:
$ git clone https://github.com/CybOXProject/python-cybox.git
$ cd python-cybox
$ python setup.py build
$ sudo python setup.py install
If all goes well you shouldn't see any errors and can now use CybOX. You can try to import it to be sure it installed OK:
$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cybox.bindings.cybox_core as core_binding
>>> from cybox.core import Observables
>>>

Obtaining IOCs

Currently, there are not a lot publicly available indicator examples in CybOX format. Granted with support currently being added to both commercial and open source tools and with government agencies looking to distribute their indicators in CybOX format, we expect that to be changing soon. In the meantime and for the sake of testing, let's demonstrate how a vendor specific format like OpenIOC can be converted to CybOX.  There are a few places that one can find IOCs in the OpenIOC format, such as:
Not all of these will be useful from a memory forensics point of view, however, since they mostly cover disk artifacts. After an OpenIOC file is obtained, you can convert them into CybOX format. The conversion script can be found in the CybOX/Tools repository, which is obtainable through github:
$ git clone https://github.com/CybOXProject/Tools.git
$ cd Tools/scripts/openioc_to_cybox/
$ python openioc_to_cybox.py -i [IOC file to convert] -o [output file]
So let's say that we want to convert this OpenIOC file to CybOX format. We'd use the openioc_to_cybox.py script like so:
$ python openioc_to_cybox.py -i 6d2a1b03-b216-4cd8-9a9e-8827af6ebf93.ioc -o 6d2a1b03-b216-4cd8-9a9e-8827af6ebf93.ioc.xml
We can now use the output file 6d2a1b03-b216-4cd8-9a9e-8827af6ebf93.ioc.xml with CybOX

CybOXer: A New Volatility Plugin

We have created a plugin, called cyboxer, that allows users to use CybOX IOCs with Volatility. This plugin has the following options:
  -v, --verbose         Verbose information
  -c CYBOX, --cybox=CYBOX
                        CybOX output file (xml)
  -D DIRECTORY, --directory=DIRECTORY
                        Directory of CybOX xml files

The plugin must have either -c or -D as an option. The -v (verbose) flag prints out more information, including what files/handles/etc were responsive to the CybOX rule. The CybOX files are first parsed in order to obtain all observables and then the plugin enumerates the appropriate memory objects and compares them to the observable values. After this, the plugin parses out the CybOX compositions which contain the logic describing how these observables relate to each other. Supported logic is as follows:
  • Equals
  • Contains
  • DoesNotContain
  • DoesNotEqual
  • StartsWith
  • EndsWith
  • GreaterThan
  • GreaterThanOrEqual
  • LessThan
  • LessThanOrEqual
Other logic will be added at a later date as needed.

Example Usage

For this example, we'll use a CybOX file that was converted from this OpenIOC file against this memory sample:
$ python vol.py -f zeus.vmem cyboxer -c TEST/6d2a1b03-b216-4cd8-9a9e-8827af6ebf93.ioc.xml
Volatile Systems Volatility Framework 2.3_beta
Getting processes...
Getting handles...
Found the following IOC: Finds Zeus variants, twexts, sdra64, ntos
Items found:
    Type: WindowsHandleObjectType, Value: _AVIRA_, Condition: Contains
    Type: ProcessObjectType, Value: winlogon.exe, Condition: Contains
    Type: WindowsHandleObjectType, Value: system32\lowsec\user.ds, Condition: Contains
    Type: WindowsHandleObjectType, Value: system32\sdra64.exe, Condition: Contains
    Type: WindowsHandleObjectType, Value: system32\lowsec\local.ds, Condition: Contains
The "Value" is the value that was given in the CybOX observable. We also see the "Type" of the observable object and the "Condition" (logic) that was used to find the value in memory. If we want to see more information about what was responsive we can use the verbose flag. Additional information includes the Observable ID, if it is a type (File, Mutex etc), a flag indicating whether or not it was found in memory (should be True) and the value of the item that was found in memory that matches the Composition criteria:
$ python vol.py -f zeus.vmem cyboxer -c TEST/6d2a1b03-b216-4cd8-9a9e-8827af6ebf93.ioc.xml -v
Volatile Systems Volatility Framework 2.3_beta
Getting processes...
Getting handles...
Found the following IOC: Finds Zeus variants, twexts, sdra64, ntos
Items found:
    Type: WindowsHandleObjectType, Value: _AVIRA_, Condition: Contains, ID: openioc:indicator-item-e033b865-95ba-44ab-baa5-3b1e8e5f348c, IsType: False, IsFound: True
        Responsive item: \Device\NamedPipe\_AVIRA_2109
        Responsive item: _AVIRA_2109
    Type: ProcessObjectType, Value: winlogon.exe, Condition: Contains, ID: openioc:indicator-item-50455b63-35bf-4efa-9f06-aeba2980f80a, IsType: False, IsFound: True
        Responsive item: winlogon.exe
    Type: WindowsHandleObjectType, Value: system32\lowsec\user.ds, Condition: Contains, ID: openioc:indicator-item-1c3f8902-d4e2-443a-a407-15be3951bef9, IsType: False, IsFound: True
        Responsive item: \Device\HarddiskVolume1\WINDOWS\system32\lowsec\user.ds
    Type: WindowsHandleObjectType, Value: system32\sdra64.exe, Condition: Contains, ID: openioc:indicator-item-c5ae706f-c032-4da7-8acd-4523f1dae9f6, IsType: False, IsFound: True
        Responsive item: \Device\HarddiskVolume1\WINDOWS\system32\sdra64.exe
    Type: WindowsHandleObjectType, Value: system32\lowsec\local.ds, Condition: Contains, ID: openioc:indicator-item-7fab12d1-67ed-4149-b46a-ec50fc622bee, IsType: False, IsFound: True
        Responsive item: \Device\HarddiskVolume1\WINDOWS\system32\lowsec\local.ds

Below we can see an example of cyboxer running against a directory of CybOX xml files
$ python vol.py -f zeus.vmem cyboxer -D TEST
Volatile Systems Volatility Framework 2.3_beta
Getting processes...
Getting opened files...
Getting handles...
Getting services...
Getting connections...
Getting registry keys...
Found the following IOC: This is a sample IOC that will hit on a number different artifacts present on a Windows computer. This IOC is used to test or illustrate the use of an IOC.
Items found:
 Type: FileObjectType, Value: win.ini, Condition: Equals
 Type: WindowsServiceObjectType, Value: ('TrkWks', None, None), Condition: Equals
 Type: FileObjectTypeExt, Value: evt, Condition: Contains
 Type: FileObjectType, Value: sens.dll, Condition: Equals


Found the following IOC: Finds Zeus variants, twexts, sdra64, ntos
Items found:
 Type: WindowsHandleObjectType, Value: _AVIRA_, Condition: Contains
 Type: ProcessObjectType, Value: winlogon.exe, Condition: Contains
 Type: WindowsHandleObjectType, Value: system32\lowsec\user.ds, Condition: Contains
 Type: WindowsHandleObjectType, Value: system32\sdra64.exe, Condition: Contains
 Type: WindowsHandleObjectType, Value: system32\lowsec\local.ds, Condition: Contains
Below is an example of cyboxer running against a flame hibernation file:
$ python vol.py -f hiberfil.sys cyboxer -c TEST/af2e8c80-13db-4a57-99ac-460ccd192333.ioc.xml -v
Volatile Systems Volatility Framework 2.3_beta
Getting processes...
Getting opened files...
Getting handles...
Getting registry keys...
Found the following IOC: IOCs to detect the presence of the Flamer framework
Items found:
 Type: FileObjectType, Value: rccache.dat, Condition: Equals, ID: openioc:indicator-item-a82530a3-2351-4625-a578-fecf9979f735, IsType: False, IsFound: True
  Responsive item: \Device\HarddiskVolume1\Program Files\Common Files\Microsoft Shared\MSSecurityMgr\rccache.dat
 Type: WindowsHandleObjectType, Value: microsoft shared_mssecuritymgr_ssitable, Condition: Contains, ID: openioc:indicator-item-c2b094ad-e353-4433-90cb-4048c62f0ff2, IsType: False, IsFound: True
  Responsive item: c__program files_common files_microsoft shared_mssecuritymgr_ssitable
  Responsive item: c__program files_common files_microsoft shared_mssecuritymgr_ssitable_SHR
 Type: WindowsHandleObjectType, Value: microsoft shared_mssecuritymgr_mscrypt.dat, Condition: Contains, ID: openioc:indicator-item-3be23f29-dc73-4baa-8ad3-4b0cd1c2b6dd, IsType: False, IsFound: True
  Responsive item: c__program files_common files_microsoft shared_mssecuritymgr_mscrypt.dat
  Responsive item: c__program files_common files_microsoft shared_mssecuritymgr_mscrypt.dat_SHR
  Responsive item: c__program files_common files_microsoft shared_mssecuritymgr_mscrypt.datShared
 Type: WindowsHandleObjectType, Value: TH_POOL_SHD_PQOISNG, Condition: Contains, ID: openioc:indicator-item-209070e1-50d7-489d-af11-e0f2b3df23d5, IsType: False, IsFound: True
  Responsive item: TH_POOL_SHD_PQOISNG_912SYNCMTX
  Responsive item: TH_POOL_SHD_PQOISNG_1244SYNCMTX
  Responsive item: TH_POOL_SHD_PQOISNG_1604SYNCMTX

Notes


Only the aforementioned items are supported at this time, however there are plans to expand the plugin sometime in the future. Unsupported items are currently ignored and have no affect on the composition logic. Only items that are found are printed out. Items that have "DoesNotEqual" and "DoesNotContain" are not printed, since they are often used in combination with other observable values (this may change sometime in the future, however). Also file objects are always evaluated as "Contains" when "Equals" has been given as a condition. This is because in memory these file objects have the entire kernel path (\Device\HarddiskVolume1\...) which will never match something like "rccache.dat" alone.

Conclusion


This plugin is still under development, but we hope that you will find this plugin useful in your investigations. I would like to thank Ivan Kirillov, Greg Back and the rest of the CybOX team for maintaining this project and for their help and support. If you are interested in testing this plugin, please drop me a line at jamie.levy {at} gmail {dot} com.