From OSINT to Internal: Gaining Domain Admin from Outside the Perimeter

September 11, 2018, Esteban Rodriguez, Consultant, Coalfire Labs, Coalfire

When I first began working at Coalfire in early 2017, I couldn’t wait to get started pentesting professionally for the first time. When I finally got tasked with my first gig, I dove right in. I was tasked to perform an assessment of the external network. After hitting all known servers and web applications with various scanning tools, I had nothing. For a penetration tester, the assessment does not end here.

I began to search open source information such as database breaches, as they can often yield many reused passwords. Using the dump from the 2012 LinkedIn breach, I searched through the database to collect credentials related to my target organization. To find the target emails, I ran the command:

grep [DOMAIN] 1.sql.txt

This brought up any email address in the dump that matched the domain of my client.

Once completed I had a list of email addresses from my target organization, but not the hashes. In the LinkedIn dump there is a number next to the email address. This is the member ID. After collecting all the member IDs from the records that were returned, I grepped through each of the remaining test files for instances of each identified member ID. I used the command:

grep -E "[MEMBER ID]:|[MEMBER ID]:" *.txt

Now that I had (Member Email + Member ID) and (Member ID + SHA1 hash) I could correlate these two data sets to identify the member email and its corresponding SHA1 hash. I took all the SHA1 hashes and used the hashes.org search to query up to 100 SHA1 hashes at a time. (At the time of this writing, hashes.org has the SHA1 hashes for the LinkedIn breach 97.96% cracked.) This gave me a list of emails and passwords for LinkedIn users who signed up to LinkedIn with their work emails.

One thing I looked for is the use of ADFS (Active Directory Federation Services). The reason this was valuable to me is that it exposes an interface you can use to authenticate against Active Directory for the target via the internet. A common service that is exposed for many organizations is Outlook Web Access (OWA). By visiting https://outlook.office.com, I could just type in any email using the target domain and it would redirect me to the organization’s OWA landing page.


click to enlarge image

After discovering the OWA endpoint, I began testing credentials. I did this via Burp Intruder. The only missing information I needed to know was the domain name of the company. I took an educated guess that it was just their company name.

I used the Burp Suite “Pitchfork” option within Intruder and added payload markers on both the username and password of a standard authentication request. 


click to enlarge image

I loaded up a list of usernames for payload set 1 and a list of corresponding passwords for payload set 2. After comparing the responses from the attack, I was able to determine that I had a valid username and password pair for one user.

Access to an employee email account could have been valuable by itself, but in this case, it could be leveraged further to achieve code execution. At the time of this attack a technique existed to leverage Microsoft Outlook rules to execute arbitrary files from the internet. While this no longer works with up-to-date versions of Outlook, you can read more about the technique here.

To start the attack, I first opened Microsoft Outlook on my own computer and navigated to: File -> Add Account


click to enlarge image

I then used the compromised email account credentials from the earlier password spraying attack.

To create a payload, I used PowerShell Empire. I used Empire to generate a “launcher_bat” stager. Once I had the .bat file, I modified it slightly to remove the self-deleting functionality.

After creating the .bat file, I converted it to an .exe using a Bat to Exe Converter. This allows me to avoid the terminal window popping up on the user’s screen when the payload was executed.


click to enlarge image

After creating the .exe payload, I needed to host it online. The quickest way I have found to do that was by hosting it with WebDAV. I set it up on an Ubuntu server by using the commands below.

First, I updated the packages and installed an Apache server.

root@Attacker:~# apt-get update
root@Attacker:~# apt-get install apache2

The next step was to create the WebDAV directory.

root@Attacker:~# mkdir /var/www/webdav
root@Attacker:~# chown -R www-data:www-data /var/www/

I then needed to add some webDAV modules:

root@Attacker:~# a2enmod dav
root@Attacker:~# a2enmod dav_fs

I needed to edit the Apache configuration file.

root@Attacker:~# vi /etc/apache2/sites-available/000-default.conf

I then added the following line on the top:

DavLockDB /var/www/DavLock

And the following line on the bottom:

Alias /webdav /var/www/webdav
<Directory /var/www/webdav>
DAV On
allow from all
</Directory>

I saved the file and restarted Apache. I then placed the payload in the webDAV directory.

In Microsoft Outlook, I needed to create a rule to run an application when a condition is met. Unfortunately, when I went to create a rule to run an application located on my webDAV server, I got this error:

At the time, Microsoft was aware of the danger posed by creating a rule that executes an application from the web and did not allow me to create it. Fortunately, a workaround was available. By importing an existing rule, I could avoid this check. To create the rule that I imported, I used Rulz.py

The output of the Python script gave me a .rwz file that I could import into Microsoft Outlook. To import the rule, I went to Rules -> Manage Rules and Alerts -> Options -> Import Rules within Outlook. Once the rule was imported, I modified the rule conditions to auto-delete the trigger email after being received.

To complete the attack, I had to wait for the client to load the Microsoft Outlook Application on their own workstation. The new rule would automatically sync to their computer. Once the rule conditions were met, the host executed the payload.

Much to my surprise, the client had local administrator permissions on their computer and was also connected to their corporate VPN. After dumping the local Administrator hash via Mimikatz, I then used that hash to authenticate to other systems within the corporate domain through the established VPN tunnel. This quickly led to me gaining access to Domain Administrator credentials.

It wasn’t long after that Microsoft began to stop the malicious mail rule attack completely, but even after that, variants of this technique began to pop up, this time using Outlook forms instead of Outlook rules. This too was eventually squashed by Microsoft, but not until months after the technique was published. 

While the techniques presented here no longer work on current software versions, it does go to show that by looking beyond the scan results, a determined attacker can quickly turn a relatively “clean” vulnerability scan into complete domain compromise. 

Esteban Rodriguez

Author

Esteban Rodriguez — Consultant, Coalfire Labs, Coalfire

Recent Posts

Post Topics

Archives