Phishing Incident 101
Your company has been spear phished. Congratulations, you’re now targeted by the bad guys. Google, RSA, The Onion, and infinitely more non public incidents are in the same club.
The majority of security breaches are caused by a few highly reliable vectors. Phishing is one of them, and has been for a long time.
This is a reference for handling traditional phishing incidents that result in a breach.
How big was this attack?
Our first goal is to understand the breadth of the attack while we create a checklist of items that will eradicate the breach.
We assume you already have a single phishing email with which you can discover other parts of the campaign. Your goal is to find other victims. Here is an example spear phish that compromised The Onion.
Dig through email for other messages that share similar characteristics. Exchange can be queried using powershell; Google apps record search is fairly limited unless you’ve setup some sort of email retention proxy or Vault.
- An email from Elizabeth Mpyisi?
- emails from “mpyisi”
- emails from unhcr.org?
- emails with “Thanks & Regards” within this timeframe
- emails with that URL?
- emails with that anchor text?
- emails with undisclosed recipients within this time window?
You may quickly realize that more attacks have happened that haven’t been found. Don’t assume the only phish reported is the only phish involved. There’s always more attack data to be found.
Are there upcoming phishing sites?
You may only be seeing the very beginnings of a string of attacks against your employees. Open source intelligence may reveal other phishing sites or command and controls that could be used in future attacks against yourself or others. If not, it never hurts to understand the adversary’s infrastructure.
These intelligence tools may include Reverse IP, Passive DNS, and other techniques may reveal an attack that will take place next week, or ongoing attacks against your peers / competitors hosted on the same infrastructure. You can proactively detect these attacks if you know about the full range of infrastructure that will be used.
Was there an attachment?
To accomplish any goal, an attack will either social engineer a victim with manipulating conversation, drop malware on a machine with an attachment or exploit, or manipulate the user into sharing credentials with a spoofed page.
An attachment spawns several investigative opportunities. For preliminary work, it will have a file name, an MD5 hash, and a file size. VirusTotal will provide further context if it’s known commodity malware. The malware will also describe how much investment the adversary has put into their campaign against you.
These characteristics are useful for finding other samples that may have been involved in the campaign to other employees. For instance, a similar file name (“financials.xls.exe” and “eom_report.xls.exe) or different MD5's with the same name. It can be tough for an attacker to keep their campaigns from brushing up against each other with these similarities, which is your advantage against them.
For example, your phishers may spend incredible time and effort with individually crafted campaigns across multiple departments and victims, but if they all share the same command and control — it can all be crippled instantly with a firewall rule. Finding these commonalities is crucial.
What does the malware do?
This is hard if you’re unprepared, but a DIY investigation of malware would require an airgapped laptop and the ability to do network traffic analysis. Or use a tool like Malwr.
My stronger recommendation, though: hire a good security consultant to crack open the malware. If you don’t feel comfortable handling volatile malware, don’t. A reverse engineer will look for the following:
- A command and control destination, or unique hosts / protocols controlling the malware
- Any specific credential targets
- Persistence characteristics, like a launchd entry
An external firm will be able to help determine if a complicated exploit was used. Don’t you wish you had a security team at this point?
What’s happening to my network?
Keep a running list of any suspicious domains or IP addresses were used for a phishing site, landing page, or command and control. These are called Indicators of Compromise and help discover hosts the bad guys have captured.
Hosts on your network that access IOC’s have nonzero probability of being owned depending on their usage. For instance, a laptop visiting a basic phishing site can be a bad thing, but communication to a command and control is a really bad sign.
Obtain access the edges of your network and perform traffic analysis with a packet capture tool. If traffic is going to any of these hosts (assuming it’s not shared by other legitimate use) you may have discovered more victims.
Add those victims to a list.
A more prepared security team may have this data retroactively through tools like Bro, Moloch, Snort, DNS logging, proxies, etc. They would easily gain certainty as to whether malicious code was ever brought down or if credentials were sent out. Without these items expect that you’ll spend some time in a network closet figuring out how you can access this traffic for the first time.
The hardest part is looking for lateral movement between known compromised hosts and other machines on your network. If the attack succeeded to this extent, your own machines will become the indicators of compromise. This is a very scary feeling.
What credentials were targeted?
Were Twitter logins targeted, or an internal tool? Depending on what was targeted and the attacks success you will want to consider shutting down general access to these tools or websites. Of course - you can’t shut down Twitter, but you may be able to temporarily deny browser access to it for a short timeframe while you try to understand what’s going on.
For each type of credential, consider the ways you can deny access to their resource from your at risk employees. It may be a firewall rule, DNS sinkhole record… or even shouting your way around the office warning your employees not to visit the threat.
Should you enforce multifactor?
Multifactor is not an all-in-one defense against active threat phishing attacks. Any decent phish will very easily steal most second factors as well (Google Authenticator, for example). However, MFA does box in an attack by denying access to other hosts with the same password, and time boxing a bad guy’s potential access to within seconds which is good for forensic follow up.
MFA is still very useful for stored credential attacks, keylog dumps, etc. If the targeted credentials support multifactor, use this incident to turn them on with the political momentum a breach usually provides.
This all said — while MFA would have been good to have before the attack, it is a great response mechanism because your attacker did not have to deal with MFA originally.
Did password resets destroy sessions?
An extremely common vulnerability is mishandling of password resets. Password resets are frequently in response to an account takeover. You need to make sure the reset flow also destroyed all current sessions. If you need to write any tools or scripts that massively reset passwords outside of the typical user flow — make sure you’re destroying current sessions as well. Otherwise, the attacker will just hang out and keep wrecking houses with their current session despite the user’s new password.
Am I ready to contain the attack?
It is impossible to say when you should start containment as every attack is different. Depending on your risks and tolerance of risk, you may want to take early measures to contain the attack. Deleting known phishing emails from inbox is a common one. However, blocking access to tools or wiping malware too early may simply be inefficient until you know more about how successful the bad guys were.
Don’t jump to high effort containment until you feel confident you have answers to most of the above.
Prevention
You can’t really prevent phishing, but you can reduce the consequences of successful attacks. A quick response is sometimes the only answer. I wrote a lot about overall security practices here. If you‘re specifically concerned about spear phishing, here are the big ticket items.
Education
Employees need a place to report scary things. They need to know where they can freak out. Set up a mailing list, a slack / hipchat / irc channel, or some other kind of on-call. Then reward people who find bad shit. Make sure they all know it as well as 911.
Never punish a false positive. Do not become a scary authority figure.
If your culture allows it, there’s no problem with some satire to keep everyone level headed. Addresses like panic@, freakout@, snafu@ all work, or the more traditional cert@ or security@.
Lastly, phish your employees and reward them for reporting to the addresses above. I’ve done this with huge success. You have an opportunity to educate about passwords, typo’d domains, and multifactor while everyone is in a fuss about receiving these phishes.
Multi Factor Everything
A 20 character random password is just as vulnerable as “12345” once it’s phished. Basic passwords are extremely vulnerable for way too many reasons. Complexity rules are important, but not as important as a second factor.
Password Manage Everything
In addition to a second factor, password uniqueness is critical. LastPass, 1Password, Okta, Meldium, OneLogin, etc, are all password manager and Single-Sign On providers that help consolidate the password problem in different ways by managing complex passwords across many places, or consolidating a single strong authentication point across many places.
Modern Browsers
Chrome is simply the most secure browser due to massive security investment by Google. Configure “Click to Play” on the browser to prevent the vast majority of exploits.
Managed Endpoints
If you can’t search your laptop fleet for a piece of malware, then you’ll be walking desktop to desktop removing malware manually. Or, you’ll end up wiping everything instead, which isn’t pleasant.
Email Delivery Policies
Delivery polices make it significantly harder for the bad guys to spoof your corporate email address without typo-jacking the domain. They’ll end up having to spoof something else entirely, which is not as effective as spoofing a teammate on your own brand. Look into setting up SPF / DKIM / DMARC in DNS, with email delivery signing your outbound emails.
There are also email client configurations to be made that reveal phishing even if it lands in the inbox.
@magoo
I’m a security guy, former Facebook, Coinbase, and currently an advisor and consultant for a handful of startups. Incident Response and security team building is generally my thing, but I’m mostly all over the place.
