Polymorphism: Less Different Than You Might Think
- The polymorphic nature of some malware makes it difficult to analyze on a case-by-case basis because of the volume and its ever changing nature. Through analysis of the memory footprint, we can gain insight that might not be otherwise available.
In the memory analysis of a sample case study, we are able to observe the following malicious activity:
- Deleted executable files with an uncommon name
- Spoofed command line execution
- Command history logging disabled
- The use of memory analysis can reduce dwell time and help mitigate the risk
The Problem of Malware Analysis Today
Malware is becoming increasingly smarter; employing environment validation and polymorphism as a way to evade security products. This translates to an overwhelming numbe -hundreds of thousands-of samples generated everyday by malware authors. Reverse engineering samples at this scale is an uphill task for a security vendor.
With that in mind, analysis of the memory footprint can provide a unique perspective into malicious events and bring down the number of samples to be evaluated as this tends to change less frequently in highly polymorphic campaigns as well. Despite the evasion techniques employed, the end goal and thereby actions taken will typically leave a trace in memory. Using SureView Memory Integrity , we are able to look at changes that happen in memory and identify events that compromise the integrity of processes in addition to performing memory based forensics. This helps reduce dwell time by enabling administrators to take action when a Linux server is compromised. They are able to detect stealthy malware and get alerted on unknown or unexpected modifications to systems without the need to constantly update the product with signatures.
More Than Meets the Eye
In this run, we ran variants of the currently active and highly polymorphic Linux/Xor.DDOS Trojan variant. The naming by the research community is based on the use of XOR encryption within its code and in its CnC traffic. The ability to compile its source code to target various systems in combination with XOR encryption gives it a polymorphic quality which makes it rather difficult to recognize with traditional detection methods. Additionally, it employs varied usage of DNS server lookups and ports. Let's explore some of the first indicators of a server’s compromise via analysis of the server memory.
One of the first warnings that arises is that executable files have been unlinked (deleted) from the file system. By removing executed files, malware authors attempt to cover their tracks. It's interesting that, one of the executable files has an uncommon name /usr/bin/kzeqlxgdeg thereby adding to the suspicion. At this time, we can observe that the alerted files were executed and unlinked. Let’s see what additional context we can derive.
Looking at the entire process tree we get a view into the executed commands associated with the unlinked files. In this case, we are observing a set of commands that reveals system details:
- Reveals the active user account (PID 3866)
- Current DNS servers being utilized (PID 3875)
- Provides a glimpse of the networking environment that the infected machine is in (PID 3876)
- Lists users currently logged in (PID 3880)
- Enumerates running processes, providing lists of exploitable applications (PID 3890)
- Enumerates files on system (PID 3891)
As you can observe, one of the executable files appears to use the “cat resolv.conf” command, which would reveal routines that provide access to the Internet Domain Name System (DNS). We can then take this a step further and trace the observed discrepancies by PID.
What appeared to be a suspicious command associated with reconnaissance tactics reveals itself to be something more nefarious. A discrepancy is found between the logged terminal command and the actual command executed (Fig. A). While the full command line entry, which we also observed via PID logs, reads “cat resolv.conf” this is actually a spoofed command tgat was logged (as seen in the process tree). As we can observe in the command field the executed item was in fact “kzeqlxgdeg”. We are able to observe the actually executed command despite attempts to spoof a less suspicious one. When looking at the environment at the time of execution we observe the actual intent (Fig. B). In this case, environment variables have been set to prevent further command history from being logged.
If end users have specific evidence, they are able to address the matter at hand as well as discover the methodologies that were employed. This provides a basis for strengthening the overall ecosystem based on observed or attempted malicious attacks on even a single machine. This is due to monitoring of memory over time that allows the analyst to identify changes which deviate from the norm.
This malware variant employed a variety of techniques to evade detection by administrators and security researchers. We have been able to leverage indicators that allowed us to identify anomalies that have occurred on our system that would otherwise be difficult to trace – especially after some of those initial changes made by the malware. While traditional forensic analysis techniques might look for indicators which are dynamic in nature, analysis at the memory level gives us a view into server activity not otherwise available. This provides the analyst a starting point for investigation and quick remediation.
Results from above can be used in addition to the context and other triggers on the system to arrive at the total risk to the system from the specific incident. In this case, the suspicious events above can be combined with other network behavior of the Linux/Xor.DDOS Trojan such as reaching out to its CnC server to get a list of targets, downloading arbitrary binaries, DDoS activity behavior. This risk based approach helps prioritize incidents that need to be further investigated to reduce dwell time and mitigate risk.
Contributors: Jose Barajas with input from Andrew Tappert, Tom O’Connor and Rajiv Motwani