Tuesday, May 21, 2013

Plugin: SAMParse

I thought I'd take a moment to discuss the samparse.pl plugin.  This plugin parses the SAM hive file for information regarding user accounts local to the system itself, as well as their group membership, both of which can be very valuable and provide a good amount of insight for the analyst, depending upon the case.  The information retrieved by this plugin should be correlated against the output of the profilelist.pl plugin, as well as the user profiles found within the file system.

One of the initial sources for parsing the binary data maintained within the SAM hive is the Offline Windows Password and Registry Editor.  There is also a good deal of useful information in this AccessData PDF document.

An interesting piece of information displayed by this plugin, if available, is the user password hint.  This capability was part of the plugin starting on 20 Oct 2009 (the capability was included in XP), and discussed by SpiderLabs almost 3 years later. This may provide useful information for an analyst...I have actually seen what turned out to be the user's password here!

Perhaps one of the most confusing bits of information in the output of the samparse.pl plugin is the "Password not required" entry.  This is based on a check of a flag value, and means just that...that a password is not required.  It does NOT mean that the account does not have a password...it simply means that one is not required.  As such, you may find that the account does, indeed, have a password.  I've seen posts to various forums and lists that either ask about this setting, or simply state that the output of RegRipper is incorrect.  I am always glad to entertain and consider issues where the interpretation of a Registry value or data flag setting is incorrect, particularly if it is supported with solid data.

If you're analyzing a Vista or Windows 7 system and run across something suspicious regarding the local user accounts, remember that you will have a copy of the SAM hive in the Windows\system32\config\RegBack folder that you can incorporate into your analysis, and that you may also have older SAM hives in available VSCs.

Finally, there's a version of this plugin that provides timeline (TLN) output for various bits of time stamped date, to include account creation date, the password reset date, the last password failure date, and the last login.  Incorporating this into your timeline, along with the historical information available in other Registry resources (such as those mentioned in the above paragraph), can provide considerable insight into user activity on the system.

MS KB305144 -
Scripting Guy blog, 7/7/2006


twjolson said...

The link to the AccessData whitepaper doesn't work.

Keydet89 said...

Thanks...fixed it.

JimmyWeg said...

>...simply means that one is not

I'm still not sure about this. Our email thread that began on 10/2/12 isn't quite on point with your comment, but relevant nonetheless. I've been meaning to blog about this, myself. Are you talking about the policy to prevent auto logon (control userpasswords2) or some seurity policy? The setting at "Users must enter a user name and password..." doesn't affect the SAM byte in question. If you've come up with something since we chatted, please let me know. Thanks.

Keydet89 said...


From the MS KB article:

"PASSWD_NOTREQD - No password is required."

My point is that this is what MS states with respect to the flag value. Too many times, I will see someone post to a forum or list, suggesting that this means that the account does not have a password.

All I am trying to do here is make the distinction that this flag can be set, AND the account can still have a password.

JimmyWeg said...

I agree that the flag does not indicate whether the user employs a password. However, I still don't see that it is an indicator of "password required." I don't see where the KB article is on point at all with respect to the flag in the SAM. The KB article doesn't apply to Win 7, and the identified flag,
0x20, differs from the byte in the SAM. The KB article applies the Active Directory attribute, userAccountControl. If I'm off in my interpretation of the KB article, please let kme know.

FWIW, AccessData never replied to my repeated requests for the basis of Registry Viewer's comment about the flag, though they modified their definition over time, to where it's "less incorrect." As I mentioned a while back, I've come up with only one way to make the flag a 0 or 1 (auto install of Win 7), and nothing that I tried could make the flag change once set. At this point, I don't know why we even report the flag at all. Thanks!

Keydet89 said...

I don't know why we even report the flag at all.

I'm with you, Jimmy.