Nkpaymentcap Fake Transfer Notification

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' section to other sections, and add any missing information or sources 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!

The EOS project nkpaymentcap was attacked through a fake receipt attack, where the token transfer was between two accounts owned by the attacker. A number of EOS smart contracts had a vulnerability where they would allow tokens to be withdrawn erroneously if an attacker sent funds to themselves. The project doesn't appear to exist at the moment, so it would not seem like anything happened to assist affected users.

This is a global/international case not involving a specific country.

About Nkpaymentcap

"On March 11, EOS DApp nkpaymentcap was attacked, and hackers successfully made a profit of 50,000 EOS, which is approximately more than 1 million yuan." "According to data monitored by PeckShield's risk control platform DAppShield, EOS DApp nkpaymentcap suffered a false transfer notification attack at around 2:30 in the morning, and lost 50,000 EOS. At the current price of EOS, the loss is about US$180,000."

"Fake Receipt Attack. The key feature of this attack is that the vulnerable smart contract is misled by the fake notification to receive tokens, while the actual token transfer occurs between the two accounts belonging to the same attacker (see §3.2). For simplicity, we will use from_account and to_account to represent the two accounts in the following, where to_account will send the fake receipt to vulnerable contract, and from_account is the ultimate beneficiary. Accordingly, we will first query all the transactions of token transfer whose tokens are issued by eosio.token and token symbols are “EOS”, to get all the true EOS token transfers."

"These transactions will be regarded as the fake receipts with crafted notifications. Next, if a from_account sends a fake receipt before making profits from the vulnerable contract, we will mark the corresponding transaction as potential. After that, by eliminating the unrelated EOS spending transactions (e.g., for testing purpose initiated by the attacker), we focus mainly on those who have gained more true EOS tokens than they spent. If the input-output ratio are still high, the corresponding transactions are labeled as suspicious. Finally, we will manually check the suspicious transactions whether the vulnerable smart contract will resume the normal execution after receiving the fake receipts. If so, we will mark such a transaction as a fake receipt attack."

"The attacker launched continuous attacks on EOS DApp nkpaymentcap and successfully profited 50,000 EOS. After analysis, it was found that the attacker used a fake transfer notification attack to obtain a large number of contract tokens, and then exchanged the tokens into real EOS for cash out through the DApp contract."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - nkpaymentcap Fake Transfer Notification

Date	Event	Description
March 11th, 2019 12:00:00 AM	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Total Amount Lost

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

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

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?

Prevention Policies

There are a number of ways to prevent and mitigate this situation. It is far more secure to have the majority of funds in a multi-signature wallet where keys are stored offline by multiple operators. This would limit the potential loss to only those funds being actively needed. Audits can be used to reduce the risks on the hot wallets further, and we advocate at least 2 reviews would be required prior to a project launch. Having known platform operators would ensure a best effort is made to assist them, with a comprehensive industry insurance fund as a fallback in the worst case.