February 28, 2024

In 2022, the Malwarebytes Threat Intelligence Team identified a suspicious email targeting a government official from Jordan’s foreign ministry. The email contained a maldoc (a malicious Excel document) designed to drop a backdoor named Saitama via an Excel macro. It included the coat of arms of the government of Jordan in both the email signature and within the document to increase its credibility. Given this customisation, had a defender been relying on something as simple as content hashes (e.g. SHA256) on the content or attachment, these would have failed to match this original, targeted content.

The Saitama backdoor included commands containing internal IPs and domain names (like ise-posture.mofagov.gover.local), indicating that the malware was clearly targeted and that the attacker had knowledge about the foreign ministry of Jordan’s internal infrastructure. The attack was attributed to APT34, an Iranian threat group linked to previous attacks on the government of Jordan.

This targeted maldoc was sent to an official from the government of Jordan. Source: Malwarebytes

Let’s assume for a moment you work in the targeted government department and that while you have a security team, you don’t have a specialist malware analysis team. Perhaps your go-to malware analysis strategy is to either look for hashes on VirusTotal or submit the file itself to run it through a public malware analysis engine. We know that the hash lookup will fail since it’s unique content. It’s also very much undesirable to have this document floating around in public with evidence a named government agency has been attacked along with possible victim information such as names, email addresses, and other PII. So, what should you do instead?

In this article, we’ll explore the threat of unique malware and steps organisations are taking to fight it with the help of tools like Cosive’s MalwareZoo, which is purpose-built to privately store and analyse sensitive, targeted malware.

What is unique malware?

While commodity malware is designed for general use against a broad range of targets, unique malware is designed for specific, targeted attacks against an organisation, facility, or individual.

Commodity malware has known signatures (recognisable patterns in the malware’s executable code) and file hashes (a “fingerprint” of a known file created using a cryptographic hash function) and can be defended against using a combination of antivirus software, Endpoint Detection and Response (EDR) software, community knowledge sharing via tools like VirusTotal and MISP. In contrast, unique malware typically lacks any known signatures and file hashes, making it difficult to defend against with traditional automated methods.

Unfortunately, the use of unique malware appears to be on the rise, with the latest BlackBerry Quarterly Global Threat Intelligence Report white paper showing a 70% increase in unique malware samples associated with attacks against BlackBerry Cybersecurity customers. 

Source: BlackBerry. Volume of attacks and unique malware hashes over time.

Why do threat actors create unique malware?

Unique malware is effective for three main reasons:

  1. Avoids signature detection. Due to its unrecognisable signatures and file hashes, unique malware is often able to evade automated detection methods that are otherwise effective in stopping commodity malware.
  2. Tailored to the target. Unique malware can be tailored to the systems, networks and processes used (or most likely to be used) by the target.
  3. Increases credibility with individual targeting. Unique malware can be seeded using custom maldocs (often malicious PDF, Word, and Excel docs) carefully crafted to appear to originate from trusted parties and tailored for individuals such as from an executive within the targeted organisation. The 2022 attack against the Jordanian foreign ministry is an example of this technique being used in the wild.

The trade off for these advantages is that custom malware takes significant time, bespoke development, and reconnaissance to create.

How do malware developers create custom malware?

To create custom malware, the malware developer must learn as much as possible about the target’s systems, network architecture, security controls, and potential vulnerabilities. Further, unique malware developers often implement advanced evasion techniques, such as polymorphism (changing the appearance of code without altering its function) and obfuscation (making it difficult to understand the true purpose of the code). They may also leverage zero-day exploits, which some malware developers purchase at significant expense from cybercriminal forums. 

Source: August 2023 BlackBerry Quarterly Global Threat Intelligence Report

Why might the use of unique malware be on the rise?

Due to the resources and technical sophistication required to create unique malware it is most commonly deployed by well-funded and/or state-backed threat actors, including Advanced Persistent Threats (APTs) and ransomware groups. It is typically used against high-value targets including government agencies, large enterprises, and strategically important assets like critical infrastructure providers and facilities.

There are three main factors that are thought to contribute to the recent increase in unique malware:

  1. As our ability to automatically detect commodity malware improves, unique malware has become more appealing to attackers as an alternative because of its superior ability to evade common detection mechanisms.
  2. Several factors may be making unique malware easier to produce, including Malware as a Service (MaaS) kits, and malicious LLMs.
  3. An increase in the number of well-funded, sophisticated threat actors means there are more malware developers with the motive and capability to create targeted malware.

Let’s explore each of these factors in-depth.

How does unique malware evade antivirus software and EDR?

Endpoints, often Windows workstations, are one of the most common vectors for malware entry. In an organisational context, an endpoint is any remote computing device that communicates with the network. In larger organisations, endpoints are typically protected by both antivirus software and Endpoint Detection and Response (EDR) systems. These are often an organisation’s best frontline defence against malware entry.

The first line of defence is antivirus software (AV) and EDR. At a basic level, AV typically works by using signature-based detection to recognise known, commodity malware. Files are checked against a database of malicious file signatures - if there’s a match, the file will be flagged as malicious. Meanwhile, although EDR is recognised as more advanced in using behavioural analysis to determine the intent of unknown file artifacts, EDR tools share some of the same techniques as AV software to defend against malware.

Signature-based detection methods typically break down when it comes to unique malware, because the unique malware has not been seen before and therefore won’t appear in the AV tool’s database of malicious file signatures. This could potentially allow the malicious file to slip through AV undetected.

As a result, recent advancements in AV technology have seen a shift away from solely relying on signature based detection. Instead, other detection methods are becoming more common:

  • Heuristic detection. Heuristic analysis is the process of statically analysing code for signs of suspicious behaviour.
  • Behaviour-based analysis. This type of analysis focuses on monitoring the behaviour of executables and files for suspicious activity. 
  • Machine learning. Rather than looking for specific patterns in code or behaviour, machine learning algorithms assess similarity between executables, processes and files and a corpus containing known benign samples and malware.
  • Community based threat intelligence. Many AV tools now tap into a wealth of community threat intelligence from sources like MISP feeds and VirusTotal. Even if a sample passes signature-based, behaviour-based and machine learning detection phases, it can still be flagged as malicious based on community consensus.

Since developers of targeted malware tend to attack high-value targets, they typically write this malware with built-in evasion techniques that assume the above defences will be in place.

Evasion techniques used in targeted malware

To evade heuristic and behaviour-based detection, it’s common for malware to use polymorphic and metamorphic techniques (T1406). Polymorphic malware is designed to frequently and automatically change its code or signature while still retaining the same underlying malicious functionality. Meanwhile, metamorphic malware goes even further, rewriting itself every time it is executed. This makes it difficult for behavioural analytics processes to build a consistent sample of malicious behaviour.

Obfuscation is another common evasion technique, designed to make the code difficult to statically analyse (T1406). This may include techniques like cryptographic obfuscation–in other words, encrypting the malware payload so that it’s unreadable to static analysis processes. The payload is only decrypted when the malware is executed.

Unique malware is often developed with environment sensing capabilities, such as virtualisation and sandbox evasion (T1497). This includes gathering telemetry about the system it is running on to determine if it is running in a sandbox environment. If it senses that it is running in a sandbox, it is designed to avoid malicious behaviours. It may even be designed to execute benign behaviours in an effort to remain inconspicuous.

Targeted malware may also include execution guardrails to prevent execution of specific (or all) behaviours outside of a target environment (T1480). This technique can be used to ensure the malware only executes in the targeted environment. Execution guardrails could include things like checking the target's DNS domain, IP address, or for the presence of a certain file before executing. A prominent example of the use of execution guardrails was Stuxnet, which checked for specific operating system versions, registry keys, and dates for vulnerabilities before executing.

A malware developer that has conducted extensive reconnaissance on the target may be able to design malware to use targeted “Living off the Land” (LotL) techniques (e.g. T1059). These attacks use authorised processes and software on the system to execute malicious behaviours. If the malware developer is able to gain intelligence on the processes and software used by the target, they may be able to design the malware to use them. For example, if the developer knows that the target uses Powershell, they could potentially disguise the malware under the guise of legitimate Powershell execution.

The most challenging technique to defend against using AV and EDR systems is the use of zero-day exploits (e.g. T1203). Targeted malware that attacks zero-day vulnerabilities is particularly difficult to defend against. It leverages exploits, files, and processes that have never been seen before. Given that so much of AV and EDR is based on recognising malicious patterns, the absence of patterns in targeted malware containing zero-day exploits makes it particularly difficult to detect.

Why would MaaS and malicious LLMs contribute to the rise in sensitive malware?

Malware as a Service (MaaS) makes sophisticated malware accessible to threat actors who may not have all the technical skills required to produce it themselves. By harnessing MaaS, malware developers can build on top of an advanced foundation which already includes many built-in evasion techniques. This means they only need to write the code required to tailor the malware to a specific target, dramatically reducing the amount of effort and technical skills required to produce bespoke malware.

In a similar vein, LLM-backed AI coding assistants may also have contributed to the rise in targeted malware through lowering technical barriers to entry. Just as these tools have provided significant productivity gains to legitimate programmers, they also have the potential to aid the work of malware developers. Content moderation aimed to prevent malicious use of LLMs has often proven relatively easy to bypass. Even when mainstream LLMs effectively stamp out malicious use cases, malicious alternatives are readily available for purchase on the dark web. In short, we must assume that malware developers will make heavy use of LLMs to produce increasingly sophisticated and targeted malware more easily and quickly than ever before.

Why do malware analysts often find unique malware difficult to analyse?

Let’s imagine that a malware analyst has obtained a sample of suspected malware from within their systems. Perhaps it is a suspicious email attachment, a potential maldoc, for example. Analysts will typically upload the sample to a threat intelligence platform like MISP or VirusTotal looking to tap into the security community’s existing knowledge about the sample. This workflow works well for commodity malware, but unique malware makes this process difficult for a couple of reasons:

  1. Targeted malware has the potential to be highly sensitive and may not be appropriate to share with the broader security community. For example, imagine that a community analysis of targeted malware reveals that a state-backed threat actor has launched a sophisticated attack against a large, publicly traded company. There are many potential ramifications to this information becoming public, primarily tipping off the threat actors that they’ve been detected which may lead them to adjust tactics. There’s also reputational damage to consider, including possible downward pressure on the company’s stock price, alarming news headlines, diplomatic and strategic implications and legal and regulatory considerations. These days multiple jurisdictions have mandatory disclosure laws but these are usually carefully coordinated; an analyst’s uploading of a sample resulting in defacto public disclosure will no doubt trigger strong opinions from an organisation’s management. It is for these reasons that we built MalwareZoo, which gives organisations their own private repository for storing and analysing highly sensitive malware without sharing it with the broader community.
  2. Collaborative threat intelligence tools like MISP and VirusTotal may have few community insights to offer when it comes to targeted malware. Since targeted malware has never been seen before it is unlikely to match the known IoCs, file hashes and signatures that usually make collaborative analysis tools so powerful.

Although the unknown nature of targeted malware limits the effectiveness of collaborative analysis tools, services like VirusTotal can still be helpful when it comes to automated malware analysis. It combines multiple AV engines to run samples through a battery of automated analysis tools, providing a score on the likely maliciousness of the sample. This process can also lay an effective groundwork for human analysis of samples in a sandbox environment.

However, it may not always be an option to upload a malware sample to a crowdsourced intelligence platform like VirusTotal. You can submit samples privately with a sufficiently well-budgeted subscription but by default, VirusTotal isn’t private, and uploaded samples are shared with the broader community. In the case of organisationally sensitive malware this may not be appropriate, especially when unique maldocs often contain information that can be traced back to the targeted individual and/or organisation.

When it comes to dealing with malware that is both sensitive and targeted, this puts malware analysts in a challenging position. The sample may have evaded AV and EDR. The sample may also be too sensitive to share with the crowdsourced threat intelligence platforms like MISP and VirusTotal. This leaves the analyst without much information to go on. Given that targeted malware is often more sophisticated than commodity malware, and may include environment sensing capabilities, it can also be difficult to reverse engineer and analyse in a sandbox environment.

How can organisations defend against sensitive, targeted malware and maldocs?

There are two aspects to defending against sensitive, targeted malware: detection and response.

To detect unique malware, avoid relying on signature-based detection and instead rely on methods that are effective with previously unknown file hashes like static analysis, sandboxing, dynamic monitoring, file entropy analysis, and behavioural analysis that uses machine learning and AI.

When targeted malware or maldocs are detected, it’s critical to gain as much information about the malicious sample as possible to understand the attack vector, identify the malware’s capabilities, and improve future detection and response. 

While it’s often not possible to share samples externally for analysis (e.g. sending samples to MISP or VirusTotal), private alternatives for automated analysis do exist, like Cosive’s MalwareZoo powered by Assemblyline 4, an open source project from Cyber Centre Canada. MalwareZoo lets you securely and hygienically store and analyse sensitive malware on a segregated, private network.

As mentioned, malware often contains anti-analysis capabilities including acting in benign ways when run in a sandbox environment. One strategy for countering this is running many different best-of-breed analysis tools and then providing an overall risk score, a strategy that Assemblyline 4 implements.

Conclusions

While there’s some evidence to suggest that targeted malware is becoming more common, behaviour-based detection techniques are advancing in lockstep. While many of these techniques rely on the use of public AV and malware analysis engines and repositories, private alternatives like MalwareZoo (hosted) and Assemblyline 4 (self-hosted) are becoming increasingly convenient and powerful for the private storage, analysis, risk scoring, and triage of suspicious files.

Our cybersecurity consultancy has frequently been called upon to confidentially assist organisations in defending against unique, targeted malware. Reach out to us if targeted malware is becoming a problem in your organisation: we’d be happy to discuss potential approaches to detection, response, and storage.