Threat Actors Using Obfuscation in Attempt to Evade Detection

As part of our product lineup, we offer security monitoring and malware removal services to our Wordfence Care and Response customers. In the event of a security incident, our incident response team will investigate the root cause, find and remove malware from your site, and help with other complications that may arise as a result of an infection. During the cleanup, malware samples are added to our Threat Intelligence database, which contains over 3.5 million unique malicious samples. Interested in integrating this data into your solutions? Check out Wordfence Intelligence Enterprise.

In a previous blog post we analyzed a malware sample whose author intended to make it look like normal code to the naked eye while carrying out a malicious task. Today, we would like to dissect and share a style of malware that uses several layers of obfuscation to disguise its main purpose while not hiding the fact that it is malicious. It was added to our malware database on February 20, 2023 when one of our analysts discovered it during a site clean.

Obfuscated malware sample (line breaks added)

A signature was developed by the same analyst the following day and released to production within a week after undergoing testing. Customers still using the free version of Wordfence received this signature after a 30 day delay.

Analyzing the Sample

Rather than making this script blend in by making it look like this code was written by a human, this sample makes use of several different techniques that help it evade detection.

Density

The screenshot above was edited in order to make sure the sample was legible. In reality, the entire sample was contained on one line when we found it. We don’t see a lot of whitespace in this file, certainly not more than one space character in a row. We often find this to be the case with malware that relies on heavy obfuscation. PHP code written by humans tends to be properly indented and readable, although exceptions exist of course.

Commenting

One of the most notable elements of this malware is the excessive use of comments in the file. Typically, human coders use comments to describe what their code does, while in this sample comments are exclusively used to break up code bits and make it harder to detect using common malware detection methods such as signatures. Comments in PHP are formatted as follows:

• /* some comment that spans one or more lines */
• // comment begins and ends with a newline (c++ style)
• # comment begins and ends with a newline (shell-style)

Once we remove those comments we get a clearer picture of what this sample does.

Obfuscated malware sample after removing comments (line breaks added)

Use of Variable Functions

After removing the comments, this sample does appear to be a bit more legible, but it still needs a little bit of work. The variable $ojq is set to the string “range” using string concatenation. The command $nHpCr = $ojq("~"," "); creates an array of items in the range defined by the two function arguments. Ultimately, the array stored in $nHpCr contains all the characters in the following string:

~}|{zyxwvutsrqponmlkjihgfedcba`_^]\[ZYXWVUTSRQPONMLKJIHGFEDCBA@?>=<;:9876543210/.-,+*)('&%$#"!

Concatenation and Arithmetic

What follows is an include statement. This include statement is built from individual characters of the aforementioned array via concatenation. Each of those character lookups uses arithmetic operations for further obfuscation. In the end, this entire malware sample accomplishes just one thing. It includes the file named yEghAwUPIiznpu.m4a, a file with an extension associated with audio files. This file adds yet another layer of complexity.

yEghAwUPIiznpu.m4a after editing for legibility

This sample makes use of similar obfuscation techniques. We removed the comments that littered the file and added some line breaks as well as indentation. The script begins with some cookie checking before declaring a class and also uses the range function along with string concatenation for added obfuscation.

We notice a static function that sets up a cURL session – used to communicate with a remote server, see checks for $_GET parameters as well as some __FILE__ handling. A protection mechanism that performs a password check is used to protect this malicious shell from unauthorized access.

While we had other signatures in place that aimed at detecting obfuscated malware similar to these samples, we realized that those signatures were not robust enough to handle recently discovered samples as well. This shows the importance of continuous signature development and of embracing redundancy during the signature development process instead of attempting to detect as many files as possible with the fewest possible number of signatures. Regular analysis of new malware samples is crucial to detection – especially when malware samples exhibit several of the aforementioned features.

Further Research

Since the discovery of these two samples, we have added dozens of signatures that target comment placement, the use of arithmetic when accessing array elements, density, excessive string concatenation, and other features often seen in obfuscated files.

We do this by writing signatures that target certain malicious behaviors of interest in novel ways. As part of our QA process we evaluate false positives as well as other potential issues and address those where possible. Taking this multi-pronged approach to signature development allows us to improve our detection capabilities more quickly and beyond the corpus of files we already have.

As a result of these efforts the first sample is now covered by five production signatures with additional signatures currently still in the testing stage. The second script is covered by six of our signatures and has additional signatures waiting for production approval.

Conclusion

In today’s post we discussed several obfuscation techniques used in a web shell to try and disguise its real purpose and evade detection. We discussed how these techniques can alternatively be used for detection purposes, and how we used broader research signatures to expand detection.

Our Premium, Care, and Response users as well as those who are still using the free version of Wordfence are protected by our malware scanner during file uploads against the upload of this sample as well as some of its variants. This means that Wordfence will block any attempts by attackers that try to upload this file to a compromised WordPress site. Properly configured scans running on those sites will also detect this sample in the unlikely event it is uploaded to a site during an infection.

It’s important to remember that detection of a compromise is just as important to security as ensuring your site remains protected. By using the Wordfence plugin, and ensuring it has been optimally configured along with following security best practices, you’re ensuring your site remains as protected as possible. Nothing can ever be 100% secure, and risk can never fully be mitigated, so it’s important to have monitoring on your site in the event your site is still compromised despite following all best practices. The Wordfence scanner will alert you to any infections so you can initiate an incident response, and also block malicious malware uploads in the event an attacker gets past a site’s first line of defense.

If you believe that your site might be infected, you can enlist the help of our Incident Response team by purchasing our Care, or Response offering or follow this guide to remove the infection yourself.

If you have a malware sample that was missed during a Wordfence scan, please let us know by sending the sample to us at samples@wordfence.com.