.webp)
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:
- Phishing operators often test credentials one-by-one, adding effort to phishers. If 80% of their harvested credentials turn out to be fake and non-functional, this is a massive inconvenience and time-sink for phishers.
- It reduces the quality of stolen, on-sold credentials, and the reputations of phishers selling them. Extracting funds from compromised financial accounts is often a specialisation in itself (often requiring the use of local money mules), and some phishers will sell harvested credentials that seem valid without thoroughly testing them. If many of these credentials turn out to be fake, this will negatively impact their all-important reputation in the marketplace where they are attempting to sell credentials. Being a “bad” bad actor, so to speak, is unprofitable for them.
- It can deter phishers from targeting you in the future. Sorting out real from fake credentials is the kind of painstaking manual task that low-skill phishers hate doing. In the face of this, the diminished ROI they get from targeting your organisation may deter future attacks against you. It’s been long observed that actors in the phishing arena target a handful of brands for months at a time, before moving on when anti phishing countermeasures become more effective and they see their returns drop.
Landing the phish: what to do when a phisher uses a canary credential
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.
Scaling up anti phishing credential submission and alerting
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.
Handling other types of personal data (PII)
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.
Automating anti phishing credential submission
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.
Poisoning from the same place victims are victimised
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.
Automating anti phishing canary management
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.
Orchestrating your anti phishing response
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:
- Receive a report of a phishing URL from customers or staff;
- Have your orchestration system fire the phishing site URL at the Phishfeeder API;
- Phishfeeder analyses the site, generates realistic canary credentials, and submits them;
- Phishfeeder makes these anti phishing credentials available via its API for you to collect;
- You fetch the seeded canary credentials;
- You continually update alerting rules from the canary credentials and have your systems automatically respond (e.g. find a unique factor about the connection that lets you ID other phished customers).
Fighting back against phishing
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.
If you’re interested in trying out Phishfeeder to automate your anti phishing operations, talk to us!
Credits
Person fishing by Andreas Wagner on Unsplash
Canary by Olena Panasovska from the Noun Project
Alert by Wolf Lupus from the Noun Project