Written by: Randy Pargman and James Quinn
Threat actors spend a lot of time and energy to evade and defeat detections on their victims’ network. Threat hunters and other defenders should be aware of the sneaky techniques that are most often used and adjust their tactics to catch the threats and put a stop to their access. In this blog post, we’ll cover some of the evasion techniques that we see threat actors using and describe how threat hunters can improve their detections.
Through the Eyes of the Attacker
First, it’s important to approach threat hunting from the perspective of someone trying to break into your network. Understanding what motivates the attacker can help you anticipate some of the tricks they might try. If you’ve never participated in penetration testing or been on a red team before, it’s a good idea to partner with someone who has experience in offensive security or take a class to learn some attack techniques.
Our Threat Hunting team also gains information about how attackers approach network exploitation by looking at the features advertised on underground forums and criminal marketplaces for services and tools that are advertised specifically to help attackers operate without being detected.
Fully Undetectable (FUD) to Anti-Virus
One of the most popular services offered on criminal marketplaces is called “Crypting.” Service providers promise that they can take any Remote Access Trojan (RAT) or other malware payload and pack it into an encrypted delivery file that will be “Fully Undetectable” or “FUD” to all antivirus programs for a guaranteed amount of time. For different prices ranging from a few dollars to tens of dollars per crypt, vendors offer to re-encrypt the sample if any antivirus product alerts on it before the guaranteed time is expired (from a few hours to a few days).
FUD Malware: Threat Hunter Response
Does this mean you shouldn’t keep your antivirus definitions up to date? Certainly not—antivirus is still one of the foundations of a good endpoint security control program and is necessary to protect against most threats. However, when malware is targeted directly at your organization, the attacker only needs to spend a few dollars to ensure that your antivirus will not set off any alarms or quarantine the program. The malware might take advantage of this limited time window to disable antivirus on the endpoint, or it might inject its code into a new thread in a legitimate, signed and trusted process. So, be sure your system alerts you if antivirus is disabled on any endpoint, and if you have an EDR solution that can detect injection into other processes, that’s another great way to detect malicious behavior (although it can result in a lot of false positive alarms).
Loaders – Using Office Files and Trusted Processes
Loaders, another popular service advertised on underground forums, are typically full-service malware delivery mechanisms that infect computers with extremely lightweight malware programs that are constantly evolved and upgraded to completely avoid detection by antivirus, EDR agents, and threat hunters. The purpose of a loader is to act as a beachhead, quietly downloading other malware payloads through a complex network, often using compromised servers around the world to host the downloads and avoid suspicion. They may supply a web-based control panel and all the features needed by a threat actor to deliver their final payload precisely to targeted computers. One recent example is the Buer loader, which was documented by Proofpoint in a blog in December 2019. The Buer loader makes use of Excel or Word document files with macros that launch trusted operating system processes such as secinit.exe and regsvr32.exe to execute malware downloaded from a constantly changing list of hosting servers.
Loaders: Threat Hunter Response
Knowing that the programs used by loaders to launch malware will likely be legitimate, signed and trusted system processes, Threat Hunters need to prepare by making sure the logs they capture from endpoints contain more information about process execution than just the path to the program itself and whether it was signed or detected as a threat. It’s critical to capture details such as the parent process that launched each process and the command-line arguments used to start each process. Knowing that Excel launched secinit.exe and then secinit.exe launched regsvr32.exe is crucial to being able to spot this malicious behavior. Other information such as DLLs that were loaded, files accessed, and registry keys written to all provide additional valuable context for a query to differentiate between a non-malicious use of a program such as regsvr32.exe and a malicious use.
Masking Intrusions in the Noise of DNS
Another particularly stealthy technique employed by threat actors is the use of DNS tunneling to mask communication with the Command and Control (C2) server. While uncommon in commodity malware, this technique sees more use with more advanced threat actors and can be used to evade network-based detections, especially if logging is improperly set up.
DNS tunneling is fairly simple in theory and is dependent on the use of TXT records by DNS servers. TXT records for DNS are unstructured text records of up to 255 bytes in size. As there can be an unlimited amount of individual TXT records on a server, files larger than 255 bytes can be stored and then concatenated together. Typically, using “A records” for data exfiltration, and “TXT records” for command and file transfer, malware will stealthily tunnel all network communication over DNS.
An example communication exchange can be found below:
Malware will communicate over port 53 to threat actor owned DNS, tunneling data through the use of “A records.” This does not require the malware to communicate directly to the attacker’s DNS server, because any request made to the victim company’s internal DNS server or any public DNS server will be recursively sent on until it arrives at the attacker’s authoritative DNS server and the reply will be relayed back (and cached for some time) at the DNS servers along the path.
Example:
- ComputerName.AccountName.OsVersion.Password.domain.com
Next, the malware will request the TXT record for the DNS, sometimes using built in tools like NsLookup.exe. The C2 will reply with the necessary data to control the bot.
DNS: Threat Hunter Response
Before detecting DNS Tunneling, defenders must ensure that they are logging DNS queries. Although it is typically a configuration option, some of the most common DNS logging configuration options for internal DNS servers include:
Bind8/9
- Enable querylog using ndc/rndc, respectively.
Windows DNS
- Debug Logging
– Legacy logging system
– Must be enabled in Properties > Debug Logging
– Can be configured to display various key indicators like data sent/received - Analytic Logging
– Current Logging System
– Uses Event Tracing for Windows
– Generates an Event every time the server sends or receives data
– Key Events
+ 261: Response In
+ 260: Query Out
InfoBlox DNS
The latest version of InfoBlox NIOS 8.5.1 includes the capability of high-speed DNS query logging through a feature called “dnstap” to enable service provider level logging of queries.
These logs can then be parsed and analyzed for trends using various tools such as Splunk, Elasticsearch, or any other analytic platform that scales well.
In addition to built-in logging solutions for common DNS servers, there are a variety of network Intrusion Detection Systems with built in DNS logging and parsing from network traffic, such as Suricata.
Unexpected Internal Proxies
Once a threat actor has established a foothold on a network, they will typically attempt to spread laterally to computers on the network. While they can accomplish this goal using a variety of resources, the typical choice is to use native Windows administrative tools, like RDP, to connect laterally to systems in an environment.
In environments where there is either no firewall or a firewall with RDP enabled, this is a fairly simple process that uses the built-in Windows RDP tool. However, what if a network has a few high value computers that have most connections blocked, except RDP from a specific administrative computer?
In these situations, once the actor gains access to the specific administrative computer, actors would then take advantage of tools like Putty Link or portproxy in order to proxy an RDP connection to a remote computer using an arbitrary unprotected port.
For example, using portproxy, a built in Windows tool, an attacker can quickly open an RDP connection on a remote computer on the same network as the infected machine, like so:
- netsh interface portproxy add v4tov4 listenport= 5400 listenaddress=<infectedmachineIP> connectport=3389 connectaddress=<target machine IP>
By then connecting to the infected machine with RDP over port 5400, the attacker can gain access from a remote machine to computers that it couldn’t otherwise access.
Additionally, this technique can be combined with reverse SSH tunnels to proxy RDP connections through an SSH connection in order to evade network-based detections.
Proxies: Threat Hunter Response
While network-based indicators can be limited in either of these scenarios, host-based logs are still generated when the attacker logs in using a remote connection. Specifically, Event ID 4624 with Logon type 10 is indicative of a login using Terminal Services, which is the process that controls RDP.
Additionally, understanding what is and isn’t anomalous in a network can help defenders make actionable decisions on alarms. For example, if plink.exe is not common on a network and it appears on an unexpected user’s computer, along with an SSH connection, this can be indicative of malicious activity. Even though, in the above scenario, both plink.exe and outbound SSH connections are not inherently malicious.
Proper log collection and management can help defenders create a “baseline” of the executables and network activity of their users, in order to better detect and respond to anomalous behavior.