Research by: Haifei Li, Check Point Research

Introduction

Outlook, the desktop app in the Microsoft Office suite, has become one of the world’s most popular apps for organizations worldwide for sending and receiving emails, scheduling conferences, and more. From the security perspective, the app is one of the critical “gateways” responsible for introducing various cyber threats into organizations. Even a minor security problem in this app could cause severe damage and undermine the overall enterprise security.

Therefore, it is essential to examine the attack vectors on Outlook for typical enterprise environments, which Check Point Research will do in this paper. We assume the position of an average user – we click and double-click on things on Outlook – as our daily work requires, and we examine the security risks they may introduce from a security research perspective.

We will examine the attack vectors in three categories: the “obvious” Hyperlink attack vector, the “normal” attachment attack vector, and the “advanced” attack vector regarding Outlook email reading and ‘special object’. We use section numbers to mark the scenario for each attack vector.

Please note that the discussed research in this paper was performed on the latest Outlook 2021 (desktop version on Windows), with the latest security updates installed as of November 2023, in typical/default Outlook + Exchange Server environments.

I – The Obvious: the Hyperlink Attack Vector

1.1 – ONE Single-click: Web Links

If an attacker wants to attack someone via emails, an obvious method is for the attacker to send emails with malicious web hyperlinks to lure the victim to click on the links in these HTML emails. This is in fact the attack vector for all the phishing emails that the industry has been fighting against every day.

For example, the following is an email we received – the email body is written in HTML and has some links, such as “https://www.microsoft.com”. When the user clicks, Outlook calls the default browser on the OS to browse the website, which is just obvious.

Figure 1 – gif showing web links in Outlook email

For this attack vector, the attacker basically uses emails as a “bridge” to perform web-based attacks, whether they are social-engineering-based phishing attacks, browser exploits, or even highly technical browser zero-day exploits.

Please note that only a single click is needed to launch web links on Outlook. No additional confirmation is needed by the users. While this may sound scary (compared to the next attack vectors we will discuss), the security risks are not in Outlook, but in the browsers. If the browser is strong enough (against browser exploits) and the user is smart enough (against phishing attacks), there would be no problem. That is probably why Outlook considers usability as the first criteria here; another reason could be that email hyperlinks are just too common, you cannot let users confirm every click, because that would be too annoying and take too much time.

1.2 – Not all hyperlinks are web links

However, Outlook hyperlinks are not just web links, they could contain other types of hyperlinks, and those may introduce security risks. In fact, we at Check Point Research have discovered an Outlook bug in this attack vector. However, discussing particular bugs is not the goal of this paper. Therefore, we’d like to leave this topic for another publication. Please watch our blog site if you are interested. We will update here when the blog post is available.

II – The Normal: the Attachment Attack Vector

Here is the normal attack vector: the attacker sends the victim an email with a malicious attachment and lures the victim to open the attachment.

The “opening the attachment” on Outlook could mean two different types of actions. When the user double-clicks on the attachment, the system is trying to call the default registered application (for that attachment file type) on Windows to open the attachment in that application. When the user single-clicks on the attachment, it is trying to call the registered “previewer” application (for that attachment file type) to preview the attachment within the Outlook app. We will discuss both in detail.

The security risk introduced in the “attachment” scenarios depends on the security of the registered application for that attachment file type. If the application is robust enough with proper security measures, it would be less risky for the end user. On the other hand, if the application is insecure, it would be more risky for the end user.

2. 1 – Double-clicking: Opening the Attachment

If the user double-clicks on the attachment, Outlook will try to call the registered application (for the file type of the attachment) to open the attachment. Depending on the attachment’s extension name (the file type), there could be three scenarios.

2.1.1 – NO CLICK: The attachment’s extension name is marked as an “unsafe” file type.

The attachment could not be opened by Outlook (but it could be received, though).

The following figure shows a “.vbs” attachment is received but the user could not open it, because the “.vbs” file type is marked as “unsafe” by Outlook.

The blocked unsafe file types on Outlook are listed here by Microsoft.

2.1.2 – ONE DOUBLE-CLICK AND ONE SINGLE-CLICK: The attachment’s extension name is not marked as “unsafe” and not marked as “safe” either.

You may consider this as the “unclassified category”. In this scenario, there would be a promoted dialog shown to the user, asking the user for confirmation to open the file.

In this scenario, the user needs to perform two clicks in order to open the attachment. One is double-clicking on the attachment; the other is clicking the “Open” button on the promoted dialog (not the default button). After that, the default/registered app for this specific file type on the Windows OS would be used to open the attachment.

In Check Point Research’s recent blog post, we disclosed an interesting attacking technique (leaking NTLM information via common ports like 80/443) whereby the attacker delivers the .accdb exploit via emails; this would also fall into this scenario. The following gif shows this in an intuition way.

Figure 3 – gif showing double-clicking to open .accdb attachment on Outlook

In the real world, there are so many file types in this “unclassified” scenario. For an average Outlook user, it is impossible to know if every app/attachment you open is secure enough. Therefore, we recommend users stay cautious against this attack vector: do not easily click on the additional “Open” button for attachments from untrusted persons.

For application developers, while it is still rare in the real world, a good recommendation is to honor the Mark-of-the-Web (MotW). In this scenario, the attachment is marked as “from the Internet” when it’s sitting in the Outlook temporary directory prior to being opened by the third-party app. Therefore, if the third-party app checks and honors the MotW, like limiting the features and/or opening the app in an application sandbox when it detects that the file has the MotW flag, it would be a very good security practice.

Knowledge note: on default Outlook + Exchange Server environment, MotW is only set for attachments from email addresses outside the organization’s domain (the Internet), but not for email addresses inside the organization. Therefore, the MotW is very good for developers to balance security and usability for their apps.

For example, on February 2023 Patch Tuesday, Microsoft released a “defense in depth” feature via CVE-2023-21715 for Microsoft Publisher, a Microsoft 365 app. What the update does is simply disable Macros on Publisher totally when the .pub file has MotW. According to our research, when a .pub file with Macros embedded is opened by Publisher, in a “pre CVE-2023-21715” environment, if the .pub file has MotW (an external .pub attachment would fall in this attacking scenario), the following warning dialog is provided to the end user.

In the “post CVE-2023-21715” environment, the dialog is changed to:

Note the difference, there’s now no option for the user to choose to run Macros inside the .pub file when the file comes with MotW (from the Internet), making it secure for the end user.

2.1.3 – ONE DOUBLE-CLICK: The attachment’s extension name is marked as a “safe” file type.

In this scenario, the attachment would be opened directly when the user double-clicks on the attachment.

Check out the following gif where the user opens a .docx file directly via one double-click because the .docx is marked as a “safe” file type.

Figure 6 – gif showing double-clicking to open .docx attachment on Outlook

Since there is no additional confirmation for users prior to opening the attachment in this scenario – one double-click is enough to call the application to open the attachment. Application developers should be extremely careful to register their file types/applications into this category.

A highly recommended security enhancement is developing an application sandbox for your application and processing the file in it, like Word, Excel, and PowerPoint’s “Protected View” mode. That said, the Word (.docx, .doc, .rtf, etc.), Excel (.xlsx, .xls, etc.), and PowerPoint (.pptx, .ppt, etc.) file types are all registered in this “safe” category, as well as the popular PDF file type for the latest Adobe Acrobat Reader (tested on version 2023.006.20360).

Figure 7 – Word running in Protected View mode (process integrity level “AppContainer”) when opening a document from external emails

The Protected View mode on Word/Excel/PowerPoint is not a typical application sandbox. In fact, beyond processing the file in the sandboxed process, it also limits the features that could run when the app is running in Protected View mode. For example, all OLE-related features are disabled when Protected View mode is activated. Therefore, the Protected Mode on Word/Excel/PowerPoint is much stronger than typical application sandboxes from a security point of view.

2.2 – Single-clicking: Previewing the Attachment

If the user single-clicks on the attachment (compared to double-clicking), Outlook will try to call the registered “previewer” app (for the file type of the attachment) to “preview” the attachment inside Outlook. Even though it’s called “preview”, the attachment file is still opened and processed from the technical point of view. The difference is that when previewing, the third-party app is running as a COM server in the background, and the attachment content is displayed in the Outlook window. As previously discussed, when “opening” the attachment via double-clicking, the third-party app is run directly, and the content is displayed in the application’s window.

Depending on the attachment’s extension name (the file type), there could be four scenarios when previewing the attachment.

2.2.1 – NO PREVIEW: The attachment’s extension name is marked as “unsafe”.

This is the same situation as we discussed in Scenario 2.1.1. Since the attachment is totally disabled, there are no opening or previewing options.

2.2.2 – NO PREVIEW: There’s no registered previewer app for the extension name.

In fact, most of the file types we have seen are in this category because most apps handling the file types are not registered as Outlook previewer apps. Check out the following gif where the user attempts to preview (via a single-click) a .wmv file (a media file type) but there is no registered app for that file type, so an error message is displayed.

Figure 8 – gif showing single-clicking trying to preview a .wmv attachment on Outlook but receiving an error message

2.2.3 – TWO SINGLE-CLICKS: The previewer app is registered but needs additional confirmation to preview the content

There are some file types, that have their previewer apps registered but Outlook doesn’t have much confidence that previewing the attachment is safe, so Outlook gives an additional warning dialog to the user – which requires another single click – to confirm to preview the attachment. Therefore, there are two single-clicks in this scenario, one for single-clicking on the attachment, and the other for clicking on the “Preview file” button on the warning window.

The following example previews a .pdf attachment – a popular file type- when Adobe Acrobat Reader is installed on the OS. When the user single clicks on the attachment, Outlook asks if the user wants to continue the previewing. Additionally, there’s an option letting the user choose if he/she wants to confirm this file type every time.

Figure 9 – gif showing single-clicking to preview a .pdf attachment on Outlook

Note that in the background, the PDF attachment is processed in the Adobe Acrobat Reader sandbox (one of the ”Acrobat.exe” processes with integrity level “Low”). The Adobe Acrobat Reader processes are started by the Windows process “prevhost.exe”. As shown in the following figures.

Figure 10 – Adobe Acrobat Reader runs in the background and processes the attachment in sandboxed environment, when user previews a PDF attachment on Outlook

Knowledge note: In Windows, standard/default users start processes with the “Medium” integrity level, so if a process is running with a lower integrity level (“Low” or “AppContainer”), it usually indicates that the process is running with a restricted application sandbox. Read more here.

2.2.4 – ONE SINGLE-CLICK: Previewer app is registered and marked as “safe”.

This scenario is the smoothest way to read the content of an attachment. When the user just single-clicks on the attachment, the attachment is previewed and the content is displayed in the Outlook window.

Because the process is very smooth, the potential security risk it may introduce is high. Therefore, from a security point of view, only the apps that have robust security enhancements should be registered into this “previewing safe list”.

For example, the Word, Excel, and PowerPoint file types are in this list. Following is a gif showing a .docx attachment being previewed on Outlook.

Figure 11 – gif showing single-clicking to preview a .docx attachment on Outlook

And, when previewing Word, Excel, or PowerPoint attachments on Outlook, the corresponding app is always run in the security-strong Protected View mode, as the following figure shows. So it protects users while also offering great usability.

Figure 12 – Microsoft Word runs in the background and processes the attachment in Protected View mode, when user previews a Word attachment on Outlook

Side note: Attentive readers may note that it is a bit different from the Adobe Acrobat Reader scenario we previously discussed, the sandboxed “WINWORD.EXE” process is started directly via Outlook process, not via “prehost.exe”, and there is only one “WINWORD.EXE” process, while in the Adobe Acrobat Reader scenario, there are two “Acrobat.exe” processes.

III – The Advanced: the Email Reading and Special Object Attack Vectors

3.1 – The Email Reading Attack Vector

The Email Reading attack vector is for the scenario in which the security problem is triggered as long as the victim reads the (attacking) email on Outlook. So this is a very powerful attack vector.

It is often referred to as the “Preview Pane” attack vector in the security domain, especially for Microsoft Security Update pages. For example, the following is a vulnerability patched by Microsoft which could be triggered when users read emails on Outlook but is referred to as the “Preview Pane” attack vector.

Figure 13 – A typical Microsoft Security Update webpage where Microsoft describes a vulnerability that could be triggered by “Preview Pane”

It is, in fact, a confusing name, as someone pointed out also. Anyway, when we read that Microsoft claims the Outlook Preview Pane is an attack vector, we can assume that the vulnerability could be triggered as long as the user reads emails on Outlook.

This lies in the core functions where Outlook processes emails or other objects that are delivered together with emails. From a vulnerability research point of view, that usually occurs when there is a vulnerability when Outlook parses or processes the email format. Outlook supports three types of email formats: the plain text email format, the HTML email format, and the TNEF email format (commonly known as the “Outlook Rich Text” format). The HTML and TNEF are complex formats so they produce more vulnerabilities, especially for the TNEF which is (basically) a binary format. The bug types could vary from memory corruptions to logical bugs.

Protip: configuring your Outlook only to read plain text email is the best for security, although you may lose the usability, of course since these links, inline pictures will not show up in the plain text email.

The following figure is an example of a piece of a TNEF format email, note the string “Content-Type: application/ms-tnef”, which specifies this email follows the TNEF format.

Figure 14 – the content of a typical TNEF (Outlook Rich Text) format email

Historically, many vulnerabilities have been found in this Outlook Email Reading attack vector, but working exploits were rare. That is because finding a scripting environment within or triggered by Outlook is not an easy job but some slips still can happen. Here is an example.

In 2015, the author of this paper discovered and reported a logical bug in Outlook, dubbed “BadWinmail”, which allows running any Flash exploit (at that time, Flash was installed by default on Windows 8/10) embedded in the TNEF format, via the OLE mechanism. Arbitrary and reliable code execution is achieved as long as the victim reads the email on Outlook – no need to click anything, so it was a very powerful zero-day exploit. Here is the paper and video demonstration if readers would like to see the impact of such an attack vector.

3.2 – The Outlook Special Object Attack Vector

For the previous Outlook Preview Pane (Email Reading) attack vector, although it is already very powerful, the victim still needs to read the email. However, there is a possibility that the victim doesn’t even need to read the email at all,- for as long as the victim opens Outlook and receives emails from the email server, he/she could still be pwned. That’s the attack vector we call the ‘Special Object’ attack vector.

Here is a real-world example, in March 2023, Microsoft disclosed that they detected a threat actor using a zero-day vulnerability (CVE-2023-23397) in Outlook to attack Ukrainian organizations. The zero-day allows local Windows to leak (Net)NTLM credential information to the attacker-controlled server. In detail, the root cause is a logical vulnerability when Outlook processes the so-called “reminder” object sent from the attacker. Please note that this attack doesn’t even need the victim to read the email on Outlook – it would be triggered automatically as long as the victim opens Outlook and connects to the email server. Here is a good analysis including a video demonstration, from MDSec .

Comparing the User Interoperability Required for Each Scenario

Now that we have reviewed all the attack vectors on Outlook, it would be interesting and valuable to compare each of them to see how easy (or hard) the attack scenario could be used for delivering exploits. Our methodology has us assuming the position of the attacker and we already have a working exploit for the targeted application, but we need Outlook as a “delivering method” to “deliver” that exploit “into” the targeted application.

We could use scores to mark the user interoperability required (or, the difficulty of delivering the exploit) for the attack scenario. For example, assuming we have a zero-day exploit for Microsoft Access – an app is usually installed with Outlook as part of the Office suite – and we need to use Outlook to deliver that Access exploit. We tested that when Microsoft Access is installed in the victim’s machine, a .accdb attachment would fall in Scenario 2.1.2 – The attachment’s extension name is not marked as “unsafe” and not marked as “safe” either. As we previously examined, that would require 1 double-click and 1 single-click.

If we set the score of a single-click to 1.0, because performing one double-click is a bit harder than performing one single-click, we could set the score of performing one double-click to 1.2 (plus 0.2, compared to single-clicking). The harder performing the action, the higher the score.

Thus, for the above Scenario 2.1.2, the total score is 1.2 (one double-click) + 1.0 (one single-click) = 2.2.

With this methodology, we could have the following table.

ScenarioDescriptionUser interoperabilityScore1.1Web links in email body1 single-click1.01.2Other hyperlinks in email body1 single-click1.02.1.1Attachment opened in third-party app, file type marked as unsafeN/AN/A2.1.2Attachment opened in third-party app, file type not marked as safe nor unsafe1 double-click and 1 single-click2.22.1.3Attachment opened in third-party app, file type marked as safe1 double-click1.22.2.1Attachment previewed in Outlook, file type marked as unsafeN/AN/A2.2.2Attachment previewed in Outlook, no registered previewer for file typeN/AN/A2.2.3Attachment previewed in Outlook, has registered previewer but not marked as safe2 single-clicks2.02.2.4Attachment previewed in Outlook, has registered previewer and marked as safe1 single-click1.03.1Email Reading / Preview Pane attack vectorNo click, just reading email is enough0.23.2Other Outlook special object exploitationNo click, just receiving email is enough0

Table 1 – a scoring system for various attack scenarios on Outlook

As you can see, we set the score of the Email Reading / Preview Pane attack vector to 0.2 (Scenario 3.1), as it requires a little more user interoperability compared to Scenario 3.2 – special object exploitation. For the special object exploitation, we set the score to 0, as this is the perfect scenario for attackers.

As we can find in the table, the most challenging scenario for attackers is Scenario 2.1.2 – the attachment’s extension name is not marked as “unsafe” and not marked as “safe” either, which has the highest score – 2.2. The perfect one is the Scenario 3.2 – the Outlook special object exploitation (score 0), or the Scenario 3.1 – the email reading attack vector (score 0.2).

However, we need to take note that we are only comparing the user interoperability here; we have a big prerequisite of having a working exploit for the targeted app. In fact, most of the time, when the score is low (easy for exploit delivering), the difficulty of finding and developing a working exploit for the targeted app is high.

For example, for the web browser exploit, the score is low (1.0) which means it is relatively easy to deliver the exploit, but finding and developing a working exploit for modern browsers, such as Google Chrome, is costly (as the attacker needs to bypass all the modern exploitation mitigations). So from a defense point of view, the risks for web links in Outlook emails are not completely unacceptable for average users.

For another example, for Scenario 2.1.3 (one double-click to open the attachment), if we assume the attacker has a Word exploit that works on the normal mode but not the “Protected View” mode of Microsoft Word – it is, in fact, the most common case of Word-based attacks. If the attacker sends the exploit (from an external source) as an email attachment, in order to gain successful exploitation, the victim needs to not only perform the one double-click in this scenario but also needs to perform an additional single-click on Microsoft Word (for the “Enable Editing” button, see the following figure), in order to exit the very strict Protected View mode. So, there are in total two user-clicks required for delivering a typical Word-based exploit, if we consider the full attack chain.

Therefore, when we assess the risk for an exploit delivered via the Outlook attack vectors, we need to assess the whole picture – we need not just consider the Outlook attack scenario discussed in this paper, but also the exploit itself, including the difficulty of developing the exploit.

Conclusion

In this paper, we examined various attack vectors in modern Outlook and compared the user interoperability required for each scenario when attackers use Outlook to deliver their exploits. We analyzed the scenarios by acting as an average Outlook user, using real-world examples, and with our own cutting-edge vulnerability research efforts. We hope this paper can help the security industry deeply understand the security threats that Outlook may pose.

All discussed attack vectors in this paper are monitored and protected by Check Point solutions including Check Point Email Security & Collaboration Security. Harmony Email & Collaboration provides complete protection for Microsoft 365, Google Workspace and all your collaboration and file-sharing apps. Harmony Email & Collaboration is designed specifically for cloud email environments and is the ONLY solution that prevents, not just detects or responds to, threats from entering the inbox.

Harmony Endpoint provides comprehensive endpoint protection at the highest security level while XDR/XPR quickly identifies the most sophisticated attacks by correlating events across your entire security estate and combining with behavioral analytics, real time proprietary threat intelligence from Check Point Research and ThreatCloud AI, and third-party intelligence.

Threat Emulation as well as Check Point gateways provide superior security beyond any Next Generation Firewall (NGFW). Best designed for Zero Day protection, these gateways are the best at preventing the fifth generation of cyber attacks with more than 60 innovative security services.
Check Point Research proactively hunts Outlook and email related attacks in the wild. As a leading security company, Check Point continues to develop innovative detection and protection technologies for customers around the world.

The post The Obvious, the Normal, and the Advanced: A Comprehensive Analysis of Outlook Attack Vectors appeared first on Check Point Research.

Check Point Research – ​Read More

By Oded Vanunu, Dikla Barda, Roman Zaikin

Unmasking Deceptive Tactics: A recent investigation by Check Point Research exposes a troubling trend in the cryptocurrency landscape. Deceptive actors are manipulating pool liquidity, sending token prices soaring by a shocking 22,000%.

$80,000 Heist Unveiled: The manipulation of pool liquidity resulted in a swift and calculated theft of $80,000 from unsuspecting token holders. This incident sheds light on the evolving strategies scammers employ to exploit decentralized finance platforms.

Continued Threat Landscape: This incident follows hot on the heels of a previously reported million-dollar scam. Check Point Research recently delved into the intricacies of a rug pull orchestrated through a fake token factory. For details on this preceding incident, visit Check Point Research: Unraveling the Rug Pull.

Check Point’s Blockchain Threat Intelligence system raised an alert on pool liquidity manipulation, resulting in a staggering token price increase of 22,000%. The malicious actor exploited the liquidity pool, stealing $80,000 from unsuspecting holders.

Check Point’sBblockchain Threat Intelligence system detected a malevolent transaction:
https://etherscan.io/tx/0x85ebb1b1d6f091a2d72c4cffb66beea0552a07b2efabb5fd53d4198f8d159b64

What did we find?

The scammer created two wallets:

0x48F7661E84A823505d683D092a2DccdA1e5aA119

0x151a2498826F9fe6f214C92bB1811f7d1153b630

Using the first wallet, they deployed the contract token WIZ (0x2ae38b2b47bf41ba4ab8f749b092fdd02b00bc1e) and its liquidity pool pair address (0x6e0367d897a8fd8bcbc44b4e2a14bafa904360aa), which included reserves of WETH and WIZ tokens. In the second wallet (0x151a2498826F9fe6f214C92bB1811f7d1153b630), the scammer created a malicious contract (0x796042E0032aC5247bc04A49102d49c5b5A5cF0c) designed to exploit a backdoor and manipulate the WIZ token price, resulting in an $80,000 theft from victims.

Method of Operation:

Token Creation: The scammer launches a new cryptocurrency token, pairs it with a well-known cryptocurrency on a decentralized exchange (DEX), creating a liquidity pool.

Token Promotion: Aggressive marketing, often leveraging social media and influencers, generates hype and attracts investors.

Investor Participation: As investor interest grows, they start purchasing the new token.

Pool Manipulation: After accumulating substantial investments, the scammer manipulates the pool reserve by burning most WIZ tokens, reducing the supply and temporarily inflating the token’s price by 22,000%.

Scammer’s Gain: Exploiting the inflated price, the scammer sells a significant number of tokens, pocketing $80,000.

Technical Insights:

Liquidity pools

In the world of cryptocurrencies, you often need to swap one type of digital currency for another. But how do you do it easily and quickly without an intermediate? That’s where liquidity pools come in. Without these pools, you’d have to find someone willing to trade at the exact time and price you want, which can be difficult and time-consuming.

So how does a liquidity pool work?

Let’s break down the mechanics of a liquidity pool:

Picture a sizable digital reservoir holding two distinct cryptocurrencies—let’s call them Token A and Ethereum. This reservoir serves as an open arena where anyone can swap Token A for Ethereum or vice versa.

Now, when an individual decides to exchange Token A for Ethereum, they contribute Token A to the pool and withdraw an equivalent value of Ethereum. The dynamic pricing within the pool fluctuates based on the quantity of each token present. If there is an abundance of Token A but a scarcity of Ethereum, the value of Token A decreases while Ethereum’s value rises.

In the case at hand, the scammer manipulates the pool balance by burning tokens. Burning tokens within a liquidity pool, like the WIZ/WETH pool, can boost the token’s value by adhering to the core principles of supply and demand. As tokens are permanently removed from circulation, the overall supply diminishes.

Liquidity pools follows a formula that harmonizes the quantities of two tokens. When one token type (WIZ in this instance) undergoes reduction through burning, the relative value of the other token (WETH) in the pool escalates to maintain equilibrium. Failure to increase the amount of WETH leads to a substantial surge in the token price, particularly for WIZ.

Are you seeing how hackers or scammers exploit this method, known as liquidity pool manipulation, to sway token prices?

The crux of this strategy lies in the transient inflation of the token’s price within the liquidity pool. Given that decentralized exchange (DEX) prices hinge on asset ratios in the pool, diminishing one side (via burning) can ditort the price.

Liquidity pools become susceptible to exploitative tactics, including rug pulls or influencing contracts reliant on these pools for price data. This blog zeroes in on the former, unraveling the narrative of a scammer concealing a backdoor to manipulate the WIZ/WETH liquidity pool by incinerating their tokens.So, let us see what the scammer did:

The scammer runs the function ‘brr’ methodID (0x5606de36) on his malicious contract:

let’s see this function:

We can see on line 127 the scammer runs the transfer function on the _coin contract address, the _coin address will be set in an earlier function by the scammer to WIZ address: 0x2ae38b2b47bf41ba4ab8f749b092fdd02b00bc1e

Using this transfer function, the scammer was able to burn the WIZ tokens on the pool, let us understand how :

In order to get to the _burn function the scammer will have to pass a few checks, which we will explore now:

The first check he will need to go through is limitsEnabled, this would have needed to be set to False in order for the scammer to get to the second check.

for limitsEnabled to be False, the scammer needed to run the function called ‘removeLimits’

And as we can see, right before renouncing the ownership of WIZ contract he calls this function:

So this is how the scammer passes the first check.

Now let us look at the second check, in this, the ‘from’ address needs to return False on the ExcludeFromFees and True for isexcludedForMaxTxAmount,

since both functions _isExcludedFromFees and _isExcludedForMaxTxAmount are public, we can run them with the scammer contract address as input and check the results:

Let us look at how the malicious contract address was set to True on the ExcludedForMaxTxAmount, since this is the part that helps us understand that the person who created the WIZ token and the scammer is the same person.

In the WIZ contract code we found a backdoor, the scammer hardcoded the malicious contract address in the code as mktRecevier, and set the excludeFromMaxTranscation to True for this address:

This helps the scammer to pass the second check, and allows him to get to the _burn function.

He then uses this function to burn the WIZ tokens in the WIZ/WETH liquidity pool.

If we will continue to look at the malicious contract code:

We can see the scammer in line 132 of the malicious contract sync the pool and raises the WIZ price. Then at the end in line 137 executes 0xf77 which sells all the tokens and steals almost 80,000 dollars.

As you can see in CoinMarketCap the price of the token raises by 21949% at the time of this malicious transaction:

Scammer’s Strategy:

The scammer’s approach involves temporarily inflating the token price in the liquidity pool. By manipulating the pool balance, they influence the decentralized exchange prices. Liquidity pools, integral to various contracts, become vulnerable to manipulative schemes.

Conclusion:

This manipulation scheme highlights the susceptibility of liquidity pools to fraudulent activities. Scammers leverage backdoors and exploits to manipulate token prices, emphasizing the importance of vigilance in the decentralized finance space.

Check Point researchers are actively monitoring domains associated with the identified scammer’s wallet address and similar. The Threat Intel Blockchain system, developed by Check Point, continues to accumulate valuable information on emerging threats, and this intelligence will be shared in the future. In this collaborative effort, we aim to empower investors with the knowledge needed to navigate the crypto space securely and protect themselves from potential pitfalls. For more information contact us at: blockchain@checkpoint.com

The post Crypto Deception Unveiled: Check Point Research Reports Manipulation of Pool Liquidity Skyrockets Token Price by 22,000%. appeared first on Check Point Research.

Check Point Research – ​Read More