A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?
Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.
Part 1 and Part 2 covered the first checkpoint in the list – Identify. Part 3 covered the next checkpoint – Protect. Part 4 continued the series – Detect.
Now we’ll move along to one of the most important parts of the checklist – Respond.
So, now you think you’ve got an incident. You may or may not be sure. Now what? Err on the side of paranoia – I’d rather capture data and investigate a dozen false positive vs. missing a true breach or other incident. Let’s get started
- Capture, review and archive all appropriate logs and alert messaging.
Grab the logs. All the logs on any potentially relevant systems, as far back as you can go. Offload them to your syslog server, or another storage location – particularly if your log retention period is short. At the beginning, you don’t know what will be relevant – and there’s no such thing as too much log data.
- Notify management or other teams as appropriate
Now is the time to begin the communications process for a potential incident, as defined in your incident response plan. (You have one, right?) You’ll need the other teams – solo investigations are not a great use of time and resources.
- Catalog each suspicious account throughout the process and immediately suspend the account and/or change the credentials. Be aware that attackers may attempt to reset passwords, especially if automated.
When in doubt, lock it out – and change the password. The inconvenience to a user or group of users should pale in comparison to a compromise.
- Scan for location information, unexpected IP addresses, suspicious subject and email body contents, etc. across the domain.
Check accesses for the “Patient Zero” account or accounts – the potential source of intrusion. Do they have an IP from the Ukraine? Other suspicious items? Check for these potential indicators across your entire domain and related systems – particularly in those logs we grabbed in step 1.
- Review and investigate each potentially compromised account. Don’t assume that the attacker(s) performed the same actions on each account. When you find new Indicators of Compromise (IOCs), scan for them against the entire domain.
I can’t emphasize that highlighted sentence too much. You’re intelligent, and resourceful – and so is your attacker. Anything that is out of the norm, even slightly, should be considered a potential IOC and investigated. If it’s an anomaly, look for it elsewhere.
- Audit each account for outbound email activity and issue email recalls, or alert additional parties as needed and as appropriate in accordance with organizational policies.
- Check each account for email forward, auto-deletion and other automation rules. Note and delete any unexpected rules, using them as IOCs.
Audits and checks are vital. A large number of the incidents we’ve investigated have employed auto-forwards, auto-replies, auto-deletion, and other email rules to obfuscate the attacker’s presence.
- Note and catalog all suspicious email data including from, reply-to, IP addresses, subject, unusual wording or phrasing, links, graphics, etc. Use these as IOCs for further investigation across the domain.
While attacks can be nuanced, attackers will often replicate actions to speed up their intrusion across accounts. Again, anything out of the norm is a potential IOC – if it doesn’t feel right, often it isn’t right.
- If wire fraud or other monetary transaction attacks have been performed, take appropriate steps to notify law enforcement, initiate SWIFT recall messages, perform wire recall processes, notify involved banks of the issue and request cooperation with your team and law enforcement as needed. Double check all wire and ACH information, including receiving bank, routing numbers, etc. to ensure that they are as expected. Consider a period of call-back verification for any transactions in doubt, or from impacted accounts.
This item is for our financial service friends and clients. Follow your organizational process and procedures for wire fraud or other monetary transactions. Be aware that attackers are also patient – it is not unusual for us to see activity in wire fraud cases 3-18 months after the initial compromise. Build your organizational safeguards with the long game in mind.
- Pay particular attention to any email requests to change payment types, payment terms, or locations that originated during the incident, especially from impacted accounts.
Consider this point not only immediately, but for the longer term – as noted above, these items are often used for fraudulent purposes many months after your initial incident.
- Inform impacted employees of the issue and ask for their ongoing vigilance for other problems stemming from the incident or if they observe other unexpected behaviors.
Communicate. Create a culture where anyone can say that something doesn’t look right without fear of repercussions. Again, I’d rather investigate a dozen false positives than let a fraudulent transaction through because someone didn’t want to make waves!
We’ve covered a lot – and there are a lot of nuances here, as well. If you’ve leveraged the first steps in the BEC checklist, you’ll find the actions here will be a lot easier than if you’re figuring things out as you go. (Logs? What logs, and who has access?)
Part 6 – Recovery – closes out the series.
Questions? Comments? I’d love to hear from you – lwallace@microsolved.com, or @TheTokenFemale on Twitter!
If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.