After any major attack or malicious campaign such as the one that SolarWinds disclosed last December, the tendency is to focus on the who-did-it, rather than the what-happened or the what-can-we-learn-from-it. That's a problem for a couple of reasons.
The first is that attack attribution is difficult. Threat actors often employ a variety of techniques to conceal the origins of their malware. The second is that knowing who the attacker is is less important than knowing what you need to do to prevent becoming the next victim.
By focusing only on where malware attacks are coming from, you are forgetting to take into account the nature of past attacks and what you can learn from them. Here's what your team needs to know, so you can increase your cyber resilience.
1. Modern compilers make code analysis a challenge
Previously, you would look for hints in the code itself to see if there was anything that would point to an attacker, likely by doing a Bayesian analysis to generate a probability of where the code originated. Then, you would look at the source code, the binaries, the subroutines, the sequence of instructions, and the language embedded in the code to get an idea of where the malware might have originated.
With today's modern optimizing compilers, however, it has become almost impossible to do that kind of analysis. Everything is moved around and hidden, and things have gotten fuzzier.
2. Comments in language or messages are not good indicators
Tags and the language and variable names in the code can give you an idea of who might have written it. But the reality is that attackers can easily put tags and misleading language in the malicious code that is not their own just to distract defenders and point them in a different direction.
A threat actor can easily put comments in Russian to make it look as though the code originated from a Russian entity, and Farsi or some other Middle Eastern language could make it look like the malware came from the Middle East. So you can't go by those clues anymore.
Another complicating factor is the hacker that attacked your organization could be using code purchased from a threat actor in another country. Players in Russia, China, and other countries sell their malware to different entities, who then weaponize and use the malware in attacks. The reality is that attackers are getting smarter and are not doing dumb things.
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. Some compilers have time stamps that are put into the code, but with globalization, the code could be assembled anywhere. So you can't depend on the stamps or any of the license information in the compiler code.
You can take a look at whom the malware is talking with—the command and communication path. What is the C2 path, where is it going, and what is the termination node? The problem is that it's not easy to trace back through multiple layers. How do you know the attackers are not using multiple compromised machines for C2 communications?
You could always look to see if somebody is taking credit for an attack. But that doesn't prove anything. Hackers have a tendency to take credit for things just to build a reputation.
3. Past tactics should be included in analysis but are often overlooked
You can learn a lot by looking at the style and nature of past attacks. Past tactics can and should be included in analysis but are often overlooked. For example, threat actors from Russia have a tendency to go after infrastructure components such as water filtration systems, the power grid, and the transportation grid for an entire country. In general, their focus is on infrastructure-layer attacks that are designed to create widespread disruption.
The Chinese, on the other hand, are always in it for the long game. Once they get their malware in place on a network, they might not activate it until much later. Their goal is always to gather information and not necessarily to disrupt things. For attackers in the Middle East, the focus is more on ransomware and disruption of services to make money.
Focus on the acts, not the bad actors
At the end of the day, when it comes to becoming more cyber resilient, it doesn't matter who hacked you. It's only in very rare cases that you are going to be able to hold them accountable. So it's better to concentrate on stopping them and preventing the attacks instead. Who did it is far less relevant than how it was done, so focus on what was stolen and how.
Look at the science behind it and what you can learn from it so you don't allow the same thing to happen to you again. And be careful about attribution. If you blame one entity and it was someone else, are you just lying to yourself?
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
