Whether you choose to believe it or not, your company (given it is of a reasonable size or deals with sensitive data) is, or will be, the target of a specific technology oriented attack of some kind. And I’m not talking a basic port scan here, I’m talking an attack tailored to your environment in some way where an attacker is specifically trying to access your infrastructure. If you look hard enough within your environment, you’ll most likely find something of value (be it your secret sauce recipe, credit card numbers, SSNs/PII, etc) and there will always be people interested in getting their hands on that data.
This is the first of a series of posts that will discuss specific attack vectors that are commonly used in targeted attacks along with how I recommend you respond to and proactively protect against the attack. We’ll begin with targeted phishing attacks…
Targeted Phishing Attacks
Wikipedia defines phishing as “the criminally fraudulent process of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication.” (source)
Common phishing attacks can be written in either a general (for a large, non-related audience) or in a targeted fashion. General phishing attempts are rather easy to recognize and many computer users have become savvy enough to not respond to those attempts (in addition, many SPAM filters catch a large number of these attempts before they even reach an inbox). However, a targeted Phishing attack is more sophisticated and is written with a specific audience (your company’s users) in mind; it’ll ask for company specific information using company specific terminology, which lends a more authentic and authoritative feel to the communication. This request for specific information may appear to be sent from a commonly known or believable email address within your organization, albeit if you dig into the email header and/or reply to address you’ll clearly notice that the email did not originate within your organization and the reply-to address is outside of your organization.
The goal of a targeted phishing attack on an organization is most likely to gain access to credentials or to some other set of information that will allow attackers to impersonate a user (to gain access to credentials, etc).
A targeted phishing attack on an organization should be considered a direct threat to the security of your environment and you should respond swiftly. Some debate may exist as to whether an actual “incident” has occurred, but I generally lean towards treating a targeted phishing attempt as a live incident and treating it as such – hopefully you already have an incident response policy in place that will provide some guidance as well as empower the incident responder (I’ll write more on this in a future post). At a minimum, given you have been notified that a targeted phishing email has made its way to end-users, you should assume that users have already responded or are at risk of responding to the attempt.
If you are the recipient of a targeted phishing attack (via email), I recommend that while following your existing incident response procedures, that you take the following incident-specific reactive steps:
- Notify end users immediately that the email that they received is not legitimate and if they responded to it, they should contact your helpdesk immediately (or some other team/individual that is available to assist) so that corrective actions can be taken; the specific corrective action that is taken by your helpdesk is dependant on the information being phished for. If the email is requesting credentials, then you should change them, if possible. If the email is requesting PII that can be used by an attacker to impersonate a user, then the account should be flagged in some way so that the helpdesk/administration team takes extra care when contacted. If you cannot quickly determine who actually received the phishing email, send this alert to your entire user population.
- Inspect the phishing email’s message header and record all pertinent information.
- If possible, put a block in place that will be prevent any outbound email being sent to the reply-to address of the phishing email. Additionally, if possible, put a block in place preventing any further attempts with the reply-to address or subject line, etc from being delivered.
- If possible, run a search of your email logs to determine whether anyone responded to (i.e. sent email to) the reply-to address of the phishing email. If you do find responses, you should contact these users immediately and take corrective action on their account – corrective action should be taken whether or not you can get in touch with the user. Since the attackers generally realize that they have a limited window to “exploit” the information that they receive, it might be wise to check any remote access systems (or other systems in the organization) for activity using the userid that was provided to the attacker to ensure that they have not already made their way into your environment.
There are a number of strategies that you can implement to help lower the effectiveness of a targeted phishing attack. The number one strategy to combat phishing is user education – I cannot stress this enough. An informed and educated user population is much less likely to respond to phishing attempts. Regular communications should be sent out to users reminding them of information that will never be asked of them via email and that any emails received asking for this information should not be responded to and reported to your security clearinghouse (be that an incident response team, helpdesk, local security contact, etc). Additionally, your user onboarding process should include education new users of this threat and IS/IT personnel should also be regularly reminded as what information they’re allowed to ask a user for and what method of communication is appropriate for these questions.
Other mitigation strategies include:
- Putting in place a filter on your email gateways and/or filtering solutions to drop any email coming from outside your organization that has your organization’s domain in the From line. Well-designed email environments should never receive email with internal From addresses from external sources – I do recognize, however, that many environments may have external providers sending in these types of emails, so exceptions may need to be put in place.
- External (and Internal, if feasible) authentication should be two-factor where the second authentication mechanism uses a rotating code (i.e. RSA SecurID) or is something the user has (i.e. smartcard).
- Externally accessible web pages, including system access pages (i.e. VPN, work from home, etc) should not contain company specific terminology or information that can be mined by an attacker to better craft their phishing message.
A good phishing attack is no longer easily identifiable and is written in such a way that even the most savvy of users may consider the request legitimate. Attackers are increasingly using more sophisticated phishing techniques to allow them to gather information to gain access to your environment and you should be taking steps now to help mitigate the impact that a well-crafted attack could make and plan for this eventuality.