Phishing for Bulls: Lessons Learned From a Crypto Wallet Attack


Posted on by Pedro Fortuna

The crypto market is clearly undergoing a bullish phase, playing in favor of a multitude of Fintechs that provide services to a fast-growing audience.

 

As news of quick profits from crypto made headlines globally, we started to witness an underlying phenomenon: a new wave of much more inexperienced users who want to join in on the crypto bandwagon even though they lack the required technical knowledge to stay secure. Combine these ingredients, and you get a scenario that’s far too appealing for attackers.

 

One of the most common goals in attacks targeting crypto holders is to trick them into providing sensitive information such as their private key. With this key, attackers can then empty users’ crypto wallets in an instant. So it’s no wonder that we have been seeing sophisticated phishing attacks specifically targeting crypto users, taking advantage of the less tech-savvy ones.

 

Recently, we saw this happen to users of the Celsius crypto wallet. Scammers were able to grab hold of leaked data of Celsius users, which included their email and phone number. Then, they sent a seemingly legitimate email that directed users to a scam page to redeem a special offer. This offer was meticulously crafted around the latent expectation of Celsius’ users surrounding the launch of a web wallet. That succeeded in tricking several users into providing their personal wallet’s private key, along with the fact that the copycat page was nearly identical to that of the company. As a result, several users lost their entire crypto balance.

 

When analyzing this attack, we found several interesting comments on the source code of the copycat page that led us to believe that the attackers may be of a Portuguese-speaking country (Portugal, Brazil, Angola, etc.) When analyzing the script that retrieved the users’ private wallet key, we also found three different domains that were being used by attackers, the oldest of which was registered on November 25, 2020. Additionally, we found a reference to an advertising domain, which might indicate that the attack was a result of collaboration between groups or individual attackers, perhaps part of a larger ongoing phishing campaign.

 

Lessons Learned

 

The first key lesson to retain from this incident is that attackers go the extra mile to get their hands on user data. With such a carefully crafted page, it’s not just the non-tech-savvy users who are getting tricked. Even a long-time Celsius customer would probably not notice any discrepancies in the scam page at first glance, assuming that it was part of a legitimate campaign.

 

However, preventing copycat pages is no easy task. In this case, the JavaScript source code of the scam page is actually quite distinct from the source code of the official Celsius page. But if attackers for some reason choose to copy the entire source code, there are some preventive measures that can raise the cost of creating the copycat page. For one, protecting the JavaScript source code with runtime defenses will make it much more difficult for attackers to even retrieve the source code in the first place and further deploy it in a different environment.

 

Of course, the outcome of these attacks is tied in with how targeted they are. As such, a successful phishing campaign depends on the ability of attackers to get valid user data. In the Celsius incident, attackers did this by gaining access to a third-party email distribution system, which enabled them to send phishing emails and SMS.

 

And this is where we find another important lesson: the fragility of software supply chains. A problem so significant that it prompted an executive order by the White House, which seeks to ensure that private and public organizations minimize their exposure to supply chain attacks.

 

Given the growing number of attacks taking advantage of the web supply chain, including the recent attacks on the Codecov tool and the breach of an official PHP repository, this could become the MO of choice for future attacks targeting the crypto industry. In a web supply chain attack, the malicious actors breach a third-party service provider (such as a chatbot or an analytics service) to inject malicious code on the website and leak sensitive user data. Once they have this data, it’s just a matter of replicating strategies similar to those used in the Celsius incident, tricking users and emptying their crypto wallets.

 

Solving the problem of web supply chain security is surely one of the biggest challenges of this decade. The technologies that companies have used for years to prevent data leakage attacks, such as Web Application Firewalls, are simply not capable of tackling web supply chain attacks. And seeing as companies will not dial down how dependent they are on third-party code, the answer to this problem seems to be to provide companies with full visibility and control of the third-party scripts running on their websites. Only then will they be able to guarantee that their websites aren’t being used to leak user data right into the hands of scammers.

 

Even if there’s not much that users can do to ensure that their data is kept secure, this is a good time to recall some of the best security practices, such as being very careful in clicking email links or submitting any type of private information and even securing accounts with multi-factor authentication and stronger passwords.

 

As for the definitive solution to the web supply chain problem, the fact that the US and UK governments are pushing for improved software supply chain security is definitely a good sign. Looking forward, the answer will likely reside in improved application security controls and procedures that allow companies to control their supply chains and drastically reduce third-party risk.


Contributors
Pedro Fortuna

CTO and Co-Founder, Jscrambler

Human Element

phishing

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community