The main aim of this article is to show how much it is important to keep systems up to date with the latest Security patches; in particular, this post is about Security in corporate Windows environments.

Active Directory

Generally, in companies with a discrete number of Windows systems, it is common to set up a domain using a system called Active Directory. Basically it implements a number of processes and services which, among the other things, simplify the management of Windows user accounts inside a domain network so as to handle them in a centralized way.

A server which runs Active Directory Domain Services takes the name of Domain Controller (DC): through its configuration it is possible to define rules and policies which are applied to users and computers belonging to the domain.
An account with administrator privileges over the domain belongs to the Domain Admin group: it has administrator rights over all the machines registered to the domain, even on the DC.
Once you have administrator privileges on the domain you can essentially do everything you want; this is why it is important to secure the domain in such a way that only a restricted group of authorized accounts (that really needs them) have those rights.

Another important aspect about the Domain Controller Security is that, while passwords for local users are stored inside the machine they have been defined in, passwords for domain users are stored on the DC itself.

Virtual Laboratory

To simulate the attack to the domain, we can setup an Active Directory virtual laboratory environment with a Windows Server 2012 R2 acting as Domain Controller and a Windows 7 SP1 64-bit client in order to emulate an employer workstation registered to the domain.
On the Windows 7 machine it is installed an old version of Java Runtime Environment, Java 6 Update 23, which is affected by a series of Remote Code Execution (RCE) vulnerabilities; moreover the OS misses a Security patch for MS15-051 vulnerability which allows Local Privilege Escalation.

The attacker will use the distro Kali Linux on which it is installed by default the notorious Metasploit Framework. After an initial Information Gathering during which he discovers Java 6u23 installation on client workstations, he starts the attack.

We can begin by launching PostgreSQL service in order to use Metasploit database:

root@kali:~# service postgresql start

Then we can power up Metasploit console:

root@kali:~# msfconsole -q
msf >

Java Client-side Exploitation

Among all the vulnerabilities affecting Java 6u23, we can use Java storeImageArray() Invalid Array Indexing Vulnerability. Through the info command we can take a look at the description that reports a lot of useful informations like the list of platforms affected, reliability Rank, vulnerability disclosure date, module authors, Common Vulnerability and Exposures (CVE) identifier and, of course, the options we need to set up to run the exploit:

This kind of exploits starts a webserver and hosts the malicious code on a webpage, so, when the victim visits the url, it executes.
Looking at the options, we have to set up the TARGET system, which is Windows, and the URIPATH that represents the last part of the malicious url address.
Moreover, we need to set the PAYLOAD type, which represents the program we can execute thanks to the RCE vulnerability: it is a good idea to choose Meterpreter payload since it offers a huge quantity of features to control the remote host; furthermore we choose it in order to set up a reverse tcp connection so as to bypass Firewall protection: reverse_tcp Meterpreter.

Another good payload, which is even more reliable in highly secured environments, is the reverse_http(s) one: in fact, “instead of a stream-based communication model, this stager provides a packet-based transaction system” (take a look to the reference at the end of this article if you want to know more about it). Of course it supports the same features of the reverse_tcp we are using here.

Once the payload is selected, we set up the IP address (LHOST) and the port (LPORT) to which we want the victim machine connects back to (in this case our host):

Generally attackers trick victims into opening links by using Social Engineering techniques: for example, a possibility is to send an email to the target by impersonating the company IT Security Team and inviting the user to visit a url in order to download an important Security patch:

So, when the victim visits the webpage the Java exploit executes and the attacker obtains a remote connection, i.e., a meterpreter session on the victim machine:

We have an established connection between the attacker machine with IP address 192.168.1.10 and the victim machine with IP address 192.168.1.208; this connection starts from the victim machine and connects back to the attacker one using port 443. Choosing this port was not random: a connection of this type will be less suspicious since it mimics an ordinary SSL session like if the user is just visiting a webpage in HTTPS.
Beware that this exploit works both on Internet Explorer (version 8 in this test) and Mozilla Firefox (of course Java plugin must be active).

Post Exploitation

Starting the interaction we may want to acquire system informations, like architecture, domain name, user ID and so on; sysinfo command is what we need:

We see that we are controlling a Windows 7 machine and the meterpreter is running inside a process owned by the user “testuser1” which is registered to the domain NET.
Another interesting information is given by system architecture that is 64-bit while the meterpreter is x86, i.e it is running on a 32-bit process: this means we have to migrate to a 64-bit process in order to use the meterpreter properly.

Before doing that, we can gather additional informations using Metasploit post exploitation modules. For example, it would be useful to know what kind of privileges the current user has got, like being in the Local Administrators group:

As reported the user has not Administration privileges, which means bad news for the attacker: in fact, a good Security practice is to set policies for employers workstations in such a way they do not have local Administrative privileges on their own machine (of course this has also to be followed by the application of Security patches as we will see afterwards).

Another smart move could be to acquire the IP address of the Domain Controller:

Enumerating Domain Admin accounts is for sure a good idea since they are interesting targets due to their privileges:

msf exploit(enum_domain) > use post/windows/gather/enum_domain_group_users
msf post(enum_domain_group_users) > info
Name: Windows Gather Enumerate Domain Group
Module: post/windows/gather/enum_domain_group_users
Platform: Windows
Arch:
Rank: Normal
Provided by:
Carlos Perez <carlos_perez@darkoperator.com>
Stephen Haywood <haywoodsb@gmail.com>
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
GROUP yes Domain Group to enumerate
SESSION yes The session to run this module on.
Description:
This module extracts user accounts from specified group and stores
the results in the loot. It will also verify if session account is
in the group. Data is stored in loot in a format that is compatible
with the token_hunter plugin. This module should be run over as
session with domain credentials.
msf post(enum_domain_group_users) > set group "domain admins"
group => domain admins
msf post(enum_domain_group_users) > set session 1
session => 1
msf post(enum_domain_group_users) > exploit
[*] Running module against WIN7SP164
[*] Found users in domain admins
[*] NET\boss
[*] Current session running as NET\testuser1 is not a member of domain admins
[*] User list stored in /root/.msf4/loot/20160906195451_default_192.168.1.208_domain.group.mem_774905.txt
[*] Post module execution completed

The results are telling us that we have only one Domain Admin user: “boss”. Remember this account, because it will be useful later.
Keep in mind that we could have gathered these informations also by dropping the meterpreter session to a Windows command shell: for example, to find the list of Domain Admins users the command would be net groups "domain admins" /domain.

Going back to the 32/64-bit architecture topic, we need to migrate the meterpreter to a 64-bit process: for this purpose we can list all the processes running on the machine and choose a 64-bit one:

Note the process with PID 1992 associated to the “.exe” payload file located in the Temp directory: this is the one the meterpreter is currently running on.
Generally, migrating to “explorer.exe” is a good choice, so we use its PID as parameter to the migrate command:

The main concern now is that, even if we are able to read and write files inside the contest of the current user “testuser1”, we want to acquire a privileged access to the machine, i.e. we want to gain Administrator rights.
For this purpose we can analyze what Security patches are installed on the system in order to find if there are unpatched privilege escalation vulnerabilities. By doing this we can drop down to a Windows command shell and use the “wmic” utility:

The output shows clearly that in this company Windows System Administrators are not frequently updating clients workstations.
For example, we have discovered that the KB to the MS15-051 vulnerability is missing, so we can exploit it. This vulnerability affects Windows Kernel-Mode drivers allowing RCE, so it is possible to perform a Local Privilege Escalation, i.e. we can elevate the rights of our meterpreter session, which runs with “testuser1” privileges, to NT AUTHORITY\SYSTEM:

Analyzing collected credentials we find the following fields: a username and two strings separated by the colon symbol; these two represent the encrypted password for that user.
Windows credentials are stored using hashing algorithms: the first part of the hash represents the LAN Manager (LM) hash. The LM authentication protocol has been disabled by default starting from Windows Vista and Windows Server 2008 since it was really unsecure; this is why the string “aad3b435b51404eeaad3b435b51404ee” represents an empty value (remember we are on a Windows 7 machine).
The second part represents the NT LAN Manager (NTLM) hash: NTLM is the successor of the LM protocol, but it is still vulnerable to password cracking attacks. This is why we can use the password cracking tool John The Ripper in dictionary attack mode to find the corresponding plain text password.

Since NTLM hashing function is well known it is possible to compute in advance for a given word the corresponding hash; moreover it is symmetric so we have a one-to-one correspondence betweeen words and hashes. So, defining f as the hashing function and x as the plain text password, we have that y = f(x) returns the computed hash.

A dictionary attack works in a simple way: we have a file with a list of words (this is why these files can be found under the name of “wordlists”); for each word we generate the corresponding NTLM hash and then we compare it with the one we want to crack. Once we find the one that matches, we are sure we have found the password.

It is always a good idea to start with a dictionary attack instead of a brute force attack, since generally people set common words as their password and in that case we can accomplish our task pretty rapidly.

We are interested in the Administrator account, so we start by saving its details, i.e. username and corresponding NTLM hash, in a text file:

Then we can launch the tool by specifying the hashes format and the dictionary file we want to use to crack the hashes (“rockyou” wordlist is included by default in Kali Linux inside /usr/share/wordlists folder):

JTR has successfully found the password for the Administrator account: “password1”.
Considering the worst case for the attacker, we suppose that the local Administrator password is different in every client belonging to the domain (otherwise he would already had access to every machine without performing any further action).

Token Impersonation

In this case there are different ways to move on; for example we can proceed by using a technique called “Token Stealing” or “Token Impersonation”.
In Windows, everytime a user tries to log in, the system verifies that user’s password is correct by matching it with the one stored in the Security database: this is called “authentication process”. When the process succeed, the system generates an access token. Tokens can be seen as a temporary key so every process executed in the context of that user does not need to request the password again to run with user’s privileges: these are called “Delegation Tokens” and they persist on the system until next reboot. In fact, a user log off does not invalidate the token, but the token itself will be reported as an impersonation token instead of a delegation one.

If a user connect to the compromised machine, it is possible to steal its relative token. This task can be performed with a Metasploit extension called Incognito.
Taking a look at the output of the “credential_collector” module used before, we see there are reported also informations about tokens. Now, supposing a Domain Admin logs on the controlled machine, we should see a delegation token for that user from the list_tokens command part of Incognito extension:

In particular, we can give Domain Admin rights to the just created user “evilboss”:

C:\Windows\system32>net group "Domain Admins" evilboss /add /domain
net group "Domain Admins" evilboss /add /domain
The request will be processed at a domain controller for domain net.testlab.
The command completed successfully.

Now we have our own Domain Admin user through which we have administrative access to every machine registered to the Domain; that said, a good target is represented by the Domain Controller which stores all domain users NTLM hashes.
To log on the DC we can use the “psexec” module:

C:\Windows\system32>^C
Terminate channel 1? [y/N] y
meterpreter > background
[*] Backgrounding session 2...
msf exploit(credential_collector) > use exploit/windows/smb/psexec
msf exploit(psexec) > info
Name: Microsoft Windows Authenticated User Code Execution
Module: exploit/windows/smb/psexec
Platform: Windows
Privileged: Yes
License: Metasploit Framework License (BSD)
Rank: Manual
Disclosed: 1999-01-01
Provided by:
hdm <x@hdm.io>
Royce Davis <rdavis@accuvant.com>
RageLtMan <rageltman@sempervictus>
Available targets:
Id Name
-- ----
0 Automatic
1 PowerShell
2 Native upload
3 MOF upload
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
RHOST yes The target address
RPORT 445 yes The SMB service port
SERVICE_DESCRIPTION no Service description to to be used on target for pretty listing
SERVICE_DISPLAY_NAME no The service display name
SERVICE_NAME no The service name
SHARE ADMIN$ yes The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
SMBDomain . no The Windows domain to use for authentication
SMBPass no The password for the specified username
SMBUser no The username to authenticate as
Payload information:
Space: 3072
Description:
This module uses a valid administrator username and password (or
password hash) to execute an arbitrary payload. This module is
similar to the "psexec" utility provided by SysInternals. This
module is now able to clean up after itself. The service created by
this tool uses a randomly chosen name and description.
References:
http://cvedetails.com/cve/1999-0504/
http://www.osvdb.org/3106
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
http://www.accuvant.com/blog/2012/11/13/owning-computers-without-shell-access
http://sourceforge.net/projects/smbexec/

This module takes as inputs the Domain name, a valid administrator username and password (no matter if plain text or hashed) and the destination host we want to log in. It connects to the Samba share specified on the target machine.

Similarly to what we did for Local Administrator password, we can use JTR to crack this NTLM hashes.

Remediation

This article has shown how much it is important to keep systems up to date; by doing this it is important to take care not only about Operating System Security patches, but also about the software installed on it.

Referring to this particular article scenario, the actions needed to secure the system are reported below:

Update Java to the latest version released so as to get rid of the CVE-2013-2465 and othere Java related vulnerabilities;

Regarding Microsoft Windows access control model based on tokens, keep in mind that this is how Windows handles the authentication so it cannot be considered a vulnerability. This means that in order to secure the environment the countermeasures are more about processes and procedures. This is why it is important to follow Security best practices; here is a list of Security rules it is good to follow to lower the risk level related to token impersonation attacks:

Limit number of Domain Admin accounts

Users with Domain Admin account must use their unprivileged account for standard use;

Create administrative groups with access restricted to their competence area (for example, development, test and production groups) so as to limit possible data breaches.