felix/master_thesis
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

finished notos; started exposure

Browse Source
This commit is contained in:
Felix Steghofer
2018-01-04 20:24:08 +01:00
parent d47217fd88
commit 0f10314bc8
19 changed files with 361 additions and 192 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
Thesis/bibliography.bib
View File

@@ -97,8 +97,37 @@
acmid = {1929844},
publisher = {USENIX Association},
address = {Berkeley, CA, USA},
}
@inproceedings{Bilge11exposure:finding,
author = {Leyla Bilge and Engin Kirda and Christopher Kruegel and Marco Balduzzi and Sophia Antipolis},
title = {Exposure: Finding malicious domains using passive dns analysis},
booktitle = {In Annual Network and Distributed System Security Symposium (NDSS},
year = {2011}
}
@article{Bilge:2014:EPD:2617317.2584679,
author = {Bilge, Leyla and Sen, Sevil and Balzarotti, Davide and Kirda, Engin and Kruegel, Christopher},
title = {Exposure: A Passive DNS Analysis Service to Detect and Report Malicious Domains},
journal = {ACM Trans. Inf. Syst. Secur.},
issue_date = {April 2014},
volume = {16},
number = {4},
month = apr,
year = {2014},
issn = {1094-9224},
pages = {14:1--14:28},
articleno = {14},
numpages = {28},
url = {http://doi.acm.org/10.1145/2584679},
doi = {10.1145/2584679},
acmid = {2584679},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {Domain name system, machine learning, malicious domains},
}
@misc{theguardiancom_wannacry,
author = {Nadia Khomami and Olivia Solon},
month = {May},
@@ -129,7 +158,6 @@
year = 2016
}
@book{mockapetris1988development,
title={Development of the domain name system},
author={Mockapetris, Paul and Dunlap, Kevin J},
@@ -138,3 +166,42 @@
year={1988},
publisher={ACM}
}
@misc{AlexaWebInformationOnline,
author={Amazon},
title={{Alexa. The web information company}},
month=nov,
year={2017},
howpublished={\url{http://www.alexa.com/}}
}
@misc{PhishtankInformationOnline,
author={openDNS},
title={{Fishtank - Join the fight against phishing}},
month=nov,
year={2017},
howpublished={\url{https://www.phishtank.com/}}
}
@misc{malwaredomainsInformationOnline,
author={DNS-BH-Project},
title={{Malware Prevention through Domain Blocking}},
month=nov,
year={2017},
howpublished={\url{http://www.malwaredomains.com}}
}
@techreport{RFC1033,
author = {M. Lottor},
title = {Domain administrators operations guide},
howpublished = {Internet Requests for Comments},
type = {RFC},
number = {1033},
year = {1987},
month = {November},
issn = {2070-1721},
publisher = {RFC Editor},
institution = {RFC Editor},
url = {http://www.rfc-editor.org/rfc/rfc1033.txt},
note = {\url{http://www.rfc-editor.org/rfc/rfc1033.txt}},
}

10
Thesis/content/Abuse_of_Domain_Names/Abuse_of_Domain_Names.tex
View File

@@ -11,6 +11,15 @@ On May 12th 2017, British security researchers discovered a malware which was sp
This case shows an example of how domains can be used by attackers to control their software. Usually domains are more often used to connect to command and control servers or to communicate with other infected machines (see Section~\ref{sec:botnets}). To infect a machine, attackers often use so called \textit{droppers} or \textit{injectors} that do not ship the malicious code in the first hand but that are little programs to download further source code or binaries that contain the harming functionality. It is much easier for malware authors to use domains for this purpose instead of hard coding the IP addresses for many reasons: If machines that serve the down-loadable content are e.g. confiscated by the police or taken down for other reasons, domains can simply be pointed to a redundant server and such minimizing slow downs in the distribution of the malware. Reliable endpoints are also used to maintain the malicious software and load additional code. As domains are comparably cheap (starting at a few cents per year compared to at least \$ 10 for a dedicated IPv4 address a year), attackers can build a pool of many domains and such compensate take downs of some domain names. This could possibly change when IPv6 is widely adopted (with IPv6 addresses being much cheaper) but according to statistics of Google, only about 20\% of worldwide users accessing google where IPv6 enabled (natively or using IPv6 to IPv4 bridges) \fsCite{googlecom_ipv6adoption}. This imposes the usage of IPv6 as the primary protocol in malware for obvious reasons.
\todo{add somewhere here}
techniques like:
fast flux networks, domain flux networks, domain generation algorithm
((
Examples of malware that make use of such DGAs are Kraken/Bobax, the Srizbi bots and the Conficker worm
))
\subsection{Countermeasures}
\label{subsec:countermeasures}
@@ -39,7 +48,6 @@ A Botnet is a network of mostly computers infected with malicious software and c
\subsection{Architecture}
\label{subsec:architecture}
xl
\subsection{Discovery}
\label{subsec:botnets_discovery}

2
Thesis/content/Development_of_DoresA/Development_of_DoresA.tex
View File

@@ -1,6 +1,8 @@
\chapter{Development of $DoresA$}
\label{cha:development_of_doresa}
==> remember, operated in a mostly safe environment (few malware should be in the field)
\section{Initial Situation and Goals}
\label{sec:initial_situation_and_goals}

195
Thesis/content/Evaluation_of_existing_Systems/Evaluation_of_existing_Systems.tex
View File

@@ -9,196 +9,9 @@ This chapter deals with work around domain reputation scoring systems that has b
For a comprehensive evaluation, all input and output as well as the exact implementations (and/or the corresponding parameters that have been used for the analysis) of the algorithm was needed. Unfortunately, none of the publications we are dealing with here have released any (raw) input data, specifically the passive DNS logs and the filter lists for the training set. Neither has any of the algorithm's actual implementation been published. For this reason the evaluation of the existing systems is focusing on the results that have individually been published. Most importantly the detection rate as well as the false positive rate. Another important fact for this overview is what data has actually been used for the training and classification and where the data has been obtained. Passive DNS logs may be collected in different stages of the DNS resolution and might, due to e.g. caching, lead to the extraction of different information. A resolver running on the users machine might obtain much more traffic and such benefit from e.g. time based patterns which are not possible at higher level DNS servers that are not able to collect that traffic because the response has been cached on resolvers in a lower (DNS-) hierarchy.
\section{Notos}
\label{sec:notos}
\input{content/Evaluation_of_existing_Systems/Notos/Notos.tex}
\subsection{General}
\label{subsec:notos_general}
\textit{Notos} has been published in 2010 by \fsAuthor{Antonakakis:2010:BDR:1929820.1929844} at the Georgia Institute of Technology. It has been introduced as ``being the first [system] to create a comprehensive dynamic reputation system around domain names'' \fsCite[Section 1]{Antonakakis:2010:BDR:1929820.1929844}. \textit{Notos} is based on observations that malicious use of DNS usually can be distinguished from legitimate, professionally provisioned DNS services by unique characteristics. Fraudulent activities therefore usually utilize techniques to evade security countermeasures \fsCite{Antonakakis:2010:BDR:1929820.1929844}. This approach is mainly using passive historical DNS information that was obtained on multiple recursive resolvers distributed across the Internet. For building a model of how resources are typically used in legitimate and malicious applications, information about vicious ip addresses and domain names is collected from different sources like honeypots, malware analysis services and spam-traps. Using this model, new domains that have never been seen before can be dynamically assigned with a reputation score of how likely this new domain is involved in malicious activities. Malicious activities in the context of \textit{Notos} are roughly described as: ``if it [a domain] has been involved with botnet C\&C servers, spam campaigns, malware propagation, etc.'' \fsCite[Section 3]{Antonakakis:2010:BDR:1929820.1929844}
\textit{Notos} uses some basic terminology which is shortly introduced here:
\begin{itemize}
\item A domain \textit{d} consists of several substrings which are described in \nameref{subsec:domain_names}. Abbreviations used in the following Sections are: \\
\textbf{Top-level domain:} TLD, where \(TLD(d)\) is the top-level domain of \textit{d} \\
\textbf{Second-level domain:} \(2LD(d)\) being the second-level domain of domain \textit{d} \\
\textbf{Third-level domain: } \(3LD(d)\) containing the three rightmost substrings separated by period for \textit{d}
\item Given domain \(d\) \(Zone(d)\) describes the set of domains that include \textit{d} and all subdomains of \textit{d}
\item \(D = \{d_1, d_2, ..., d_m\}\) representing a set of domains and \(A(D)\) all IP addresses that, at any time, any domain \(d \in D\) resolved to
\item \(BGP(a)\) consists of all ip addresses that are residing in the same \gls{bgp} prefix than \textit{a}
\item Analogously, \(AS(a)\) as the set of IP addresses located in the same \gls{as} than \textit{a}
\end{itemize}
\subsection{Architecture}
\label{subsec:notos_architecture}
The main goal of \textit{Notos} is to assign a dynamic reputation score to domain names. Domains that are likely to be involved in malicious activities are tagged with a low reputation score, whereas legitimate Internet services are assigned with a high reputation score.
\textit{Notos'} primary source of information is a database that contains historical data about domains and resolved ip addresses. This database is built using DNS traffic from two recursive ISP DNS servers (RDNS) and pDNS logs collected by the Security Information Exchange (SIE) which covers authoritative name servers in North America and Europe. For building a list of known malicious domain names, several honeypots and spam-traps have been deployed. A large list of known good domains has been gathered from the top sites list on \textit{alexa.com} which ranks the most popular websites in several regions. These two lists are referred to as the \textit{knowledge base} and are used to train the reputation training model.
To assign a reputation score to a domain \textit{d}, the most current set of IP addresses \(A_{c}(d) = \left\{a_{i}\right\}_{i=1..m}\) to which \textit{d} points is first fetched. Afterwards the pDNS database is queried for several information for this domain \textit{d}. The \textit{Related Historic IPs (RHIPs)} is the set of all IP addresses that ever pointed to this domain. In case domain \textit{d} is a third-level domain, all IP addresses that pointed to the corresponding second-level domain are also included. See Chapter~\ref{subsec:domain_names} for more information on the structure of domain names. If \textit{d} is a second-level domain, then all IPs that are pointed to from any of the third-level subdomains are also added to the RHIPs. In the next step, the set of \textit{Related Historic Domains (RHDNs)} is queried and covers all domains that are related to the currently processed domain \textit{d}. Specifically, all domains which ever resolved to an IP address that is residing in any of the ASNs of those IPs that \textit{d} currently resolves to.
There are three types of features extracted from the database for \textit{Notos} that are used for training the reputation model (quotation from \fsCite[Section 3.1]{Antonakakis:2010:BDR:1929820.1929844}):
\begin{quote}
\begin{enumerate}
\item \textbf{Network-based features:} The first group of statistical features is extracted from the set of RHIPs. We measure quantities such as the total number of IPs historically associated with \textit{d}, the diversity of their geographical location, the number of distinct autonomous systems (ASs) in which they reside, etc.
\item \textbf{Zone-based features:} The second group of features we extract are those from the RHDNs set. We measure the average length of domain names in RHDNs, the number of distinct TLDs, the occurrence frequency of different characters, etc.
\item \textbf{Evidence-based features:} The last set of features includes the measurement of quantities such as the number of distinct malware samples that contacted the domain \textit{d}, the number of malware samples that connected to any of the IPs pointed by \textit{d}, etc.
\end{enumerate}
\end{quote}
Figure~\ref{fig:notos_system_overview} shows the overall system architecture of \textit{Notos}. After all the features are extracted from the passive DNS database and prepared for further steps, the reputation engine is initialized. \textit{Notos'} reputation engine is operating in two modes. In offline mode, the reputation model is constructed for a set of domains using the feature set of each domain and the classification which can be calculated using the \textit{knowledge base} with black- and whitelist (also referred as training). This model can later be used in the online mode to dynamically assign a reputation score. In online mode, the same features that are used for the initial training are extracted for a new domain (resource record or RR, see Section~\nameref{subsubsec:dns_resource_records}) and \textit{Notos} queries the trained reputation engine for the dynamic reputation rating (see Figure~\ref{fig:notos_online_offline_mode}). The data for labeling domains and IPs originates from various sources: the blacklist primarily consists of filter lists from malware services like malwaredomainlist.com and malwaredomains.com. Additional IP and domain labeling blacklists are the Sender Policy Block from Spamhaus and the ZeuS blocklist from ZeuS Tracker. The base has been downloaded before the main analyzation period (fifteen days from the first of August 2009)and as filter lists usually lag behind state-of-the art malware, the blacklists have continuously been updated. The whitelist was built using the top 500 popular Alexa websites. The 18 most common second level domains from various content delivery networks for classifying the CDN clusters and a list of 464 dynamic DNS 2LD for identifying domains and IPs in dynamic DNS zones.
\begin{figure}[!htbp]
\centering
\includegraphics[scale=.3, clip=true]{content/Evaluation_of_existing_Systems/Notos_System_overview.png}
\caption{Notos: System overview \fsCite[Figure 1]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_system_overview}
\end{figure}
\begin{figure}[!htbp]
\centering
\includegraphics[scale=.3, clip=true]{content/Evaluation_of_existing_Systems/Notos_offline-online_mode.png}
\caption{Notos: online and offline mode \fsCite[Figure 3]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_online_offline_mode}
\end{figure}
\subsection{Features}
\label{subsec:notos_features}
In this Section, all statistical features are listed and a short explanation, for what reason those have been chosen, is introduced.
The first group of features handles network-related keys. This group mostly describe how the owning operators of \textit{d} allocate network resources to achieve different goals. While most legitimate and professionally operated internet services feature have a rather stable network profile, malicious usage usually involves short living domain names and ip addresses with high agility to circumvent blacklisting and other simple types of resource blocking. Botnets usually contain machines in many different networks (\glspl{as} and \glspl{bgp}) operated by different organizations in different countries. Appropriate companies mostly acquire bigger ip blocks and such use consecutive IPs for their services in the same address space. This homogeneity also applies to other registration related information like registrars and registration dates. To measure this level of agility and homogeneity, eighteen statistical network-based features are extracted from the RHIPs (see Table~\ref{tab:notos_network-based_features}).
\begin{table}[!htbp]
\centering
\caption{Notos: Network-based features}
\label{tab:notos_network-based_features}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\textbf{Feature Source} & \textbf{Feature} \\ \hline
\multirow{9}{*}{\textit{BGP}} & \# of distinct BGP prefixes related to \(BGP(A(d))\) \\ \cline{2-2}
& \# of countries in which these BGP prefixes reside \\ \cline{2-2}
& \# of organizations that own these BGP prefixes \\ \cline{2-2}
& \# of distinct IP addresses in the sets \(A_{3LD}(d)\) \\ \cline{2-2}
& \# of distinct IP addresses in the sets \(A_{2LD}(d)\) \\ \cline{2-2}
& \# of distinct BGP prefixes related to \(BGP(A_{3LD}(d)\) \\ \cline{2-2}
& \# of distinct BGP prefixes related to \(BGP(A_{2LD}(d)\) \\ \cline{2-2}
& \# of countries in which \(BGP(A_{3LD}(d)\) \\ \cline{2-2}
& \# of countries in which \(BGP(A_{2LD}(d)\) \\ \hline
\multirow{3}{*}{\textit{ASN}} & \# of distinct autonomous systems related to \(AS(A(d))\) \\ \cline{2-2}
& \# of distinct autonomous systems related to \(AS(A_{3LD}(d)\) \\ \cline{2-2}
& \# of distinct autonomous systems related to \(AS(A_{2LD}(d)\) \\ \hline
\multirow{6}{*}{\textit{Registration}} & \# of distinct registrars associated with the IPs in the \(A(d)\) set \\ \cline{2-2}
& diversity in the registration dates related to the IPs in \(A(d)\) \\ \cline{2-2}
& \# of distinct registrars associated with the IPs in the \(A_{3LD}(d)\) \\ \cline{2-2}
& \# of distinct registrars associated with the IPs in the \(A_{2LD}(d)\) \\ \cline{2-2}
& diversity in the registration dates for the IPs in \(A_{3LD}(d)\) \\ \cline{2-2}
& diversity in the registration dates for the IPs in \(A_{2LD}(d)\) \\ \hline
\end{tabularx}
\end{table}
The second group is about zone-based features and is extracted from the RHDNs. In contrast to the network-based features which compares characteristics of the historic IPs, the zone-based features handles characteristics of all historically involved domains. While legitimate services often involve many domains, they usually share similarities. ``For example, google.com, googlesyndication.com, googlewave.com, etc., are all related to Internet services provided by Google, and contain the string 'google' in their name.''. In contrast, randomly generated domains used in spam campaigns are rarely sharing similarities. By calculating the mean, median and standard deviation for some key, the ``summarize [of] the shape of its distribution'' is investigated \fsCite[Section 3.2.2]{Antonakakis:2010:BDR:1929820.1929844}. To calculate this level of diversity, seventeen features are extracted which can be found in Table~\ref{tab:notos_zone-based_features}:
\begin{table}[!htbp]
\centering
\caption{Notos: Zone-based features}
\label{tab:notos_zone-based_features}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\textbf{Feature Source} & \textbf{Feature} \\ \hline
\multirow{12}{*}{\textit{String}} & \# of distinct domain names in RHDNs \\ \cline{2-2}
& average \# of distinct domain names in RHDNs \\ \cline{2-2}
& standard deviation of \# of distinct domain names in RHDNs \\ \cline{2-2}
& mean of the occurrence frequency of each single character in the domain name strings in RHDNs \\ \cline{2-2}
& median of the occurrence frequency of each single character in the domain name strings in RHDNs \\ \cline{2-2}
& standard deviation of the occurrence frequency of each single character in the domain name strings in RHDNs \\ \cline{2-2}
& mean distribution of 2-grams (i.e. pairs of characters) \\ \cline{2-2}
& median distribution of 2-grams \\ \cline{2-2}
& standard deviation of 2-grams \\ \cline{2-2}
& mean distribution of 3-grams (i.e. triples of characters) \\ \cline{2-2}
& median distribution of 3-grams \\ \cline{2-2}
& standard deviation of the distribution of 3-grams \\ \hline
\multirow{5}{*}{\textit{TLD}} & \# of distinct TLD strings of each domain \(d_i\) in the RHDNs set \\ \cline{2-2}
& ratio between \# of domains \(d_i\) whose \(TLD(d_i)=".com"\) and the total \# of TLD different from ".com" \\ \cline{2-2}
& mean of the occurrence frequency of the TLD strings \\ \cline{2-2}
& median of the occurrence frequency of the TLD strings \\ \cline{2-2}
& standard deviation of the occurrence frequency of the TLD strings \\ \hline
\end{tabularx}
\end{table}
For the evidence-based features, public information and exclusively collected data from honeypots and spam-traps is collected. This \textit{knowledge base} primarily helps to discover if a domain \textit{d} is in some way interacting with known malicious IPs and domains. As domain names are much cheaper than ip addresses, malware authors tend to reuse IPs with updated domain names. The blacklist features detect the reuse of known malicious resources like IP addresses, \gls{bgp} prefixes and \glspl{as}.
\begin{table}[!htbp]
\centering
\caption{Notos: Evidence-based features}
\label{tab:notos_evidence-based_features}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\textbf{Feature Source} & \textbf{Feature} \\ \hline
\multirow{3}{*}{\textit{Honeypot}} & \# of distinct malware samples that, when executed, try to contact \(d\) or any IP address in \(A(d)\) \\ \cline{2-2}
& \# of malware samples that contact any IP address in \(BGP(A(d)\) \\ \cline{2-2}
& \# of samples that contact any IP address in \(AS(A(d))\) \\ \hline
\multirow{3}{*}{\textit{Blacklist}} & \# of IP addresses in \(A(d)\) that are listed in public IP blacklists \\ \cline{2-2}
& \# of IPs in \(BGP(A(d)\) that are listed in public IP blacklists \\ \cline{2-2}
& \# of IPs in \(AS(A(d))\) that are listed in public IP blacklists \\ \hline
\end{tabularx}
\end{table}
\begin{figure}[!htbp]
\centering
\includegraphics[scale=.3, clip=true]{content/Evaluation_of_existing_Systems/Notos_features.png}
\caption{Notos: Computing network-based, zone-based, evidence-based features \fsCite[Figure 2]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_features}
\end{figure}
\todo{not referenced atm}
\subsection{Reputation Engine}
\label{subsec:notos_reputation_engine}
The reputation engine is used to dynamically assign a reputation score to a domain \textit{d}. In the first step, the engine has to be trained with the available training set (temporal defined as the \textit{training period}). The training is performed in an offline fashion which means all data is statically available at the beginning of this step. The training mode consists of three modules: The \textit{Network Profile Model} is a model of how known good domains are using resources. This model uses popular content delivery networks (e.g. Akamai, Amazon CloudFront) and large sites (e.g. google.com, yahoo.com) as a base. In total the \textit{Network Profile Model} consists of five classes of domains: \textit{Popular Domains}, \textit{Common Domains}, \textit{Akamai Domains}, \textit{CDN Domains} and \textit{Dynamic DNS Domains}. The second module \textit{Domain Name Clusters} performs a general clustering of all domains (respectively their statistical feature vectors) of the training set. There are two consecutive clustering processes: The \textit{network-based} clustering aims to group domains with similar agility characteristics. To refine those clusters, a \textit{zone-based} clustering is performed which groups domains that are similar in terms of its RHDNs (see explanation for the \textit{zone-based features}). Those clusters of domains with similar characteristics can then be used to identify mostly benign and malicious sets of domains. In the last step of the offline mode, the \textit{Reputation Function} is build. As seen in Figure~\ref{fig:notos_online_offline_mode} this module takes the results of the \textit{Network Profile Model} (\(NM(d_i)\)) and the \textit{Domain Name Clusters} (\(DC(d_i)\)) for each domain \textit{d} in \(d_i, i = 1..n\) as inputs, calculates an \textit{Evidence Features Vector} \(EV(d_i)\), which basically checks if \(d_i\) or any of its resolved IPs is known to be benign or malicious, and builds a model that can assign a reputation score between zero and one to \textit{d}. This \textit{Reputation Function} is implemented as a statistical classifier. These three modules form the reputation model that can be used in the last step to compute the reputation score. A rebuild of the training model can be done at any time, for example given an updated training set.
The final stage of the reputation engine is the online (streaming like) mode. Any considered domain \textit{d} is first supplied to the \textit{network profiles} module which returns a probability vector \(NM(d) = \{c_1, c_2, ..., c_5\}\) of how likely \textit{d} belongs to one of the five classes (e.g. probability \(c_1\) that \textit{d} belongs to \textit{Popular Domains}). \(DC(d)\) is the resulting vector of the \textit{domain clusters} module and can be broken down into the following parts: For the domain \textit{d} of interest, the network-based features are extracted and the closest network-based cluster \(C_d\), generated in the training mode by the \textit{Domain Name Clusters} module, is calculated. The following step takes all zone-based feature vectors \(v_j \in C_d\) and eliminates those vectors that do not fulfill \(dist(z_d , v_j ) < R\), where \(z_d\) is the zone-based feature vector for \textit{d} and \textit{R} being a predefined radius; or \(v_j \in KNN(z_d)\), with \(KNN(z_d)\)) being the k nearest-neighbors of \(z_d\). Each vector \(v_i\) of the resulting subset \(V_d \subseteq C_d\) is then assigned one of this eight labels: \textit{Popular Domains}, \textit{Common Domains}, \textit{Akamai}, \textit{CDN}, \textit{Dynamic DNS}, \textit{Spam Domains}, \textit{Flux Domains}, and \textit{Malware Domains}. The next step is to calculate the five statistical features that form the resulting vector \(DC(d) = \{l_1, l_2, ..., l_5\}\).
\begin{enumerate}
\item \(l_1\) the \textit{majority class label} \textit{L}, i.e. the most common label in \(v_i \in V_d\) (e.g. \textit{Spam Domains})
\item \(l_2\) the standard deviation of the occurrence frequency of each label
\item \(l_3\) mean of the distribution of distances between \(z_d\) and the vectors \(v_j \in V_{d}^{(L)}\), where \(V_{d}^{(L)} \subseteq V_d\) is the subset of those vectors, associated with the \textit{majority class label} \textit{L}
\end{enumerate}
Having the \textit{Network Profile Model} \(NM(d)\), the \textit{Domain Name Clusters} \(DC(d_i)\), and the \textit{Evidence Features Vector} \(EV(d)\), these vectors are combined into a sixteen dimensional feature vector \(v(d)\) which is then fed into the trained reputation function. This results in a reputation score \textit{S} in the range of [0, 1], where values close to zero represent a low reputation and such more likely represent malicious usage of the domain.
\subsection{Results}
\label{subsec:notos_results}
In the last Section of the evaluation of \textit{Notos}, experimental results that have been published are listed. This covers metrics about the usage of raw data, lessons learned in the analyzation process (e.g. examined algorithms) and final acquisitions like precision and accuracy of the classification.
\textit{Notos} being the first dynamic reputation system in the context of domain names, it is able to identify malicious domain names before they appear in public filter lists. To be able to assign reputation scores to new domains, \fsAuthor{Antonakakis:2010:BDR:1929820.1929844} used historic passive dns logs of a time span of 68 days with a total volume of 27,377,461 unique, successful A-type resolutions mainly from two recursive ISP DNS servers in North America (plus pDNS logs from various networks, aggregated by the SIE \ref{subsec:notos_architecture}). Figure~\ref{fig:notos_volume_new_rr} shows that after a few days, the number of new domains (RR) stabilizes at about 100,000 to 150,000 new domains a day compared to a much higher total load of unique resource records (about 94.7\% duplicates) (see Figure~\ref{fig:notos_total_volume_unique_rr}). The amount of new IPs is analogously nearly constant. After few weeks, even big content delivery networks with a large (but nearly constant) number of IP addresses will get scanned, in contrast to botnets where continuously new machines are infected. The authors follow that a relatively small pDNS database is therefor sufficient for \textit{Notos} to produce good results.
\begin{figure}[!htbp]
\centering
\includegraphics[scale=.3, clip=true]{content/Evaluation_of_existing_Systems/Notos_new-RR.png}
\caption{Notos: Volume of new unseen RRs \fsCite[Figure 7b]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_volume_new_rr}
\end{figure}
\begin{figure}[!htbp]
\centering
\includegraphics[scale=.3, clip=true]{content/Evaluation_of_existing_Systems/Notos_total-RR.png}
\caption{Notos: Total volume of unique RRs \fsCite[Figure 7a]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_total_volume_unique_rr}
\end{figure}
To get optimal results with the \textit{Reputation Function}, several classifiers have been tested and selected for the given circumstances (time complexity, detection results and precision [true positives over all positives]). A decision tree with Logit-Boost strategy has shown to provide the best results with a low false positive rate (FP) of 0.38\% and a high true positive rate (TP) of 96.8\%. These results have been verified using a 10-fold cross-validation with a reputation score threshold of 0.5. For this validation, a dataset of 20,249 domains with 9,530 known bad RR has been used. As the list of known good domains, the Alexa top 500 websites have been used. Taking a bigger amount of Alexa popular sites has shown to decrease accuracy of the overall system, e.g. 100,000 entries showed a TP of 80.6\% and a FP of 0.6\%. To compare \textit{Notos}' performance with static filter lists, a pre-trained instance has been fed with 250,000 unique domains collected on 1. August 2009. 10,294 distinct entries have been reported with a reputation score below 0.5. 7,984 of this 10,294 or 77.6\% could be found in at least one blacklist (see Section~\nameref{subsec:notos_architecture} for a list of included blacklists). The remaining 22.4\% could not be precisely revealed. It is worth stating that 7,980 of the 7,984 confirmed bad domain names were assigned a reputation score of less than or equal to 0.15.
\section{Exposure}
\label{sec:exposure}
\input{content/Evaluation_of_existing_Systems/Exposure/Exposure.tex}
\section{Kopis}
@@ -207,3 +20,7 @@ To get optimal results with the \textit{Reputation Function}, several classifier
\section{Results and Comparison}
\label{sec:results_and_comparison}
==> Exposure much simpler, much less data available (ips of malicious servers, honeypots, dyndns,...)
==> not possible to simply block everything, always false positives

70
Thesis/content/Evaluation_of_existing_Systems/Exposure/Exposure.tex Normal file
View File

@@ -0,0 +1,70 @@
\section{Exposure}
\label{sec:exposure}
\subsection{General}
\label{subsec:exposure_general}
\textit{Exposure} is ``a system that employs large-scale, passive DNS analysis techniques to detect domains that are involved in malicious activity'', which was first introduced in 2011 by the \textit{Institute Eurecom} in Sophia Antipolis, the \textit{Northeastern University} from Boston and the \textit{University of California} in Santa Barbara \fsCite{Bilge11exposure:finding}. \textit{Exposure} is the second published system to detect malicious domains using passive DNS data and is built on the key premise, that most malicious services are dependent on the domain name system and compared to benign services should expose enough differences in behavior for an automated discovery. The main analysis for \textit{Exposure} has been run on data of a period of 2.5 month with more than 100 billion DNS queries. \textit{Exposure} is not targeted at a specific threat but rather covers a wide variety of malicious activities like phishing, Fast-Flux services, spamming, botnets (using domain generation algorithms), etc. It uses fifteen features with nine features, that have not been proposed in previous research. Ultimately, \textit{Exposure} offers a real-time detection system which has been made available for the public in 2014 \fsCite{Bilge:2014:EPD:2617317.2584679}. Unfortunately, the service was not accessible at the time of this work.
\subsection{Architecture}
\label{subsec:exposure_architecture}
For the distinction of benign and malicious domains to perform well, a large set of training data is used in \textit{Exposure} (seven days). The offline training has been powered by recursive DNS traffic (RDNS), gathered from the Security Information Exchange (SIE). Specifically, only the answer of the RDNS traffic has been used, that comprises of: the queried domain name, timestamp of the request, caching time TTL and the list of resolved IP addresses. The overall systems consists of five main components. The interaction of those models can be seen in Figure~\ref{fig:exposure_system_overview}.
\begin{itemize}
\item The \textit{Data Collector} module passively captures the DNS traffic in the monitored network.
\item The \textit{Feature Attribution} component is attributing the captured domains with the desired features.
\item The third component \textit{Malicious and Benign Domains Collector} is running in parallel to the first two modules and constantly gathers information about known good and known bad domains. These lists are used to label the output of the \textit{Feature Attribution} module afterwards, as it can be seen in picture~\ref{fig:exposure_system_overview}. The list of benign domains is extracted from the Alexa top list \fsCite{AlexaWebInformationOnline} and externally confirmed \gls{whois} data. The list of known malicious domains is collected from several external sources and includes domains in different threat classes, e.g., malwaredomains.com \fsCite{malwaredomainsInformationOnline}, Phishtank \fsCite{PhishtankInformationOnline} and Anubis (no longer available).
\item The labeled dataset is then fed into the \textit{Learning Module} and trains the domain detection model that is used in the final step. This classifier may also be retrained on a regular basis to keep up with malicious behavior (daily in \textit{Exposure}).
\item The \textit{Classifier} uses the decision model to classify unlabeled (new) domains into benign and malicious groups. For this, the same feature vector that is produced by the \textit{Feature Attribution} module is used.
\end{itemize}
\begin{figure}[!htbp]
\centering
\includegraphics[width=.9\textwidth, clip=true]{content/Evaluation_of_existing_Systems/Exposure/exposure_system_overview.png}
\caption{Exposure: System overview \fsCite[Figure 1]{Bilge11exposure:finding}}
\label{fig:exposure_system_overview}
\end{figure}
\subsection{Features}
\label{subsec:exposure_features}
\textit{Exposure} uses a total of fifteen features that have been chosen after several month of study with thousands of well-known benign and malicious domains. These features are grouped into four different categories which can be seen in Table~\ref{tab:exposure_features}.
The first group, with \textit{Time-Based Features} has not been approached in publications before. These features investigate the time, at which the request with domain \textit{d} has been issued. The main idea behind this group of features is to find malicious services that use techniques like \textit{domain flux}
\todo{explain domain flux} to circumvent take downs and make their infrastructure more agile. ``[\textit{Domain flux}] often show a sudden increase followed by a sudden decrease in the number of requests'' \fsCite[Section 3.1]{Bilge:2014:EPD:2617317.2584679}. Domains of malicious services using a DGA do only exist for a short period of time by design. \fsAuthor{Bilge:2014:EPD:2617317.2584679} defines the first feature as follows: ``A domain is defined to be a short-lived domain [...] if it is queried only between time \(t_0\) and \(t_1\), and if this duration is comparably short (e.g., less than several days).'' The next three features are subject to the change point detection (CPD) problem: Change point detection is about the identification of (abrupt) changes in the distribution of values, for example in time series. \textit{Exposure} implemented a CPD algorithm based on the popular CUSUM (cumulative sum) algorithm. At first, the time series of request timestamps is split into periods of 3600 seconds (one hour was tested to work well). After that, all time intervals are iterated and for each interval, the average request count of the previous eight hours \(P_t^-\) and following eight intervals \(P_t^+\) is calculated. In the next step, the distance of these two values is calculated \(d(t)=|P_t^--P_t^+|\) for each interval and the resulting ordered sequence \(d(t)\) of distances is fed to the CUSUM algorithm to finally get retrieve all change points (For more information on the implemented CPD algorithm, see \fsCite[Section 3.1]{Bilge:2014:EPD:2617317.2584679}). To calculate feature two (\textit{Daily similarity}), the Euclidean Distance of the time series of each day for \textit{d} is calculated. Intuitively, a low distance means similar time series and such high daily similarity whereas two days with higher distance do show a less similar request volume. All the features of this group do naturally only perform well when having a larger number of requests to \textit{d} over a significant period of time.
The next group of Features (\textit{DNS Answer-Based Features}) investigates resolutions of the requested domain \textit{d}. While one domain can map to multiple IP addresses for benign services, most harmless services do show a much smaller network profile in terms of e.g. location and \glspl{as}. To satisfy those findings, four features have been extracted: The number of distinct IP addresses, the amount of different countries these IP addresses are assigned to, the number of other domains that share an IP address \textit{d} resolves to and the fourth feature is the amount of results of the reverse dns query for all IPs of \textit{d}. It is worth noting, that some hosting providers also use one IP address for many domains so an extra layer to prevent such false positives make sense.
The \textit{TTL Value-Based Features} covers five individual features. Each answer for a DNS request contains the TTL attribute, which is the recommendation, configured by the operator of \textit{d}, of how long the resolution will be valid and should be cached for this reason. Whereas RFC 1033 recommends a TTL of one day (86400 seconds) \fsCite{RFC1033} it is getting more common, especially for content delivery networks to use much lower values (e.g. Cloudflare, one of the biggest managed DNS providers is using a default of 5 minutes). Botnets are also usually applying low TTL values to avoid long outages of C\&C servers and bots. As \fsAuthor{Bilge:2014:EPD:2617317.2584679} states, botnets do also change their TTL values more frequently and use values in different ranges depending on their availability. While applying a higher value to high bandwidth servers with low downtimes, home computers behind a digital subscriber line are much likely to fail and get lower TTL values. For this reason, all TTL values for a domain are checked against the following ranges: [0, 1], [1, 10], [10, 100], [100, 300], [300, 900], [900, inf].
The last group of features are the \textit{Domain Name-Based Features}. Domain names of benign services mostly use easy to remember names which consist of valid words. Attackers often are not interested in human readable domain names. This is especially right for domains generated by a DGA. \textit{Exposure} extracts two statistical features out of the domain name, the first being the percentage of numerical characters and secondly the length of the longest (english) meaningful string (LMS).
\begin{table}[!htbp]
\centering
\caption{Exposure: Features}
\label{tab:exposure_features}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\textbf{Feature Set} & \textbf{Feature Name} \\ \hline
\multirow{4}{*}{\textit{Time-Based Features}} & Short life \\ \cline{2-2}
& Daily similarity \\ \cline{2-2}
& Repeating patterns \\ \cline{2-2}
& Access ratio \\ \hline
\multirow{4}{*}{\textit{DNS Answer-Based Features}} & Number of distinct IP addresses \\ \cline{2-2}
& Number of distinct countries \\ \cline{2-2}
& Number of domains share the IP with \\ \cline{2-2}
& Reverse DNS query results \\ \hline
\multirow{5}{*}{\textit{TTL Value-Based Features}} & Average TTL \\ \cline{2-2}
& Standard Deviation of TTL \\ \cline{2-2}
& Number of distinct TTL values \\ \cline{2-2}
& Number of TTL change \\ \cline{2-2}
& Percentage usage of specific TTL ranges \\ \hline
\multirow{2}{*}{Domain Name-Based Features} & \% of numerical characters \\ \cline{2-2}
& \% of the length of the LMS \\ \hline
\end{tabularx}
\end{table}

1
Thesis/content/Evaluation_of_existing_Systems/Exposure/exposure_all_features.tgn Normal file
View File

File diff suppressed because one or more lines are too long

BIN
Thesis/content/Evaluation_of_existing_Systems/Exposure/exposure_system_overview.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 67 KiB

193
Thesis/content/Evaluation_of_existing_Systems/Notos/Notos.tex Normal file
View File

@@ -0,0 +1,193 @@
\section{Notos}
\label{sec:notos}
\subsection{General}
\label{subsec:notos_general}
\textit{Notos} has been published in 2010 by \fsAuthor{Antonakakis:2010:BDR:1929820.1929844} at the Georgia Institute of Technology. It has been introduced as ``being the first [system] to create a comprehensive dynamic reputation system around domain names'' \fsCite[Section 1]{Antonakakis:2010:BDR:1929820.1929844}. \textit{Notos} is based on observations that malicious use of DNS usually can be distinguished from legitimate, professionally provisioned DNS services by unique characteristics. Fraudulent activities therefore usually utilize techniques to evade security countermeasures \fsCite{Antonakakis:2010:BDR:1929820.1929844}. This approach is mainly using passive historical DNS information that was obtained on multiple recursive resolvers distributed across the Internet. For building a model of how resources are typically used in legitimate and malicious applications, information about vicious ip addresses and domain names is collected from different sources like honeypots, malware analysis services and spam-traps. Using this model, new domains that have never been seen before can be dynamically assigned with a reputation score of how likely this new domain is involved in malicious activities. Malicious activities in the context of \textit{Notos} are roughly described as: ``if it [a domain] has been involved with botnet C\&C servers, spam campaigns, malware propagation, etc.'' \fsCite[Section 3]{Antonakakis:2010:BDR:1929820.1929844}
\textit{Notos} uses some basic terminology which is shortly introduced here:
\begin{itemize}
\item A domain \textit{d} consists of several substrings which are described in \nameref{subsec:domain_names}. Abbreviations used in the following Sections are: \\
\textbf{Top-level domain:} TLD, where \(TLD(d)\) is the top-level domain of \textit{d} \\
\textbf{Second-level domain:} \(2LD(d)\) being the second-level domain of domain \textit{d} \\
\textbf{Third-level domain: } \(3LD(d)\) containing the three rightmost substrings separated by period for \textit{d}
\item Given domain \(d\) \(Zone(d)\) describes the set of domains that include \textit{d} and all subdomains of \textit{d}
\item \(D = \{d_1, d_2, ..., d_m\}\) representing a set of domains and \(A(D)\) all IP addresses that, at any time, any domain \(d \in D\) resolved to
\item \(BGP(a)\) consists of all ip addresses that are residing in the same \gls{bgp} prefix than \textit{a}
\item Analogously, \(AS(a)\) as the set of IP addresses located in the same \gls{as} than \textit{a}
\end{itemize}
\subsection{Architecture}
\label{subsec:notos_architecture}
The main goal of \textit{Notos} is to assign a dynamic reputation score to domain names. Domains that are likely to be involved in malicious activities are tagged with a low reputation score, whereas legitimate Internet services are assigned with a high reputation score.
\textit{Notos'} primary source of information is a database that contains historical data about domains and resolved ip addresses. This database is built using DNS traffic from two recursive ISP DNS servers (RDNS) and pDNS logs collected by the Security Information Exchange (SIE) which covers authoritative name servers in North America and Europe. For building a list of known malicious domain names, several honeypots and spam-traps have been deployed. A large list of known benign domains has been gathered from the top sites list on \textit{alexa.com} which ranks the most popular websites in several regions \fsCite{AlexaWebInformationOnline}. These two lists are referred to as the \textit{knowledge base} and are used to train the reputation training model.
To assign a reputation score to a domain \textit{d}, the most current set of IP addresses \(A_{c}(d) = \left\{a_{i}\right\}_{i=1..m}\) to which \textit{d} points is first fetched. Afterwards the pDNS database is queried for several information for this domain \textit{d}. The \textit{Related Historic IPs (RHIPs)} is the set of all IP addresses that ever pointed to this domain. In case domain \textit{d} is a third-level domain, all IP addresses that pointed to the corresponding second-level domain are also included. See Chapter~\ref{subsec:domain_names} for more information on the structure of domain names. If \textit{d} is a second-level domain, then all IPs that are pointed to from any of the third-level subdomains are also added to the RHIPs. In the next step, the set of \textit{Related Historic Domains (RHDNs)} is queried and covers all domains that are related to the currently processed domain \textit{d}. Specifically, all domains which ever resolved to an IP address that is residing in any of the ASNs of those IPs that \textit{d} currently resolves to.
There are three types of features extracted from the database for \textit{Notos} that are used for training the reputation model (quotation from \fsCite[Section 3.1]{Antonakakis:2010:BDR:1929820.1929844}):
\begin{quote}
\begin{enumerate}
\item \textbf{Network-based features:} The first group of statistical features is extracted from the set of RHIPs. We measure quantities such as the total number of IPs historically associated with \textit{d}, the diversity of their geographical location, the number of distinct autonomous systems (ASs) in which they reside, etc.
\item \textbf{Zone-based features:} The second group of features we extract are those from the RHDNs set. We measure the average length of domain names in RHDNs, the number of distinct TLDs, the occurrence frequency of different characters, etc.
\item \textbf{Evidence-based features:} The last set of features includes the measurement of quantities such as the number of distinct malware samples that contacted the domain \textit{d}, the number of malware samples that connected to any of the IPs pointed by \textit{d}, etc.
\end{enumerate}
\end{quote}
Figure~\ref{fig:notos_system_overview} shows the overall system architecture of \textit{Notos}. After all the features are extracted from the passive DNS database and prepared for further steps, the reputation engine is initialized. \textit{Notos'} reputation engine is operating in two modes. In offline mode, the reputation model is constructed for a set of domains using the feature set of each domain and the classification which can be calculated using the \textit{knowledge base} with black- and whitelist (also referred as training). This model can later be used in the online mode to dynamically assign a reputation score. In online mode, the same features that are used for the initial training are extracted for a new domain (resource record or RR, see Section~\nameref{subsubsec:dns_resource_records}) and \textit{Notos} queries the trained reputation engine for the dynamic reputation rating (see Figure~\ref{fig:notos_online_offline_mode}). The data for labeling domains and IPs originates from various sources: the blacklist primarily consists of filter lists from malware services like malwaredomainlist.com and malwaredomains.com. Additional IP and domain labeling blacklists are the Sender Policy Block from Spamhaus and the ZeuS blocklist from ZeuS Tracker. The base has been downloaded before the main analyzation period (fifteen days from the first of August 2009)and as filter lists usually lag behind state-of-the art malware, the blacklists have continuously been updated. The whitelist was built using the top 500 popular Alexa websites. The 18 most common second level domains from various content delivery networks for classifying the CDN clusters and a list of 464 dynamic DNS 2LD for identifying domains and IPs in dynamic DNS zones.
\begin{figure}[!htbp]
\centering
\includegraphics[width=.9\textwidth, clip=true]{content/Evaluation_of_existing_Systems/Notos/Notos_System_overview.png}
\caption{Notos: System overview \fsCite[Figure 1]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_system_overview}
\end{figure}
\begin{figure}[!htbp]
\centering
\includegraphics[width=.9\textwidth, clip=true]{content/Evaluation_of_existing_Systems/Notos/Notos_offline-online_mode.png}
\caption{Notos: online and offline mode \fsCite[Figure 3]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_online_offline_mode}
\end{figure}
\subsection{Features}
\label{subsec:notos_features}
In this Section, all statistical features are listed and a short explanation, for what reason those have been chosen, is introduced.
The first group of features handles network-related keys. This group mostly describe how the owning operators of \textit{d} allocate network resources to achieve different goals. While most legitimate and professionally operated internet services feature have a rather stable network profile, malicious usage usually involves short living domain names and ip addresses with high agility to circumvent blacklisting and other simple types of resource blocking. Botnets usually contain machines in many different networks (\glspl{as} and \glspl{bgp}) operated by different organizations in different countries. Appropriate companies mostly acquire bigger ip blocks and such use consecutive IPs for their services in the same address space. This homogeneity also applies to other registration related information like registrars and registration dates. To measure this level of agility and homogeneity, eighteen statistical network-based features are extracted from the RHIPs (see Table~\ref{tab:notos_network-based_features}).
\begin{table}[!htbp]
\centering
\caption{Notos: Network-based features}
\label{tab:notos_network-based_features}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\textbf{Feature Source} & \textbf{Feature} \\ \hline
\multirow{9}{*}{\textit{BGP}} & \# of distinct BGP prefixes related to \(BGP(A(d))\) \\ \cline{2-2}
& \# of countries in which these BGP prefixes reside \\ \cline{2-2}
& \# of organizations that own these BGP prefixes \\ \cline{2-2}
& \# of distinct IP addresses in the sets \(A_{3LD}(d)\) \\ \cline{2-2}
& \# of distinct IP addresses in the sets \(A_{2LD}(d)\) \\ \cline{2-2}
& \# of distinct BGP prefixes related to \(BGP(A_{3LD}(d)\) \\ \cline{2-2}
& \# of distinct BGP prefixes related to \(BGP(A_{2LD}(d)\) \\ \cline{2-2}
& \# of countries in which \(BGP(A_{3LD}(d)\) \\ \cline{2-2}
& \# of countries in which \(BGP(A_{2LD}(d)\) \\ \hline
\multirow{3}{*}{\textit{ASN}} & \# of distinct autonomous systems related to \(AS(A(d))\) \\ \cline{2-2}
& \# of distinct autonomous systems related to \(AS(A_{3LD}(d)\) \\ \cline{2-2}
& \# of distinct autonomous systems related to \(AS(A_{2LD}(d)\) \\ \hline
\multirow{6}{*}{\textit{Registration}} & \# of distinct registrars associated with the IPs in the \(A(d)\) set \\ \cline{2-2}
& diversity in the registration dates related to the IPs in \(A(d)\) \\ \cline{2-2}
& \# of distinct registrars associated with the IPs in the \(A_{3LD}(d)\) \\ \cline{2-2}
& \# of distinct registrars associated with the IPs in the \(A_{2LD}(d)\) \\ \cline{2-2}
& diversity in the registration dates for the IPs in \(A_{3LD}(d)\) \\ \cline{2-2}
& diversity in the registration dates for the IPs in \(A_{2LD}(d)\) \\ \hline
\end{tabularx}
\end{table}
The second group is about zone-based features and is extracted from the RHDNs. In contrast to the network-based features which compares characteristics of the historic IPs, the zone-based features handles characteristics of all historically involved domains. While legitimate services often involve many domains, they usually share similarities. ``For example, google.com, googlesyndication.com, googlewave.com, etc., are all related to Internet services provided by Google, and contain the string 'google' in their name.''. In contrast, randomly generated domains used in spam campaigns are rarely sharing similarities. By calculating the mean, median and standard deviation for some key, the ``summarize [of] the shape of its distribution'' is investigated \fsCite[Section 3.2.2]{Antonakakis:2010:BDR:1929820.1929844}. To calculate this level of diversity, seventeen features are extracted which can be found in Table~\ref{tab:notos_zone-based_features}:
\begin{table}[!htbp]
\centering
\caption{Notos: Zone-based features}
\label{tab:notos_zone-based_features}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\textbf{Feature Source} & \textbf{Feature} \\ \hline
\multirow{12}{*}{\textit{String}} & \# of distinct domain names in RHDNs \\ \cline{2-2}
& average \# of distinct domain names in RHDNs \\ \cline{2-2}
& standard deviation of \# of distinct domain names in RHDNs \\ \cline{2-2}
& mean of the occurrence frequency of each single character in the domain name strings in RHDNs \\ \cline{2-2}
& median of the occurrence frequency of each single character in the domain name strings in RHDNs \\ \cline{2-2}
& standard deviation of the occurrence frequency of each single character in the domain name strings in RHDNs \\ \cline{2-2}
& mean distribution of 2-grams (i.e. pairs of characters) \\ \cline{2-2}
& median distribution of 2-grams \\ \cline{2-2}
& standard deviation of 2-grams \\ \cline{2-2}
& mean distribution of 3-grams (i.e. triples of characters) \\ \cline{2-2}
& median distribution of 3-grams \\ \cline{2-2}
& standard deviation of the distribution of 3-grams \\ \hline
\multirow{5}{*}{\textit{TLD}} & \# of distinct TLD strings of each domain \(d_i\) in the RHDNs set \\ \cline{2-2}
& ratio between \# of domains \(d_i\) whose \(TLD(d_i)=".com"\) and the total \# of TLD different from ".com" \\ \cline{2-2}
& mean of the occurrence frequency of the TLD strings \\ \cline{2-2}
& median of the occurrence frequency of the TLD strings \\ \cline{2-2}
& standard deviation of the occurrence frequency of the TLD strings \\ \hline
\end{tabularx}
\end{table}
For the evidence-based features, public information and exclusively collected data from honeypots and spam-traps is collected. This \textit{knowledge base} primarily helps to discover if a domain \textit{d} is in some way interacting with known malicious IPs and domains. As domain names are much cheaper than ip addresses, malware authors tend to reuse IPs with updated domain names. The blacklist features detect the reuse of known malicious resources like IP addresses, \gls{bgp} prefixes and \glspl{as}.
\begin{table}[!htbp]
\centering
\caption{Notos: Evidence-based features}
\label{tab:notos_evidence-based_features}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\textbf{Feature Source} & \textbf{Feature} \\ \hline
\multirow{3}{*}{\textit{Honeypot}} & \# of distinct malware samples that, when executed, try to contact \(d\) or any IP address in \(A(d)\) \\ \cline{2-2}
& \# of malware samples that contact any IP address in \(BGP(A(d)\) \\ \cline{2-2}
& \# of samples that contact any IP address in \(AS(A(d))\) \\ \hline
\multirow{3}{*}{\textit{Blacklist}} & \# of IP addresses in \(A(d)\) that are listed in public IP blacklists \\ \cline{2-2}
& \# of IPs in \(BGP(A(d)\) that are listed in public IP blacklists \\ \cline{2-2}
& \# of IPs in \(AS(A(d))\) that are listed in public IP blacklists \\ \hline
\end{tabularx}
\end{table}
\begin{figure}[!htbp]
\centering
\includegraphics[width=.9\textwidth, clip=true]{content/Evaluation_of_existing_Systems/Notos/Notos_features.png}
\caption{Notos: Computing network-based, zone-based, evidence-based features \fsCite[Figure 2]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_features}
\end{figure}
\todo{not referenced atm}
\subsection{Reputation Engine}
\label{subsec:notos_reputation_engine}
The reputation engine is used to dynamically assign a reputation score to a domain \textit{d}. In the first step, the engine has to be trained with the available training set (temporal defined as the \textit{training period}). The training is performed in an offline fashion which means all data is statically available at the beginning of this step. The training mode consists of three modules: The \textit{Network Profile Model} is a model of how known good domains are using resources. This model uses popular content delivery networks (e.g., Akamai, Amazon CloudFront) and large sites (e.g., google.com, yahoo.com) as a base. In total the \textit{Network Profile Model} consists of five classes of domains: \textit{Popular Domains}, \textit{Common Domains}, \textit{Akamai Domains}, \textit{CDN Domains} and \textit{Dynamic DNS Domains}. The second module \textit{Domain Name Clusters} performs a general clustering of all domains (respectively their statistical feature vectors) of the training set. There are two consecutive clustering processes: The \textit{network-based} clustering aims to group domains with similar agility characteristics. To refine those clusters, a \textit{zone-based} clustering is performed which groups domains that are similar in terms of its RHDNs (see explanation for the \textit{zone-based features}). Those clusters of domains with similar characteristics can then be used to identify mostly benign and malicious sets of domains. In the last step of the offline mode, the \textit{Reputation Function} is build. As seen in Figure~\ref{fig:notos_online_offline_mode} this module takes the results of the \textit{Network Profile Model} (\(NM(d_i)\)) and the \textit{Domain Name Clusters} (\(DC(d_i)\)) for each domain \textit{d} in \(d_i, i = 1..n\) as inputs, calculates an \textit{Evidence Features Vector} \(EV(d_i)\), which basically checks if \(d_i\) or any of its resolved IPs is known to be benign or malicious, and builds a model that can assign a reputation score between zero and one to \textit{d}. This \textit{Reputation Function} is implemented as a statistical classifier. These three modules form the reputation model that can be used in the last step to compute the reputation score. A rebuild of the training model can be done at any time, for example given an updated training set.
The final stage of the reputation engine is the online (streaming like) mode. Any considered domain \textit{d} is first supplied to the \textit{network profiles} module which returns a probability vector \(NM(d) = \{c_1, c_2, ..., c_5\}\) of how likely \textit{d} belongs to one of the five classes (e.g. probability \(c_1\) that \textit{d} belongs to \textit{Popular Domains}). \(DC(d)\) is the resulting vector of the \textit{domain clusters} module and can be broken down into the following parts: For the domain \textit{d} of interest, the network-based features are extracted and the closest network-based cluster \(C_d\), generated in the training mode by the \textit{Domain Name Clusters} module, is calculated. The following step takes all zone-based feature vectors \(v_j \in C_d\) and eliminates those vectors that do not fulfill \(dist(z_d , v_j ) < R\), where \(z_d\) is the zone-based feature vector for \textit{d} and \textit{R} being a predefined radius; or \(v_j \in KNN(z_d)\), with \(KNN(z_d)\)) being the k nearest-neighbors of \(z_d\). Each vector \(v_i\) of the resulting subset \(V_d \subseteq C_d\) is then assigned one of this eight labels: \textit{Popular Domains}, \textit{Common Domains}, \textit{Akamai}, \textit{CDN}, \textit{Dynamic DNS}, \textit{Spam Domains}, \textit{Flux Domains}, and \textit{Malware Domains}. The next step is to calculate the five statistical features that form the resulting vector \(DC(d) = \{l_1, l_2, ..., l_5\}\).
\begin{enumerate}
\item \(l_1\) the \textit{majority class label} \textit{L}, i.e. the most common label in \(v_i \in V_d\) (e.g. \textit{Spam Domains})
\item \(l_2\) the standard deviation of the occurrence frequency of each label
\item \(l_3\) mean of the distribution of distances between \(z_d\) and the vectors \(v_j \in V_{d}^{(L)}\), where \(V_{d}^{(L)} \subseteq V_d\) is the subset of those vectors, associated with the \textit{majority class label} \textit{L}
\end{enumerate}
Having the \textit{Network Profile Model} \(NM(d)\), the \textit{Domain Name Clusters} \(DC(d_i)\), and the \textit{Evidence Features Vector} \(EV(d)\), these vectors are combined into a sixteen dimensional feature vector \(v(d)\) which is then fed into the trained reputation function. This results in a reputation score \textit{S} in the range of [0, 1], where values close to zero represent a low reputation and such more likely represent malicious usage of the domain.
\subsection{Results}
\label{subsec:notos_results}
In the last Section of the evaluation of \textit{Notos}, experimental results that have been published are listed. This covers metrics about the usage of raw data, lessons learned in the analyzation process (i.e. examined algorithms) and final acquisitions like precision and accuracy of the classification.
\textit{Notos} being the first dynamic reputation system in the context of domain names, it is able to identify malicious domain names before they appear in public filter lists. To be able to assign reputation scores to new domains, \fsAuthor{Antonakakis:2010:BDR:1929820.1929844} used historic passive dns logs of a time span of 68 days with a total volume of 27,377,461 unique, successful A-type resolutions mainly from two recursive ISP DNS servers in North America (plus pDNS logs from various networks, aggregated by the SIE \ref{subsec:notos_architecture}). Figure~\ref{fig:notos_volume_new_rr} shows that after a few days, the number of new domains (RR) stabilizes at about 100,000 to 150,000 new domains a day compared to a much higher total load of unique resource records (about 94.7\% duplicates) (see Figure~\ref{fig:notos_total_volume_unique_rr}). The amount of new IPs is analogously nearly constant. After few weeks, even big content delivery networks with a large (but nearly constant) number of IP addresses will get scanned, in contrast to botnets where continuously new machines are infected. The authors follow that a relatively small pDNS database is therefor sufficient for \textit{Notos} to produce good results.
\begin{figure}[!htbp]
\centering
\includegraphics[width=.9\textwidth, clip=true]{content/Evaluation_of_existing_Systems/Notos/Notos_new-RR.png}
\caption{Notos: Volume of new unseen RRs \fsCite[Figure 7b]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_volume_new_rr}
\end{figure}
\begin{figure}[!htbp]
\centering
\includegraphics[width=.9\textwidth, clip=true]{content/Evaluation_of_existing_Systems/Notos/Notos_total-RR.png}
\caption{Notos: Total volume of unique RRs \fsCite[Figure 7a]{Antonakakis:2010:BDR:1929820.1929844}}
\label{fig:notos_total_volume_unique_rr}
\end{figure}
To get optimal results with the \textit{Reputation Function}, several classifiers have been tested and selected for the given circumstances (time complexity, detection results and precision [true positives over all positives]). A decision tree with Logit-Boost strategy has shown to provide the best results with a low false positive rate (FP) of 0.38\% and a high true positive rate (TP) of 96.8\%. These results have been verified using a 10-fold cross-validation with a reputation score threshold of 0.5. For this validation, a dataset of 20,249 domains with 9,530 known bad RR has been used. As the list of known good domains, the Alexa top 500 websites have been used. Taking a bigger amount of Alexa popular sites has shown to decrease accuracy of the overall system, i.e. 100,000 entries showed a TP of 80.6\% and a FP of 0.6\%. To compare \textit{Notos}' performance with static filter lists, a pre-trained instance has been fed with 250,000 unique domains collected on 1. August 2009. 10,294 distinct entries have been reported with a reputation score below 0.5. 7,984 of this 10,294 or 77.6\% could be found in at least one blacklist (see Section~\nameref{subsec:notos_architecture} for a list of included blacklists). The remaining 22.4\% could not be precisely revealed. It is worth stating that 7,980 of the 7,984 confirmed bad domain names were assigned a reputation score of less than or equal to 0.15.
\subsection{Limitations}
\label{subsec:notos_limitations}
As \textit{Notos} is mainly using historic DNS information, new domain names that resolve to IP addresses with previously unseen prefixes, can not be reliably classified. Once IPv6, with its huge address space, will get the overall standard, a precise reputation score based on the fine grain IP address features will get harder.

0
Thesis/content/Evaluation_of_existing_Systems/Notos_System_overview.png → Thesis/content/Evaluation_of_existing_Systems/Notos/Notos_System_overview.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 145 KiB

After

Width:  |  Height:  |  Size: 145 KiB

0
Thesis/content/Evaluation_of_existing_Systems/Notos_features.png → Thesis/content/Evaluation_of_existing_Systems/Notos/Notos_features.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 58 KiB

After

Width:  |  Height:  |  Size: 58 KiB

0
Thesis/content/Evaluation_of_existing_Systems/Notos_new-RR.png → Thesis/content/Evaluation_of_existing_Systems/Notos/Notos_new-RR.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 50 KiB

After

Width:  |  Height:  |  Size: 50 KiB

0
Thesis/content/Evaluation_of_existing_Systems/Notos_offline-online_mode.png → Thesis/content/Evaluation_of_existing_Systems/Notos/Notos_offline-online_mode.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 87 KiB

After

Width:  |  Height:  |  Size: 87 KiB

0
Thesis/content/Evaluation_of_existing_Systems/Notos_total-RR.png → Thesis/content/Evaluation_of_existing_Systems/Notos/Notos_total-RR.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 69 KiB

After

Width:  |  Height:  |  Size: 69 KiB

1
Thesis/content/Evaluation_of_existing_Systems/Notos/notos_evidence_based_features.tgn Normal file
View File

@@ -0,0 +1 @@
{"rows_views":[[{"style":{"borders":"ltrb","font_style":{"bold":true},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}},{"style":{"borders":"ltrb","font_style":{"bold":true},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}}],[{"style":{"borders":"ltrb","font_style":{"italic":true},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}},{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}}],[{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}},{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}}],[{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}},{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}}],[{"style":{"borders":"ltrb","font_style":{"italic":true},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}},{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}}],[{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}},{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}}],[{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}},{"style":{"borders":"ltrb","font_style":{},"text_color":"","bg_color":"","halign":"left","valign":"middle","padding":{"top":10,"right":5,"bottom":10,"left":5}}}]],"model":{"rows":[[{"value":"Feature Source","cspan":1,"rspan":1},{"value":"Feature","cspan":1,"rspan":1}],[{"value":"Honeypot","cspan":1,"rspan":3},{"value":"# of distinct malware samples that, when executed, try to contact d or any IP address in A(d)","cspan":1,"rspan":1}],[{"value":"","cspan":1,"rspan":-1},{"value":"# of malware samples that contact any IP address in BGP (A(d))","cspan":1,"rspan":1}],[{"value":"","cspan":1,"rspan":-2},{"value":"# of samples that contact any IP address in AS(A(d))","cspan":1,"rspan":1}],[{"value":"Blacklist","cspan":1,"rspan":3},{"value":"# of IP addresses in A(d) that are listed in public IP blacklists","cspan":1,"rspan":1}],[{"value":"","cspan":1,"rspan":-1},{"value":"# of IPs in BGP (A(d)) that are listed in public IP blacklists","cspan":1,"rspan":1}],[{"value":"","cspan":1,"rspan":-2},{"value":"# of IPs in AS(A(d)) that are listed in public IP blacklists","cspan":1,"rspan":1}]]},"theme":null,"fixed_layout":false}

1
Thesis/content/Evaluation_of_existing_Systems/Notos/notos_network_based_features.tgn Normal file
View File

File diff suppressed because one or more lines are too long

1
Thesis/content/Evaluation_of_existing_Systems/Notos/notos_zone_based_features.tgn Normal file
View File

File diff suppressed because one or more lines are too long

4
Thesis/content/Introduction/Introduction.tex
View File

@@ -7,6 +7,8 @@ The domain name system (\gls{dns}) has been one of the corner stones of the inte
\section{Motivation}
\label{sec:motivation}
\todo{also check papers for motivations}
\section{Challenges}
\label{sec:challenges}
@@ -28,4 +30,4 @@ The task of this work is to evaluate existing scoring mechanisms of domains in t
\lstinputlisting[language={java}, label=lst:sendImpliciteIntent,caption=Intent - Bild anzeigen]{res/src/sendImpliciteIntent.java}
%\lstinputlisting[language={java}, label=lst:sendImpliciteIntent,caption=Intent - Bild anzeigen]{res/src/sendImpliciteIntent.java}

6
Thesis/glossar.tex
View File

@@ -41,6 +41,12 @@
description={The Border Gateway Protocol, also known as the Exterior-Gateway-Protocol (EGP), is the protocol to connect different Autonomous Systems in the Internet. Is is used to share several information for IP blocks to allow routing between different Autonomous Systems.}
}
\newglossaryentry{whois}
{
name={Whois},
description={Whois is a protocol, used to gather information about owners of domains in the domain name system and IP addresses, specified in RFC 1834.}
}
\newacronym{sri-nic}{SRI-NIC}{Stanford Research Institute - Network Information Center}
\newacronym{dns}{DNS}{Domain Name System}

0
literature/EXPOSURE_Finding Malicious Domains Using Passive DNS Analysis_2014.pdf → literature/EXPOSURE_Finding Malicious Domains Using Passive DNS Analysis_2014_a_service.pdf
View File