Dns.exe

[Taneka Tarring]

Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation.

SIGRed (CVE-2020-1350) is a wormable, critical vulnerability in the Windows DNS server that affects Windows Server versions 2003 to 2019 and can be triggered by a malicious DNS response. Because the service is running in elevated privileges (SYSTEM), an attacker that successfully exploits it is granted Domain Administrator rights. This can effectively compromise the entire corporate infrastructure.

The .exe extension on a filename indicates an executable file. Executable files may, in some cases, harm your computer. Therefore, please read below to decide for yourself whether the dns.exe on your computer is a Trojan that you should remove, or whether it is a file belonging to the Windows operating system or to a trusted application.

The process known as FTP Serv-U Daemon or Domain Name System (DNS) Server belongs to software Microsoft Windows Operating System or Serv-U by Microsoft (www.microsoft.com) or Cat Soft (www.cat-soft.com).

Is dns.exe a virus? No, it is not. The true dns.exe file is a safe Microsoft Windows system process, called "FTP Serv-U Daemon".However, writers of malware programs, such as viruses, worms, and Trojans deliberately give their processes the same file name to escape detection. Viruses with the same file name are for example TrojanDownloader:Win32/Small (detected by Microsoft), and BKDR_SERVU.BH or Cryp_Xed-12 (detected by TrendMicro).
To ensure that no rogue dns.exe is running on your PC, click here to run a Free Malware Scan.

If dns.exe is located in a subfolder of C:\Windows\System32, the security rating is 56% dangerous. The file size is 707,584 bytes (75% of all occurrences) or 442,880 bytes.The program has no visible window. It is not a Windows core file. The process listens for or sends data on open ports to a LAN or the Internet. The dns.exe file is located in the Windows folder, but it is not a Windows core file.Dns.exe is able to hide itself.

If dns.exe is located in a subfolder of C:\Windows, the security rating is 70% dangerous. The file size is 707,584 bytes.The program is not visible. The dns.exe file is an unknown file in the Windows folder. It is not a Windows core file. The process uses ports to connect to or from a LAN or the Internet.Dns.exe is able to hide itself.

Important: Some malware disguises itself as dns.exe, particularly when not located in the C:\Windows\System32 folder. Therefore, you should check the dns.exe process on your PC to see if it is a threat. We recommend Security Task Manager for verifying your computer's security. This was one of the Top Download Picks of The Washington Post and PC World.

Summary: Average user rating of dns.exe: based on 5 votes with 3 user comments.3 users think dns.exe is essential for Windows or an installed application.One user thinks it's probably harmless.One user thinks dns.exe is dangerous and recommends removing it.

A clean and tidy computer is the key requirement for avoiding problems with dns. This means running a scan for malware, cleaning your hard drive using cleanmgr and sfc /scannow, uninstalling programs that you no longer need, checking for Autostart programs (using msconfig) and enabling Windows' Automatic Update. Always remember to perform periodic backups, or at least to set restore points.

Should you experience an actual problem, try to recall the last thing you did, or the last thing you installed before the problem appeared for the first time. Use the resmon command to identify the processes that are causing your problem. Even for serious problems, rather than reinstalling Windows, you are better off repairing of your installation or, for Windows 8 and later versions, executing the DISM.exe /Online /Cleanup-image /Restorehealth command. This allows you to repair the operating system without losing data.

To help you analyze the dns.exe process on your computer, the following programs have proven to be helpful: Security Task Manager displays all running Windows tasks, including embedded hidden processes, such as keyboard and browser monitoring or Autostart entries. A unique security risk rating indicates the likelihood of the process being potential spyware, malware or a Trojan. Malwarebytes Anti-Malware detects and removes sleeping spyware, adware, Trojans, keyloggers, malware and trackers from your hard drive.

In our active directory we are observing very high number of Event Log ID 5156 for dns.exe service which is getting generated from location system32/dns.exe to specific internal IPs. Our active directory server is also our DNS server.

I'm getting a large number of "RDP communication over nonstandard port" with a wide range of parent processes and commandline entries as well as inconsistent ports. Some examples include process of dns.exe on port 53 (making it sound like RDP over DNS), Java.exe on port 80, and even port 445 with no process. It will occasionally give me the commandline that triggered the detection, but most of the time I get nothing more than what I gave in my examples.

@SEV0218 For rule "Protocol Mismatch - detected RDP communication over non-standard port [E0517]", it is important to identify if it is inbound or outbound events causing the detections.

You can see the same issue you are speaking of has been addressed in this post here:

Its very likely that you have ports exposed to the internet, and public IP Addresses are performing port scans of your public IPs and testing what is hosted on each port (AKA Service Scan). This can lead to inbound connections on ports like DNS (53) where the port is tested to see what is on. This will lead to RDP communication being seen on port 53 and other ports, as they are being tested to see if they host RDP on those ports. Its likely the port scans are also working to see if other services like SMTP, DNS, SMB, etc... are on any ports visible to the public.

I highly recommend auditing what ports you need exposed to the internet and work towards closing any ports which should not be exposed to the internet. For ports you cannot close, you should work towards restricting who and what can access those ports.

The systems showing the dns.exe process were domain controllers, so it's not unusual. These systems specifically look to be triggered by the SIEM, however. The problem I have now is that there doesn't seem to be a way to write an exclusion for the source IP that triggered the alert, only the local application.

Since it is from internal IPs, you should verify if those IPs have Vulnerability scanners or software which may be port/service scanning (some software proactively does silent services scans on the network to identify remote machines and it can be hard to identify which software is doing this).

Its more than just the TCP handshake. Its the TCP handshake followed by the initial request of RDP or SMB which ends before any real info is transferred. Service based port scans send the minimum amount of information required to attempt and identify what service may be hosted on a port.

Is there a place where I can veiw a detection where it will give me similar terminology as the advanced exclusions? I would like to better understand the formatting/syntax of the exclusion language. My fear is that I will inadvertently make too broad of an exclusion.

Unusual File Modification by dns.exeedit Identifies an unexpected file being modified by dns.exe, the process responsible for Windows DNS Server services, which may indicate activity related to rem...

I have a windows 2003 server that has AD installed with DNS. When i uninstall DNS from the control panel->Add/Remove Programs->Add/Remove Windows Components->Networking Services, the file C:\windows\system32\dns.exe remains. I cannot delete it, some process re-adds it within a few seconds. Can anyone explain why this file does not uninstall when the DNS component is removed?

Why do you want to delete this file?Installing or removing features from windows 2003 are just activating or deactivating them. If the files are not present they will be copied to the system, but on remove those files wont be removed. For what? If you remove the DNS service, the server don't act as name server and don't give any answers.

Today, in the Threat Hunting Content section, we would like to draw your attention to the community rule by Lee Archinal, which helps to detect when dns.exe crashes and could uncover attempted CVE-2020-1350 exploitation: =1

This rule can be paired with other CVE-2020-1350 detections to receive a better picture of the surrounding activity. Yes, dns.exe crashing could be due to configuration errors or other administrative tasks but could also be a sign of something malicious.

Detects an unexpected process spawning from dns.exe which may indicate activity related to remote code execution or other forms of exploitation as seen in CVE-2020-1350 (SigRed). This rule is adapted from _creation/proc_creation_win_dns_susp_child_process.yml

Initial Access consists of techniques that use various entry vectors to gain their initial foothold within a network. Techniques used to gain a foothold include targeted spearphishing and exploiting weaknesses on public-facing web servers. Footholds gained through initial access may allow for continued access, like valid accounts and use of external remote services, or may be limited-use due to changing passwords.

Adversaries may leverage external-facing remote services to initially access and/or persist within a network. Remote services such as VPNs, Citrix, and other access mechanisms allow users to connect to internal enterprise network resources from external locations. Access to Valid Accounts to use the service is often a requirement, which could be obtained through credential pharming or by obtaining the credentials from users after compromising the enterprise network.

c80f0f1006