Hacking Book | Free Online Hacking Learning


dns attack and defense (2)

Posted by truschel at 2020-03-26



DGA (domain name generation algorithm), as the name implies, is often used to build malicious domain names, such as wannacry and xshellghost, which also use DGA domain names to avoid blacklist detection.

Previously, a paper using LSTM (short and long term memory network) to predict DGA domain name has been widely interpreted on various platforms. Basically, LSTM, an advanced algorithm based on RNN, can learn and predict new information in a large span of time area, with a high accuracy. At present, a large number of similar machine learning algorithms for predicting DGA domain names are based on the sample set of random domain names.

So the key problem is that the randomness of DGA domain name seems to bring some inconvenience to it. How to break through this randomness? Then the attacker researches and bypasses these new algorithms.

Confrontation upgrading

To solve the above-mentioned randomness problem, we can use character entropy to help judge whether it is a DGA domain name, in order to break through the characteristics of randomness. The researchers implemented a pseudo-random DGA algorithm named charbot, which successfully attacked some DGA classifiers, such as RF model named Fanci and DNN model named lstm.mi.

This character based DGA algorithm mainly uses the following three data sets as the basic input:

1. Legal secondary domain name (SLD);

2. Top level domain name (TLD);

3. A date value used as pseudo randomized seed;

Then the basic algorithm process of charbot is as follows (the specific algorithm pseudo code is shown in the figure):

1. Select a domain in the data set;

2. Select two characters in SLD (the more characters are replaced, the higher the detection rate of DGA classifier is, and the less characters are, the more registered. Two are the best intermediate values for balancing the two states;

3. Select two replacement characters (the algorithm ensures that the replacement characters are different from the original characters);

4. Add the suffixes of COM, UK, biz, FR, JP to become the top-level domain name.

This algorithm greatly reduces the detection rate of DGA classifier to randomization. However, the only obstacle to the implementation of the algorithm is that the software needs to build a large number of domain name data sets when the algorithm is built in, which results in a large increase in the file size of the software itself. However, according to the actual test, the volume of a Python code containing Alexa global data set is still smaller than that of deepdga algorithm, so this problem will not affect the deployment of charbot algorithm in malware.

There are some methods to detect the domain name generated by charbot algorithm as follows:

1. Comparing with Alexa sample, we find whether there is a phenomenon of several character substitution (Alexa sample is huge, and the attacker may not use Alexa sample, so the defense cost is too high);

2. It is not feasible to use more complex model to train processing, because it needs to be retrained regularly and there are too many objects to be processed;

3. Repeated white box antagonism training, but the parameters of antagonism learning are difficult to adjust;

4. Use information other than DGA domain name for auxiliary judgment, such as IP address, domain query frequency and time, etc.


Solution to DNS class attack

Some common official methods of blackmailing malicious domain names include DNS sinkhole and nxdomain, or mapping them to experimental IP geological classes (Class D address and class E address). But these methods are all the ways to catch the malicious domain name and then blackmail it. How to catch the malicious domain name or find the malicious DNS activity traffic in the process of emergency response? Researchers have developed several framework systems.


The PDNS (process DNS system) here is different from the PDNS (passive DNS) mentioned earlier. PDNS here is a system that can monitor DNS traffic at the process level. Its monitoring capability is mainly based on two characteristics:

1. Network characteristics

Whois information of domain name (domain name usage time, domain name registration information, domain name registration address);

IP whois information and IP physical location (as autonomous system number, IP physical location);

Authorization resolution server (TTL value of domain name)

2. Process characteristics

DNS activity information (domain name and host name, domain name resolution failure rate);

Process information (loading DLL, code signing);

The system is deployed on a background server and each terminal host that needs to be monitored. It makes up for the inaccuracy of tracing and positioning of the traditional DNS monitoring system

1. The fine-grained level of PDNS analysis is from the host level to the thread level, and the collected data is more sensitive and more conducive to model building;

2. The malicious process can be determined immediately with the process as the center;

3. Terminal deployment can improve the visibility of DNS over TLS / HTTPS;

So why does PDNS need to bind these two characteristics (network characteristics and process characteristics) for analysis? First of all, define what is software and what is process. Software can start multiple processes, which are one or one of the running entities of software.

As shown in the figure, skype.exe starts multiple processes, each process connects to Skype or Microsoft and other related domains. The 29K DNS queries collected by these processes started by Skype only correspond to 19 domains, 17 of which are registered by Microsoft or Skype. In addition to Skype's domain name registered in Ireland (ie), they are registered only under four organizations and only in the United States (US). The program DNS profile also shows the correlation between the software publisher of the program and the Registrar of the domain that the program accesses.

The code signature information of skype.exe identifies the software publisher as Skype software SARL. Accordingly, the DNS whois record confirms that most DNS queries have "Skype" or "Microsoft" as the registrant, and that the registrant is ultimately the same company. Skype software runs in a graphical interface, allowing users to interact. So it can be seen from the information that Skype is a legitimate software without malicious behavior.

Mal.exe has the opposite characteristics. It accesses about 20 different domains, and all domains are registered under different organizations in different geographical locations, and some domains are nxdomain. Although malware is properly signed, the code signer hardly matches the domain registrar. Malware runs mainly as a background process without loading GUI and user interaction DLLs. This information shows that it is a software that has executed malicious behavior in general rate.

The basic operation process of PDNS system is as follows:

1. The agent loading the monitoring client intercepts and monitors the activity behavior in DNS traffic;

2. The agent will also obtain process information (loaded DLLs, code signing) from the kernel;

3. The agent transfers the acquired information to the backend server;

4. The backend server obtains the external network feature information;

5. The backend server obtains DNS historical activity information;

After the background server of PDNS obtains the above-mentioned complex information, it will throw it to the built-in machine learning algorithm for analysis and judgment. Finally, it will give the result whether there is the outgoing or incoming DNS traffic of the malware, and can accurately trace the specific host and process information of the malware. In order to find the best classifier, researchers use 2015-2017 malware samples as input to test several training models. From the view of training results, we can find that random forest algorithm (RF) has the highest accuracy in judging malware.

There are two problems in the above process, one is how to capture all DNS activities, the other is how to link the captured DNS activities with the process.

The software usually performs domain name resolution through two channels:

1. UDP communication with resolution server;

For this channel, you can use network tracking tools, such as Princeton's open source project for the phone (which itself can associate each captured package with the process ID).

2. The software considers that the resolution is directly delegated to the DNS resolution function of the system itself;

Capture the communication data between the process and the resolution server or read the log file generated by the local service.

For Linux hosts, developers generally do not use the DNS resolution service inside Linux, so they can capture and read directly through the phone. For Windows systems, developers generally use the DNS client service provided by windows. Therefore, in Windows 8 and below, PDNS will block lprc communication for analysis, while in Windows 8.1 and above, PDNS can be read directly from the log of DNS client service.

So why is it not feasible to use DNS client service log in Windows 8 and below? This is because there are some bugs in the logging function.

DNS log problem

To solve the problem of logging for DNS client service in Windows platform, SCZ wrote in the blog about why some lower versions of windows could not log DNS logs properly. I analyzed the existing DLL component, dnsrslvr.dll. The basic process is no longer detailed.

    In short, there are two problems. The first one is to directly search for the keyword "dnsrs" in strings through decompilation. You can see the file names of two slightly different log files, dnsrslvr.log and dnsrsvlr.log. It is obvious that the component names dnsrsvlr.log and dnsrslvr.dll do not match very well, so in short, this is a misspelled word, but it does not affect the log record Abnormal key.

    The second is that in the key function dnslonit() called by dnslonit(), a condition judgment is made when entering the function body. The judgment is based on a global variable, loggingmode, which has been defined once in dnslonit(). The initialization value is 0. After exiting dnslonit(), it returns to the initialization value 0. Then, the condition judgment cannot be passed in the main body of dnslonit() function, and it directly exits Out of function, so the DNS log cannot be recorded normally.

After testing and analysis, kb2956577 patch installed, the problem will not exist. SCZ's blog also describes how you can normalize this feature without installing a patch.

DNS record tricks

There is a little-known side of "DNS domain transmission vulnerability", which is often used to mine sub domain names in DNS. We are well known that DNS is an alternative protocol in TCP / IP stack, because it occupies 53 ports of both TCP and UDP. In rfc1035, there are only two cases where DNS will use TCP 53 port. One is to use TCP 53 port for data synchronization during domain transmission operation, while UDP is preferred for DNS resolution query. When UDP fails to complete the query (that is, the query data is too large, more than 512 bytes), TCP query will be converted. Therefore, monitoring the DNS data transmission over the TCP protocol will improve the accuracy a lot, but the amount of capture will not be very much.

Microsoft's new solution

The new version of Sysmon provides event ID 22: dnseek (DNS query), that is, whenever a DNS request is sent, the log will be recorded, and the configuration is simple and clear. Please refer to https://github.com/swiftonsecurity/sysmon-config.

Confrontation upgrading

Just a few days after the new upgrade of Sysmon, a utilization article about bypassing Sysmon's DNS logging was published. After reading the next article, you can know that after Sysmon is started, you can find a data collector set of my event trace session, which once appeared in the sample code provided by Microsoft.

Use the reverse to find the function of the string for analysis. The function provides a data pointer, which is found to be exactly the data pointer used by dns_client.

So we can directly customize a simple DNS query function, and then debug it dynamically to find the clue. In debugging, you can find that the evenwrite function is called from the stack information.

Evenwrite will call evenwritetransfer to write to the log after the end of evenwrite, so we just need to modify the DLL to avoid evenwritetransfer.


Interest or malice?

Use DNS to track user behavior and keep sessions uninterrupted. This technology mainly solves the problem of short DNS cache time, and breaks through the restriction that cookies and other technologies cannot continue to track in the multi browser and browser privacy mode, and is not affected by VPN, Socks4, IPv6, enterprise family bucket software package (the fingerprint of the computer in the enterprise cluster is almost the same), etc. However, the technology itself has some limitations, so it needs to be combined with the traditional tracking technology (such as the tagging technology represented by cookies and the computer fingerprint recognition technology such as font recognition) in order to make the most of it.

The red part in the figure is the actual controllable component part of the tracker.

1. The browser loads the trace code fragment;

2. The browser requests the operating system's stub resolver to resolve the xi.anonymity.fail domain name;

3. The operating system passes the resolution request to the resolution platform, which knows that it needs to resolve to the DNS resolver controlled by the domain name owner. And the DNS resolver responds to RRset, which is a series of randomly ordered tracers' controllable IP addresses;

4. Stub resolver caches RRset and returns IP address list to browser;

5. The browser sends HTTP request to the first IP address in RRset;

6. The server sends different response contents to different IP addresses;

7. JS collects data from the server and assembles it into an ID;

For this tracking method, only using HTTP proxy or tor proxy can definitely invalidate it.

From here we can find that a technology itself is not right or wrong, but the purpose of its users determines whether there is malice. The tracking technology still has some technical details. I have written in detail in this official account DNS Cache-Based User Tracking.


[email protected]



[1] Woodbridge, J., Anderson, H. S., Ahuja, A., & Grant, D. (2016). Predicting domain generation algorithms with long short-term memory networks. arXiv preprint arXiv:1611.00791.

[2] Peck, J., Nie, C., Sivaguru, R., Grumer, C., Olumofin, F., Yu, B., ... & De Cock, M. (2019). CharBot: A Simple and Effective Method for Evading DGA Classifiers. arXiv preprint arXiv:1905.01078.

[3] Sivakorn, S., Jee, K., Sun, Y., Kort-Parn, L., Li, Z., Lumezanu, C., ... & Li, D. (2019). Countering Malicious Processes with Process-DNS Association. In NDSS.

[4] Pupeng (2015, Feb, 20). Hone [Web log post]. Retrieved August 01, 2019, from https://github.com/pupeng/hone

[5] SCZ. (2017, May 11). DNS series (10) -- Open DNS client service log [Web log post]. Retrieved June 24, 2019, from http://scz.617.cn/windows/201705111519.txt

[6] Microsoft. (2019, June 14). Sysmon v10.1 [Web log post]. Retrieved June 15, 2019, from https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

[7] Good news: Microsoft released Sysmon [Web log post] with DNS query logging function. Retrieved June 13, 2019, from https://mp.weixin.qq.com/s/0xkyo5nobxv9lsyb97fhjg

[8] SwiftOnSecurity. (2019, May 10). Sysmon-config [Web log post]. Retrieved May 11, 2019, from https://github.com/SwiftOnSecurity/sysmon-config

[9] Chester A.(2019, June 15). Evading Sysmon DNS Monitoring [Web log post]. Retrieved June 16, 2019, from https://blog.xpnsec.com/evading-sysmon-dns-monitoring/

[10] DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. (1987, November). Retrieved June 5, 2019, from https://www.ietf.org/rfc/rfc1035.txt

[11] Klein A., Benny P. (2019). DNS Cache-Based User Tracking. In NDSS.

About the security academic circle, please contact [email protected] if you are interested in joining the academic circle