Deep Dive into the Hack and Scam DB
May 9, 2022 - We received some requests from our site users asking about the underlying meaning of the data fields in our database. In this post we will provide a breakdown on what they mean using the actual result from the Mad Meerkat Finance incident.
For the basic information section shown in the upper left, we provide the following:
Entity Name: Is the name of the entity impacted by the incident. This may be the common name of the project, protocol, or token, etc.
Date: Is the date when the incident was first recorded.
Status: Is set to Verified if the incident can be confirmed by at least one reputable source. Examples of reputable sources include mainstream blockchain security firms or mainstream media. Refer to Data Source for more discussion on how we set this status.
Count: Is the number of occurrences that the entity has been identified in our database. This metric is significant as the security posture of the organization can be inferred from repeated incidents.
Contributor: Is the identifier of the non-organizational person that provides the incident details through our contribution link. If we source the incident, we list our company name.
For the audit/KYC section shown in the upper right, we provide the following.
KYC By: Displays the names of firms that KYC'ed the entity. We verify if the listing exists.
Audit By: Shows the names of auditing firms that reviewed the smart contract(s). However, we do not confirm if the audit applicable to the incident as that narrative will be discussed in the Description of the incident.
It is important to note that not all entities will have complete information on all data fields. This may be due to many reasons including the loss of information in case of rug pulls where owners deliberately delete social and site information. In such cases, we indicate the data field with 'no data'.
The incident may or may not result in a financial loss. We provide the following:
Loss Amount: Is the approximate loss reported in dollars from the incident, if known. The loss amount does not account for any recovered amount. The actual loss may be more or less to this amount due numerous factors including the timing of the exploit, the price of the underlying tokens, valuation of the assets in case of NFTs, cross-chain impact, availability of information, etc. Unknown loss is reported as '-'.
Recovered Amount: Is the amount recovered from the incident. Examples of recovered amount can be observed with Colonial Pipeline or Poly Network incidents. Unknown or zero recovered amount is reported as '-'.
Currency: Displays the currency of the loss along with primary tokens that were involved in the incident. We do not list the tokens that the primary tokens were swapped into.
For the contact information section, we report the entity's web site, Twitter, Discord, Telegram, Medium handles and Github account identified at the time of incident reporting. For certain incidents (e.g., rug pulls), some handles may not be available as they have already been deleted by the time the incident is reported. However, under normal circumstances, these metrics offer important insights to the legitimacy of the project. Examples of how you can use them include:
For Github, contribution insight provides the extent of activities against a repository, as shown in the example below.
For Telegram, Discord, and Twitter, consider the joined date, numbers of followers, and tweet/post counts and frequency. Recent joined date should raise concerns as well as accounts that are not active with regard to the number of posts (not likes or tweet replies). Private (by invite only) Discord or Telegram should also raise a concern.
For Medium, look for consistent posts with updates related to the project. Developers who sincerely care about their project will take the time to communicate progress and share details.
In the Key Indicators section we apply standardized tags that are assigned by our analysts based on our review of the incident.
By using standardize the labels for these indicators, we can provide more concise analyses across all known incidents. This approach offer the end-users a comprehensive capability to dissect the data set to identify certain patterns, build models, etc. Please note that not all indicators are publicly available through the data set.
Platform: List the chain or project or the application relating to the incident. If multiple chains are impacted by the same incident, they are reported as such allowing the query to properly identify them.
Type: Is the generic classification of the entity. Hypothetically, if Uniswap was impacted, we tagged the incident as 'Protocol'. If Coinbase was impacted, we tagged the type as 'Exchange'.
Category: Lists the extended attributes related to Type. Using our Uniswap example, from previous, we tagged as 'Dexes', or in the case of Coinbase, we tagged as 'Assets'.
Method: Is the major method to which we classify the incident. Examples of methods include contract vulnerabilities, poor key management, scams, etc.
Extended Method: Provides the ability for our analysts to capture any additional details about the method. examples include the use of 'reentrancy attack', 'private key leak', 'phishing', etc.
Data Source: Provides links to authoritative links from which the details for the incident are gathered from. We consider the authoritative links in this order, starting from the impacted entity such as developers initial incident report or post-mortem, from secondary sources such as news and security company reporting, and lastly from tertiary sources (e.g., everything else). The further away from the entity will requires more data sources to set the incident status as 'Verified'.
The Description Tab provides a narrative of the event. We typically provide the following in this order:
What is the impact entity?
Core offerings or services provided by the entity
Type of incident and the method that was utilized
The amount in dollars lost from the incident
Supporting details such as who identified the incident
Any other interesting narratives observed by our analysts
The Lessons Tab highlights any key learning details as the result of the incident or similar incidents. Also include here are any immediate actions that should be taken by users to prevent possible losses of user funds.
The Attacker Info Tab provides onchain tracing details verified by us based on the incident to confirm the transactions. In certain cases, we may apply our expertise to provide more in-depth analyses using Breadcrumbs.app investigation tool.
The Others Tab displays additional information about the entity such as the entity's whitepaper and/or smart contract address(es), and specific access to KYC and audit reports if available.
That concludes our deep dive into the meaning of the metadata collected by Zero Friction's Hack and Scam DB. There are many interesting insights that can be obtained from our dataset. Check out some of our past insights here.