Honeywords like method for detecting site cloning and phishing

After reading various articles today on honeywords, I thought this would be the perfect time to talk about a technique that I came up with last year that is very similar in nature. Honeywords is the act of seeding your user databases with false usernames and/or passwords, and then monitoring for any activity involving those accounts. If activity is seen on those accounts, it can be assumed that there has been some sort of compromise as these accounts would not have been used otherwise.

The Problem:

Similar methods can be used to detect another common attack that plagues the industry, phishing and site cloning. As I displayed in TekTip episode 7, using tools like the Social Engineering Toolkit (SET) one can easily clone a site for use of delivering exploits, or credential harvesting. The basic idea behind tools like this is they clone the site of the attackers choosing, inject some code to enable exploit deliver or credential harvesting, then the attacker waits for shells or credentials to roll in.

In organizations I have worked with, we would see attacks like this used. One particular scenario we often saw was attackers would clone the webmail site for the organization (http://webmail.example.com). The clone would look like an exact copy of the actual webmail site. The attacker would sometimes register a domain name that looked very similar to the actual domain name such as:

- webmail.examp1e.com

- webmail.example.com.co.uk

Once cloned the attacker using a list of email targets probably gained with The Harvester or Recon-ng would send out an email to as many users as possible. The email would look something like this:

Hello example.com webmail user,

Example.com has recently undergone security updates. Please login and reset your password at the following link: http://webmail.examp1e.com.

Thank you,

Example.com Security Team

As you can probably imagine, many users would click on this link and would be brought to what seemed to be the webmail system they were familiar with. Once the user attempted to login, the cloned site would send the username and password to the attacker. The attacker now with credentials could login to that email account and collect intelligence, get more email addresses, and various other items of malicious intent.

This happened several times in many organizations I have worked with. The solution I came up with for this scenario was a very simple one much like honeywords is.

The solution:

To combat this problem, we had to understand what did we have control over in this scenario. Could we detect someone cloning the site? Could we detect collection of email addresses? Could we detect someone registering domain names similar to the organizations? The answer to most of these questions was, not with any regularity. For instance we could detect site cloning if they used a specific useragent each time (python-urllib2). We could also look for similar domains being registerd with tools like URLcrazy. These were not very reliable solutions though. What we settled on is this:

Step one: Inject a tracking code on the website you want to protect. This tracking code can be anything as long as it is unique and discrete. You would not want to call it "Hacker Tracker UNIQUE CODE" as that may give away what you are doing to attackers. Instead go with something like "Analytics cookie: abcdefgh12345678"

Step two: Write a signature for your IDS to alert on that cookie if it is seen from an internal user going to an external address. The logic here is you would expect to see this unique code from external users going to the webmail server in your DMZ, and you may also expect to see this traffic from internal users attempting to use webmail in your DMZ, but you should NEVER see this tracking code in any traffic from your internal network to an external address. If that is seen you can assume someone has cloned your site and has tricked a user to going to it somehow. Your signature may look something like this:

alert $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg: "Cloned site detected"; content: "abcdefgh12345678")

*This is a very simple example used for readability, you will want your signature to be as specific as possible here.

Step three: Monitor for activity. If detected, using a protected method investigate the site to determine if it is a credential harvester or if it is delivering exploits. If it is a credential harvester give it some fake credentials and then monitor your webmail system to see who attempts to login with the fake account.

Limitations:

This approach will not work in every situation. Some of the obvious limitations with a technique like this is:

- You will only detect this if internal users attempt to go to the cloned site. If they were to go to the cloned site from a network you do not monitor, you would not be able to detect.

- Attackers could attempt to detect these tracking codes and delete them.

- If attackers manually clone the site instead, they may not take the tracking code.

Improvements:

Like any solution, this could be done better depending on the resources available

- If you have an endpoint Intrusion Prevention System (HIPS) the signature could be implemented there as well. This would help detect attacks if the victim is not on the organizations network.

- A more contreversial method I considered was instead of using a tracking code, include a small javascript link in the webmail site that would collect some client side information on the users. I figured I could do something similiar to the way Google Analytics works. Using this type of technique I might be able to get better attribution on the attacker while also detecting who went to the cloned site regardless of what network they were on. I ultimatley decided against this idea as there were too many privacy and legal items to consider.

Conclusion:

Too often I think security professionals rely on techniques and tools that are given to us. In my opinion there is not enough creativity being applied to security problems. I hope techniques like this will help security teams realize that if they try to understand the problem, they may be able to come up with creative solutions that don't require purchasing a new product.