Part Two of Our Three Part Blog Series on Phishing

In our previous phishing and spear phishing blog post we discussed the prevalence of these attacks, as well as some common tactics that we have observed. More and more, phishing attacks are leading to the compromise of companies around the world, so it begs the question…how can we prevent it from happening? There are two different approaches our team recommends to combat phishing attempts:

  • The technological approach, which we’ll be discussing in this post
  • Effective user training, which will be covered in part three of this series

How to Avoid Phishing Emails

There are many things a systems administrator can do to help prevent phishing emails from even getting to users in the first place and to help limit the severity of attacks if the emails do end up getting through. The first and most important aspect is email and spam filtering. Most systems administrators have an understanding of this, but it is important to have spam filtering enabled for emails to keep generic phishing attempts and other spam from landing in your inbox. Highly-targeted attacks are more difficult to prevent as spam filters may not know if an email is coming from a malicious domain or a doppelgänger domain, for example. This is where tools like DNSTwist can come in handy. Once a domain is entered by a systems administrator, DNSTwist will generate hundreds of doppelgänger domains that attackers could use for phishing attacks. These domains can then be added to the blacklist of the spam filter in order to prevent these doppelgänger domains from ever being delivered. Some organizations also decide to purchase some of these doppelgänger domains to prevent an attacker from using these domains for phishing attacks.

Here is an example of DNSTwist in action for lmgsecurity.com:

 

Setting up Technical Barriers to Reduce Phishing Attempts

Let’s take a deeper technical look at this process. In addition to filtering doppelgänger domains, organizations should also:

  • Configure mail servers with Sender Policy Framework (SPF). This prevents forged emails from ever being accepted. It is done by verifying DNS entries on the mail servers and checking incoming emails with a list of verified sending DNS entries and IP addresses.
    • Domain Keys Identified Mail (DKIM) should be set up as well and required for all mail servers. DKIM is a way for emails to be signed and verified as a genuine sender. Once an email is sent, it is signed with a DKIM key by the server and can be checked against the server’s key to ensure the email is actually valid.
    • Domain Message Authentication Reporting & Conformance (DMARC) should also be set up on all mail servers in an organization. DMARC is an extension of the previous protocols.  It allows a systems administrator to set up instructions for how their outgoing emails should be verified (either by SPF, DKIM, or both). Once DMARC instructions are published, a DNS record is made and all emails appearing to come from the domain of the organization can be verified or rejected if it fails the DMARC instructions. These protocols should be enabled and required by all mail servers in an organization. In addition, filtering should be done by verifying these protocols and rejecting emails that fail these verification checks.
    • These safeguards protect against phishing attacks where an attacker attempts to spoof their sending address to impersonate an organization’s authentic domain.
  • Implement a secondary form of email verification. For added security, an organization can implement an extra form of email verification where emails are verified client-side on each user’s computer. This can be accomplished by implementing a service such as PGP, GPG, SMIME, etc. which use public and private keys (Public Key Infrastructure, PKI) for each user to verify the authenticity of the emails.
  • Maintain up-to-date patches. Ensuring that patches are current for systems and antivirus software is important since attackers may attempt to exploit systems through browser exploits or file attachments. This can lead to malware being installed on a host or spreading throughout the network. In addition to maintaining up-to-date systems and software, the configuration of proper egress filtering is important as attackers can use a hidden Server Message Block (SMB) resource link which may allow an attacker to capture a user’s NetNTLM password hash. Prohibiting TCP and UDP ports 445 and 135-139 from sending data outside of the network would prevent this attack.

Services such as Microsoft ATP, Mimecast, Proofpoint, and others can help prevent many phishing attacks by scanning emails and URLs for malicious content. URL inspection and rewriting services help protect users from harmful emails or links by following the targets of these links, scanning for malicious content, or even going as far as executing the link’s contents in a sandbox environment. Services like these can add an extra layer of defense towards preventing malicious emails and attacks on an organization.

How to Avoid Phishing Attempts from Within the Domain

The methods described in this post can help prevent many external phishing attacks, but as we discussed previously, there has been an uptick in attackers using valid accounts to conduct phishing attempts from within a domain. In this case, it becomes more difficult to determine if emails are spam since they are originating from valid internal accounts. The easiest and most secure ways to prevent internal spam is to prevent attackers from gaining access to mail accounts in the first place. Enforcing Multi-Factor Authentication (MFA) and strong account credentials go a long way in preventing unauthorized access to accounts. Even if an attacker has valid credentials for a user, the use of MFA would prevent the attacker from logging into the account.

In addition to MFA, logging and notifications should be configured to monitor for suspicious logins. This is commonly based off GeoIP data—if an account attempts to login from a country or area where a user should not be logging in, a temporary block should be put on that account and IT should be notified for further investigation. In addition, if a user sets up any forwarding or mail rules, IT should be notified of these changes to investigate and validate their purpose. Many attackers exploit the use of mail rules to hide their presence on a user’s account.

In addition to our previous recommendations, there are additional areas that system administrators can enhance security and limit an organization’s attack surface. Unless there is a business need for them, the POP and IMAP protocols should be disabled. If an attacker authenticates using POP/IMAP, the entire contents of a user’s mailbox are downloaded to the attacker’s system. This creates additional issues after the fact when trying to determine what sensitive mailbox contents an attacker accessed as there are no data access logs available after the mailbox contents are downloaded. Network monitoring and alerting should be implemented on the organization’s internal network. This can be useful in many cases, but for phishing attacks, the ability to see odd traffic on the network can help notify IT of a potential phishing attempt and stop it before an attacker is able to gain a foothold or compromise an account. In addition, the ability to block access to a phishing page could limit the number of affected users. Finally, prohibiting mail relaying and anonymous mail submission on mail servers can help prevent unauthorized relaying or forging attacks.

Although many steps can be taken to limit the ability to send phishing emails to an organization, some phishing emails may still bypass technical controls and get into users’ inboxes. Training users to identify suspicious emails and take appropriate actions is vitally important and will be covered in the next post in this series. Stay tuned for our third and final installment on how to prevent phishing attacks.