How to Disrupt Phishing with Anti Phishing Canary Credentials

This article is a collaboration between Cosive’s CTO, Chris Horsley, and Tash Postolovski.

The traditional response to a phishing attack is to issue a take-down request and wait for the site to (possibly) be yanked offline.

The biggest problem with this method is that, according to IBM researchers, on average, 70% of the credentials harvested during a phishing attack are collected within the first hour. By the time most phishing websites are taken offline they have already delivered their stolen data payload to the criminals operating them. Take-downs, while necessary, just don’t hit phishers where it hurts.

In light of this, security teams are looking for new anti phishing techniques to fight back against phishers. Rather than be reactive, we want to disrupt phishers’ operations. A strategy rapidly gaining in popularity is the use of credential poisoning techniques, utilising what are referred to as ‘canary credentials’.

What are canary credentials?

A canary credential is a fake set of credentials (e.g. username and password) designed to be indistinguishable from legitimate credentials to the untrained eye. If you ever see these credentials used anywhere, it’s a signal that someone is up to no good - the proverbial canary in the coal mine.

These canary credentials mix in with the real credentials harvested by a phisher in the same way that marked money mixes in with unmarked cash. By convincing criminals to use these canary credentials to log into your systems in the hope of getting account access, you can fire alerts whenever you see them.

For example, you submit a fake username of “12032452” to a phishing site. You make sure that “12032452” is never assigned to a real customer, and goes on your alerting watchlist. So, if you ever see “12032452” appear in your authentication logs, you know with certainty something bad is happening.

Using this initial analysis foothold, you can profile their remote connection, their behaviour, or their web browser. This profile of the attacker can lead you to other malicious activities they are performing in your system, like logging into actual compromised user accounts.

Effectively using canary credentials as an anti phishing technique

In this article, we’re going to be talking specifically about phishing against your customers. Canary credentials for phishing against your staff has its own considerations which we’ll talk about another time.

When your anti phishing team receives a copy of a phishing email, poisoning the phishing site would normally involve visiting the URL and manually entering canary credential data. The data you submit must be credible and believable enough that the attacker is going to accept it and use it without reservation.

Junk data won’t cut it. Do it right or don’t do it at all. When we locate and review the credential logs of phishing sites, we often see people manually entering junk data in an effort to annoy phishers. They might submit twenty credentials to the phishing site, but they are all clearly rubbish, containing things like “Haha, I’m on to you!”.

What these people don’t realise is that, increasingly, phishing sites are automatically validating the data that is given to them. The validations check things like the following, and throw out any credentials that match these rules:

1. Does the username fall outside the parameters actually used by the targeted institution?
2. Is the connection coming from the targeted institution’s IP address, e.g. an anti-phishing team?
3. Does the user IP originate from an unexpected geographic location (e.g. Pakistan IP for a New Zealand-targeted phish)?
4. Does the IP address correspond with an IP address or network range already on our blacklist? Extensive blacklists featuring IP addresses associated with anti-phishing activity frequently circulate on underground forums and are even included in many popular ‘phishing kits’ out of the box. Getting a decent blacklist to throw off security teams is not as hard as you may think.

Looking through phishing site credential logs, we see junk credentials immediately marked as ‘invalid’ and discarded automatically. By attempting to poison phishing sites with anti phishing junk data you may instead magnify the negative impacts of the phishing attack by just wasting your own valuable time. If phishers can easily pick out your data as being fake, they’ll never try your credentials. You’ll never see the canary credential appear in your system, and your alert will never fire. The whole anti phishing exercise will be rather pointless.

We have seen multiple instances where phishers, suspicious of activity from a particular IP, respond by putting that IP or its network range on a blacklist that gives your monitoring scripts the false impression that the phishing site has been taken offline. Most commonly, this would be a fake 404 HTTP status code returned by the phishing kit. Your anti phishing team monitoring a phishing URL may be left thinking it has been taken down, when it is actually still impacting your customers.

A careless response to poisoning phishing websites is, in many ways, worse than no response at all.

Poisoning the well, well

Ultimately, canary credentials are only worth using as part of your anti phishing strategy if you’re going to use them well. There’s an art to doing that, and some careful forethought required.

The main principle at work here is: don’t be predictable. Don’t leave obvious signatures.

1. Reserve a range of values for your anti phishing canary credentials. Let’s say you generate six digit account numbers for each of your users. This is a range of one million potential values. The next step would be to set aside a number (e.g. 1,000) of secret combinations in that range that you will never issue to customers. If anyone tries to use any of those reserved digit combinations on your website, you know their connection is associated with fraud. If your site uses usernames, you may need to generate a list of fake usernames and then reserve them so that any user who tries to sign up with one of those usernames is told that the username is taken.
   
   Ultimately, you need to ensure that there can be no overlap between your anti phishing canary data and your real customer data, otherwise, your alerts will prove inaccurate.
2. Don’t poison repeatedly from the same IP address. Even if you’re using a convincing proxy, using the same IP repeatedly for anti phishing activity will raise red flags. In fact, many phishing kits have automated rules to add IPs with multiple repeated visits to a blacklist. Why? Because real phishing victims generally don’t visit a phishing site more than once.
3. Don’t leave tell-tale signs that your session is scripted. An obvious sign is using the Python or curl built-in HTTP client user agent, for example, which a real victim would never do. Phishers can easily block this with automated validation.
4. Randomise your browser profile. A single web browser is much less difficult to uniquely identify than you think. A simple trick is mixing up your HTTP User-Agent header, but there’s multiple things you can do to make each trip to the target site look different enough.
5. Don’t initiate connections from AWS or another data centre. Phishers know that real victims would very rarely do this. It’s a common mistake made by anti phishing teams who underestimate the opposition - plenty of phishers are indeed paying attention to who is visiting their scams.
6. Don’t proxy in using an unexpected location. Using a proxy when poisoning phishing sites is a must, but pick a geographic location that matches where victims would be expected to come from. Blocking visits from unexpected locations is a no-brainer for attackers. They can and commonly do perform geographic lookups of each potential victim’s IP address.
7. Don’t use a commercial VPN. Commercial VPNs are typically used by more savvy internet users, who could be judged less likely to be phishing victims. Some phishing kits err on the safe side by discarding credentials coming from popular VPN network ranges. This includes Tor.
8. Assume that phishers will manually inspect data for quality. Credentials are a phisher’s bread and butter. They see a lot of victim credentials, and as such, should be expected to have a keen sense for what real victim data looks like. If a phisher tries to harvest the user’s drivers licence, for example, your fake data should follow the format of a valid driver’s license. A value that looks obviously fake, like 1234567890, will immediately raise suspicion.
9. Understand that realistic fake data becomes more critical as you poison phishing sites with larger volumes of fake data. The more anti phishing canary credentials you use, the more likely it is that phishers will spot patterns in how you generate your anti phishing credentials. If you’re always using the same sort of IP address, and the same user agent, one connection might not look too suspicious, but 20 connections matching this pattern (e.g. fakeuser1, fakeuser2, fakeuser3) will likely generate suspicion.
10. Don’t submit credentials on a rigid schedule.  If you’re going to submit multiple anti phshing credentials, allow some randomisation of submission times. Credentials appearing every 15 minutes on the dot are a dead giveaway. Also consider when a victim is likely to submit credentials, e.g. not at 4am local time.

If you don’t want to invest a lot of effort into realistically faking data, or don’t want to use anti phishing software to do this for you, we recommend poisoning phishing sites with a single canary credential. This makes it difficult for phishers to observe patterns in your faked data, even if the fake data is imperfect. If the phisher tries logging in with all the credentials they harvest on your website, you’ll still get an alert whenever they use the canary credential. The downside of the single credential method is that the quality of the phisher’s overall credential harvest is, for the most part, undamaged. Phishing attackers are still reaping the rewards of targeting your organisation, though at least now you have a way to profile and detect them with your canary credential.

To do poisoning at scale, automation is essential, and something we do every day at Cosive with our Phishfeeder anti phishing software.

In Part 2, we look at how to automate submission of canary credentials, and how you can orchestrate your anti phishing response when you detect their use.

Credits

Canary by Olena Panasovska from the Noun Project
Alert by Wolf Lupus from the Noun Project