I once saw a quote (or a Tweet) that said "Look, do you want to have a defensible network or not?" This quote stuck with me over the years as it essentially asked (in well under 140 characters), "Do you have the right technology, vantage points, processes, procedures, training, executive support, personnel, policy, controls, logs, etc., in place to duke it out and protect yourself?"
There are a lot of things we can do to reduce the impact of a successful phishing attack. But like all things in information security, we can't completely eliminate the risk, so it’s important to proactively prepare an effective phishing incident response strategy. So, what do you do if you suspect or know there was a successful phishing attack against your organization? Here is our list of 14 things you need to do when it happens:
What To Do When You Have Been Phished: 14 Things To Do
1. Activate IR procedures
You do have a phishing incident response plan, right? You have done an IR tabletop to test how smoothly things go, right? After you confirm that you are dealing with a real incident, draw the shades, grab the playbook, and order pizza. You’ll need to figure out the who, what, when, and where of the incident — as well as what time to tell your family you think you’ll be home the next day.
2. Obtain a copy of the email with full headers and any original attachments
Part of your phishing email incident response should be to make sure that you get the phishing email with full headers showing routing info, etc. In Outlook, you’ll have to look at the message’s Properties in order to see all of the email routing information. Take note of the IP address that the message came from. In most cases it will be from a compromised machine of some sort – either an end user’s desktop acting as a bot for the message or from a compromised or vulnerable server. Either way, it will help to have all of this information.
3. Mine the web for threat intelligence
There are a lot of threat intel and lookup sites out there. Take any URLs, attachments, etc., to www.virustotal.com or any of the other sandbox and lookup sites out there. (I personally like www.hybrid-analysis.com.) Take domains, IPs, etc., to sites like IPVoid.com. Google the IP, hostnames, URLs, files, etc., of what you see.
But be careful that you don’t actually go to malicious sites. If you paste an IP into your browser, it will change it to a URL and go to the IP. That’s embarrassing (and potentially dangerous). Rather, put the IP address in quotes to ensure that your browser knows you are just searching.
4. Talk to the clicker(s)
This is a simple step that is sometimes overlooked. Don’t sidestep the end user! Ask any and all clickers what happened, what they saw, and if they noticed anything strange or out of place before or after interacting with the phish.
5. Adjust perimeter email filters to block similar messages
In order to prevent other users from falling victim to the same attack, look for attributes in the email that you can filter on. In some cases the From, Subject, and other fields may change. Look for something that will remain somewhat static. Black listing based on a regex obviously isn’t a long-term solution, but in the short term it can help stop any other messages from getting in.
6. Start searching internal systems
Search your firewall logs for all of the suspicious IPs, URLs, etc., from the email, URL, attachment, etc. to see if there was any traffic leaving your network going to those IPs. Keep in mind that some attacker command and control domains will change their IPs every few minutes. As such, you will want to search your DNS logs (you are logging all DNS requests, aren’t you?) and see if any host on your network did a lookup on them.
Keep in mind you will likely need to search DHCP logs as well to see what workstation had the IP when the DNS lookup happened. (You do have DHCP logs, right?). Use Splunk or Elasticsearch/Logstash/Kibana (ELK).
7. Review proxy or outbound web logs
If you use a proxy such as BlueCoat, WebSense, or the like, it makes sense to search the logs to see if any other users accessed the site or other telltale URLs. Or if you log all outbound firewall requests, check for the IP address of the server that the site is running on.
Want to learn more about phishing attacks? Download our State of the Phish Report .
8. Review mail server logs
Check to see which users received the message by searching your mail server logs. If possible, search on the message ID, source IPs, From, Subject, file attachment name, etc.
9. Review DNS logs
Logging DNS traffic is no longer hard. Enabling DNS logging in BIND is not hard either. When enabled, you can import these logs into Splunk, then run queries on them to see which of your hosts did a lookup on any malicious domains you find.
10. Ensure logs are retained
Nothing stops an investigation cold like a total lack of critical logs. Ensure that your DNS, DHCP, firewall, proxy, and other logs don’t rotate off. Depending on how things go, you may need to save these logs and handle them in a way that will stand up in court. Your IR plan should address this.
11. Make an example out of it
Rahm Emanuel once said, “You never let a serious crisis go to waste. And what I mean by that, it’s an opportunity to do things you think you could not do before.” Remember this quote the next time you are dealing with a successful phishing attack, and use that event as an opportunity to raise security awareness among management and your users.
There’s a reason, after all, that high schools put wrecked cars out front of their buildings during prom season. It hits home because it’s relatable; those who are forced to confront a possibility often can’t help but think, “That could have been me!” But tread softly — you don’t want users to feel that reporting something leads to professional embarrassment.
12. Clean up
As a general rule of thumb, you’ll need to change the affected users’ passwords — even if you are pretty sure that nothing serious happened. Why? Because you’ll never have 100% assurance that the victims weren’t completely compromised.
If a user’s credentials (especially those used for remote access) are compromised, an attacker could come back and use legitimate access methods like OWA or the VPN. After passwords have been changed, review the activity of any impacted user account for a period of time pre- and post-incident.
13. Check for active sessions of affected users
A popular technique among attackers is to leverage legitimate access methods like VPNs and Citrix to maintain a presence within the network and exfiltrate data. Following an attack, collect a list of the affected users and check to ensure that there aren’t any current connections that shouldn’t be active.
You do have a list of every remote access method, don’t you?
14. Train your users to be “smart skeptics”
14. Train your users to be “smart skeptics”
Get proactive! Have you ever received an email and thought, “There’s something not quite right with this…”? Those of us in the security space like to say we have “infosec spidey sense.” But we didn’t get this overnight; it’s a skill that we’ve passively built up over time. Wouldn’t it be great if instead of a Pavlovian response to click on anything in their inbox, your users paused for even 500 milliseconds and though, “Wait a sec…could this be a PHISH?” Use phishing tests and security awareness training to your advantage.
It can be done! Trust us, we’re professionals at this.
Note: This article originated on the ThreatSim® blog. ThreatSim was acquired by Wombat Security in October 2015.
