Mosca Exit Program Double Withdrawal Exploit 2

Notice: This page is a freshly imported case study from an original repository. While the original content had a similar format, some sections may not have been fully completed. Please help fill in any empty sections or any missing information you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

BNB Smart Chain Image

The Mosca contract, launched on the Binance Smart Chain (BSC) on January 4th, is a decentralized subscription and referral system supporting multiple tokens, including USDT, USDC, and a native Mosca token. It offers users two subscription tiers, Standard and Enterprise, with rewards based on network activity. However, the contract contained a critical vulnerability, particularly in the exitProgram() function, where improper state updates allowed attackers to manipulate balances and perform double withdrawals. This exploit was caused by user.balanceUSDT and user.balanceUSDC not being reset correctly, which enabled attackers to acquire unusually large balances and withdraw funds using a flawed logic in the join() and exitProgram() functions. The exploit, attributed to a unique attacker named the Mosca exploiter (0xE763DA20e25103Da8E6AFa84b6297F87de557419), resulted in reported losses of $37.6k.

About Mosca

The Mosca contract appears to be a decentralized subscription and referral-based system deployed on the Binance Smart Chain (BSC) starting January 4th. It supports multiple tokens, including USDT, USDC, and a native Mosca token. The contract enables users to join a subscription program, participate in a multi-level referral system, and earn rewards based on network activity. It offers two subscription tiers: Standard and Enterprise, with higher rewards and benefits for enterprise users.

The Reality

The smart contract appears to have been deployed quickly and with a critical vulnerability.

What Happened

"Mosca was reportedly attacked on BSC, resulting in an approximate loss of $19,500."

Key Event Timeline - Mosca Exit Program Double Withdrawal Exploit 2

Date	Event	Description
January 4th, 2025 1:41:11 PM MST	Mosca Smart Contract Launch	The Mosca smart contract is first launched on BSC.
January 5th, 2025 10:22:49 PM MST	Theft Transaction On BSC	The first exploit transaction occurs on the Binance Smart Chain.
January 5th, 2025 10:44:00 PM MST	TenArmorAlert Posts About Exploit	TenArmorAlert posts about the exploit, along with details of the root cause. "Root cause appears to be in the exitProgram() call, the user.balanceUSDT & user.balanceUSDC are not reset correctly, enabling double withdrawal."
January 5th, 2025 11:40:00 PM MST	SlowMist Reports On Incident	SlowMist
January 7th, 2025 6:10:00 AM MST	Tweet Post By @lmanuel	Twitter/X user @lmanualm reports "[p]otential suspicious activity".
January 7th, 2025 9:42:00 AM MST	0xCommit Audits Post Made	0xCommits makes a post which appears to summarize only that there was a high level exploit.
January 12th, 2025 6:52:21 PM MST	Verichain Publishes Blog Post	Verichain publishes a detailed breakdown of the exploit.
January 12th, 2025 11:00:03 PM MST	Second BSC Theft Transaction	The vulnerability is exploited a second time in the Mocha smart contact.
January 13th, 2025 12:04:00 AM MST	TenArmor Posts Second Attack	TenArmor posts a second attack, including additional detail on the cause.
January 14th, 2025 7:17:53 AM MST	Substack Vestra Article	Olympix publishes a description of the first exploit with additional details.
January 23rd, 2025 12:15:12 AM MST	MaanVader Article Published	MaanVader publishes a Medium article with even more details of the exploit.

Technical Details

"Improper state updates in the exitProgram() function allowed attackers to manipulate balances."

"Root cause appears to be in the exitProgram() call, the user.balanceUSDT & user.balanceUSDC are not reset correctly, enabling double withdrawal."

"The join() function in the Mosca contract appears to have a logic flaw, incorrectly adding a diff to the deposited amount. A strange logic!

This flaw enabled the attacker to acquire an unusually large user.balance."

"The root cause of the exploit was improper state updates in the exitProgram function. The withdrawAll() function calculated the withdrawal amount as the sum of user.balance, user.balanceUSDT, and user.balanceUSDC. However, only user.balance was reset to zero after the withdrawal, leaving user.balanceUSDT and user.balanceUSDC unchanged. The attacker manipulated this flaw by first calling the buy() function to increase their user.balanceUSDC. Next, they used the join() function to add their address to the rewardQueue. Finally, they withdrew funds using the exitProgram() function, leveraging the incomplete state reset."

Unique exploiter named Mosca exploiter (0xE763DA20e25103Da8E6AFa84b6297F87de557419)

Total Amount Lost

Losses here are reported as $37.6k.

The total amount lost has been estimated at $38,000 USD.

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.