Harlan,
Doesn't Prodiscover let you extract registry entires as *.reg files after you mount the image???
After extracting the registry entries use sidtont or some commercial tool (FTK registry viewer) to decode SIDs.
But if you are trying to do this just within prodiscover strictly meaning without extracting any evidence for analysis outside of prodiscover, I am not sure. IMO FTK will be better tool in this case rather than prodiscover. Prodicover do advertise their program for live incident reponse mainly, which you are not interested in according to you previous post in this case scenario.
> Doesn't Prodiscover let you extract registry entires as *.reg files after you mount the image???
Actually, you can access the Registry pretty much the same way you would a live system using Perl. In PD, you use ProScript.
> After extracting the registry entries use sidtont or some commercial tool (FTK registry viewer) to decode SIDs.
I'm not sure why you'd suggest that. So far, it seems that the SID itself doesn't hold the information regarding group membership. Do you have some information regarding how the SID is decoded to reveal group membership?
I'm using PD to examine the image of a system, you're right, and I'm not interested in the live response aspect of it right now. I prefer PD's Registry Viewer and Perl interface.
Harlan
Thanks for the clarification.
Doesn't the operating system uses these Security Identifiers, not user or group names, to determine the access privileges of users and groups?
How is it decoded?
When a user logs on to a NT domain successfully, an access token is then created locally that contains the logged on user's SID, plus the SID of every group the user belongs to and any SIDs that were previously associated with the user account through the SID History. Added together, these two elements determine whether the user can access the network and what level of access he or she will have.
arashiryu,
You're correct on that, but you'll have to pardon me, as I don't see how that applies to what I'm asking. In a sense, we're already well beyond that point.
Here's the issue, as plain as I can make it…I have a 'dd' image of an XP system, with several user accounts on the system. I want to determine to which local groups a particular user belongs, using only the image (and not booting the image in anyway).
Harlan
Hey Harlan. Did you ever get an answer? I don't have ProDiscover so no idea how to do it that way and I'm not a PERL guy like you so no binary parsing answer either, but I can tell you how to do it with AccessData's Registry Viewer.
Open the SAM, go to \SAM\SAM\Domains\Account\Users to keys with user ID's jsawyer=000003EB, bobnum1=000003EC, bobnum2=000003ED. Registry Viewer does the coding for you so just click on one of the 8 digit hex codes on the left to see info about the user.
Next, go to SAM\SAM\Domains\Builtin\Aliases where the groups are listed on the left in 8 digit hexadecimal. Click on one to see what it is. Registry Viewer decodes it in the bottom left corner or you can figure it out by the ASCII decode on the right. Starting at the bottom of the hex decode on the right hand side, each 28 bytes represents a user in the group.
The last 28 bytes references the BobNum1 account, the next 28 is for jsawyer and the next is the Administrator account. Just reverse the last 8 bytes (GH EF CD AB = AB CD EF GH) to match it up.
Maybe you can use that to develop something to add into your regparse.pl script.
BTW, I was trying to put in the full 28 hex digits in this post and the forum kept cutting it off. Any ideas?
jsawyer,
Yes, I got some information from another forum that summed up what I needed. I do need to parse the C values you mention…I suspected that was the key (not Registry key…pardon the pun) to the issue, and that was confirmed for me.
Those user IDs you found are actually the RIDs.
Thanks,
Harlan