-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract timeline info from RegRipper TLN plugins #1318
Comments
I'm sorry, but I'm not seeing an issue here. Can you help me understand what it is that constitutes an issue? Thanks! |
Hi @keydet89. This is not an actual issue, but an enhancement request into IPED tool, not into RegRipper. |
What is "IPED"? |
You can find it into this project Readme.md. Let me know if something is not clear enough. |
I would like some opinions:
|
Patrick, I'll be 100% honest with you...I have no idea what you're asking. "-aT gerenates the report in a different format." It creates output in a different format, yes...TLN output. That's the point. "-Use the "-aT" output to extract the timestamps only, not adding it?" I'm not sure what this is saying or asking here. "Running the "-aT" in full_report and in the profiles..." What profiles? The point of using "-aT" is so that you don't have to use profiles. Can you elaborate on this? |
Another opinion is how could I describe the timeEvent? The output is too heterogenoues, depending on pluggin. Exs: For winlogon_tln pluggin: |
I think that I will put as timeEvent the name of the plugging executed that produced the entry, prefixed with "WinReg:". |
Okay, thanks. "The output is too heterogenoues,..." This is intentional. Not all time stamps reported are key LastWrite times, and as such, the context is heterogenous, so the output must be, as well. |
|
Hi Carvey, It seems that you are the main developer of RegRipper. This thread is about IPED, a tool that uses the output of many tools like regripper. |
About the timeEvent property, ideally it should come from the event description, but the absence of a clear pattern could make it difficult... Not sure if using the plugin name would be good/informative enough to the user... Wireless Connect (or Last Connected to), Task Registration, Task Last Run, Task Completed seems good timeEvent values (we can remove the spaces). The full event description can be added to another property. What about taking everything before the hyphen in the event description and using it as timeEvent value at first, run it on some dozens or hundreds of registry files and try to improve based on the results shown in the Metadata filter tab? Storing the full description String in another property can help the results analysis. |
patrickdalla, What is "IPED"? Is there a link? |
Carvey, this thread is inside IPED github page. I don't know how you are following this thread. If you are receiving this from github, there should be a link to the thread at the end of the email. If not, this is the link: https://github.com/sepinf-inc/IPED |
Well, a version was pushed in RegRipperTLN branch. It uses the before "-" in description approach to name the timeEvent title, and the field. For the field I removed some incompatible characters. Some RegRipper plugins that extracts important timestamps don't have their TLN counterpart. Examples:
These are the one's I've noted. But it seems there is more. |
So, should I try to parse these dates not parsed by TLN pluggins? |
That's bad news...
If it's easy and if there are relevant dates, that would be great! |
It is reasonably easy to find timestamps in normal plugins reports as they are formated as ISO 8601, or as perl gmtime result (Ex.:"Thu Oct 13 04:54:34 1994"). It is not easy, though, to associate these dates with the better name to identify the correspondent timeEvent, as these names are not standarized. For some dates, the preceding string is good enough like ShutDownTime. For AppCompatCache entries, though, the dates are preceded by the file path of the respective cached executable "shim". The AppCompatCache term can be found at the top of the list. We can make code to treat some exceptions, but as the output are not standarized, the parse will be coupled with specific regripper plugin version. |
Yes, that's the challenge. I expected -aT switch would return all timestamps and events in a standard output format... |
"I expected -aT switch would return all timestamps and events in a standard output format..." Such as? What would that format look like? The version of RegRipper you're referring to hasn't been updated in almost 3 yrs, due in part to almost no feedback from the community. |
"Some RegRipper plugins that extracts important timestamps don't have their TLN counterpart." Such as? Do you have examples? "So, should I try to parse these dates not parsed by TLN pluggins?" If you have examples, perhaps I can assist. If that's what you want. |
Hi. I think I could make a parse that was enough, at least for my test case. Timestamps are extracted directly from normal plugins output (full). I need more test cases to validate the parse. |
There are some dates formatted as ISO 8601 that in reality corresponds to just the time info without the date, so the date part remains 1970-01-01 without the date information. Should I ignore them as timestamp entries or include them? |
For now I think it is better to ignore them. But what plugin is generating them? Maybe that could be an issue and it would be better to check/report it to regripper project. |
I can provide samples to you when I return back to work.
WinReg:nic2:T1, WinReg:nic2:T2 seems not intuitive, what do they mean? Even appcompatcache and shimcache may not be clear for beginners, I think the executed program name should be put in another metadata in the first case, at least. Not sure, but -aT output seems more descriptive to me at a first sight... |
Hi @keydet89, thank you very much for your comments. I'm just saying my expectation about -aT is that it would output ALL parsed timestamps by regripper plugins. But @patrickdalla said some parsed timestamps present in the default output format are not present in -aT output. He provided examples above in this thread. |
Researching I found that T1 and T2 are in fact not timestamps, but a delay, a time lapse. I think they can be let out. So, I made a rule to let out all dates that starts with 1970-01-01 00:00:00, I can change this, and let out all dates from year 1970, as they probably are representation of time lapses, or, if not, some misinformation as I think in 1970 there were no window registry format :-). |
About the description: I've made a parse of RegRipper output, so, little detailed info from there won't be complemented, and improvement should also be asked in RegRipper. The parser only read info from RegRipper output, and I think that any other more detailed info should be asked from RegRipper also. At least, that was what I thought was the only purpose of this implementation. The parser puts as the "title" and "timeEvent" of the item any preceding terms in the same line of the timestamp. As the content of the item, the entire line is put. For some output, as appcache and shimcache, the preceding terms are paths to files, so they would generate to much distinct timeEvents, one for every file, and for these plugins I omitted this on title or timeEvent fields (they are included in item content). |
AFAIK, the TLN pluggin counterpart is a pl script file with the same script file name suffixed with "_tln". If I am right, there are 258 script files without their TLN counterpart. I don't know how many of them parses timestamp key values. |
"AFAIK, the TLN pluggin counterpart is a pl script file with the same script file name suffixed with "_tln". If I am right, there are 258 script files without their TLN counterpart." The assumption that there is a one-to-one correlation between regular plugins and "_tln.pl" plugins is incorrect. That simply does not make sense. Take the Run key, for example. The only time stamp available is the Run key LastWrite time value. Individual values beneath the key do not have associated time stamps. Keys that contain MRU listings are different, clearly. Keys such as the UserAssist subkeys, which have values whose data includes a time stamp, are different, as well. These can be included in a timeline, which is why they have "_tln.pl" plugins. Keys such as the Run key are covered for inclusion in a timeline by regtime.exe. " I don't know how many of them parses timestamp key values." I'm sorry, but I have no idea what "timestamp key values" is meant to refer to... |
As you have said, every key has at least a "LastWrite" time value. Maybe this can be considered forensically irrelevant, and for this reason there is no TLN counterpart plugin and no one-to-one relation. As I've said before, for the case I am evaluating these are some dates that I could not find the correpondent entry in the "-aT" TLN output: |
@patrickdalla, how many timestamps you got with your last approach (parsing default regripper output) and with the first approach (parsing -aT output)? |
Also, for networklist.pl there is a networklist_tln.pl counterpart, but the TLN script could not parse the dates of network entry creation and network last connection, although the networklist.pl presents these dates. |
"Maybe this can be considered forensically irrelevant..." It's not about being "forensically irrelevant". "...for the case I am evaluating these are some dates that I could not find the correpondent entry..." From the point when RegRipper was originally released in 2008, it was intended to be a community-based project. This means that if you see something that's "missing", or find something that you would like added to it, you can either do so yourself and add it back to the project, or ask for assistance in getting it added. You're looking at what's publicly available. No one has asked for anything to be updated in almost 3 yrs...and that's just based on the time stamps in Github; in reality, it's been longer than that. During this time, I've been continually and regularly updating RegRipper v4.0. So, if you're evaluating the tool and see that need for something to be added, do so, or ask for help in doing so. |
There were 304 additional timestamps not found in TLN "-aT" output. |
And the totals? |
Right, no problem. This thread is about IPED. And we are trying to parse the maximum we can from RegRipper current used release output. |
2315 total timestamps extracted from normal plugins output, and 2011 from TLN output. |
"Then why not seek or develop a means for getting more from RegRipper?" Yes, sure. Any improvement would be great. IPED is a tool to parse and present info from many sources and formats. We are trusting on RegRipper as good tool as a source of registry info. Personally I don't know perl to help efficiently. |
Hi @keydet89, thanks for your insights here. I totally agree that if something is missing or if some issue is found in RegRipper, that should be fixed into RegRipper.
Is RegRipper-4.0 open source and available publicly somewhere? |
Thanks. Have you checked the opposite, if all TLN time stamps were got by the new approach? And do you think the descriptions of the new approach are better than those got parsing TLN output? Actually I'm not too concerned about getting as much timestamps as we can, but about providing meaningful timestamp information to the user. |
"Have you checked the opposite" - yes, they were all parsed (my case) in the normal report parsing approach. "do you think the descriptions of the new approach are better than those got parsing TLN output?" - I didn't analyse all TLN pluggins output, as my test cases is small. But the description was similar. "Actually I'm not too concerned about getting as much timestamps as we can, but about providing meaningful timestamp information to the user." - providing meaningful timestamp information for these entries should require some "library" with these details, as there are many different timestamps context. I think it would be better to search for these details on other sources/internet. Certainly the best option would be a well formatted output with all these dates. |
The date info itself could be not too detailed, but once easily found, the analyst can detail it by searching other artifacts. |
Hi @lfcnassif , 1 - Parsing timestamps from standard RegRipper reports resulted in 640.552 items. From TLN resulted in 352.745. These were the parsed timeEvents from standard RegRipper (some little few strage descriptions remain): For the timeEvents padronization from TLN reports, lot of work remains. |
|
I finished a good enough PR, please test it. I have reported RegRipper-3. As soon as they improve and fulfill our necessity we can adapt it. |
As pointed by #331 (comment) we can use the new
-aT
RegRipper-3.0 option to run plugins which have a timeline output. We can parse that output and populate IPED's timeline.The text was updated successfully, but these errors were encountered: