Things that security settings have to be known
1. Summary
Analyzing the security account manager structure was done more than a month ago, only recording fragments and never publishing them. The main reason for not publishing is that the Security Account Manager (SAM) is the core of WIN system account management and is very systematic. I also have many things that just make inferences and guesses. At the same time, SAM hack may cause an error in loading the Account Manager at startup, and even the safe mode cannot be fixed (SAM must be loaded at startup) causing the entire system to start crash (I usually need to rely on the second system to delete the SAM file to start). As for the release now, it is mainly because the rootkit production methods described by Adam and Dingding's "Clone Administrator Account" are concealed and harmful. The familiarity with the SAM structure can help security maintenance personnel to conduct security inspections (of course, it may also be used by bad attempters). This is only the content about SAM, and those related to Security will not be disclosed for the time being.
2. About SAM
Don't misunderstand SAM, it's not as simple as a file sam. SAM (Security Accounts Manager Security Account Manager) is responsible for the control and maintenance of SAM database. The SAM database is located under the registry HKLMSAMSAM and is protected by ACL. You can use to open the registry editor and set appropriate permissions to view the content in the SAM. The SAM database is stored on disk in the sam file in the %systemroot%system32config directory. In this directory, it also includes a security file, which is the content of a secure database. The two have a lot to do with each other.
The SAM database contains information about all groups and accounts, including password HASH, account SID, etc. These contents are described in detail later. The system analyzed in Chinese Win2K Adv Server is an example.
3. Structure of SAM database in the registry
Expand the Registration HKLMSAMSAM:
HKLM---SAM
|---SAM
|---Domains
| |---Account
| | |---Aliases
| | | |---Members
| | | |---Names
| | |---Groups
| | | |---00000201
| | | |---Names
| | | |---None
| | |---Users
| | |---000001F4
| | |---000001F5
| | |---000003E8
| | |---000003E9
| | |---Names
| | |---Adaministrator
| | |---Guest
| | |---IUSR_REFDOM
| | |---IWASM_REFDOM
| |---Builtin
| |---Aliases
| | |---00000220
| | |---00000221
| | |---00000222
| | |---00000223
| | |---Members
| | | |---S-1-5-21-1214440339-706699826-1708537768
| | | |---000001F4
| | | |---000001F5
| | | |---000003E8
| | | |---000003E9
| | |--- Names
| | |---Administrators
| | |---Users
| | |---Guests
| | |---Power Users
| |---Groups
| | |---Names
| |
| |---Users
| |---Names
|
|---RXACT
This is the SAM tree in the registry on the machine.
By comparing the contents in the SAM file, it can be seen that the SAM tree in the registry is actually the same as in the SAM file. However, the SAM file is first listed in the RXACT and then the Domains content (and so on), and the expression order in the file is the opposite of the tree order in the registry. If you are used to looking at the content of a file, from 0000h to 0006Ch of the file, it means the location of the SAM database: systemrootsystem32configsam, and then one end is blank until 01000h (hbin), from here it is the content of the entire database. The file content of the SAM database will not be mainly introduced, but there will be introductions interspersed. If you are interested, you can study it yourself.
4. SAM database structure and main content:
In the entire database, the main content of the account exists in the following locations:
Under Domains is the SAM content in the domain (or native), under which there are two branches "Account" and "Builtin"
DomainsAccount is the content of the user account.
DomainsAccountUsers are the information of each account. The subkey below is the SID relative identifier of each account. For example, 000001F4, each account has two sub-items, F and V. Under Names is the user account name, and each account name has only one default child. The type in the item is not the general registry data type, but points to the last item (relative identifier) of the SID that marks the account. For example, the Administrator below is of type 0x1F4, so the previous 000001F4 corresponds to the content of the account name administrator. This shows the logic of MS account search.
Inferred 1: From the structure of the registry, if you query the relevant information of an account name refdom, then Microsoft will use the account name refdom.
Find its type 0x3EB, and then find the account content with the relative identifier (or SID) of 000003EB. This is how all API functions (such as NetUserEnum()) are executed. Therefore, if type 0x3EB in the refdom account is changed to 0x1F4, then this account will be pointed to the account of class 000001F4. This account 000001F4 is the administrator account. In this way, the system completely converts the refdom account to the administrator account during the login process. All the content and information used by the account refdom are the administrator content, including passwords, permissions, desktops, records, access time, etc. This inference should be valid, but it will mean that two user names correspond to one user information, and an error should occur on the system startup!
Inferred first, it was concluded when analyzing the structure before, revealing the relationship between the account name and SID during and after the login process.
DomainsAccountUsers00001F4, this is the account information of the administrator (other similar). There are two children V and F.
The basic information of the account is stored in project V, such as user name, user full name, group, description, password hash, comments, whether the password can be changed, account enablement, password setting time, etc. Project F saves some login records, such as the last login time, the wrong number of logins, etc. Another important point is the SID relative identifier of this account.
I didn't notice this place when analyzing the structure before, and this is what Adam proposed. This is where the SID relative identifier appears twice in the registry, one is in the subkey 000001F4, and the other is the content of item F in the subkey, from 48 to 51: F4 01 00 00. This is actually a long type variable, that is, 00 00 01 F4. Synchronization problems will occur when a sign appears in two places. Obviously, Microsoft has made this problem. The two variables should have unified the tags for a user account, but Microsoft has played their respective roles, but it has not been unified synchronously.
The 000001F4 in the subkey is used to correspond to the user name administrator, which is convenient for users to query account information. For example, the account-related API functions such as LookupAccountSid() are all used to locate user information through this location. This association should be used after the account login. The F4 01 00 00 in the project V value is the most directly related to the same account login.
Inference 2: When WIN logs in, the relative identifier will be obtained from the SAM, and the position of this relative identifier is F4 01 00 00 in the V value. However, the content of the SAM neutron key used by the account information query is used.
The reason hypothesis for inferring two (assumption 1): When the account is logged in, the login process obtains the relative identifier value in the account record information used by the user name in the SAM database (equivalent to F4 01 00 00 in the V value). After the account is logged in, all the account-related accounts are no longer used by the API function, and the relative identifier is replaced by the field name of a data record item (equivalent to the subkey 000001F4). Microsoft has committed a synchronization logic problem!
The second reason for the inference is based on Adam's proposal, and it has not been inferred like this before. :( Inferred 2, if it is true, it reveals the process of the account SID during the login process. This is why the values in V are related to the account login record (login time, password error times, etc.). At the same time, because F saves a username content, and the API function querys this username, Adam's cloning method is still easy to show its face. After Ding Ding, the username is restored to the original username, so it is relatively difficult to detect from the username.
As mentioned above, you can know that the basic information of the account is stored, user name, user full name (full name), group, description, password hash, comments, whether you can change the password, account activation, password setting time, etc. What I care about now is the password HASH.
Assumption 2: In the account item V, the user HASH is included, including the password encryption hash of LM2 and NT, respectively. When Crack, it can be performed separately. After all, LM2 is simple.
The contents under DomainsBuiltin are related to the account group. The structure is similar to that under Account, and there are corresponding problems, so I won't go into details.
The files sam stored in the SAM database do not have as concise content as in the registry, but mainly locate content through offset and length. And the information of a single account is concentrated in one piece, rather than separated like the registry form (one key of the name and another key).
In the sam file, the following separators can be used to locate the data meaning:
nk (6E 6B) key or subkey name
vk (76 6B) Responsive value
if (6C 66) Subkey list
sk (73 6B) Permission
5. Conclusions about SAM database analysis:
SAM HACK is very dangerous. Incorrect modifications will destroy the system's security data manager, causing system startup problems, although startup recovery can be made by deleting the SAM file. If you can be familiar with the structure of SAM, you will find that you can switch between usernames and usernames, user groups and user groups, as well as account and account groups forgery, completely breaking Microsoft's account structure. And it is very concealed, making the account-related API functions confused. Although Microsoft has committed many logical problems in handling account information, the secure account database is not unsafe, and all operations must have full administrator rights.
When the method of hiding backdoors is proposed, it will definitely be exploited by many "hackers", and administrators should also be familiar with relevant technologies and conduct security inspections.
1. Summary
Analyzing the security account manager structure was done more than a month ago, only recording fragments and never publishing them. The main reason for not publishing is that the Security Account Manager (SAM) is the core of WIN system account management and is very systematic. I also have many things that just make inferences and guesses. At the same time, SAM hack may cause an error in loading the Account Manager at startup, and even the safe mode cannot be fixed (SAM must be loaded at startup) causing the entire system to start crash (I usually need to rely on the second system to delete the SAM file to start). As for the release now, it is mainly because the rootkit production methods described by Adam and Dingding's "Clone Administrator Account" are concealed and harmful. The familiarity with the SAM structure can help security maintenance personnel to conduct security inspections (of course, it may also be used by bad attempters). This is only the content about SAM, and those related to Security will not be disclosed for the time being.
2. About SAM
Don't misunderstand SAM, it's not as simple as a file sam. SAM (Security Accounts Manager Security Account Manager) is responsible for the control and maintenance of SAM database. The SAM database is located under the registry HKLMSAMSAM and is protected by ACL. You can use to open the registry editor and set appropriate permissions to view the content in the SAM. The SAM database is stored on disk in the sam file in the %systemroot%system32config directory. In this directory, it also includes a security file, which is the content of a secure database. The two have a lot to do with each other.
The SAM database contains information about all groups and accounts, including password HASH, account SID, etc. These contents are described in detail later. The system analyzed in Chinese Win2K Adv Server is an example.
3. Structure of SAM database in the registry
Expand the Registration HKLMSAMSAM:
HKLM---SAM
|---SAM
|---Domains
| |---Account
| | |---Aliases
| | | |---Members
| | | |---Names
| | |---Groups
| | | |---00000201
| | | |---Names
| | | |---None
| | |---Users
| | |---000001F4
| | |---000001F5
| | |---000003E8
| | |---000003E9
| | |---Names
| | |---Adaministrator
| | |---Guest
| | |---IUSR_REFDOM
| | |---IWASM_REFDOM
| |---Builtin
| |---Aliases
| | |---00000220
| | |---00000221
| | |---00000222
| | |---00000223
| | |---Members
| | | |---S-1-5-21-1214440339-706699826-1708537768
| | | |---000001F4
| | | |---000001F5
| | | |---000003E8
| | | |---000003E9
| | |--- Names
| | |---Administrators
| | |---Users
| | |---Guests
| | |---Power Users
| |---Groups
| | |---Names
| |
| |---Users
| |---Names
|
|---RXACT
This is the SAM tree in the registry on the machine.
By comparing the contents in the SAM file, it can be seen that the SAM tree in the registry is actually the same as in the SAM file. However, the SAM file is first listed in the RXACT and then the Domains content (and so on), and the expression order in the file is the opposite of the tree order in the registry. If you are used to looking at the content of a file, from 0000h to 0006Ch of the file, it means the location of the SAM database: systemrootsystem32configsam, and then one end is blank until 01000h (hbin), from here it is the content of the entire database. The file content of the SAM database will not be mainly introduced, but there will be introductions interspersed. If you are interested, you can study it yourself.
4. SAM database structure and main content:
In the entire database, the main content of the account exists in the following locations:
Under Domains is the SAM content in the domain (or native), under which there are two branches "Account" and "Builtin"
DomainsAccount is the content of the user account.
DomainsAccountUsers are the information of each account. The subkey below is the SID relative identifier of each account. For example, 000001F4, each account has two sub-items, F and V. Under Names is the user account name, and each account name has only one default child. The type in the item is not the general registry data type, but points to the last item (relative identifier) of the SID that marks the account. For example, the Administrator below is of type 0x1F4, so the previous 000001F4 corresponds to the content of the account name administrator. This shows the logic of MS account search.
Inferred 1: From the structure of the registry, if you query the relevant information of an account name refdom, then Microsoft will use the account name refdom.
Find its type 0x3EB, and then find the account content with the relative identifier (or SID) of 000003EB. This is how all API functions (such as NetUserEnum()) are executed. Therefore, if type 0x3EB in the refdom account is changed to 0x1F4, then this account will be pointed to the account of class 000001F4. This account 000001F4 is the administrator account. In this way, the system completely converts the refdom account to the administrator account during the login process. All the content and information used by the account refdom are the administrator content, including passwords, permissions, desktops, records, access time, etc. This inference should be valid, but it will mean that two user names correspond to one user information, and an error should occur on the system startup!
Inferred first, it was concluded when analyzing the structure before, revealing the relationship between the account name and SID during and after the login process.
DomainsAccountUsers00001F4, this is the account information of the administrator (other similar). There are two children V and F.
The basic information of the account is stored in project V, such as user name, user full name, group, description, password hash, comments, whether the password can be changed, account enablement, password setting time, etc. Project F saves some login records, such as the last login time, the wrong number of logins, etc. Another important point is the SID relative identifier of this account.
I didn't notice this place when analyzing the structure before, and this is what Adam proposed. This is where the SID relative identifier appears twice in the registry, one is in the subkey 000001F4, and the other is the content of item F in the subkey, from 48 to 51: F4 01 00 00. This is actually a long type variable, that is, 00 00 01 F4. Synchronization problems will occur when a sign appears in two places. Obviously, Microsoft has made this problem. The two variables should have unified the tags for a user account, but Microsoft has played their respective roles, but it has not been unified synchronously.
The 000001F4 in the subkey is used to correspond to the user name administrator, which is convenient for users to query account information. For example, the account-related API functions such as LookupAccountSid() are all used to locate user information through this location. This association should be used after the account login. The F4 01 00 00 in the project V value is the most directly related to the same account login.
Inference 2: When WIN logs in, the relative identifier will be obtained from the SAM, and the position of this relative identifier is F4 01 00 00 in the V value. However, the content of the SAM neutron key used by the account information query is used.
The reason hypothesis for inferring two (assumption 1): When the account is logged in, the login process obtains the relative identifier value in the account record information used by the user name in the SAM database (equivalent to F4 01 00 00 in the V value). After the account is logged in, all the account-related accounts are no longer used by the API function, and the relative identifier is replaced by the field name of a data record item (equivalent to the subkey 000001F4). Microsoft has committed a synchronization logic problem!
The second reason for the inference is based on Adam's proposal, and it has not been inferred like this before. :( Inferred 2, if it is true, it reveals the process of the account SID during the login process. This is why the values in V are related to the account login record (login time, password error times, etc.). At the same time, because F saves a username content, and the API function querys this username, Adam's cloning method is still easy to show its face. After Ding Ding, the username is restored to the original username, so it is relatively difficult to detect from the username.
As mentioned above, you can know that the basic information of the account is stored, user name, user full name (full name), group, description, password hash, comments, whether you can change the password, account activation, password setting time, etc. What I care about now is the password HASH.
Assumption 2: In the account item V, the user HASH is included, including the password encryption hash of LM2 and NT, respectively. When Crack, it can be performed separately. After all, LM2 is simple.
The contents under DomainsBuiltin are related to the account group. The structure is similar to that under Account, and there are corresponding problems, so I won't go into details.
The files sam stored in the SAM database do not have as concise content as in the registry, but mainly locate content through offset and length. And the information of a single account is concentrated in one piece, rather than separated like the registry form (one key of the name and another key).
In the sam file, the following separators can be used to locate the data meaning:
nk (6E 6B) key or subkey name
vk (76 6B) Responsive value
if (6C 66) Subkey list
sk (73 6B) Permission
5. Conclusions about SAM database analysis:
SAM HACK is very dangerous. Incorrect modifications will destroy the system's security data manager, causing system startup problems, although startup recovery can be made by deleting the SAM file. If you can be familiar with the structure of SAM, you will find that you can switch between usernames and usernames, user groups and user groups, as well as account and account groups forgery, completely breaking Microsoft's account structure. And it is very concealed, making the account-related API functions confused. Although Microsoft has committed many logical problems in handling account information, the secure account database is not unsafe, and all operations must have full administrator rights.
When the method of hiding backdoors is proposed, it will definitely be exploited by many "hackers", and administrators should also be familiar with relevant technologies and conduct security inspections.