SBN

Malware Analysis Part 2: What benefit does it serve?

In Part 1 of this blog series, we covered a (somewhat) brief introduction to malware analysis. We learned how malware analysis is performed in general and the various types of analysis–triage, dynamic, and static analysis. 

It’s all well and good that there are so many niches and disciplines that tie in to malware analysis, but what is the overall goal? 

Offense Informs Defense

Have you ever heard of the phrase offense informs defense? The idea is that interactions with real cyber attackers–be they vulnerability scans and vulnerability management, penetration tests, adversary emulations, red/blue team joint operations, or actual security incidents–all result in lessons being learned. By looking at what weakness attackers leveraged to gain access, we can learn how they were able to perform these actions. Malware analysis is another tiny piece of this puzzle.

We perform analysis actions and answer questions about the malware in order to inform our defense against the threat a particular family of malware represents. 

But what are some ways in which malware analysis informs defense?

APT Reports

Advanced Persistent Threats (APTs) gain their name by utilizing advanced tactics and by being persistent towards achieving an objective of some sort. 

The advanced tactics they might use include:

  • targeted exploits, 
  • spear phishing, 
  • social engineering, and
  • zero day exploits.

And their persistence manifests when they:

  • attempt multiple methods of entry, 
  • exploit multiple targets within the same vertical, 
  • pivot from targets of opportunity, 
  • utilize multiple persistence methods, or
  • use a “low and slow” methodology.

The reports on these threat groups are the result of months–and sometimes years–of patient counterintelligence operations by security researchers observing their tools, exploits, malware, and targeted verticals. This results in reports that inform the defense of organizations all over the world–researchers provide indicators of compromise (IoCs) in the form of file hashes, network artifacts (e.g. IP addresses, domains, user-agents, and URLs requested), files dropped to disk, configuration files modified, commands executed, and so on. 

Organizations consume the information in these reports and use them to retroactively search for these indicators in their network and endpoint security logs for the length of time that particular campaign was active. This allows them to confirm that they either: 

  • were not targeted, or 
  • if they were targeted, that they were not compromised, or 
  • if they were compromised, the scope by which they were.

Want an example? Let’s jump back to December of 2020, when the SolarWinds backdoor SUNBURST was publicly announced. 

SUNBURST was a backdoor associated with a Russian threat group “APT 29” (Dark Halo, UNC 2452, etc.) FireEye released a report describing the actions the threat group used. They also released a repository of indicators. Between the report, the timeframe by which the campaign was active (according to the report, “This campaign may have begun as early as Spring 2020 and is currently ongoing.”), and the indicators, organizations who utilized SolarWinds during that period could sweep through their logs to see if they were possibly affected.

Threat Intelligence

Threat Intelligence usually comes in the form of blocklists for a wide variety of threats–IoT botnets, Ransomware, Remote Access Trojans (RATs), and so on. These blocklists are mostly the result of analyzing malware–running payloads in a sandbox, deobfuscating and extracting the configuration information for downloaders, reverse engineering RATs, decoding various scripts to see what the malware communicates with for command and control (C2), and so on. 

Just like APT reports, these blocklists typically come in the form of indicators of compromise–such as file hashes, IP addresses, domains, exploits and/or delivery methods used to deliver malware, etc. And also like APT reports, most threat intelligence feed information is meant to be used retroactively to look for threats in a fairly limited timeframe. 

Time for another example: Let’s pick on LokiBot. LokiBot is classified as an information stealing Trojan, but it also has the ability to backdoor targets and deliver additional payloads. 

For this exercise, I’m going to pick on a sample observed on abuse.ch’s malware bazaar. Malware bazaar is a massive database of malware samples with scores of analysis done on each submitted sample–file hashes, sandbox runs, Yara rules, the works. Here is the LokiBot report we’re going to focus on:

27d79e79361f3d086f3c9001d35d51328f513a1061b3a89389d4291cc85427df

Just like VirusTotal, there is a TON of information about the sample in question. Unlike VirusTotal however, anyone can download the sample without needing to pay an arm and a leg for VirusTotal Enterprise.

Additionally, samples are submitted to a wide variety of analysis, triage, and sandbox services for additional analysis (including VirusTotal, ironically enough.)

As you can see from the illustrations above, we have a wide variety of file hash formats we can add to a threat intelligence feed. Users can then utilize the file hashes from this threat intel feed with their endpoint protection tools and logs to see if this version of LokiBot has been observed in their networks. Scrolling further down, there’s also a URL associated with this threat:

hxxp://jlpack[.]email/grace/Panel/five/fre[.]php

While not explicitly listed as an IoC, one could also resolve the domain jlpack[.]email to an IP Address: 104[.]223[.]93[.]105. Now users have additional indicators they can look for in firewall, proxy, netflow and/or IDS/IPS logs. But this is just one instance of LokiBot that was observed in the wild for one day.

Lambda Complex: Half Life of Indicators

Most commodity malware of a given family or type is polymorphic. That means that the malware alters itself slightly resulting in different file hashes for the same malware. If it isn’t polymorphic, the configuration is dynamic and may change the behavior of the malware–it may perform different actions on a host or call back to different IP addresses and domains for command and control. 

Additionally, some malware families are “keyed” or tied to particular target vertical or sub-group of adversaries. All of these factors mean that indicators have a very short half-life for active campaigns. 

Indicators from threat intel reports for APTs have an even shorter half-life before they decay into uselessness because most threat groups are extremely observant, and the moment they realize that security researchers are watching them, have copies of their malware, and/or have mapped their command and control infrastructure, they’re doing everything they can to consider that infrastructure “burned” and no longer associate themselves with it. 

All of this information leads to threat intelligence feeds and indicators of compromise being data that is only useful if it is published both early and often, and then refreshed frequently as malware campaigns change. The best use for indicators of compromise and threat intelligence feeds is to retroactively verify your organization wasn’t a victim or help define the scope of a compromise.

Going back to our LokiBot example above, this is a screenshot of MalwareBazaar entries for LokiBot observed from 9/24 – 9/26:

Every one of these file hashes represent a unique instance of LokiBot, each with unique behavior and unique command and control. These hashes will be seen once–on the day they were first observed–and then likely never be seen again.

These hashes all represent a single instance of LokiBot in a single point in time. Unless intelligence on this threat is timely and is being received the same day it is being observed, this information will not serve to proactively protect your assets. 

On the other hand, however, these indicators can be retroactively searched to see if any systems were compromised by LokiBot on those particular days from now until the end of time.

On the ATT&CK

While this blog post may seem like an overall negative view on threat intelligence (and by extension malware analysis), it really isn’t! Malware analysis and indicators of compromise help inform defense and help defenders to identify specific threats. 

Although the indicators themselves are short-lived for proactive defense and are more widely used for retroactive detection, the techniques, tools, and actions the malware takes are also considered actionable intelligence. 

How many of you are familiar with Mitre ATT&CK? Their matrix consists of a variety of categories such as execution, persistence, privilege escalation, and maps different techniques to those categories. These techniques are attributed to threat groups, malware operators, open-source tools, malware strains, nation-state implants, and so on. We learn about these techniques by observing the attackers and observing the capabilities of their tools and malware.

Many threat groups, tools, and malware variants utilize similar techniques. By observing the techniques of one malware group, it helps the SOC be more observant of that technique and figure out methods to detect the use of particular techniques. This can help enterprises defend themselves against multiple adversaries and malware variants by looking for the tactics and techniques they utilize and how to detect them–rather than sweeping for indicators of compromise assigned to one malware family or a particular malware campaign.

The Mitre ATT&CK matrix identifies multiple categories of tactics and then describes techniques associated to those tactics. Those techniques are then mapped to tools, implants, malware, malware groups, nation-state actors (e.g. APTs), and so on and so forth. The main idea behind the ATT&CK matrix is to understand the techniques being used by multiple actors and/or malware families and understand how to detect the techniques in addition to the pieces of malware themselves via indicators of compromise. If an organization can figure out how to detect a given technique, it offers protection against multiple threats.

Conclusion

In general, the purpose of malware analysis is to gain a better understanding of how a given malware sample behaves. In this way, the offensive actions we observe the malware taking (delivery mechanisms, integrated tools, exploits used, pivoting methods, etc.), its network artifacts (IP addresses, DNS domains, user-agents, URLs, etc.), and host-based artifacts (file hashes for dropped files, added/modified registry keys, modified files, etc.) can be observed, documented, and published in the form of indicators of compromise (IoCs). 

These IoCs can then be used to augment network and/or host-based security products, giving security analysts malicious behavior to search for.

Indicators of compromise, however, have a somewhat limited half-life that defines the period in which they are useful. They are best utilized either while the malware campaign is currently active or to enable searching for artifacts from a particular malware family, malware campaign or threat group at a particular point in time. 

It is in the nature of malware groups and APTs to change their tradecraft, malware, and infrastructure constantly to avoid being caught and/or to attack more victims. That means keeping on top of malware campaigns and keeping up to date on threat reports and/or threat intelligence feeds is a must for security analysts. 

Indicators of compromise and threat intelligence, while a large part of malware analysis, are not the only reason malware analysis is performed. We also want to observe the tactics different malware or tools use to achieve their goals, and the techniques associated with those tactics. The MITRE corporation maintains a matrix of tactics (called MITRE ATT&CK), and the techniques that various malware strains, threat actors, and open-source tools use to achieve a certain objective. Documenting techniques allows researchers to develop methods to detect a given technique. If a technique can be detected, it offers better protection against multiple types of malware and/or threat groups. 

That’s all for this blog post. Stay tuned for part three in which we analyze how malware analysis contributes to incident response.

The post Malware Analysis Part 2: What benefit does it serve? appeared first on Hurricane Labs.

*** This is a Security Bloggers Network syndicated blog from Hurricane Labs authored by Tony Robinson. Read the original post at: https://hurricanelabs.com/blog/malware-analysis-part-2-what-benefit-does-it-serve/?utm_source=rss&utm_medium=rss&utm_campaign=malware-analysis-part-2-what-benefit-does-it-serve