English
I did an external network pentest for a client a few weeks back that led to some decent pwnage, and as if writing the report wasn’t tiring enough, I decided to do a blog post as well. Go figure.
“An external network pentest without thorough open source intelligence gathering is just a glorified vulnerability scan.” OK, who am I quoting? Well, actually I just made this up. But with that in mind, let’s get started!
The test was a typical external network pentest—the client provided me only with the company name and some scope restrictions. I started off by gathering information manually to get an idea of their Internet footprint. After achieving some familiarity, I switched to automated reconnaissance (recon)—I won’t go into details on the intelligence gathering process, since it has already been covered widely elsewhere.
There are many great open source tools available that automate the whole recon process. I like to use the following:
Recon-ng
Datasploit
FOCA
Additionally, digging for more data by reviewing as many publicly available resources, such as discussion forums, social networking sites, coding platforms like Github (look at Gitleaks), and password dumps can yield crucial information.
At the end of this process, I was able to gather a ton of information, including domain names, subdomains, netblocks, host names, contact details, email IDs, first/last names, titles, administrative interfaces, code snippets, leaked passwords (that of course did not work), and so on.
During the recon phase, I discovered that the client uses Office 365 and identified the link to their OWA. I had already gathered some work email IDs, but in order to maximize my chances, I wrote a small Ruby script that parsed LinkedIn to extract the first/last name and title of everyone working at that company. From my initial recon, I already knew the company’s email ID pattern. So I expanded my script to construct email IDs, using the first and last names. At this point, I was privy to around 850 email IDs, aka domain usernames (in most cases). Given that I had this information, combined with the knowledge that “P@ssword1” is obviously a strong password, I decided to launch a horizontal brute-force attack against OWA. I used SensePost’s Ruler (https://github.com/sensepost/ruler) to perform the attack.
That password got 11 hits, which was a bit disappointing, since I was expecting more users to comply with the “complex” password policy.
But on the bright side, I had credentials for 11 domain accounts. I could log on to their respective OWA and read through their emails. I checked through my recon notes but did not find any other obvious way to gain access to the internal network. I then fired up my Windows virtual machine, configured one of the compromised accounts in my Outlook client using the auto discover feature, and pulled down that account’s emails. There are a couple of reasons why I did that.
First, I wanted to create a malicious Outlook rule for that user. I configured this rule to be triggered upon receipt of an email with subject “Weekend.”
Once triggered, this rule would pull my malicious binary “rule.exe” from a remote server and execute it. Rule.exe was a PowerShell Empire payload binary, which would then spawn a https reverse shell talking to my server. As a result, I was able to compromise 4-5 hosts on the internal network. The whole process of exploiting malicious Outlook rules is explained very well here:
https://silentbreaksecurity.com/malicious-outlook-rules/
htttp://www.blackhillsinfosec.com/?p=5465
The other reason I configured my Outlook mail client with one of the compromised accounts—and I don’t know why I never thought of this before—is that Outlook allows you to export all your contacts. With nothing more than access to someone’s Outlook account, you can export their GAL (Global Address List), access ALL the associated internal domain names, and relaunch the horizontal brute-force attack for more pwnage. You may also get access to Exchange Public Folders and any shared mailboxes for another easy win. This may not make sense here, since I already had a shell on the internal host, but things seldom run as smoothly in a real-world pentest as in a blog post, and you’re always hunting for more information.
To export all the contacts from GAL, you would have to add them to your contacts first. Select all the contacts in GAL, right-click and select “Add to contacts”. Some versions of Microsoft Outlook do not provide the option to “select all”. In that case, you’d have to use your “Shift + Down Arrow” key to select all the contacts in GAL. I was sitting at around 57,000 contacts in that list, so I had to be creative. I handled it with a lighter and an external disk drive:
(Fun fact: Using the compromised credentials with the Microsoft Outlook client in most cases also bypasses two-factor authentication, since that is commonly applied to web-based resources only.)
The malicious Outlook rule attack was cool, but it was a lot of work. You have to create one rule per mailbox, send a trigger email, then wait and pray for the victim to open his or her mailbox. Too much work.
While reading through the emails from some of the compromised accounts, I found multiple references to Citrix. Not sure how I missed this during my recon, but my client had an Internet-facing Citrix platform configured to use AD authentication. This was a gold mine because of the ease of compromise. As you might have heard or read, Citrix provides a restricted desktop environment—and then allows you to break out of it (Cool! Sarcasm!). I was able to log in with the brute-forced domain credentials, break out of the restricted environment using Internet Explorer, and invoke a command prompt.
Once again, I executed the PowerShell Empire payload to get a reverse https shell communicating back to my server that allowed me to compromise more hosts on the internal network.
At this point, I had compromised enough internal hosts and had enough login credentials to do the whole privilege escalation dance and eventually get domain admin privileges. Some of the easy-win PowerShell Empire modules to try are:
privesc/gpp
privesc/ms16-032
collection/Inveigh-Unprivileged
collection/keylogger
In conclusion, breaching the external perimeter by applying malicious Outlook rules and using Citrix and PowerShell Empire, combined with a little ingenuity, could lead to compromised accounts with relative ease.
Not every person has access to ethical hackers, but enterprises do. The time to start leveraging experts to aid in managing your security arsenal is now, and Spirent is positioned to be your partner in your fight against cybercrime.
If you’re interested in learning more about our security solutions visit Spirent’s SecurityLabs page. If you would like this level of security expertise for your company and want to speak to our security experts directly, contact us, or register for our Cybersecurity live and on-demand webinars.
Follow Spirent Security on Twitter (@spirentsecurity) for the latest security news.
