This article is the third in our series of articles introducing DNSMon in the production of threat intelligence (Domain Name IoC).

As a basic core protocol of the Internet, DNS protocol is one of the cornerstones for the normal operation of the Internet.

DNSMon, which was born and raised on the foundation of DNS protocol, naturally has a broad vision and can be involved in security incidents that happen in different industries or different platforms. In our first two blog posts of DNSMon's series, the Skidmap mentioned in the first article was infected with cloud hosts on Linux platform; while the second article mentioned a set of domain names issued after the Windows platform of an Internet cafe was infected; this article is a case involving Android platform. We believe this is the beauty of using DNS data, no matter what platform the bad guys are using, the knowledge points or rules used by DNSMon do not fundamentally change.

Blocking the unknown threat

Recently, we noticed that DMSMon has marked a set of structurally similar domains and automatically blocked them starting from 2021-01-10.

Going into the system to check the collected information, we see that this is a set of malicious domains related to Android platform.

Expanding Similar Domains

Using the rdata and other data of the automatically blocked domains, we found that DNSMon actually warned of more than the 5 domains listed above, there are 16 domains in this category in total.


In terms of active time, these 16 domains are put into use sequentially and have a relatively intensive launch period in January 2021.

In the course of writing this article, we have seen other new similar domains captured by our system such as antdaugh[.] top, ngslalatfin[.] top, etc., but for the sake of consistency, these new domains will be omitted from this article.

Reasons for autoblocking

In the first article, we mentioned that

The core of DNSMon is to cross-compare the massive DNS data with the security-related data owned by 360 (including whois, web, sandbox, honeypot, certificate, etc.) and analyze it to derive the threat intelligence IOC.

In the following, we analyze the data features and annotate from the whois and sandbox obtained by the system. Of course, in addition to these data, DNSMon's autoblocking process also relies on other feature data, but we will not list them here.

1. whois

The 16 domain names were registered in two batches, one on 2020-11-06 and the other on 2020-12-23; the length of validity of the registration: one year, and the privacy protection was turned on.   createddate                 2020-11-06 10:10:12   updateddate                 2020-11-06 10:20:27   expiresdate                 2021-11-06 23:59:59   status                      addPeriod | clientTransferProhibited | serverTransferProhibited  createddate                 2020-11-06 10:10:12  updateddate                 2020-11-06 10:20:20  expiresdate                 2021-11-06 23:59:59  status                      addPeriod | clientTransferProhibited | serverTransferProhibited   createddate                 2020-11-06 10:09:51   updateddate                 2020-11-06 10:15:26   expiresdate                 2021-11-06 23:59:59   status                      addPeriod | clientTransferProhibited | serverTransferProhibited
...   createddate                 2020-12-23 15:57:59   updateddate                 2021-01-06 10:37:20   expiresdate                 2021-12-23 15:57:59   status                      clientTransferProhibited    createddate                 2020-12-23 15:58:00    updateddate                 2021-01-06 10:37:23    expiresdate                 2021-12-23 15:58:00    status                      clientTransferProhibited   createddate                 2020-12-23 15:58:01   updateddate                 2021-01-06 10:37:24   expiresdate                 2021-12-23 15:58:01   status                      clientTransferProhibited

Batch registration + new domain names + short registration validity period + privacy protection, malicious possibility +1.

2. Sandbox

DNSMon's data on the sandbox focuses on the network behavior of the sample and extracts the relationship between the sample and the domain name visited, and then evaluates the score of the domain name in turn with the help of the sample's score. As can be seen from the correlation chart, the samples visiting the domains have malicious labels in the system (the samples are marked with "black dots" in the upper right corner).

According to the label propagation algorithm, 16 domains were awarded with black possibility plus points.

In order to clarify the purpose of sample propagation, we conducted a simple reverse analysis of the sample.

Reverse Analysis

This article selects a sample named “Your File Is Ready To Download.apk” as the object of analysis, and its basic information is shown below.

File type:Android
Magic:Zip archive data, at least v2.0 to extract
File size:543671 bytes

The sample Assets have a dat file that contains Base64 encoded configuration information.

And the content is


After Base64 decoding, we get the following configuration information in json format, and we can see that the "urls" field contains the domain name we want to characterize.

    "cid": "1dfbe035-d75b-43c8-bc03-da89ae9755f6",
    "urls": [
    "fn": "Your File Is Ready To Download",
    "info": "blank_",
    "routes": {
        "x86": "/x86",
        "arm64-v8a": "/arm64",
        "x86_64": "/x64",
        "armeabi-v7a": "/arm"
    "uid": "888098709355331972",
    "sid1": "888098709355331972",
    "tid": "792297",
    "sid2": ""

Download data from the domain stored in "urls" via the following code snippet.

This process can generate the following URL.


So what exactly is the download? Taking the x86 parameters as an example, the download gets a json file (f7e8f0aec32ceb27d5e202d4b2b50812), which has an apk field pointing to a new APK file (12098a59b35bcabb16bfeab887eb7f9f).

After analysis, the new APK file belongs to the FakeAdsBlocker family, a covert adware program, which has a low detection rate of 4/64 in VT at the time of this writing.

In addition, we also found another URL.


Accessing the above domain, for example, will download an APK named "synapse_x_key" (a384b97afd0f9432a71b27fa0ccd9667), which is homologous to the sample analyzed above.

The main function is to download and execute FakeAdsBlocker.

So far, the purpose of the dissemination of this batch of domain names is very clear, they are used to spread FakeAdsBlocker Downloader and FakeAdsBlocker.

New features

In the process of manually checking the URLs, we noticed a patternthat we had not seen before, that is, a string of identical URLs with randomly downloaded samples at different times, with different MD5 values for each sample file.

For example.


Randomly downloaded 3 times, the file name is "Your File Is Ready To Download.apk", but the MD5 values are.


Again, the author randomly picked another domain to test, same pattern


The file name "MobileVPN.apk", MD5 values are different.


Inspired by this, we extracted a new feature and searched the database with the new feature to find the data with the same feature in the history, such as the URL in the following figure.

Subsequently, all eligible historical data are manually statistically analyzed to determine the size of the contribution value of the new features to the judgment of the black action, and finally decide whether to merge them into the DNSMon system. It can be said that the accumulation of features is extremely important for a massive data analysis and mining system like DNSMon. It is the system that has precipitated a lot of rules in more than 6 years since 2014 that makes it possible to extract threat intelligence (domain name IOC) from the daily hundreds of billions of DNS traffic and provide security defense to end users.


Thanks to the fundamental nature of DNS, DNSMon has a broad view and can see security events occurring on Linux, Windows and Android platforms without discrimination. The main reason for this capability is that the system has accumulated a large number of security-related feature rules.

Readers should note that they should not easily imitate the process of judging the malicous in the article by themselves. Industrial IoC production includes not only the basic determination process, but also the complex processes of filtering, false alarm prevention, feedback correction, fail-safe, and automation. This article is written to facilitate the reader's understanding of the general principles of how DNSMon works, but the complexity of the various devilish details of the industrialized process is far beyond what can be described in the lines.