Throughout my career, I have witnessed many cyber security professionals adopting a “shoot and don’t ask questions” approach when dealing with malware. They were only ever seeking to understand if a file is good or bad. Once you know it is bad, why bother understanding what you’re up against, where it originated, or what is its intended purpose? Simply terminate the process, delete the file, and problem solved.
At first glance, this seems like a reasonable idea.
In the commonly adopted NIST Incident Response Lifecycle (see picture below), the second stage is ‘Detection & Analysis’. In following the simplistic approach described in the beginning of the Lifecycle, the subsequent Analysis process appears not to be wholly necessary. It doesn’t seem all that important to do in order to complete the next stages, which include the ever-critical Containment and Recovery.
After detecting malware running in your system, you probably have enough information (such as the infected computer, process ID, file path, etc.) to contain, eradicate and recover needed files and processes. Why, then, in most incident response standards today, it is important to both analyze and understand threats after the initial detection? This is what I’ll discuss in this blog post.
* NIST Incident Response Lifecycle (check out Komand’s useful blog series, explaining the cycle in more detail).
One of the most important things to do after an incident is to make sure you are prepared and protected from a similar attack; indeed, this will be a requirement for EU companies under the forthcoming General Data Protection Regulation (GDPR). Otherwise, you’d be wasting your time responding to alerts that have already been handled. Extracting IOCs from malware as part of the Post Incident Activity and applying them in your currently installed solutions such as firewall and anti virus software is a very good step toward being prepared for a similar incident to come. Yet again, generating the hash of the malware or looking for some IPs is hardly considered an analysis.
Here’s the thing, though: if a hacking group wants to penetrate your organization, the fact that you have detected and removed malware won’t make them stop. On the contrary, it would force them to use more sophisticated malware and stealthier tools the next time.
As such, if our SoC or Incident Response team ‘shoots and doesn’t ask questions,’ they essentially make us blind to the security status of the organization.
Not performing a deeper analysis after the initial infection prevents us from performing an effective remediation to the actual problem. Instead of healing the disease, we instead would be treating only the symptom.
In order to treat the root cause, we should first ask these three key questions during the analysis stage:
1. What are the malware’s capabilities? (e.g. Information theft, Banker, Ransomware, etc.)
2. Who is responsible for the attack? (e.g. Nation state, criminal group, level of adversary, is it a known campaign, etc.)
3. How did the attack happen? (how did the malware manage to bypass all existing security solutions, etc.)
Knowing the answers to these questions would help us to remediate the main problem, since we could understand how to stay protected against the adversary, rather to simply avoid infection from the exact same sample or file.
Forcing the attackers to change their method of operation would be a hard blow to their ability to hack your systems. For example, if you know your adversary usually uses satellite ISPs as C&C and you block or set up an alert regarding such outgoing traffic, it’d be extremely hard for them to recover. If you manage to force your attacker to rewrite all of their code from scratch, it would be a huge hit as well.
In addition, knowing the answers to these three questions will also enable you to assess the risk that the malware poses to the business and to prioritize your response accordingly, relative to other alerts. In a modern SoC that deals with thousands of alerts every day, it is critical to know what to handle first. This approach to prioritization could give your organization the ability to spot a single alert that is, in fact, nation-sponsored malware hiding within hundreds of other alerts. That would probably save many organizations from some very unfortunate and embarrassing consequences.
The problem is that it’s difficult to answer these questions, and even harder to do it quickly. I believe this is the main reason why companies are compromising with the simplistic approach described at the beginning of this post. Getting to the bottom of these questions usually requires reverse engineering skills and a lot of time, which most organizations don’t have on hand.
Even understanding something fairly simple such as the malware’s capabilities is not straightforward at all. When discussing the capabilities of malware, people often discuss irrelevant technical details, since that is what sandboxes and other malware analysis solutions can only explain most of the time. These solutions can ascertain which files the malware created and which registry keys were modified, but the CISO or the CERT/SoC leader doesn’t care about that. They care about whether it’s a Trojan horse, a Banker, or a Ransomware; that’s what really matters in order to fully understand the situation.
At Intezer, we believe that we’ve managed to close this critical skill gap, allowing organizations to answer these necessary questions in a matter of few seconds. For instance, our technology was able to discover the link between WannaCry and the alleged North Korean malware Joanap and Lazarus which allowed our customers to not only immediately detect this type of malware, but also to know this threat is related to a nation-sponsored attacker and to prioritize their efforts toward mitigating it.
In addition, our technology enabled our customers to create antidotes (e.g. YARA signatures) that could be installed on their existing security solutions, which cover all of the Lazarus code base. As a result, the adversary would need to completely rewrite its code from scratch in order to attack the organization. Writing new software without reusing code is one hell of a ride.
In another recent case, we discovered new variants of the Turla hacking group. Knowing that a certain sample shares code with this attacker immediately allows to understand the intentions, capabilities, and level of sophistication behind this specific type of malware.
We invite you to check out Intezer Analyze™, our product that provides a deep, rapid malware analysis solution using our unique technology, which covers the ‘Detection & Analysis’ stage in your incident response plan.
To conclude:
1. Simple detection (good/bad) without investigating is not enough.
2. Deep analysis of malware is necessary to protect your organization from modern threats.
3. Organizations should seek to understand who is responsible for attacks, and to make themselves immune against the adversary itself versus just a single instance of malware.
4. If you’re interested in improving your team’s detection and analysis process, we would be happy to show you how Intezer can help. Contact us here.
About Intezer:
Through its ‘DNA mapping’ approach to code, Intezer provides enterprises with unparalleled threat detection that accelerates incident response and eliminates false positives, while protecting against fileless malware, APTs, code tampering and vulnerable software
Co-founder and CEO of Intezer, on a mission to revolutionize the way we investigate and respond to cybersecurity incidents. Once led a government CERT.
