Owning Computers Without Shell Access

By Royce Davis ·

Introduction

What’s This All About? Consultants often upload and execute a binary payload to a remote system during penetration tests for the purpose of footprinting the target, gathering information, and leveraging that information to compromise additional hosts. When the scope of the engagement calls for the consultant to remain stealthy and undetected throughout the assessment, uploading a shell to your target is potentially catastrophic. My colleague Eric Milam created the SMBExec project to avoid this type of disaster.

Eric’s tool takes advantage of native Windows functionality and SMB authentication to execute commands on remote Windows systems without having to upload a payload to the target. This decreases the likelihood of being stopped by an Anti-Virus (AV). Eric first created SMBExec with the intent to upload obfuscated payloads that don’t contain the same signatures as the default payloads generated by the Metasploit Framework. Since then, he has expanded its capability to do more including dumping local and domain cached password hashes and stealing the NTDS.dit file from a Windows Domain controller.

SMBExec is a great tool with many powerful features; however, I wanted to see if I could improve upon SMBExec by integrating the functionality into the Metasploit framework. The main advantages of integration includes taking advantage of the native threading capabilities within the Metasploit Framework and interoperating with Metasploit’s auxiliary modules. Additionally, since Metasploit is a tool that I use often, the prospect of giving back to the community was exciting.

With a lot of patience, hard work, and some help from several knowledgeable programmers, we were able to create four auxiliary modules and one standalone tool. These modules and the tool can accomplish everything that made SMBExec great, with the advantage of being integrated into Metasploit.  The best part is that none of these tools require you to upload any binaries to your target, making them extremely difficult to detect and defend against using AV solutions.

Command Execution – command.rb

What Does It Do? For a pentester, one of the basic and most fundamental needs for attacking a computer system is the ability to execute commands on the target. The first module, “/auxiliary/admin/smb/command.rb,” serves that very need. This module takes a username and password (or password hash) and authenticates to one or more systems over SMB, then executes a single Windows command on the target via DCERPC. We do not upload any binaries to the target, so we shouldn’t be detected by AV engines.

But How Is This Possible? Think about Metasploit’s /exploit/smb/psexec.rb module. It builds a binary executable, authenticates to a target over SMB, uploads the binary executable, and finally, spawns a Windows Service that launches the executable with SYSTEM level privileges. The problem is AV engines often detect the binary file that is uploaded to the target.

Instead of uploading a binary to the target, we can make a call to one that already lives on the remote host, “cmd.exe.” Windows systems have shipped with cmd.exe since Windows 2000. An AV engine won’t complain about cmd.exe since it’s a trusted component of the operating system. We can use the /C parameter when calling cmd.exe to execute a single Windows command on the target with the security context of the provided user.

Using command.rb Using command.rb

(command.rb source code: Here)

Dumping Password Hashes – hashgrab.rb and cachegrab.rb

Current Techniques The current methods used within Metasploit for extracting password hashes work almost every time, provided you have admin access. The two most common reasons for failure are User Access Control and AV engines. We can address both issues simultaneously by dumping the hashes using a registry backup using Windows’ built-in tool “reg.exe.” Once we transfer the backup, we can isolate the password hashes. Since we never used a malicious binary, we avoid AV engines entirely.

Using hashgrab.rb Using hashgrab.rb

(hashgrab.rb source code: Here)

The hashgrab.rb module pulls down copies of the SYSTEM and the SAM hive and stores them in the /tmp/ directory. The password hashes are then extracted from the hive files.

Note: Use cachegrab.rb For Cached Domain Hashes

Using cachegrab.rb Using cachegrab.rb

(cachegrab.rb source code: Here)

Usually, cached domain hashes can be broken with a good dictionary file and a little luck. On rare occasions you might even find clear-text Domain Admin credentials. With cachegrab we can retrieve these cached domain hashes without uploading any foreign binaries to the target.

Dumping All The Hashes – ntdsgrab.rb

The NTDS.dit File Ultimately, the Holy Grail of most penetration tests are the Windows Domain Controllers, where you will find an ESE (Extensible Storage Engine) database file named “NTDS.dit.” This database contains useful information such as AD password hashes that can be forensically extracted via Libesedb.

Obtaining a copy of NTDS.dit can be tricky as it is opened for exclusive access by the operating system.  However, you can make a Volume Shadow Copy of the %SYSTEMDRIVE% with a native Windows tool “vssadmin” and retrieve the file without issue. Of course this technique is well known and documented, but it’s great to have a Metasploit module that implements the technique without foreign binaries. In Figure 4, you can see ntdsgrab.rb in action.

Using ntdsgrab.rb Using ntdsgrab.rb

(ntdsgrab.rb source code: Here)

What’s Happening? When looking at the console output in Figure 4, we can see that a Volume Shadow Copy was successfully created for us on the target system within the path located at ‘\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy47.

Once the Volume Shadow Copy is made, we can simply copy the version of NTDS.dit from the VSC to the WINDOWS\Temp directory. If we take a look at the specified log directory, we can see that the files have been successfully downloaded to our machine as shown in Figure 5.

Local directory on attacking machine Local directory on attacking machine

Getting What We Came For There’s already a great article on exporting the necessary tables from NTDS.dit using Libesedb. The article talks about using a really cool tool called NTDSXtract to retrieve information from the exported tables, including the AD user account password hashes. In order to integrate all of this functionality within metasploit, I wrote a simple ruby script that produced a JTR compatible format for extracting the password hashes from the exported datatable. The script is in the MSF/tools directory and is quite useful. The program only needs the path to the exported datatable and the path to the SYSTEM hive file as arguments.

using ntds_hashextract.rb using ntds_hashextract.rb

Simply run the tool with the proper arguments to get all of the password hashes to all of the AD accounts.

using ntds_hashextract.rb 2using ntds_hashextract.rb 2

(ntds_hashextract.rb source code: Here)

Wrap Up

All of the functionality works without uploading any binaries to the target host. Additionally, since everything is done via native Windows commands, it is very unlikely that AV engines will generate any red flags.

Since these tools are seamlessly integrated into metasploit, they can improve your efficiency while conducting penetration tests. The ‘command.rb’ module is great for performing Windows-based enumeration tasks such as querying the Domain Admins group members or searching systems for potentially sensitive information. The ‘hashgrab.rb’ and ‘cachegrab.rb’ modules work well together download hashes from a large number of systems, decreasing the amount of time it takes to determine the systems that Domain Admins access.  Finally, ‘ntdsgrab.rb’ and ‘ntds_hashextrac.rb’ help ensure that once you’ve compromised an Active Directory (AD) server you can dump all of the password hashes.