Privilege escalation in a Windows environment
Information Security Management Practice: pentest
User privilege escalation to Windows domain administrator level
A good information security management system (ISMS) requires regular evaluation of its effectiveness. There are different methods of such assessments, one of the varieties of which is the so-called. “Penetration test” or pentest - an authorized simulation of a hacker attack on an information system in order to detect vulnerabilities in its defense before being detected by a real intruder. Any real-life hacking tools, exploits, methods, etc. can be used.
This article contains a description of one of these anti-hacker practices, aimed at raising the powers of an ordinary user of a Microsoft Windows domain to the level of a domain administrator. The article was based on a report on the results of a test implemented in practice. For confidentiality reasons, all information allowing to identify the venue (domain names and hosts, accounts, etc.) is deleted or changed. The article shows the basic techniques, for a better understanding, I cited the theoretical foundations and vulnerabilities used for specific versions of operating systems, as well as general recommendations for protection. And although most of these versions of Windows at the time of publication will be considered obsolete,
Description of the test object
The object of testing is fairly standard - the information system of a small (less than 200 employees) company specializing in software development. The company's internal network is also typical: switched Gigabit Ethernet, Microsoft Windows domain (we will call it CORP.LOCAL). Internal hosts are divided into IP subnets on the basis of their functional affiliation (such as: development team, quality engineers, human resources, accounting, marketing, top management, facilities, etc.); all segmentation is done on the L3 switch . There is also a park of internal servers allocated to a separate IP subnet, containing: two Windows Server 2008 domain controllers with integrated DNS, an internal mail server running Exchange, a file server, terminal server and some other auxiliary servers running Windows and Linux. Separately, it is worth noting the test lab with a fleet of machines running different versions of Microsoft Windows (both desktop and server) and designed to test the software being developed. Access to the test lab hosts have all employees. The basic version of the desktop OS is Windows 7. On desktops and servers, poorly configured anti-virus software from different manufacturers is installed (from Symantec, Kaspersky, and Trend Micro, why it is badly configured — more on this later).
The intruder is an internal employee who has an unprivileged user account in the domain, a desktop computer, physical access to test computers (may have a corporate laptop), but does not have local administrator privileges on any of them. Also, the account of the offender does not have the ability to change the settings of antivirus software. The purpose of the offender is to gain access, equivalent to administrator access, to a domain controller and / or file server.
As we see, both the model of the infringer and the description of the company are quite typical.
Step 0. Gather information about the internal network
So, we act on behalf of the offender. In this step, we need to collect information about:
- internal addressing and subnetting
- names and IP addresses of hosts, first of all we are interested in the list of servers
- using the NetBIOS protocol.
First, using the ipconfig utility, we obtain the IP addresses of the DNS servers: 192.168.12.1 and 192.168.12.2. Because DNS is integrated with Active Directory, this gives us reason to believe that we know the IP addresses of domain controllers. Next, using the nslookup utility in interactive mode, we try to get a list of all the hosts in the corp.local zone:
> ls –d corp.local> file
In fact, this command initiates a full transfer of the DNS zone, saving it to file. Many administrators forget to set restrictions on the transfer zone for the internal network, which makes it easier for a potential attacker to gather information about the company's infrastructure, see  for more details.
Result.Success. The unsecured zone transfer gave us a complete list of internal host names, including servers, and their IP addresses. Using the utilities nbtstat, telnet as well as any of the common vulnerability scanners, an intruder can collect information about the platform, the services running, the OS version on the hosts of interest.
Step 1. Obtaining local administrator privileges
Theory.To obtain the password of the local administrator, an attack is made on the hash function stored in the system registry of this password. Despite the fact that mathematically the hash function is irreversible, the password can be calculated by directly iterating its values together with a dictionary attack. Windows has historically used two algorithms for computing the password hash function: the outdated LM algorithm and the newer NT algorithm (sometimes also called NTLM). The LM hash function is vulnerable due to its low computational complexity, which makes it possible to iterate over its values even on a weak computer. The presence in the registry of the system at the same time LM- and NT-password hashes guarantee an attacker to break it in a reasonable time. The LM hash value at default settings is saved in the Windows XP / 2003 OS registry, which makes these systems particularly attractive to a hacker. The NT hash function is computationally more complex, however, the enumeration of its values is greatly simplified by the fact that for it there are available tables of pre-calculated values (so-called Rainbow-tables) - they reduce the calculation of the value of the hash function to the search for the desired hash among pre-calculated values.
The object of attack. Password hashes in the SAM database (registry). In our case, these are all machines to which we have physical access. First of all, this is our working desktop, in the second - the hosts to perform the tests.
Implementation. With machines that are physically accessible, we perform the following operation: boot from external media (using the Windows Pre-installation Environment CD or Linux Live CD), mount the NTFS system partition and copy the HKLM \ SYSTEM and HKLM \ SAM registry branches (% WINDIR files % \ System32 \ Config \ System and% WINDIR% \ System32 \ Config \ Sam respectively). Particular attention is paid to machines running Windows XP \ Windows 2003, which is likely to find LM-hash. To dump passwords from copied registry files, we use the tools ,  (all links at the end of the article). Result:
The last line contains the required NT hash of the local administrator. On the hosts from the test lab (let's call these hosts LAB1 and LAB2) we find a non-zero LM hash:
So, we have obtained NT- and LM-hashes. But how to recover from them the password? To do this, we will use the same tools ,  as well as online hash reverse services  - :
Note: the real password consisted of the name of the company with a small modifier and quickly broke under dictionary attack).
Result. Success. Passwords (let them be “Pa $$ word1” and “Pa $$ word2”) are obtained to the local administrator account from our desktop and two test computers. But will they help get domain administrator rights? About this further.
Step 2. Obtain domain administrator credentials
Theory.In most cases, it is enough to get the NT hash value of the domain administrator password. This is due to the fact that when checking a user using the NTLM protocol, the authenticated system presents only the NT-hash to the authenticator, and the password check does not occur. NT hash can be obtained from the so-called. storage LSA by referring to the so-called. Logon-session administrator (Logon-session - a special data area created by the Winlogon process, which stores the user name, domain login and the value of the NT password hash, all together it is called LSA-secret). This NT hash is used by the NTLMSSP process for NTLM authentication. Logon-session is saved all the time while the account is logged into the system. Also NT-hash can be intercepted from the administrator's NTLM authentication session. Besides, An administrator password can be obtained from the Domain Cached Credentials (DCC) cache. DCC is a local cache that is filled when a user successfully enters a domain. The purpose of the DCC cache is to be able to authenticate the user when the domain controller is unavailable.
Objects of attack:
- DCC hashes (registry HKLM \ Security).
- Logon-session of the domain administrator (LSA-secret).
- Interception NTLM-session (not considered because of the greater practical complexity).
Practice. Many Windows administrators use a domain administrator account to perform various kinds of operations on users' computers. However, its data is in the DCC cache. Therefore, first try to get the password from the DCC cache. We go to our workstation, save the registry branch HKLM \ Security and import it into . Because we have a local administrator password, you no longer need to boot the machine from external media to save the registry:
The cache is the password data of the three accounts. The last account (*** user) does not interest us, the second account does not have the required privileges, but the user shadmin looks like the desired administrator. Unfortunately, the MS-CACHE2 algorithm has a large computational complexity and brute force attack on it is ineffective. The MS-CACHEv2 function contains a “computational secret” - salt (the account name is used as “salt”), which makes it protected from attacks against Rainbow tables. However, in the future, tables of hash values for standard accounts - “Administrator”, “Administrator”, etc. may appear. For the sake of interest, we send the found “cache hash” to the cloud service  -  (on the results and effectiveness of such services at the end of the article). While the “cloud is thinking” we are trying to find other DCCs. Analyzing the list of hosts obtained in step 0, we check on which servers we can log in as local administrator using the passwords obtained in step 1. Since the local administrator is blocked on the domain controller and the mail server is usually better protected, it is necessary to experiment with secondary servers. In our case, in the list of servers a server was found with the inconspicuous name Upd. Logging in with the password “Pa $$ word2” found in step 1 is successful. We find out that on the host Upd: Logging in with the password “Pa $$ word2” found in step 1 is successful. We find out that on the host Upd: Logging in with the password “Pa $$ word2” found in step 1 is successful. We find out that on the host Upd:
- Antivirus software is not installed.
- It runs Apache, which is the management server for the corporate antivirus (this means that there is also an account password used for remote installation of the antivirus software and theoretically it can be pulled out from there).
- The host is not auditing failed login attempts.
- OS version - Windows 2008 R2.
Having dumped the HKLM \ Security registry, we get the DCC hash of the CORP.LOCAL \ Administrator account (and several others):
Theoretically, you can try to find the password to the Administrator via the cloud service. However, as I mentioned above, the brute force attack on MS-CACHEv2 is useless (although, perhaps, in a couple of years the situation will change). Leave DCC alone and proceed to search for Logon sessions. Checking which users are logged in on the Upd host:
We see that on the Upd machine there are two inactive sessions - the administrator and the user Shadmin already familiar to us, which means that we can get the NT hashes of their passwords by stealing the LSA-secret. This is the key point in determining the success of the entire attack. To steal a hash, use the Lslsass  exploit. To perform it, you need local administrator rights (or rather, debugging rights to processes), which we already have. We get the list of LSA secrets (in the format "domain \ account: LM-hash: NT-hash :::"):
lslsass v1.0 - Copyright (C) 2010 Bjorn Brolin, Truesec (www.truesec.com) Found Lsass pid: 520 Lsass process openFound possible primary token Foundreal token UPD\Administrator::00000000000000000000000000000000:<i>8833c58febc977799520e7536bb2011e</i>::: Found possible primary token Found possible primary token Found possible primary token Foundreal token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Foundreal token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Foundreal token CORP.LOCAL\UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Foundreal token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Foundreal token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Foundreal token CORP.LOCAL \Administrator::00000000000000000000000000000000: <b> c690e441dc78bc5da8b389e78daa6392 </b>::: Found possible primary token Foundreal token CORP.LOCAL \shadmin::00000000000000000000000000000000: <b> 5794cba8b464364eacf366063ff70e78 </b> :::
Bold lines contain the required password hashes. Also note the italicized hash in the sixth line. Somewhere we have already seen it, right?
Result. Success. We have on hand NT-hash of the domain administrator account password. But what is the use of a hash if it is impossible to recover the original password using it in a reasonable time? About this in the next step.
Step 3. We are deceiving the NTLM authentication session.
Theory. Windows never uses a pure password for authentication; an authenticated system always presents a hash. Hence the idea: replacing the user name, the login domain and the NT hash in the Logon session of the logged-in user with the corresponding values of the domain administrator, we can authenticate using the NTLM protocol before the remote system as the domain administrator. This attack  is possible only with NTLM authentication. Despite the widespread use of the Kerberos protocol, NTLM is the only possible way to authenticate a client, when accessing a network balloon not by a symbolic name, but by an IP address .
The object of attack. Logon session local administrator.
Practice.There are several available exploits that allow you to implement an attack on the Windows Server 2008 x86 and x64 platform. The main exploit is the Windows Credentials Editor . To launch an attack, we go to the host LAB2 using the “Administrator” \ ”Pa $$ word2” credentials. Using , we substitute the account name, the login domain and the NT hash data in the Logon session with the corresponding Shadmin values we obtained in the previous step:
The name of the domain administrator account and its NT hash is passed to the wce command as an argument from the command lines. Result - hash was successfully changed. I note that the user's membership in the group and the access token do not change during an attack:
We are still the local Administrator, the green host name in the screenshot above is LAB2. However, with NTLM authentication, the remote system will be shown the domain name CORP. LOCAL, the user name Shadmin and the hash of the password Shadmin. Here is a dump of a single network packet containing the security blob of the NTLM session: The
domain name (CORP.LOCAL) and the host name (LAB2) are smeared with green and the account Shadmin is presented. Now we are trying to connect to the root partition of the system volume on the domain controller using the net use command using the IP address of the domain controller:
Successfully. To check access, I created a text file in the root (find it in the screenshot). Having created a batch file on the disk of the domain controller with the sequence of commands we need, we can, using , perform the necessary operation on the domain controller (for example, add a user to the domain administrators group). The operation will be performed with the rights of the Shadmin account. To illustrate, we create a simple command file on a remote host that adds a local user:
net user TstUsr Pa $$ word / add
Remotely start it from the host LAB2:
It will be executed on the remote system 192.168.13.125 with the privileges of the user of our current session - shadmin (t. e., domain administrator). Checking:
The second output of the net user command shows the new user. Despite the fact that it is impossible to launch applications that require interactive user interaction (for example, MMC snap-ins) in this way, you can perform a wide range of actions using scripts.
Result. Success. Got access to the file system and the domain controller shell.
In short, the attack chain looked like this: Gathering information about the network structure -> Getting the local administrator password -> Using this password to log in to one of the secondary servers -> Theft of unattended domain administrator credentials -> Modifying your Logon session and elevation of privileges to the desired level.
The success of the attack contributed to:
- Weak DNS zone protection from transfer to untrusted hosts.
- Weak password policy. On most domain computers, the local administrator account used the same password, vulnerable to a dictionary attack.
- Absence or weak configuration of antivirus software on critical hosts.
- Weak password hash protection - two inactive administrator Logon sessions on the Upd host, presence of LM hashes in the SAM database.
- Poor audit policy.
Based on this, you can derive general protection recommendations:
0. Carefully hide the internal structure of the network from possible intruders. So, users should not be able to get the full contents of the DNS zone file. Untrusted users (it may be, for example, trainees, employees who have not completed the trial period, etc.) it makes sense to transfer to a separate subnet, using NAT to spoof addresses (including, for example, modifying DNS responses).
1. Proper local administrator password assignment policy. The local administrator password must be different on hosts that have different degrees of security from unauthorized access. Compromising the local administrator password on any of the domain hosts should minimize the possibility of an attacker using this password.
2. Storage of LM hash in SAM should be prohibited by security policies.
3. It is not necessary to use the name of the company or its domain as part of the administrator’s password. But even using a complex password, do not forget to regularly and regularly test his hash for resilience using online services.
4. It is not recommended to perform routine operations on domain computers under a domain administrator account. This will protect the account from intercepting Logon session data and from hitting the password hash into the DCC cache.
5. Make it a rule not to leave unattended a domain administrator's Logon session. Best practice: finished work - log out.
6. The LSA spoofing utilities are quite few. It makes sense to track their evolution and to check their successful detection by corporate antivirus software.
7. A user, even having local administrator rights, should not be able to change the settings of a corporate antivirus. Shutting down the antivirus service on domain workstations should trigger a domain administrator alert (in this sense, Symantec Endpoint Protection performed quite well during the test).
Addition 1. Behavior of antivirus software
Three types of antivirus software were used on the company's computers: KAV, which was current at the time of the Symantec Endpoint Protection test, and an outdated product from Trend Micro. In most cases, the tools used during the attack were identified as Hack Tool / Rootkit / Trojan. KAV without warning deleted them, and SEP (even turned off) issued a warning and moved to quarantine without giving the opportunity to run. However, the presence of local administrator rights allows you to disable KAV, and the protection of SEP was circumvented by manually setting the exception path for checking, again using the local administrator account. The Trend Micro antivirus installed on some hosts did not launch exploits in any way.
Addition 2. Efficiency of using online hash check services
To check the strength of password hashes, there are many online services. They allow you to work with the most common hashes - LM, NTLM, MD4, MD5, WPA, with hashes that use salt, etc. To verify the hash, brute force is used using the computational power of modern GPUs, dictionary searching, hybrid attacks, etc. Once opened, the hash can fill up the base and be used in the future. The service can be free to check a short (less than 8 characters) password or take a small reward. During the test, I used four such services, links are provided at the end of the article. I sent several of the hashes found in step 2 and after 15 months I received a notification from the On-line Hash Crack service  about successful recovery of one of them)
 Cain & Abel - a password recovery tool for Microsoft Operating Systems. It can be encrypted, it can be encrypted, it can be encrypted, it will be possible to record it. protocols.
 L0pht Crack.
 Lslsass exploit. Dumps active logon session password hashes from the lsass process.
 Windows Credentials Editor post-exploit. Tool to change logon-credentials.
 PsExec from the PS Tools Kit
Detailed Vulnerability Descriptions
 A series of articles “Efficiently obtaining password hashes in Windows” on the website www.securitylab.ru
 Pass-the-Hash, describing an attack on a remote system by providing it with a compromised hash.
Cloud services hacking hashes
 Question-defense.com (it seems to be already inoperable at the time of publication ()
 On-line hash killer
[12 ] Security and DNS Tuning in Windows Server
 Kerberos by IP Address