Join Us!

Registry timestamps...
 
Notifications
Clear all

Registry timestamps manipulation  

  RSS
joakims
(@joakims)
Active Member

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; http//code.google.com/p/mft2csv/wiki/SetRegTime

Again, maybe informative, maybe not..

Quote
Posted : 20/08/2012 3:48 am
joachimm
(@joachimm)
Active Member

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.
http//www.forensicswiki.org/wiki/Windows_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 http//en.wikipedia.org/wiki/Unix_time. (Signed, unsigned, 32 or 64-bit.)

ReplyQuote
Posted : 20/08/2012 12:42 pm
keydet89
(@keydet89)
Community Legend

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.

ReplyQuote
Posted : 20/08/2012 5:49 pm
jaclaz
(@jaclaz)
Community Legend

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; http//code.google.com/p/mft2csv/wiki/SetRegTime

Again, maybe informative, maybe not..

Nice idea! )

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
http//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

ReplyQuote
Posted : 21/08/2012 1:18 am
athulin
(@athulin)
Community Legend

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.

ReplyQuote
Posted : 21/08/2012 1:36 pm
joakims
(@joakims)
Active Member

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).

ReplyQuote
Posted : 22/08/2012 2:16 am
athulin
(@athulin)
Community Legend

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.)

ReplyQuote
Posted : 22/08/2012 12:36 pm
jaclaz
(@jaclaz)
Community Legend

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

Sure ) .

Here you are
http//www2.zshare.ma/gbxayyxla7we

this is the whole package as it was on the original site, related pages (but not the above archive) is on the Wayback Machine allright
http//web.archive.org/web/20090413131629/http//czwsoft.dyndns.org/regfs.html
http//web.archive.org/web/20090413154006/http//czwsoft.dyndns.org/regfs_imp.html

While you are at it, maybe this could also be of use (OT)
http//web.archive.org/web/20071126044832/http//czwsoft.dyndns.org/sdedit_doc/introduction.html
http//web.archive.org/web/20071202013457/http//czwsoft.dyndns.org/sdedit_doc/usage.html

This latter tool is available through Softpedia
http//www.softpedia.com/get/Security/Security-Related/SD-Edit.shtml

And Chris Smith has a new page on google code
http//code.google.com/p/ulimitnt/
I presume you can contact him through the above, from the post on boot-land, he seems like a very nice guy and it is possible that he has done something in the meantime and hasn't released it yet….

The page by Carlo Pasolini is still online
http//pasotech.altervista.org/articoli/regfs.htm
and (though in Italian) contains several useful pics and hints on how to compile (should you need this kind of info).

jaclaz

ReplyQuote
Posted : 22/08/2012 1:43 pm
joachimm
(@joachimm)
Active Member

Maybe the main point (from my side) was not raised clearly enough.

Yes not raised clearly enough. No need to do a cross comparison of the tools, but please adjust your wording in the article.
Now they are very suggestive and make claims without any proof to back it up.

ReplyQuote
Posted : 22/08/2012 4:32 pm
joakims
(@joakims)
Active Member

OK then, text adjusted to clearly state the main point, while also making a note at the end of why "strange" decode may be observed using certain tools (also stating that this particular "issue" has nothing to do with the point being raised). )

ReplyQuote
Posted : 23/08/2012 2:05 am
joachimm
(@joachimm)
Active Member

Much better, thanks.

FYI, the "issue" as you refer to it are actually multiple

The FILETIME values are sometimes overloaded with special value, as athulin points out 0 and ~0, but also -1 and 0x2a2a2a2a2a2a2a2a have been seen in e.g. PST, ESEDB. Overloaded values are likely to be context specific.

Some tools do truncate the FILETIME to a 32-bit signed POSIX timestamp, and then use the system functions to represent the time. This not often looses the date and times before and after the Unix epoch (1970), although if done correctly dates before 1970 can be represented using negative POSIX timestamps, nonetheless there still is a cutt-off point and ranges are lost.

The conversion also looses precision, because FILETIME is in 100th nano seconds and POSIX timestamp is in seconds (although variations exists that use micro seconds). The fallacy of these tools is that it is the precision can be useful to detect "artificial" created times, which if the API allows for less of a precision than timestamps generated by the system.

ReplyQuote
Posted : 23/08/2012 11:42 am
keydet89
(@keydet89)
Community Legend

The fallacy of these tools is that it is the precision can be useful to detect "artificial" created times, which if the API allows for less of a precision than timestamps generated by the system.

I wrote an MFT parser in Perl and incorporated a check for precision in the FILETIME time stamps, as a means of detecting this issue.

However, in my experience, there's been a move away from the use of such tools and toward the use of GetFileTime()/SetFileTime()…get the times from kernel32.dll and use those to replace the times on the file(s) you're trying to obfuscate.

ReplyQuote
Posted : 23/08/2012 7:13 pm
joachimm
(@joachimm)
Active Member

keydet89, sure the precision by itself is not sufficient to rule-out time manipulation, but it can help in identifying it.

ReplyQuote
Posted : 23/08/2012 10:52 pm
Audio
(@audio)
Active Member

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.

I'm a rookie so maybe I don't understand, but shouldn't those 4 reasons for applauding Joakim apply to other anti-forensic techniques? For example, normal file timestamp modification that has been going on for years… I'm not sure why investigators need to be continually reminded to fix the same problems in our analysis process. I mean if someone hasn't learned those things from anti-forensics so far, are they really going to learn this time?

ReplyQuote
Posted : 25/08/2012 4:43 am
Share: