Exploiting Password Reuse on Personal Accounts: How to Gain Access to Domain Credentials Without Being on a Target’s Network: Part 1

Beau Bullock //

In this series of posts I am going to detail multiple ways to gain access to domain user credentials without ever being on a target organization’s network. The first method involves exploiting password reuse issues where a user might have reused the same password they used for their corporate domain account on another external service. The second method is what I think is a far more interesting way of gathering user credentials that involves discovering a target organization’s username schema, followed by password spraying user accounts against an externally facing service that is hosted by the target organization (for example an Outlook Web Access portal). Other methods will follow these posts.

In part 1, I will detail how an attacker can gain access to corporate domain account credentials by taking advantage of password reuse by an employee on their personal accounts.

This Article Does Not Involve Sticky Notes

Credential Reuse on Personal Accounts

Individuals that reuse the same password on multiple web services is a very huge issue. Many people will use the same password for many different services out of the ease of remembering multiple logins across the web. The problem with this is that if a website is compromised and a user reused the same password for their personal account and their corporate account then, potentially, an attacker who has gained access to the personal credential now has access to corporate account credential.

Very commonly when we start to analyze credential leaks for a target organization we typically tend to just look at the domain name owned by the organization. By only looking at the target organization’s domain name one will only gain access to credentials where a target user has used their corporate email address to sign up for an external service. A far more interesting way to go about looking for user credentials involves attempting to locate corporate employees’ personal accounts that have been part of a third-party compromise. This can be a very difficult task provided the many services that are available for users to sign up for email (Yahoo, Gmail, etc.). The difficulty of locating a user’s personal account can be decreased when the target organization itself has a service that offers personal accounts.

For example, think about an organization like Google who has gmail.com. It’s safe to think that employees of Google potentially have a gmail.com account. On a recent engagement I had the opportunity of testing a company that also offered a similar service where they offer email addresses to their customers. Pwnedlist.com is one of a few sites that collects the information dumped publicly from various data breaches. They have a service that allows users to submit email addresses and determine if that address was associated with a data breach. Pwnedlist also accepts domain names. When submitting a domain name to Pwnedlist the site will tell you how many accounts from that target domain were part of various breaches. When I ran the target organization’s domain through a Pwnedlist.com search I found the domain used by the customers of the target organization had over 50,000 accounts that were part of various data breaches as recent as a few days before I began the assessment.

 I spoke with the target organization about the potential of their own employees having accounts that were technically personal accounts they set up as a customer of the target organization. They were in agreement that this was a possibility. The organization was rightly interested in which of their customers have been part of a data breach, and they requested that I provide this data. I proceeded to gather this information from Pwnedlist.

This got me thinking about the potential for analyzing and correlating whether an employee’s personal account credentials that are part of a previous compromise align with their actual corporate account credentials. Could I actually cross reference a user’s personal account credential back to their corporate account, and potentially login using the same credentials that they used on their personal account? (Just to clarify I am not attempting to login to, or utilize an individual’s personal account. The goal is to see if the password they used on a third-party site that was part of a breach was reused on their corporate account login.)

After gaining access to 50,000 personal email addresses, and potential credentials for those personal email addresses, one must then find a way to relate those email addresses to actual people and then potentially relate them to corporate email addresses. The problem with sites that allow users to create their own email address is that the address name is at the discretion of the user. So, in my case I ended up getting credentials from Pwnedlist for accounts that looked similar to “[email protected]”.

In order to determine whether [email protected] belongs to an actual employee of the target organization one needs to be able to take that email address and figure out who exactly it belongs to. To do this I used the Pipl.com search engine. Pipl.com will accept an email address and provide a ton of information that they have gathered from many different social media and news sites around the web. For example, you can submit an email address and they might be able to provide details they gathered from sites like LinkedIn, Facebook, etc.

This information generally will include a full name of a person if they posted it somewhere on the Internet. Also, a ‘Career’ field potentially details where someone has said they work somewhere on the Internet, maybe on LinkedIn.

Using Burp Suite’s Intruder functionality (sidenote: I’m working on turning this into a Recon-ng module) I submitted over 50,000 email addresses that were technically personal email accounts of customers of my target organization to pipl.com’s search engine. I then grepped the responses from Pipl for the ‘Career’ field looking for the title of the company itself. On the Options tab of Burp Intruder you can add in custom fields to grep for. I removed all of the other default fields and added in the company name of the target organization.

Burp now tells us whether the response contained the company name or not. This helps us narrow down the possible matches for employees.

Managers never reuse their passwords right?

Out of the 50,000 email addresses that I submitted to Pipl I actually ended up with 252 hits that appeared to be employee’s personal accounts. After finding these 252 potential personal accounts of employees the task then becomes to convert them into the organization’s email standard. If Pipl was able to find the full name of the individual whose personal email account I submitted was associated with, then it shouldn’t be too difficult to mangle their name into a corporate email address (i.e. [email protected]).

For this particular target organization I was able to find other valid email addresses during reconnaissance so it was very easy for me to discover the schema. I was able to then convert what appeared to be personal employee accounts to corporate email account addresses. I also had credentials for these accounts from Pwnedlist. The next step was to simply go attempt to login to an external portal (like Outlook Web Access) with these credentials that were part of a third-party breach. If an employee of the target organization had reused the same password they used for their personal account, then we now have access to a valid domain account.

….and we’re in… to Mr. John Doe’s email.

Just to recap, the steps of this approach to gathering user credentials follows:

1. Gather credentials of personal accounts associated with a target organization through public data breaches. Sites like Pwnedlist host services for gathering these.
2. Submit these personal email addresses to Pipl and grep the results for the company name. This is to help locate individuals who said they work at the target company on the Internet and Pipl was able to correlate a personal account to them.
3. After crafting a list of potential employee’s personal accounts use the information gathered about them from Pipl to craft potential corporate email accounts.
4. Potentially, you now have email addresses and passwords of corporate accounts if credential reuse was occurring.

Recommendations

• Introduce your users to password managing services. The best defense against this is to make your users stop using the same passwords everywhere.

In the next part of this two-part article, I will detail how an attacker can discover a target organization’s username schema and perform password spraying attacks against an externally facing service. You can read it HERE.