Determining user's groups from Windows image
The tool you mention uses a publicly available API to get the information from a live system…which, while useful in some ways, doesn't really answer my question.
I don't understand? Please explain? Do you mean, not forensically sound?
I've been trying to find a way to determine the groups a user has membership in, using nothing more than an image, opened in ProDiscover.
I am not asking for methods to determine group membership from live systems.
I've been doing some limited testing this morning on a standalone (not networked, not part of a domain, etc) XP Pro SP 2 system.
I created a user via the GUI, and created another user via the 'net user' command. These are the only two user accounts on the system besides the Administrator. The Administrator is in the Administrators group only, and the other two users (ie, test and test2) are in the Users group only.
Looking at the SIDs in the Registry, all users have the same SID…the only difference is the RID.
Changing the group membership doesn't seem to change the SID at all.
if you are using NTFS, my understanding is that users and groups SIR/RID are stored as part of file attributes used by the user. could that help in gleannig groups membership.
Obviously if some SID are domain based you would need to have access to the Domain controllerto map these SID to group names.
For pure user/group relationship (with no file association) this is defined in the Local SAM for local account and doamin SAM for Domain accounts.
where exatcly in the SAM these keys are is the crux of the matter. I would try to do my research and see what turns up.
I'm not sure that NTFS has a whole lot to do with it, as you're still able to assign users to groups on a FAT filesystem…you just don't get the security mechanisms inherent to NTFS.
I've done some research, running "net localgroup users" while running Regmon. I saw accesses to HKLM\SAM\SAM\Domains\Account\V and …\Builtin\V. Then I saw accesses to HKLM\SAM\SAM\Domains\Builtin\Aliases\00000221. I think this may be the alias within the SAM for the Users group. Afterward, I saw accesses to the V structures for HKLM\SAM\SAM\Domains\Account\Users\000003F0 and 000003F1…if I parse the V structures, I find the names for the two user's accounts (respectively) that are assigned to the Users group.
More testing needs to be done.
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.
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.
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).
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?
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.