Protect your organization in the age of Magecart

The continuing wave of attacks by cybercriminal groups known under the umbrella term Magecart perfectly illustrates just how unprepared many e-commerce operations are from a security point of view. It all really boils down to timing. If the e-commerce world was able to detect such Magecart attacks in a matter of seconds (rather than weeks or months), then we could see an end to Magecart stealing all of the cybercrime headlines.

Magecart security

What steps can organizations take then to mitigate against this method of cyber attack? Let’s delve deeper.

Assess your degree of client-side visibility

To avoid the hindsight is 20/20 syndrome, a key first step is understanding how aware you are of what your users are actually getting when they visit your e-commerce platform. You may think that every user will get an identical, safe-to-use version of your website when, in fact, some users may be interacting with compromised web pages and hijacked forms.

It might surprise you to learn that neither business owners or security teams seem to have a definite answer here.

For far too long now, there has been a spotlight on server-side security. Consequently, just about everything that happens on the client-side (for example the browser and the environment where Magecart attacks thrive) is generally overlooked. Based on the information we have gleaned from previous Magecart attacks, it is obvious that there is no sure-fire way of preventing these types of attacks completely. However, a good place to start is to shift our focus and prioritize what is happening on the client-side.

The average Magecart attack remains undetected for 22 days and it only took 15 days for attackers to steal 380,000 credit cards during the British Airways breach. That’s 18 credit cards per minute. This is how you should look at this threat: each minute that goes by while there’s an undetected skimmer on your website means a growing critical business problem.

Third parties are your weakest link

Various Magecart groups use different strategies to breach e-commerce websites. However, most go after the weakest security link: they avoid breaching your servers and prefer delivering malicious code to your website through third parties.

Nearly all websites use one or more third-party solutions: a live chat widget, an analytics tool, or an accessibility service. By doing so, companies end up having almost no control over the security of this externally sourced code. When attackers breach one of these third parties and inject malicious code, this code very easily bypasses firewalls and browser security mechanisms because the attack originates from a source that is trusted by default – in this case, a legitimate third-party supplier.

It’s crucial that you make sure that your business is scrutinizing third-party code and also its supplier’s level of security. Sadly, though, this is not something companies prioritize, as they are concentrated on product development.

And while many businesses are only just now learning about Magecart web skimmers, these skimmers are far from being the first iteration. Over time, skimmers have evolved to include obfuscation techniques to conceal their malicious code and even go as far as using defense mechanisms to avoid being detected by bots, rendering many detection options useless.

Taking decisive action to detect and control Magecart web skimmers

An ever-evolving security mindset is needed here. Businesses should find ways to quickly detect these injected skimmers and swiftly block Magecart attacks. This is preferable to solutions that prevent malicious (unpreventable) code injections.

Whilst third-party management and validation play a good part, they alone are not enough. The key is to look for malicious behavior.

We know that a skimmer always displays at least one sign of malicious activity. For example, a known script like a live chat has no business interacting with a payment form (formjacking). If that happens, it’s an indicator that something may be wrong. Also, if we start seeing a new script appearing in some user sessions, that is also something that warrants further analysis. Sure, it could be harmless – but it could also be a skimmer. Similarly, a network request to a previously unknown domain may be an indication that attackers are trying to exfiltrate data to their drop servers.

It is precisely here where most businesses are deficient. Not only do companies lack client-side visibility, but they also lack proper detection and control capabilities. Taking decisive action against web skimming means being able to detect and control any malicious activity on the client-side in real-time. To this extent, consider a web page monitoring solution, as it brings real-time visibility of malicious code and provides a more effective Magecart mitigation approach.

Most global brands fail to implement security controls to prevent data leakage and theft

The global pandemic has seen the web take center stage. Banking, retail and other industries have seen large spikes in web traffic, and this trend is expected to become permanent.

global brands security controls

Global brands fail to implement security controls

As attackers ramp up efforts to exploit this crisis, a slew of high-profile attacks on global brands and record-breaking fines for GDPR breaches have had little impact on client-side security and data protection deployments.

There’s a troubling lack of security controls required to prevent data theft and loss through client-side attacks like Magecart, formjacking, cross-site scripting, and credit card skimming. These attacks exploit vulnerable JavaScript integrations running on 99% of the world’s top websites, Tala Security reveals.

The report indicates that security effectiveness against JavaScript vulnerabilities is declining, despite high-profile attacks and repeated industry warnings over the past 18 months, including the largest GDPR fine to date.

Without controls, every piece of code running on websites – from every vendor included in the site owner’s website supply chain – can modify, steal or leak information via client-side attacks enabled by JavaScript.

In many cases, this data leakage is taking place via whitelisted, legitimate applications, without the website owner’s knowledge. What this report indicates is that data risk is everywhere and effective controls are rarely applied.

Key findings highlight the scale of vulnerability and that the majority of global brands fail to deploy adequate security controls to guard against client-side attacks.

JavaScript risk has increased in 2020

The average website includes content from 32 third-party JavaScript vendors, up slightly from 2019. JavaScript powers richness but also the framework of what renders on customer browsers, including images, style sheets, fonts, media and content from 1st party source- the site owner.

Content delivered by third-party JavaScript integrations

58% of the content that displays on customer browsers is delivered by third-party JavaScript integrations identified above.

This website supply chain leverages client-side connections that operate outside the span of effective control in 98% of sampled websites. The client-side is a primary attack vector for website attacks today.

Websites expose data to an average of 17 domains

Despite increasing numbers of high-profile breaches, forms, found on 92% of websites expose data to an average of 17 domains. This is PII, credentials, card transactions, and medical records.

While most users would reasonably expect this data to be accessible to the website owner’s servers and perhaps a payment clearing house, the analysis shows that this data is exposed to nearly 10X more domains than intended.

Nearly one-third of websites studied expose data to more than 20 domains. This provides some insight into how and why attacks like Magecart, formjacking and card skimming continue largely unabated.

No attack is more widespread than XSS

While other client-side attacks such as Magecart capture most of the headlines, no attack is more widespread than Cross-Site Scripting (XSS). This study found that 97% of websites are using dangerous JavaScript functions that could serve as injection points to initiate a DOM XSS attack.

Standards-based security controls exist that can prevent these attacks. They are infrequently applied.

Unfortunately, despite high-profile risks and the availability of controls, there has been no significant increase in the adoption of security capable of preventing client-side attacks:

  • Over 99% of websites are at risk from trusted, whitelisted domains like Google Analytics. These can be leveraged to exfiltrate data, underscoring the need for continuous PII leakage monitoring and prevention. This has significant implications for data privacy, and by extension, GDPR and CCPA.
  • 30% of the websites analyzed had implemented security policies – an encouraging 10% increase over 2019. However…
  • Only 1.1% of websites were found to have effective security in place – an 11% decline from 2019. It indicates that while deployment volume went up, effectiveness declined more steeply. The attackers have the upper hand largely because we are not playing effective defense.

Magecart Group 8 skimmed card info from 570+ online shops

Your payment card information got stolen but you don’t know how, when and where? Maybe you shopped on one of the 570 webshops compromised by the Keeper Magecart group (aka Magecart Group 8) since April 1, 2017.

Magecart Group 8

Magecart Group 8’s modus operandi and targets

The list of the online shops hit by the criminals has been released by researchers from Gemini Advisory, who managed to compile it after gaining access to the group’s dedicated attack server that hosts both the malicious payload and the exfiltrated data stolen from victim sites.

“Analysis revealed that the Keeper group includes an interconnected network of 64 attacker domains used to deliver malicious JS payloads and 73 exfiltration domains used to receive stolen payment cards data from victim domains.

Their research also revealed that:

  • Over 85% of the victim sites operated on the Magento CMS, 5% WordPress, and 4% Sophify
  • The group tried to disguise its malicious attacker domains as legitimate services (e.g., the attacker domain closetlondon[.]org attempted to imitate and tried to imitate popular website plugins and payment gateways
  • The group occasionally used public and custom obfuscation methods to make the injected information-stealing JavaScript less noticeable and detectable
  • The majority of victim e-commerce sites was hosted in the U.S., followed by the U.K., the Netherlands, France, India, etc.

“The 570 victim e-commerce sites were made up of small to medium-sized merchants and were scattered across 55 different countries,” the researchers shared.

“Victims with the top Alexa Global Ranking received anywhere from 500,000 to over one million visitors each month and were responsible for selling electronics, clothing, jewelry, custom promotional products, and liquor.”

The attackers likely targeted small and medium-sized retailers because they are less likely to have a dedicated IT security team, to implement CMS and plugin patches promptly, and to have security measures in place and attack detection capabilities.

The profitability of Magecart attacks

The researchers estimated that the group may have generated over $7 million USD from selling compromised payment cards between 2017 and today.

“With revenue likely exceeding $7 million and increased cybercriminal interest in CNP [Card Not Present] data during the COVID-19 quarantine measures across the world, this group’s market niche appears to be secure and profitable,” they noted, and said that they expect the group to continue launching increasingly sophisticated attacks against online merchants across the world.

It is unknown if the group is state-sponsored or not. While we may think of Magecart groups as “mere” cyber criminals, Sansec researchers recently tied one of them to a North Korean APT group.

For the end users – i.e., the online shoppers – it’s all the same and, unfortunately, there is little they can do to protect themselves against the threat of getting their payment card info skimmed.

Avoiding smaller sites/shops might be a good idea, and so is using browser plugins that prevent JavaScript loading from untrusted sites, but there is no 100% guarantee.

Magento 1 reaches EOL: Merchants urged to upgrade or risk breaches, falling out of PCI DSS compliance

When Adobe released security updates for Magento last week, it warned that the Magento 1.x branch is reaching end-of-life (EOL) and support (EOS) on June 30, 2020, and that those were the final security patches available for Magento Commerce 1.14 and Magento Open Source 1.

Magento 1 EOL

Unfortunately, there are still too many (over 100,000) active Magento 1.x installations. The company is urging their owners and admins to migrate to Magento 2.x or risk being hit once another critical and easily exploited vulnerability is unearthed and its existence made public.

About Magento

Magento is a very popular open-source e-commerce platform that powers many online shops, a fact that hasn’t gone unnoticed by cyber criminals.

Nearly four years ago (and possibly even earlier), cyber crooks started concentrating on breaching Magento-based shops and injecting them with scripts that quietly grabbed users’ personal and payment card data information and sent it to a server they controlled.

Since then, the tactic has been used and continues to be used by many cyber criminal groups, which have been classified by security companies as “Magecart” attackers. As they are quick to exploit newfound vulnerabilities in the Magento core and third-party extensions, hardly a day passes without news about another online shop having been compromised.

If you decide to stick with Magento 1

“If you have a store that continues to run on Magento 1 after June 30, please be aware that from that date forward you have increased responsibility for maintaining your site’s security and PCI DSS compliance,” Adobe warned.

Merchants that continue to use an unsupported Magento 1 version will have to implement compensating controls to re-certify PCI DSS compliance, such as signing up for and implementing third-party fixes and updates, continuously scanning their installations for malware, vulnerabilities and unauthorized accounts, using a web application firewall, and so on.

“General security vulnerabilities tend to increase the longer software is unsupported as hackers continue to use new technologies and techniques for exploitation. This raises the risk of attacks and security breaches over time and increases the possibility of exposing personally-identifiable customer data,” Adobe explained.

Companies risk their reputation, the trust of their customers, fines and may even lose their credit card processing ability if they fail to protect user information.

Another thing: the end of support for Magento 1 also means that some extensions merchants use will not be available anymore.

“We encourage Magento 1 merchants to download the Magento 1 extensions they plan to keep, since Magento 1 extensions will not be available in the Magento Marketplace after July 7, 2020, and will be removed from the Magento repository after August 6, 2020,” Adobe noted last week.

Magento 2 or something else?

PayPal, Visa and other payment processing companies and payment platforms have also been urging merchants to make the switch to Magento 2.
Even though Magento 2 was released five years ago and even though the migration from Magento 1 to Magento 2 can be performed by using an official Data Migration Tool the number of Magento 2 installations is still lagging (it’s currently around 37,500 installations).

As “painful” and costly as it maybe, this EOL will hopefully push many of them to finally make the switch – or make the switch to an alternative platform.

“2020 has been a tumultuous year for retailers. Merchants should not have to worry about security issues or upgrading their ecommerce platform while they are in the middle of adapting to drastically changed consumer behaviors and expectations. Amidst the list of business-critical priorities a merchant needs to focus on, worrying about what’s happening with a Magento migration or installation should not be included,” noted Jimmy Duvall, Chief Product Officer at BigCommerce.

Magecart attackers hit Claire’s, Intersport web shops

Magecart attackers have compromised web shops belonging to large retail chains Claire’s and Intersport and equipped them with payment card skimmers.

Magecart Claire's Intersport


The compromise of Claire’s online store and that of its sister brand Icing has been flagged by Sansec researchers.

The skimmer was served from a domain made to look like it might belong to the company (, and it was added to the two online stores between April 25th and 30th.

“The malware was added to the (otherwise legitimate) app.min.js file. This file is hosted on the store servers, so there is no “Supply Chain Attack” involved, and attackers have actually gained write access to the store code,” the researchers pointed out.

“The skimmer attaches to the submit button of the checkout form. Upon clicking, the full ‘Demandware Checkout Form’ is grabbed, serialized and base64 encoded. A temporary image is added to the DOM with the __preloader identifier. The image is located on the server as controlled by the attacker. Because all of the customer submitted data is appended to the image address, the attacker now has received the full payload. Immediately, the image element is removed.”

How the attackers managed to compromise the web shops is still unknown, but they started planning the attack a month before actually executing it. In fact, they registered the malicious domain a day after Claire’s announced that they will be temporarily close all of their brick and mortar stores due to COVID-19.


ESET researchers have pointed out the compromise of Intersport’s web store and said that the company fixed the issue within several hours of ESET letting them know.

Sansec researchers say that an initial hack happened on Apr 30th and then another one on May 14th:

Only the localized Intersport web shops serving customers from the Balkans region have been compromised.

What now?

It is still unknown how long the skimmers went unnoticed.

None of the compromised web shops sport a prominent notification about the breach and payment card info theft. Claire’s notified the payment card networks and law enforcement, and let’s hope they will contact affected customers directly once they determine the extent of the compromise and theft.

Companies should have protections in place to notice this and other types of breaches soon after they happen, but unfortunately many don’t.

If you’re paying for your purchases with payment cards – whether online or in physical stores – you should regularly check your account statements for unauthorized charges and report them quickly.

Debunking myths related to client-side security and Magecart attacks

The client-side landscape has been overrun by third-party script attacks executed by malicious attackers utilizing formjacking or other methods made famous by the Magecart attack group.

Magecart attacks

Many companies assume their current security stack ensures protection for these seemingly basic attacks, but in reality, they open a can of worms and you may not even know you’ve been attacked. Take a read below to see some of the common misconceptions regarding client-side protection, these dedicated threats and if your business is in fact safe.

Myth #1 – I don’t need to worry about client-side security unless I have a virtual shopping cart/eCommerce

While formjacking is heavily concentrated in online retail, there is a significant weakness in other pertinent verticals as only a few lines of code can interrupt any organization that collects personal information on a website.

Attackers also utilize malicious JavaScript injections running almost seamlessly with your third-party vendor scripts that a website utilizes to improve performance or experience. These are all areas of potential vulnerabilities and if not monitored, can prove costly.

Myth #2 – I have a firewall, WAF and a secure connection so I’m safe from these attacks

Firewall, WAF, secure connection and many other solutions are focused on securing internal servers and the communication between the browser and these internal servers. Formjacking and Magecart attacks are executed on the user’s browser and in many cases, load from a remote server. This client-side connection operates completely outside of the security capabilities an organization deploys to secure the server side of the browser session.

Myth #3 – RASP or DASP catches formjacking and Magecart-type attacks

Dynamic Application Security Testing (DAST) is usually active on a pre-production environment and does not cover live sites. The few who run DAST on a live site will simulate a few user profiles but cannot possibly scale this solution to monitor and detect all web sessions.

As third parties change their behavior from user to user, DAST is largely ineffective in detecting attacks on large production networks and completely ineffective at preventing these types of attacks. Detection methodologies do not help organizations fulfill compliance guidelines requiring customer data privacy.

RASP is Runtime Application Self-Protection; it exists only on the Java virtual machine and .NET Common Language Runtime. Since it will not run on the actual live site, third parties are outside of its detection scope. Again, RASP is not intended as a prevention solution. Detection methodologies do not help organizations fulfill compliance guidelines requiring customer data privacy.

Myth #4 – CSP and other page headers will stop Magecart attacks

CSP is often being suggested as the solution for Magecart attacks. Although it can be part of the solution, by now we know that a lot of the Magecart attacks are being done from trusted domains. Take for example the 24/7 chat hack that captured payment card information from huge enterprises websites such as Delta Airlines, Sears, Kmart, and BestBuy. This tool was trusted by those firms and needs to be whitelisted by the CSP in order to work.

Other headers such as HSTS are sometimes also mentioned as a possible solution but all of us understand that by now attackers are sophisticated enough to use SSL (https) when loading their payload to avoid this header as well.

Myth #5 – Magecart hackers need to use a “drop server” to capture the data

In most of the known Magecart attacks, the payload is being delivered by a trusted domain (for example a third party vendor) and the data it collects is being sent to the hacker server, also called “drop server”. In some of the attacks we are seeing the hackers are using domain names that look legit to avoid detection, for example, the drop server in the British Airways attack was under the domain “”.

But the more sophisticated hackers will avoid using a drop server altogether and create an account in one the third parties the website use in order to capture the information in an undetectable way.

Magecart attacks

Using Google Analytics to capture user credentials

Myth #6 – You can detect all Magecart attacks from the outside without implementing code to your website

Using a tool to scan the website from the outside in order to capture those attacks is a VERY low barrier that can be overcome by simply using one of the most common methods almost all third-party vendors use. By nature, third party code is dynamic and can adjust to run only for specific users – for example, when you go to a website, you will see an advertisement that is related to your browsing history, and some else will see completely different advertisements according to his history.

Hackers are using those same methods to avoid detection so the hack payload will be applied to real users and not shown to an outside scanner, sometimes limiting the hack to be sent only to a small percentage of the site visitors to avoid detection by humans. In order to detect Magecart, you need real-time all the time protection.

Myth #7 – If I am being attacked right now my team would definitely be aware of it

As proven by the Magecart attack that affected over 800 websites for 3 years, many dedicated attacks are very hard to detect. If you Google “undetected Magecart attacks” the search will return a number of recent threats that top Fortune 100 companies unfortunately experienced. While security teams are trained in responding to DDoS and bot attacks, these vectors are new and evolving establishing additional operational costs in dedicated man hours and more than likely a third-party solution alternative.

Myth #8 – Third-party risks are the top concern your company should be worried about

While third-party risks present the largest issues at hand, you can’t diminish fourth- and fifth- party risks that come as extensions of third parties.

Even the most security-driven websites, who audit and test the vulnerabilities of the third-party scripts they interact with (which is in itself rare and difficult to follow through), still remain exposed through the fourth- and fifth- party scripts these suppliers interact with. This makes the process of fully protecting websites and their users from attack scripts much more challenging.

How a favicon delivered a web credit card skimmer to victims

Cyber crooks deploying web credit card skimmers on compromised Magento websites have a new trick up their sleeve: favicons that “turn” malicious when victims visit a checkout page.

Favicons and card skimmers

Favicons is a file containing one or more small icons associated with a website and are usually displayed in the browser’s address bar, on the tab in which a website has been opened, and in the bookmarks.

favicons card skimmers

“The goal [with online credit card skimmers is] to deceive online shoppers while staying under the radar from website administrators and security scanners,” Malwarebytes researcher Jérôme Segura explained.

In this latest approach, the crooks registered a new website purporting to offer thousands of images, icons and favicons for download (myicons[.]net) and made it an exact copy of the legitimate site by loading it as an iframe.

Several e-commerce sites were loading a Magento favicon from this domain, Segura noted, but at first glance, the favicon image was clean.

Further analysis showed that, instead of the favicon, the malicious site returned JavaScript code that consists of a credit card payment form – but only when a user visited a checkout page.

favicons card skimmers

The script would override the PayPal checkout option with its own drop down menu for MasterCard, Visa, Discover and American Express. The entered information would be exfiltrated to a remote server controlled by the crooks.

The new trick is part of ongoing attacks

“Given the decoy icons domain registration date, this particular scheme is about a week old but is part of a larger number of ongoing skimming attacks,” the researcher noted.

In fact, the IP of the server on which the malicious icon was hosted was flagged as part of an attack infrastructure nearly a month ago by Sucuri researchers, who tied it to a gang “known for using quite a few interesting tricks in their skimmers.”

It’s difficult for consumers to spot this type of attack and endpoint security solutions may or may not detect it. It’s on site owners to keep their websites secure and to quickly spot malicious changes.

Client-side web security

To address attacks such as XSS, Magecart and other card skimming exploits found in modern eCommerce environments, the use of client-side web security methods is beginning to emerge as a particularly useful practice.

client-side web security

Obviously, enterprise teams should integrate client-side protections with desired server-side countermeasures to ensure a full risk management profile (e.g., the client-side is a poor selection point to stop denial of service).

Several standards-based client-side security approaches have begun to mature that are worth examining from the perspective of website security and protection of browser sessions from malicious exploits. The best client-side security platforms automate implementation of these standards-based controls with emphasis on simplicity of administration. A typical, representative platform is used to demonstrate necessary client-side security controls.

Content security policy

To understand client-side security platforms, it helps to first explore the specifics of a standard approach known as a content security policy (CSP). This is a standard that is designed to address several types of web breaches such as cross-site scripting, click-jacking and form-jacking (all described earlier in this article series). CSP is also designed to reduce the risk of client-side malware injected from an infected advertising ecosystem.

CSPs are implemented as standard directives involving HTTP headers or page tags that specify which domains, subdomains, and resources a browser can load from a website. CSP use is consistent with the browsers any user would likely use including Chrome, Firefox, Safari, and Edge. The goal is that if malicious code is resident on a site, then visitors to that site would be prevented by the CSP from being directed to the hacker’s domain.

client-side web security

Figure 1. Content security policy

The example shown above in Figure 1 is taken directly from the original W3 recommendation. The CSP code can be interpreted as follows: Each source expression represents the location where content of the type specified is allowed to be pulled. To illustrate this whitelist security operation, consider that the self keyword-source designation, in the example above, represents the set of URIs in the origin as the protected website.

Companies like Google have rolled out CSP successfully and are using it to stop attacks against their web applications daily. However, CSP is deployed only lightly in most web application environments. The challenge with CSP implementation has been its complex administration. Tala Security researchers have found, for example, that roughly two percent of website operators in the top Alexa 1000 websites deploy the standard to prevent client-side attacks. Assisting with this administrative challenge is a primary motivation for client-side platforms.

Client-side security protection results from using CSP can websites can be quite impressive. Here are some observed statistics from the Tala Security research team based on their experiences with client-side security support:

  • Images – The average website in the Alexa 1000 loads images from roughly sixteen different external domains. The img-src directive in CSP blocks images from any unwanted or potentially malicious sites.
  • Stylesheets – The average website in the Alexa 1000 loads stylesheets from roughly two different external domains. The style-src directive in CSP blocks stylesheet loads from any unwanted or potentially malicious sites.
  • Fonts – The average website in the Alexa 1000 loads images from roughly one-and-a-half different external domains. The font-src directive in CSP blocks font downloads from any unwanted or potentially malicious sites.
  • Media – The average website in the Alexa 1000 loads images from different external domains. The media-src directive in CSP blocks font downloads from any unwanted or potentially malicious sites.

Subresource integrity

An additional applicable cyber security standard from the World Wide Web Consortium (W3C) is known as subresource integrity (SRI). This standard is designed to validate resources being served up by any third party on a visited website. Such third parties include content distribution networks (CDNs), where it has not been uncommon to find malicious code being offered up to unsuspecting websites.

SRI is implemented through cryptographic hash functions which finger-print JavaScript being offered by third parties. Browsers can then fetch a resource, check the cryptographic hash value – which include the location of the resource, and then make a policy decision about whether to accept the resource. This capability is supported in all important browsers, and significantly reduces the risk of malware from third party actors.

Client-side security platform

Client-side security platforms will make use of both CSP and SRI to provide effective client-side protections. The goal of these platform is to provide policy-based mitigation of fine-grained behavior for third-party sources where content is being served. Client-side platforms can then watch for any data collection suggestive of the attacks used by Magecart (and similar groups).

The client browser mitigation should be implemented based on artificial intelligence-based classification and learning. The software should install quickly and easily. Commercial platforms should support implementation for many target environments including Apache Nginx, IIS, NodeJS, and others. Performance and latency impacts should also be essentially non-existent and non-affecting of the user experience. Specific capabilities included in a commercial platform should include:

  • Indicator evaluation – The selected platform should be designed to evaluate many different indicators of a web page’s architecture to analyze code, content, connections, and data exchange.
  • Behavioral and risk modeling – The platform should include support for analysis to inform a behavioral and risk modeling task designed to highlight normal behavior and expose vulnerabilities.
  • Operational improvement – Insights gained from the platform evaluation and modeling should be made available to help prevent client-side attacks such as XSS, Magecart, and the like.

The operation of world-class client side security platforms should include an on-going interaction between four different activities: Build, Monitor, Block, and Respond. The connection flow between these different lifecycle phases is depicted below.

client-side web security

Figure 2. Commercial client-side security lifecycle

Information model

Client-side security platforms should implement some type of information model that can be used to analyze the different behaviors on pages from the customer’s website to be protected. The security objective for such extraction should be to explicitly identify any sources of code and content on these web pages, as well as to find any data exchange support options that could involve sensitive data.

The resultant behavioral information model will thus provide a functional baseline on which to perform the necessary client-side risk management. The goal obviously should be to determine in real-time whether the site is vulnerable to attacks, third-party insertion, or other advanced breaches. As one would expect, performance of such behavioral modeling and protection in real-time complements any existing server-side security tools.

Contributing author: Aanand Krishnan, CEO, Tala Security.

Mac threats are growing faster than their Windows counterparts

Mac threats growing faster than their Windows counterparts for the first time ever, with nearly twice as many Mac threats detected per endpoint as Windows threats, according to Malwarebytes.

mac threats growing

In addition, cybercriminals continue to focus on business targets with a diversification of threat types and attack strategies in 2019.

Emotet and TrickBot were back in 2019

Trojan-turned-botnets Emotet and TrickBot made a return in 2019 to target organizations alongside new ransomware families, such as Ryuk, Sodinokibi and Phobos.

In addition, a wave of new hack tools and registry key disablers made a splashy debut, reflecting greater sophistication used by today’s business-focused attackers.

Threat actors are becoming more creative

Adware was particularly problematic for consumers and businesses on Windows, Mac and Android devices, deploying aggressive techniques for serving up advertisements, hijacking browsers, redirecting web traffic and proving extremely difficult to uninstall.

“A rise in pre-installed malware, adware and multi-vector attacks signals that threat actors are becoming more creative and increasingly persistent with their campaigns,” said Marcin Kleczynski, CEO of Malwarebytes.

“It is imperative that, as an industry, we continue to raise the bar in defending against these sophisticated attacks, actively protecting both users and businesses by flagging and blocking all programs that may violate their privacy, infect their devices, or even turn the infrastructure they depend on against them.”

Mac threats are growing, other threats in the spotlight

Mac threats significantly ramp up – An average of 11 threats per Mac endpoint were detected in 2019—nearly double the average of 5.8 threats per endpoint on Windows. Overall Mac threats increased by more than 400 percent, year-over-year.

Business detections continued to rise – In 2019, global business threats rose 13 percent to about 9.6 million detections.

HackTools triumph – With consumer detections of HackTools up 42 percent, this is a threat to watch in 2020, bolstered by families such as MimiKatz, which also targeted businesses.

Dynamic duo does damage – TrickBot and Emotet once again reigned globally, targeting businesses heavily in the last year. Emotet was second-most detected threat against businesses in 2019.

mac threats growing

Meanwhile, TrickBot saw enormous growth, with business detections on-the-rise by 52 percent, year-over-year.

Ransomware is rampantRansomware targeted cities, schools and healthcare organizations with increased vigor in 2019. Newer ransomware families saw the highest growth, with Ryuk business detections up by 543 percent, year-over-year, and Sodinokibi increasing by 820 percent since its introduction in May 2019.

Beware of adware – Adware increased 13 percent, year-over-year, for consumers and 463 percent for businesses. Seven of the 10 top consumer threat families were adware variants, as well as five of the top 10 business threat families.

Pre-installed malware became pervasive – Top-rated mobile threat in 2019 was a team of pre-installed potentially unwanted program (PUP) variants that combined for 321,103 detections.

These auto installers ship with Android devices and are used to update the phone’s firmware—but they also take and sell personal information.

Just keep skimming – Credit card skimmers, or Magecart, were one of the most prevalent web threats in 2019. Magecart activity will continue in 2020 with more e-commerce platforms targeted.

Key targets shift – The services sector leapfrogged over education and retail, snagging the top spot for industries impacted by threats in 2019. Notably this includes managed service providers (MSPs), which are being leveraged to take advantage of their network of clients.

Macy’s online store compromised in Magecart-style attack

The webshop of noted U.S. department store company Macy’s has been compromised and equipped with an information-stealing JavaScript, which ended up collecting users’ personal and payment card information for a week. What is known about the breach According to the notice sent by Macy’s to affected customers, the breach was discovered on October 15, 2019, after they were alerted to a suspicious connection between and another website. “Based on our investigation, we believe that … More

The post Macy’s online store compromised in Magecart-style attack appeared first on Help Net Security.