# Identifying malicious accounts in Blockchains using Domain Names and
associated temporal properties

Rohit Kumar Sachan, Rachit Agarwal, Sandeep Kumar Shukla
CSE Department, IIT Kanpur
Email: {rohitks, rachitag<EMAIL_ADDRESS>
###### Abstract

The rise in the adoption of blockchain technology has led to increased illegal
activities by cyber-criminals costing billions of dollars. Many machine
learning algorithms are applied to detect such illegal behavior. These
algorithms are often trained on the transaction behavior and, in some cases,
trained on the vulnerabilities that exist in the system. In our approach, we
study the feasibility of using metadata such as Domain Name (DN) associated
with the account in the blockchain and identify whether an account should be
tagged malicious or not. Here, we leverage the temporal aspects attached to
the DNs. Our results identify 144930 DNs that show malicious behavior, and out
of these, 54114 DNs show persistent malicious behavior over time. Nonetheless,
none of these identified malicious DNs were reported in new officially tagged
malicious blockchain DNs.

###### Index Terms:

Blockchain, ML, Suspect Identification, Domain Name, Temporal properties

##  I Introduction

Cyber-criminals/attackers always explore new ways to perform malicious
activities over the Internet. Malicious activities are either socially
engineered (like Phishing, Spam) or exploit vulnerabilities in a system (like
hacks) with a motivation to either steal information, sabotage operations, or
corrupt the hardware/software to earn illegitimate revenue such as
cryptocurrency. Cryptocurrencies are based on blockchain technology, where
cyber-criminals leverage the anonymity aspects of the blockchain technology
for the malicious activities [1].

In the infrastructure supporting blockchain, especially permissionless
blockchains such as Ethereum, many organizations that are involved in cyber-
crime, create malicious distributed applications (dApps) and malicious
blockchain wallets (BCWs) that people sometimes use (deliberately or
accidentally) and get victimized. One such malicious activity is that of
Gambling which is illegal in many countries such as India. In Ethereum, dApps
are programs (commonly called Smart Contract (SC) that are written in ‘Turing
complete’ Solidity language), and BCWs are digital wallets (typically used to
store and manage cryptocurrency). Both dApps and BCWs have associated
addresses. The dApps and BCWs interact with other SCs, wallets, and other
externally owned accounts (EOAs - accounts owned by people or entities) to
perform illegal transactions [2]. Thus, it is highly desirable to efficiently
and effectively detect and report such dApps and BCWs and safeguard the
blockchain users.

Most of the related state-of-the-art malicious account detection techniques
include the transaction-based features [3, 4] or study vulnerabilities present
in the blockchain ecosystem [5]. Malicious dApps and BCWs, besides their
transaction behavior, have unique signatures where their metadata shows
different characteristics. Such metadata includes Domain Name (DN) and
associated Domain Name System (DNS) records (including IP address, IP prefix,
and NS address). DNs are human-readable alias names given to Internet-based
services running on IP addresses [6]. Thus, we ask, can such DN-related
information be helpful in the identification of malicious dApps and BCWs?
There are two ways to answer the above question (i) we include DN related
features in the current ML-based approaches and study the improvements, and
(ii) as DNs are associated with accounts, we only use DN related features, use
ML to identify malicious DN, and assume that the associated account is also
malicious. In this work, we only focus on the DNs and not on the transactions
of a particular dApp or a BCW to identify malicious dApps and BCWs. Note that
Ethereum provides an Ethereum Name Service (ENS) where users, including dApps
and BCWs can associate DNs to their addresses. The ENS domains are different
from traditional DNs as they do not have associated DNS records. In Ethereum,
Zedrun111Zedrun: https://zed.run/, Note that we have no intention to align any
transaction of with Zedrun, it is just an example for us. is an example of a
gambling dApp which does not have an ENS entry on Ethereum, but it has DN and
DNS records.

Nonetheless, in many cases, a malicious DN is algorithmically generated and
shows patterns. There are various state-of-the-art techniques to detect
malicious DNs. In [7], the authors present a survey of state-of-the-art
approaches (including blacklist-based and Machine Learning (ML) based
approaches) that detect malicious DNs. However, these methods have drawbacks.
Blacklist-based methods cannot adapt to the behavioral changes and capture any
hidden aspects. While ML-based techniques use various features, but in most
cases do not provide any information on whether their hyperparameters are
optimized. Nonetheless, it requires continuous monitoring of DNS traffic (DNs
request-responses and associated DNS records) from the behavior and social
perspective to detect malicious DN in a blockchain ecosystem. The state-of-
the-art algorithms do not use such temporal aspects.

This motivates us to include temporal features and non-temporal features in
the ML pipeline to detect malicious DNs and tag associated dApps and BCWs as
suspects. We call the identified malicious dApps and BCWs as suspects because
these accounts might not be officially tagged, but their features might show
behavioral similarity with the already marked malicious accounts. Here, we
first identify the temporal properties that exist by analyzing the temporal
behavior of the DNS traffic data. On top of the features that are lexical-
based, DNS query-based, host-based, and static graph-based, we introduce the
DNS traffic-based temporal features. These features are burst-based (such as
inter-event time burst and query frequency burst) and temporal graph-based
(such as changes in the degree and diameter of the underlying network formed
using IP address, NS address, and IP prefix associated with the DNS records).
Thus, including both temporal and non-temporal features in our study. Using
such a rich feature set, we only study the behavior of DNs over two different
temporal (2 hr based and 1 month based) granularities. The reason for such a
choice is the computational resources available to us. Using the feature set,
we study both supervised and unsupervised ML algorithms for completeness. Our
approach using supervised learning is able to detect malicious blockchain DNs
with 89.53% balanced-accuracy and all malicious DNs (including malicious
blockchain DNs) with 81.52% balanced-accuracy. While when using unsupervised
learning, our approach detects 144930 DNs that show malicious behavior at
least once in a given temporal granularity and 54114 DNs that show persistent
malicious behavior but are not marked.

With respect to the blockchain technology, to the best of our knowledge, ours
is the first work that identifies the significance of temporal aspects of DNs
and analyzes them to detect suspect BCWs and dApps in a blockchain. In
summary, our core contributions through this work are:

  * •

Comparative study: We present a comparative study of the various state-of-the-
art techniques used towards detecting the malicious DNs. Here we present the
features the use, what they detect, ML algorithms they use, what dataset they
use, issues with their approach, hyperparameters of the used ML algorithms,
and reported performance.

  * •

Features: We identify the feature vector that includes temporal and non-
temporal features. The temporal features are based on the time-series analysis
of the DNS traffic data and are based on burst, degree, and diameter.

  * •

Behavior analysis: We analyze the temporal behavior of the malicious DNs,
benign DNs, and malicious DNs associated with the blockchain and apply ML-
based approach to detect malicious DNs. We find that DecisionTree performs the
best in terms of balanced-accuracy for our dataset. Our approach, based on
Unsupervised ML algorithm, reports 54115 DNs that are not marked as malicious,
but their behavior is similar to the malicious DNs. These DNs were also not
present in the new list of malicious DNs that were identified between 30st
October 2020 and 7th April 2021. Nonetheless, we cannot identify which DNs are
associated with accounts present in a blockchain due to security reasons.

The rest of the paper is organized as follows. In Section II, we present the
state-of-the-art works related to the detection of malicious DNs using DNS
traffic data. In Section III, we present our methodology and followed by in-
depth evaluation along with the results in Section IV. We finally conclude in
Section V.

##  II Related Work

This section discusses the state-of-the-art approaches that target the
identification of malicious DN using ML algorithms. Based on our survey on
different state-of-the-art techniques to detect malicious DNs, we identify
that no approach targets blockchain accounts and uses temporal features
associated with DNs of the dApps and BCWs. They talk about DNs in general.
Generally, the state-of-the-art techniques mainly use features extracted after
studying either DN strings, underlying static graph, or DN query.

Analysis of substrings present in a DN is one of the most popular way to
classify it as malicious. In [8], the authors present an ML-based model to
detect DNs associated with botnets. The model uses statistical characteristics
extracted using N-grams and the vowel distribution characteristics in a DN.
N-gram is a Natural Language Processing (NLP) concept where a string is
segmented into substrings up to length N. Then, the weights of each substring
is calculated based on the frequency of occurrence of each substring. This
approach has a drawback. In N-grams, the number of features increases
exponentially with respect to ‘N’. To overcome such an issue, in [9], the
authors propose a masked N-Gram approach where symbols substitute each
character, i.e., character ‘c’ replaces all consonant, ‘v’ substitute all
vowels, ‘n’ substitutes all digits and ‘s’ substitutes all others characters
in the given string. Such substitution reduces the number of features
significantly. In many cases, attackers use algorithmically generated DNs to
avoid detection by such N-gram-based techniques. In [10], the authors present
an ML-based approach to detect such malicious DNs that are algorithmically
generated (mainly using a Domain Generation Algorithm (DGA)). The approach
uses lexical and statistical features (such as N-gram and character occurrence
frequency in DNs). In follow-up work, in [11], the authors present an ML-based
method for detecting the malicious Word-list-based DGA DNs based on lexical
and network-based features (such as created since, updated since, registrar,
and Time-to-Live (TTL)).

Besides algorithmically generated DNs, attackers use the concept of changing
IPs (i.e., IP-Flux or Fast-Flux) to perform malicious activities such as
phishing [12]. Such DNs are hard to detect. In [13, 14], the authors present
an ML-based approach to detect malicious Fast-Flux DNs that use features (like
short TTL and the high number of resolved IPs) available from the passive DNS
traffic data. In another approach, in [15], the authors detect malicious DNs
that are DGA generated and have Fast-Flux behavior after analyzing the DN
strings and the associated DNS query records. In a similar work, in [16],
authors present an ML-based method to classify a Fast-Flux-based DN as
malicious or benign. Their approach uses an extended feature set (i.e., uses
features such as the number of resolved IP address, the minimum value of TTL,
entropy of prefixes, entropy of sub-domains, stability of IP address pool, the
time between first seen and last seen) to improve the confidence interval to
95%. In [17], the authors present an URL-based malicious DNs detection system.
Their system uses DN-based features and DNS query-based features. They study
past DNS activities of each DN and explore the difference between the physical
behavior of benign and malicious DNs.

Many approaches also assign a reputation score to classify a DN as malicious
or benign. In [18], the authors use an N-gram concept to calculate the
reputation value of a DN. They calculate the reputation value of a DN based on
its weight value in the DN’s substrings. The algorithm marks all the DNs whose
reputation value is above a threshold as malicious DN. Similarly, in [19], the
authors present _Notos_ , a dynamic reputation system for DNs. Notos assigns a
low reputation score to a malicious DN based on the characteristics of the
malicious DN that include resource provisioning, usages, and DN management. In
[20, 21], the authors present _Exposure_ , which assigns a reputation score
based on the analysis of passive DNS data for detecting the malicious DNs.
Exposure identifies behavioral differences between benign and malicious DNS
based on time-based features (lifetime, repeating patterns), DNS answer-based
features (unique IP addresses and countries, number of DNs associated with an
IP), TTL value-based features (unique TTL, number of TTL changes), and DN-
based features (string-based) that exists in the DNS traffic data. Both Notos
and Exposure need initial IP reputation. However, in cases when such
reputation is not present, both Notos and Exposure fail to perform. To
overcome this issue, in [22], the authors present _Kopis_ that monitors the
DNS traffic between the top-level domains (TLD) and authoritative name servers
(AuthNSs).

Other malicious DN detection systems use graph data structure (i.e.,
underlying associated DNS graph). These systems use graph properties, node
connectivity, and edge association to identify malicious DNs. In [23], the
authors propose an ML-based approach to obtain labels of the DNs based on the
features selected from graph components by monitoring the malicious DNS
traffic. In another work [24], the authors present a non-ML malicious DNs
detection approach using the DN-resolution graph. The approach assumes that if
a DN is strongly associated (connected) with a known malicious DN, it will
likely be malicious. In [25], the authors present _Segugio_ , a malware-
control DN system. It closely monitors the DNS query behavior of malware-
infected machines and builds a machine-domain bipartite graph that represents
‘who is querying what’. It detects the previously unknown malware DNs based on
the query behavior of DNs. In [26], the authors construct a DNS graph between
DN and IP address for only A-records and use connectivity between DNs and
malicious DNs to tag DNs as malicious. Their performance purely depends on the
association/link with known malicious DNs.

Note that all the above ML-based techniques have inherent data imbalance
problems. The number of malicious DNs is low as compared to benign DNs. In
[27], the authors present the _HAC_EasyEnsemble_ -based model to overcome the
data imbalance problem. This model extracts static lexical features and
dynamic DNS resolving features to profile every DN from the DNS traffic data.
In [28], the authors also address the imbalance problem and present a
_KMSMOTE_ method that uses SMOTE and K-Means clustering algorithm. The system
uses assumptions such as malicious DNs leave their traces on DNS traffic,
malicious DNs have lower DN registration cost, and reuse network resources.

In general, the ML-based approach to detect malicious DNs have high time
complexity. In [29], the authors present a method to detect malware DNs using
Extreme Learning Machine (ELM) to improve time complexity. ELM is new, fast
learning, and highly accurate Neural Network (NN) scheme for Single-hidden-
Layer Feed-forward NNs (SLFNs).

We summarize these state-of-the-art techniques in more detail in Table I.
Here, we report the features that these approaches use, what they detect,
which ML algorithms they test, what dataset they use, and the issues these
approaches have. In Table II, we report the hyperparameters of the ML
algorithms that these approaches have used along with the reported
performance. Most of the state-of-the-art approaches use the supervised
learning method and do not report the hyperparameters they use to train the
learning algorithms. We also observe that all the state-of-the-art approaches
use features that do not capture the temporal behavior of DNS data. To the
best of our knowledge, none of the approaches uses temporal (or time series)
features and do not target identifying malicious dApps and malicious BCWs
using DNs.

TABLE I: Features used in related studies

# | B/C | Features Used | Detection | ML Algo. | Datasets | Issues
---|---|---|---|---|---|---
N | Q | G | T | O | Of | Tackles | Sources used | Size
[8] | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | BT | - | KNN, C4.5, | [30, 31, 32] | 60K |
RF, NB | Only based
[9] | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | AG | - | RF | [30] [33] | 64K | on
[10] | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | AG | - | C5.0, GB, | [30, 31] | 51K | string analysis
RF, CART, |
KNN, SVM |
[11] | ✗ | ✓ | ✗ | ✗ | ✗ | ✓ | AG | - | KNN, GB, RF, | [30, 31, 34] | 40K | Based on limited
CART, C4.5, | DGA based
NB, C5.0 | DNs
[13] | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | FF | - | C4.5 | American ISP | 2.5B | Limited to fast-flux,
IP and TTL based
[14] | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | FF | - | C4.5 | Security Info. | ✗ | Based on local
Exchange | RDNS traffic
[15] | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | FF, | - | C5.0, BC, NB |  [35, 36], | 40M | No mention of
AG | [37, 38] | evolution of DNs
[16] | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | FF | - | RF |  [30, 39, 40], | 5.4M | Only based on
[41, 42], | n/w and IP
[38, 37] | based features
[17] | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | - | R | C4.5 | [30, 43, 44] | 10K | Considers only spec-
ific types of DNs
[18] | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | - | R | Heuristic |  [30, 45, 31], | 21K | Features only
[32, 35] | based on N-Gram
[19] | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | - | R | LBS | [30, 41, 38] | 1.4M | Needs a lot of
history
[20]+ | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | - | R | C4.5 |  [30, 32, 41], | 4.8M | Rely on passive
[21] | [46, 42, 38] | RDNS traffic
[22] | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | - | R | RF, NB, KNN, | [30, 46, 38] | 100K | Scaling to large n/w
SVM, RC | and real-time system
[23] | ✗ | ✗ | ✓ | ✓ | ✗ | ✓ | - | L | K-Means | ISP Denmark | ✗ | Focus on ground-
truth labeling
[24] | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | - | - | Heuristic | [30, 47] | 54K | Based on intuition
[25] | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | - | - | Heuristic | [30, 41] | 10M | Slows down n/w
[26] | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ | - | - | Heuristic | [30, 31, 44] | ✗ | Based on intuition
[27] | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | - | DI | EEA, |  [30, 39], | 10K | Focus only on data
HAC_EEA | [48, 46] | imbalance
[28] | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | - | DI | CatBoost, SVM |  [30, 49, 43], | 16K | Oversampling
GBDT, XGBoost | [41, 50, 34]
[29] | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | APT | EI | ELM, LR, SVM, |  [30, 41], | 40K | Only for
CART, BPNN | [42, 34] | targeted attacks
Ours | Eth | ✓ | ✓ | ✓ | ✓ | ✗ | - | - | K-Means, 11 |  [49, 51, 33], | 335M | -
ML Algos |  [52, 44],
using TPOT | [53, 42]

  * •

$\bullet$ B/C Blockchain, Eth Ethereum Blockchain data, $\bullet$ Features: N
DN String based, Q DNS Query based, G DNS Graph based, T Temporal aspect
based, O Other, ${}^{\text{\char 55}}$ particular feature not used, $\bullet$
Detection Of: AG Algorithmic Generated Names, BT Botnet, FF Fast-Flux, APT
Advance Persistent Threats, - no specific mention but targets DNs in general,
$\bullet$ Tackles: R Reputation, L Ground Truth Labeling, DI Data Imbalance,
EI Efficiency Improvement, - no specific mention, $\bullet$ ML Algo: GB
Gradient Boosting, SVM Support Vector Machine, RF Random Forest, KNN K-Nearest
Neighbors, NB Naive Bayes, BC Bayesian Classifier, LBS Logit-Boost Strategy,
RC Random Committee, EEA EasyEnsemble Algorithm, ELM Extreme Learning Machine,
GBDT Gradient Boosting Decision Tree, XGBoost eXtreme Gradient Boosting, LR
Logistic Regression, BPNN Back Propagation Neural Networks, $\bullet$ Dataset
Size: ${}^{\text{\char 55}}$ no mention, $\bullet$ Issues: DGA: Domain
Generation Algorithm, RDNS Recursive DN System, n/w: network, IP: IP address

TABLE II: Hyperparameters and Performance in related studies

# | ML Algo. | Hyperparameters | Reported Performance (%)
---|---|---|---
Used | Best | Accuracy | Precision | Recall | F1 | TPR | FPR | Other
[10] | C5.0 | - | - | 97.04 | - | - | - | - | - | 94.08K
GBM | - | - | 96.44 | - | - | - | - | - |  92.87K
RF | - | - | 96.63 | - | - | - | - | - |  93.26K
CART | - | - | 96.27 | - | - | - | - | - |  92.55K
SVM | - | - | 96.71 | - | - | - | - | - |  93.41K
KNN | - | - | 94.99 | - | - | - | - | - |  89.99K
[19] | LBS | - | - | - | - | - | - | 96.80 | 0.38 | -
[22]$\dagger$ | RF | - | - | - | - | - | - | 98.40 | 0.50 | -
NB | - | - | - | - | - | - | - | - | -
KNN | - | - | - | - | - | - | - | - | -
SVM | - | - | - | - | - | - | - | - | -
RC | - | - | - | - | - | - | - | - | -
[20, Exposure-bilge2014exposure] | C4.5 | - | - | - | - | - | - | - | 7.90 |  98.00DR
[11] | KNN | - | - | 96.50 | - | - | - | - | - |  95.32K
GBM | - | - | 97.89 | - | - | - | - | - |  97.19K
C4.5 | - | - | 97.56 | - | - | - | - | - |  96.75K
C5.0 | - | - | 98.08 | - | - | - | - | - | 97.44K
CART | - | - | 82.30 | - | - | - | - | - |  76.40K
RF | - | - | 98.02 | - | - | - | - | - |  97.37K
NB | - | - | 77.58 | - | - | - | - | - |  70.11K
[8] | KNN |  k $\in$ [1, 20] | 15 | 87.70 | - | - | 86.70 | 80.40 | 5.00 |  94.10DR
C4.5 | - | - | 87.60 | - | - | 86.70 | 80.90 | 5.70 |  93.40DR
RF |  T $\in$ [5, 50] | 27 | 88.10 | - | - | 87.20 | 80.90 | 4.80 | 94.40DR
NB | - | - | 86.00 | - | - | 86.40 | 89.10 | 17.10 |  83.90DR
[24] | Heuristic | - | - | - | - | - | - | 95.00 | 0.50 | -
[27] | HAC_EEA | - | - | 96.32 | 95.17 | - | 95.74 | - | - | -
EEA | - | - | 93.58 | 93.38 | - | 93.47 | - | - | -
[17] | C4.5 | - | - | - | 85.20 | 69.90 | 76.80 | 69.90 | 13.80 |  77.50DR
[13] | C4.5 | - | - | - | - | - | - | - | 0.70 |  99.30DR
[14] | C4.5 | - | - | - | - | - | - | - | 0.15 |  99.30DR
[25] | Heuristic | - | - | - | - | - | - | 95.00 | 0.10 | -
[9] | RF | - | - | 98.73 | - | - | - | - | - |  97.47K
[29] | ELM | - | - | 96.28 | - | - | - | - | - | -
LR | - | - | 91.95 | - | - | - | - | - | -
CART | - | - | 91.83 | - | - | - | - | - | -
BPNN | - | - | 95.82 | - | - | - | - | - | -
SVM | - | - | 94.70 | - | - | - | - | - | -
[15] |  C5.0$\ddagger$ | - | - | - | - | - | - | - | - | -
BC | - | - | 85.00 | - | - | - | 81.00 | 11.00 | -
Naive-BC | - | - | 87.00 | - | - | - | 82.00 | 8.00 | -
[23] | K-Means | - | - | 73.48 | 72.41 | - | - | 52.69 | 13.02 | -
[26] | Heuristic | - | - | 98.30 | 99.10 | 98.60 | - | - | - | -
[16] | RF | - | - | 98.79 | 99.86 | - | - | 94.52 | 0.13 |  2.19FNR
[28] | CatBoost | - |  | 98.42 | 99.26 | - | 98.38 | - | - |  52.518srTime
SVM | - | - | 94.84 | 95.08 | - | 96.41 | - | - |  174.564srTime
GBDT | - | - | 94.78 | 95.07 | - | 95.07 | - | - |  94.912srTime
XGBoost | - | - | 94.81 | 95.07 | - | 96.39 | - | - |  89.074srTime
[18] | Heuristic | - | - | 94.04 | - | - | - | - | 6.14 |  7.42FNR

  * •

TPR True Positive Rate, FPR False Positive Rate, FNR False Negative Rate, TNR
True Negative Rate, DR Detection Rate, rTime Running Time, TO Time Overhead, K
Kappa Comparison, - no mention, † only mentions for the best case, ‡ no
results shown

##  III Methodology

We follow a standard ML pipeline that includes the following main processing
steps: data collection, data pre-processing (cleaning, enrichment, and ground
truth labeling), feature engineering (feature extraction and selection), ML
algorithm (supervised and unsupervised), and evaluation. This section mainly
focuses on the data pre-processing, feature engineering, and application of ML
algorithm steps.

###  III-A Data Collection and Pre-processing

In blockchains, meta-information associated with dApps and BCWs is highly
limited. On top, in Ethereum, extraction of DNs associated with dApps and BCWs
is not easy. Etherscan and other blockchain explorers provide APIs to extract
transaction data of accounts present in Ethereum. Further, very few accounts
are labeled to be involved in malicious activity. Due to such limitations, we
evaluate our approach using DN data available from multiple public sources
such as [49, 51, 33, 52, 44, 53, 42]. Note that [51, 52] provides a limited
list of malicious DNs present in the Ethereum Blockchain, while [49] provides
us with the DNS records for the DNs over time. [33, 44, 53, 42] provides us
the ground truth labels for the malicious DNs.

A DNS query record of [49] typically contains 105 fields per record. However,
we only consider those fields that are useful for us. These include _query_
(or the DN), _query type_ , _response type_ , _response name_ , _TTL_ (Time-
to-Live), _timestamp_ , _RTT_ (Round-Trip-Time), _IP Address_ (IPv4 and IPv6),
_country_ , _IP prefix_ , _CNAME_ (Canonical Name), _DNAME_ (Delegation Name),
_MX Address_ (Mail Exchange), _NS Address_ (Name Server), and _TXT Records_.
We clean this data by removing the records in which information about either
TLD (top-level domain extracted from the query/DN) or timestamp is missing. We
also remove the strings like ‘www.’ and ‘http’ from the DN of the DNS query.
After cleaning, we enrich our data by labeling each DN as malicious or benign.
The labels or the ground truth information about the DNs is extracted from
[51, 33, 52, 44, 53, 42].

In the pre-processing stage, we segment the DNS record data based on different
temporal granularities that range from hours to months to identify behavioral
changes. Due to computational resources available to us, we currently only
validate our approach on two temporal granularities ($T_{G}$): 2 hour ($2H$)
and All ($ALL$). In a $2H$ temporal granularity, the entire data $D$ is
segmented into multiple data segments of 2 hours each. For example, if the
entire data is of 1 month (duration $T$ hours), we have
$\approx$1$\times$30$\times$12 data segments. In $ALL$ granularity we use
entire data instead of segmenting it. Note that a data segment in the $2H$
granularity is not a static snapshot, but the features present in the feature
vector are both temporal and static. Here, 2-hour granularity provides fine-
grain results and is able to capture highly dynamic behavior.

###  III-B Feature Engineering

We use temporal (i.e., time-series based) and non-temporal (i.e., non-time
series based) features to understand the actual behavior of a DN before we
classify it as malicious or benign. We extract all the non-temporal features
(described next) from the DNs using string-based analysis and DNS
query/response information given in DNS traffic records during feature
engineering. The temporal features (such as _burst_ , _degree_ , and
_diameter_ also described next) are the time-dependent features reflecting the
changes. The analysis of the DNS traffic data enables the identification of
such features.

Thus, our set of features ($F$) is based on both non-temporal (that comprise
of string-based features ($F_{s}$) and DNS query-based ($F_{q}$) features) and
temporal features (that comprise of burst-based features ($F_{b}$) and
temporal graph-based ($F_{g}$) features). In details, these features are:

  * •

Non-Temporal features: The string-based features ($F_{s}$) and DNS query-based
($F_{q}$) features are mainly extracted using the lexical and statistical
analysis. These features are directly derived from the DN string and DNS
traffic records.

    * –

String-based features ($F_{s}$): are useful to detect the malicious DN that
are algorithmically generated by a Domain Generation Algorithm (DGA) or follow
specific string patterns. These patterns are generally identified after
performing the lexical and statistical analysis. From the analysis, we
identify features such as the length of the DN, number of digits in the DN,
number of unique digits in the DN, number of characters in the DN, number of
unique characters in the DN, number of symbols in the DN, number of vowels in
the DN, number of consonants in the DN, number of unique alphanumeric
characters, and the ratio between the number of unique alphanumeric characters
and the total length of the DN. Note that we do not use the N-gram-based
features due to the limited computation power we have.

    * –

DNS Query-based features ($F_{q}$): are useful for identifying malicious DNs
as there are significant differences between DNS traffic footprints of a
malicious DN and a benign DN. With respect to static features, we extract
features such as the ratio between each of the unique _query types_ ,
_response type_ , _response name_ , _counties_ , _IP prefix_ , _CNAME_ ,
_DNAME_ , _MX Address_ , _NS Address_ , _TXT Records_ , _IPv4_ , _IPv6_ and
respective total count value from the specific DNS query records of a DN.
Apart from these ratios, other features includes the number of unique _TTLs_ ,
minimum TTL, maximum TTL, average TTL, standard deviation in TTL, number of
unique _RTTs_ , minimum RTT, maximum RTT, average RTT, standard deviation in
RTT, total number of unique IP addresses (sum of number of IPv4 and IPv6
addresses), number of unique _IPv4 addresses_ , and number of unique _IPv6
addresses_ associated with a DN.

The DNS traffic data is temporal data. Thus, we extract a temporal graph
($g^{t}_{i}(V^{t},E^{t})$) at time $t$ representing the connections between
the DN ($i$) and the associated IPs. Let the set of such temporal graphs be
$G$. Here, $V^{t}$ is a set of nodes such that a node represents a type $\in$
_{ DN, IPv4 address, IPv6 address, NS address, IP prefix}_ and $E^{t}$
represents a set of link/edge between the nodes in $V^{t}$. At each $t$, we
create temporal graphs and extract properties such as _Diameter_ , _Degree_ ,
and their _changes_ (these features are described next). Note that these
features are derived from the time series analysis of the DNS traffic record.
The overall notion of the temporal features is illustrated in Figure 1. Here,
the figure represents the DNS queries for a particular DN. These queries are
fired at different times where the difference between the two consecutive
timestamps is represented by inter-event time $\Delta t$. At each time
instance, there could be multiple DNS queries (query frequency). Further, the
DNS queries could be consecutive and span over time. A $g^{t}_{i}$ is computed
using all the DNS queries at a time $t$ and has properties such as degree and
diameter. Next, we explain the different temporal features (query frequency
burst, query inter-event burst, degree of DNS query, and diameter of DNS
query) that we derive.

Figure 1: Concept of temporal features

  * •

Burst-based features ($F_{b}$): A burst is defined as a temporal non-
homogeneous sequence of DNS queries. We consider two types of bursts (query
frequency burst (fB) and query inter-event burst (iB)). Both bursts are
derived from the temporal analysis of the DNS traffic data.

    * –

Query frequency burst (fB): represents the number of DNS queries at a
particular time instance. If the number of queries at a particular time is
above a threshold (i.e., 80% of the maximum number of queries of a DN during a
time frame), then it considers as a candidate of frequency burst. From the
analysis of candidates, we formulate burst features such as the number of
frequency bursts of a DN, maximum size of frequency bursts of a DN, average
frequency burst of a DN.

    * –

Query Inter-Event Burst (iB): refers to a continuous sequence of DNS queries
where the inter-event time is very small. The DNS queries that were
continuously made, up to a certain threshold (i.e., more than 80%), their DNs
are considered as a candidate of the inter-event burst. From the analysis of
candidates, we define features such as the number of inter-event bursts of a
DN and the maximum size of an inter-event burst of a DN.

Figure 2: Our Methodology

  * •

DNS graph-based features ($F_{g}$): These features are directly derived from
the temporal graph ($g^{t}_{i}$) of a DN ($i$). These are useful to identify
the malicious DNs based on the association and connection between the elements
of the DNS network.

    * –

Degree ($d$): In $g^{t}_{i}$, degree represents the number of edges that a DN
($i$) has. It is helpful to understand whether the malicious DN changes their
associated IPs frequently. Here, we consider features such as the ratio
between the number of times degree changes and total time instance the DN
appeared and the ratio between total degree change and total time instance.
Assume that a DN’s change in degree over time is represented by a vector (2,
0, 0, 2, 1, 2), then the two above-mentioned feature values are 4/6 and 7/6,
respectively. Apart from these two ratios, we also consider the maximum degree
and minimum degree of a DN as degree features.

    * –

Diameter ($D$): is useful to detect malicious DNs based on their association
with others. It represents the largest shortest path of the component in which
the DN exists. From the analysis of this component, we formulate features such
as the maximum diameter of a DN, the minimum diameter of a DN, and the number
of times diameter changes during the time frame.

After the feature extraction, as the features might be correlated and may not
reflect much importance, we select the features based on the Pearson
correlation. Here, we remove those features for which the Pearson correlation
value is high.

###  III-C ML Algorithm

After the feature engineering process, we apply supervised and unsupervised ML
algorithms to different data segments generated at different temporal
granularities. This helps us analyze the behavior of DNs and identify the DNs
which show persistent suspicious behavior over time. Most of the ML algorithms
used in the state-of-the-art approaches are supervised ML algorithms. Thus, to
validate and test which supervised algorithm performs best in classifying
malicious DNs, we use AutoML tool called TPOT [54]. Here, we configure TPOT to
use the supervised algorithms and their set of hyperparamters as reported by
state-of-the-art algorithms as well validate other sets of hyperparameters
because it may enhance the overall results. Note that we use default
hyperparameters as set by the used python library in the case where the state-
of-the-art approaches do not report hyperparameters. We report balanced-
accuracy, Precision, Recall, and F1-score for the supervised case. We apply
supervised algorithms only on _ALL_ data granularity. This reduces our search
space to stay within the limits of the computing power available to us.

Further, we also use unsupervised ML algorithms to validate our approach.
Here, to test, we only use the K-Means clustering algorithm due to the
availability of computing resources and use hyperparameter K$\in$[30, 100]
(for _ALL_ granularity) and K$\in$[7, 24] (for _2H_ granularity). Our choice
(range on K) is based on the size of data. For the best number of clusters
identified using silhouette score, we select the cluster where most malicious
DNs are. We then identify the benign account within the selected cluster that
shows high similarity (similarity$\rightarrow$1) with the malicious account.
Here, to calculate the similarity, we chose cosine similarity as it is widely
adopted. We acknowledge that there are other types of similarity measures, and
with the use of different similarity measures, the results might change. But
for this work, we chose cosine similarity simply because it is widely used and
accepted. In the case of _2H_ , we repeat the same process for each data
segment and determine the behavior of DNs based on the probability, which is
calculated as the fraction of the number of times a DN shows malicious
behavior over the total number of times the DN occurs.

(a) Distribution of Query Frequency of individual DNs

(b) Distribution of Query Frequency of all DNs combined

Figure 3: Distribution of Query Frequency

In summary, our methodology is illustrated and summarized in Figure 2. It
shows the standard ML pipeline that includes key processing steps: pre-
process, validation of temporal behavior, feature constructor, and ML
algorithms. The collected dataset is organized into two temporal
granularities: 2H and ALL. During pre-processing, data is cleaned by removing
the noisy records and labeled using the malicious datasets. The time-series
data is extracted from the desired fields and processed to generate different
features. Next, to understand temporal behavior that exists, we validate it on
different data segments representing different temporal granularities. Time-
series and non-time series features are constructed from the respective
datasets. Finally, a complete feature vector is formed by merging both time-
series and non time-series features and is passed to the ML algorithms.

##  IV Evaluation and Results

We evaluate our approach on the publicly available Cisco Umbrella top 1
million dataset [49] for January 2020. All evaluations are performed using
Python v3.8.3 within the Python environment with supporting libraries such as
pandas v1.1.3, numpy v1.18.5, pickle v4.0, matplotlib v3.2.2, and tldextract
v2.2.3. With respect to computational resources, we test our approach on a
machine with Intel(R) Core(TM) i7-9700<EMAIL_ADDRESS>GHz with 64.00 GB RAM.

###  IV-A Dataset

_Cisco Umbrella top 1 million dataset_ [49] for the month of January 2020
contains 361 sub-datasets of $\approx$2 hours each. For January 2020, there
are $\approx$335 Million DNS queries and out of these, only $\approx$1.77
Million are distinct queries because dataset has multiple entries for a query
in dataset with different DNS records. Note that we consider only January 2020
data due to the limited computing power available to us. For the malicious
tags/labels, we use DGA dataset [33], Phishtank [42], Openphish [53],
Cryptoscam blacklist [51], Ethereum wallet dark list [52] and Malware DN list
[44]. DGA dataset has $\approx$88 Million malicious DNs on 07th January 2019.
The total number of malicious DNs extracted from sources other than DGA is
31985. Out of these, 14706 are unique TLDs (top-level domains). In the
complete dataset, there are only 87557 malicious DNs, out of which 41991 DNs
are present in different blockchains such as Ethereum. Note that these 41991
malicious DNs are tagged as of 30st October 2020. We also use a new list of
unique 2479 malicious blockchain DNs [51, 52] as of 7th April 2021 and used it
to validate our results.

###  IV-B Validation of Temporal aspects and importance of a feature

For validation of temporal aspects, on the complete dataset, we analyze the
behavior of temporal features present in malicious DNs, benign DNs, and
malicious DNs in a blockchain. Although more refined, the _2H_ granularity has
very limited data and variation. In the following discussion, we represent
malicious DNs present in a Blockchain as MBC.

To validate the existence of the _query frequency bursts_ , we study the
distribution of the number of queries made (or the query frequency) for each
DNs (cf. Figure 3a where a different color represents a different DN). We also
study the distribution of query frequencies per class computed considering all
individuals as one under that class (cf. Figure 3b). Figure 3a shows a bursty
_query frequency_ where very few DNs have a high query frequency (more than
100) while most of the other DNs have a low query frequency (less than 100).
Similarly, when analyzing the differences between DNs those belong to benign
(B), malicious (M), and MBC class, we identify that the probability
distribution of query frequency follows an exponential distribution with
$x_{min}$=1.0 and $\lambda$=$\\{0.1313,0.0958,0.1267\\}$, respectively. Here,
we observe that the distributions for B and MBC are relatively similar. To
identify how similar they are, we use the KL Divergence (KLD). A KLD=0
signifies that the two distributions are similar, while a KLD$>$0 signifies
that the two distributions diverge. In our case, between the distributions for
B and MBC class, KLD is 6.28$\times$10-4. From this, we infer that the two
classes have differences, and query frequency bursts can be used as a feature.

(a) Distribution of Inter-Event Time in millisecond of individual DNs

(b) Distribution of combined Inter-Event Times in millisecond

Figure 4: Distribution of Inter-Event Time

For an inter-event time, in Figure 4, we also observe the existence of a
burst. Here, Figure 4a shows that for a very large number of DNs the maximum
inter-event time $<$104, while a very few DNs have a very high (maximum
$>$108) inter-event time. Note that as we show distributions of the individual
(represented by a different color) inter-event times, these distributions have
different minimum and maximum values resulting in a visual disconnect (i.e.,
absence of inter-event times for certain values). Similarly, for the B, M, and
MBC cases, the probability distribution of inter-event time is shown in Figure
4b. Here, on the entire data due to diversity in $x_{min}$ and $x_{max}$
values for each DNs the studied distributions had a large Kolmogorov-Smirnov
(KS) distance. Nonetheless, out of the studied distributions, truncated-
powerlaw provided the best fit. For the truncated-powerlaw distribution, for
the two classes (B and M), $x_{min}$=1000 millisecond and a cutoff parameter,
$\beta$=$\frac{1}{\lambda}$ where
$\lambda$=$\\{1.1563$$\times$$10^{-9},9.6612$$\times$$10^{-9}\\}$, while for
MBC exponential distribution was the best identified fit with parameters
$x_{min}$=1000 and $\lambda$=$1.1505$$\times$$10^{-8}$. The whole notion of
distribution fit is dependent on the sample space (more specifically, the
range of ‘x’ ($x_{min}$ and $x_{max}$) in which the distribution is studied).
Choosing $x_{min}$=5000 and $x_{max}$=$10^{7}$, we identify that exponential
distribution with parameter values $\lambda$=3.9897$\times$10-7 for M,
$\lambda$=4.3806$\times$10-7 for B, and $\lambda$=4.2957$\times$10-7 for MBC
fits the best. Thus, this feature can also be an indicator.

(a) Distribution of Degree of individual DNs

(b) Distribution of Degree of all DNs combined

Figure 5: Distribution of Degree

Next, we identify the behavior of the degree present in the data by analyzing
the change in degree over time. First, we analyze the degree distribution plot
(cf. Figure 5) and then the degree change distribution plot (cf. Figure 6 and
7). Figure 5a shows the variations in the degree of each DN. Here, we observe
that _(i)_ very few DNs have a degree $>$100 while most of the other DNs have
a degree $<$10 (thus, showing a bursty behavior) and _(ii)_ for most of the
DNs, change in the degree exists as their degree range $\in[1,100]$. The
distribution plots of the DNs with respect to their types follows a positive
log-normal distribution with $x_{min}$=1.0,
$\mu$=$\\{0.7719,0.8106,1.3198\\}$, and $\sigma$=$\\{1.6206,1.2229,1.3250\\}$
for M, B and MBC classes, respectively. Here, KL divergence between M and B is
$0.0970$, M and MBC is $0.1321$, B and MBC is $0.07994$. Further, we also
observe that the maximum degree for B is $>$1000 while that for M and MBC
types is $\approx$500 and $\approx$300, respectively. Similarly, Figure 6
shows the distribution of the change in degree for each DN. As discussed
before, a change is a difference between degree values in consecutive time
instances. However, if the degree reduces, we do not consider it as a change.
From Figure 6, we observe that very few DNs show a change $\geq$70 while most
of DNs have a change that is $\leq$10\. We also observe that no DN has a
change $>$100.

We then analyze the behavior differences between M, B and MBC type of DNs in
terms of the number of instances in which a degree change was made (cf. Figure
7a) and the total number of such changes made (cf. Figure 7b). In the case of
number of instances in which a degree change happened, we find that for each
DN the distribution again showed a bursty behavior. When analysing particular
classes of DNs, we find that the distribution for each class (B, M, and MBC)
follows a truncated-powerlaw distribution with $x_{min}$=1.0,
$\alpha$=$\\{1.0001,1.6838,1.0001\\}$ and
$\lambda$=$\\{0.0404,0.0245,0.0264\\}$. We also find that the maximum number
of degree changes made at any instance for B is $\approx$90, while for both M
and MBC it is $\approx$80\. Similarly, in case of total number of degree
changes made, we find that positive log-normal distribution fits best with
$x_{min}$=1.0, $\mu$=$\\{1.5286,1.0357,1.9800\\}$, and
$\sigma$=$\\{1.5968,1.3693,1.3270\\}$ for B, M, and MBC, respectively. Here,
KLD between the distributions identified for M and B is 0.09103. While that
between M and MBC is 0.0967 and between B and MBC is 0.2542.

Figure 6: Distribution of Degree Change of individual DNs

(a) Distribution of Count of Degree Changes of all DNs combined

(b) Distribution of Sum of Degree Changes of all DNs combined

Figure 7: Distribution of Degree Change

Next, we identify the behavior of the diameter attribute present in the DNS
traffic data. We study the $Diff$=$\max_{\forall t\in
T}(D(g_{i}^{t}))-\min_{\forall t\in T}(D(g_{i}^{t}))$ associated with a DN
over entire data and the probability distribution of the number of instances
in which diameter changes occur for a DN. Here, $T$ is set of all times when a
DNS query was made for a particular DN, $i$. Figure 8a shows the probability
of $Diff$ associated with different types of DNs. Here, we observe that the
$\max(Diff)$ for any DN is 4, but such instances are rare. For most of DNs,
there was no change in the diameter. For B DNs $\approx$54% DNs showed no
change. We also observe the significant difference between B and M DNs.
Similarly, the analysis of probability distribution of number of instances in
which diameter changes (cf. Figure 8b) identifies the positive log-normal
distribution fits M and MBC DNs, while truncated-power-law distribution fits B
DNs. The parameters of probability distribution for M and MBC DNs are
$x_{min}$=1.0, $\mu$=$\\{0.3208,1.3323$$\times$10${}^{-15}\\}$, and
$\sigma$=$\\{0.9940,1.0115\\}$, respectively. The KLD between M and MBC DNs is
0.0506. The distribution parameters of B DNs are $x_{min}$=1.0,
$\alpha$=1.0540, and $\beta$=$\frac{1}{\lambda}$ where $\lambda$=0.0949. The
different distributions show differences between the B and M DNs.

(a) Variation between maximum and minimum of Diameter

(b) Distribution of Diameter Change of all DNs combined

Figure 8: Distribution of Diameter

Apart from the above discussed temporal features, Time-to-Live (TTL) also
reflects the behavioral difference between the B, M, and MBC DNs. Here, we
study a composite distribution of TTL of all DNs under a class (cf. Figure 9).
We observe that a positive log-normal distribution fits all classes of DNs
(i.e., B, M, MBC) with $x_{min}$=1.0, $\mu$=$\\{5.9656,6.7587,5.6341\\}$, and
$\sigma$=$\\{2.3297,2.1915,2.2833\\}$, respectively. Here, we observe the KLD
between the M and B distributions is 0.0691. While that between M and MBC is
0.0116 and between B and MBC is 0.1244. It signifies that the distributions
small divergence with each other.

From the above analysis, we see that temporal aspects exist in DNs where DN
associated with B and M differ. While those that belong to M and MBC show less
divergence than with B. Thus, these temporal features along with the non-
temporal features play as an important role in differentiating M and B DNs,
but not so much between M and MBC DNs.

###  IV-C Results

As the feature space is large, we use Pearson correlation to identify
correlated features. We find that there is a weak correlation between the
features. Thus, we use all the 48 features and train the ML algorithms.

####  IV-C1 Approach using Supervised Learning

Most state-of-the-art approaches use supervised ML algorithms. Thus, we
validate and test which supervised ML algorithm, along with its
hyperparameters, performs best towards identifying the malicious DNs in the
complete dataset. To perform such a task, we use AutoML tool called TPOT.
Although other AutoML tools exist, our choice to use TPOT is based on its
easy-to-use functionality. Here, we configure TPOT to use 11 different
supervised ML algorithms that are used by the state-of-the-art approaches. We
configure these 11 algorithms to use hyperparameters reported by the state-of-
the-art and other custom hyperparameters to have more diversity. For the best
identified algorithm in terms of balanced-accuracy, we also report Precision,
Recall, and F1 score for the malicious class.

Figure 9: Distribution of Time-to-Live of all DNs combined

TPOT reports DecisionTree (criterion=entropy, max_depth=8, min_samples_leaf=5,
min_samples_split=18, splitter=random) to achieves _balanced-accuracy_ of
89.53% as the best classifier for malicious blockchain DNs. Here, other
hyperparameters have default values and thus not reported here. It achieves
95.0% _Precision_ , 79.16% _Recall_ , and 86.0% _F1 score_. In case of
detection of all malicious DNs (including malicious blockchain DNs), TPOT
reports DecisionTree (max_depth=10, min_samples_ leaf=13,
min_samples_split=12) to achieves _balanced-accuracy_ of 81.52% and as the
best for detection. It achieves 91.0% _Precision_ , 63.0% _Recall_ , and 75.0%
_F1 score_. Although, the Recall on the malicious class is low, the overall
balanced-accuracy is high. Nonetheless, selecting with respect to the best
Recall as the selection criteria, TPOT reports GaussianNB
(var_smoothing=$\times$10-8) to achieve best _Recall_ of 98.58% on the
malicious class. While _Precision_ is 5.0% and _F1-score_ is 9.0% on the
malicious class. Here, a high Recall value or the low false-negative score
demonstrates that most malicious DNs are correctly identified. However, the
balanced-accuracy is low (the Recall value is 1.0% for benign class). Thus,
reducing the balanced-accuracy to $\approx$50.0%.

####  IV-C2 Approach using Unsupervised Learning

We apply K-Means unsupervised ML algorithm on the entire dataset to detect
malicious DNs (those that have high cosine similarity ($>$1-$\epsilon$ were
$\epsilon$=10-7) with malicious DNs). Using K-Means, we find optimal cluster
configurations (value of K) based on the silhouette score. We check the
silhouette score for different values of K$\in$[30,100] and find optimal
silhouette score is 0.836 for K=50 (different silhouette scores obtained are
listed in Table III). After exploring the clusters obtained for K=50, we find
that cluster number 22 has 77751 malicious DNs and 1284523 benign DNs.
Identifying cosine similarity for such a large number of DNs is resource
expensive and the approach does not capture behavioral changes.

TABLE III: Silhouette Scores (S) obtained by K-Means for different K. K | 30 | 40 | 50 | 60 | 70 | 80 | 90 | 100
---|---|---|---|---|---|---|---|---
S | 0.78 | 0.80 | 0.84 | 0.73 | 0.73 | 0.71 | 0.72 | 0.75

To capture the behavioral changes, we apply K-Means for different values of
K$\in$[7,24] for each data segment present in the _2H_ granularity. Each data
segment results in a different value of K for which silhouette score is
maximum. From the clusters identified using the best K, for all the data
segments, we select the cluster in which the number of malicious DNs are
maximum. Within these selected clusters, we identify cosine similarity between
the malicious and benign DNs and finally select those benign DNs where the
cosine similarity $>$1-$\epsilon$ where $\epsilon$=10-7. Using such a
technique, for each DN, we get a series of labels representing, in a given
granularity, how many times a particular DN was reported as malicious. Among
all the DNs, we find 144930 DNs show malicious behavior at least once. Out of
these DNs, 54114 DNs show persistent malicious behavior over time and have a
high probability of being malicious. None of these DNs were marked malicious
in any datasets we found. Figure 10 shows the histogram of the probability of
previously unflagged DN being malicious. We then analyze how many identified
DNs were marked and present in the new list of malicious DNs. This analysis
reveals that none of the identified malicious DNs are present in the latest
malicious blockchain DNs as of 7th April 2021. That is, the identified
malicious DNs were not marked. This could be because of reasons such as _(i)_
the DN was not malicious or _(ii)_ it was able to evade detection by the
authorities. Here, we do not reveal the identity of these DNs as we do not
want to malign any dApp or BCW until authorities validate them.

Figure 10: Probability of being a malicious DN vs. Number of malicious DNs
with that probability on a semi-log scale

##  V Conclusion

Safeguarding accounts in a permissionless blockchain is essential to minimize
the risk of any fraudulent activity. Past approaches have identified that
transactions performed by an account provide essential features using which we
can detect malicious accounts. Besides the transactions, meta-information
attached to the account also provides valuable inputs. In this work, we use
Domain Name (DN) and related DNS query records to identify the malicious DNs
and thus report malicious accounts associated with the particular DNs. Our
approach captures the temporal aspects present in the DNS record to identify
malicious DNs. In our work, besides the temporal aspects, we also use the non-
temporal features of DNS query data. In the process, we also perform a
comparative study of various techniques that identify malicious DNs.

Our results show that temporal features associated with a DN of a particular
account can be useful towards the identification of whether that account is
malicious or not. Our approach identifies 144930 DNs that show behavior as
similar to known malicious DNs, and out of these 54114 DNs show persistent
malicious behavior over time. None of these 54114 DNs were reported malicious
in the newly identified malicious blockchain DNs as on 7th April 2021. This
could be because the DN evaded the detection by the authorities, was not
reported to the authorities or showed adversarial behavior. Integrating DN
based features with other features (transaction and vulnerabilities-based
features) would provide an edge in identifying malicious accounts in a
blockchain.

Further, continuous identification of malicious accounts and those accounts
that show adversarial behavior based on such techniques is one possible
extension. Deep learning algorithms can be used to detect malicious accounts
based on DNs. Our technique uses association with underlying IP addresses.
Identifying malicious DNs internally gives us IPs that are associated with
malicious activities. Thus, resulting into blacklisting of associated IPs.
Besides blockchain providers, security providing companies can also use such
list to the safeguard underlying network. With respect to blockchain
providers, nodes associated to such IPs and DNs can be blocked by ISPs.
Nonetheless, we also warn users to not use predictable DNs. Such DNs reduce
privacy and could reveal lot of information about the account [55]. With
respect to ENS, one can use our approach on the Ethereum names to identify
malicious accounts. However, in such a case DNS query-based, burst-based, and
DNS graph-based features will not be applicable.

## Acknowledgement

This work is partially funded by the National Blockchain Project at IIT Kanpur
sponsored by the National Cyber Security Coordinator’s office of the
Government of India and partially by the C3i Center funding from the Science
and Engineering Research Board of the Government of India. We also thank
Daniel Plohmann who made DGA dataset available.

## References

  * [1] CBR Staff Writer, “Rise in malicious infrastructure hosted on blockchain identified,” 04 2018, Accessed: 01/02/2021. [Online]. Available: https://www.cbronline.com/news/malicious-infrastructure-blockchain
  * [2] J. Beyers, “Blockchain domains: What are they and how are they implemented?” 09 2019, Accessed: 01/02/2021. [Online]. Available: https://bit.ly/3ihaJWt
  * [3] R. Agarwal, S. Barve, and S. K. Shukla, “Detecting malicious accounts in permissionless blockchains using temporal graph properties,” _Applied Network Science_ , vol. 6, no. 1, pp. 1–30, 02 2021.
  * [4] R. Agarwal, T. Thapliyal, and S. Shukla, “Detecting malicious accounts showing adversarial behavior in permissionless blockchains,” _arXiv_ , pp. 1–15, 01 2021.
  * [5] A. Alkhalifah, A. Ng, A. Kayes, J. Chowdhury, M. Alazab, and P. Watters, “A Taxonomy of Blockchain Threats and Vulnerabilities,” in _Blockchain for Cybersecurity and Privacy_ , Y. Maleh, M. Shojafar, M. Alazab, and I. Romdhani, Eds. CRC Press, 08 2020, pp. 3–28.
  * [6] R. Mitra, “Blockchain domain name systems,” 10 2020, Accessed: 03/02/2021. [Online]. Available: https://bit.ly/3vOAMYw
  * [7] D. Sahoo, C. Liu, and S. Hoi, “Malicious URL Detection using Machine Learning: A Survey,” _arXiv_ , pp. 1–37, 08 2017.
  * [8] X. D. Hoang and Q. C. Nguyen, “Botnet detection based on machine learning techniques using DNS query data,” _Future Internet_ , vol. 10, no. 5, pp. 1–11, 05 2018.
  * [9] J. Selvi, R. J. Rodríguez, and E. Soria-Olivas, “Detection of algorithmically generated malicious domain names using masked n-grams,” _Expert Systems with Applications_ , vol. 124, pp. 156–163, 06 2019.
  * [10] P. M. Anand, T. G. Kumar, and P. S. Charan, “An ensemble approach for algorithmically generated domain name detection using statistical and lexical analysis,” _Procedia Computer Science_ , vol. 171, pp. 1129–1136, 01 2020\.
  * [11] P. S. Charan, S. K. Shukla, and P. M. Anand, “Detecting word based dga domains using ensemble models,” in _Cryptology And Network Security_. Vienna, Austria: Springer, 12 2020, pp. 127–143.
  * [12] Y. Zhauniarovich, I. Khalil, T. Yu, and M. Dacier, “A survey on malicious domains detection through DNS data analysis,” _Computing Survey_ , vol. 51, no. 4, pp. 1–36, 07 2018.
  * [13] R. Perdisci, I. Corona, D. Dagon, and W. Lee, “Detecting malicious flux service networks through passive analysis of recursive DNS traces,” in _2009 Annual Computer Security Applications Conference_. Honolulu, HI, USA: IEEE, 12 2009, pp. 311–320.
  * [14] R. Perdisci, I. Corona, and G. Giacinto, “Early detection of malicious flux networks via large-scale passive DNS traffic analysis,” _Trans. on Dependable and Secure Computing_ , vol. 9, no. 5, pp. 714–726, 04 2012.
  * [15] E. Stalmans and B. Irwin, “A framework for DNS based detection and mitigation of malware infections on a network,” in _Information Security for South Africa_. Johannesburg, South Africa: IEEE, 08 2011, pp. 1–8.
  * [16] D. T. Truong, D. T. Tran, and B. Huynh, “Detecting malicious fast-flux domains using feature-based classification techniques,” _Journal of Internet Technology_ , vol. 21, no. 4, pp. 1061–1072, 07 2020.
  * [17] K. A. Messabi, M. Aldwairi, A. A. Yousif, A. Thoban, and F. Belqasmi, “Malware detection using DNS records and domain name features,” in _2nd International Conference on Future Networks and Distributed Systems_ , ser. ICFNDS ’18. Amman, Jordan: ACM, 06 2018, pp. 1–7.
  * [18] H. Zhao, Z. Chang, G. Bao, and X. Zeng, “Malicious domain names detection algorithm based on n-gram,” _Journal of Computer Networks and Communications_ , vol. 2019, pp. 1–9, 02 2019.
  * [19] M. Antonakakis, R. Perdisci, D. Dagon, W. Lee, and N. Feamster, “Notos: Building a dynamic reputation system for DNS,” in _19th USENIX Conference on Security_. Washington DC, USA: USENIX, 08 2010, pp. 273–290.
  * [20] L. Bilge, E. Kirda, C. Kruegel, and M. Balduzzi, “EXPOSURE: Finding malicious domains using passive DNS analysis,” in _the Network and Distributed System Security Symposium, NDSS_. San Diego, USA: The Internet Society, 02 2011, pp. 1–17.
  * [21] L. Bilge, S. Sen, D. Balzarotti, E. Kirda, and C. Kruegel, “EXPOSURE: A passive DNS analysis service to detect and report malicious domains,” _Trans. on Information System Security_ , vol. 16, no. 4, pp. 1–28, 04 2014\.
  * [22] M. Antonakakis, R. Perdisci, W. Lee, N. Vasiloglou, and D. Dagon, “Detecting malware domains at the upper DNS hierarchy,” in _20th USENIX Conference on Security_. San Francisco, USA: USENIX, 08 2011, pp. 1–16.
  * [23] M. Stevanovic, J. M. Pedersen, A. D’Alconzo, S. Ruehrup, and A. Berger, “On the ground truth problem of malicious DNS traffic analysis,” _Computers & Security_, vol. 55, pp. 142–158, 11 2015.
  * [24] I. Khalil, T. Yu, and B. Guan, “Discovering malicious domains through passive DNS data graph analysis,” in _the 11th ACM on Asia Conference on Computer and Communications Security_. Xi’an, China: ACM, 05 2016, pp. 663–674.
  * [25] B. Rahbarinia, R. Perdisci, and M. Antonakakis, “Efficient and Accurate Behavior-Based Tracking of Malware-Control Domains in Large ISP Networks,” _Trans. on Privacy and Security_ , vol. 19, no. 02, pp. 1–31, 08 2016.
  * [26] H. Tran, A. Nguyen, P. Vo, and T. Vu, “DNS graph mining for malicious domain detection,” in _International Conference on Big Data (Big Data)_. Boston, USA: IEEE, 12 2017, pp. 4680–4685.
  * [27] Z. Liu, Y. Zeng, P. Zhang, J. Xue, J. Zhang, and J. Liu, “An imbalanced malicious domains detection method based on passive DNS traffic analysis,” _Security and Communication Networks_ , vol. 2018, pp. 1–7, 06 2018.
  * [28] Q. Wang, L. Li, B. Jiang, Z. Lu, J. Liu, and S. Jian, “Malicious Domain Detection Based on K-means and SMOTE,” in _LNCS-Computational Science_. Amsterdam: Springer, 06 2020, pp. 468–481.
  * [29] Y. Shi, G. Chen, and J. Li, “Malicious domain name detection based on extreme machine learning,” _Neural Processing Letters_ , vol. 48, no. 3, pp. 1347–1357, 12 2018.
  * [30] Statvoo, “Alexa top domain list 1 million,” Accessed: 04/04/2021. [Online]. Available: https://statvoo.com/dl/top-1million-sites.csv.zip
  * [31] Netlab OpenData, “DGA Dataset,” Accessed: 04/04/2021. [Online]. Available: https://data.netlab.360.com/dga/
  * [32] Computer Emergency Response Team Austria, “Conficker,” link unavailable. [Online]. Available: https://bit.ly/3wIhrct
  * [33] D. Plohmann, “Domain Generation Algorithms (DGA) dataset,” 01 2020, Accessed: 25/12/2020. [Online]. Available: https://bit.ly/3zyvG5w
  * [34] DannyCork, “whois 0.9.6: A Python package for retrieving WHOIS information of domains,” 02 2020, Accessed: 04/04/2021. [Online]. Available: https://pypi.org/project/whois/
  * [35] ABUSE, “Fastflux tracker,” link unavailable. [Online]. Available: https://bit.ly/2T1kaz2
  * [36] Google, “Google Doubleclick ad planner top-1000,” link unavailable. [Online]. Available: http://www.google.com/adplanner/static/top1000/
  * [37] ABUSE, “Spyeye Monitor,” link unavailable. [Online]. Available: https://bit.ly/3ccQkhF
  * [38] ABUSE Project, “Zeus Tracker: Zeus IP & domain name block list,” Accessed: 04/04/2021. [Online]. Available: https://sslbl.abuse.ch/blacklist/
  * [39] “Cybercrime-Tracker,” Accessed: 04/04/2021. [Online]. Available: http://www.cybercrime-tracker.net
  * [40] S. Burn, “hpHosts,” 03 2018, Accessed: 04/04/2021. [Online]. Available: http://hphosts.gt500.org/hosts.txt
  * [41] Malwaredomainlist, “Malware Domain List,” Accessed: 04/04/2021. [Online]. Available: http://www.malwaredomainlist.com/
  * [42] OpenDNS, “PhishTank dataset,” Accessed: 29/10/2020. [Online]. Available: https://www.phishtank.com/
  * [43] Google, “Safe Browsing,” Accessed: 04/04/2021. [Online]. Available: https://safebrowsing.google.com/
  * [44] Risk Discovery, “Malware domains list,” Accessed: 30/10/2020. [Online]. Available: https://riskdiscovery.com/
  * [45] joewein.de LLC, “Blacklist provided by JWSDB,” link unavailable. [Online]. Available: http://joewein.net/spam/blac-klist.htm
  * [46] “MalwareDomains,” link unavailable. [Online]. Available: http://www.malware-domains.com
  * [47] Farsight Security, “DNSDB Scout,” Accessed: 04/04/2021. [Online]. Available: http://www.dnsdb.info/
  * [48] “Hosts-File,” link unavailable. [Online]. Available: http://www.hosts-file.net/
  * [49] OpenINTEL Consortium, “Cisco umbrella 1m,” 01 2019, Accessed: 02/10/2020. [Online]. Available: https://bit.ly/35ETXsU
  * [50] McAfee, “Web Advisor,” Accessed: 04/04/2021. [Online]. Available: https://bit.ly/2RtuLSS
  * [51] CryptoScamDB.org, “Crypto scam black list,” Accessed: 30/10/2020 and 07/04/2021. [Online]. Available: https://bit.ly/3vOBDZe
  * [52] MyEtherWallet, “Ethereum dark list,” Accessed: 30/10/2020 and 07/04/2021. [Online]. Available: https://bit.ly/34PD5zl
  * [53] OpenPhish, “OpenPhish dataset,” Accessed: 29/10/2020. [Online]. Available: https://openphish.com/
  * [54] R. Olson and J. Moore, “Tpot: A tree-based pipeline optimization tool for automating machine learning,” in _Workshop on Automatic Machine Learning_. New York, New York, USA: PMLR, 06 2016, pp. 66–74.
  * [55] T. Copeland, “We tracked 133,000 ethereum names and exposed their secrets,” 02 2020, Accessed: 06/06/2021. [Online]. Available: https://bit.ly/3qca1fe