Detect and remove PHP.Anuna

[touchweb-vincent]

Hello,

I just found your amazing software, thanks you for all this. That's great.

I'm currently working on a quick and efficient solution in order to remove PHP.Anuna from an infected Prestashop.

Your software only detect 2 infected files instead of hundred.

I would like to help you to improve your work.

How can i help ?

PS : To detect PHP.Anuna, you have to detect this sequence : "\x61\156\x75\156\x61" inside a PHP file, always at the beginning of the file.

Best regards,

Vincent GUESNARD

[jvoisin]

Thank you for your kind words.

Can you please provide us a sample of PHP.Anuna, so we can create generic signature for it :)

If you're looking for something to detect known classic samples, over efficiency, you can give a try to Loki, who uses artifacts, instead of generic signatures.

[touchweb-vincent]

Here we go : http://pastebin.com/n6vjDVzZ

As you will quickly understand, it's a polymorph. I'm tracking it over this sequence : "\x61\156\x75\156\x61" which is the only way i found to match it.

It has infested absolutely all .php files of my customer (for the story, who contact me because of this, few days ago). I'm writing a repair tool to overwrite all .php files.

Currently, nor ClamAV nor ISPProtect detect it.

Full decrypted source code : http://magento.stackexchange.com/questions/28826/magento-website-hacked-encryption-code-in-all-php-files/72702#72702

[jvoisin]

Unless we can gather a large number of sample (or even better, the builder), odds are that we won't be able to write generic detection rules.

If anyone has an idea, I'll be happy to hear it :)

[jvoisin]

You can grab a yara rule here to detect it, and integrate this into your PMF instance.

[touchweb-vincent]

Seems that it has been potentially created with this awesome one : http://pastebin.com/u9sz0s5K (which is completely useless for us) - We could at least detect this pure bullshit with a fingerprint and mark it as webshell (instead of "ObfuscatedPHP" as your software do)

Here is another potential webshell i found to manage files : http://pastebin.com/pfq8AuGj - your software didn't tell anything about it (it's not a blame since it can be a false positive)

And finally, this one, which seems to be crawler : http://pastebin.com/qTkhfZqf

---

J'ai cru comprendre que vous étiez français. J'aimerais intégrer nativement votre outils dans mon CMS, ainsi que vous aider, autant que je peux. La GPL ne me permet pas de l'utiliser. Serait il envisageable de le distribuer sous LGPL ? (Yara ne pose pas de soucis avec sa BSD light)

Cependant, je ne sais pas trop comment interpréter cela : "Of course it's trivial to bypass PMF, but its goal is to catch kiddies and idiots, not people with a working brain. If you report a stupid tailored bypass for PMF, you likely belong to one (or both) category, and should re-read the previous statement." ;)

A très bientôt j'espère

[jvoisin]

Thank you for your 3 samples. The first one is already detected, the second could be legit, and the last one doesn't exhibit a super-malicious behaviour.

We just changed the license of PMF to LGPL, feel free to include it (and to advertise about this) into whatever products you want :)

[farahpoor]

https://github.com/farahpoor/WHICH
use Project WHICH(Web Host Integrity CHECK ) an open source File Integrity Monitoring (FIM) for monitoring and detecting php.anuna and replace infected files with original files.

[jvoisin]

https://github.com/farahpoor/WHICH
use Project WHICH(Web Host Integrity CHECK ) an open source File Integrity Monitoring (FIM) for monitoring and detecting php.anuna and replace infected files with original files.

Once you've fixed the multiple sql injections, xss, symlink DoS and using modern cryptography instead of the infamously broken md5 function in your script, we might consider checking it.

Let alone the fact that using a php script with credentials in it to check the integrity of your php setup doesn't sound like the best way to go.

Please do keep us in touch if you ever implement "automatic tampered files recovery", we'd love to see if/how we could leverage it as an arbitrary file overwrite.

Thank you very much.

[farahpoor]

Dear jvoisin,
Thank you very much for your comment.
I will be glad if people can work on this project for completing and providing more future to this project, I just tried to provide a simple method for solving this problem. if you contribute to this project I will be glad.
also I updated it to SHA512 hash function.

[lukapaunovic]

Here it is

https://pastebin.com/r6B9zmLn

[jvoisin]

$r yara ./php.yar -s sample.php
DodgyPhp sample.php
0x1a7a:$reversed: NoiTCnUF_EtaERC

[lukapaunovic]

Edit: Do NOT run this command on a production server

Here is a really neat command I constructed to remove this virus.

user="user"
dir="/home/user"
find $dir -type f -iname '*.php' -print0 | xargs -0 -I{} sudo -H -u$user sed -i '1s/.*\(<.*\)$/\1/g' {}

[jvoisin]

Your command will break a lot of valid files, please don't provide such kind of commands on issues, because people will inevitably run them.

If a machine is compromised, you should do a complete forensic analyse, find the root cause of the compromission, trash the data, and redeploy a clean backup. Trying to disinfect files with find will always make you miss backdoors.

[lukapaunovic]

Why would it break valid files? It's only removing the first line if it has an opening and closing tag in it. and I already checked with maldet. Each PHP file has this virus on the first line.
And I'm not disinfecting them with find but SED
I counted the total of php files with wc -l and then i counted detected by maldet, then I inspected manually diff files. In my case, each file had same virus code I provided above.
And obviously, a person should make a backup before running it.
Also, on WordPress site, this couldn't break anything. No WordPress installation has

<?php ?> on it's first line.

I tested this on many regular PHP files and did a DIFF and it did nothing harmful.
The most help you can give @jvoisin is explaining what this sed syntax does rather than saying not-helpful statements like 'oh this would break...'. Or providing a better solution for removing this virus for inexperienced users.

EDIT:
What I am trying to say this issue has a lot of hits from Google and therefore any solution should be provided.

[jvoisin]

And obviously, a person should make a backup before running it.

This isn't obvious. Only a smart fraction of webmasters do have backups. You provided a command that you referred to as "neat", not as "this could (and will likely)" completely wreck your website, please do backup before."

Also, on WordPress site, this couldn't break anything.

Not everyone is running WordPress, and some CMS are using <?php … ?> on the first line. What about generated web pages, where everything is on the same line? What about my premium plugins that I paid for and that are obfuscated?

I tested this on many regular PHP files and did a DIFF and it did nothing harmful.

Cool, but it breaks valid things here. Proving that something works on some cases doesn't meant that it'll work everywhere.

The most help you can give @jvoisin is explaining what this sed syntax does rather than saying not-helpful statements like 'oh this would break...'.

Or you could avoid throwing cryptic command on issues about disinfecting compromised website, and hoping that no one will run it without backup, on production. The statement about your command breaking things is actually helpful, since it will prevent people from nuking they compromised website by running non-trivial copy-pasted sed commands found on a random github issue.

Or providing a better solution for removing this virus for inexperienced users.

Like something along the line of the second paragraph of my previous reply?

What I am trying to say this issue has a lot of hits from Google and therefore any solution should be provided.

It is indeed the first link on Google when you type remove PHP.Anuna, so providing fool-proof solutions is desirable, however, providing trigger-happy nuclear foot-gun isn't.