The only real thing of interest is that there's an alleged zero day magento exploit out there, PHP in images is nothing new, encrypting it so that script kiddies/ clean up crew can't read the purloined info is not new. Mr Black Hat has just come up with a differing mechanism to protect that data.
Putting the data in a php image is inefficient, as soon as the web server is stopped from serving images as PHP then it collects no more and is reliant on clean up not noticing embedded PHP in the image,
grep -i '<?php' `find . -type f -iname \*.png`
is basic but works.
Much better would be to append the encrypted info to any file (existing or not) in a comment block which would reduce the chance of detection and still enable pick up, or to just send the data out straight away to multiple compromised sites.
This also fails if the magento site is using external authentication for payments, though probably useful for collecting background info like email addresses, address details etc... and the clean up is easy if the site is configured correctly from the beginning, a git repository above the web root by a higher level user would show every altered file and log analysis of access to those files could then be backtrace to the original attack vector.
Distributing the data out immediately is preferable as it retains the max amount of efficiency rather than relying on pick up at a later date, all this indicates is that one black hat is working on a better way of obsfucating which data is exfiltrated and I take my hat off to him, modifying the file time is quite nice as it confuses as to who has bought what during the time the hack was live (and is probably used to check if the file has altered since the last pick up). Downside, makes it easier to track which files were modified for exfiltration during clean up.
Biting the hand that feeds IT
