<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-5HLVVHN" height="0" width="0" style="display:none;visibility:hidden">

Avoiding Erroneous False-Positives in Malware Scanner

erroneous_header

 

When the Imunify360 Malware Scanner for Linux servers 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:

 

tempnam(sys_get_temp_dir(), "theme_temp_setup")

 

Then code is passed into the file using:

 

fwrite($handle, "<?php\n" . $phpCode

arbitrary

 

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 wp-includes:

 

directories

 

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 $_GET, $_POST, $_REQUEST, $_SERVER, and $_COOKIE.

 

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.

 

passwords

 

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:

 

domains

 

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:

 

includes

 

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:

 

obfuscates

 

It uses an error control operator (@).

 

If an error control operator (@) is used before any critical PHP functions, such as include, file_get_contents, eval, chmod, or 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:

 

error

 

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...

 

smwrap

 

...but with word wrap enabled, you can see how large that single line of code really is:

 

wrap

 

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.

 

cleanupbut

Imunify360 is a comprehensive six-layers web server security with feature management. Antivirus firewall, WAF, PHP, Security Layer, Patch Management, Domain Reputation with easy UI and advanced automation. Try free to make your websites and server secure now.
TRY IMUNIFY360 NOW

Avoiding Erroneous False-Positives in Malware Scanner

erroneous_header

 

When the Imunify360 Malware Scanner for Linux servers 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:

 

tempnam(sys_get_temp_dir(), "theme_temp_setup")

 

Then code is passed into the file using:

 

fwrite($handle, "<?php\n" . $phpCode

arbitrary

 

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 wp-includes:

 

directories

 

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 $_GET, $_POST, $_REQUEST, $_SERVER, and $_COOKIE.

 

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.

 

passwords

 

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:

 

domains

 

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:

 

includes

 

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:

 

obfuscates

 

It uses an error control operator (@).

 

If an error control operator (@) is used before any critical PHP functions, such as include, file_get_contents, eval, chmod, or 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:

 

error

 

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...

 

smwrap

 

...but with word wrap enabled, you can see how large that single line of code really is:

 

wrap

 

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.

 

cleanupbut

Imunify360 is a comprehensive six-layers web server security with feature management. Antivirus firewall, WAF, PHP, Security Layer, Patch Management, Domain Reputation with easy UI and advanced automation. Try free to make your websites and server secure now.
TRY IMUNIFY360 NOW

Subscribe to Imunify security Newsletter