Understanding malware beacons and knowing how to block them can help keep your organization safer. A beacon, also known as a payload, is an executable or program that communicates back to a cyberattacker via some communication channel. From the threat actor’s point of view, beacon management is the foundation for their malicious campaign. Depending on the type and capability of a beacon, it’s the means by which a threat actor can gain a direct line into your network, maintain that line of communications, and carry out their illegal aims and objectives.
For example, the SolarWinds supply chain attack involved an elusive threat actor using beacon or payload staging. As several post-incident analysis reports showed, this was a sophisticated, multistage attack in which the Sunspot malware was initially used to compromise the supplier. Next came the Sunburst backdoor on the supplier’s customers. After this was successfully executed, it was used to deliver the memory-only dropper Teardrop, followed by the Raindrop loader and Cobalt Strike beacon. Each payload had a unique purpose and set of capabilities.
Common steps in a malware attack sequence
In instances of malicious activity where some vulnerability is involved, whether end-user or system, the attack sequence typically takes the following path:
It’s useful to understand these phases from the threat actor’s perspective. By learning how attackers get their malicious communications for command and control, we can also build a defense against them. Let’s take each step separately.
On the attacker’s side, there will be a command-and-control listener to receive and process communications from all victim machines compromised by the corresponding payload. The listener will be supported by web servers, mail systems, DNS, alerting systems and attack servers, which host the tools used in the threat campaign.
The attacker’s own communications out of their infrastructure will likely be anonymized — that is, bounced through a series of proxy servers to hide their true identity. Here’s an example:
For more sophisticated attacks, threat actors may also deploy distributed infrastructures dedicated to their specific campaigns. This lets them quickly bring up or tear down infrastructure across multiple geographic locations as required. One important part of this infrastructure is the Domain Name System (DNS). An attacker can leverage DNS to deliver malicious communications to their infrastructure, and they can also use DNS to exfiltrate (that is, steal) data.
Alongside the infrastructure setup will likely be the human resources responsible for planning, deploying and managing the malicious campaign. Most threat campaigns have a whole team of people and infrastructure behind them; they’re unlikely to be a one-person show.
The following breakdown shows an example of an attack campaign team. Note how similar it is to the team of a typical IT services company.
For threat actors, the process of securing their own infrastructure while also evading detection in the victim network is referred to as operational security. Sophisticated threat actors tend to favour high operational security. And to achieve it, they’ll use an array of techniques for evasion and obfuscation.
A vulnerability is simply any inherent weakness in a computer system or related technologies that a threat actor seeks to exploit. This vulnerability could stem from either the source (the equipment vendor) or the destination (typically an end user). For example, in 2017, Microsoft’s SMBv1 vulnerability was successfully exploited by ransomware attackers on a global scale. Here’s a look at that vulnerability’s detail report:
Once a system or program vulnerability is discovered, it may be made public; in this case, the vulnerability is issued a standard CVE (common vulnerabilities and exposures) number. Or it may be known only to a private few, and without any fixes available (aka a "zero-day"). The vulnerability phase may also refer to more common end-user vulnerabilities, typically leveraged with social engineering, such as phishing and malvertising. At this stage, the threat actor’s overall aim is to exploit the vulnerability and turn it into an opportunity for a successful attack.
Attack or exploit
The next significant phase in an attack occurs when the threat actor gains access to some piece of code they can use to leverage a vulnerability while bypassing security controls. For example, by using the Metasploit Framework as an attacker server, a threat actor found three exploits available for the Windows SMBv1 vulnerability, as shown here:
These vulnerabilities are of the type leveraged by the infamous WannaCry and NotPetya ransomware campaigns. Exploits like these often contain both the exploit code for the vulnerability and a small payload code for malicious communications.
An exploit is often separate from the beacon or payload. However, the two are commonly put together as shellcode. Once the exploit gains access to the target system, it will load a small beacon or payload that can call back to the attacker to complete the attack, a process known as payload staging.
Beacon or payload
As mentioned above, a beacon or payload is an executable or program that communicates back to the attacker via some communication channel. This may be secured over HTTPS or use a plain-text protocol such as DNS. The attacker, using what’s known as a beacon or payload callback, can then transfer further payloads, often with additional capabilities to achieve the intended objectives.
In the example below, you can see a Meterpreter payload as a Windows EXE using the Metasploit Framework’s msfvenom:
Once such a payload is delivered and executed on a victim system, it will silently create a reverse TCP connection. The payload uses default port 4444 from inside the victim network back to the attacker’s IP address. Note that the payload example above would have a high chance of being detected in the real world, as it was generated with default values and no encoding. It’s really just an academic example.
Once an attacker executes the beacon or payload, they can carry out their threat campaign. This may involve stealing data, installing ransomware, or causing some other type of disruption.
Before moving ahead, here’s a summary of the steps an attacker will take to achieve their objective:
Step 1: Plan the campaign and design corresponding infrastructure, including web servers, email servers, DNS infrastructure and attack servers.
Step 2: Conduct reconnaissance on the selected targets and systems.
Step 3: Select the most effective attack or vulnerability to exploit, using a combination of humans and systems.
Step 4: Develop or acquire the corresponding exploit tools, including the delivery mechanisms.
Step 5: Set up the attack infrastructure, including the command-and-control infrastructure (aka a "listener"), to receive reverse beacon communications.
Step 6: Run the malicious campaign.
Step 7: Manage the beacon and payloads to avoid detection and carry out the campaign’s objectives.
Once a threat actor has designed and implemented the infrastructure and related setup, their malicious campaign is ready to begin. To do this, the threat actor will need their beacons or payloads to execute inside the victim network. Then they can gain access, maintain a foothold and carry out their objectives.
Let’s walk through some of the important steps from an attacker’s point of view.
To start, here’s a look at generating the desired payload:
In this case, the payload is generated to communicate using a domain (app12.webcoms-meetings.com, shown as LHOST in the first full line of green) that mimics some remote meeting and collaboration software for the Windows operating system. A check shows that the domain resolves to the attacker’s controlled IP address.
From here, the attacker chooses a delivery mechanism for their initial entry into the target. In this example, they’ve chosen to use spear phishing, a kind of social-engineering attack that gets an unsuspecting user to download what they think is an update to their software for remote meetings. The attacker has set up a corresponding domain (email and web) and website infrastructure to support this social-engineering delivery method, as shown below:
The attacker hopes the unsuspecting user will download and run the payload. Or, if the user visits the phishing site, the payload can be run automatically via a drive-by-download. Either way, the disguised payload is now on the user’s computer and ready to be executed, as shown here:
Once the payload is running, it silently calls back to the attacker’s command and control. A listener will already be up and running on the attacker’s side to receive the callback communications. In the example below, a payload handler or listener, exploit/multi/handler, has been set up on the attacker’s side to receive communications from the reverse_tcp payload running on the victim machine via the malicious domain app12.webcoms-meetings.com.
Once the beacon reaches the attacker infrastructure, the relevant listener or handler receives the connection, and the initial payload can download a much larger main payload, known as the Stage. This can be seen below with the message “sending stage (175174) to 203.0.113.1.” The victim machine is behind a NAT Firewall with the external IP of 203.0.113.1. The attacker payload in this example is the versatile Metasploit Meterpreter.
Once the initial beacon downloads the main payload, it’s ready to continue the rest of the attack. Upon successfully executing, program control is then passed to this main payload (Stage) to deliver a shell for the attacker. All this happens in memory and involves code-injection techniques. The next screenshot shows the attacker with hands-on keyboard access to the victim machine. The attacker can run the “dir” command and see all files in the user’s downloads folder.
From here, the attacker does some internal reconnaissance (aka "discovery") on the victim machine. The attacker can now obtain the victim’s account and directory information. For example, the logged username for the compromised machine is “ama”. They can even capture a screenshot of the target system’s Windows Desktop, as shown here:
At this point, the attacker can also scan the internal network to discover other systems. The next screenshot shows an Address Resolution Protocol (ARP) scan of the internal network. This will be useful for lateral movement, described later.
The attacker can also perform more malicious actions such as exfiltrating (stealing) a Project_Progress.pdf file from the victim machine. As shown below, they can also upload Mimikatz, a malicious tool for stealing user credentials. Attackers need credentials with elevated privileges to perform system-level actions and lateral movement inside a network.
The example below shows how the attacker can run the uploaded Mimikatz credential dumping tool to view password hashes on the compromised Windows machine.
Another critical step for the attacker is creating a route back to the victim machine, even after it has been rebooted by the user. This is where the technique of persistence comes into play. Attackers have several ways to achieve this, including autorun reverse payloads and persistent backdoors.
As shown below, the attacker chooses to run a post-exploit persistence module, which involves a Visual Basic Script (VBScript) placed in the Windows Temp folder of the logged-on user, UoPfNwo.vbs. The attacker then installs a Windows registry entry to enable the script to autorun after the machine boots up.
Now the attacker has ensured that their payload script can connect back to their listener, even if the machine is rebooted. However, files on the disk can now also be detected by a file system antivirus (AV) scan.
Finally, the attacker will want to clean up all potential evidence. To do this, they may remove original malicious files and entries, and encrypt or even mix malicious files among legitimate system files. To further cover their tracks, they can also delete both shadow copies and system logs.
Analysis and forensics of the attack
I’ll now walk through some initial incident responses (IR) and the basic analysis of specific components of the attack. This will give you a better understanding of certain malicious actions.
Network and DNS analysis
Starting with network communication analysis from the victim machine, the internal IP (10.1.1.81) is observed to have established a TCP connection on remote port 443 to the outside attacker DNS name. This is a command-and-control communication.
Next, by analyzing the typical components involved in a regular DNS resolution hierarchy, we can break down the attacker’s process:
First, the threat actor registered a domain: webcoms-meetings.com
The domain points to the outside IP 203.0.113.123.
The attacker uses sub-domain name app12.webcoms-meetings.com to direct traffic from the payloads on compromised machines to their command and control.
Threat actors may also attempt to exfiltrate data using DNS. For example, they might use DNS TXT records or even encoded unique information about their victims as part of a supposed outbound DNS query. These queries will be received by the authoritative DNS server under the attacker’s control. An authoritative DNS server receives and answers DNS queries for a specific domain.
Threat actors can also use Domain Generation Algorithms (DGAs) to automatically generate thousands of domains each day. With this technique, an infected machine will have built-in code (that is, an algorithm) to generate and then attempt to connect to a number of these generated domains over a specified period. For example, it might try to connect to 1,000 generated domains every 24 hours until one succeeds. The attacker will then register a few of these domains each day and keep them up for short periods of time.
These domains will likely receive malicious communications every so often. This technique, popularized by the Conficker family of malware, makes it difficult to create a deny list as a kill switch. To further evade detection and maintain resilience, more sophisticated threat actors also use a distributed infrastructure that combines proxies, redirectors and load balancers.
Most of the typical payload or beacon post-exploitation operations involve manipulation of Windows processes, which occur entirely in memory. An attacker with a process-manipulation capability can start new processes on the victim machine. This can be a native interactive shell (Windows cmd.exe) that lets the attacker use native Windows commands. The attacker can also start processes non-interactively, as shown here:
On the victim machine, a process dump (shown below) displays the newly created processes with their respective process IDs, 2624 and 1972, both running.
The ability to start new processes is very useful. The attacker can start a new unsuspecting process like notepad.exe and then migrate their original malicious payload process to it using code / DLL injection. It’s a technique that makes a malicious process on the system appear to be legitimate; I’ll discuss it in more detail in part two of this series.
The attacker, as part of their post-exploitation evasion, migrates the original malicious process, web1_meeting_update.exe (2472), to a new notepad.exe process (1768), as shown here.
On the victim machine, the original malicious process, PID 2472, has been migrated and is now running as notepad.exe with process ID 1768. As shown below, only the new process is now running.
From the earlier persistence technique, the Windows Temp folder (see below) shows both the VBScript used and the corresponding autorun keys that were created in the registry for the malicious script.
An initial static analysis of the original malicious executable payload file shows that it has several associated risk factors. For instance, it loads some interesting Windows libraries (DLLs), especially those used for network communications. A corresponding memory and dynamic analysis will display the suspicious behavior of a notepad.exe process making network connections.
In this article I have discussed some of the typical considerations and actions involved in a threat campaign and its associated malicious communications. I hope this gives you some insight into how and why a threat actor uses certain techniques.
We can summarize the attack cycle that leads to malicious communication into three phases:
A good way to approach mitigation strategies is to apply the assume breach philosophy. That is, assume that the attacker is already in, and that therefore, your key security objectives should be detection and containment. Also, your security outcomes must include at least automated visibility, alerting and containment (Zero Trust segmentation). I’ll discuss mitigation techniques in more detail the third and final part of this blog series.
In the next article, part two of this series, I’ll take a deeper look at beacons and payloads and explain why a threat actor might choose one type over another. I’ll also delve into some of the advanced techniques attackers use for evasion and obfuscation.