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”
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.