As an interpreted language, PHP has the unique problem of disclosing all of its source code. This does not benefit malware developers trying to hide their code. Obfuscation helps, but only to a certain extent. This is to the benefit of security researchers. After finding a nasty infestation on a clients site, I was intrigued by the different ways these malware devs were using the web to defeat modern anti-virus techniques.
One way this piece of malware kept prying eyes from seeing exactly what it was doing, was by taking use of the eval() PHP function. After sending a GET request to a server with the param abc=1, the server would return the payload within the body of the response. Before writing to disk, the payload was sent to the eval() function and executed. this keeps any malware from being present on disk, and stops Heuristics engines from scanning the file.
While I applaud the ability to keep the payload in memory, the base64 encoding of the staging mechanism would not only scare anyone who doesn’t see code on a regular basis, it would also red flag both experts and a lot of detection engines. The use of
include("base64encodedstring") as a path to the malware did absolutely nothing for keeping the malware safe. The poor idea that unreadable meant undiscoverable made me wonder the level of technical skill of the authors.
It seems modern detection engines, while sophisticated in some degree, lack some basic parsing skills. The amount of malware that passed through just fine by defining parts of the payload in different areas, then using
. to concat them together was too damn high. I think this highlights an ever=evolving style of malware development. It’s not the idea that the cryptography is better. Nor the idea they found some 0day vulnerability that allows a rootkit to be installed. It’s simply doing something that many malware detection engines fail to do. Perhaps something like AI is the future for detecting these anomalies.