0X00 Foreword
I read the list of common privilege escalation methods for Windows written by Master Nancheng in one breath, remembered the recent subscribed articles, HTB range and penetration testing experience, and tried to expand the boundaries of my knowledge, so I have this following article. The promotion of power to the red team is equivalent to Sichuan cuisine to Sichuan peppercorns. When I was working as a penetration testing engineer, I found that the Windows local elevation method was divided into two main categories because of environmental problems (domain environment and workgroup). Due to the particularity of Windows, the attack methods of the domain environment and the working group are quite different, so we need to treat them differently according to the actual environment of penetration testing.
In the workgroup privilege escalation section, a large part of the local privilege escalation method is caused by writable directories in the system path environment variable and OS-based memory overflow. The root cause of these threats is common enterprise system misconfigurations and the operating system versions or system builds used by the enterprise, which lowers the barrier to entry for identifying and exploiting these issues.
In the domain environment section, the author will introduce the common local privilege escalation method in the red team, that is, the NTLM trunk privilege escalation and the Kerberos protocol in the domain environment are used to attack in the Windows domain environment to elevate the privilege on the employee workstation.
0X01 System Path Directory Configuration Issues (Working Group)
For enterprises with mature and complete security monitoring solutions, it is difficult to successfully exploit vulnerabilities to obtain high privileges, and it is difficult to avoid triggering detection in enterprise endpoint and network monitoring products, and local privilege escalation operations need more covert and reliable methods. The System Path Directory Configuration Problem (Working Group) is a Windows native privilege escalation method that I often use in my penetration testing role, and it is very common on multi-user systems with many applications installed.
A: It is caused by improper configuration of applications or scripts that allow users to write to restricted directories. For example, if a web application allows a user to upload a file, and the application does not properly validate the destination directory of the uploaded file, an attacker can upload a file to a restricted directory.
For example, the experiment in Figure 3 shows that after creating two folders named test in C:\Program Files\test and C:\test, create an unprivileged user and try to have the unprivileged user write to these two directories. There is a significant difference in the inheritance permissions between directories created in the C:\Program Files directory and directories created in the C:\ directory. Unprivileged users can write to C:\test\, but not to C:\Program Files\test\, i.e., C:\Program Files directory permissions are more stringent by default than C:\directory permissions.
C:\ directory (Figure 1): 1. By default, the Authenticated Users group has permission to create files and folders, and 2. This permission is inheritable, which means that it applies to all created directories that have not explicitly rejected it.
C:\Program Files directory (Figure 2): 1. By default, the Authenticated Users group does not contain permission to create files and folders, and 2. Folders created in Program Files prevent non-privileged users from writing to them by default.
图一(图片来源praetorian)
图二(图片来源praetorian)
图三(图片来源praetorian)
0X02DLL Sideloading (Workgroup)
A common DLL sideloading vulnerability process is as follows: an attacker modifies a registry key to point to a malicious DLL, uses social engineering (via email, social media, or other channels) to approach the target to send a malicious DLL, and tricks the victim into running an application, and when the target runs the program, the application will try to load the DLL from the path specified in the registry key, and because the registry key has been modified, the application will load the malicious DLL and execute its code. (as shown in Figure 4 below)
Figure IV
In the author's red team career, while phishing in this way to obtain high local privileges of the target, the risk of being discovered by enterprise security devices was greatly avoided. According to Microsoft's regulations, we need to note that DLL sideloading behavior may not raise a vulnerability alert for Windows systems because the system is performing the correct operation to search for the path. However, if a third-party application installer modifies the system path environment variable and introduces a writable path permission issue during the installation process, this may be detected by Defender and alert the user. So if the red team needs to cover people's eyes, then Microsoft's own products are the most interesting targets for attackers.
THE MOST STRAIGHTFORWARD WAY TO TAKE ADVANTAGE OF DLL SIDELOAD ELEVATION IS TO IDENTIFY AN APPLICATION SERVICE RUNNING AS NT AUTHORITY\SYSTEM THAT IS TRYING TO LOAD A NON-EXISTENT DLL (DYNAMIC LINK LIBRARY) OR TRYING TO EXECUTE AN EXECUTABLE FILE THAT DOES NOT EXIST. The service may attempt to load a DLL file that exists only on the desktop operating system. Since the file does not exist on the server operating system, it will eventually traverse the system path, looking for the file. From an operational perspective, the best-case scenario for an attacker is for an unprivileged user to trigger this action without rebooting the target system.
Figure 5 (Image source)
For example, the email shown in Figure 5 of the spear phishing attack contains an attachment that exploits a vulnerability in Windows ActiveX (CVE-2012-0158) that appears to be a normal binary on its own, but when combined it becomes an executable malicious file. As shown in the figure, the green icon indicates that the executable file contains a DLL sideload vulnerability. oinfop11.exe will be introduced after the Office 2003 Service version is updated. The spear-phishing attack loads a deceptive DLL component (Oinfo11.ocx). Once Oinfo.ocx is loaded into memory, it automatically decompresses, loads, and decodes auxiliary components (Oinfo11.iso).
0X03Win32k Elevation of Rights (Working Group)
Win32k privilege escalation is a good local privilege escalation method, and its influence is very large, including the Win32k subsystem in Windows 8, Windows 10, and Windows Server. Low-privileged users can easily obtain Windows system privileges by exploiting the Win32k privilege escalation vulnerability. The vulnerability is located in the Win32k subsystem (i.e., the Win32k.sys kernel driver), which manages the operating system's window manager, screen output, input, and graphics.
It was found that the Win32k subsystem only locked the window object, but failed to lock the nested menu object. The reason for this type of problem is that the old version of the code is copied to the new version of Win32k. If an attacker has permission to change a specific address in the system's memory, it can cause the menu object to be tampered with or hijacked. By controlling the menu object, an attacker can gain the same level of access (usually system privileges) as the program that launched it. Researchers on Github have published a Win32k privilege-escalation poc (Win32kpoc link) that elevates privileges to the system level, which significantly lowers the threshold for exploiting the vulnerability. This version of the POC usually doesn't require new exploitation techniques other than exploring different ways to control the first write operation by freeing up the reoccupied data in memory. While Win32k privilege escalation may seem unavailable on Windows 11 versions, it poses a significant risk to enterprise systems (Windows 10 is still the main office system in today's enterprises). And the Win32k privilege escalation vulnerability is largely because of the desktop heap handle address leaked by the system, if the enterprise does not have a reasonable solution, the information security of the enterprise is still facing a greater risk, which is a good local privilege escalation method for the red team.
The author's research was conducted on Windows Server 2016, and through the vulnerability analysis blog on the Internet and the study of the vulnerability patch, the author found a rather interesting problem. Due to the antiquity of the win32k code, the author can only increase the convincing power by citing some early source code comments (Figure 7). Win32k's code implementation focuses only on locking window objects, inadvertently ignoring locking menu objects nested within window objects. So how does the incorrect reference to the menu object in this window occur? The author analyzes the vulnerability function context (Figs. 8 and 9). In the process of analysis, the author found a noteworthy problem. While menus passed to xxxEnableMenuItem() are typically locked in higher-level functions, determining exactly which menu object should be protected in this particular case raises a question that needs to be determined. By continuing to analyze the xxxEnableMenuItem function in depth, the author carefully examines the potential handling of menu objects and finds an important problem, that is, the menu returned by the MenuItemState function can not only contain the main menu in the window, but can also be extended to submenus, and in some cases even to submenus.
Figure 6 (Image source)
Figure 7 (Image source)
Figure 8 (Image source)
Figure 9 (Image source)
When exploiting the Win32k elevation of privilege vulnerability, it is necessary to conduct an initial assessment to avoid situations where it cannot be bypassed, thus saving a lot of time. There are two scenarios to consider before building an exploit for this particular vulnerability when analyzing its poc or exp: execute a shellcode\ modify the token address using a read-write primitive. Based on earlier CVE-2017-0263 and CVE-2016-0167 vulnerabilities, shellcode operations were executed. Note: This approach is not recommended because of the challenges of implementing shellcode behaviors and security mechanisms such as SMEP in later versions of Windows. Over the past few years, public POCs have proven the superiority of modifying token addresses using read-write primitives. Although this type of exploit shows persistence and versatility in terms of the memory layout of the desktop heap and the read/write primitives in the desktop heap, it also presents considerable challenges. How do I control the value of cbwndextra when reusing UAF memory?A: The author suggests dividing the entire exploit into two different problems: 1) using the UAF vulnerability to control the value of cbwndextra, and 2) establishing a stable method of reading and writing primitives after gaining control of the cbwndextra value.
When an attacker triggers the vulnerability, the system may crash. This is because the method of triggering the POC eliminates all other associations of reuse vulnerabilities in the system. It is possible that the system incorrectly uses window object data from memory that we control only in the MNGetPopupFromMenu() and xxxMNUpdateShownMenu() functions of xxxEnableMenuItem. In order to occupy the released menu object during the vulnerability trigger, you can exploit the window name object in the window class WNDClass. The first data write takes place during this process, and we determine the appropriate location in the built address structure. This position allows us to write data arbitrarily, even if it's just a byte (which can be written to the high bits of cbwndextra).
In the xxxRedrawWindow function, we identified two alternative ways to handle operations on adjacent memory data. Let's explore these methods in more detail: the method that uses GreCreateRectRgnIndirect/the method that relies on the flag bit AND 2 operation. One option is to use GreCreateRectRgnIndirect, but it presents two challenges. First, controlling the first 8 bits of CBWNDEXTRA proved difficult because it only briefly turned into 1 under specific finite conditions. Second, when this approach is taken, the other relative offsets of CBWNDEXTRA will point to the last 8 bits of the previous object (regardless of object type). The last 8 bits usually represent the safe bytes at the end of the heap linked list and are not easily manipulated. Considering the difficulties associated with the first method, we opted for another method, which involves the use of AND 2 operations to manipulate flag bits. However, controlling the secure bytes at the end of the heap linked list remains a challenge. To overcome this obstacle, we modified our strategy. Instead of writing to the cb-extra of the window object, we are directing the write operation to the cb-extra of HWNDClass. The latter's cb-extra has a smaller offset from the former's cb-extra, allowing us to manipulate the memory data of the previous object as a parameter for flag checks in the xxxRedrawWindow function (Figure 10).
Figure X
0X04NTLM Trunk Privilege Escalation (Domain Environment)
In the case of privilege escalation in the context of entering the domain environment, we can use such a method: NTLM relay elevation (reference). In NTLM relay, the attacker needs to replay the intercepted Net-NTLM hash for attack, so as to achieve control over other machines. For the workgroup machine, the passwords of the two machines need to be the same to be successful, but for the domain user, the deceived user (the user who initiated the request) needs the user in the domain administrators group, and the permission after the NTLM relay is successful is the permission of the deceived user. To make Net-NTLMhash replay successful, the first thing to do is to obtain this Net-NTLMhash, because SMB, HTTP, LDAP, MSSQL and other protocols can carry NTLM authentication of three types of messages, so as long as you use SMB, HTTP, LDAP, Programs that use MSSQL and other protocols for NTLM authentication can try to send Net-NTLMhash to the attacker so that the attacker can intercept the user's Net-NTLMhash, which means that we can attack through these protocols.
FIGURE XI
NTLM authentication process (Figure 11):
When the client needs to access the server, the client needs to enter the username and password of the server for verification, and the client caches the NTLM-Hash value of the server. After that, the client starts sending a TYPE 1 Negotiate message to the server
After receiving the TYPE 1 negotiation message sent by the client, the server will take out the content that it can accept, pass it to the NTLM SSP, and obtain the TYPE 2 challenge message, which contains a 16-bit random value generated by the server, which is called Challenge. The server saves a copy of this challenge and sends a TYPE 2 message back to the client
After receiving the TYPE 2 message from the server, the client reads out the challenge value, encrypts it with the NTLM-Hash of the cached server password, and combines it with the username and challenge to obtain Net-NTLMHash, and finally encapsulates the Net-NTLMHash into a TYPE 3 NTLM_AUTH message and sends it to the server
After receiving the TYPE 3 message from the client, the server takes out the Net NTLM-Hash value and sends an authentication request to the domain controller to the client. The content of the request includes: the username, the original challenge, and the encrypted challenge (i.e., Net NTLM-Hash)
The DC takes out the password hash NTLM-Hash of the account according to the user name, and encrypts the original challenge with the password hash NTLM-Hash to obtain the Net NTLM-Hash. If the encrypted challenge is the same as that sent by the server, it means that the user has the correct password and the authentication fails. The DC sends the verification result to the server
During NTLM authentication, the client can use its password to encrypt certain information provided by the server to prove its identity to the server. So, what an attacker has to do is let the client do its job and pass the message from the client to the server and the reply from the server to the client. All the messages that the client wants to send to the server, the attacker receives, and then he sends the message back to the real server, and all the messages that the server sends to the client, the attacker also receives, and he forwards them to the client as is. In fact, from the client's point of view, NTLM authentication takes place between the attacker and him, with all the necessary conditions. The client sends a negotiation request in its first message, and the attacker replies to the request with a challenge. After receiving this challenge, the client constructs its response with its secret and finally sends the last authentication message containing the encrypted challenge. But the attacker can't do anything with this exchange. From the server's point of view, the attacker is just as much a client as any other client. He sends the first message to request authentication, and the server responds with a challenge. When an attacker sends the same challenge to a real client, the real client encrypts the challenge with its secret* and responds with a valid response. As a result, an attacker can send this valid response to the server. From the server's point of view, the attacker has authenticated itself using the victim's secret, but is transparent to the server. It doesn't know that the attacker is replaying his message to the client in order for the client to give him the correct answer. At the end of these exchanges, the attacker authenticates with the client's credentials on the server.
I encourage you to read the article "Gone to the Dogs" outlining a way to obtain the NetNTLM authentication primitives for computer accounts over HTTP by leveraging the ability to customize the Windows lock screen as an unprivileged user. Successful exploit of the vulnerability requires the following prerequisites: 1) a domain controller running a Windows Server 2012 or later operating system, 2) an attacker must have access to a user or computer account object with a service principal name set, or be able to add new computers to the domain, 3) the domain controller must not be configured to enforce LDAP signatures and LDAP channel binding (the default), and 4) the victim computer must have a "webclient" installed and running Services (installed by default on Windows 10) and 5. Users must be allowed to customize the Windows lock screen (default permissions), which are worth digging into.
0X05Kerberos Protocol (Domain Environment)
In addition to this, escalation of privilege in the context of entering a domain environment can also attempt resource-based constraint delegation or other Kerberos-based attacks. A: RBAC is an access control model that controls a user's access to a resource by assigning permissions to the user. A resource can be any type of object, such as a file, a database table, or an application. In many enterprises, there will be an account dedicated to adding machines to the domain. If we get the user rights in the Account Operators group, we can get the system permissions for all machines except the domain controller. An attacker can query the mS-DS-CreatorSID of a computer in the domain, which represents the user who joined the computer to the domain, and it has the permission to modify the msDS-AllowedToActOnBehalfOfOtherIdentity, and if we can get the credentials of that user, we can control all the computers that the user adds to the domain.
Add the machine account, change the msDS-AllowedToActOnBehalfOfOtherIdentity value to the SID of the machine account, and then fake the identity of the machine account as the administrator to request a ticket (similar to a silver note) to access the machine account because the machine account does not have it There is a configuration of binding delegation, so this ticket is not forwardable, but in the resource-based constraint delegation, it is not important whether the ticket can be forwarded, and it has no impact on s4u2proxy in the future, and finally use this ticket to apply for access to the machine that has modified the msDSAllowedToActOnBehalfOfOtherIdentity property.
FIGURE XII
The operator specified the IP address (192.168.184.144) instead of the TGS ticket generated with the DESKTOP-KOERA35. CONTOSO. LOCAL) The full hostname specified in the associated service principal name.
图十三(图片来源praetorian)
An operator may attempt to use Rubeus to generate a new beacon from the host to import the TGS ticket retrieved when the S4U is executed into the current login session. While this technique works when targeting other hosts, it does not appear that a "full network login" is performed when attempting to execute beacons using WMI from the same host. Instead, security tokens associated with the process are leveraged. The results are shown in the figure below. ALTHOUGH THE TGS TOKEN FOR THE ADMIN USER IS ASSOCIATED WITH THEIR LOGIN SESSION, THE SECONDARY BEACON IS GENERATED AS A JSMITH USER. To avoid this issue, we have to use SOCKS to proxy Impacket to the host to perform a full network login.
图十四(图片来源praetorian)
0X06 defense methods
The fix for the system path directory configuration issue is relatively easy, as only the permissions for the writable directory need to be modified. If the application installer introduces a writable path vulnerability by modifying the system path, consider filing a report with the Enterprise SRC.
Restrict write access to restricted directories: Ensure that only authorized users can write to restricted directories
Verify uploaded files: Verify files uploaded to the web application or other systems to ensure that they are not written to restricted directories
Use secure coding practices: Follow secure coding practices to avoid misconfigured applications
Use an intrusion detection system (IDS): Deploy IDS to detect suspicious activity, such as an attempt to write to a restricted directory
Patch regularly: Install security patches in a timely manner to fix known vulnerabilities
It is also relatively easy to fix DLL test load attacks and Win32k privilege escalation attacks, which require enterprises to strengthen the monitoring and updating of security devices, and greatly alleviate the security threat problems of enterprises through diversified interception methods and internal training.
Use digital signatures: Sign legitimate DLL files to prevent attackers from using unsigned malicious DLLs
DLL Integrity Check: Verify the hash or signature of DLL files to ensure they have not been tampered with
Code Signing Verification: Verify that the loaded DLL has been signed by a trusted authority
Network Intrusion Detection/Prevention System (NIDS/NIPS): Detects and blocks malicious DLLs in network traffic
Use sandboxing: Isolate sensitive applications in a sandbox to restrict attackers' access to system resources.
Deploy an anti-malware solution: Detect and block malware that exploits Win32k vulnerabilities
Use virtualization: Virtualize applications and services to isolate them from potential attacks
Implement network segmentation: Divide the network into different zones to limit the lateral movement of attackers on the system
As for the threat of privilege escalation in the domain environment, the author believes that it is necessary to improve enterprise security planning and implement enterprise security configuration policies. We know that resource-based constrained delegation (RBCD) is a delegation mechanism that allows a user or application to access or manipulate a specific part of a particular resource without granting full control over the entire resource. This helps reduce the risk of elevation of privilege attacks, as attackers cannot access or modify other parts of a resource, even if they gain access to a restricted resource. Measures to defend against resource-based constrained delegation attacks include:
Implement the principle of least privilege: Grant users and applications only the minimum privileges they need to perform tasks, including access to resources
Use access control lists (ACLs): Configure ACLs to specify which users and applications can access which parts of a resource
Enable audit logging: Log access and modification attempts to restricted resources to detect suspicious activity
Use secure programming practices: Follow secure coding guidelines, such as input validation and bounds checking, to prevent vulnerabilities such as buffer overflows and integer overflows
0X07 conclusions
From the perspective of security technology, the author believes that the most ideal way to elevate privilege locally in Windows is the system path directory configuration problem + DLL side loading. In many enterprise environments, the author finds that the web service is often a good breakthrough through dotting into the enterprise environment, the security device's access to the web service does not require multi-factor authentication, and the employees in the enterprise can usually access the website, and the use often spans multiple departments, the host of the web service is usually installed with a large number of applications, and the author finds that the system path directory configuration on these hosts will have some problems. Since the permissions are generally not high after the dotting is successful, at this time, the system path directory configuration problem + DLL side loading is a good solution.
After gaining a foothold in the enterprise intranet, by distinguishing the internal environment of the enterprise (workgroup\domain environment), after moving laterally, the appropriate attack method Win32k privilege escalation (workgroup) and NTLM relay privilege elevation \Kerberos protocol (domain environment) are used to carry out attacks. to avoid being discovered by an enterprise SOC with proven detection and response capabilities. In a similar environment, unreasonable privilege escalation techniques and lateral movement technologies will be quickly detected by the enterprise SOC and expelled, resulting in the failure of the attack.
Finally, I would like to thank Master Nancheng for the inspiration of the article, as a safe salted fish, I hope that you will criticize the author's above article and correct it in the comment area, and the author will keep a normal heart. After all, there are too many knowledge points involved in the promotion of power, and the author will inevitably have omissions and deficiencies. It can be said that the level of an attacker is closely related to the knowledge and ability of the attacker. Win32k privilege escalation and the Kerberos protocol are not something that the author can understand now. Therefore, the author humbly accepts the match and enjoys the learning process.
References:
https://www.numencyber.com/cve-2023-29336-win32k-analysis/
https://github.com/0x5bfa/NT5.1/blob/1b390dddff9fe017e9c11a7845c67a887c3483dc/Source/XPSP1/NT/windows/core/ntuser/kernel/mnsys.c#L511
Hattops://github.com/kalendc/cwe-2022-21882/blob/i/exploittest.cp
https://www.real-sec.com/2022/01/technical-analysis-of-cve-2021-1732/
https://techcommunity.microsoft.com/t5/core-infrastruct-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536
hatpas://vv.freebf.com/articles/system/338877.html
hatps://eladshamir.com/2019/08/08/lock-screen-lape.html
https://petri.com/understanding-kerberos-delegation-in-windows-server-active-directory
https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-ef185fb8-00f7-167d-744c-f299a66fc00a