It is time for another blog post, this time looking at the recent update to the Mitre ATT&CK framework. 

The Mitre ATT&CK framework version 9 was released on 29th April, which contained many additional techniques and sub-techniques. As Elemendar’s READ product uses Mitre ATT&CK to extract attack patterns from CTI reports, we are always interested in any updates or additions to the framework. 

The following additions of new techniques and sub-techniques refer to attack techniques that primarily affect Windows, Linux, and MacOS operating systems. There’s also a whole new matrix added to the framework covering Containers.

Boot or Logon Autostart Execution

Two sub-techniques have been added to the ‘T1547:Boot or Logon Autostart Execution’ technique.

First is ‘T1547.014:Active Setup’ which allows adversaries to gain persistence on a Windows machine by adding a Registry key to Active Setup on the local machine. 

Active Setup is a mechanism in Windows to allow the execution of programs when a user logs in. Any programs executed in this way will be executed under the context of the logged in user and will have the associated account’s permission levels. 

A registry key can be added to “HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\” within the registry and a malicious value for “StubPath” added. This value points to a malicious executable, allowing persistence.

The second is ‘T1547.013:XDG Autostart Entries’ which allows adversaries to gain persistence on Linux systems by modifying XDG autostart entries to allow malicious executables to be run during system boot. By default, XDG autostart entries are stored at “/etc/xdg/autostart” or “~/.config/autostart”. Any XDG autostart entries will run on user login under the context of the logged in user and will have the associated account’s permission levels.

Credentials from Password Stores

Two more sub-techniques have been added to the ‘T1555:Credentials from Password Stores’ technique.

The first being ‘T1555.004:Windows Credential Manager’ in which credentials can be acquired by adversaries directly from the Windows Credential Manager. This credential manager stores credentials for websites, applications, and devices that request authorisation through NTLM or Kerberos in Credential Lockers. 

These Credential Lockers store credentials in encrypted ‘.vcrd’ files at ‘%Systemdrive%\Users\[Username]\AppData\Local\Microsoft\Vault\Credentials\[UUID]\’ with the encryption key being held in the ‘Policy.vpol’ file within the same location. 

Adversaries can list credentials managed by the Windows Credential Manager using the native Windows executable ‘vaultcmd.exe’ that is used to enumerate credentials. Credentials can also be read by reading files located within the credential lockers or abusing Windows APIs such as ‘CredEnumerateA’.

Password recovery tools may also be used to view credentials in plain text.

The second subtechnique is ‘T1555.005:Password Managers’ in which adversaries can acquire credentials from third-party password managers. These credentials are usually stored in encrypted databases and require a master password to unlock. However, after the master password has been provided, an adversary can extract the plain text master password or plain text credentials directly from memory. Adversaries may also use brute force to obtain the master password of a password manager. 

Stage Capabilities 

A new technique that has been added in ATT&CK version 9 is ‘Stage Capabilities’. This technique includes adversarial behaviours that include uploading, installing, or setting up other capabilities that are then used during targeting. These capabilities that are either developed or obtained can be staged on adversary controlled infrastructure. This infrastructure could be owned or rented by the adversary, or simply previously compromised. 

There are 5 sub-techniques within Stage Capabilities. 

  • Upload Malware
  • Upload Tool
  • Install Digital Certificate
  • Drive-by Target
  • Link Target.

Subvert Trust Controls

Two subtechniques have been added to ‘T1608:Subvert Trust Controls’. ‘Mark-of-the-Web Bypass’ and ‘Code Signing Policy Modification’.

Within Windows operating systems, if a file is downloaded from the internet, it is tagged with the hidden NTFS Alternate Data Stream (ADS) ‘Zone.Identifier’ with a specific value known as MOTW (Mark-of-the-Web). 

Files marked with MOTW are protected and are restricted in the actions they can perform, such as MS office files being opened in Protected View. Any executable files tagged as MOTW will be processed by Windows Defender SmartScreen. 

With a ‘T1553.005:Mark-of-the-Web Bypass’ adversaries can abuse container files such as archive files or disk images to deliver malicious payloads. While the container file will be tagged as MOTW, any files within the container may not be tagged with MOTW after extraction or mounting and will be treated as local files on disk and run without protections.

Code signing provides authenticity for a program from the developer and guarantees that the program has not been tampered with. Security controls include enforcement mechanisms to ensure only programs and code with valid signatures are able to be run. 

Some of these controls are enabled by default, such as Driver Signature Enforcement (DSE) on Windows or System Integrity Protection (SIP) on macOS, while other controls can be enabled through application controls. 

By using ‘T1553.006:Code Signing Policy Modification’, adversaries may modify code signing policies through the use of command-line utilities, modifying the registry, booting the systems in debug or recovery modes, or by altering values within kernel memory. 

System Location Discovery

By using ‘T1614:System Location Discovery’, adversaries may gather system data in order to determine the geographic location of a victim. The location can be inferred by using system checks, such as time zone, keyboard layout, and language settings. Windows API functions such as GetLocaleInfoW can also be used to determine the locale of the host. In cloud environments, an instance’s availability zone may also be discovered by accessing the instance’s metadata service. Location can also be inferred from using IP addressing via geolocation IP-lookup services. 

System Network Configuration Discovery: Internet Connection Discovery

Using ‘T1016.001:Internet Connection Discovery’, adversaries may check for internet connectivity on compromised systems by using ping, tracert, and GET requests to legitimate web services. These results can be used by the adversary to determine whether the system is capable of communicating with their C2 servers before attempting to connect. These results may also be used to identify routes, redirects, and proxy servers.

 

ATT&CK for Containers

A major addition to the newest version of the Mitre ATT&CK framework is ATT&CK for Containers. This container specific matrix is a welcome addition to the framework and one that CTI professionals have been long awaiting. Below are the techniques and sub-techniques that have been specifically added for containers in version 9. 

Build Image on Host

Using ‘T1612:Build Image on Host’, adversaries may build a container image directly on a compromised host to bypass any security controls that monitor for malicious images by using a remote build request to the Docker API that includes a Dockerfile that pulls a vanilla image. A custom image is then built upon the vanilla image taking advantage of the build API to include malware downloaded from their C2 server. If the base image is pulled from a public repository, security controls are unlikely to detect the image as malicious. If the base image resides in a local registry, the pull may be considered less suspicious as the image is already within the environment. 

Container Administration Command

Using ‘T1609:Container Administration Command’, adversaries may use a container administration service such as the Docker daemon, the Kubernetes API server, or the kubelet to allow remote management of containers within an environment and allow commands to be executed within the container.

Container and Resource Discovery

Using ‘T1613:Container and Resource Discovery’, adversaries may attempt to discover containers and other resources such as images, deployments, pods, nodes, and other information such as the status of a cluster, from within a container’s environment. 

These resources can be viewed within the Kubernetes dashboard or queried via the Docker and Kubernetes APIs. Docker logs may leak environment information such as the environment configuration, services available, and cloud provider information. 

The discovery of this information may inform the adversary on how to perform lateral movement or which execution methods to follow.

Deploy Container

Using ‘T1610:Deploy Container’, adversaries may deploy a container onto a compromised system in order to evade defence controls. A new container can be used to execute or download malware, or be configured without network rules or user limitations to bypass defences on the host machine. 

Containers can be deployed using Docker’s create and start APIs  or via web applications such as Kubernetes dashboard or Kubeflow. 

Escape to Host

Using ‘T1611:Escape to Host’, adversaries may break out of a container to gain access to the host system. This can allow an adversary to gain access to host resources, as well as access to other containerised resources. 

There are multiple ways to escape a container to a host environment, including mounting the host’s filesystem using the bind parameter, allowing the adversary to drop payloads and execute control utilities such as cron on the host, and using an over privileged container to run commands directly on the host. 

Gaining access to the host may provide persistence, allow lateral movement, or allow setting up of command and control channels on the host. 

Scheduled Task/Job: Container Orchestration Job

‘T1053.007:Container Orchestration Job’ has been added to the ‘T1053:Scheduled Task/Job’ technique. This is used when adversaries abuse the task scheduling functionality provided by container orchestration tools such as Kubernetes to schedule deployment of containers configured to execute malicious code. Container orchestration jobs run at a specific date and time similar to cron jobs. 

Unsecured Credentials: Container API

‘T1552.007:Container API’ has been added to the ‘T1552:Unsecured Credentials’ technique. Adversaries may gather credentials via APIs within a container’s environment. APIs such as Docker API and Kubernetes API allow a user to remotely manage container resources and cluster components. 

An adversary may access the Docker API to collect logs that contain credentials to cloud, container, and other resources in the environment. With sufficient permissions an adversary may use the Kubernetes API to retrieve credentials from the Kubernetes API server, which may include Docker API authentication or Kubernetes cluster component secrets. 

User Execution: Malicious Image

‘T1204.003:Malicious Image’ has been added to the ‘T1204:User Execution’ technique. Adversaries may rely on user interaction to run a malicious image which then facilitates execution of malicious code. The following images can be backdoored: 

  • Amazon Web Services (AWS) 
  • Amazon Machine Images (AMIs) 
  • Google Cloud Platform (GCP) Images 
  • Azure Images 
  • Docker Containers

These backdoored images can be uploaded to public repositories causing users to download and deploy an instance or container without knowing it is malicious, allowing adversaries to bypass any techniques needed to gain initial access. This then leads to malicious code execution, such as cryptocurrency mining.

Final Thoughts

There are some great techniques added to the framework and ATT&CK for Containers is a very welcome addition. I’m sure i’m not the only one looking forward to using and implementing Mitre ATT&CK framework version 9.

The official update information can be found at https://attack.mitre.org/resources/updates/updates-april-2021/