Your organization’s leadership is 12 times more likely to be the target of a security incident and nine times more likely to be the target of a data breach than they were last year. Find out how they can be protected.
Read the Datasheet
Gift Cardsharks: The Massive Threat Campaigns Circling Beneath the Surface
Learn about the attack group primarily targeting gift card retailers and the monetization techniques they use.
Get the Report
Threat Hunting Workshop Series
Join one of our security threat hunting workshops to get hands-on experience investigating and remediating threats.
Attend an Upcoming Workshop
Inside Magecart: New RiskIQ & Flashpoint Research Report
Learn about the groups and criminal underworld behind the front-page breaches.
Threat Hunting Guide: 3 Must-Haves for the Effective Modern Threat Hunter
The threat hunting landscape is constantly evolving. Learn the techniques, tactics, and tools needed to become a highly-effective threat hunter.
On May 14th, RiskIQ covered the latest mass compromise of third-party web suppliers by a Magecart group. This initial report focused on seven of these suppliers, the scripts of which were injected with skimmer code, which possibly affected several thousand websites using their services.
However, the actual scale of this campaign and the number of sites affected is much larger than previously reported. The actors behind these compromises have automated the process of compromising websites with skimmers by actively scanning for misconfigured Amazon S3 buckets. These buckets are un-secure because they are misconfigured, which allows anyone with an Amazon Web Services account to read or write content to them.
RiskIQ has been monitoring the compromise of S3 buckets since the beginning of the campaign, which started in early April 2019. We’ve been working with Amazon and affected parties to address Magecart injections and misconfigured S3 buckets as we observe them.
We wrote the following article to raise awareness around the security policies for Amazon S3 as well as web-skimming attacks in general.
These attackers have been active in web skimming for a long time using other techniques, but they started compromising unsecured S3 buckets in early April. According to RiskIQ data, the group has managed to compromise a vast collection of S3 buckets to impact well over 17,000 domains. This list includes websites in the top 2,000 of Alexa rankings as well.
Although the attackers have had lots of success spreading their skimmer code to thousands of websites, they sacrificed targeting in favor of reach. The actors used this technique to cast as wide a net as possible, but many of the compromised scripts do not load on payment pages. If you’ve read our coverage of Magecart in the past, then you know that if the skimming script doesn’t load on a payment page, the actors cannot glean payment data.
However, the ease of compromise that comes from finding public S3 buckets means that even if only a fraction of their skimmer injections returns payment data, it will be worth it; they will have a substantial return on investment.
Perhaps most importantly, the widespread nature of this cyber attack illustrates just how easy it is to compromise a vast quantity of websites at once with scripts stored in misconfigured S3 buckets. Without greater awareness and an increased effort to implement the security controls needed to protect the content stored in these buckets from theft or alteration by malicious attackers, there will be more—and more impactful— cyber attacks using techniques similar to the ones outlined in this blog.
Note: Amazon’s current protections include:
A lot has been written on security and S3 buckets in the past. However, we feel that it’s essential to again put together the most up-to-date and conclusive advice in this article. Additionally, Amazon has written a general guide of items to check on for maintaining a secure S3 bucket setup titled, “How can I secure the files in my Amazon S3 bucket?”.
If a customer alters the default behavior of an S3 bucket and requires public access, setting up proper access control is critical. Access control for S3 buckets comes in different layers and options, from Amazon’s IAM (Identity and Access Management) policies, specific bucket policies, or general access control policies. These various policies can be overlayed and stacked depending on the bucket and how you want to set it up.
The type of access control policies you use will depend on whether you are using your bucket for public content or private content:
We recommend these three crucial steps for access control to any S3 bucket:
A compromised bucket is a painful moment for an organization, but it’s also a pivotal one. Once the compromise comes to light, it is essential to assess the full scope of the incident. While the exact list of questions may differ depending on the type of organization, we recommend first answering these basic questions when performing your investigation:
Some compromises might only result in external damage such as to the brand, or no damage at all, but it’s still essential for the security team to get answers. 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.
Once these questions are answered, the next step is mitigation. The basics of most, if not all, S3 bucket compromises we observe come down to improper access control. We suggest cleaning out the bucket and performing a new deployment of resources or simply setting up a new bucket. Customers can also enable versioning on their buckets to “rollback” objects to a known good version. As for the policies to secure your bucket, we recommend the following approach:
The actors use a skimmer to exfiltrate payment data to their own servers. The following domains can be used to identify successful theft of information. The stolen data is sent in the form of a fake image that is included from the <baddomain>/img URL path.
One thing to keep in mind, this list is always expanding and won’t contain all the IOCs as the attackers keep registering new ones when we get them taken down with the help of AbuseCH & Shadow Server.
RiskIQ is the leader in attack surface management. We help organizations discover, understand, and mitigate exposures across all digital channels.
“(...) RiskIQ has been able to track much more of the bad guy’s infrastructure used in their scam operations. We’ve identified around 400 domains so far that are all tied to these scams.” - @ydklijnsma
WHAT JUST HAPPENED? Security pros offered a range of opinions about the breach. All agreed the fault did not lie with each hacked account's owner. Some say it may have come from inside @Twitter.
@BradyDale and @benjaminopowers report
Targeted #cyberthreats are spiking during #COVID19. We provide one source for information to simplify and accelerate your investigation process #ThreatHunting https://bit.ly/3c9xKoq
RiskIQ researchers just doubled the number of IoCs in the Pastebin. Please continue to monitor it for updates as this situation evolves https://pastebin.com/h64CK3CG #twitterhack #twitterhacks #ThreatIntel #IOCs
Just in case my last tweet got lost in the thread storm, @RiskIQ's list of domains apparently tied to this scam gives us a pretty good idea of who was targeted here. https://pastebin.com/h64CK3CG
This is developing very quickly, but seems to have been staged well in advance. Take a look at some these domains set up to support this scam. H/T @RiskIQ https://twitter.com/ydklijnsma/status/1283508384335925248
Leveraging @RiskIQ's datasets we have identified more infrastructure tied to the current cryptocurrency scammers impacting @elonmusk , @billgates, etc. This is research data, validate before taking action, it might identify new targets also.
At this point we can just assume the entire platform compromised. https://twitter.com/ydklijnsma/status/1283503695796162560
And they've just crossed the cryptocurrency boundary https://twitter.com/ydklijnsma/status/1283501318917611521