Support

Please do read the documentation to understand what the Threat Score is and what the PHP File Change Scanner does. The file did get marked as "modified", therefore the PHP File Change Scanner performed correctly.

Regarding your complaint, we have the following regular expression to match preg_replace with the e switch:
#preg_replace(\s)*\((\s)*[\'"]{1}(\s)*.\.\*.e(\s)*[\'"]{1}#
That regular expression has a Threat Score weight of 100. As you have observed, it does not match the line in your script.

The line in your script has nothing suspicious gong on about it as far as a computer can tell. preg_replace is a valid PHP function and the e switch does have valid uses (just like exec and base64). Giving a threat score to that indiscriminately increases the rate of false positives.

The only dead giveaway that this line may be a problem is the fact that the POST variable it's looking for is called fbnjkwuzqjehgvw which looks like random letters. Please note that this QUALITATIVE parameters cannot be encoded into a hard rule without answering "what is a non suspicious variable name" first. The parameter names id, cid, identity, client_identity, taftotita, taftotita_xristi, identidad_cliente, kundenidentitaet, kident, identite_client all refer to the same thing and are all valid... if you speak the relevant language (in my example: English, English, English, English, Greek, Greek, Spanish, German, German, French). Some are full words, some are abbreviations. Even intClntIdNr would be valid in the context of a variable name even though it looks like line noise. This is called the "Hungarian notation" and translates to English as "integer representation of Client Identity Number). So, creating a rule which can reliably predict "suspicious" variable names is impossible.

What you need is software which can detect the changes and potential problems to the files and highlight them to a human operator who can then apply good old-fashioned human fuzzy logic and common sense to figure out if something is malicious. This is what the PHP File Change Scanner does and it's documented.

If you were using the product as documented you'd have seen that a file changed when you do not expect it (you didn't upgrade the template). The generated diff would point you out to this line which you can evaluate, using human logic, that it's probably malicious. This is all already possible.

If you expect a software product which can analyse source code and tell you with great accuracy which code is malicious, you are looking for a human role called a "senior software developer" and his or her salary starts at about 50,000 Euros a year. Even that human wouldn't be able to have absolute accuracy. Reading free form text (source code) and flawlessly understanding its intent is something that machines have NOT mastered yet.

So, no, service providers DO NOT have this kind of technology. They are using exactly the same technology as us: they are applying regex of known patterns against source code and choose different weights for each patterns and thresholds for marking code as malicious. A service provider usually errs on the side of more false positives, delegating the responsibility for proving that you are not elephant to you. Some will even arbitrarily delete legitimate code files that their scanner misidentified as malicious. We've written about this in December 2013, when exactly this kind of pattern scanner resulted in some hosts deleting the legitimate files of our extensions, including Admin Tools. Ironically, the best way we found to protect our code against these scanner was to do what any self respecting real hacker would do: we compressed and encoded our code that was triggering the scanner and we decompress and decode it on the fly. Look at the administrator/components/com_admintools/backend/platform/Filescan/Archiver/Jfscan.php lines 405 to 420 and administrator/components/com_admintools/backend/platform/Filescan/encodedconfig.php to see what I'm talking about. Technically, this code pattern is malicious and should have raised a million red flags if the technology you mistakenly assume exists really did exist.

You know what's the closest technology has come to that? The deep source code analysis in IDEs like phpStorm and Visual Studio. However, they can only map which piece of code calls which other piece of code, not what the code does. Moreover, in order to do that, they need to expend 100x to 500x as much CPU power and 50x as much memory as the PHP File Change Scanner. Running that against your site would bog down your server for dozens of minutes to hours at a time. And even if you did do that, you would get exactly zero insight into the code intention, which means that you're back to weighed pattern matching, i.e. the technology employed in the Threat Score calculation in the PHP File Change Scanner AND every single host's "AI-powered malware scanner" (which is as much AI as I am the Queen of England). Try asking them and see how they avoid giving you any meaningful answer of how exactly they detect "malware" PHP files.

I rest my case.

In any case we might adjust our pattern to match more instances of preg_replace with the e flag BUT only if it does not unnecessarily increases false positives. As I explained and we have documented, the PHP File Change Scanner feature is designed to detect and inform you about changes in your PHP files. It does not pretend to give you an accurate malware analysis BECAUSE THIS IS IMPOSSIBLE AND WHOEVER CLAIMS THAT IS A LIAR.