Sergey Nivens - stock.adobe.com
Poorly-secured AWS buckets used to launch Magecart attacks
Cyber criminals are exploiting misconfigured AWS S3 buckets to run credit card fraud and malvertising campaigns, according to new data
Cyber criminals launching Magecart credit card-skimming attacks continue to take advantage of lax attitudes to securing Amazon Web Services Simple Storage Service (AWS S3) to inveigle their way into their targets’ infrastructure, according to new research from RiskIQ.
Through no fault of AWS’s – S3 buckets are secured by default, so when they leak, it is down to error on the owner’s part – the popular object storage service can easily be exploited to get access to websites and inject malicious code into them.
Vulnerable AWS S3 buckets can easily be found by scanning for them – legitimate security professionals often do this in order to warn their owners – but obviously cyber criminals are aware of this too. Back in July 2019, RiskIQ reported that a Magecart campaign was leveraging misconfigured S3 buckets to insert JavaScript credit card skimmers on hundreds of websites.
In May 2020, RiskIQ found more Magecart skimming code on three websites belonging to Endeavor Business Media, a US-based B2B publisher of multiple titles, including several dedicated to security professionals.
The firm said its approaches to the publisher had been ignored, and it was therefore working with third parties to sinkhole the malicious domains, which we are not linking to here for your protection.
RiskIQ found one of the websites was also hosting a malicious redirector, “jqueryapi1oad”, which connects to the Hookads malvertising campaign, historically linked to a number of exploit kits and other malicious behaviour. This particular redirector first surfaced in April 2019 and has been connected to more than 270 hosts to date, including Futbolred.com, a South American soccer news website with a top 30,000 Alexa ranking.
“Misconfigured S3 buckets that allow malicious actors to insert their code into numerous websites is an ongoing issue,” said RiskIQ’s Jordan Herman in a disclosure blog. “Here, we have identified three sites belonging to the same company that currently host instances of Magecart.
“One of these is also hosting jqueryapi1oad, a malicious redirector we connect to the Hookads campaign, which has been historically associated with exploit kits and other malicious behaviour.
“As attacks involving misconfigured S3 buckets continue, knowing where your organisation is using them across its digital attack surface is imperative. In today’s threat environment, businesses cannot move forward safely without having a digital footprint, an inventory of all digital assets, to ensure they are under the management of your security team and properly configured.”
Read more about Magecart
- RiskIQ researchers have observed a sharp uptick in Magecart credit card attacks, driven by increased traffic to online retailers during the coronavirus pandemic.
- Three alleged cyber criminals suspected of being associated with Magecart were arrested in Indonesia via an Interpol-assisted operation called Operation Night Fury.
- US retailer Macy’s admits some customer data was accessed by unknown actors during a week-long Magecart attack.
RiskIQ acknowledged that finding a compromised S3 bucket was inevitably a painful and potentially embarrassing moment for an organisation, but stressed that it was vital to take action to assess the scope of the incident immediately, rather than trying to wish the problem away.
On finding a leaky bucket, security teams should establish what happened, how, and the immediate impact, such as whether or not files were accessed, removed or modified, whether or not any processes deteriorated, or any public content was affected.
“Some compromises might only result in external damage, such as to the brand, or no damage at all, but it is still essential for the security team to get answers,” said Herman. “Groups like Magecart are always on the prowl and will be back to compromise you again if you don't fix your exposures. Next time, the damage could be catastrophic.”
To mitigate, RiskIQ recommends cleaning out the bucket and performing a new deployment of resources, or simply setting up a new bucket altogether. It is also possible to enable versioning on S3 buckets to roll back objects to the last known safe version.
By this point, hopefully, lessons will have been learned. Going forward, security teams should: check the data classification, and whether it can be public or not; restrict write permissions; only provide such permissions to specified users or hosts, and review whether they still need access from time to time; take a whitelist approach to the previous items; and enable account-level blocks.
More information on this threat, along with indicators of compromise, can be found at RiskIQ’s website.
