Extend the NTUSER.dat/UsrClass.dat FileMasks for RegistryHivesUser.tkape #974
Replies: 3 comments
-
Sure, I don't see why not. That makes a lot of sense! Did you want to do a PR, or me? Sidenote, do we know how often Velociraptor updates the targets it uses? |
Beta Was this translation helpful? Give feedback.
-
I can work on the PR tonight/tomorrow yes! Hum ... I wouldn't know about that sadly. I'll drop the question in the Velociraptor Discord and report back! |
Beta Was this translation helpful? Give feedback.
-
Sorry for the delay, very busy week! Created the PR and realized that I should go with NTUSER.dat* and UsrClass.dat* and not NTUSER.dat.* and UsrClass.dat.* as the last "." (dot) would mess up the FileMask. As for Velociraptor, the target files are updated every release from what Mike said in the Discord :) |
Beta Was this translation helpful? Give feedback.
-
Not a "new idea" per say as it would be more of an update/improvement to an existing KapeFile.
Right now, the NTUSER.dat and UsrClass.dat Registry Hives are collected through RegistryHivesUser.tkape using a "strict" FileMask on the filename. Namely:
NTUSER.dat
UsrClass.dat
Most of the user-based forensics are located in these two hives. However, in situations where a system has been encrypted, it is not unusual for these files to be encrypted, for instance:
NTUSER.dat.locked
UsrClass.dat.locked
Because of the "strict" FileMask, if an extension is appended to the file, these won't be collected. However, Registry Transaction Files do not have that issue, since they use a wildcard (*) FileMask (probably because it's usually LOG1 and LOG2):
NTUSER.DAT.LOG*
UsrClass.dat.LOG*
So even if these files get encrypted, they get collected.
The idea here would be to change the NTUSER.dat and UsrClass.dat FileMask to use a wildcard (*) so that even if they get encrypted, they are collected:
NTUSER.dat.*
UsrClass.dat.*
The use case is for DFIR scenarios where a triage package of an encrypted endpoint is collected (e.g.: through Velociraptor) and the victim ends up paying for the ransom later on. At a time where the endpoint may have been rebuilt. It would allow DFIR people to decrypt these files after the fact and then have full access to their evidence/artifacts.
Obviously, changing that FileMask to a wildcard (*) would probably make the ones for Registry Transaction Files moot (as they would be covered).
I know it may be a very niche scenario, but one that I'm sure many DFIR people have encountered at least once. Since there can be a lot of time between the initial response (e.g.: collecting forensic triage packages) and the ransom payment, should the ransom be paid by the victim.
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions