Daily server & endpoint patching, application whitelisting, web application firewalls, intrusion prevention systems and more all sound like excellent defences yet phishing can punch through them. Why? Phishing goes after the person unlike a SQL injection attack. Strangely some email security gateways guarantee 100% (hmm) malware blocking and 99% or so spam blocking.
Hackers, terrorists and heist gangs do reconnaissance before an attack and if you can hide your services hackers will struggle to pull off the attack. Everyone has a website which routes through www (www.domain.com) and @ (http://domain.com). For VPN gateways, client logins, document management systems; sub domains are used, i.e. vpn.domain.com, clients.domain.com and docshare.domain.com.
To pull off an attack, an attacker needs to see the target URL, craft an email and then login as the victim user. If he/she cannot view the URL then he/she cannot craft an email along with fake login page which looks like the real deal. Sub domain records are not typically query(able) though there are a few ways of finding them. If you make it very hard for hackers to find such sub domains, then it may slow down or even stop the attack.
Publicly facing records should be published online with records used by internal staff being published internally. Dev, UAT, SIT, pre-prod server records should be published on an internal DNS server which is only query(able) internally. Thus, outsiders have little chance of finding such servers/domains. Test environments have a habit of being poorly secured with default credentials and being forgotten about.
We are all familiar with application whitelisting for mainly Windows servers & desktops where you deny all new installers not digitally signed by vendors you trust. This method is not used that much let alone this method. Website whitelisting operates on the same concept but for domain names instead. What is it you may wonder?
IT ask a wide range of employees which websites they visit which will be in the thousands. The information security team then visits the websites and investigates the reputation of each 'vote'. Then HR signs off the new policy and list. From now on while in the office and on the VPN only the list loads which consists of 5000 vetted websites or so. Now the chance of visiting a phishing website or picking up a malware infection from a website is greatly reduced.
Targeted phishing is likely to involve customised newly registered domain names. I.e. natwest-login.com. These domains will be registered and used within days to stop them being found and taken down. For this reason, they are unlikely to be listed in categorisation lists, think: Bluecoat (now Symantec owned), Forcepoint (ex-Websense) and BrightCloud (Webroot owned). Websites are categorised as: gambling, webmail, malware etc.
Since newly registered domains are unlikely to be in a list, conventional defences will struggle. Reputation defence is pre-calculated or works in real-time. Aspects such as: IP country origin, domain extension, domain age and how many people have visited the domain in x days are taken in to account. A score is then calculated out of 100 and depending on your website security gateways policy, the end user is either denied access to the website or given a warning message.
Firewall rules implemented on the operating system, network firewall or application layer is a great defence which is often neglected. If an attacker cannot see what he/she wants to clone and more importantly login to with stolen credentials, then the attack stops dead in its tracks. The whole world does not need the facility to see and have the ability to login to: ServiceNow, Salesforce, Jira, Confluence, Bitbucket etc. FTSE 100s and large public sector departments are guilty of this.
Yet, these are often left open with zero firewalling. IP whitelisting should be used so only offices, VPN IP ranges and suppliers (be careful here - supply chain attacks!) can access such services. Thus, even if an attacker managed to grab a valid set of credentials it could not be used due to network firewall or the application refusing a valid login due to the source IP address.
Two factor authentication
Despite everyone knowing what two factor authentication is (something you know, something you have and something you are) it is not as common as you would think. Depending on which method used they can still be defeated by phishing or really the end user being stupid! 2FA makes brute forcing harder or impossible but clever phisher(wo)men can simply ask the victim for the OTP (one-time code). OTP's usually are valid for 30-60secs, 10mins or forever. Thus, if a username + password + OTP was captured it could be used if used quickly.
Soft OTP i.e. Google or Microsoft authenticator and SMS based is vulnerable since the end user could simply hand it over. SMS comes with its own dangers, malware, interception or tricking the phone network into transferring the number to a new SIM card. Hardware based, not necessarily the good old RSA token has two advantages. Being hardware, the end user may think no, I am not going to hand this code over. Hardware or software is far better than nothing of course.
If challenge-response is used, where the authentication system presents a number to the end users token and the token gives back a number based on a shared secret then no code is ever shown to the user which means it is un-phishable. Smartcard are very secure as well. Hardware based authentication is expensive yet more secure hence why it is not seen very often.