When the Imunify360 Malware Scanner component identifies an injected code snippet as malicious, how can you tell it’s malicious? How can you avoid reporting this malicious code as a false-positive? The Imunify product team can show you how.
Correcting Erroneous False-Positives
Sometimes, Imunify360 users see a file identified by the Malware Scanner as having malicious code in it, then they open the file and it looks okay to them. So they decide that Malware Scanner made an error, and report it as a false-positive: a file that’s been identified as malware, but isn’t actually malware.
When the Imunify analytics team reviews these files reported as false-positive, they almost always turn out to be real malware. Since Imunify360 incorporates user reports into its rules, taking time to correct these erroneous false-positive reports slows things down a bit.
To reduce the number of false positives in the false-positive queue, speed things up, and make server protection more efficient, the Imunify analytics team thought it would be a good idea to show Imunify360 users how to “read” files and distinguish malicious code.
We’ve outlined several ways to distinguish malicious code below.
Signs That Code Is Malicious
It creates temp files arbitrarily.
In the example of malicious code below, a file is created in the server’s temp directory using:
Then code is passed into the file using:
fwrite($handle, "<?php\n" . $phpCode)
This code is executed by running an include() on the new temporary file, after which the temporary file is deleted from the server.
It drops files into key directories.
Malicious code often drops files into WordPress’ core directories, such as wp-admin and wp-includes.
In the example below, you can see that a file named
wp-tmp.php is being dropped into
It uses hardcoded passwords.
Malware commonly uses hardcoded passwords and authentication keys. They give attackers web access to a file using superglobal arrays such as
In the example below, the parameter password enables the attacker to access the file with a custom password. This is done to prevent other hackers from accessing the malware.
It communicates with sketchy domains.
Malware will try to communicate with sketchy domains of unknown origin. In the code below, for example, it wants to communicate with a Command & Control (C2) server at marors.com:
It employs includes.
Includes and references to other files are often unsafe, because they can be part of more complex malware. For example, the code below references and includes a file named
class.theme-modules.php which contains the main malware code.
The one-line include is being used to check for the presence of that file, then execute it:
It obfuscates code.
Malicious code is deliberately obfuscated to make it difficult to understand and read. For example, the code below includes a malicious file, obfuscated to make it harder to identify:
It uses an error control operator (
If an error control operator (
@) is used before any critical PHP functions, such as
curl_exec, it’s often a sign that the code is malicious.
When a function is preceded by the
@ sign, error messages generated by that function are ignored, which can prevent malicious activity from showing up in logs. Here’s an example:
It employs a long single line of code.
If there’s a large piece of code at the top of a file in a single line, that code is probably malicious.
In the example below, a large chunk of obfuscated code has been injected into a core wordpress file, code that creates a backdoor. This is difficult to see in a text editor without word wrap enabled...
...but with word wrap enabled, you can see how large that single line of code really is:
A Good Rule Of Thumb
If you’re not sure about whether a piece of code is malware, just click the “Clean Up All“ button in Malware Scanner, and wait until it finishes cleanup.