Detecting and Visualizing Lateral Movement Attacks with Trellix XDR

By Chintan Shah, Maulik Maheta, Ajeeth S · December 13, 2023

Executive summary

With Organizations deploying multiple security controls and solutions on their network and endpoints, there is a significant gap in the way threat events from multiple sources are correlated and contextualized to enable the analyst to see the complete threat activity. Without complete contextual threat information, analyst and incident response teams are required to switch to different endpoint products and network solutions to understand the attack sequence. Additionally, with the high volume of threat events coming in from diverse security solutions, it becomes extremely difficult for analysts to connect the dots between cross-product alerts and conclude consequential and actionable attack information. This significantly impacts their ability to effectively triage, hunt for threats and apply responsive actions. This is one of the major challenges for organizations that rely on a broad set of security solutions to protect the network and critical assets in their infrastructure.

In this blog, we present multiple attack scenarios focused on lateral movement, including abuse of weak service permissions to execute code, dumping and exfiltrating credential material from Active Directory. For each scenario, we demonstrate how Trellix eXtended Detection and Response (XDR) helps detect and visualize lateral movement by providing a unified view, thereby enabling the analyst to fully assess the situation.

Introduction: XDR and lateral movement detection

The lack of accurate visualizations of the attack path, and the use of multiple security products to correlate alerts, makes detecting and responding to lateral movement attacks challenging. In the lateral movement phase of an attack, adversaries use several tools and techniques to pivot from one system to another. Their goal is to reach critical assets like Active Directory, which allows them to compromise the domain at scale.

Trellix XDR expands its capabilities beyond the conventional endpoint-focussed approach. XDR correlates threat activity across multiple security solutions, providing analysts with greater visibility into adversarial behavior. XDR unifies alerts from across the security stack, such as endpoint, network, email, and identity, providing a unified view so analysts can contextualize the attack. This improves their ability to triage and investigate alerts, and empowers them to apply remediation actions. By tightly integrating security controls with playbooks across various products, XDR is armed with response actions like purging identified phishing emails, quarantining malicious files, disabling compromised user accounts, and blocking network access from specific infected assets.

Insecure service permissions abuse

Windows has permissions and privileges for controlling access to objects like files and the registry, which includes Windows Services. During the lateral movement phase, exploiting weak or misconfigured Windows Services is one of many privilege escalation techniques used by attackers to execute malicious payloads on remote systems. This technique has been known for many years, but it is still very common to find services running on Windows with insecure permissions. Services run with the SYSTEM level privileges, and if this technique is combined with weak service binary permissions, the path of the service executable can be modified to point to an executable under the attacker’s control. This results in code execution with elevated privileges when the service restarts. Weak permissions fall into several categories, as defined by the MITRE ATT&CK Enterprise framework:

Figure 1: Insecure or weak service permissions techniques

The Windows Service Control Manager ( SCM ) provides a Remote Procedure Call ( RPC ) interface which allows any authenticated user to connect to the SCM and manipulate service parameters, such as configurations and service executables on remote machines. When the service objects are created, the SCM creates access rights for specific accounts over the service object, as documented here. To modify service parameters, an authenticated user connects to the SCM, opens a handle using the RPC call OpenSCManager, and requests the access rights to the service. The RPC call QueryServiceConfig allows an authenticated user to query service configurations, like binpath or imagepath. The RPC call QueryServiceObjectSecurity allows an authenticated user to retrieve a copy of the security descriptor associated with the service object.

Many third-party software components are potential targets because they run misconfigured services. An attacker targets vulnerable services to gain a foothold in the domain, and then enumerate services that have SERVICE_ALL_ACCESS orSERVICE_CHANGE_CONFIG permissions. These service permissions allow any authenticated user with low privileges to modify service parameters using ChangeServiceConfig, including service binary path.

Figure 2: Checking service permissions

Attack flow – Abusing weak service permissions ( MITRE TID: 1574.011)

Figure 3 shows a lateral movement attack scenario. In this example, a victim is targeted by a drive-by-download attack, or a phishing campaign. They visit a malicious URL that results in additional malware downloading onto the compromised system, giving the attacker full control of the system.Gaining control of the target system could also be a result of exploiting known or zero-day vulnerabilities. To move laterally inside the network, attackers need credentials, privileges, and access to multiple pivot systems to define their path towards critical network resources.

Figure 3: Attack flow

To synthesize this lateral movement attack flow, we assume that the attacker compromised one of the internal systems using a targeted attack campaign. They acquired domain credentials to access the pivot system, which could allow them to escalate their privileges. To abuse the remote services, the attacker performs reconnaissance, checking the service permissions and configurations. This can be done using Sysinternal’s accesschk.exe, or similar tools, as shown in Figure 4.

Figure 4: Enumerating service permissions

Using sc.exe to check the target service configuration, Figure 5 shows it executes under the LocalSystem account. This is an extensively privileged account, with its tokens having NT AUTHORITY\SYSTEM and BUILTIN\ADMINISTRATORS SIDs. It has access to most system objects inheriting the security context of the SCM. However, If the compromised user is a low privileged user, it could still allow the attacker to modify path to service binaries, given the target service has writeable privileges for the AUTHENTICATED USERS.

Figure 5: checking service configuration

Once the attacker has the information on the target service with required permissions, service manipulation frameworks like SCShell, or similar tools, can be used to modify the service binary path. SCShell uses the same set of APIs discussed previously, and modifies the executable path of the service using the PRC call ChangeServiceConfigA.

This technique can also be used as a fileless lateral movement technique, as long as the payload is not dropped on the disk in the remote system. One of the arguments to this API is BinaryPathName, which from the attacker’s perspective is useful as it allows them to specify a path to an arbitrary executable.

Figure 6 – ChangeServiceConfig parameters

As visualized in the attack flow in Figure 7, harvested credentials, or NTLM hashes, can be used in SCShell to open the remote service and abuse this parameter to supply the command which can add an administrator user to the remote machine. Once the supplied binary path is modified, the service is restarted with the RPC call StartServiceA. This API will trigger an error as the executable is not a service DLL, but the code will still execute the supplied command. At this point, the payload is executed.

Figure 7: Attack flow to add the local admin user account to remote system

Detection - Trellix XDR Insights and alert correlation

Trellix XDR shows several alerts providing insight into multiple stages of the attack. Figure 8 shows the detailed alert provided by Trellix Endpoint Detection and Response (EDR), when the service permissions were enumerated using Sysinternal’s accesschk64.exe tool to identify the service to be targeted. It also shows the process tree with the techniques observed on the endpoint during this activity.

Figure 8 : An EDR alert for service permissions check

Figure 9 shows some of the events generated on the target endpoint during activities performed as part of the attack flow visualization shown in Figure 3.

Figure 9: An EDR alert on the target endpoint

However, when we dig deeper into these events, we see the raw events capturing the exact net user add command that was executed through the SCShell utility. This was very well captured as the service registry was modified multiple times for the target service. This is as shown in Figure 10.

Figure 10: Detailed alerts view for net user command

It is critical to share this visibility on the network, as well as the endpoint. Since the service modifications is made using SCM RPC calls on the network, we will see the network alert as shown in Figure 11.

Figure 11: Network Security alert

Detecting and responding to lateral movement attacks is difficult due to the lack of accurate visualizations of the attack path, and the use of multiple security tools. Figure 12 shows how XDR brings this information into one place. It shows a consolidated view of the alert, how the activity was first identified on the network, the assets involved, and the alerts associated with them.

Figure 12 : Lateral movement path visualization

Dumping and exfiltrating Active Directory Ntds.dit file ( MITRE TID : T1003.003 )

The New Technology Directory Services Directory Information Tree file (ntds.dit) acts as the primary database file. Ntds.dit stores and organizes all information relating to domain objects, such as people, groups, computers, and so on. It serves as Active Directory’s (AD) backbone, storing vital data such as user account information, passwords, group memberships, and other object properties. Importantly, the file also contains the password hashes for all domain users. Cybercriminals who obtain these hashes can subsequently undertake Pass-the-Hash (PtH) attacks with tools like Mimikatz, or offline password cracking with programs like Hashcat. In fact, once the hashes are obtained, an attacker can pose as any user on the domain, even Domain Administrators.

On a domain controller, the Ntds.dit file is typically located in C:\Windows\NTDS\Ntds.dit. However, the location can be changed during the AD installation process to meet unique needs or preferences.

Figure 13 : The location of the NTDS file

Adversaries may try to dump credentials from the operating system and applications to get account login and credential information, typically in the form of a hash or a clear-text password. These credentials can then be used to perform lateral movement and access restricted information. OS credential dumping falls into multiple categories, represented by MITRE IDs as shown in Figure 14.

Figure 14 : OS credential dumping techniques

In OS credential dumping, NTDS Adversaries may try to gain access to, or make a copy of, the Active Directory domain database to steal credentials or other information, such as devices, users, and access rights. The default location for the NTDS file (Ntds.dit) on a domain controller is %SystemRoot%\NTDS\Ntds.dit. Adversaries may look for backups that contain the same or comparable data, in addition to searching for NTDS files on live domain controllers.

Attack flow – Data theft from a compromised endpoint: Active Directory Ntds.dit file dump and Exfiltration

Figure 15 shows an OS credentials dumping attack scenario. When a victim of a drive-by-download attack or a phishing campaign accesses a malicious URL, it may result in malware downloading onto the compromised system. This allows the attacker to gain complete system control. Controlling the target system could also be accomplished by exploiting known or zero-day vulnerabilities. As discussed previously, the attacker needs credentials to move laterally in the network. Once an attacker gains access to a compromised system that is linked to an AD server, they can use a tool to dump the Ntds.dit file, and then export it to an external server or crack password hashes locally or remotely.

Figure 15 : NTDS dump, registry hive dump and exfiltration attack flow

STEP 1 - Steal password hashes

When an attacker gains access to a network, they can retrieve password hashes using a variety of methods, such as DCSync and extracting hashes from ntds.dit. Figure 16 shows how to extract hashes from the lsass.exe process memory, which maintains hashes for users currently logged in to the system. This method requires compromising a user with administrative privileges Figure 16 : Credential dump using mimikatz

Figure 16: Credential dump using mimikatz

STEP 2 - Authenticate using a stolen password hash

The adversary then employs the Pass the Hash approach ( MITRE ID: T1550.002) to authenticate as a user using one of the stolen password hashes. Figure 17 shows how to use the stolen password hash to launch cmd.exe. The hash can also be used to access network resources supporting NTLM authentication.

The following arguments are supplied while performing pass-the-hash using mimikatz sekurlsa::pth:

• /user — The username and domain of the hacked user.
• /Domain — The domain’s FQDN, if you are using a domain account. Or “.”, if you are using a local account.
• /ntlm, /aes128, or /aes256 — The NTLM, AES-128 or AES-256 stolen password hash.
  
  Figure 17 : Pass-the-Hash using Mimikatz

STEP 3 - Access other resources

Finally, the adversary might employ their newly obtained advantages to promote their goals. Figure 18 shows how they can use the PSExec tool to run commands on remote systems to broaden their footprint, and repeat the cycle of credential theft and lateral movement on an increasing number of systems.

Figure 18 : Accessing using PSExec

STEP 4 - Dump and exfiltrate ntds.dit

If an attacker has access to the file system of a domain controller, they can exfiltrate ntds.dit and the HKEY_LOCAL_MACHINE\SYSTEM registry hive, which is required to retrieve the Boot Key for decrypting the ntds.dit file. Active Directory keeps a file system lock on the ntds.dit file while it is running, so any attempt to copy it will fail. Adversaries can get around this constraint in a number of ways, including:

• Take a snapshot of the volume with the Volume Shadow Copy Service (VSS) and extract the ntds.dit file from the snapshot.
• Using a PowerShell utility like PowerSploit’s Invoke-NinjaCopy to copy the files while they are being used.
• Using a built-in program such as DSDBUtil.exe or NTDSUtil.exe to build active directory installation media files.
  
  Figure 19 : Ntds.dit file dump

Detection - Trellix XDR Insights and alert correlation

Trellix XDR shows several alerts providing insights into multiple stages of the attack flow. Figure 20 shows the detailed alert provided by EDR when the credentials are dumped on a compromised system. It also shows the process tree with the techniques observed on the endpoint during this activity.

Figure 20: Credential access alerts

Figure 21 shows some of the events generated on the target endpoint during activities performed as per the attack flow visualization in Figure 15

Figure 21 : Credential access events
Figure 22 and Figure 23 show the detailed alerts generated by EDR when the ntds.dit and SYSTEM hive files drop on a compromised system.
Figure 22 : NTDS copy create and dump alert

Figure 23 : NTDS copy create and dump alert

Figure 24 shows an alert from Network Security. This provides network visibility for the NTDS exfiltration attempt.

Figure 24: Network alerts

When an attacker attempts to upload the ntds.dit and SYSTEM hive files to an external server, Data Loss Prevention (DLP) generates a high severity alert as shown in Figure 25.

Figure 25 : DLP alerts for NTDS exfiltration attempt

Detecting and responding to lateral movement attacks is difficult due to the lack of accurate visualizations of the attack path, and the use of multiple security tools. Figure 26 shows how XDR brings this information into one place. It shows a consolidated view of the alert, how the activity was first identified on the network, the assets involved, and the alerts associated with them.

Figure 26 : Lateral movement attack path

Conclusion

It is critical for the product ecosystem to correlate alerts to provide a unified view to analysts. Trellix XDR consolidates the data and products on the security stack, and provides analysts with an extended view of the threat, analysis, and response actions on the network. Trellix XDR is continuously evolving with newer capabilities and features to detect lateral movement threats and enable appropriate response actions. Additionally, Trellix XDR allows analysts to prioritize alerts and group related alerts together to analyze them as part of a whole. With Trellix Automated Response actions, analysts can perform repetitive and complex response actions with ease.