Focusing on threat actors' behaviors is more effective for detecting re-entry attempts than relying on simple indicators.
Targeted threat actors who are tasked with infiltrating and maintaining access to organizations frequently attempt to re-enter a network if they cannot meet their objective before being evicted. The re-entry may occur hours, days, or weeks after the containment and eradication of the threat group. Relying on previously observed simple threat indicators rarely helps detect future intrusions because the threat group will leverage tools with new hashes and new network infrastructure. Organizations need to be vigilant about re-entry attempts — not seeing the attempts likely means they were missed and the threat actors are already back inside the enterprise. To avoid becoming a repeat victim, organizations need to focus their detection efforts on identifying threat actors’ behaviors.
Case study
Dell SecureWorks Counter Threat Unit™ (CTU) researchers conducted an incident response engagement to investigate threat actors logging in to the organization’s VPN solution to access the network. Two months after a successful eviction, which involved remediating the access vectors and changing credentials, the Red Cloak endpoint detection and response technology detected the PlugX malware running on a system (see Figure 1). CTU researchers suspected the activity was part of a re-entry attempt and used Red Cloak to quickly investigate. The threat actors likely resorted to using a backdoor like PlugX because the organization had configured all remote access solutions to use two-factor authentication (2FA).
Figure 1. PlugX detection event. (Source: Dell SecureWorks)
The process tree showed the malicious code was running in the context of the legitimate msiexec.exe Windows process (see Figure 2).
Figure 2. PlugX process tree. (Source: Dell SecureWorks)
The suspicious starter.exe process running out of the %ALLUSERSPROFILE% directory started the process that contained the PlugX code. Basic information about starter.exe indicated that it contained a valid digital signature and was part of Kaspersky’s antivirus software (see Figure 3). The threat actors likely selected Kaspersky antivirus software because signed security software would be ignored during an investigation. They did not attempt to blend in by using software native to the environment, as the victim used a different antivirus solution. The technique of running a legitimate, typically digitally signed, program and replacing one of its legitimate DLLs with a malicious one that loads shell code is referred to as “DLL side loading.” That malicious shellcode payload is often injected into a legitimate Windows process like svchost.exe, msiexec.exe, or explorer.exe.
Figure 3. Basic file information about starter.exe. (Source: Dell SecureWorks)
Using the file hash shown in Figure 3, CTU researchers identified additional suspicious activity occurring minutes before the PlugX detection. The process tree in Figure 4 shows the chain of events leading to the installation of the malware. The Resume.chm file was likely delivered via a spearphishing email sent to a member of the talent acquisition team.
Figure 4. Suspicious process tree. (Source: Dell SecureWorks)
The PlugX backdoor was installed via a malicious Microsoft Compiled HTML Help (CHM) file that used Microsoft HTML Application Host (mshta.exe) to run a Visual Basic script. The s.vbs script wrote and executed a self-extracting RAR archive (a.exe), which in turn launched the starter.exe process.
After identifying the installation method and payload, CTU researchers investigated the persistence mechanism used by the malware on the Windows XP system. The legitimate signed Kaspersky binary persisted as a Windows service and was set to start every time the system was booted (see Figure 5).
Figure 5. Persistence mechanism. (Source: Dell SecureWorks)
CTU researchers reviewed the network connections established by the processes involved in running the malware. The PlugX backdoor attempted to connect to IP address 23.245.4.46 on port 443 (see Figure 6).
Figure 6. PlugX network connections. (Source: Dell SecureWorks)
Analysis of the netflow data captured by Red Cloak revealed that the malware attempted to connect to its command and control (C2) server using UDP, but there was no response (see Figure 7). CTU researchers determined that although the malware was successfully installed, the netflow data indicated that no operators interacted with the compromised system.
Figure 7. PlugX netflow. (Source: Dell SecureWorks)
CTU researchers searched for evidence of similar activity across the enterprise by querying for observed persistence mechanisms, parent-child process relationships, and network activity. This search revealed two additional compromised systems whose network connections to the same C2 IP address (see Figure 8) indicated that they were involved in the re-entry activity and in scope for investigation and remediation. By investigating and subsequently remediating all affected systems, the organization was again able to completely evict the threat actors from its network.
Figure 8. Additional PlugX netflow. (Source: Dell SecureWorks)
Conclusion
Organizations need to focus on detecting malicious or suspicious behaviors instead of attempting to hunt and respond using simple indicators like hashes, domains, and IP addresses. If the victim in the case study had solely relied on previously known threat indicators to detect the re-entry, then they would have overlooked the activity. Threat groups frequently change tools and network infrastructure after being discovered to avoid detection during the re-entry. However, it is likely that the threat group’s tactics, techniques, and procedures (TTPs) will remain constant because people are creatures of habit and in some cases are trained to operate in a specific way.