Malware Payloads & Beacons: Techniques to Mitigate Impact

The first article in this series unpacked how malicious communications start, aided by the attacker’s infrastructure and associated beacons and payloads. In the second article, we investigated the categories and types of payloads together with the in-memory manipulation techniques. In the final part of this series, we will focus on some of the obfuscation techniques used to disguise payloads and examine mitigation techniques defenders can employ.

An important metric in cybersecurity is mean time to detect (MTTD) also known as “time to detect." This is the amount of time from an initial entry of an attacker to when the attack is detected by the target organization. A successful entry or exploit is usually only the beginning. Threat actors often employ different obfuscation techniques to stay undetected in compromised networks.

It is useful to consider the following broad mitigation approaches involving reactive and preventive techniques:

1. Reactive-first approach

• Detection only
• Detection and response

2. Preventive-first approach

• Preventive only
• Prevention and response

Under the reactive-first approach, detection only, is what technologies such as Intrusion Detection Systems (IDS) of old fall under. Such systems typically used a set of known signatures of malicious code or payloads to detect threats. These are easily bypassed by altering the hashes or signatures. Threat detection has evolved quite a bit since then. Modern detection techniques include behavior and heuristics, machine learning, self-learning, and artificial intelligence capabilities.

Building on the reactive-first approach, detection and response, includes the ability to stop a threat after it has been detected. This builds on the detection capability to block or allow.

Here, the confidence level of the detection engine should be extremely high to avoid false positives (blocking legitimate files mistaken for threats) or false negatives (allowing threats mistaken for legitimate files or code). With both reactive-first approaches, some action deemed suspicious must first happen before these systems trigger some reactive action.

On the other hand, the preventive-first approach, specifically preventive-only, does not rely on something happening first to act. It has a set of always-on rules in place for what must be allowed or blocked irrespective. It is also the approach employed by Zero Trust segmentation (also referred to as micro-segmentation).

This approach can also be adaptive, depending on the technology to respond in cases where a reactive-based response is required. We will examine both of these approaches in this article.

Let’s first look at some techniques that threat actors employ to obfuscate or hide their activities from detection. Then we’ll examine examples of both reactive-first ("detection" and "detection and response") and preventive-first ("preventive only" and "prevention and response") approaches to mitigate the impact of malware attacks.

Obfuscation techniques

Techniques such as custom code, code packing (e.g., using UPX packer), steganography, delayed execution, backdooring, encoding (Base64) and encryption may all be used by threat actors to attempt to hide or obfuscate malicious payloads.

Threat actors may also employ “living-off-the-land” techniques to utilize already trusted system files and binaries such as Powershell or WMI, or they may attempt to leverage already trusted third-party binaries and executables.

Executable backdoors

There are several techniques an attacker may use to make sure their payloads get executed.

One way is to hide their malicious code inside a legitimate executable file. Looking back at the compromised victim machine in the previous blog, we noticed a putty.exe executable in the user’s Downloads folder. Putty.exe is a widely used Telnet and SSH client.

Aiming to insert the malicious payload as a backdoor in putty, the attacker first downloads the user’s legitimate putty.exe executable file.

Next, the attacker generates a new payload but uses the legitimate putty.exe file as an executable template for their payload. They name the resultant executable putty_new.exe.

They can now upload this new backdoor executable into the user’s system as shown below.

As a lateral movement technique, the attacker can push out this executable on other systems inside the compromised network to get even more users to unknowingly run the malicious payload.

After the user runs the trojanized putty.exe, they can use the program normally. But in the background, the malicious payload is executed and makes a callback to the attack command-and-control listener as seen here.

On the compromised machine’s running processes, we can see the putty_new.exe process has established a TCP connection (port 443) back to the attacker on app12.webcoms-meeting.com.

Payload encoding

In computing, encoding is the process of applying some algorithm to some data to change its format. Encoding can be useful for changing the format of one data type to another for easy transmission, storage or usage on a target system.

Here is an example of ASCII text (normal English text) on the left, encoded into Base64 on the right. Even though the data is the same, the format is completely different. If one receives only the unfamiliar Base64 encoded text, they will need a Base64 decoder to reverse it to the more familiar ASCII text.

This capability is also extremely useful for threat actors to effectively conceal their malicious code and payloads to attempt to evade detection. Encoding makes it harder to perform static analysis on a payload in as much as a technique like packing makes it difficult to do the same analysis, especially detecting strings.

The following example shows how encoding can be used as part of generating a malicious payload by the attacker.

Here, the encoder algorithm is shikata_ga_nai. The payload is encoded by running this algorithm against it in six iterations as shown in the image below. This helps to obfuscate aspects of the payload and makes it harder to detect, especially by signature analysis using hashing or even static analysis of the payload code and strings.

Threat actors may also use Microsoft Office document macros, Powershell scripts and other native and legitimate binaries and tools to attempt to hide malicious activity. Employing native tools and binaries on a compromised system or in a breached environment is referred to as “living off the land.” Next, we'll examine some mitigation capabilities.

Reactive-first approach: Detection techniques

Reactive-first approaches depend on the initial ability to detect suspicious or malicious activity. Let's explore a few of these.

Static analysis: Code analysis

Static analysis is the process of analyzing a piece of code of an executable on disk. Expanding on this type of analysis from the first article, further static analysis shows some additional useful indicators. This payload file references certain risky strings and libraries and calls some system functions that would be of interest to an investigation of suspicious activity.

Signature analysis: Antivirus

Signature analysis on the basic level involves taking a hash or signature of the file or payload of interest and comparing it to a large database of previously detected, known signatures. This is the approach taken by traditional antivirus solutions. The example below shows the malicious staged payload from the first article scanned against a group of antivirus scan engines.

Dynamic analysis: Sandboxing

Dynamic analysis involves monitoring behavior to detect malicious actions. Here, the payload or file of interest is run in a sandbox environment to study its behavior and compare that to a set of good or bad criteria. Each bad behavior is scored up against a weight to make a final malicious or not malicious detection decision.

A sandbox could be an application such as a browser running and monitored in a protected space, an operating system running inside a virtual machine, or a complete emulation of both computer software and hardware components such as disk, memory and CPU — the latter being the most difficult for malware to evade.

The example below shows a subset of the suspicious activities that an executable or payload will be measured against after sandboxing or emulation.

Reactive-first approaches are important and almost all organizations have some form of it in their networks. But like everything else in security, this approach needs to be complemented with other layers of protection for an effective security strategy — applying the security-in-depth philosophy. Since detection sometimes fails or can be bypassed, preventive-first approaches are necessary.

Preventive-First Approach

As described earlier, the preventive-first approach generally falls under “preventive only” and “prevention and response.” In the next steps, we'll first walk through the initial discovery actions a threat actor might take to find other machines accessible by the machine they have compromised. We'll then examine the steps defenders can take to segment systems on the network, even those on the same subnet, to mitigate the risk of lateral movement.

Preventive Zero Trust Segmentation

Following on from the obfuscated putty.exe payload, a threat actor may continue an attack by performing another discovery scan on the network using the compromised pivot point machine. Threat actors are particularly interested in the common living-off-the-land lateral movement communication paths such as Telnet, SSH, SMB and RDP so as not to stand out in the network.

We can see that some of these communication paths are open on the subnet where the attacker has successfully compromised a machine. This basic scan provides a good indication that both Windows and Linux systems are on the network. Windows systems typically have SMB ports open and Linux systems typically have SSH open.

Considering a proactive, preventive-first mitigation approach, a technology like Illumio Core provides extremely useful visibility. Illumio Core can clearly show the attacker’s actions, even in a “monitor only” mode — in the case below, a one-to-many scan from the pivot machine to the rest of the systems on the targeted subnet. Illumio Core’s visibility map, known as Illumination, shows a business view of the organization’s network. We can also see that these systems are spread across multiple locations.

On the Illumio map, the communication from the scan indicates that it is originating from the HQ-Office workstations destined for Datacentre-1. Identifying useful and actionable information is easy because the systems are all associated with Illumio labels (tags or metadata) to enrich the map. This same information will later be used to define policy without relying on network constructs like IP addresses, VLANs (virtual LANs) or zones, ensuring that security policies automatically adapt to changes.

Another useful capability is to proactively perform an audit of the network using Illumio’s risk analysis and investigative tool. This can show us the risk paths that this network is susceptible to, such as the pathways commonly used by malware and ransomware to spread on a compromised network. We do not actually have to wait for a cyber incident before we act. A recommended pre-emptive risk analysis will clearly and easily provide us with this information as demonstrated below.

In this investigative view above, the Consumer side shows the source and the Provider side shows the destination of the communications. We can also see the ports used and, on the far right, the processes associated with this communication. If required, we can drill down further to the individual machines' names.

As an example, we can decide to take an always-on preventive-only action by putting in location-based controls between our HQ-Office workstations and our Datacentre-1 workloads. This is known as an Enforcement Boundary. It simply blocks all communications between the workstations and the workloads or servers as defined.

Another approach will be to use the Zero Trust allow-list (default deny) policy approach. Whichever approach we decide to take, after enforcing this preventive action, another discovery scan shows that the communication paths that were opened inside the network are now all showing as filtered.

Back to the Illumio visibility map, these communication lines are now red indicating that the scan was not just monitored but blocked this time around.

This means we have successfully mitigated our lateral movement risk proactively across multiple systems running on different platforms at the same time — all from a single point of management. We can still go further with this particular system by enhancing the preventive-only approach with prevention and response to isolate this system for further investigation.

Prevention and Response: Adaptive Zero Trust Segmentation

We have just seen how a preventive approach, such as in the case of Zero Trust segmentation, can ensure an always-on security policy to prevent the spread of malware and other attacks.

However, there might have already been an incident that we need to respond to in some cases. It may be that we had not yet enabled our preventive security policy. This is where the same Illumio Core technology can be used to react and respond, still utilizing a preventive approach but with an added adaptive capability.

In the examples we have shown so far, you will notice that the policies have all been defined by metadata or labels not network constructs or IP information. These labels are also used to logically group the workloads, servers and workstations.

We can see in the screenshot below that we have a policy named “Ransomware-Quarantine” already defined.

We now need to switch one or more of the 4-dimensional labels of the system of interest to the quarantine label shown in the workload inventory page below.

This can be done manually or automatically. It can also be triggered via a SoC (Security Operations Centre) or SOAR playbook as required. As a result of this action, we will automatically isolate that specific system and cut off all communication from that system to the rest of the network. However, we will still allow management communications to monitor and investigate its actions.

From the example below, the infected system has now been isolated into its own quarantine bubble away from the original HQ-Office location and associated application groups. It is effectively cut off from the rest of our systems and even from the Internet, as indicated by the red lines of communication.

However, we can still clearly monitor all this system’s actions safely and continue whatever investigations we might need to carry out on this system.

Additionally, for the critical or “crown jewel” servers and workloads, we can apply other security best practice configurations such as:

• Restricting outbound communications to only a list of approved destinations
• Using internal DNS servers that are heavily monitored and segmented
• Regular vulnerability scans as part of an overall vulnerability management posture

All these capabilities can be incorporated into the same Illumio Core solution to enhance your overall security posture and bolster existing detection and response security investments.

Conclusion

For all the threat techniques described in this series, and even for those yet to be discovered, the aim of the attacker is to move laterally through the environment without being detected. Since most organizations will already have some form of reactive first technology like antivirus, endpoint detection and response, or sandboxing, it is crucial to also ‘lock the doors’ with an always-on preventive-first technology that has adaptive response capabilities.

To learn more about Illumio's malware and Ransomware Containment and visibility capabilities:

• Read "Fight Ransomware Fast With Enforcement Boundaries."
• Check out our three-part webinar series, "Ransomware Happens. We Stop It From Spreading."
• Try Illumio yourself — sign up for free hands-on labs, The Illumio Experience.