In part 1 of our mini-series on canary credentials, we talked about what anti phishing canary credentials are, why to use them, and how to use them well. It’s highly recommended to read part 1 first.
So, let’s assume you’ve had some early success in manually using canary credentials in limited numbers - great! Now you’re looking to take your next steps.
Arguably, the most powerful way to land a blow against phishing attackers and deter future attacks is using canary credentials at scale via automation. Here’s why:
A simple way of handling an attempted login with a canary credential is to just reject the username and password like you do for any invalid login attempt; the account ID doesn’t actually exist in this case. This still creates the all-important entry in your logs that the canary credential was used and gives you helpful insight into the phisher’s tactics, techniques and procedures (TTPs).
You could get more sophisticated though, like appearing to accept the canary credential and then showing that your website (e.g. your banking transaction page) is down for maintenance. You can even create an elaborate honeypot where everything looks normal to the phisher and things like transactions appear to be possible, but they are being secretly monitored in an environment where they can’t do any real damage. Meanwhile, you’re trying to learn as much as possible about their operations.
The basic approach for detecting canary use is to raise an alert in your logging platform whenever one is observed. For example, username ‘CA21234’ is an anti phishing canary credential you’ve created that will never be legitimately used by a customer, so you can alert with high confidence whenever you see it used in a log in attempt.
This is trickier to do at scale. It’s reasonable to manually poison phishing websites with fake credentials if you only get one or two a month, but organisations like financial institutions and universities may need to handle dozens of phishing attacks per day. Manual poisoning is not feasible at this kind of scale - at least, not without burning out your valuable analysts.
Many phishing sites don’t only ask for a customer’s username and password. We regularly observe phishing kits that, after asking for and receiving simple login credentials, will subsequently ask for everything else that makes identity theft much easier.
A phish will ask for your passport details, your driver’s license number, date of birth, even answers to the common ‘secret questions’ used as a fallback for forgotten passwords. Armed with all of this information, a phisher can contact a company or government bureau and do an effective job impersonating you for the purposes of fraud.
This lets the phisher build up a fairly complete personal profile that allows for all kinds of identity theft. It’s no trivial challenge to realistically fake all of this data for canary credential purposes.
Naturally, one way to tackle the problem of handling all types of phishing sites is to either manually or programmatically generate, submit and track lots of different types of personal data like usernames, addresses and passport numbers. This requires significant effort for a phishing response team that is already likely very busy.
So, for organisations that deal with a high volume of phishing attacks, we developed Phishfeeder anti phishing software to solve this problem. We began by digging into real data from Australians and New Zealanders and analysed the patterns. We’ve solved the problem of creating realistic physical addresses, driver’s licenses, passport numbers, and so on. It’s not an easy problem to solve, but it’s a necessary one if you’re going to poison phishing sites at scale, and you want to be able to handle all the myriad combinations of data that different phishing sites will ask for.
Another factor in poisoning phishing sites at scale as part of your anti phishing strategy is ensuring your connections to phishing sites don’t raise suspicion; that is, your connection looks just like that of a victim. We’ve built a covert network you can use, called Smokeproxy, to initiate connections from major telcos and ISPs.
These connections look much like victims’ home connections from the phisher’s point of view. They originate from locations where your customers live and internet services they use, and connections can be rotated so that different IP addresses are used for different canary credentials. Phishfeeder uses Smokeproxy under the hood to make its anti phishing activity highly difficult to distinguish.
For teams doing credential poisoning at scale, one of the features we built into Phishfeeder is an API you can use to request all the canary credentials that have been used to poison any particular phishing websites targeting your customers.
Just submit a new phishing URL to Phishfeeder, regularly poll the API for new canary credentials as they are created, and add them to your alerting rule so you’ll find out when they are abused. Phishfeeder takes care of all the complexity of handling the data each phishing site asks for. Cosive keeps a close eye on the effectiveness of our canary credential poisoning so we can develop further anti phishing countermeasures as needed. How we generate data like usernames is also customisable for your organisation.
Using Phishfeeder, you never need to generate and maintain lists of canary credentials by hand. Doing this manually just isn’t reasonable at high volume. Freeing security personnel from this kind of reactive, manual, mind-numbing work is why security orchestration and automation is of increasing interest to SOCs.
As mentioned in part 1, phishing sites generally do the bulk of their damage in the first 1 - 2 hours after the phishing lure email is sent out. Once discovered, many phishing websites are “only active for only 4-8 hours on average”. If you’re not orchestrating and automating your anti phishing response, you’ve got to manually poison the website and update your list of canary credentials in that narrow time window. It’s reactive, repetitive work. It’s a perfect candidate for orchestrating the whole workflow.
Automated credential poisoning is one of the most effective phishing defences using security orchestration, automation, and response (SOAR).
When you’ve automated your anti phishing response with something like Phishfeeder, you:
Whether your organisation is targeted by one phishing attack per month or fifty, it’s clear that while essential, solely focusing on taking down phishing attacks doesn’t 1) help us track who is being victimised or 2) inconvenience the phishers too much. Increasingly, organisations should consider disrupting phishing sites with anti phishing canary credentials, either using manual processes or, at sufficient scale, smart automation.
Person fishing by Andreas Wagner on Unsplash
Canary by Olena Panasovska from the Noun Project
Alert by Wolf Lupus from the Noun Project