A root cause analysis should be part of any incident response plan. For Magento 1 & 2, there is a generic overview of analysis steps. Should you require assistance or a more thorough analysis, please contact us for an in-depth analysis.
Find timestamps of malicious or modified assets
Find (HTTP-) activity in the web server access logs for these timestamps and identify suspect properties such as IP and user-agent.
Find correlated activity for these IPs, user-agents etcetera.
For each activity, repeat step 1.
Compile a list of sources (IPs) and activity into a timeline.
The oldest activity is generally a strong indicator of the root cause. Search the web for indicators that may point to a known exploit. Our open source Magento Vulnerability Database may be a good start.
A typical compromised Magento store has malware injected into static files (PHP or JS) or into the database. For files, the “visible” timestamp is often spoofed by the attacker, however the actual timestamp can be found using the stat command:
$ stat app/webshell.php File: app/webshell.php Size: 29624 Blocks: 27 IO Block: 16384 regular file Device: 1000f6h/1048822d Inode: 437073 Links: 1 Access: (0644/-rw-r--r--) Uid: (11134/webserver) Gid: (11134/webserver) Access: 2019-04-03 05:48:25.991900869 +0000 Modify: 2013-07-04 03:11:18.734417791 +0000 Change: 2019-04-03 05:48:26.531897938 +0000 Birth: -
In this case, the “Modify” date (which you see with
ls -l) is spoofed. However, the “Change” time reflects the date that the file was created. On Linux, this date cannot be spoofed without administrator access. In this case, we can assume that the Change date is a valid pointer.
For databases, it may be problematic to get a timestamp. In some cases, when the attacker uses the Magento admin panel to inject malware, a timestamp is saved in the cms_page or cms_block table. YMMV.
Given one or more timestamps, you should search your web server access logs for corresponding entries. Remember, various web servers will register requests at different times (eg at beginning or end of a request) so it may be useful to examine all activity within 10 minutes of the timestamp. Also take timezone differences into account (what timezone is the server? And the logs? And the database?).
Usually, log analysis will produce one or more suspect requests. Is the originating IP from a far country? Did they provide a user-agent for an old or exotic browser? You can then search the logs for these IPs and user-agent. Note that the use of certain WAF/proxy services may conceal the actual IP.
Without timestamps, your job is much harder. You can start searching the web server access logs for a list of suspicious patterns. Start with this:
cat > filter.txt <<EOM /catalog/product/frontend_action_synchronize /catalog/product_frontend_action/synchronize adminer webgility/ /cms_block/save/key/ /system_config/save/section/design YTozOntzOjc6InByb2R1Y3QiO3M6 magmi/ /madecache/varnish/esi/ /freegift/cart/gurlgift/ /qquoteadv/download/downloadCustomOption/ /ajaxproducts/index/index/ /minifilterproducts/index/ajax/ /advancedreports/chart/tunnel/ /bssreorderproduct/list/add/ /rewards/notifications/unsubscribe/ /emaildirect/abandoned/restore/ EOM grep -Ff filter.txt /path/to/webserver/access.log
This will produce a list of activity. Some of it may be legitimate, so careful interpretation is required.
Need faster or more thorough results? Hire us for an in-depth analysis.
This page was last updated at May 18th, 2020