As an integral part of our job, we have the opportunity to look into the network communication of many different types of companies. During audits, we have come across all sorts of different misconfigurations and malicious activities. Today, we will look at what to look out for in the area of\u00a0DNS<\/span>.<\/strong><\/p> When you type\u00a0www.greycortex.com<\/em><\/a>\u00a0into your web browser, you assume that you are accessing our\u00a0GREYCORTEX<\/span>\u00a0website.<\/p> What you see depends, among other things, on the\u00a0DNS<\/span>\u00a0translation, which translates the name\u00a0www.greycortex.com<\/a><\/em>\u00a0into the numeric form of the\u00a0IP<\/span>\u00a0address:\u00a091.239.201.14<\/em>.<\/p> The\u00a0DNS<\/span>\u00a0server that controls this translation also controls the destination\u00a0IP<\/span>\u00a0address and the server to which the user is redirected. Whoever sees the\u00a0DNS<\/span>\u00a0queries for a\u00a0particular device can see what servers the device connects to \u2013 what services it uses or what it\u00a0does.<\/p> The following are the most common problems we see in\u00a0DNS<\/span>\u00a0management:<\/p> In many networks, we see an\u00a0open port 53<\/strong>\u00a0from the internal network to the Internet without any restrictions. This means that any device on the internal network can connect to any other device on the Internet. This is used by both attackers and legitimate applications, which can be a\u00a0problem from a\u00a0security perspective.<\/p> Attackers can use an open port 53 to the Internet\u00a0to create a\u00a0DNS<\/span>\u00a0tunnel<\/strong>. They can then\u00a0send any data<\/strong>\u00a0through it. For example, using\u00a0Iodine<\/a>\u00a0software, they can create an\u00a0IP<\/span>\u00a0layer on top of the application\u2019s\u00a0DNS<\/span>\u00a0protocol and then use port 53 to transmit arbitrary data or create a\u00a0reverse\u00a0SSH<\/span>\u00a0tunnel from the Internet to the internal network. This creates\u00a0permanent access<\/strong>, which\u00a0allows an attacker to return to the internal network<\/strong>\u00a0at any\u00a0time.<\/p> Specifically, in the case of Iodine software, the created\u00a0IP<\/span>\u00a0layer is transmitted hidden in strings that represent a\u00a0third-order domain. From the perspective of a\u00a0network communications analyst, the client is communicating with a\u00a0legitimate\u00a0DNS<\/span>\u00a0server on the internal network, but a\u00a0closer look at the transmitted data will show that this is not the\u00a0case.<\/p> Let\u2019s have a\u00a0look at this data in\u00a0GREYCORTEX<\/span>\u00a0Mendel. As an example, there\u2019s a\u00a0device with the\u00a0IP<\/span>\u00a0address 10.0.2.30 that is sending\u00a0DNS<\/span>\u00a0queries to an internal\u00a0DNS<\/span>\u00a0server with the\u00a0IP<\/span>\u00a0address 10.0.2.20. In the figure below, you can see an example of several queries in the application\u2019s log data itself that query the domain name\u00a0pirate.sea<\/em>. The third-order domain name changes in each query and also looks very strange at first glance. Note also that the\u00a0rrtype<\/a>\u00a0attribute contains an unusual\u00a0NULL<\/span><\/em>\u00a0value.<\/p> An example of a\u00a0legitimate use of an open port 53 is some antivirus products. For example, one of Avast\u2019s products has a\u00a0DNS<\/span>\u00a0secure<\/strong>\u00a0(now Real Site) feature. This is\u00a0designed to prevent\u00a0DNS<\/span>\u00a0hijacking attacks<\/strong>\u00a0in which an attacker spoofs a\u00a0DNS<\/span>\u00a0record of a\u00a0user, which then leads the user to a\u00a0malicious server. When the\u00a0DNS<\/span>\u00a0secure feature is enabled, the antivirus sends\u00a0DNS<\/span>\u00a0requests to its own\u00a0DNS<\/span>\u00a0servers, thereby preventing\u00a0DNS<\/span>\u00a0record spoofing.<\/p> Thus, the\u00a0client device bypasses the internal\u00a0DNS<\/span>\u00a0server<\/strong>\u00a0and sends\u00a0DNS<\/span>\u00a0queries to the server directly via the Internet. From a\u00a0network traffic perspective, you then see outbound traffic to the external server on port 53. Since the communication is encrypted, you will not see the\u00a0DNS<\/span>\u00a0name that the client requested resolving.<\/p> This functionality may be desirable when connecting devices to public wi-fi networks, but\u00a0in a\u00a0corporate environment, it can pose a\u00a0problem<\/strong>\u00a0when tracking and monitoring\u00a0DNS<\/span>\u00a0traffic.<\/p> For auditing\u00a0DNS<\/span>\u00a0communication and the long-term monitoring and data collection needed to address security events, we recommend you:<\/p> During audits, we encountered a\u00a0situation where\u00a0two domains were being<\/strong>\u00a0used on the internal network. This happened when it was not possible to migrate the old domain to the new systems. So, the administrators decided to create a\u00a0new domain. The old domain was\u00a0company.com,<\/em>\u00a0then the new version was created with a\u00a02v extension:\u00a0company2v.com<\/em>.<\/p> At first glance, this may seem like a\u00a0harmless change. However, the problem was that the\u00a0administrators did not register the new domain<\/strong>\u00a0with the domain administrator, then another entity registered it.<\/p> What implications might this case\u00a0have?<\/p> One day, the administrator decides they want to see the web traffic going out to the Internet. They use a\u00a0proxy server and set it up automatically using a\u00a0Windows\u00a0GPO<\/span>\u00a0(Group Policy Object). In this case, the stations start trying to connect to a\u00a0server named\u00a0wpad.company2v.com<\/em>\u00a0for their new domain. Devices with an external\u00a0DNS<\/span>\u00a0server set up, which the firewall lets onto the Internet, redirect the device to a\u00a0DNS<\/span>\u00a0server that is authorized for the\u00a0company2v.com<\/em>\u00a0domain. These servers are on the Internet and are not owned by the customer.<\/p> The problem is that the\u00a0actual owner<\/strong>\u00a0of the\u00a0company2v.com<\/em>\u00a0domain\u00a0manages all\u00a0DNS<\/span>\u00a0records<\/strong>\u00a0for that domain. Therefore, they can ensure that devices from the internal network connect to a\u00a0proxy server on the Internet when trying to obtain a\u00a0proxy configuration. It is then possible to carry out, for example, a\u00a0MITM<\/span>\u00a0attack<\/strong>. Now, the attacker is only one step away from\u00a0delivering ransomware<\/strong>\u00a0to this client. And the ransomware can look like an executable file that the user originally wanted to download, for example,\u00a0firefox.exe<\/em>.<\/p> During an audit, we recommend looking into:<\/p> We frequently encounter typos in these\u00a0DNS<\/span>\u00a0server\u00a0IP<\/span>\u00a0addresses:<\/p> If the\u00a0DNS<\/span>\u00a0server is configured incorrectly, the device cannot perform a\u00a0DNS<\/span>\u00a0translation. For devices that are used daily, the problem will be quickly detected. But the problem can occur with devices where the\u00a0DNS<\/span>\u00a0is configured manually, like cameras or sensor systems. Such a\u00a0configuration error can prevent security updates<\/strong>\u00a0of the device.<\/p> In the figure below, you can see an example from the Mendel system where it detected thirteen devices trying to send\u00a0DNS<\/span>\u00a0queries to the\u00a0IP<\/span>\u00a0address\u00a08.8.6.6.\u00a0<\/em>However, there is no\u00a0DNS<\/span>\u00a0server at this\u00a0IP<\/span>\u00a0address and, therefore, the translations are unsuccessful.<\/p>An Unlimited Open Port\u00a053<\/strong><\/h2>
![](\"https:\/\/i0.wp.com\/www.greycortex.com\/sites\/default\/files\/perm\/image\/unlimited-open-port-53.png?w=1200&ssl=1\")
<\/a><\/p>When to Have an Open Port\u00a053?<\/h3>
You Do Not Really Own Your Own Domain<\/strong><\/h2>
Misspellings in\u00a0DNS<\/span>\u00a0Server\u00a0IP<\/span>\u00a0Addresses<\/strong><\/h2>
![](\"https:\/\/i0.wp.com\/www.greycortex.com\/sites\/default\/files\/perm\/image\/ip-address-typos.png?w=1200&ssl=1\")
<\/a><\/p>