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. This is essentially asking “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?”
Almost a year ago, I posted Fighting The Advanced Attacker: 9 Security Controls You Should Add To Your Network Right Now to the ThreatSim blog. This is a list of security controls that I feel will help any organization create a defensible network. The list includes both preventative and detective controls. If you aren’t doing at least some of these, you are going to be in trouble when someone clicks on something they shouldn’t have.
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 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 13 things you need to do when it happens:
1. Activate IR procedures – You do have one, right? You have done an IR table-top 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 need to figure out who, what, when, where, and what time to tell your family you think you’ll be home tomorrow.
2. Obtain a copy of the email with full headers – Make sure that you get the email message with FULL headers showing routing info, etc. In Outlook you have to look at the message’s Properties so you can 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 helps to have all of this information.
3. 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, we just want to stop any other messages from getting in.
4. Block URL at firewall – If the phish was a drive-by or data entry style phish, block the URL ASAP so that any other user who received it won’t be able to access the URL.
5. Review proxy or outbound web logs – If you use a proxy such as BlueCoat, WebSense, etc. it makes sense to search the logs to see if any other users accessed the site or other tell-tale URLs. Or if you log all outbound firewall requests, check for the IP address of the server that the site is running on.
6. Review Mail Server Logs – Check to see if any other user’s received the message by searching your mail server logs. If possible search on the message ID, source IPs, From:, Subject:, file attachment name, etc.
7. Reverse engineer the malware – If the attack was a drive-by style phish, see if you can get ahold of the payload that was used to compromise the victim’s device. NOTE: caution should be used when clicking on links in a known phishing email. Trying to reverse engineer the attack should only be performed by someone who knows what they are doing. If possible, see where the exploit causes the victim’s machine to phone home. It will either be an IP address or a domain name. Which is useful in the next step…
8. Review DNS logs – I know, logging DNS is hard. But it can be done. Check out my popular post Analyzing DNS Logs Using Splunk. Basically you can push Windows domain server logs into Splunk, then run queries on that to see if a client performed a lookup for that domain. This is helpful if you are able to get the IP or DNS name that the victim connects to from #7 above. Search to see which clients requested the DNS name, and start investigating those too.
9. Ensure logs are retained – Nothing stops an investigation cold like a total lack of critical logs. Ensure that your DNS, DHCP, firewall, proxy, etc. 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.
10. Make an example out of it – “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. -Rahm Emanuel”. There’s a reason that high schools put wrecked cars out front of high schools during prom season. It hits home because it’s relatable. “That could have been me!” Use an event like this as an opportunity to raise awareness among management and your users. But tread softly – you don’t want users to feel that reporting something leads to professional embarrassment.
11. Change Passwords – As a general rule of thumb, change the affected user’s passwords even if you are pretty sure that nothing serious happened. You will never have 100% assurance that the victims did or didn’t get completely compromised. If a user’s credentials (especially those used for remote access) are compromised, an attacker may come back and use legitimate access methods like OWA or the VPN.
12. Check for active sessions of the affected users – A popular technique among attackers is to leverage legitimate access methods (e.g. VPN, Citrix, etc.) to maintain presence within the network and to exfiltrate data. 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?
13. Train your users to be “Smart Skeptics” – Get proactive! Have you ever received and email and thought “There’s something not quite right with this email…”? Those of us in the security space have “infosec spidey sense”. It’s a skill that we passively build 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 said “wait a sec… THIS IS A PHISH”? It can be done! Trust us, we’re professionals at this.
ThreatSim allows customers to launch immersive on-going phishing simulations. Users that are (gently) stung a few times by one of our mock phishing messages will develop a Pavlovian response to new email by giving the message a smart skeptic’s glance. They will mouse-over the link. They will perform a quick mental risk assessment that may make the difference between the user reporting the phish and you ordering pizza and launching your IR plan. Is user training a silver bullet*? No! But it is something you can do to proactively get ahead of this threat to drastically and measurably reduce your risk.
*TheatSim actually comes armed with a whole extended clip of really shinny bullets, but that’s another post.