Daily Blog #130: Detecting Fraud Sunday Funday 10/27/13 Part 3 - SetMace

Hello Reader,
            Yesterday we reviewed the timestomp tool and showed how simple MFT analysis can defeat it. Today we are going to go into the newest version of setmace v1006 which not only can modify the STDINFO timestamps but the FILENAME timestamps as well. I'm not sure how widely known setmace is but I will tell you that its very good at what it does as we'll see in the screenshots below. Prior versions of setmace did some tricks with file moving to reset the FILENAME timestamps but in version v1006 it actually modifies the physical disk itself leaving very few traces of its actions. Setmace will work on NTFS and FAT file systems.

Things to understand

What it does
Setmace will access the underlying physical disk and modify the $MFT directly changing the timestamps you specify (STDINFO or FILENAME or both) or cloning them from another file. Since this is direct physical disk access there are no $logfile or USN entries that show these changes.

What it does not do
It does not change the MFT record number, sequence number or find other artifacts pointing to it. That does not mean that future versions couldn't be modified to further obfuscate the original timestamps.

Capabilities by OS

Windows XP
On a Windows XP system setmace can reset timestamps on a file on any volume as XP's security model did not restrict access to the physical disk. Further since Windows XP does not have a USN Journal by default the only way to prove the original timestamps of a file will either be through the $Logfile or shell items pointing to the file.

Windows Vista/7/8
On a Windows Vista/7/8 system setmace cannot access the physical disk of any system volume, but it can access the physical disk of non system volumes. In my virtual environment I created two additional partitions one which i ran setmace from and the other where i stored the files whose timestamps i reset.

What does it look like?

After setmace runs this is what the STDINFO timestamps look like:

This is what the FILENAME timestamps look like for both the 8.3 and Unicode filenames:

I've used 1-1-1970 here to make it easy to spot that this is a fake timestamp but notice something here, the milliseconds here are set. This is another standard forensic analysis technique to detect timestamp modification, finding files where the milliseconds are set to 0. In this instance our suspect could set the full timestamp value to any date/time desired or clone a valid file. Scary stuff

The USN Journal contains no entries as the timestamp alteration occured outside the filesystem driver, we do have an entry from the usage of the file prior to its timestamp alteration that we can gather a last true usage time from:

The $Logfile contains the original timestamps of these files from its creation:

However there is no entry in any of the filesystem journal logs we normally rely on that would detail the fact that a timestamp change occured, it would be up to the analyst to look for indicators.

What indicators are left?

Don't lose hope, this isn't a blank check just yet for undetectable timestamp alteration. We still have several analysis points left that can reveal past true timestamps of this file:

• Shell Items contain timestamps, compare them to the MFT to determine if MFT creation date is different. Examples of Shell item containers include
• LNK Files
• Shell bags
• Jumplists
• Other registry keys being identified but that I don't have in front of me :) Sounds like a good post for next week.
• MFT entry and sequence numbers, is the file outside the range that it should be in to be created at that time? 
• Registry MRUs
• System restore points
• Vista/7/8 - Shadow copies - Compare MFTs
• XP - Restore Points  - Parse LNK files for shell items
• Any activity taken place through the filesystem driver prior to the timestamps change will still be in the $logfile and USN
• Prefetch of the setmace execution

Now having said this, not every analyst will think of these things. This will require an additional  steps in your process to look for these kinds of indicators and likely won't be the first thing you check for. Setmace will modify timestamps but it doesn't eliminate any of the IOCs/Artifacts you are already looking for.

I am going to be looking deeper into setmace to see what other artifacts of execution exist, I'll follow up on this on a later blogpost. Until then get some rest, these anti-forensic tools will only get better and you will have to do get better as well to keep up.

Tweet

Daily Blog #129: Detecting Fraud Sunday Funday 10/27/13 Part 2 - Timestamp changes

Hello Reader,
              Yesterday we went through detecting system clock changes on Windows 7, today we are going to talk about timestamp changing using two different utilities, timestomp and setmace.  Why two timestamp changing tools? They have two different approaches, timestomp and its variants use a Win32 API call to change timestamps that allow them to adjust STDINFO attribute timestamps but not FILENAME attribute timestamps within the MFT. setmace on the other hand can change both and its use is currently not detectable by comparing the STDINFO and FILENAME timestamps. Let's get into it. None of the information in this post is new but I hope to frame it in such a way that it is easy to understand and approach if you don't have a low level understanding of MFT operations.

Initially I was going to cover both tools in this post, but there are enough details and new gotchas between the two to justify taking the time to split this between two posts. Today we will cover timestomp running through meterpeter on a compromised xp host.

Timestomp

Timestomp and other timestamp modification programs that work like it make use of the win32 api to reset timestamps located in the STDINFO MFT attribute for a file. STDINFO contains the timestamps shown to you within explorer and most non forensic file utilities. This method of timestamp modification has a simple detection mechanism that has been a staple for IR and forensic investigators to detect.

Step 1. Grab the MFT from the file system
Step 2. Parse the MFT (I used our ANJP tool)
Step 3. Compare the STDINFO creation/modification and access times to the FILENAME creation/modification and access times.

If the times in step 3 do not equal you have a file with a possibly altered timestamp.

Step 4. Validate your assumptions and make sure the file wasn't distributed by a vendor with a bad timestamp.

Here is an example, we created a file called 'test.txt'. We then used timestomp to reset the timestamp of that file to 0 which in timestomp terms is 1601-01-01 and the STDINFO creation dates look as follows:

When you look at the FILENAME attribute of the same file you will find the original timestamps:

So the comparison here is pretty obvious, not only because without the possibility of time travel there is no computer file being created in 1601 (Oh man, Time travel forensics!) but also because this file named:

is user created and not part of a system package or other vendor delivered weirdness that you can find. In my testing I found a lot of 0 date FILENAME attribute files within the system32 directory which surprised me.

Let's not stop here though, let's talk about why these things exist. When a file is created in NTFS the first thing that is created is a File record. This file record maintains the basic header needed for NTFS to be able to reference and find the file. The second thing created is the STDINFO or standard information attribute which contains metadata about the file, MAC timestamps, etc..., but not the name of the file itself. Instead the name of the file and an additional set of timestamps is kept in a separate attribute called FILENAME.

The first FILENAME attribute will contain the 8.3 version of the files name (so called because it allows 8 characters in the name and 3 in the extension). If the file name is longer than 8 characters in the name or 3 in the extension then a second FILENAME attribute will be created that will store it and another set of timestamps. There can be even more FILENAME attributes but I haven't found any documentation yet that states all the possible mechanisms that generate additional ones. If you have please leave a comment and let me know.

Tomorrow we will show how setmace works and how using journal forensics we can overcome what is a very effective methods with some limitations on newer platforms.

Tweet

Daily Blog #128: Detecting Fraud Sunday Funday 10/27/13 Part 1 - Time Changes

Hello Reader,
           Let's talk about system clock changes which is one of the areas not covered by this weeks Sunday Funday winning answer. Often times when creating fraudulent documents a suspect will change the date of the system in order to make the document appear to be generated at an earlier time. If you've done these cases on Windows XP you've probably read Steve Bunting's old blog regarding this, http://www.stevebunting.org/udpd4n6/forensics/timechange.htm. However the event ids and sources have changed since XP and since this challenge focuses on Windows 7 I thought it would be useful to show what clock changes now look like.

Windows 7 has a lot more logging turned on by default, as such clock time change events are logged. The entry will be found in the 'Security' event log and the source will be 'Microsoft Windows security auditing'. The task category is 'Security State Change' and the Event ID is 4616. Here is an example:

You can see that the event records the previous and new times, in this case my clock was 9 minutes behind and I set it forward. If the clock were to be changed back you would see the new time be earlier than the previous time.

If you wanted to quickly determine if a user had changed the system clock recently this is the best place to quick filter for Event ID 4616. The security log for a workstation on my system goes back two months and there would be additional copies of it in the shadow copies and possible freesspace if you can recover event log entries from freespace.

So that is a pretty simple way to detect when the system clock for the entire system is changed, pretty easy huh? Tomorrow we will going into individual files timestamps being altered.

Tweet

Daily Blog #127: Sunday Funday 10/27/13 Winner!

Hello Reader,
                       Another Sunday Funday behind us and a another challenger who came with a great writeup full of testing and description. This weeks winner Andy Dove is now a two time Sunday Funday winner and brought some good testing this week. I plan to spend this week delving into the host based artifacts outside of Office that Andy didn't cover.

The Challenge:
An employee has been terminated after a lengthy workplace investigation. After being terminated the employee has come back with a lawyer stating that a word document on their work computer will exonerate them and that they are suing for discrimination.  The document appears to be a memo written by the employee's manager to the ex employee with derogatory language toward their race. The employee's manager has stated that they never wrote the document and they believe it be fraudlent.

If the employee was issued a Windows 7 system with Microsoft Word 2007 what would you do to determine:

• Which system the document with authored on
• Who was the author
• What was the last author
• If the time stamps have been altered

The Winning Answer:
Two Time Winner Andy Dove!

Nice to be back to Forensics for this week’s challenge.  My first port of call in this particular situation is to look at the Metadata embedded into each Office File.  This can be viewed quite simply using the Windows File Properties dialog.  Of particular interest in this particular case are the internal author and timestamp fields.  These internal timestamps are completely independent of the file system values and are not affected by utilities such as “Touch” which change MAC times.  To illustrate this I have done the following:

1. Created a file in Word 2007
2. Copied it onto a FAT32 formatted SD Card.
3. Copied onto a different user account.
4. Edited the file on the new account.
5. Edited the file again and changed the Author using MS Word.

After each step I have displayed the properties and taken screenshots.

Original File

Note that in this document the internal creation time precedes the file system time.  This is because the document was created within word, edited and then saved, rather than generating a new document from the Explorer right click menu.

Copied File (Unedited)

Here the file system times are again quite different to those held internally.  Had this process taken place over hours or days rather than minutes this difference would highlight the document had likely been copied over onto the machine.  Here the Author and Last Saved By fields also reflect the original values.  Possibly of note is also that the the NTFS Modified TimeStamp value has also changed due to having been stored on a FAT32 system where the timestamp is stored with less precision.

Copied and Edited

After editing the Last Saved by field has been updated to show a new user has worked on the document.

Author Changed

Here I have edited the author field to make it look more likely that it was created by the second user.

Where was the Document Created?

In MS Office 97 a GUID based on the MAC address of the computer which created the document is embedded within the file.  This is only added at creation time and is never changed on subsequent saves.  I have examined all the embedded XML files in my test document and have not been able to find a similar artefact within the Word 2007 files.  In this case I would revert to traditional forensic methods such as the examination of Jump Lists, Link Files, Prefetch Files and Volume Shadow Copy analysis to try and find evidence of the original file.

Interestingly the Windows file properties dialog isn’t your friend here.  Although it shows an entry for computer (See below) switching to another machine and then displaying the properties will show the new computer rather than the one on which the document was created.  The document shown below was created on a machine called PIGLET.

Examination on a non-Windows Machine

If examining the files on a non-windows machine it would be possible to view the embedded information by treating the file as a zip, unpacking it and opening the doc\Props\core.xml file.  In the case of my original document this clearly shows the same information as shown previously:

AndyAndy1 2013-10-27T14:56:00Z 2013-10-27T14:57:00Z

Tweet

Daily Blog #126: Sunday Funday 10/27/13

Hello Reader,
          It's Sunday Funday time again!Let's switch up these contests to something a little more internal investigation focused, these fraud cases are more common than you may think!

The Prize:

• A signed copy of the new book

The Rules:

1. You must post your answer before Monday 10/28/13 2AM CST (GMT -5)
2. The most complete answer wins
3. You are allowed to edit your answer after posting
4. If two answers are too similar for one to win, the one with the earlier posting time wins
5. Be specific and be thoughtful 
6. Anonymous entries are allowed, please email them to dcowen@g-cpartners.com
7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post

The Challenge:
An employee has been terminated after a lengthy workplace investigation. After being terminated the employee has come back with a lawyer stating that a word document on their work computer will exonerate them and that they are suing for discrimination.  The document appears to be a memo written by the employee's manager to the ex employee with derogatory language toward their race. The employee's manager has stated that they never wrote the document and they believe it be fraudlent.

If the employee was issued a Windows 7 system with Microsoft Word 2007 what would you do to determine:

• Which system the document with authored on
• Who was the author
• What was the last author
• If the time stamps have been altered

Tweet

Daily Blog #125: Saturday Reading 10/26/13

Hello Reader,
       It's Saturday! Time to rock out with your dongle out as we get down to some forensic goodness.

1. We had the third and final IR roundtable on the forensic lunch yesterday, watch it here http://www.youtube.com/watch?v=7UZnJ5m5aLc and make sure to tune in live next week 11/1/2013 at noon central.This week we covered the end of the IR lifecycle with remediation, how to communicate with teams during an IR and more.

2. If you use both Encase and IEF make sure to read this post on creating logical evidence files from the data recovered by IEF so it can be brought in directly, http://www.forensicfocus.com/News/article/sid=2108/.

3. Lance Mueller has a good post up listing out those tools he makes use of and establishing a hierarchy of tools in his arsenal, http://www.forensickb.com/2013/10/what-tier-2-tier-3-tools-do-you-load-on.html, its a good way to think about the tools you use and please comment on Lance's post if you use any additional tools.

4. I read the cyb3rcrim3 blog but only really include it here with it involves an interesting civil case, this week we have a winner http://cyb3rcrim3.blogspot.com/2013/10/the-contractor-login-and-computer.html. This case involves a dispute between a contract developer and his client and the rash steps he took when he didn't receive payment, namely locking his client out of the system he developed for them. This is a good read with many implications for those of you freelancing out there to remind you not to give in to that bad idea.

5. If you are doing IR and want to be able to search for possible exploits to known ports/errors within logs on systems you are triaging Corey has a new custom Google search for you called Vulnerability Search http://journeyintoir.blogspot.com/2013/10/re-introducing-vulnerability-search.html.

6. Lastly this week a short article from DFI News talking about ways to become a more credible witness, http://www.dfinews.com/articles/2013/10/gain-credibility-courtroom, I'll want to talk about this more next week :)

Stay tuned for another Sunday Funday tomorrow!

Tweet

Daily Blog #124: Forensic Lunch 10/25/13

Hello Reader,
              We had another great forensic lunch today, this time we finished out the IR roundtable series with James Lohman and Kyle Maxwell joining us to discuss the end of the IR lifecycle. From dealing with aggravated attackers, working with worried clients to best practices in remediation we got some great facts and opinions out there for you to consider. Please give it a watch and try to join us live next week when we return to digital forensics topics!

Tweet

Daily Blog #123: Svchost Persistance Question Answered

Hello Reader,
            After getting our stock XP VM license up and activated I did some testing today with the svchost key found here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost The purpose of my testing was to determine what would be required to enable persistence using the Service Host facility. This came about after this weeks Sunday Funday answer and Harlan Carvey's follow on question. After doing my testing this is what I can say.

1. The svchost key determines grouping for which services will run under which svchost process, but it does not attempt to call out to the path for any executable. Instead svchost is looking into the services key found in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services to find the information needed to find and execute the service. 

Result: Svchost on its own is not a persistence mechanism

2. You cannot create just a stub service in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services and expect it to run from svchost. The service must be correctly registered and seen by services in order for svchost to execute it. 

Result: Currently I do not see a way to half create an executable service that will not be listed in services, this requires more testing to find what the criteria is for a executable service.

3. You cannot append a ; to the ImagePath key and get a second command to execute, for instance I appended the following: ; %SystemRoot%\system32\test.bat to the ImagePath value for DHCP found in the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp\ImagePath which was only met with a service that failed to start.

Result: Currently I do not see a way to load a second program within a legitimate service stub, this also needs further test

So there you are, I am going to play with this a bit more and bad guys can still use the method Harlan Carvey documented on the secure works blog to hide as a legit service. Otherwise my testing just lead to execution failures and dead ends, which is good for the analyst! 

Did you find something different? Leave a comment or email me dcowen@g-cpartners.com

Tweet

Daily Blog #122: Question regarding Persistence via Svchost

Hello Reader,
              Harlan Carvey had a question from this weeks answer:

"I have a question about the description of the SvcHost key, particularly when compared to what's listed here:
http://support.microsoft.com/kb/314056

I'm not sure that the SvcHost is, in itself, a persistence mechanism, as without the service existing beneath the Services key, the entry is just a place holder."

The description in the winning entry for this key was:

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost

This registry key contains a list of processes that should be run as services under the svchost.exe program.  These will be automatically loaded by the operating system so this is a prime target for malware executables."

The description from the MSDN documentation states:

"The Svchost.exe file is located in the %SystemRoot%\System32 folder. At startup, Svchost.exe checks the services part of the registry to construct a list of services that it must load. Multiple instances of Svchost.exe can run at the same time. Each Svchost.exe session can contain a grouping of services. Therefore, separate services can run, depending on how and where Svchost.exe is started. This grouping of services allows for better control and easier debugging.

Svchost.exe groups are identified in the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Svchost

Each value under this key represents a separate Svchost group and appears as a separate instance when you are viewing active processes. Each value is a REG_MULTI_SZ value and contains the services that run under that Svchost group. Each Svchost group can contain one or more service names that are extracted from the following registry key, whose Parameters key contains a ServiceDLL value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Service"

From looking at the key within my system it would appear as though the service is added to a group that is tored as a  keyvalue under svchost. What I don't know and what I want to test is can you add an item to the grouping list without also defining it as a service separately or will it execute whatever is named that in the local path.  I will test this and let you know tomorrow!

Tweet

Daily Blog #121: Sunday Funday 10/20/13 Winner!

Hello Reader,
           It was very much worth extending the contest for another day, I received several good submissions this time and the anonymous winner below was the best of those. 
         
The Challenge:
List and explain all of the methods of persistence for malware available in Windows 7 that is written to the file system/registry.

The Winning Answer:
Anonymous

The goal of many malware programs is to remain on an infected host and run silently in the background without intervention from outside sources. In order to do this the malware installs configuration settings in the following areas of the Windows operating system:

The Registry

The registry is used to store system wide configuration information and the operating system will use it as a guide to run various system services and drivers. The registry is consulted at start up by the boot loader who will use the values it finds in various keys to load a range of services and executables.  The following keys are often used by malware to achieve persistence:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\TerminalServer\Install\Software\Microsoft\Windows\CurrentVersion\Run

These keys contain a list of programs that will execute automatically when a user logs.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

This key can contain a value named “AppInit_DLLs” which stores a list of dlls or Dynamic link libraries that will be automatically loaded with any process that runs in the user context.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost

This registry key contains a list of processes that should be run as services under the svchost.exe program.  These will be automatically loaded by the operating system so this is a prime target for malware executables.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services

This key is often used by malware to ensure that it is executed when the system starts. It contains a list of drivers and services that will be executed by the boot loader. Values under this key contain a start field which can have the following settings:

0x0 To be started by the boot loader

0x1 To be loaded by the kernel

0x2 To be started automatically by the Service Control Manager

0x3 To be started by the user

0x4 Disabled

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Start Menu

The start-up menu location is contained in this key and some malware has been known to change this value to point to a new malware defined location. This results in the contents of the new location being executed.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Shell

Values under this registry key will be loaded as the shell and by changing this value the malware can ensure that it is executed automatically.

--------------------------------------------------------------------------------------------------------------------------------------

Some registry entries can be altered to ensure the malware remains hidden from view as follows:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced   

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\HideFileExt   

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\Hidden\SHOWALL HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Folder\SuperHidden\UncheckedValue

These keys are set so that a user cannot select to view hidden files in “organise\folder and search options\ view\” and therefore suspicious malware files are hidden.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\OpenOffice.Doc(any file type)\Default

This value can be changed to associate the file type with a malware executable which will be executed every time the specific file type is run. The values of several of these keys can be changed to ensure the malware is executed.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_CLASSES_ROOT\Shell\shell\explore\command

This key associates a handler for certain file types and malware can add itself which ensures that it is executed each time the particular file is executed.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mobi (or any file type\OpenWithList

Malware can alter values in these keys to associate as the executable that should open files with the specific extentions eg txt or doc.  The malware is therefore executed whenever the file is opened.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_CURRENT_USER\Software\Mirabilis\ICQ\Agent\Apps\test

This registry key is used by Mirabilis ICQ chat and any programs stored as values in this key will be executed when the Mirabilis program detects an Internet connection. Therefore any malware values stored here will be executed.

--------------------------------------------------------------------------------------------------------------------------------------

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

Any values stored in this key will be executed when a user logs-in and therefore can provide persistence for malware.

--------------------------------------------------------------------------------------------------------------------------------------

Thanks for sharing anonymous! Good listing with good descriptions, a worthy winner!

Tweet

Daily Blog #120: Sunday Funday 10/20/13... Winner?

Hello Reader,
            This Sunday Funday saw ... no submissions. Here was the challenge:

The Challenge:
List and explain all of the methods of persistence for malware available in Windows 7 that is written to the file system/registry.

I was a little surprised as I didn't think the question was that difficult but maybe all of you didn't have time to respond. With that in mind I'm going to give you another 24 hours and try to give this a bit more visibility to respond and win before I post the answers tomorrow.

Good luck Reader!

Tweet

Daily Blog #119: Sunday Funday 10/20/13

Hello Reader,
          It's Sunday Funday time again! Last week you worked against a Linux challenge that proved to be quite difficult. This week let's switch it to a Windows IR based challenge that should be more accessible to more of you.

The Prize:

• A signed copy of the new book

The Rules:

1. You must post your answer before Monday 10/21/13 2AM CST (GMT -5)
2. The most complete answer wins
3. You are allowed to edit your answer after posting
4. If two answers are too similar for one to win, the one with the earlier posting time wins
5. Be specific and be thoughtful 
6. Anonymous entries are allowed, please email them to dcowen@g-cpartners.com
7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post

The Challenge:
List and explain all of the methods of persistence for malware available in Windows 7 that is written to the file system/registry.

Good luck! This may seem like a simple copy and paste job at first, but the winner will be the one who can explain the persistence mechanisms best.

Tweet

Daily Blog #118 Saturday Reading 10/19/13

Hello Reader,
       It's Saturday and time for another set of links to to make you think. I am actually writing this on Friday this week so there may be some links that won't make it until next week.

1. This week we had a bit of a last minute forensic lunch, so its just Matthew and I this week. We talked about perl development, tsk for perl, developing a research and testing plan and more: http://www.youtube.com/watch?v=pSU4LI54ZtY

2. Didier Stevens has released another updated tool, http://blog.didierstevens.com/2013/10/14/update-xorsearch-version-1-9-1/, that searches a file or binary for known dictionaries for 32bit and brute force for less. Why is this useful outside of malware reversing? Think of how many artifacts we found that end up being xor encoded, using a known word of a website, document, etc.. you can then search strange files looking to see if they are xor encoded for privacy and storing history.

3. Looking to make forensic test images but don't have the time to do it manualy? There is a great article over on forensic focus, http://articles.forensicfocus.com/2013/10/18/forge-computer-forensic-test-image-generator/, detailing a new tool called ForGe developed by Hannu Visti that automates the creation of forensic test images. The tool isn't perfect, yet, as it really is meant to manipulate single files around a forensic image but it can certainly create some interesting scenarios and provide some great challenges. I'll have to try it one Sunday!

4. Lance Mueller has put up a really cool Enscript to take the hashes created within Encase and look them up on virustotal creating a bookmark for those that return a score http://www.forensickb.com/2013/10/vtbookmark.html This could help many of you when trying to quickly triage a system for known malware but without having to work with extracted data and risking infection.

5. There is a great webinar scheduled for Oct 24th by Alissa Torres on the SANS site with an introduction to the different tools that are in use in the industry for creating dumps of physical memory, https://www.sans.org/webcasts/dumping-dark-gaining-insight-memory-acquisition-tools-techniques-97260, SANS is no longer requiring Java so not many reasons not to give it a watch.

6. Want to have a more portable version of WinFE, check out this nice video tutorial on Mini-WinFe https://www.youtube.com/watch?feature=player_embedded&v=IJ3OBTysVbI

Thanks for stopping by, make sure to come back for tomorrow's Sunday Funday!

Tweet

Daily Blog #117: Forensic Lunch 10/18/13

Hello Reader,
   Pretty hectic travel schedule this week with my little ones so no real time to organize a proper forensic lunch. Instead Matthew and I did a last minute lunch to discuss our research, tools we are using in development, creating a testing plan and opportunities in forensics.

I hope you enjoy it and tune in again next week for a full forensic lunch!

Tweet