Privilege escalation in a Windows environment

Information Security Management Practice: pentest

User privilege escalation to Windows domain administrator level

Introduction

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 protection before a real attacker detects them. Any hacking tools, exploits, methods, etc. available in real life 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 the Microsoft Windows domain to the domain administrator level. The article was based on a report on the results of the 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, the article may be useful to novice system administrators to better understand the methods of protecting credentials in the Windows environment.

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, a terminal server, and some other auxiliary servers running Windows and Linux. Separately, it is worth noting a 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).
')

Intruder Model

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 violator and the description of the company are quite typical.

Attack implementation

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. Since 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 [12] 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 nbtstat, telnet utilities, as well as any of the common vulnerability scanners, an intruder can gather 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 value of the hash function stored in the system registry. Despite the fact that mathematically the hash function is irreversible, the password can be calculated by directly iterating through its values ​​along 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 stored in the Windows XP / 2003 OS registry, which makes these systems especially attractive for 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 the 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 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 [1], [2] (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 received NT- and LM-hashes. But how to recover from them the password? To do this, use the same tools [1], [2] as well as on-line hash reverse services [8] - [11]:



Note: the real password consisted of the name of the company with a small modifier and quickly broke down under a 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, login domain 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. In addition, 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, we 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 [1]. Since we have the local administrator password, you no longer need to boot the machine from external media to save the registry:



In the cache are the password data of 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 [8] - [11] (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. We analyze the list of hosts obtained in step 0, check for 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, you need 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 discover that on the host Upd:

1. Antivirus software is not installed.
2. 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).
3. The host is not auditing failed login attempts.
4. OS version - Windows 2008 R2.

By dumping 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 through 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 already familiar user Shadmin, 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 [3] 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 open Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:<i>8833c58febc977799520e7536bb2011e</i>::: Found possible primary token Found possible primary token Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Found real token CORP.LOCAL\UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \Administrator::00000000000000000000000000000000: <b> c690e441dc78bc5da8b389e78daa6392 </b>::: Found possible primary token Found real 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 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 [7] 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 its symbolic name, but by its IP address [13].

The object of attack. Logon session local administrator.

Practice. There are several exploits available that allow you to implement an attack on the Windows Server 2008 x86 and x64 platform. The main exploit is the Windows Credentials Editor [4]. To launch an attack, we go to the host LAB2 using the “Administrator” \ ”Pa $$ word2” credentials. Using [4], we substitute the account name, login domain and 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 line. Result - the 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 username Shadmin and the hash of the password Shadmin. Here is a dump of one network packet containing an NTLM security blob session:



Smeared with a green domain name (CORP. LOCAL) and host name (LAB2)), 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 [5], 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 run it from 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 (i.e., the domain administrator). Checking:



The second output of the net user command shows the new user. Despite the impossibility of launching 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.

Summary

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:

1. Weak DNS zone protection from transfer to untrusted hosts.
2. Weak password policy. On most domain computers, the local administrator account used the same password, vulnerable to a dictionary attack.
3. Absence or weak configuration of antivirus software on critical hosts.
4. Weak password hash protection - two inactive administrator Logon sessions on the Upd host, presence of LM hashes in the SAM database.
5. Poor audit policy.

Based on this, general protection recommendations can be derived:

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 (this may be, for example, interns, employees who have not had a trial period, etc.) it makes sense to transfer them 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. This will make it more difficult for an attacker to attack a dictionary. But even using a complex password, do not forget to regularly and regularly test its 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 in 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. LSA spoofing utilities are quite small. 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 the corporate antivirus. Shutting down the antivirus service on domain workstations should trigger a domain administrator (in this sense, Symantec Endpoint Protection performed quite well during the test).

Appendix 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 defined 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 start. 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 to check, 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 check 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 hashes found in step 2 and after 15 months I received a notification from the On-line Hash Crack service [9] about successful recovery of one of them)

Links

Tools used

[1] Cain & Abel - a password recovery tool for Microsoft Operating Systems. It can be encrypted, it can be encrypted, it will be possible to record it, it will help you to learn how to use it. protocols.
[2] L0pht Crack.
[3] Lslsass exploit. Dumps active logon session password hashes from the lsass process.
[4] Windows Credentials Editor post-exploit. Tool to change logon-credentials.
[5] PsExec from PS Tools

Detailed descriptions of vulnerabilities

[6] Series of articles "Effectively obtaining password hashes in Windows" on the site www.securitylab.ru
[7] Pass-the-Hash, describing an attack on a remote system by providing it with a compromised hash.

Cloud services hacking hashes
[8] Question-defense.com (seems to be no longer operational at the time of publication ()
[9] www.onlinehashcrack.com
[10] www.cloudcracker.com
[11] On-line hash killer

Additional materials

[12] Security and DNS Tuning in Windows Server
[13] Kerberos is not used when you connect by using IP address