Tag Archives: PHP

Stealth Code for New Mutation of PHP Bot Infector

Posted on by
5

Recently, I found another new mutation of a PHP bot infector, with zero percent detection by anti-virus software. There was an anti-security tool code included, as well. 

For those interested, you can view this link to see that the total number of anti-virus detections was 0.

However, when I decoded the PHP backdoor, I got 17 anti-virus hits on it. It seems they locked into the c99 backdoor code remnants, which is a pretty old backdoor PHP trojan. This leads to the question about evasion techniques and how effective anti-virus applications are at doing code de-obfuscation. For example, if you want a currently effective AV evasion technique in PHP, it comes down to this simple line of code: (gzinflate(str_rot13(base64_decode($code)))); – There’s the cash money key in terms of evading most, if not all, current anti-virus tools.

However, if you have a process that runs grep against your files  looking for base64_decode and alerts you to new ones, you’ll get visibility to it and many, many others like it. Base64 encoding is still quite a popular call in PHP attack and compromise tools.

Here are some examples of this specific trivial control — here, and here. Now you have a real life example of how it pays off. So simple, yet so effective at detecting these slippery backdoors.

Finding specific nuance controls that pay off against specific threats to your assets is a key way to better security. It’s a win, all around!

What the Heck Is FeeLCoMz?

Posted on by
3
FeeLCoMz is a string I often get a lot of questions about. Basically, people see it and other strings in their logs, or if they are unlucky, they run into it like this, in a file in their web directories:
 
 Basically, if this is in the file system, then the system has been compromised, usually by a PHP RFI vulnerability. Other strings to check for, if you feel you want to run some basic grep checks against web files, include: 
 
“FaTaLz”,”KinCay”,”CreWz”,”TeaM”,”CoMMunity”,”AnoNyMous”,”Music”,
“ProGraMMeR”,”CyBeRz” and “mIRC”
 
If you find those strings, they usually indicate other PHP scanners, worms or attack tools have compromised the system. Now, if you don’t find those, it does NOT mean the system is safe, the list of all of those relevant strings would be too large and dynamic to manage. 
 
Another good grep check to parse files for in web directories, especially PHP and text files, if the nearly ubiquitous, “base64_decode(“, which is an absolute favorite of PHP bot, shell and malware authors. Any files you find using that call should be carefully inspected.
 
If you want to find more information on how PHP RFI attacks and other such issues occur, check out these links 
 
 
Basically, if you find files with the FeeLCoMz tag in it in the web directories, you have some incident response and investigation work to do. Let us know if we can assist, and stay safe out there. 
 
PS – It’s a good idea to have all PHP applications, even common ones like WordPress and the like, assessed prior to deployment. It might just save you some time, hassle and money! 

Excellent Source for Metrics on PHP RFI

Posted on by
1

My friend Eric has put up some excellent statistics and metrics on PHP RFI attacks against his honeynet. This is some excellent data. If you have read other stuff we have pointed to from Eric, then you know what to expect. But, if you are interested in a real world look at trends and metrics around PHP exposures, give this a few moments of your time.

You can find the interface and metrics set here.

Check it out, I think you’ll be impressed. Thanks, as always, to Eric and other folks in the honeypot community for all of their hard work, time and attention.

If you have some honeypot metrics to share, drop a comment below! As always, thanks for reading!

Inside an Average PHP Scan

Posted on by
Reply

I have been talking about PHP scans for a while now. They are so common that we get them on our HoneyPoint deployments all the time, often several times per day, depending on our location.

These scans follow traditional scanner patterns in that they grind through a list of specific urls that are known to have issues looking for a 200 response from the server.

Here is a quick list of a recent scan against one of our HoneyPoints:

/+webvpn+/index.html: 1 Time(s)
/PMA/main.php: 1 Time(s)
/admin/database/main.php: 1 Time(s)
/admin/datenbank/main.php: 1 Time(s)
/admin/db/main.php: 1 Time(s)
/admin/main.php: 2 Time(s)
/admin/myadmin/main.php: 1 Time(s)
/admin/mysql-admin/main.php: 1 Time(s)
/admin/mysql/main.php: 1 Time(s)
/admin/mysqladmin/main.php: 1 Time(s)
/admin/pMA/main.php: 1 Time(s)
/admin/padmin/main.php: 1 Time(s)
/admin/php-my-admin/main.php: 1 Time(s)
/admin/phpMyAdmin-2.2.3/main.php: 1 Time(s)
/admin/phpMyAdmin-2.2.6/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.4/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.6/main.php: 1 Time(s)
/admin/phpMyAdmin-2.6.0-pl1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.6.0/main.php: 1 Time(s)
/admin/phpMyAdmin-2.6.2-rc1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.6.3-pl1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.6.3-rc1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.6.3/main.php: 1 Time(s)
/admin/phpMyAdmin/main.php: 1 Time(s)
/admin/phpmyadmin/main.php: 1 Time(s)
/admin/phpmyadmin2/main.php: 1 Time(s)
/admin/sqladmin/main.php: 1 Time(s)
/admin/sqlweb/main.php: 1 Time(s)
/admin/sysadmin/main.php: 1 Time(s)
/admin/web/main.php: 1 Time(s)
/admin/webadmin/main.php: 1 Time(s)
/admin/webdb/main.php: 1 Time(s)
/admin/websql/main.php: 1 Time(s)
/board/index.php: 4 Time(s)
/database/main.php: 1 Time(s)
/datenbank/main.php: 1 Time(s)
/db/main.php: 1 Time(s)
/favicon.ico: 1 Time(s)
/forum/index.php: 4 Time(s)
/forums/index.php: 4 Time(s)
/myadmin/main.php: 1 Time(s)
/mysql-admin/main.php: 1 Time(s)
/mysql/main.php: 1 Time(s)
/mysqladmin/main.php: 1 Time(s)
/padmin/main.php: 1 Time(s)
/php-my-admin/main.php: 1 Time(s)
/phpMyAdmin-2.2.3/main.php: 1 Time(s)
/phpMyAdmin-2.2.6/main.php: 1 Time(s)
/phpMyAdmin-2.5.1/main.php: 1 Time(s)
/phpMyAdmin-2.5.4/main.php: 1 Time(s)
/phpMyAdmin-2.5.6/main.php: 1 Time(s)
/phpMyAdmin-2.6.0-pl1/main.php: 1 Time(s)
/phpMyAdmin-2.6.0/main.php: 1 Time(s)
/phpMyAdmin-2.6.2-rc1/main.php: 1 Time(s)
/phpMyAdmin-2.6.3-pl1/main.php: 1 Time(s)
/phpMyAdmin-2.6.3-rc1/main.php: 1 Time(s)
/phpMyAdmin-2.6.3/main.php: 1 Time(s)
/phpMyAdmin/main.php: 1 Time(s)
/phpbb/index.php: 4 Time(s)
/phpbb2/index.php: 4 Time(s)
/phpmyadmin/main.php: 1 Time(s)
/phpmyadmin2/main.php: 1 Time(s)
/robots.txt: 15 Time(s)
/sqlweb/main.php: 1 Time(s)
/web/main.php: 1 Time(s)
/webadmin/main.php: 1 Time(s)
/webdb/main.php: 1 Time(s)
/websql/main.php: 1 Time(s)
As you can see, the scanner requests some of the pages many times, usually with subtle differences in the method or url termination scheme. When we have faked the 200 responses for these pages, it simply catalogs the success and continues. Thus far, we have been unable to identify when/if the real human attacker returns to test and play with the finds, since there are just so many scans for these issues going on all the time. But, we continue to monitor and analyze, so hopefully soon we can identify a pattern of scans followed by verification and exploit.

Note that some/many of these scans will immediately exploit the vulnerability in PHP and use it to drop a bot-net client onto the machine. Of course, this immediately compromises the system and adds it to the scanning army. In those cases, the waiting for the return of the human attacker would not apply.

So, what does all of this mean? We wanted to give you some more insight into the wide scale PHP scans and what they look like. If you have not checked your own web site for these known vulnerabilities, it would likely be very wise to do so. It can be done quite easily by hand, using a simple Perl script or any of the publicly available web scanner tools.