Root cause analysis for Magento hacks

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.

General approach

1. Find timestamps of malicious or modified assets

2. Find (HTTP-) activity in the web server access logs for these timestamps and identify suspect properties such as IP and user-agent.

3. Find correlated activity for these IPs, user-agents etcetera.

4. For each activity, repeat step 1.

5. Compile a list of sources (IPs) and activity into a timeline.

6. 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.

Finding timestamps

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.

Finding activity

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.

No timestamps?

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.