Conducting Red Team Assessments Without the Use of Malware

A Red Team Assessment (also known as an advanced penetration test or an attacker simulation) may sound like a group of cyber wizards hurling zero-day exploits, conducting man-in-the-middle attacks against SSL, and using highly advanced methods of data exfiltration. In practice, Mandiant has had great success conducting Red Team Assessments without using exploits or even malware.

In this post we will walk through a Red Team Assessment that we recently conducted during which no malware was used in the client environment – an approach that significantly reduced the likelihood we would be detected. In fact, the only tools we used in the environment were tools that we found within the client’s environment itself.

Our assessment began with a basic phishing campaign. This step is typically the most likely to be detected by a client; however, when conducted properly phishing can fly under the radar and evade detection by users and security teams. For example, we have conducted successful phishing attacks to obtain user credentials using both IT and compliance-themed email messages.

The phishing scenario we used in this case involved sending an email to chosen targets that ask them to conduct a security compliance check by visiting a URL hosted on a domain we control. When a user visits the URL, they are prompted for their Active Directory credentials to start the compliance check process. Figure 1 shows an example of this email.

Figure 1: Example IT-Compliance related phishing email

In parallel with our phishing campaign, we conducted a stealthy assessment of our client’s externally facing infrastructure. We noticed that although the client utilized two-factor authentication for their VPN, other externally facing services used only single-factor authentication. Two of these services were Outlook Web Access and a Remote Desktop Web Access server.

Using the Windows Active Directory credentials gathered from our phishing emails, we were able to authenticate to the Remote Desktop Web Access server, as shown in Figure 2 below. This application used only basic authentication and provided limited access to various applications including Internet Explorer, Windows Explorer and Remote Desktop. Although we could have chosen to “break out” of Internet Explorer and Windows Explorer in order to obtain command line access on the server, instead we leveraged our existing access to the Remote Desktop application to pivot to other internal hosts[1].

Figure 2: Gaining access to Remote Desktop using compromised credentials

The externally accessible Remote Desktop Web Access server, protected with only single-factor authentication, provided us with access to the client’s internal network from the Internet. Our next step was to escalate our privileges, since the credentials obtained from our phishing attack were non-administrative. We located a Domain Controller for our domain, and mounted its SYSVOL folder, which is shared by default on Domain Controllers to facilitate replication of Group Policy Objects, scripts, and other data.

Some versions of Windows previously allowed passwords to be stored using weak encryption in a Group Policy Object (GPO) through certain Group Policy Preferences. Although Microsoft issued a patch for the vulnerability in 2014[2], not all organizations have adopted their fix. A filename search for “groups.xml” (one of the affected Preferences files) yielded a result: a local administrator password encrypted using a known 32-byte AES key.[3] Our search and the resulting file with the encrypted password are shown in Figure 3.

Figure 3: Searching for “groups.xml” on the Domain Controller

The password in the XML file is AES-encrypted and base64 encoded. There are a number of ways to automatically decrypt the password. However, for the sake of illustration we have shown each step in Figure 4. The base64-encoded data must be padded, if necessary, to create a valid base64 string for decoding. The decoded data can then be decrypted using Microsoft’s AES key. The decrypted password is displayed in the red box on the right of Figure 4.

Figure 4: Decoding and decrypting the local Administrator password

Once we had local administrator access to client machines, our next step was to obtain clear text passwords from the Local Security Authority Subsystem Service (LSASS). A common way to accomplish this is to use the PowerShell command “Invoke-Expression” to download and execute the “Invoke-Mimikatz[4]” script over HTTPS. Because the incoming traffic is encrypted and the resulting script is run directly in memory, network intrusion detection systems and host-based anti-virus software will not typically generate any alerts. However, we were unsure whether our client, who previously told us they had “excellent” ingress and egress detection capabilities, had enabled SSL inspection.

With SSL inspection, an organization intercepts, decrypts, inspects, and then re-encrypts SSL traffic, allowing them to perform network detection on otherwise encrypted communications. If SSL inspection were enabled, there would be a greater possibility that the client would detect and alert on the download of a well-known PowerShell script that is now commonly blacklisted. Fortunately, we had previously discovered an “IT-tools” directory on the first host we accessed (“System A”) via the Remote Desktop Web Access server. The directory contained a copy of the Sysinternals  “procdump.exe” utility.[5] We executed procdump.exe with the ‘runas’ command and our local administrator credentials to get the memory dump of the LSASS process on the ”System A”, as shown in Figure 5.

Figure 5: Dumping LSASS with procdump

We then downloaded the memory dump from the client environment to our local attacker machine, and safely ran Mimikatz[6] to extract the clear text Windows credentials, as shown in Figure 6.

Figure 6: running Mimikatz on a local machine

With clear text Active Directory as well as local administrator credentials, our next step was to move laterally throughout the environment in search of more privileged Active Directory credentials, such as those for IT administrators, database administrators, or other relatively privileged accounts. We hoped, based on our experience, that we could find these types of privileged credentials on other systems in the environment.

Our local administrator account credentials were likely to be shared by at least some other hosts in the client environment. We had to identify additional live hosts on the network for which our gathered credentials were valid. One way to identify host names is to obtain DNS data from the client environment. However, some DNS enumeration techniques will generate security alerts. For example, attempting a full DNS zone transfer should, in a perfect world, always generate a security alert. In our experience, simple reverse hostname lookups, performed in limited quantities, are very likely to pass undetected. Using a quick one-line script to conduct reverse lookups we were able to enumerate some live hosts. Sample output from this script is shown in Figure 7.

Figure 7: Simple script for host enumeration with nslookup

Using DNS with a combination of netstat and arp output, we were able to find multiple live hosts and collect additional user credentials, including those of a database administrator (DBA). We were also able to identify Microsoft SQL servers, which make great targets for a red team as they often contain customer data as well as domain administrator credentials within the LSASS cache.

Our intuition proved correct – we discovered customer data stored in one of the MSSQL databases, which we accessed using the DBA account we had previously compromised. We also obtained domain administrator credentials from LSASS on the same system using the same combination of procdump and Mimikatz to dump process memory and extract clear text passwords, as discussed previously.

After gaining domain administrator credentials, we logged into the Domain Controller to generate a copy of all of the Active Directory password hashes for the domain using the Microsoft utility “ntdsutil”[7] as shown in Figure 8.

Figure 8: running ntdsutils to copy NTDS.dit

After running ntdsutil.exe, we had a fresh copy of the Active Directory database (NTDS.dit) and the SYSTEM registry hives. We archived and encrypted the data using native Windows commands. We then moved the file from the Domain Controller to “System A” over Microsoft’s SMB protocol. We then transferred the compressed data from “System A” to our local attacker box via our Remote Desktop connection. This activity is shown in Figure 9.

Figure 9: Flow of data from the domain controller to our local machine

Now that we had a local copy of NTSD.dit and the SYSTEM hives, we could use “secretsdump” from the Impacket project[8] to extract NTLM password hashes from those files. This analysis is shown in Figure 10.

Figure 10: Screenshot depicting execution of secretsdump.py

Finally, we began cracking the password hashes extracted by secretsdump. Given a large NTDS.dit file, little more than a basic dictionary is typically need to crack a large percentage of the users’ passwords. Figure 11 depicts the use of Hashcat[9] on a standard laptop to parse the output from secretsdump.

Figure 11: local analysis of NTDS.dit

Once we had parsed and cracked the hashes within the NTDS.dit we had clear text credentials for multiple Domain Admins, several IT administrators, several DBAs, and several members of our client’s IT security staff. This amount of credentials would provide us redundancy in the event that one account changed its password. The broad range of user accounts that we had also gave us full access to the client environment.

In this Red Team assessment, all we needed was a phishing campaign, built-in Windows tools, and some tools found locally in the client environment to go from initial access to domain administrator privileges and full Active Directory access. Red Teams and attackers alike may prefer to leverage tools found in client (or victim) environments, including security assessment tools; if those tools have a legitimate use within the environment, any alerts generated by the presence or use of those tools may be ignored. This process of “hiding in plain sight” allows a Red Team to move quickly through networks with little need for malware or exploits.

What should you take away from this blog? Skilled attackers do not always leverage advanced malware, if they do not see the need. In addition, a fully patched environment does not indicate an immunity to attackers. Finally, proactive security audits and auditing in general for anomalous “legitimate” user behavior is just as important as responding to alerts generated on security events.

 

[1] Quick tip: oftentimes setting a destination of 127.0.0.1 will let you remote desktop into the server itself!
[2] For more information see https://support.microsoft.com/en-us/kb/2962486
[3] The key published by Microsoft is available at https://msdn.microsoft.com/en-us/library/Cc422924.aspx
[4] Invoke-Mimikatz is a PowerShell implementation of Mimikatz.exe, which is a password stealing software. Invoke-Mimikatz is part of the larger PowerSploit project.
[5] https://technet.microsoft.com/en-us/sysinternals/dd996900
[6] https://github.com/gentilkiwi/mimikatz
[7] https://technet.microsoft.com/en-us/library/cc753343.aspx
[8] https://github.com/CoreSecurity/impacket
[9] https://hashcat.net/oclhashcat/