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
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
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
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.
In this article
What is Magecart?
Also known as digital skimming, this crime has surged since 2015. Criminals steal card data during online shopping. Who are behind these notorious hacks, how does it work, and how have Magecart attacks evolved over time?About Magecart