IPED
IPED copied to clipboard
sepinf-inc
Extract timeline info from RegRipper TLN plugins
As pointed by https://github.com/sepinf-inc/IPED/issues/331#issuecomment-1247230262 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.
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:
-
-aT gerenates the report in a different format. Should we: -replace the current report format? -Add the report as a new subitem? -Use the "-aT" output to extract the timestamps only, not adding it?
-
Running the "-aT" in full_report and in the profiles can add the same timestamp twice. Should we run the "-aT" in fullreport only, or only for each profile?
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. Only the date is in a common format, in the start of the line. Other information from where we could infer the timeEvent is placed on the description, the way the plugin developer chose.
Exs: For AppCompatCache: 1523489668|REG|||M... AppCompatCache - C:\Windows\system32\odbcad32.exe 1523489687|REG|||M... AppCompatCache - C:\Windows\SysWOW64\chcp.com 1523489699|REG|||M... AppCompatCache - C:\Windows\SysWOW64\prevhost.exe 1541727458|REG|||M... AppCompatCache - C:\Program Files\rempl\sedlauncher.exe 1532953101|REG|||M... AppCompatCache - C:\Program Files\WindowsApps\Microsoft.Windows.Photos_2018.18051.18420.0_x64__8wekyb3d8bbwe\Application
For winlogon_tln pluggin: |REG|||[GPO Hist] Horario_Verao_Desabilitado - \PROX.GRUPO\sysvol\PROX.GRUPO\Policies{AF2E6E0D-10B4-49BC-A440-F362AC3D3F5F}\Machine (Linked to an OU) |REG|||[wireless Connect] - Last Connected to DIRECT-GUPC-28QSYB (-----) |REG|||[wireless Connect] - Last Connected to VIVO-E98C (34-57-60-0E-E9-8C) |REG|||Adobe Acrobat Update Task key LastWrite time 1537462666|REG|||Task Registration - Adobe Acrobat Update Task 1543861940|REG|||Task Last Run - Adobe Acrobat Update Task 1543861940|REG|||Task Completed - Adobe Acrobat Update Task |REG|||autopico daily restart key LastWrite time 1543492317|REG|||Task Registration - autopico daily restart 1543848619|REG|||Task Last Run - autopico daily restart |REG|||GoogleUpdateTaskMachineCore key LastWrite time 1527855018|REG|||Task Registration - GoogleUpdateTaskMachineCore 1543839318|REG|||Task Last Run - GoogleUpdateTaskMachineCore 1543839319|REG|||Task Completed - GoogleUpdateTaskMachineCore |REG|||GoogleUpdateTaskMachineUA key LastWrite time 1527855018|REG|||Task Registration - GoogleUpdateTaskMachineUA 1543873729|REG|||Task Last Run - GoogleUpdateTaskMachineUA 1543873729|REG|||Task Completed - GoogleUpdateTaskMachineUA |REG|||OneDrive Standalone Update Task v2 key LastWrite time 1527854105|REG|||Task Registration - OneDrive Standalone Update Task v2 |REG|||OneDrive Standalone Update Task-S-1-5-21-246674189-1450962176-99410399-1142 key LastWrite time 1543494605|REG|||Task Registration - OneDrive Standalone Update Task-S-1-5-21-246674189-1450962176-99410399-1142 1543856037|REG|||Task Last Run - OneDrive Standalone Update Task-S-1-5-21-246674189-1450962176-99410399-1142
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.
- I think -aT should be used just to generate regripper timeline reports temporarily and they should be broken into timestamp subitems of current reports, each subitem referring to one timestamp.
- I think -aT should be executed just for the full reports
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.
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:
- Network DateLastConnected, DateCreated (wireless)
- DHCP leate obtain and termination times
- Storage (USB included) FirstInstallDate, LastRemoval, LastArrival
- Computer shutdown time
These are the one's I've noted. But it seems there is more.
Some RegRipper plugins that extracts important timestamps don't have their TLN counterpart.
That's bad news...
So, should I try to parse these dates not parsed by TLN pluggins?
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.
It is not easy, though, to associate these dates with the better name to identify the correspondent timeEvent, as these names are not standarized.
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). The name of the field follows the pattern "WinReg:[pluginname]:[fieldName]" where fieldName is the term before the date in the same line.
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?
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 need more test cases to validate the parse.
I can provide samples to you when I return back to work.
"WinReg:[pluginname]:[fieldName]"
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...
Such as?
What would that format look like?
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 :-). https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978471(v=technet.10)?redirectedfrom=MSDN
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. For appcompatcache, for example, the only description that exists is "(System) Parse files from System hive AppCompatCache", even in TLN output. Shimcache is, actually, the same appcompatcache info parsed with a different name. They are generated because there are "duplicate" plugins, one that exports using the name appcompatcache, and the other shimcache.
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.
I also created a category specific for these extracted timestamp entries: