±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35742
New Yesterday: 3 Visitors: 131

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

Registry timestamps manipulation

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page 1, 2  Next 
  

joakims
Senior Member
 

Registry timestamps manipulation

Post Posted: Aug 20, 12 02:48

Just a quick note about registry timestamps. Maybe informative, maybe not. Anyways, based on the material I've read so far, there seems to be something missing.

When it comes to timestamps in the registry, I have the impression that either of these points prevail when it comes to analysis:

a) Completely neglect to mention the fact that it may be possible to deal with a modified registry timestamp. Usually filesystem timestamp manipulation is mentioned.

and/or

b) States that it is not possible to modify these timestamps, at least not without using a hex editor in offline mode.

I therefore created a PoC, SetRegTime, to show how easy it actually is, and that is certainly should not be forgotten as a possible issue; code.google.com/p/mft2...SetRegTime

Again, maybe informative, maybe not..
_________________
Joakim Schicht

github.com/jschicht 
 
  

joachimm
Senior Member
 

Re: Registry timestamps manipulation

Post Posted: Aug 20, 12 11:42

I would not say the timestamp conversion issue is limited to registry tools only.
I assume since it should be core knowledge to most investigators (analog and digital) that timestamps can be tampered with, they are often not explicitly discussed.

In your article you only talk about one tool, but you claim "result in most forensic utilities displaying blank timestamps".
Please add the proof to back-up this statement.

Some other issues commonly with dealing with registry files.
www.forensicswiki.org/...s_Registry

Also for the sake of the article, be more transparent which function calls you used and specify what you think is "the range for unix" timestamps. Since there are multiple variants: en.wikipedia.org/wiki/Unix_time. (Signed, unsigned, 32 or 64-bit.)  
 
  

keydet89
Senior Member
 

Re: Registry timestamps manipulation

Post Posted: Aug 20, 12 16:49

Joakims,

First off, I would suggest that your thesis statement for your post oversimplifies the issue.

What I mean by that is that I and others have commented time and time again this particular issue. In fact, my statements have been along the lines of not being aware of a particular public API (from MS) that allows for this. This does not say that it is impossible, nor does it suggest that it doesn't happen/occur.

Time stamp manipulation of Registry keys is, in fact, well known. For example, someone can perform actions that have an affect on a particular Registry key, such as a value being added, causing the LastWrite time of the key to be updated automatically by the operating system or an application. Someone could then later use another means to modify the key in some other way...create and then delete a value, modify an existing value, etc. These actions would cause the key LastWrite time to be updated, albeit not to an arbitrary value and not post-dated.

I applaud your effort in identifying the particular APIs for manipulating key LastWrite times to arbitrary values. I would suggest that in doing so, you've accomplished several tasks all at once:
1. Identified the API and increased the possibility (albeit not the likelihood) of this occurring.
2. Illustrated the need for an overall analysis process.
3. Illustrated the need for a greater understanding of the Registry as an investigative resource.
4. Illustrated more than ever the need for timeline analysis.

Thank you.  
 
  

jaclaz
Senior Member
 

Re: Registry timestamps manipulation

Post Posted: Aug 21, 12 00:18

- joakims


I therefore created a PoC, SetRegTime, to show how easy it actually is, and that is certainly should not be forgotten as a possible issue; code.google.com/p/mft2...SetRegTime

Again, maybe informative, maybe not..


Nice idea! Smile

And, maybe OT or maybe not Wink , I personally still see the Registry as a filesystem (basically because IMHO it is a filesystem) so I find it normal that dates/times can be changed in a similar way as you can do on filesystems:
reboot.pro/7681/
(though I still seem like being the only one - set apart from the Author and possibly another few peeps around - believing in this approach).

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

athulin
Senior Member
 

Re: Registry timestamps manipulation

Post Posted: Aug 21, 12 12:36

- joakims
Again, maybe informative, maybe not..


More an indication, perhaps, that the field of CF needs to cover both basic science as well as applied science -- just as any other forensic field. The 'applied science' is the most visible CF focus, but without the 'basic science' foundation it may rather hang in the air.

It's also a useful reminder that the history of operating systems is important: the Nt... routines that you use were more obvious in the early days of Windows NT: today, .NET and similar frameworks have been built on top of them, and they are increasingly lost to view. Yet, they are still there, and we need to be reminded of that from time to time.

Those coming from software development may have encountered books such as 'Undocumented Windows', 'Windows 95 Programming Secrets', 'Undocumented Windows NT', 'Undocumented Windows 2000 Secrets', 'Windows NT/2000 Native API Reference' etc. that were rather popular in the late '90s. They're often targeted to areas that software developers found important, but there is also material directly relevant for CF-related problems.  
 
  

joakims
Senior Member
 

Re: Registry timestamps manipulation

Post Posted: Aug 22, 12 01:16

Hi again.

@joachimm
Maybe the main point (from my side) was not raised clearly enough. It was not that certain tools that decode registry hives, would display blanks when in fact there was an un-nantural timestamp. Those blanks come from specific implementations of timestamp handling, are just affected when timestamp are way off, but I don't have a list off all these nor do I have an interest in pointing out any code error/issue with them. Either way, if such a timestamp is found (lets say 1784 or 2269), it's so far off that anyone would raise an eyebrow and take a second look, regardless of a blank decoded timestamp or a correctly decoded timestamp. My main point was that we only have 1 timestamp tied to each registry key, and if that one is modified then for sure you would need to look elsewhere to find something to compare against, other registry keys, timeline analysis, or whatever. It therefore makes no sense to me to post testresults from many different decoding tools. That can others do if they want.

@keydet89
Although I've seen comments by you on the topic, it was not directed at anyone in particular. As I said, I got the impression that usually when the topic of timestamp manipulation is discussed, it has been about filesystem and very rarely about registry. But as I also said, "maybe not informative", because I certainly have not read the amount of material that you and others here have.. Thanks for pointing out in nice words the ever growing need for proper timeline analysis.

@jaclaz
I could not find the source for it anymore. Do you still have it, and are willing to share?

@athulin
I too, although a bit late compared to late 90s, find it interesting to investigate their (the native functions) possibilities. They are a powerfull set of functions!! (maybe not surpising as they are kernel mode ready, the Zw.. counterparts).
_________________
Joakim Schicht

github.com/jschicht 
 
  

athulin
Senior Member
 

Re: Registry timestamps manipulation

Post Posted: Aug 22, 12 11:36

- joachimm
In your article you only talk about one tool, but you claim "result in most forensic utilities displaying blank timestamps".
Please add the proof to back-up this statement.


As a side note, I would have though that the need for that would not be particularly big -- I expected just about any forensic analyst to have seen these.

There is nothing in Microsoft documentation to suggest that any part of the 64-bit range of a FILETIME would be invalid. Trying to check it by calling FileTimeToSystemTime() on the offending timestamps mentioned below does not produce any error results.

Some Windows system calls treat FILETIME values 0 and ~0 (C convention) apart: 0 means 'do not change the current file time stamp in this one call', and ~0 means (I think) 'prevent future calls on this file handle from altering this value', though the MS documentation is particularly unclear on the last one (see SetFileTime()).

As for tools ...

Take DCode. Enter the values 0 or 1, and it decodes to 'Not A Valid Date!'.

Or, take EnCase, sweep an appropriate area in a test file and bookmark as 'Windows Date/Time'. You'll get 'Invalid' in return. (Tested with 00 00 00 00 00 00 00 00, 01 00 00 00 00 00 00 00 and 25 25 25 25 25 25 25 25). (If I recall, the Table View will show file time stamps with these values as empty fields.)

FTK imager gets these things right, though -- as far as I have tested it.

(Several special tools also fail these, but they as they typically require specially tooled test files, I'm leaving them aside for the moment.)

In each failed case there *might' be some kind of policy at work in each particular tool: if the date is to far from the present time, treat it as invalid. If there is such a policy, it is not as far as I know documented. That's reason enough to label this as a bug.

For the ranges where these tools *do* return a date/time, I have not found any reason to suspect an error -- though I think it may be time to do some hostile testing.

(Added: it would perhaps be worthwile to take each type of timestamp, really dig into the basics, and develop a number of *good* test values for tool testing purposes: extreme ranges, leap days, and perhaps leap seconds if the time system has them, values that might cause overflow or loss of precision in poor implementations, etc. Some of this could probably be based on fixed bugs in open software source code.)  
 

Page 1 of 2
Page 1, 2  Next