Cyberattack Attribution: Don’t Rush to Judgment 

It’s only human to want to attribute blame when a cyberattacker breaches your company’s network. But while attribution has some value — at the right place and time — in most cases, that information is not going to help your immediate incident response.

That was the takeaway from Mimecast’s recent webinar, “Attribution, Fact or Fiction?”, where we hosted Sam Humphries, Head of Security Strategy at Exabeam. A Mimecast partner, Exabeam specializes in threat detection, investigation, and response workflows for security teams. You can watch the webinar on demand here (and the attribution discussion begins at minute 18).

How Attribution Can Slow Incident Response

Incident response should be driven by three priorities: Stop the attack, eject the rogue software, and recover. Here’s how Sam described the many risks inherent in prioritizing attribution instead:

“If you start running down the path of attribution, that will skew your thought process as you go through your investigation and response. You’ll look for stuff that isn’t there. … You’ll ignore information that doesn’t back up your ‘hot take’ on who attacked you. Or you’ll accept unsubstantiated falsehoods.” Above all, “you can waste time, and time in an investigation is absolutely at a premium,” she said.

About half of incident responders surveyed said that incident responses typically take two to four weeks, according to Mimecast partner IBM,[1] and companies’ losses are measurably lower for shorter investigations and downtime.[2] In many cases, especially advanced persistent threats (APTs), the attack may already have been in progress for far longer. 

Not only is attribution the wrong starting point for an investigation, but it’s also increasingly difficult to identify which nation-state actor or cybercrime gang is to blame. Investigators may find themselves up against false flag operations in which attackers deliberately plant red herrings such as foreign language characters in their code. Also, ransomware-as-a-service, email phishing kits, and other hacking tools are readily available for sale on the dark web to “script kiddies” — those unskilled newcomers who are swelling the ranks of cyberattackers. These kits make for a lot of lookalike attackers. Our webinar included another example of obfuscation, with the anatomy of an “impossible travel” exploit in which the attack appeared to migrate in real time across the globe. 

If an attack is still in progress when detected, “they’re essentially exploring a system and internal network to see what they can control, what they can steal, what else they can attack,” according to a report from Mimecast partner Palo Alto Networks. They may also be in the process of exfiltrating your company’s trade secrets, customers’ personal identity information, or network access credentials.[3]

So it’s important to turn your immediate focus on what’s going on — not who might be behind it — and answer three key questions:

• What have they done?
• How did they do it?
• Did they steal anything?

When Attribution Matters

Timing attribution is essential. While not a priority in most cases, attribution has important value at the right time, and it can be essential in some cases. 

Government agencies often need to identify nation-state actors for geopolitical reasons. Insurance companies also want to know who is to blame, and one major insurer recently announced it would no longer cover so-called “acts of war” by nation-state actors. That’s why many incident responders should dedicate a latter part of an investigation to attribution.

Another time to look at attribution is in advance — to build defenses against attacks. Threat intelligence can identify the tools different attackers use, their methodologies for accessing a network, and their typical targets. So a hospital, for example, can use threat intelligence to defend against known attackers in the healthcare industry.

In the heat of an attack, however — even though knowing different attackers’ modus operandi can be informative — attribution is a risky starting point for incident response. Asking “who” and not “what” can take responders down a rabbit hole, causing them to close off other lines of investigation that could lead to the real attacker’s actual activity in your network. Usually, attribution should wait.

Six Steps for Incident Response

Exabeam recently published a six-step incident response plan,[4] including:

1. Preparation: Tasks at this stage include forming an incident response team, for example, and ensuring that a plan of action is in place.
2. Identification: This is the time to assess the incident, gather evidence, and escalate, as needed. Email-based threats present a particularly difficult challenge here due to their volume and complexity as cyberattackers’ preferred means of launching an exploit.
3. Containment: This step involves triaging by isolating network assets, for example, and ensuring backups.
4. Eradication: Here is where the response team removes malware and patches the network vulnerabilities used for access.
5. Recovery: At this point, it’s time to carefully bring cleaned-up systems back online.
6. Lessons Learned: Debriefing and documenting what happened could include attribution.

The Bottom Line

Attribution of attacks to a particular cybercrime gang or nation-state actor has pluses and minuses — but mostly minuses in the heat of an attack on your company. That’s because it can bias incident responders and cloud visibility into the real threat that needs to be addressed. A Mimecast webinar recently discussed this all-to-human problem of bias in incident response, and you can watch it on-demand (at minute 18).

[1] “Cybersecurity Incident Responders Have Strong Sense of Service,” IBM

[2] “Cost of a Data Breach 2022,” IBM

[3] “2022 Incident Response Report,” Palo Alto Networks

[4]“Incident Response: 6 Steps, Technologies and Tips,” Exabeam