Hacking Incursions on DApps and Liquidity
Last updated
Last updated
Hacking can be denoted as an act of unauthorized access to privately-owned or identity-confidential data. Traditional hacking outside the cryptocurrency market has gained traction by the sheer notoriety and glamourization of the act itself. From that stemmed a plethora of movements aimed at preventing and consolidating the security facet of the related tech and/or application. It can be argued that the issue with cybersecurity in cryptocurrency has started to surface very recently despite the galore of hacks that started to sprout from early 2013.
Because of the relative ease of access and structurally different mechanism of work, the cryptocurrency market has become a vulnerable target for a range of sweeping attacks. Frequently, the main victims of such attacks are exchanges, liquidity providers or aggregators, and DeFi projects. These hacking intrusions have been growing exponentially in the last 5 years because of the substantial expansion of the cryptocurrency reach and the common ones include ransomware , scamming activity, phishing scams, and hacking of exchanges or wallets (Chainalysis 2019). The main vector of attacks can frequently be delineated in either internal flaws of the code or negligence of shared private keys. Indeed, the amount of cybercrime involving cryptocurrencies has grown via ransomware, scamming activity, phishing scams, and hacking of exchanges or wallets.
Exchange hacks are one of the most financially devastating types of hacks and traditionally incur losses over a wide field of parties involved: immediate participants and entrants of an exchange, reputational loss of exchange itself, and distrust of the cryptocurrency market in general. The available data is clear that the egregiousness of the attacks can get fairly out of hand. According to Chainalysis, More than 20b $ were illicitly gained access to or interacted within 2019 and 10b in 2020.
Normally, exchanges are shielded by a certain layer of protection that in most cases represents a typical tracing software or protocol that acts as an observer of fund flow. It can act on the risk posed by freezing a transaction and/or assess the individual risk of every incoming transaction by the set of proprietary algorithmic and dataset parameters.
In the case of unforeseeable events, there can be either a governmental involvement or a privately-owned cybersecurity investigation to trace suspicious fund transfers. The following happens when there is a suspicion about the hacking address involved:
The tracing starts from the known address
Following the address through up to a myriad of different addresses
Identifying the destination of the last address to hit an off-ramp service
Uncovering the identity of the perpetrator by issuing a subpoena to an above-mentioned service.
The problem with the chain of events above is the post-factum nature of it. Tracing can be beneficial in the spectrum of enacting enforcement of a law or in other words indictment of an individual behind the attack. Thus deanonymization becomes the core factor of the process. This arguably should not be the forerunning goal of the incident. Instead, there should be both preventative and reactive mechanisms in place in order to act on the attack immediately after it transpires or, in the best-case scenario, prevent it altogether.
There is a need then for a failsafe mechanism within the decentralized space that can vicariously or hand in hand execute a similar or supplementary role to the currently established centralized system of custody while eliminating the need to employ tight surveillance and deanonymization.
This can be fairly easily leveraged with the help of smart contract integration that records the inflow and outflow of addresses interacting within a given infrastructure. Each recorded address then can be granularly investigated either by an automatically embedded algorithmic system that employs various clustering techniques and factorial values or/and manually by a specifically designated group of individuals via a governance system. Various datasets are subsequently utilized to group and cluster transactions in different categories. The most basic categories might include dualistic representation of the nature of the transaction in the given time, namely “risky” and “non-risky”. The risky transaction is defined on the basis of previous activity of a given address and confluence of factors or datasets that contribute to that. For instance, a reputation scoring mechanism or RSP can be instituted in order to effectively and efficiently profile each address and endow it with the pertinent score. In this vein, “risky” transactions are considered risky because of a plethora of factors contributing negatively to the scoring.
Distinguishing a risk factor requires a meticulously crafted pattern recognition algorithm. This is crucial as to not misnomer a specific address that might engender a chain of unfortunate misconstructions. In order to achieve granularity, specificity, and accuracy to assign an address with, there is a need to query the history of past transactional activity. Concurrently, we need to find similarities and appropriately compare them to glean any results. Whereupon we can identify a propensity factor of the given address out of similarities found and infer that this address might in fact be a “risky” one. This is also a juncture where machine learning techniques might be handily used. Machine learning will significantly simplify the manual work needed for dataset provision and augment the future detection capabilities of the system. Transactions are analyzed based on the preemptively inputted set of quantifiable characteristics that are consequently also subclassified with the help of metrics. Machine learning will not only append to the dataset but also strengthen the accuracy of classification meaning a more robust automated system can be attained.
Per regulatory dialectics, there is a need to constantly revise, add or refine certain parameters in order to be congruent with unavoidable alterations. These alterations can include administrative decisions, compliance regulations, or even locally enacted laws. In this vein, a system is able to be fully customizable and tweaked on the fly to adapt to the regulatory instances of change. It is also mandatory to add a kind of DAO system in order to make the system decentralized, incentivized by communal decisions of the majority, or in other words, democratized, and malleable enough as to enable an ever-growing, self-subsisting body of decentralized autonomous regulations to be implemented and defined by community voting.
