Enhancing cyber resilience: What your team needs to know
In the wake of malicious attacks, we often witness everyone focusing on searching for those responsible, as opposed to how or why the attack took place and the most critical lessons that we can learn as a result. This line of thinking is wrong and here’s why.
To start, attributing attacks to the responsible party or parties is difficult as bad actors use a variety of techniques to mask their malware’s origins. Secondly, we may wish to know who performed the attack so that retribution or justice can be served, but this knowledge does absolutely nothing to prevent such an event from occurring again, perhaps even in the same way.
By focusing on the “where” or “who,” you are neglecting to analyze the nature of past attacks and discover the lessons that can be learned from them.
Enhancing your cyber resilience while applying key learnings
1. Previously effective analysis techniques are nearly useless because of modern compilers
In the past a Bayesian analysis would help identify clues in the code that might lead to a possible point of origin, followed by analysis of the source code, binaries, the subroutines, the sequence of instructions, and the language embedded in the code to paint a picture of where the malware might have originated.
However, today’s modern optimizing compilers make it nearly impossible for those previously effective analysis techniques to produce useful information.
2. Previously reliable indicators are no longer reliable
While certain indicators, such as tags, language and variable names in the code can provide a glimpse at who might have written it, the truth is that these are easily masked by savvy attackers to distract and mislead. A bad actor can simply put comments in Farsi or Mandarin to make it appear as though the code originated in the Middle East or China.
It is also quite possible that the code used to attack your organization has been purchased from a threat actor in another country. So, threat actor A, in let’s say Italy, purchases malware from threat actor B, in Russia, who then weaponizes it and uses it in their attacks against an organization anywhere in the world. And, unfortunately, attackers are getting more sophisticated in their methods and are making less mistakes.
Moreover, attackers also often reuse and share codebases, so it can be hard to attribute a particular piece of malware to a specific threat actor with any certainty. And while time stamps can be found in the compilers, the code could have been assembled anywhere in the world so you cannot depend on that or the license information also found in the compiler.
You could analyze to whom the malware is talking to by looking at the command and control (C2) path, but what if the threat actor is using a layered vector with multiple compromised machines for C2 communications?
3. Don’t overlook past tactics in your analysis
A lot can be gleaned by evaluating the style and nature of previous attacks, though often they are ignored or overlooked. As an example, there is a strong tendency for bad actors from Russia to target the infrastructure of an entire countries (think water filtration systems, the power grid, etc.). Generally speaking, these infrastructure-layer attacks are meant to create widespread disruption.
Threat actors from China, on the other hand, play the long game. Once malware is placed on a network it might not be active for months, or even years. The goal here is to gather information, as opposed to causing disruption. For those attackers that are based in the Middle East, an analysis of previous attacks would indicate ransomware and disruption of services to make money.
4. Focus on the how, not the who
When all is said and done the goal is to become more cyber resilient, and that means who did it is far less important that how it was done and what was stolen. Becoming more cyber resilient necessitates identifying the methods and gaps in security that allowed for the hack to happen in the first place.
Identify and analyze the science behind the hack and focus on what you can learn from it, so you don’t allow the same thing to happen to you again. And be weary of attributing hacks even if you have indicators.