Need for Registry references
I'm curious as to what sort of information analysts and in particular LEOs are looking for in a Windows Registry reference.
Sticking to just 2K+ (including XP and 2K3), I'd like to know
1. What are LEOs and analysts looking for? What format is easiest to use? Spreadsheet? Database?
2. What kinds of things do you want to know about the keys? Where they come from? How/when they're created/updated?
3. Besides MS keys, what other applications are of interest?
4. What references do you use already? Are you maintaining a local list? Do you access online references (if so, can you share the links/URLs)? How credible are your references?
I think that there's a need for consolidation, testing/analysis (to verify and establish credibility), and a way to make it available to everyone who needs it. Perhaps a way to do with would be to have a central location, maintained by one person (or a small group) with requirements for submissions and updates. That way, the list could be available to all, with at least some assurance that a process is followed and updates aren't made lightly.
I'm a bit in the dark as to what is being used at present time by LE and the such but will troll the Internet and forums should I have any registry based inquiries.
The problem however is I'm not 100% sure of the accuracy of the information (with regards to hard to find reg info). Hence a central database maintained by a reputable source (educational institute for example) I think is a great idea especially if it contains key contents and how and why they are created.
An example from my end would be the Userassist key. I can see that once decoded the values represent CLI executables run, links accessed as well as URL's visited. Why they are created I'm not sure…clearing the values and launching different programs I can't see any real rhyme or reason as to why the key is populated. (at least during a cursory test).In terms of what I've found concerning the key…very little, just a blurb on Word Instrumental 2000 mentioning the key
http//support.microsoft.com/default.aspx?scid=kb;en-us;239062. Doesn't tell me much if I'm asked how the values are created.
I for one am interested in knowing that such and such a key contains xx value, but knowing how/why it is created I believe is just as important especially if I may be questioned on this at some point.
In terms of specific keys, with the proliferation of all the USB devices I think many will be interested in any information regarding the use of devices plugged into these portsâ€¦which I think you covered awhile back (usbstor & setupapi.log). The PC is becoming more of a Hub for tons of other stuff that at times you never visually see (and may not know were ever attached)….so these values I think are very useful.
I wish I had more time to dedicate to certain aspects of the discipline such as the registry but with a full time job outside of forensics I can only put aside so much time as I try and educate myself in hopes of a future foray into the field.
> I'm a bit in the dark as to what is being used at present time by LE
Okay, but I didn't limit my query to just LEO. If you're doing forensic analysis, what sorts of things are YOU looking for with regards to the Registry?
> The problem however is I'm not 100% sure of the accuracy of the information
This is a problem across the board. This is why I suggest the use of references, primarily from credible sources, as well as verifiable and reproducible testing.
> In terms of specific keys, with the proliferation of all the USB devices
Like you said yourself…been there, done that.
> I wish I had more time to dedicate to certain aspects of the discipline
> such as the registry
Again, this is why I posted originally, because this seems to be a common thread throughout the community, regardless of whether you are a LEO or not. It's pervasive. There are analysts out there…LEOs and otherwise…who are NOT performing Registry analysis, for no other reason than b/c they know far too little about the Registry.
What would you think of a standardized location (much like what Linus does with Linux kernel development) and a standardized testing procedure. Submissions can be made to the repository, but they must pass certain criteria, to ensure credibility? I don't agree that an academic site would be the most credible, as few academic institutions understand the needs of the analyst in the field.
I'm still open to thoughts and ideas about this…
Okay, so that's it? No one has any thoughts on the subject, nothing to add? No keys and supporting info that you'd like to submit?
Is no one out there doing any sort of Registry analysis, or even just correlating one or two values?
I'm in the midst of collecting what I think may be somewhat important registry locations. I have yet to do any real investigative work on them to determine if they are actually useful and if so, how they are created, what creates them and when.
The following is the list of keys that may be interesting. As I said I haven't looked in to them yet or compared against other lists I use already, so I apologize if they are actually useless. Also, if they've been duplicated elsewhere, let me know where, and in what doc so I can save myself some time.
Windows Installer file locations. This may help determining the existance of certain applications. I want to check how long this data is stored, to determine if say..a wiping application was once installed.
Last visited MRU.
Mapped network drive MRU
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
Network cards installed
Print server MRU
Recent Docs MRU
Shell Bag MRU
Special Accounts list
Terminal Services Cache information
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Remote Desktop Cache Files
NTP Servers being used
Terminal Services MRU
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default
Time Zone configuration
Time Zone mapping
Windows Uninstall locations
Windows Shutdown information
Winlogon information. Contains information about each SID, the GPO applied and possibly whether or not winlogon has been trojaned.
WOW Exec configuration
Thanks for the list…I've got most of them in my Registry key spreadsheet already.
What I'm looking at providing isn't just a list, but an explanation/description of how the keys are used (ie, conditions under which they are created/modified), as well as credible references that support this information.
In order for a Registry reference to be useful, it has to contain more than just a list of keys. Not only do keys and values need explanations, but information about how they are used, particularly when correlated with other keys or files is extremely important.
Right now, there're people like you and me, with lists of keys. Individually, we know why we want to look at those keys, and what we look for. When I was in an FTE position, I looked at the contents of the HKLM\..\Run key from all systems in the enterprise once a month, so I got pretty good at quickly spotting anomolies. However, there are new people every day being confronted with Registry analysis for the very first time…either as new forensic analysts, or b/c they are encountering Windows systems for the first time. The information needs to be consolidated, and built up, so that it can be of tremendous value to everyone.
I'll give you an example. In your list above, you mention "Telephony", and list a path to a key (??) named "Locations". I'm sure that you know why you're looking at the key, but does anyone else know? Why is this key important? What do the values within the key tell the investigator? How can this information be used with other values from the Registry to paint a picture for the investigator?
Indeed, more than just a list is necessary, and I do intend to complete the list and the contents of the keys so they are useful. All this list was intended to be was flagging potentially revealing keys so I could go back and dig deeper in to the what,when,how of the values. I should have *some* free time in the next month or so to develop the list in to something useful. As for credibility of the resources….know anyone at Microsoft? )
> know anyone at Microsoft?
I do…but haven't gotten anything out of them. Kind of like the whole "blood from a stone" thing.
When I sat down and was thinking about the format for a Registry reference, I also thought about how to handle submissions. As far as "credible references" go, two things came to mind (a) links to MS KB articles, and other credible sites (NIST, etc.), and (b) verifiable, repeatable testing. An example of this might be
1. Run the first half of the InControl5 two-phase process.
2. Initiate monitoring via Regmon.
3. Perform a single, atomic action (double-click a JPG image, either on the local hard drive or on a USB-connected removable storage device).
4. Halt Regmon capture.
5. Complete the InControl5 process.
6. Submit Registry key with description, test procedure, and results.
The basic idea is that if someone else uses the testing procedure, and performs the same action as in step 3, they should get the same results.
An additional step might be to query the LastWrite time of the key in question before step 1 and again after step 4.
It does sound reasonable. However, what about keys and values that are user configured such as the telephony key(s)? In that case, I'd say step 3 needs to be expanded to include the configuration of a single field (or the entire dialog window) in a user configurable utility.
Is the Telephony key directly user configurable? Does the user open RegEdit to modify the key, or is the action taken through a wizard or some part of the shell/GUI?
What I provided in my list of steps is an example. I think it applies to most, if not all, cases…particularly the part of step 3 that says, "Perform a single, atomic action"…this pertains to the action a user would take, such as interacting with a Wizard, the shell, a GUI dialog, etc. This includes the configuration of a single field.