Magecart is a malware framework/operation that targets e-commerce websites and aims at collecting credit card information. It is considered a web-based card skimming attack, as the payment gate on a website is used to steal the customers’ credit card details.
Magecart attacks are named after the online shops that are targeted and which are usually running on the Magento ecommerce platform.
How it works
The attack works by injecting malicious code in the checkout page of an online store. This can take place either via a malicious third party plugin or via a compromise of the website.
The code copies the user input, e.g. Credit Card Number, Expiration Date, Card Verification Value (CVV), Name and Address and delivers them to an external location that is controlled by the attackers. In this way, the users are able to proceed with the current transaction without noticing any issues and without getting alerted that their details have been compromised.
The attack is especially dangerous because it hits even the cautious and security aware users that follow best practices – use only trusted devices, use trusted connectivity and check the https connection, and shop only on trusted sites.
From the first moment the threat was identified, Whalebone included the domain in its threat database and protected users that visited the affected websites by blocking only the external connection to the malicious domain, while at the same time allowing the desired user experience.
Additionally, Whalebone’s team was able to take advantage of the power of the available DNS data and identify another compromised website that was part of the same campaign. By tracing the path of previous DNS requests, it was evident that another domain induced the communication with the command and control endpoint. The domain was jeulia[.]com, which at the time of this writing has over 2 million likes on its Facebook page.
As it is evident in the following snippet, the malicious code can be found in the source code of the page during the checkout process.
The incident has been responsibly reported to the website’s administrators.
Update: As a result of this communication, the infection has been cleaned up and further customers’ credit card exposure has been avoided.
Coronavirus is rapidly spreading across the world and leaving a trail of disrupted businesses, daily lives and national and global economies in its wake.
In an oddly prophetic move, in February 2020, Netflix released a new series aptly titled “Pandemic – How to Prevent an Outbreak” in which copious health experts, pointing to the 1917 Spanish flu pandemic that claimed millions of lives, claimed that another pandemic was not a question of “if”, but “when”. Unfortunately for us as a species, that when is now.
Governments and health care professionals across the globe are issuing guidelines and emergency measures in an attempt to stop the deadly spread of the virus. With social distancing a compelling tactic to this end, hundreds of millions of people are being asked to isolate themselves, stay at home and, for non-essential services, work from home. Schools are closed and families around the world are wondering how to pass the time. Turning to the internet for information, work and entertainment is now, more so than ever before, an essential part of everyday life.
Yet, as we have all seen in the early stages of the Coronavirus pandemic, with exposure comes risk. When it comes to the internet, with more people online than ever, more users are exposed, and malicious attackers are finding new ways to exploit the vulnerable and our concerns.
Key word based attacks
As we search the internet for more information about what is going on to assuage our own fears, cyber criminals are ready, willing, and able to exploit our compelling need to know. Due to the pandemic, as Andronikos Kyriakou, a technical consultant at Whalebone points out, “only in the last two weeks, we have seen a 7% daily increase in the number of unique domains that our users communicate with. There are indicators that 4% of these domains are linked with some kind of malicious behavior.” Whalebone statistics show that coronavirus- related domains are 50% more likely to be malicious than other domains registered at the same period.
Fake news and information
According to a recent report by Zack Doffman at Forbes, even Coronavirus maps are being used to plant malware to extract passwords, personal information and credit card details from unsuspecting victims.
“Users do not need to download apps to run risks, malicious websites can also infect computers. And so you should avoid accessing any unknown coronavirus sites or clicking random links under any circumstances. This particular .exe file pretends to come from Johns Hopkins, and mimics the university’s real map,” writes Doffman.
Coronavirus malware map. Source: forbes.com
Closer to home the threats get even more real. Security Week wrote that “On March 13, 2020, it was reported that the Czech Republic’s second-largest hospital, the University Hospital Brno, which has a major COVID-19 research laboratory, was hit by ransomware.” The attack shut down the entire network of the clinic, imperiling the lives of both patients and health care workers and stopping mission critical work.
The site went on to report that “Researchers from Cybereason Nocturnus have been tracking the rise and variety of such attacks, which now include phishing, fake apps and ransomware. Phishing has followed the spread of COVID-19 infections, fake apps are targeting the growing number of home workers, and ransomware is targeting healthcare organizations.”
Even the World Health Organization (WHO) has issued a press release warning internet users to beware of cyber criminals pretending to be the WHO and specifically referencing Coronavirus. Known as phishing, these types of attacks use email to elicit users to provide sensitive information, click on malicious links or open malicious attachments, under the guise of being a reputable source of information.
The fake page not only shows a page that looks like the WHO website, it actually is the WHO’s website embedded in the malicious page, with a simple pop up box over top (see below).
WHO phishing site. Source: Sophos and Whalebone
Here’s another slick and easy to believe example of a phishing email purporting to be an airbnb update.
Airbnb phishing site. Source: Whalebone
How to stay safe
The global scope of the threats, both in the real world and online, illustrate the seriousness of the problem. It’s now more than ever essential to keep your valued users safe and secure. To do so, Whalebone has created a product uniquely suited to provide telco operators and their customers with the security they need. Unobtrusive, providing only a users’ consent at the point of sale or via a call line, residing on the network at the DNS level, offering rapid return on investment and the fastest possible time to market, whalebone is ready and waiting to help you protect your customers in these trying and dangerous times. For more information, visit the Whalebone webpages here or contact a Whalebone consultant today.
Amazon’s Route 53 was subject to a massive Distributed Denial of Service (DDoS)
On October 24, 2019, Amazon informed its customers that Route53 was subject to a Distributed Denial of Service (DDoS) attack and that there was a disruption in the name resolution process. In more detail, the attack affected mainly the naming system of the S3 buckets.
This situation could fall into the category of Slow Drip attacks. In this kind of attacks, a malicious actor continuously sends queries to the authoritative nameservers of the domain that they are targeting. The queries contain mainly non-existing pseudo-random subdomains. A direct result of this flood of queries is that the resources of the victim’s nameservers are depleted and eventually they stop answering even to legitimate requests.
Some indicative queries that were found in the traffic of the recent attack confirm this pattern:
Whalebone identified the attack
In the case of Amazon, Whalebone was successful in timelyidentifying this attack and informing their affected customers.
Some early indication of the upcoming events can be traced back on October 19 when there was a spike in the DNS requests on Amazon’s domains. This could be considered as a testing cycle before the final outbreak.
Get protected with DNSSEC
A possible defence against this kind of attacks could be the introduction of aggressive usage of DNSSEC-validated cached answers. According to this specification, NSEC/NSEC3 resource records could be used to cryptographically prove the inexistence of a domain (or subdomain in this case).
By taking advantage of this, the compatible resolvers that are performing DNSSEC validation can deduce an answer to a query directly by their cache and thus drastically decrease the number of requests to the authoritative servers.
Whalebone’s security-enhanced resolvers are based on Knot resolver’s technology that, since version 2.0.0, supports this approach and guarantees resilience when facing this kind of attacks.
DNSSEC has to be configured properly
Unfortunately, Amazon’s DNS zones are not cryptographically signed (as can be seen below), and thus the cache-based inexistence proof could not be applied during the recent attack.
It is worth mentioning that even though Whalebone’s resolvers could not protect Amazon’s servers, they were not affected by the Increased malicious workload and the customers’ quality of service remained consistent.
Learn the impact of cyber criminality to ISPs and the ways how Whalebone could protect you. We invite you for Whalebone DNS Security webinar and product introduction.
The best way to describe Whalebone benefits is through customer feedback:
We were looking for something that could eliminate the behaviour of our clients who are not aware of their cybersecurity. Due Whalebone I am able to protect our network with 10.000 clients with two on-premise DNS resolvers. Moreover, Whalebone DNS resolving is 100% stable and reliable since it was deployed 2 years ago. Whatever we used before, there was always some issue. However, with WB everything goes like a Swiss watch. And I can get DNS off my head.
Do you agree DNS is a crucial part of each network? Additionally, have you ever heard it is also one of the most vulnerable parts of your network infrastructure?
The problem is massive!
According to Cisco’s Annual Report 2016, 91.3% of malware uses DNS to harm networks. We have our own data! In a period of last 30 day, 27% of all IPs protected by Whalebone experienced at least one security incident related to DNS. Besides, the proportion is increasing each month since we started to measure it.
DNS Security and Internet Service Providers
Should you be an ISP, you are experiencing a typical issue related to your customers. Your customers are not aware of their cybersecurity. Even if they have at least antivirus installed, they may forget to update it. As a result, they cause troubles to your network:
outgoing SPAM or DoS campaigns
blacklisting of IPs
and many more…
It is not on purpose. They just do not know about that. Moreover, the impacts of malware can start to live their own life unnoticed by the user.
It can get even worse. Not only copmuters and phones can get infected, but even smart devices, IoT or network components could be targeted by attackers.
DNS challenges ISPs have to deal with
Both DNS and cybersecurity area become more difficult and complex to manage. Terms like DNSSEC, IPv6, DNS over TLS are just the tip of the iceberg. The more important form of business perspective is to have reliable DNS resolving so that your customers do not experience any troubles whilst using the internet. You need peace of mind, right?
ISP, get your peace of mind about DNS with Whalebone
We can help you with everything mentioned above. And even more.
Let us invite you for Whalebone DNS Security webinar or you know what? Try Whalebone even before the webinar. Our full trial is for free and you will receive our complete support.
For Whalebone, getting fresh information on current threats is crucial. One source of such information is Twitter accounts of threat experts who post threats that they have come across. These tweets usually identify current threats, which makes their contents extremely valuable. Crucially, the data is neither structured nor harmonized, meaning one must use heuristic reasoning (“decode” them back to proper form) to be able to extract it.
In this article, we aim to describe how we went about extracting the data while showing different challenges we faced during the implementation. Besides, we will show how useful this data is in protecting the network.
There are two ways in which tweeters (Twitter users from the security community) share threat intelligence data, so called “indicators of compromise” (later on referred as “IOCs”). In our case, IOCs are malicious web addresses, posted either in a link to pastebin.com or in the body of the tweet itself, in which case they are usually protected against opening as described below.
How do tweeters share data about threats?
The former could easily reduced to the latter. We implemented a function that connects to those links and extracts e-text, from which IOCs can then be extracted by similar methods as from the main body of the text, but with the simplification that obfuscation usually doesn’t take place. At the end of the day, however, not all tweeters post URLs on pastebin and some post hashes and other information about threats. To take care of such cases, we follow URLs only for specified Twitter accounts.
Extracting data from the tweet body seemed like a formidable task, since there is no straightforward way of telling which URL is a true IOC and which is just a legitimate address that the tweeter could have posted. Fortunately, IOCs are marked by an important feature – they are obfuscated, so that Twitter doesn’t convert them into clickable links and people do not accidentally end up on malicious websites.
This feature of IOCs enabled us to filter out legitimate links – simply exclude all the links that are clickable (which is done by blacklisting t.co domain, as twitter sends all links through its servers).
Having ignored the t.co domain, all that is left in a raw tweet are obfuscated IOCs. The obfuscation methods vary, but there are not too many and most work by direct substitution. Common examples include ‘abd[.]com’ and ‘hxxp://el_karls.com’:
The first example contains the most common substitution: ‘.’ for ‘[.]’. Such obfuscation can be undone by simply substituting ‘[.]’ for ‘.’, leaving valid URLs which can then be parsed.
The second example contains another common method: the replacement of http by hxxp. Dealing with such cases is even easier – we simply ignore the protocol in the later stages of parsing the text.
It turns out that for most tweeters, we could simply revert the substitutions made during obfuscation by a mere substitute command. This makes it really simple to start parsing a new twitter feed – plainly collect the tweets from that tweet and add the substitutions required to revert obfuscation to a list in the config file.
After performing substitutions, we have URLs matching a URL regex ignoring the protocol (to account for ‘hxxp’). Matching against this regex and then checking with get_tld whether the matched text is indeed a valid domain is all that is left to do.
In a production environment, we implemented this algorithm with a configuration file containing 30 tweeters and 6 substitutions. Pastebin was followed in about 10 of them.
This results in about 2500 IOCs weekly flowing into our system, and since deployment in April, we have already recorded 3000 incidents involving these IOCs.
While useful, this model is still rather crude and doesn’t make use of all the information available in the tweets. For example, most tweeters also include the classification of the shared IOCs in their tweets (see example tweets, which both include this information), which is a useful bit of information and future challenge for us to get it into Whalebone.
Author: Kryštof Kolář
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.