Chapter 10: Malicious Functionality: Mapping Your Sample to MITRE ATT&CK

In previous chapters, we've discussed monitoring for behaviors, statically reviewing file information, and de-obfuscating code in order to ascertain what behaviors a piece of adversarial software may undertake in its journey to take action on objectives on our networks.

In this chapter, we'll discuss how to utilize MITRE's famous ATT&CK framework in order to both better understand what each step the malicious code takes is attempting to achieve and to allow us to better categorize, classify, and report on the various samples of malware we may uncover during the course of our career as malware analysts.

Once we've covered each of these points, you'll also have a chance to test your understanding of the topics we've covered by utilizing a real-world piece of malware and attempting to map its behaviors against the MITRE ATT&CK framework.

To this end, we'll cover the following points:

  • Understanding MITRE's ATT&CK framework
  • Case study: Andromeda
  • Utilizing ATT&CK for C-level reporting

Technical requirements

The following is the only technical requirement for this chapter:

  • An internet connection

Understanding MITRE's ATT&CK framework

The ATT&CK framework built by MITRE attempts to achieve a consistent way to describe adversarial behaviors on a network or system by breaking down and naming each stage of an attack by the goal that the attacker is trying to achieve – these are called tactics. In a moment, we'll define each of these.

Additionally, within each ATT&CK tactic, there are techniques that can be utilized to achieve this end. For instance, tactic execution – or executing a piece of malicious code – may be achieved using Windows Management Instrumentation. This would be the technique for the tactic. In this example, the full MITRE description would be Execution via Windows Management Instrumentation.

Tactics – building a kill chain

As previously described, within the ATT&CK framework, there are 10 tactics – or stages – to an attack. We'll utilize the next space to go through each of these to ensure an understanding of each stage of an attack, and what an adversary or piece of malware may hope to achieve from each stage.

Analysis tip

Just because there are 10 tactics in MITRE's framework does not mean that each piece of malware will utilize each tactic. For instance, some malware may have no interest in moving laterally within a network. While it's common for malware or adversaries to use many of these tactics, it's not strictly necessary.


In this stage, an attacker will attempt to gain information about the target network, user, or system. This is done particularly in targeted attacks or penetration tests in order to gain more information before proceeding to further stages. The more an adversary knows about an enemy, the easier it is to attack.

Resource development

A not-often discussed tactic is resource development. In this tactic, the adversary purchases, steals, builds, and otherwise manages the tooling and infrastructure necessary to facilitate their malicious operations. This is the stuff often focused on by malware researchers and intelligence departments.

Initial access

This tactic covers how the adversary or piece of malicious code gains an initial foothold in the system or network that is being attacked. Common examples are as follows:

  • Phishing
  • Exploit public-facing application
  • Supply chain compromise
  • Replication through removable media


This broad tactic endeavors to explain how the malicious code was executed on the target system. Within Windows (and other operating systems), there are many ways to achieve the end goal of executing malicious code. Common examples of techniques within this tactic are as follows:

  • Command and scripting interpreter (Command Prompt, PowerShell, Python, and so on)
  • User execution
  • Windows Management Instrumentation
  • Scheduled task/job


Here, we cover how the attacker will maintain their presence on the target system. Often, it isn't enough for an attacker to have a one-and-done level of access to a target system. Even ransomware operators are known to maintain a persistent foothold within networks in order to re-compromise after backups are restored, or exfiltrate more data as leverage against the victim. Common examples of techniques here are as follows:

  • External remote services (TeamViewer, AnyDesk, RDP, and so on)
  • BITS jobs
  • Account creation
  • Valid account usage
  • Scheduled tasks/jobs

Privilege escalation

In this tactic, it's explained how the adversary may move from a low-privileged user to an administrative, or higher-privileged user utilizing exploitation or credential harvesting. While not always necessary in order to achieve the goals the operator has, it's a frequently utilized tactic. Here are some common examples:

  • Exploitation via vulnerability
  • Access token manipulation
  • Valid account usage
  • Abuse elevation control mechanism

Defense evasion

Perhaps the broadest of all of the ATT&CK tactics, this tactic is nearly always used in some form or fashion by both actively interactive adversaries and malware alike. This tactic has to do with an attempt to either evade analysis – as in anti-sandboxing tricks – or evade Endpoint Detection and Response (EDR) with any number of techniques. Some common ones are as follows:

  • BITS jobs
  • File and directory permissions modification
  • Indirect command execution
  • Modifying the registry
  • Signed binary proxy execution

Discovery and lateral movement

These two closely linked tactics have to do with the adversary discovering additional systems on the network and attempting to additionally infect or compromise systems that are lateral to the initially exploited system in order to further reach and compromise. Some common tactics that fall under this umbrella are as follows:

  • Network share discovery
  • Network service scanning
  • Remote system discovery
  • Taint shared content
  • Remote services
  • Internal spearphishing
  • The exploitation of remote services

Collection and exfiltration

Another two closely linked tactics are collection and exfiltration. These tactics deal with the adversary's collection and remote downloading of sensitive data from the exploited target system after the compromise has already taken place. These tactics are often used by ransomware operators to both prove they have access and to gain leverage against the victim. Common ways these are implemented include the following:

  • The collection of clipboard data
  • Archiving collected data from network shares, removable media, and the local system
  • Screen captures
  • Video captures
  • Email collection
  • Exfiltration over a physical medium
  • Exfiltration via a network medium
  • Transferring data to a cloud account


Finally, we arrive at the most dreaded tactic in the MITRE framework, impact. In this tactic, either the availability of systems or the integrity of data is tampered with. Ransomware operators are certainly the most famous implementors of this tactic with data encrypted for impact, but certainly others have been known to do the same. Here are some common examples:

  • Data encrypted for impact
  • Defacement
  • Account access removal
  • Data destruction
  • Data manipulation

Now that we have a good handle on each of the tactics and some of the example techniques that may be utilized by adversaries in order to achieve their ends, let's take a look at an example piece of malware, describe what happens, and see how that may map to the MITRE ATT&CK framework.

Case study: Andromeda

Andromeda is a now (mostly) dead worm that was first spotted in 2011. Andromeda used a number of techniques to infect hosts, but commonly was spotted on USB media when the following command was detected upon plugging in the drive:

C:windowssystem32cmd.exe'' /c start rundll32 ececacacaeaeaecececacacaeaeaecececacacaeaeaececca.ececacacaeaeaecececacacaeaeaecececacacaeaeaececca,CaWSOKGsokgcOKaY

Upon executing via runDLL32, the malware would first check to see if the machine was a VM or debugging workstation by utilizing a list of blacklisted processes in memory and comparing it to a list of running processes utilizing the CreateToolhelp32Snapshot API and then cycling through the processes.

If all checks were passed, the malware would then copy itself to %ALLUSERSPROFILE% and rename the binary randomly prepended with MS.

Finally, to achieve persistence, the Andromeda malware would create a value at registry key HKCUSoftwareMicrosoftWindowscurrentVersionPoliciesExplorerRun, and then change the security permissions so that no one may delete the registry key value. Then, with a fully infected host, any further USB drives plugged in would also be infected.

Upon subsequent runs, Andromeda has been observed utilizing code-injection techniques via the ResumeThread API to inject into MSIExec.exe.

C2 (Command and Control) traffic was observed to take place via JSON requests over HTTP, encrypted with RC4.

So, with all of this information in mind, starting with initial access, let's build a MITRE ATT&CK kill chain of tactics and techniques utilized by the Andromeda malware.

Initial access

Andromeda's technique for gaining a foothold on the system is fairly obvious. The malware primarily makes use of MITRE's T1091 technique – replication via removable media. Because the malware installs itself on any USB drive plugged into the infected machine, the malware will continue to spread via this vector.


This one is a bit trickier – but also easy to ascertain. The malware utilizes a trusted Windows utility, RunDLL32.exe, to execute its payload. The parent technique here is T1218 – Signed Binary Proxy Execution. This technique is so named because the malware utilizes a trusted binary, in this case RunDLL32.exe, to attempt to hide the execution of a malicious payload. The specific sub-technique is T1128.011 in this instance and specifically relates to RunDLL32.


The primary technique for Andromeda's persistence within the environment maps directly to T1547 – Boot or Logon Autostart Execution, because the registry key it creates ensures that it runs each time the environment starts. More specifically, the sub-technique is T1547.001, which specifically deals with all automatically running registry keys in Windows.

Defense evasion

Andromeda makes use of several evasion techniques in order to ensure it is not analyzed or detected. First, its execution via RunDLL32 in signed binary proxy execution is defense evasion – it attempts to hide the fact that malware is executing by hiding behind a trusted, signed binary. This maps to T1218.011.

Additionally, it checks for running processes in order to evade sandboxing or analysis tools in a VM. This broadly maps to T1497, though it also maps to process discovery in the discovery phase of the matrix.

Finally, with observed process injection via ResumeThread, in order to hijack a legitimate process, the sample can also be said to have attempted to evade detection via tactic T1055.003 – Process Injection via Thread Execution Hijacking.

Command and Control

Andromeda has several techniques utilized in Command and Control. First, it utilizes T1071.001 – web protocols – because we know that it utilizes HTTP in order to send and receive command and control information. We also know that it utilizes RC4 based encryption in order to hide the contents of the command and control, mapping to tactic T1573. Because we know that RC4 is a symmetric algorithm, we can further say that it maps to T1573.001 – Command and Control via Web Protocol with Encrypted Channel via Symmetric Encryption.

As you can see, MITRE ATT&CK allows us to be both very broad and very specific in regard to how the malware got into the environment, how it attempted to persist, what actions it took on the system, as well as how it was controlled by the adversary.

Now that we have an idea of how building a kill chain works, let's examine how this may be useful to us!

Utilizing MITRE ATT&CK for C-level reporting

As we've just covered, ATT&CK is a wonderful framework for allowing breadth and depth of technical coverage as well as simply painting the broad strokes.

Often, when reporting to director-level (with a few exceptions), the few questions that will be asked are things like ''How did this happen?'', ''What was the impact?'', ''How did the attacker interact with our systems?'', and ''How can we prevent this?'' or ''How can we remediate this?''.

The MITRE technique framework allows us as analysts a pre-written guide on the techniques observed by the malicious sample we are currently studying.

For instance, the page on Signed Binary Proxy Execution via RunDLL32 offers a great snippet that explains how and why adversaries may utilize this technique, as well as mitigations that can be put in place to avoid being victimized by this technique:

Not only is this information excellent for giving C-suite and non-technical reviewers of incidents a good overview of what and how something happened, but it also contains excellent technical information for those who may be incident responders or responsible for implementing changes after the incident as a result of our findings – for which your systems administration comrades will be thankful.

Reporting considerations

Report writing is one of the fundamental skills that sets excellent malware analysts above the merely good. While a solid technical understanding and foundation is required in order to grasp what actions an adversary is taking within an environment, equally important is the ability to pass along the findings to the requisite teams in an easily digestible format so the proper actions may be taken.

To this end, it's valuable to understand what particular audiences may be looking for as far as actionable information purpose-tailored to their role within the organization. As an analyst, if you can deliver tailored intelligence on the basis of your findings, you will quickly become a greatly appreciated asset by your superiors and your colleagues alike.

Writing for the C-suite

Generally speaking, when writing for those in executive positions, or those in positions that do not perform technical duties and instead are decision-makers, the Executive Summary section of the report is of the greatest importance.

In an executive summary, there are a few general rules that are best to follow.

The length of the executive summary is greatly dependent on the length of the document as a whole – not necessarily the technical complexity of the subject at hand. Generally, for a report that's 10-12 pages, the executive summary should not be more than a page in length.

Secondly, within the executive summary, it's important to present the conclusions of your investigation prior to any underpinnings or technical details that led you to this conclusion. Those of a non-technical leaning will generally not be interested in what small breadcrumbs led to the incident you are investigating – just what the logical outcome is. (Were we breached? What was lost? What were the attackers attempting to do? Were we targeted specifically?)

If it's necessary to point to more technical details, that can be done in citation style with [brackets] pointing to appendices that exist deeper within the report, so more detail may be gleaned from your technical analysis if so desired.

Finally, it's important here to use plain English and not slip into jargon or technical nomenclature that the audience of the summary or abstract may not be familiar with. We can utilize metaphor if necessary, but it's important to do so without being condescending in tone. The point of the summary is to have an abstract that self-describes our work without us as analysts having to answer clarifying questions surrounding the summary itself.

Writing for a technical audience

For a more technical audience, the rules are not quite as strict as they are for the technical summary.

Within the technical subsection of the report, we can utilize what we've already written in the summary to guide our work. Here, we should be able to look at the abstract and write out the technical analyses that we have utilized as rationales for the main points we have made within the summary already.

Here, the guidance is going to be to attempt to answer the following points in as much technical depth as possible:

  • How did the initial compromise take place?

    What logs, analysis, and so on led to this conclusion?

  • What further compromise attempts (lateral movement), if any, took place?

    What tools were utilized to facilitate this?

    What MITRE techniques were utilized for this?

  • What persistence mechanisms or malware was utilized within the compromise?

    What are the characteristics of this malware?

    What IOCs can we utilize to detect further instances of this malware?

  • What MITRE techniques does this malware utilize?
  • What further action on an objective was taken by the adversary, if any, prior to the response?

    What logs do we have to support this?

  • Can we prove a negative (that is, that no exfiltration took place)?
  • Most importantly, how can we prevent this from recurring?

For each of the preceding points, we'll need to provide supporting technical details. Unlike the executive summary, we can go into great technical depth, and utilize technical language here, as the intended audience is expected to be able to understand what we are writing.

However, even when going into such detail, it is also important to be succinct and draw conclusions at the end of each section that gracefully wrap up the analysis you have performed as an analyst for those skimming these reports for action items that they as stakeholders may have to implement.

It's important to keep in mind that every conclusion that you draw during the technical report should be consistent with those in the executive summary, and they should never diametrically oppose the audience.

The conclusions you present to decision-makers should be in line with the controls or remediations you recommend to technical stakeholders to avoid any internal confusion during the response to the incident as a result of your reporting.


For our challenge for this chapter, utilize this analysis (and your own research) of the Dridex threat from Count Upon Security:

  1. What techniques are described in the article?
  2. What technique is generally utilized for initial access by Dridex?
  3. What impact techniques, if any, are the threat actors behind Dridex known to use?


In this chapter, we've discussed what MITRE's ATT&CK framework is all about, and how it can help us describe the behaviors of both adversaries and malware, and how to do so.

Not only does the framework allow us the ability to describe things very succinctly, but it also enables us to further describe the behaviors we are seeing in consistent language with sufficient technical depth for those who may hold an interest in such technical knowledge.

We've also learned how it may enable us to write better reports, and have enough information for everyone involved, from those who may be less technical than us as analysts, to those who will be taking action during or after a security incident caused by a piece of malware we are studying.

The next section focuses on practical, example driven application of the findings from previous parts where we will be looking at the solutions to the previously posted challenges.

Further reading

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.