Anti-phishing - Incident Response
As we had seen in the first two parts of the series, there are several ways of preventing and detecting a phishing attack. Even if we take all necessary precautions a successful phishing attack could still happen and we need to be prepared to respond to it. In this article we explore some of the incident response steps we can take to limit the damage.
As we had seen in the first two parts of the series, there are several ways of preventing and detecting a phishing attack. Even if we take all necessary precautions a successful phishing attack could still happen and we need to be prepared to respond to it. In this article we explore some of the incident response steps we can take to limit the damage. These steps include:
- Bring down the phishing site
- Block access to the phishing site
- Actively feed wrong data to the phishing site
- Additional authentication at original site
- Force user password change at original site
- Lookout for attacker connections
- Actively inform customers about attack
Bring down the phishing site
It is definitely the most obvious and effective thing to do. The ease with which it can be done depends on the location where the phishing site is hosted. There are several companies which are offering "take-down" of phishing sites as a service. There are committed service-level-agreements and pricing is available in multiple models - pay per use as well as pay-in-bulk. The success rate of this type of service is definitely high as the average lifetime of phishing site is now down to about 5 days [as per APWG statistics]
Block access to phishing site
If we cannot bring down the site, this is probably the next best. This is especially relevant if the phishing site is hosted in a foreign country and most of your customers operate from your home country. It is possible to block the phishing site (by name or IP) at the gateway routers of the home country. How fast and effective this can be done varies based on the country. Forums like National-CERT normally have working relationships with ISPs who manage these gateway routers and can coordinate to get this done within reasonable time.
Feed wrong data
Access the phishing site and supply wrong user-id/passwords. It could be a useful mechanism to confuse the phisher and reduce chances of the attacker being able to identify the correct user-id/passwords from the pile of data.
Introduce additional authentication
The idea is to prevent the hacker from using the data collected at the phishing site. Introduce an additional authentication layer at the original website in addition to the normal user-id/password. The challenge is to ask for a parameter that is already known to the user and the Bank but not to the phisher. Some of the options available to a Bank are asking the customer for one or more of the following:
- Enter the branch name
- Enter your date of birth
- Enter last four digits of your account number
Force change of passwords
The idea is to ensure that the information collected by the hacker is stale. Once the user has logged in through the extra user-id/password and extra authentication layer added now, force the user to change the old password.
Track weblogs for attacker connections
The attacker is bound to try the user-id/passwords collected at the phishing site against the original site. Track the weblogs to see if login attempts for multiple user-ids are coming from a single source-IP. Though we cannot conclude that this IP would be that of the attacker, it might be worth checking the details of the suspicious IP like country/ISP etc. If the source points to a country where the chances of valid customer being present are remote, we can block access from that block of IP address.
It is important to let our customers know that an attack has happened and they need to be careful. We could use alternate channels like SMS or Notices at ATM centers or Branches to spread news of the attack and how-to-respond. It may not be a wise idea to shoot another email or post something on the website. This may further confuse the user.
We need to be prepared to respond to phishing attacks. Immediate take down of phishing site is the best approach to limit the damage. However this may not be achievable in all cases. Hence we need to proactively try and corrupt the attackers' database and also put in controls to prevent him from successfully using the phished IDs against our site.