Support

Ah, finally, someone who's paying attention! Thank you for this ticket :)

We added more malware detection patterns in version 5. These patterns carry a high threat score since the code they detect is most often -but not exclusively- used in advanced malware. Some existing code will of course match these patterns and show a higher Threat Score for the file. After all, scanning source code is by definition impossible to do in a way that's free of false positives unless you have a highly trained, highly experienced, highly expensive and really slow human developer do it.

The example files you shared are exactly where I would expect to see false positives. These files deal with encryption (all of the files belonging to our software that you shared) or use complex regular expression patterns (the SimplePie ones). This kind of code is very likely to trigger the new patterns by error, i.e. a false positive. However, I am healthily paranoid -if you deal with security some low key paranoia is a very healthy sign- and I don't just mark as safe any file I would expect to throw false positives. This kind of complacency is what gets you hacked.

Sidebar: you wondered, why does the Akeeba Backup file show as both modified and high threat score? You are running your scanning every 24 hours. In those past 24 hours you updated Akeeba Backup and Admin Tools. Their files changed so they are no longer marked as safe. The detection patterns in Admin Tools do report false positives on these (changed) files. So everything is working as expected. Closing this sidebar, this is also an inference and susceptible to complacency. So just keep it in mind as a potential explanation of the observed behavior, not as a gospel. End of sidebar.

What you really need to do is check if the file has changed. If the file has not changed but the threat score got bumped it's a false positive; mark as safe and don't think about it twice. If the file has changed you need to verify it. Compare it to the file that's shipped in the official distribution of the software it belongs to. If the files are identical mark them as safe. If they are not, analyze the contents of the file on disk. Clicking the file in the report will highlight the suspicious parts of the file, letting you see what the PHP File Change Scanner "sees" as a problem on the file.

What you should be doing to avoid this pain in the future is run the detection right before and right after updating a bunch of components. You know that the changed files between those two scans are legitimate - you just installed them. Therefore you can blindly mark as safe all of the changed files with a non-zero threat score in this scenario. This is a safe and easy thing to do on top of your daily scan.