Friday, April 4, 2014

Malware analysis basics

Malware can be complicated and hard to analyze without years of experience and a computer science degree.  Not all malware created equal and the best way to learn about malware is to look at some easy malware deployment methods to develop pattern recognition and critical thinking. 

Old methods die hard and this example explores the way malware still uses hosts file hijacking that's been around since the dawn of the Internet.  This example also explores basic registry modification malware can perform in order to make the hosts file and the infestation consistent on the local system.

Analysis is logic and not magic!!!

http://youtu.be/suG8NafYI3E

Wednesday, March 19, 2014

GPS Tracking

The news item "MH370: FBI investigators to examine flight simulator used by pilot" triggered this video to show how Google Earth, metadata, and GPS coordinates can be used to create a very visual trace of "indirect" suspect actions.

http://youtu.be/cddm4e9YClA



Saturday, March 8, 2014

Daylight Savings Time Exploration

Daylight savings time change and operating system adoption to the change as well as file system and application logs can "eat your lunch" if you are not prepared for in case analysis.  User actions are the artifacts that you are supposed to reveal, but being off an hour in your analysis can be devastating to the case.  So, don't just read and understand registry keys and the concept of time change, but be able to verify the way the changes will take effect before you are faced with a case with this issue.

Monitor the changes over night as they happen

March and November are the months that gives you the opportunity to test the effects of daylight savings time changes in real time.  A day before the change, you can create a simple batch file to create files on your system one minute at a time.  It will create the files as the time rolls over and the daylight savings time takes effect. 

Create the following batch file and schedule it to run from 11PM to 4AM

REM schedule with
REM C:\Windows\system32>schtasks /create /TN daylight_change /SC MINUTE /MO 1 /TR c:
\monitor.bat /SD 03/08/2014 /ED 03/09/2014 /ST 23:00 /ET 04:00
REM if not using /K to terminate the task, then you can manually remove it
REM schtasks /delete /TN daylight_change /f
REM you can schedule tasks in GUI by running
REM control schedtasks
REM or
REM taskschd.msc
@echo OFF
for /f "tokens=2-4 delims=/ " %%a in ('date /T') do set month=%%a
for /f "tokens=2-4 delims=/ " %%a in ('date /T') do set day=%%b
for /f "tokens=2-4 delims=/ " %%a in ('date /T') do set year=%%c
for /f "tokens=1-3 delims=:/ " %%a in ('time /T') do set hour=%%a
for /f "tokens=1-3 delims=:/ " %%a in ('time /T') do set minute=%%b
for /f "tokens=1-3 delims=:/ " %%a in ('time /T') do set tod=%%c
set time=%month%%day%%year%%hour%%minute%%tod%
dir c:\ > c:\temp\file_%time%.txt

Note: Windows XP does not support /ET and /ST must be in HH:MM:SS format i.e. 23:00:00

Code it to Learn It
Create code and understand the SYSTEMTIME structure that Microsoft uses that might be helpful in other structure analysis later as you investigate new artifacts.  Understanding structures helps you develop pattern recognition for closed source systems where low level analysis is needed.  Structures are the easier to understand for new to programming if you run some code that uses structures.  The TimeZoneInformation registry key can give you a good example of SYSTEMTIME usage and you can use the values to verify your understanding of structures as they are stored.  Pay attention to data types especially the size of WORD.  You can compile the following code in Visual Studio that should be free to download for students from DreamSpark ( https://www.dreamspark.com/ ) or use a free compiler like Dev-C++ ( http://sourceforge.net/projects/orwelldevcpp/ )

 Always use reliable resource as you form your opinion on how data structures work by reading the vendor or developer's documentation and not someone else's interpretation.

http://msdn.microsoft.com/en-us/library/ms724950(v=VS.85).aspx

/*
Read time zone information from registry
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\TimeZoneInformation
Value 2
  Name:            StandardStart
  Type:            REG_BINARY
  Data:           
00000000   00 00 0b 00 01 00 02 00 - 00 00 00 00 00 00 00 00
Value 6
  Name:            DaylightStart
  Type:            REG_BINARY
  Data:           
00000000   00 00 03 00 02 00 02 00 - 00 00 00 00 00 00 00 00
Understand the SYSTEMTIME structure
          typedef struct _SYSTEMTIME {
                WORD wYear;                // 1601 - 30827 
                WORD wMonth;               // Jan(1) - Dec(12)
                WORD wDayOfWeek;           // Sun(0) - Sat(6)
                WORD wDay;                 // 1 - 31
                WORD wHour;                // 0 - 23
                WORD wMinute;              // 0 - 59
                WORD wSecond;              // 0 - 59
                WORD wMilliseconds;        // 0 - 999
         } SYSTEMTIME, *PSYSTEMTIME;
*/
//Experiment with time values
#include <windows.h>  // GetSystemTime, GetLocalTime, SYSTEMTIME
#include<iostream>    //cin , cout, endl
//#include <stdio.h>  //printf
#include <fstream>    // ifstream, ofstream - file stream handling
#include <ctime>      //time_t, time(), localtime()
#include<iomanip>     //setw(), setfill()
using namespace std;
int main()
{
    ofstream outFile;
    //log the file times into c:\temp\time_output.txt by appending the values
 outFile.open("c:\\temp\\time_output.txt",ios::app);
 SYSTEMTIME st, lt;
   
    GetSystemTime(&st);
    GetLocalTime(&lt);
   
    //printf("The system time is: %02d:%02d\n", st.wHour, st.wMinute);
    //printf(" The local time is: %02d:%02d\n", lt.wHour, lt.wMinute);
   
    cout<<"The system time is: "<<setw(5)<<st.wHour<<":"<<st.wMinute<<endl;
    cout<<" The local time is: "<<setw(5)<<lt.wHour<<":"<<lt.wMinute<<endl<<endl;
   
    outFile<<"The system time is: "<<setw(5)<<st.wHour<<":"<<st.wMinute<<endl;
    outFile<<" The local time is: "<<setw(5)<<lt.wHour<<":"<<lt.wMinute<<endl;
   
    outFile.close();
/*  
   struct tm {
  int tm_sec;   // seconds of minutes from 0 to 61
  int tm_min;   // minutes of hour from 0 to 59
  int tm_hour;  // hours of day from 0 to 24
  int tm_mday;  // day of month from 1 to 31
  int tm_mon;   // month of year from 0 to 11
  int tm_year;  // year since 1900
  int tm_wday;  // days since sunday
  int tm_yday;  // days since January 1st
  int tm_isdst; // hours of daylight savings time
}
*/

   // current date/time based on current system
   time_t now = time(0);
   cout << "Number of seconds since January 1, 1970: " << now << endl<<endl;
   tm *ltm = localtime(&now);
  
      // print various components of tm structure.
   cout << " Year: "<<setw(11)<< 1900 + ltm->tm_year << endl;
   cout << "Month: "<< setw(11)<<1 + ltm->tm_mon<< endl;
   cout << "  Day: "<<setw(11)<<  ltm->tm_mday << endl;
   cout << " Time: "<<setw(5)<< 1 + ltm->tm_hour << ":";
   cout << 1 + ltm->tm_min << ":";
   cout << 1 + ltm->tm_sec << endl;
  
    return 0;
}

Note: Newer compilers will not allow to use deprecated function localtime().  Use localtime_s() instead.
struct tm timeinfo;
localtime_s(&timeinfo, &now); 
        cout << " Year: " << setw(11) << 1900 + timeinfo.tm_year << endl;


UTC time stamps provide a more consistent view of file metadata.
Filename Size (bytes) Created Modified Accessed
file03092014-01_54_AM.txt 102262 2014-Mar-09 07:54:00.171875 UTC 2014-Mar-09 07:54:00.203125 UTC 2014-Mar-09 07:54:00.203125 UTC
file03092014-01_55_AM.txt 102262 2014-Mar-09 07:55:00.156250 UTC 2014-Mar-09 07:55:00.187500 UTC 2014-Mar-09 07:55:00.187500 UTC
file03092014-01_56_AM.txt 102262 2014-Mar-09 07:56:00.156250 UTC 2014-Mar-09 07:56:00.187500 UTC 2014-Mar-09 07:56:00.187500 UTC
file03092014-01_57_AM.txt 102262 2014-Mar-09 07:57:00.156250 UTC 2014-Mar-09 07:57:00.187500 UTC 2014-Mar-09 07:57:00.187500 UTC
file03092014-01_58_AM.txt 102262 2014-Mar-09 07:58:00.156250 UTC 2014-Mar-09 07:58:00.187500 UTC 2014-Mar-09 07:58:00.187500 UTC
file03092014-01_59_AM.txt 102262 2014-Mar-09 07:59:00.156250 UTC 2014-Mar-09 07:59:00.187500 UTC 2014-Mar-09 07:59:00.187500 UTC
file03092014-03_00_AM.txt 102262 2014-Mar-09 08:00:00.156250 UTC 2014-Mar-09 08:00:00.187500 UTC 2014-Mar-09 08:00:00.187500 UTC
file03092014-03_01_AM.txt 102262 2014-Mar-09 08:01:00.156250 UTC 2014-Mar-09 08:01:00.187500 UTC 2014-Mar-09 08:01:00.187500 UTC
file03092014-03_02_AM.txt 102262 2014-Mar-09 08:02:00.265625 UTC 2014-Mar-09 08:02:00.328125 UTC 2014-Mar-09 08:02:00.328125 UTC
file03092014-03_03_AM.txt 102262 2014-Mar-09 08:03:00.156250 UTC 2014-Mar-09 08:03:00.187500 UTC 2014-Mar-09 08:03:00.187500 UTC
file03092014-03_04_AM.txt 102262 2014-Mar-09 08:04:00.156250 UTC 2014-Mar-09 08:04:00.187500 UTC 2014-Mar-09 08:04:00.187500 UTC

Sunday, March 2, 2014

Windows 8.1 Volume Shadow Copies and File History

Volume shadow copy analysis is not new to investigations, but the new feature of tracking file changes away from volume shadow copies in Windows 8.1 can lead to a new evidence collection methodology.  Files on the systems drive are still protected by the process of creating a restore point, but file history can also create another copy of files from the system partition.  Turning on the system protection does not give an option anymore to create just a system restore point or one that also includes files.  Clicking "Create..." will only allow you to name the manual restore point.

File history is a service that is new to Windows and it is not enabled by default, most likely, since a dedicated drive needs to be selected to host the history of files.


The service is created to "Protects user files from accidental loss by copying them to a backup location".


It creates a folder structure resembling the actual hierarchical structure of the original file location including the name of the machine where it came from.

T:\>tree FileHistory
Folder PATH listing for volume VOLUME_NAME
Volume serial number is ####-####
T:\FILEHISTORY
└───<UID>
      └───<MACHINE_NAME>
           ├───Configuration
           └───Data
                 └───C
                       └───Users
                            └───<UID>
                                  ├───Contacts
                                  ├───Desktop
                                  ├───Documents
                                  ├───Favorites
                                  │     └───Dell
                                  ├───Music
                                  ├───Pictures
                                  └───Videos
By default, libraries, desktop, contacts, and favorites are backed up.  The configuration settings can be examined for the configured drive and follow the traditional mounted device analysis to locate the actual drive.

C:\Users\<UID>\AppData\Local\Microsoft\Windows\FileHistory\Configuration\Config#.xml 
Excerpt from the configuration file shows drive details where the file history will be located
<Target>
    <TargetName>ThawSpace0</TargetName>
    <TargetUrl>T:\</TargetUrl>
    <TargetVolumePath>\\?\Volume{8c66088c-9e66-11e3-8252-806e6f6e6963}\</TargetVolumePath>

System log file
C:\Windows\System32\winevt\Logs\Microsoft-Windows-FileHistory-Core%4WHC.evtx

The documents and their changes are saved in the corresponding directory marked with UTC time stamps.

T:\FileHistory\<UID>\<MACINE_NAME>\Data\C\Users\<UID>\Documents>dir
Volume in drive T is VOLUME_NAME
Volume Serial Number is F4A8-C897

Directory of T:\FileHistory\<UID>\<MACHINE_NAME>\Data\C\Users\<UID>\Documents

03/02/2014 09:29 PM 15,544 Report Template (2014_03_03 03_45_37 UTC).odt
02/26/2014 08:49 AM 83,619 Report Template (2014_03_03 03_45_37 UTC).ott
03/02/2014 09:48 PM 14,450 Report Template (2014_03_03 04_09_19 UTC).odt
02/26/2014 08:49 AM 83,610 Report Template (2014_03_03 05_04_56 UTC).odt

The default settings would suggest a long term forensic value of these files since they will be kept "forever" and backed up every hour.  Even though, I could see multiple instances of backed up files, the File History event log did not show any activity.  This process will need further investigation to learn if the default values will trigger as they are set by default and if the event log will be generated by these events.


Some people might miss the Previous Version tab in the file properties, but there is a simple way around this change in Windows 8.1, just look at the file's property using a null session.


The above syntax will work on any drive and the file property will show the Previous Version tab, but populating it with values will also need further investigation since just creating restore points did not populate it all.


Thus, it seems like there is no backup of the file at all looking at it this way.  The old fashioned looking at the shadow volumes still works like it did in Windows 7.

vssadmin list shadows /for=c:|findstr Contained
Contained 1 shadow copies at creation time: 2/25/2014 3:15:33 PM
Contained 1 shadow copies at creation time: 2/26/2014 9:43:36 PM
Contained 1 shadow copies at creation time: 2/28/2014 2:16:11 PM
Contained 1 shadow copies at creation time: 3/2/2014 11:08:45 PM

So, the restore points exist, but the question was if the restore points contained the changes of the files or not.  To test it, I have deleted a couple of files ( Report Template.odt and .ott ) and removed them from the recycle bin.  The files were gone.

Since the shadow volumes existed, I used the Shadow Explorer to drill down into the file structure with that tool.

Sure enough, the files were still there waiting to be restored.  The time stamp was not accurate besides the oldest time stamp,  but the command line method captured them more accurately.

The command line method also allowed to access and copy the deleted files out of the volume shadow.  

C:\Windows\system32>vssadmin list shadows /for=c:|findstr GLOBALROOT
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4

C:\Windows\system32>mklink /d c:\shadow_copy3 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\
symbolic link created for c:\shadow_copy3 <<===>> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\

C:\Windows\system32>cd c:\shadow_copy3\Users\<UID>\Documents

c:\shadow_copy3\Users\<UID>\Documents>dir
Volume in drive C is OS
Volume Serial Number is E828-D083

Directory of c:\shadow_copy3\Users\<UID>\Documents
02/26/2014 08:49 AM 83,610 Report Template.odt
02/26/2014 08:49 AM 83,619 Report Template.ott

Conclusion
Volume shadow copies will be accessible in cases on the secondary storage devices like before, but it will be more important to also collect removable storage devices and look for File History based evidence not just as a single source, but also to validate volume shadow copy based located evidence to show human interaction with the digital data.  The long history of file changes might reveal human intention as related to digital data manipulation.  As always, understanding the process is IT, but interpreting the relevant artifacts and connecting those artifacts to human interaction is what forensic investigations are all about.  





Tuesday, February 18, 2014

PCI DSS Poster

This poster is a simplified version of consequences related to not being compliant with PCI DSS requirements and fine structure by credit card provider.

PCI DSS Cost of not being compliant poster

Sunday, February 16, 2014

Transfer of Evidence or a DNA of an Event



In this page, we'll be focusing on evidence or data location as a process based discovery where we have to triage the event in question. In any digital system, humans interact with an operating system by using applications in turn the operating system interacts with the hardware. Thus, relevant evidence transfer must take place at each of these interaction points.
Let's start with a reference to this theory that has been used in forensic science, Locard's exchange principle. Edmond Locard (1877-1966) was the founder and director of the Institute of criminalistics at the University of Lyons in France. Locard believed that whenever a criminal came into contact with his environment, a cross-transference of evidence occurred. He believed that "every criminal can be connected to a crime by dust particles carried from the scene." (Saferstein, Richard, Criminalistics, Seventh Ed., 2001)

Therefore, relevant evidence can connect a person to a crime scene by blood, semen, saliva, and hair, to paint, explosive, drugs, impressions, and chemicals. In digital device interaction or even network communication, the basic premise is that where ever we go ( browse or launch an application ), we will carry some evidence with us and leave some behind. We cannot interact with digital devices without a transfer of evidence occurring.
In most cases, the main transfer points in local systems are:
- UA - User to Application ( i.e user starts IE browser )
- AOS - Application to Operating System ( i.e. IE browser stores recently typed URLs in the registry )
- UOS - User to Operating System ( i.e. user interrupts the boot process to load kernel drivers for a SCSI drive )
- OSH - Operating System to Hardware ( i.e. OS saves a file to the physical drive or temporarily stores data in physical memory )
- UH - User to Hardware ( user changes the hard drive jumper or sets the thumb drive switch to read only )

Note: In a network environment, the data path crosses network devices where transfer takes place as well.

To demonstrate this visually, I have designed a tripple helix structure of the interaction between user, application, and OS. The most challenging evidence to validate and present as an admissible evidence is UA, UOS, UH. AOS, OSH, and network device artifacts are easier to classify as admissible evidence since they are not hearsay, but business records.



Monday, February 10, 2014

Back to basics - Metadata

Metadata can be crucial information to find out information about the stored data that can be under "attack" by those practicing eDiscovery.  We know about locally stored data's metadata while the same data generated metadata in transit is getting less focus.  We can find out file system and application generated metadata and feel very comfortable with this known knowns.  Transmitting this same data can generate metadata on the network that we know, but the full extent of the collected data related to the content is unknown as it is getting further and further away from the local system.  What information is collected in the cloud can be very vague and lesser known or not known at all to the local data owner.  Thus, it adds another layer of uncertainty.