Threat actors that target eCommerce platforms to skim credit card information from online shoppers are commonly referred to under the umbrella threat actor name “Magecart.” This blog analyzes recently observed Magecart tactics, techniques, and procedures (TTPs) used to exploit e-commerce applications and steal credit card information from customers during online checkout.
A popular target of Magecart threat actors has been the Magento eCommerce platform, which is used by merchants to offer direct-to-consumer goods for sale. Since 2016, Magecart threat actors have targeted Magento retailers
by exploiting CVE-2016-4010, a PHP Object Injection vulnerability in the Magento API. More recently, however, CrowdStrike has observed Magecart threat actors targeting undisclosed PHP Object Injection vulnerabilities in Magento eCommerce third-party plugins and extensions. Like CVE-2016-4010, these vulnerabilities allow an attacker to execute arbitrary code in the context of the vulnerable server, commonly known as a remote code execution (RCE) vulnerability.
Initial Reconnaissance
CrowdStrike observed recent attacks against Magento that began with an automated scanner attempting to identify URIs (Uniform Resource Identifiers) associated with previously aggregated vulnerable Magento plugins. The scanner requests various URIs with a basic PHP Object Injection payload to probe for vulnerable servers. An example scan request for the resource/madecache/varnish/esi
is below.
As shown in Figure 1, the attacker assigns a large base64 encoded string to the misc
parameter and sends a secondary request parameter dl
. A closer look at the misc parameter indicates the data is likely base64-encoded, and decoding the data shows a serialized PHP object indicative of a typical PHP object post request.
The decoded PHP object looks benign, with the exception of a 29-character string embedded toward the end of the object:
When the PHP Object is deserialized, this snippet of PHP code included in the object will be executed in the context of the server. If the
/madecache/varnish/esi/
resource is vulnerable, the server will retrieve and evaluate the contents of the "dl" parameter, shown in figure 3 above. Percent-decoding the dl parameter value shows the following code snippet exit("<h1>Hi</h1>");
. From this, we determine that the adversary is likely performing automated scanning of a large set of domains to check for the HTTP 200 response of Hi
. This response determines if the URI queried is present on the web server and vulnerable to PHP Object Injection.
CrowdStrike identified Magecart threat actors scanning for 30 URIs, shown in the list below:
- /rewards/customer_notifications/unsubscribe/
- /appointment/index/index/
- /AvisVerifies/dialog/index/
- /pdffree/Product/pdfsave/
- /ajax/Showroom/submit/
- /prescription/Prescription/amendQuoteItemQty/
- /netgocust/Gwishlist/updategwishlist/
- /CustomGrid/index/index/
- /simplebundle/Cart/add/
- /layaway/view/add/
- /multidealpro/index/edit/
- /vendors/credit/withdraw/review/
- /customgrid/Blcg_Column_Renderer_index/index/
- /tabshome/index/ajax/
- /customgrid/Blcg/Column/Renderer/index/index/
- /customgrid/index/index/
- /aheadmetrics/auth/index/
- /rewards/customer/notifications/unsubscribe/
- /gwishlist/Gwishlist/updategwishlist/
- /vendors/credit_withdraw/review/
- /vendors/withdraw/review/
- /emaildirect/abandoned/restore/
- /rewards/notifications/unsubscribe/
- /bssreorderproduct/list/add/
- /advancedreports/chart/tunnel/
- /minifilterproducts/index/ajax/
- /ajaxproducts/index/index/
- /qquoteadv/download/downloadCustomOption/
- /freegift/cart/gurlgift/
- /madecache/varnish/esi/
From RCE to Payment Information: Attack Path Analyses
Example One: Overwriting a Core JavaScript Library
In this attack path, the attacker attempts to overwrite a JavaScript library file, used by the victim website, with attacker-controlled JavaScript. The HTTP request for this type of attack would look like the following: The payload in Figure 4 is similar in structure to the scanning payload except with a larger dl parameter value. The attacker uses the same PHP Object Injection technique to execute the dl parameter in the context of the vulnerable application. Percent-decoding the dl parameter shows the code snippet in Figure 5. As shown in Figure 5, the attacker attempts to coerce the server to download a JavaScript file from attacker-controlled infrastructure$url
and overwrite a local file on the victim server $dest
using native PHP functions.
The attacker strategically overwrites a core JavaScript library file because these files are referenced on every Magento web resource. This means they are executed by the victim’s browser every time a Magento-affiliated web page is visited. If the JavaScript code identifies a credit card form on the current webpage, the code will capture the credit card information on submission and forward the credit card data to the attacker-controlled infrastructure.
Example Two: Altering the Magento Configuration Database Table
CrowdStrike has also observed a secondary attack vector involving a sequence of payloads from the attacker. Using the same PHP Object Injection vulnerability to execute a request parameter, the attacker first attempts to retrieve the Magento configuration filelocal.xml
by executing the following PHP code:
The configuration file local.xml1
contains the plaintext username and password for the Magento database, providing the attacker with the necessary credentials to directly connect to the database via a similar payload. The attacker uses the compromised credentials to update the Magento core configuration table core_config_data
to reference attacker-controlled infrastructure. The attacker’s command would look similar to Figure 7, displayed below.
The base64-encoded $k
variables decode to a raw SQL query, as shown below in Figure 8.
The config_id
variable referenced in Figure 6 typically corresponds to a generic HTML tag, such as footer
, that is included on every page of the eCommerce website. Therefore, the attacker-controlled JavaScript executes on each page, allowing the attacker to identify credit card forms and exfiltrate payment card data.
Example Three: Exploiting Old Vulnerabilities
Creation of a Database Account
To gain access to the Magento database, attackers have also exploited versions of Magento that do not have the SUPEE-5344 patch. This exploit leverages a vulnerability where the attacker can create database administrator accounts through GET requests against the web front-end. Figure 9 contains an example GET request where the attacker references the WYSIWYG (what you see is what you get) page editor resource to leverage an SQL Injection and ultimately create a new database administrator account inside a base64 payload. Figure 10 shows the decoded payload, which created the database administrator accountrogueaccount.
Leveraging the Magpleasure Extension
With the malicious database administrator account created, the attackers can install additional tools to aid in their attack. One tool in particular includes the Magpleasure filesystem Magento extension, which allows administrators to modify the web server’s filesystem. Similar to PowerShell in Windows, Magpleasure is used legitimately by admins, but threat actors also leverage the extension to modify files within the web directory and further their attack. In a number of investigations CrowdStrike has conducted, Magpleasure was identified within the php-fpm-error.log
file on a victim web server. An example from the error log is shown in Figure 11.
Magento Core File Code Injection
In addition to overwriting JavaScript libraries, CrowdStrike has also observed attackers modifying a core PHP file within Magento. In this example, the attacker inserts base64 encoded code within the functions.php core Magento file. The malicious code snippet extracts victim billing information from HTTP POST requests and copies the extracted information to a file on disk. The code injected into functions.php can be seen in Figure 12. Figure 13 shows the code from Figure 12 after it has been de-obfuscated. The malicious code is loaded when functions.php is imported into other Magento scripts. The snippet attempts to match strings within the preg_match regular expression with data sent via HTTP POST requests by potential victims. If a regular expression match occurs, the skimmer then serializes the$_POST
and $_COOKIE
data and writes it to a JPG file in the NFS directory of the web server. The attacker intermittently retrieves the JPG file from the web server as data is collected.
Detection and Prevention Measures
This section provides an overview of techniques to detect and prevent attacks against your eCommerce application.Audit Magento Third-Party Extensions and Plugins
CrowdStrike recommends auditing your Magento installation to determine if your deployment contains any aforementioned plugins targeted by Magecart threat actors. If identified, CrowdStrike recommends removing the plugin, or blocking requests to these resources by editing .htaccess, utilizing Apache mod_rewrite or similar, depending on the web infrastructure in use. A forensic investigation should be conducted to determine if threat actors successfully targeted these resources. Additionally, unnecessary plugins and extensions should be removed to minimize the eCommerce application’s attack surface.Database Logging in Magento Enterprise
In some investigations, CrowdStrike was able to identify previous attacker activity by analyzing a table in the Magento database that logs all changes made to it. Theenterprise_logging_event_changes
table, available in enterprise versions of Magento only, records changes to the Magento database. This can be extremely useful to forensic investigators if any reverting occurred or modifications were made to the database since the initial attack. Figure 14 below shows an example entry in the enterprise_logging_event_change
table, where a URL to a malicious JavaScript file was added to the absolute_footer
field.
Web Log Analysis and Monitoring
eCommerce environments should actively monitor and analyze web access logs for unauthorized or suspicious activity, specifically for the presence of SQL Injection methods, and the placement and interaction with web shells. eCommerce environments should also monitor authentications to the back-end eCommerce application database to ensure only authorized accounts from expected source IP addresses are occurring.Perform Regular Penetration Tests
eCommerce environments should perform web application penetration testing on at least a biannual basis to ensure their eCommerce web application is patched and secure. The testing should be conducted by a third party with the goals of identifying any unpatched vulnerabilities on the web application and/or the system running the web application, as well as trying to access the eCommerce web server and/or the database.Implement Code Integrity Checks
eCommerce environments should consider implementing code integrity verification checks and processes for their eCommerce applications. These checks would detect the “Overwriting a Core JavaScript Library” example mentioned above. For instance, an eCommerce administrator can calculate a SHA256 hash of core JavaScript libraries employed by the eCommerce application and ensure the hash of these libraries only changes during expected maintenance periods.Regular Updates and Patching
eCommerce environments should minimize the attack footprint by regularly patching the core eCommerce platform and pertinent application dependencies, such as Apache and PHP. Administrators should also audit and remove unnecessary eCommerce application plugins and extensions.Implement a Web Application Firewall
Deploying and configuring a Web Application Firewall (WAF) will mitigate the probability of a successful attack. WAFs should be configured to block and generate alerts on potential code injection attacks, such as PHP Object Injection or SQL Injection. Generated alerts should be regularly reviewed by security personnel to ensure the attacks were successfully prevented.Implement Advanced Endpoint Protection
Deploying an advanced endpoint protection program, such as the CrowdStrike® CrowdStrike Falcon® platform, will mitigate the risk of a successful attack. Falcon utilizes an array of powerful methods to provide protection against rapidly changing TTPs used by various adversaries. Falcon Prevent™ next-gen antivirus is capable of detecting and preventing the execution of exploits and web shells that are often used in attacks against eCommerce applications.Conclusion
Magecart threat actors continue to target payment web applications in an attempt to steal credit card information. Despite the absence of known high-severity vulnerabilities in the core Magento eCommerce product since 2016, attackers have successfully gained access by targeting common third-party Magento plugins. They have also used these same techniques on other eCommerce applications such as PinnacleCart. CrowdStrike analysts expect this attack trend to continue, and they advise eCommerce administrators to review the previously mentioned detection and prevention measures to minimize the likelihood of the attackers successfully exploiting and exfiltrating payment card information.Footnotes
- This file may vary depending on Magento version
Additional Resources
- Learn how CrowdStrike can help your organization answer its most important security questions: Visit the CrowdStrike Services web page.
- Download the 2018 CrowdStrike Services Cyber Intrusion Casebook and read up on real-world incident response (IR) investigations, with details on attacks and recommendations that can help your organization be better prepared.
- Watch an on-demand webcast on the Cyber Intrusion Casebook: Stories From the Front Lines of Cybersecurity in 2018 and Insights That Matter for 2019.
- Learn more about CrowdStrike’s next-gen endpoint protection by visiting the Falcon platform product page.