ATT&CK Series: Command and Control
August 06, 2019
Regardless of motivation, industry affiliation, or target, attackers are often compelled to find methods by which they can leverage compromised hosts to accomplish their objectives. Compromised e-mail accounts and cloud-based resources can provide a wealth of information, however highly-secured environments often require internal network access and host interaction to compromise sensitive data (such as PCI-DSS cardholder data environments).
Although attackers can identify and exfiltrate data through a myriad of compromise methods, one of the most commonly-used methods is the establishment of remote command and control (C2) sessions. Remote C2 enables attackers to accomplish tasks as if they were sitting in front of a compromised computer and typing on the keyboard. In some cases, remote C2 can also allow for interactions that would not usually be possible in a local context (e.g., multiple simultaneous interactive logons, BIOS interaction through out-of-band-management functionality, etc.).
Remote C2 can manifest in many forms including bespoke malicious software designed to evade detection, off-the-shelf attack simulation software, enterprise system administration software or use of built-in remote administration tools.
In this post, we will review ATT&CK’s C2 techniques from an attacker’s point of view. The techniques covered here are not inclusive of every possible method for establishing C2 on a compromised system but are a reflective sample of commonly-observed contemporary methods used by attackers.
The ever-present fight between attackers and defenders has rendered surreptitious establishment of C2 an increasingly difficult proposition. To avoid detection, attackers are leveraging methods of C2 that are indistinguishable from normal user traffic, such as the use of legitimate remote desktop support software to interact with compromised machines. Software solutions like these are commonly used within corporate network environments for legitimate purposes, which can make malicious activity hard to detect.
Using third-party desktop support software could allow an attacker to establish an initial remote C2 session in a corporate network with social engineering techniques such as sending malicious spear-phishing emails with the desktop support software attached, or by enticing users to install the software over the phone with phishing phone calls.
Several mitigation techniques exist for preventing unauthorized use of desktop support software. The first and easiest step to implement should be to configure firewalls to limit traffic to sites and services used by remote desktop software tools. Additionally, the use of application whitelisting to restrict code execution to a list of pre-approved software is an excellent step in securing any machine connected to your network but is not without its drawbacks. If your environment relies on the use of remote desktop support software; that software will need to be whitelisted negating the very benefits of whitelisting. Finally, endpoint protection products can also flag remote desktop support software as malicious to prevent it from executing if a user is tricked into downloading the software.
In an effort to blend in with normal user traffic, attackers may communicate over commonly used ports to bypass firewall restrictions. Some of these include ports used to mimic web browsers, email servers, and DNS requests to prevent discovery of C2 traffic going out to the public internet. For internal networks, attackers may leverage ports and protocols used by remote administration tools such as Secure Shell (SSH), Remote Desktop Protocol (RDP), or Server Message Blog (SMB). This traffic blends in with internal network traffic by mimicking legitimate traffic that would typically be seen between machines on a corporate network.
Being able to detect command and control network traffic using commonly used ports and protocols is necessary in detecting network attacks as an attack can go unnoticed indefinitely if proper security controls are not in place.
The appearance of C2 traffic evolves as attackers change their tradecraft. However, there remain some basic characteristics that a defender can use to identify malicious traffic. Network-based characteristics such as time of established connection, frequency of those connections, and does the connection make sense. For example, is a machine in accounting initiating a remote desktop connection into a Domain Controller, and if so, why? Other characteristics such as the geolocation data of the destination IP address on egress traffic can be checked and determined if there is a legitimate business case for that traffic.
Domain fronting is a technique in which an attacker hides their C2 traffic by masquerading as traffic to trusted servers hosted behind Content Delivery Networks (CDN). Put simply, an attacker can send traffic to a CDN end-point and the CDN will route the traffic to the attackers-controlled domain, making it difficult for defenders to differentiate malicious traffic from the normal traffic.
Detecting malicious C2 traffic is paramount in finding and stopping attackers from compromising additional assets. The longer an attacker goes unnoticed in an environment, the harder it is to find and stop them.
Detecting and mitigating domain fronting can be difficult as it relies on sending traffic to ‘trusted’ sources to be routed to an attacker-controlled domain. To accomplish this, the HOST field of the HTTP header is set to tell the CDN where to send the traffic. Defenders can inspect the HTTP header for indicators such as trusted traffic appearing to go to un-trusted domains (for example., Microsoft Updates going to non-Microsoft domains). In addition to inspecting the HTTP header, defenders can implement intrusion detection or prevention systems (IDS/IPS). Most IDS/IPS implementations deploy anomaly-based detection to identify deviations from baseline normal traffic. This can assist the defender in locating a possibly compromised machine. In addition, an IDS/IPS can often employ a whitelist or blacklist for domains specified by the organization and take appropriate action on traffic destined towards those domains, such as dropping the traffic entirely. However, taking a whitelist/blacklist approach for domain fronting can be difficult as most normal traffic relies on the use of a CDN endpoint.
While we have covered three common C2 techniques here, it is important to note that there are many other techniques that may be employed by an adversary to maintain command and control on the network. Although many of these techniques can be detected or mitigated with the previously mentioned utilities, it may be necessary to engage with an Incident Response (IR) team before making any system changes if you suspect a breach has occurred as these tactics may contain important evidence for your case.
Read more in Optiv’s ATT&CK series. Here's a review of related posts on this critical topic:
- ATT&CK Intro - September 2018
- ATT&CK Initial Access - October 2018
- ATT&CK Privilege Escalation - November 2018
- ATT&CK Discovery - March 2019
- ATT&CK Persistence - April 2019
- ATT&CK Credential Access - April 2019
- ATT&CK Execution - May 2019
- ATT&CK Defense Evasion - May 2019
- ATT&CK Lateral Movement Techniques - June 2019
- ATT&CK Exfiltration - July 2019
- ATT&CK Series: Command and Control - August, 2019
- ATT&CK Series: Collection Tactics – September, 2019
- ATT&CK Series: Collection Tactics Part Two – April, 2020
- ATT&CK Series: Impact – September, 2019