ATT&CK Series: Execution
May 07, 2019
Along with Initial Access, the Execution phase of an intrusion is crucial to an adversary’s ability to compromise a network. Well-designed execution policies that restrict an attacker’s options for executing their own code and gaining a foothold inside the organization can often stop an attack almost before it starts.enterprise environment.
In this blog, we will look at ATT&CK’s Execution Phase techniques and tactics from an adversarial perspective. We will cover a few of the most common techniques used in today’s intrusions of enterprise networks, but it is important to note that attackers have multiple methods of execution available that are not mentioned here, and staying current on all these methods is crucial.
Command-line interfaces are ubiquitous in computing; a carryover from the days before the graphical user interface that remains one of the most powerful tools in an administrator’s arsenal for effectively managing systems and users. Prominent in some form or another on all modern operating systems, the Command-Line Interface (CLI) has also often been the first stop for an adversary looking to establish a foothold in a corporate network environment.
The CLI most commonly used in Unix-based operating systems today is the Bash shell, an iteration of the original Bourne shell. Thus, it shares many similarities with Apple’s Unix-derived macOS counterpart, Terminal, and has even recently gained some support in Windows 10. Bash is particularly noteworthy as it often serves as an adversary’s primary workbench, allowing them to run a versatile range of commands and tools to begin achieving their goals even before reaching any corporate network. This same versatility, as well as familiarity with the CLI, can be leveraged in a compromised and unrestricted environment to perform tasks ranging from simple information gathering to establishing persistent access, escalation of privilege, or executing additional pieces of code or software.
However, the most widely available CLI in most enterprise environments is Windows’ own cmd.exe. The classic Windows CLI does not offer all the flexibility of its Unix-based alternatives, but it is native to every modern Windows operating system, and may still allow an intruder to perform many of the same information gathering and code execution tasks. Additionally, as Windows systems are more commonly domain-joined than those running Linux, Unix, or macOS, cmd.exe is frequently used as an interface to communicate with domain controllers on the network, which may provide an attacker with valuable information such as password policy and group memberships.
Access to a CLI on any operating system often provides intruders with ease of access to information which they may not otherwise be able to obtain via GUI-based tools. Access to the CLI is so valuable that various techniques have existed over the years to gain access to it in scenarios where it should be prevented, such as with locked-down kiosk machines.
Due to its pervasiveness, fully mitigating the risk associated with the CLI is difficult – but several steps can be taken to increase the difficulty an attacker may face when attempting to leverage the CLI. First and foremost, limiting user access to command-line utilities using tools such as AppLocker or software restriction policies will also limit an intruder’s ability to access the CLI. Appropriate delegation of user privileges, particularly in non-Windows environments, will restrict the types of commands that can be run should an attacker gain access to a command line. Finally, logging and auditing can aid in monitoring and tracking down abuses of the CLI on any operating system, and while this may not directly assist in preventing an attacker from leveraging the CLI in their attack chain, it will allow for a more effective response once the threat has been identified.
PowerShell is a command-line interface of its own, increasingly enjoying popularity and traction within the information community within the last several years. Devised by Microsoft as an answer to the Unix-based shells, it allows much more flexibility than the standard cmd.exe CLI, provides its own integrated scripting environment, and is designed to fully integrate into the Windows operating system and network environment. As with CLI interfaces in general, this flexibility and integration provide an opportunity for intruders, and PowerShell-based attacks, in particular, have been so common over the past few years that PowerShell deserves a section of its own.
As with regular CLIs, an attacker who has access to a system that has PowerShell can use it to gather information, manipulate files, and execute code. However, PowerShell is so flexible that it has been used to build several offensive testing tools and tool suites, such as Empire, PowerSploit, and PS>Attack. These tools allow a user to run simple cmdlets, or scripts, which may otherwise be too complex for cmd.exe. Because of these easily run cmdlets, less experienced individuals may also have increased success in attacking an organization that does not defend against malicious PowerShell use.
Perhaps most importantly, PowerShell provides options for remote management of, and code execution on, systems where it resides. Access to PowerShell and a compromised user account does not simply mean flexible access to one system, but every PowerShell-enabled system in the environment where that user has access. This can be used to great effect to quickly gather system information, check privileges, or access files on multiple systems.
Although advances in PowerShell security mean that attacks leveraging it are quickly falling out of favor, obfuscation techniques continue to make it difficult for security controls to identify these attacks, and lowering one’s guard against these attacks may result in a resurgence in their success.
Because of the combination of PowerShell’s versatility, availability, and the collections of well-developed tools, many individuals may have increased success in attacking an organization that does not defend against malicious PowerShell use. The ease with which even an inexperienced attacker can exploit and navigate a Windows environment using PowerShell only increases the risk associated with default implementations of this specific CLI.
PowerShell has built-in execution policy that may help to prevent the execution of unauthorized or unsigned scripts. While an attacker who succeeds in obtaining administrative privileges on a machine may change this execution policy to be able to run those scripts or tools, this change in itself can be monitored for as a method of detecting unauthorized use. Additionally, as of PowerShell 5.0, and retroactively to PowerShell 4.0, enhanced logging capabilities can be enabled to monitor the types of commands being run. Together with data analytics, an organization can gain a significant amount of insight into the typical use of PowerShell in an environment, and therefore what activity may stand out. Finally, PowerShell can be removed from systems where it is not needed, and the WinRM service can be disabled to prevent remote execution on systems where remote execution of PowerShell commands is not required.
A feature that often flies under the radar, Windows Management Instrumentation (WMI), allows both local and remote administrative control over Windows system components. Locally, this feature has its own running service; remotely, WMI relies on remote procedure calls (RPCs) via port 135 and Server Message Block (SMB) communication via port 445. Like PowerShell above, WMI’s power and remote availability make it not only a powerful administration tool, but also a powerful attack vector in the wrong hands.
Many identified threats have been known to use WMI queries to gather system information, execute commands, and even remotely spawn CLI processes such as cmd.exe for more interactive control over a compromised system. Most recently, attackers have leveraged WMI queries that obtain malicious Extensible Stylesheet Language (XSL) files from web servers and execute them in memory without that code ever reaching storage drives, increasing the difficulty involved in detecting associated activities.
WMI’s continued availability makes it a prime target on any network. Its local capabilities may allow an intruder to stealthily obtain a foothold within an environment, and when that intruder is ready to expand their access and begin moving laterally through the environment, WMI’s remote functions provide the opportunity to find and compromise their next target.
WMI is crucial enough to the continued stable operation of a Windows environment that disabling the service entirely is rarely an option. Instead, restricting WMI access only to accounts that need to interact with Windows in that way may prevent an attacker from being able to utilize the service. Monitoring for WMI connections and “wmic” commands may also alert an organization to the presence of malicious activity, allowing the appropriate actions to be taken.
The three techniques described above form a trifecta of most commonly seen methods of code execution, and any of the three can be leveraged in tandem with any of the others in most Windows environments to make an intrusion even more effective. Mitigation strategies vary slightly between all methods, but implementing controls against all of these may severely hamper an intruder’s efforts to obtain a foothold in the organization. However, as mentioned before, the techniques above do not comprise an exhaustive list, and it is important to remain familiar with all of an attacker’s options throughout the entire attack chain. To that end, this series will continue covering various modern ATT&CK techniques and tactics, providing insight, clarity, and recommended mitigation strategies.
In our previous posts in this series, we reviewed MITRE’s National Cybersecurity Federally Funded Research and Development Centers (FFRDC’s) Adversarial Tactic, Techniques, and Common Knowledge (ATT&CK) repository of collected cybersecurity data. ATT&CK bridges the gap between multiple offensive security data points, including tactics, techniques, tools, and identified malicious Advanced Persistent Threat (APT) actors. The creation of most of this framework comes from an interesting project executed by Blake Storm, of MITRE, called project FMX (Fort Meade eXperiment). In this project, a production network was attacked by Blake and other security professionals which impersonated adversarial groups' tactics and techniques. By leveraging data points collected on the network, Blake was able to construct a large part of the ATT&CK framework that could be leveraged by offensive as well as defensive security professionals, to map potential offensive tactics and techniques.
Here's a review of related posts on this critical topic: