Take a Product Tour Request a Demo Cybersecurity Assessment Contact Us

Blogs

The latest cybersecurity trends, best practices, security vulnerabilities, and more

Detecting and Visualizing Lateral Movement Attacks with Trellix XDR - Part 2

Executive summary

In the part 1 of this series we discussed in depth about the known Lateral movement attacks like abusing weak service permissions (T1574.011), NTDS.dit file dumping and exfiltration over the network (T1003.003). We also discussed how Trellix XDR can bring detections from multiple data sources together for better visualization of the attack path and assets involved.

Lateral Movement techniques discussed in our previous blog have been used by multiple threat actors in the past as mentioned in the MITRE Technique page. We have also been observing multiple alerts for these methods in the customer environments indicating that they are still being used actively in the enterprise network. Below highlights the NTDS.dit file exfiltration attempt alerts from the multiple environments and industry sectors as reported by Trellix telemetry data.

Figure 1: Trellix telemetry data for NTDS.dit exfiltration attempt
Figure 1 : Trellix telemetry data for NTDS.dit exfiltration attempt

Trellix Telemetry also reported several alerts for fileless lateral movement techniques as shown below.

Figure 2: Trellix telemetry data for Fileless lateral movement attempt
Figure 2 : Trellix telemetry data for Fileless lateral movement attempt

Trellix XDR has been consistently evolving in its capabilities of detecting and correlating lateral movement activities across multiple assets, helping analysts visualize attack flow. In this blog, we will look at additional lateral movement techniques like Kerberoasting ( used to steal user or service credentials ) and DCOM ( used to execute remote code ) while demonstrating how Trellix XDR can help detect and correlate alerts across Endpoint and Network to visualize a full attack path.

Kerberoasting : Attack flow

Kerberoasting is another post exploitation technique in which an attacker attempts to bruteforce the credentials of the service account in the active directory domain, having Service Principal Name set. Any authenticated user with the valid domain credentials can enumerate service accounts with SPNs set. Once the attacker acquires the interesting service account SPNs, weak encrypted kerberos service tickets can be requested for them. These service tickets can then be dumped from the cache and brute forced offline to recover the service account credentials. These credentials can then be used to access the service with higher privileges impersonating a domain user.

Below is the typical Kerberoasting attack flow visualizing stages of the attack.

Figure 3: Kerberoasting attack flow
Figure 3: Kerberoasting attack flow

Assuming the attacker has compromised the domain user and has acquired domain credentials, a typical first step in the Kerberoasting attack is to enumerate the service accounts with the Service Principal Name (SPN) set. Service Principal Names are the unique identifier of the service account in the domain used for kerberos authentication. For instance, If SPNs are configured for the user accounts, they are visible as under in the Active Directory.

Figure 4: Service principal names in AD user objects
Figure 4: Service principal names in AD user objects

Authenticated attacker can enumerate SPNs in the domain using impacket’s GetUserSPNs.py or by writing a custom script using the following LDAP filter. Requesting the service accounts set with SPNs using LDAP enumeration will result into following:

Figure 5: Scanning for SPNs
Figure 5: Scanning for SPNs

Once discovering the service accounts with SPNs, the attacker can use the following powershell commands to request the weak encrypted Kerberos service tickets ( TGS ) for the specific SPN.

PS>$spn = 'MSSQLSvc/sqlserver.trellixdemo.com:1433'
PS>Add-Type -AssemblyName System.IdentityModel
PS>New-Object System.IdentityModel.Tokens.KerberosRequestorSecuritToken -ArgumentList $spn
Figure 6: Powershell commands to request TGS

Above powershell commands will result into the TGS request to acquire kerberos ticket for the discovered SPN which will be visible when the kerberos tickets are enumerated on the compromised system using “klist” command as shown below :

Figure 7:  Klist command output on the compromised host
Figure 7: Klist command output on the compromised host

Subsequently, the cached kerberos tickets can be dumped to the disk using offensive tools like mimikatz which can then be exfiltrated and brute forced offline to recover service account credentials.

 Figure 8 :  Exporting Kerberos TGSs and bruteforce using tgsrespcrack.py
Figure 8: Exporting Kerberos TGSs and bruteforce using tgsrespcrack.py

Detection - Trellix XDR insights and alert correlation

Trellix XDR shows alerts providing insight into multiple stages of the Kerberoasting attack. Figure 9 shows the alert provided by Trellix Network Security, when the SPN scanning activity is done on the network. This Network event is then forwarded to XDR for threat correlation.

Figure 9: Network Security alert for SPN Scanning
Figure 9: Network Security alert for SPN Scanning


Figure 10:  XDR alert for SPN scanning
Figure 10: XDR alert for SPN scanning

Trellix XDR also provides an alert when the weak encrypted Kerberos TGS tickets are requested from the Domain Controller providing the visibility into suspicious kerberos activity. This becomes extremely important and allows multiple activities to be correlated across data sources.

Figure 11: XDR alert for weak kerberos Ticket Request
Figure 11: XDR alert for weak kerberos Ticket Request

When the kerberos ticket is dumped on the disk using Mimikatz or other tools, Trellix Extended Detection and Response (EDR) detects the ticking dumping activity providing appropriate process level details which can eventually be used in response actions.

Figure 12: EDR alert Kerberos Ticket dump on disk
Figure 12: EDR alert Kerberos Ticket dump on disk

Detecting and responding to lateral movement attacks has been a challenge due to the lack of accurate visualizations of the attack path. Figure 13 shows how XDR brings this information from multiple data sources into one place. It shows the view of the attack cycle along with alerts associated with assets.

Figure 13: visualization of assets involved in the attack
Figure 13: visualization of assets involved in the attack

Lateral movement with DCOM ( Excel Application ) - Attack flow

DCOM enables remote communication between software components that communicate across the network, essentially  enabling a client application to remotely instantiate and use the methods of a COM server object on another system. It uses TCP/IP for network communications and runs on top of the remote procedure call (RPC) transport mechanism.

DCOM configuration information is kept in the Windows Registry using three identifiers:

  • CLSID or Class ID: Serving as a distinct ID for each Windows component, typically contained in registry “HKEY_CLASSES_ROOT\CLSID\{CLSID value}”
  • ProgID: Unlike CLSID, ProgID is not a sophisticated GUID format but a human understandable format like “Excel.Application”
  • APPID: The AppID identifies all the classes that are part of the same executable and the permissions needed to access it

Below visualizes the DCOM communication attack flow between client and server.

Figure 14: DCOM Attack flow
Figure 14: DCOM Attack flow

As a prerequisite for the DCOM attack, an attacker would need an ability to write a file in the system PATH and Microsoft Excel installed  on the target system. Successful attack consists of following steps:

  • Adversary uploads an arbitrary malicious file with a well-chosen file name (like “FOXPROW.EXE”) within a well-chosen PATH on target system
  • Adversary creates an Excel instance on remote system via DCOM
  • Adversary executes ActivateMicrosoftApp method, to achieve execution of (fake) FOXPROW.EXE
  • On successful attack, Excel.exe would spawn (fake) FOXPROW.EXE at the target system

Microsoft still allows the activation of some end of life (EOL) offerings, like FoxPro, Schedule Plus, and Office Project; shell access may be obtained via the ActivateMicrosoftApp() method. While it's unlikely that any of these obsolete programs will find their way into modern setups, we could exploit this vulnerability to execute persistence and lateral movement strategies.

As shown below  “ActivateMicrosoftApp()” method activates the running application and the function launches a new instance of the application as the starting user or the currently logged in user, depending on how DCOM was configured, if the application is not running.

Figure 15: Excel’s DCOM Methods
Figure 15: Excel’s DCOM Methods

Figure 16: ActivateMicrosoftApp() method parameters
Figure 16: ActivateMicrosoftApp() method parameters

This method looks for the related binary in the SYSTEM path. The Excel.exe process tried to search the system PATH for the FOXPROW.exe binary file, but since the program isn't installed, it gave an error instead. We must locate write rights inside the system PATH in order to abuse this. The place on the PATH where users most frequently have write permission is:

C:\users\*\AppData\Local\Microsoft\WindowsApps\

Since January 2010, the FoxPro application has been discontinued, and it is improbable that it may be found in any modern environments. Therefore, our malicious code will execute and grant us access to the target system if we are able to upload a malicious binary with the name "FOXPROW.exe" and place it in the mentioned folder.

Figure 17: Copy File on Target Machine
Figure 17: Copy File on Target Machines


Figure 18: Create an object on the remote computer, the client provides a request with the CLSID, PROGID or APPID.
Figure 18: Create an object on the remote computer, the client provides a request with the CLSID, PROGID or APPID.


Figure 19: ActivateMicrosoftApp() Method Call
Figure 19: ActivateMicrosoftApp() Method Call

This technique could be used for persistence once we have established a foothold on a machine that has Microsoft Office installed. Attacker can potentially develop a PowerShell script that initializes an instance of the Excel.Application object via DCOM and invokes the ActivateMicrosoftApp() method on the localhost and then create a schedule task.

Figure 20: Scheduled task to execute
Figure 20: Scheduled task to execute

Detection - Trellix XDR insights and correlation

Trellix XDR shows several alerts providing insight into multiple stages of the attack. Figure 11 and 12 shows the detailed alert provided by Trellix Endpoint Detection and Response (EDR) for non-persistence Method, when a malicious program known as "FOXPROW.exe" tries to be uploaded and then abused by the malware itself through the use of the “ActivateMicrosoftApp()” function.

Figure 21: File Created
Figure 21: File Created


Figure 22: DCOM Lateral Movement alert
Figure 22: DCOM Lateral Movement alert

Trellix Endpoint Detection and Response (EDR) is detecting all stages of attacks for the persistence method highlighting the process activity as shown below.

Figure 23 : Process Tree Created on Trellix EDR
Figure 23: Process Tree Created on Trellix EDR

On the compromised machine, Powershell script execution was identified by EDR.

Figure 24: EDR alert for powershell Script Execution  R
Figure 24: EDR alert for powershell Script Execution R

Moreover, EDR detects scheduled task to be executed as visualized in Figure 25.

Figure 25: EDR alert for Scheduled Task Execution
Figure 25: EDR alert for Scheduled Task Execution

When examining this behavior from the network perspective, we can demonstrate the alert that detected the Lateral Movement attempt. This greatly helps in alert correlation and threat visualization.

Figure 26: Suspicious File Creation
Figure 26: Suspicious File Creation


Figure 27 : Network alert for DCOM Lateral Movement Attempt
Figure 27: Network alert for DCOM Lateral Movement Attempt

Below visualization shows how XDR brings this information together showing consolidated view of the threat activity. The activity was first identified on the endpoint, the assets involved, and the alerts associated with them.

Figure 28: DCOM Lateral Movement Attack Path
Figure 28: DCOM Lateral Movement Attack Path

Conclusion

You need the full picture of a threat in order to improve your efficacy and efficiency. Helix Connect (the Trellix XDR engine) integrates security controls from the Trellix XDR platform and over 490 third-parties to create deep multi-vector threat detections and prioritized, AI-guided responses to threat events.
Data is ingested from multiple sources, then correlated by pre-built analytics and rules to create multi-vector, multi-vendor detections so you can rapidly see the complete story of an attack and immediately investigate and respond with high confidence. Helix Connect creates AI-powered context that enables users of any skill level to Investigate threats with AI guidance and UI-driven, point and click automation.

To learn more about Helix Connect and the Trellix XDR platform, take our product tour to see it in action or read more by visiting this page.

Ref:- https://specterops.io/blog/2023/10/30/lateral-movement-abuse-the-power-of-dcom-excel-application/

Get the latest

We’re no strangers to cybersecurity. But we are a new company.
Stay up to date as we evolve.

Please enter a valid email address.

Zero spam. Unsubscribe at any time.