One of the benefits of being part of a global research-driven incident response firm like X-Force Incidence Response (IR) is that the team has the ability to take a step back and analyze incidents, identifying trends and commonalities that span geographies, industries and affiliations. Leveraging that access and knowledge against the ransomware threat has revealed tools, techniques and procedures that can often be detected through the default Windows event logs (WELs).

In particular, the X-Force IR team has identified several actions ransomware operators take that are common across almost all ransomware attacks — and are also relatively easy to detect through search queries and detection mechanisms identified by X-Force IR. This blog will review several opportunities security teams have to detect most ransomware adversaries within the default WELs. By leveraging the default WELs, many ransomware victims have the data they need to detect ransomware operators; they simply need to know where to look. That is where X-Force IR can help.

Because many ransomware affiliates interact, cross-pollinate and operate on behalf of different ransomware groups, we don’t attribute the following activities to any particular ransomware group; they are common across multiple ransomware groups. Sodinokibi/REvil, Avaddon and DarkSide ransomware groups shut down from May to July, but the affiliates that conducted attacks on behalf of these groups have shifted to new groups such as LockBit and emerging ransomware groups.

X-Force Threat Intelligence has tracked several malicious actors that have acted as affiliates of multiple groups. For example, ITG08 — also known as FIN6 — has probably acted as an affiliate for Ryuk, LockerGoga and MegaCortex attacks. In addition, ITG14, which shares campaign overlap with FIN7, has been an affiliate of Sodinokibi/REvil and was the overarching operator behind the DarkSide ransomware cartel.

The following event log entries have been present in the majority of ransomware incidents that X-Force IR has responded to and were all logged on systems with the default audit policy. While all these detections have been useful during X-Force IR engagements, there is always the possibility of false positives. Defenders should evaluate their datasets to identify possible false positives and tuning opportunities before adding to a production system.

Without a doubt, Event ID 7045 is the most important event log entry to detect ransomware operators once they have gained access to a target network. In reviewing the 2020 ransomware incidents to which X-Force IR responded, evidence of adversary activity was identified within 7045 event log entries in over 90% of the ransomware incidents where adversaries moved laterally to at least one system.

For lateral movement, adversaries will leverage the Windows Service Control Manager (SCM) to create a new service where the target file is a custom command or executable that enables remote access to the target system.

Within Cobalt Strike, adversaries can leverage the jump command to spawn a beacon on a remote host through a new service.

Figure 1: Cobalt Strike’s default listing for Jump commands

Similar capabilities exist within the Metasploit Framework, which is another offensive security tool that X-Force IR has observed ransomware operators leveraging to carry out their attacks. Evidence of Metasploit’s SCM lateral movement tools can also be detected through 7045 event log entries.

In addition to offensive security frameworks, ransomware adversaries have been observed leveraging remote access tools like PsExec, TeamViewer and ScreenConnect to carry out their operations. Evidence of these tools can also be recovered from the 7045 event log entries.

Adversaries will leverage the SCM as a privilege escalation technique by configuring the new service to run as SYSTEM.

Event ID 7045 Detection:

Table 1: Detections in Windows Event Log 7045 entries

Figure 2: Evidence of Cobalt Strike’s psexec_psh Jump command

Figure 3: Evidence of Cobalt Strike’s svc_exe elevate command

Figure 4: Evidence of ScreenConnect utility

X-Force IR has observed that ransomware operators continue to leverage a tunneled remote desktop protocol (RDP) connection to bypass network restrictions during data collection and exfiltration.

While various utilities can facilitate RDP tunneling, X-Force IR has observed that plink and ngrok are the two most common utilities used by ransomware operators. Plink (Putty link) is a command-line tool used to establish secure shell (SSH) connections to remote systems.

The following command has been used by ransomware operators to create an RDP tunnel via a batch script.

Table 2: Example plink command to enable RDP tunneling on a host

Ngrok is a utility designed specifically to enable remote access to systems behind firewalls. X-Force IR has observed adversaries masquerading ngrok as other utilities for RDP access to a target system in order to maintain persistence access to systems behind network address translation (NAT) or firewalls.

Figure 5: Ngrok entries masquerading as legitimate tools within Program Files to enable persistent remote access through tunneled RDP

Through analysis of evidence collected from incident response engagements and behavioral research performed by X-Force IR, researchers have determined that EID 4624 can be leveraged to detect a user accessing a system through a tunneled RDP connection.

Event ID 4624 Detection:

Table 3: Event ID 4624 keyword detections for RDP tunneling

Figure 6: Evidence of RDP tunneling 

Figure 7: Evidence of RDP tunneling

Once access to an enterprise network is established, ransomware operators are constantly on the hunt for privileged access to the domain, typically by targeting members of the domain administrators group. Privileged domain access grants the adversary the ability to access more data and effectively deploy the ransomware in the final stage of the attack. However, in multiple cases, X-Force IR has observed ransomware operators targeting multiple domains within a forest for ransomware deployment. X-Force IR has observed multiple ransomware operators leveraging the DCSync command within Mimikatz to access the KRBTGT account, which is used to encrypt and sign Kerberos tickets within a domain. With access to the KRBTGT account, adversaries can gain privileged access to the forest root domain and subsequently gain privileged access to all domains in the forest.

DCSync was implemented in Mimikatz (authored by Benjamin Delpy and Vincent Le Toux) back in 2015, which allowed an adversary to masquerade as a domain controller and remotely retrieve password hashes from other domain controllers without executing any code on the target domain controller.

To be executed, the adversary must have access to a domain resource with domain replication privileges — specifically ‘replicating directory changes,’ ‘replicating directory changes all,’ or ‘replicating directory changes in filtered set.’ By default, domain controllers, domain administrators and enterprise administrators have these privileges granted.

On domain controllers, Event ID 4662 is logged when an operation is performed on an object within Active Directory, and this event is normal for when objects are changed or when domain controllers need to replicate changes to other domain controllers.

In the case of a DCSync command, the adversary leverages the DS-Replication-Get-changes-All extended right within the Domain-DNS class to request data to replicate to a user or system that is not a domain controller. When this action occurs, an Event ID 4662 is logged on the target domain controller, which can be used to detect adversary activity.

Event ID 4662 Detection:

Table 4: Keyword DCSync detection in 4662 event log entries

Figure 8: Evidence of DCSync

It is worth noting that if the adversary executes DCSync as SYSTEM from another computer account, an Event ID 4662 containing the source computer account will not be available. To detect that behavior, defenders should audit the required permissions within Active Directory for unauthorized computer or user accounts.

Table 5: PowerShell Command to Audit DCSync privileges

X-Force IR has observed ransomware operators taking advantage of the remote code execution and local privilege escalation vulnerabilities within the Microsoft Print Spooler Service (a.k.a., PrintNightmare) to escalate privileges during ransomware attacks.

PrintNightmware exploits a design flaw where non-privileged users can add printer drivers to a Windows system. Attackers can exploit this vulnerability by installing a malicious printer driver, which will be executed as SYSTEM via the Print Spooler service, effectively granting the attacker SYSTEM-level permissions. Attackers targeting domain controllers are able to assume control of the entire domain through the PrintNightmare exploit.

Through observations of ransomware operator activities and continued research into the forensic evidence of the PrintNightmare exploit, X-Force IR has noted that Event ID 808 in the Print Service log is commonly present after successful exploit. Event ID 808 is logged when the Print Spooler has failed to load a plug-in module within a driver. In most cases, the referenced module is a malicious dynamic-link library (DLL) used by the attacker to execute arbitrary commands via the Print Spooler service.

Event ID 808 Detection:

Table 7: PrintNightmare detection within 808 Event Log entries

Figure 9: Evidence of PrintNightmare

Event ID 4648 is created when a process executes an account logon event by explicitly specifying user credentials. This event is commonly logged when a user leverages the runas command. In instances where runas is executed, the associated process name is svchost.exe. Additionally, an Event ID 4648 with a process name of consent.exe will be logged when user account control (UAC) is enabled and prompts for credentials prior to executing a program.

An interesting observation of the evidence collected during ransomware investigations is the fairly common presence of Event ID 4648 entries referencing AdFind within the process name. X-Force IR was only able to reproduce this behavior without executing AdFind leveraging pass-the-hash within Mimikatz, which eliminates the ability to retrieve the output of AdFind. It’s likely that Event ID 4648 entries are the result of the ransomware operator making a command execution mistake and not correlated to the standard ransomware attack life cycle. However, the presence of this evidence is common enough to note for the purposes of detection.

Event ID 4648 Detection:

Table 8: AdFind detection within 4648 Event Log entries

Figure 10: Evidence of AdFind execution

As previously mentioned, Cobalt Strike provides a jump command to assist operators with facilitating lateral movement. In addition to executing lateral movement via a new service, Cobalt Strike includes a jump command to move laterally via Windows Remote Management (WinRM).

WinRM is the native Windows remote management tool that enables administrators to manage and monitor remote servers and workstations. Within Cobalt Strike, adversaries can leverage the jump command to execute a command on a remote system over the WinRM protocol.

Figure 11: Cobalt Strike WinRM jump commands

When executed, a successful remote WinRM connection will log an Event ID 91 within the WinRM event log. Used in conjunction with the PowerShell operational log event ID 4104, researchers can detect ransomware adversaries moving laterally via WinRM.

Event ID 91 and Event ID 4104 Detection:

Table 9: Cobalt Strike WinRM jump detection within 91 and 4104 Event Log entries

Figure 12: Evidence of Cobalt Strike WinRM jump command in 91 Event Log entry

Figure 13: Evidence of Cobalt Strike WinRM jump command in 4104 Event Log entry

X-Force IR recommends that every organization centralize all Event ID 7045 event logs and build automated detections to identify malicious service installs. Various log aggregation solutions exist but Microsoft Windows provides a zero-cost native capability to centralize Windows Event Logs called Windows Event Forwarding.

In Microsoft Windows, Windows Event Forwarding (WEF) is the built-in log centralization solution. WEF enables systems within your network to forward event logs to a Windows Event Collector (WEC) server. The event logs that are forwarded to the WEC are defined within an event subscription. WEF subscriptions can be configured to be source initiated, where each system that receives the subscription will push logs to the WEC, or collector initiated, which relies on the WEC to retrieve logs from each of the systems.

The following links provide resources on how to configure a Microsoft Windows system to forward event logs to a central collection server.

https://www.ibm.com/docs/cs/qradar-on-cloud?topic=wincollect-overview

https://www.ibm.com/support/pages/qradar-agentless-windows-events-collection-using-msrpc-protocol-msrpc-faq

https://docs.microsoft.com/en-us/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection

Event ID 7045 WEF Subscription

Once WEF is enabled, X-Force IR recommends organizations implement the configurations described in this section to centralize System Event ID 7045 in order to detect ransomware operators.

From the collection server, open the Event Viewer and navigate to Subscriptions. When prompted to start the Windows Event Log Collector Service, select Yes.

Once the service is started, right click on Subscriptions, and select Create Subscription.

In the dialog box, provide a descriptive name and description to the appropriate fields and select System as the destination log. The reason for selecting the System log is that by default the Forwarded Events log is not published to Win32_NTLogEvent class and the following PowerShell script will leverage that class to monitor and automatically generate an alert when the conditions for the aforementioned Event ID 7045 detection are met.

Select the radio button next to Source computer initiated and select ‘Select Computer Groups.’

From the Select Computer Groups dialog, select the machine accounts from which you want to collect 7045 event logs.

Once the target computers are specified, select ‘Select Events’ and select ‘System’ from the event logs dropdown and enter 7045 into the Event ID filter. From the Advanced menu, select the appropriate protocol and delivery optimizations for your WEF configuration.

Select OK to save the subscription. On the next policy refresh, the target computers will begin to forward their 7045 event logs to the collection server.

Once the collector begins receiving logs, it can be manually audited using the following command.

To enable automated alerts of service installs matching characteristics observed by ransomware operators, X-Force IR has created some PowerShell scripts that will monitor the System log and send an email and export the log details to a log file when the conditions are met.

The scripts are available for download from the X-Force IR GitHub here:

https://github.com/XForceIR/ServiceInstallMonitor

The first script, TempServiceMonitor, creates a temporary WMI event subscription to the System  allowing defenders to test and tune the detections based on their specific environment. The script creates two event consumers, one which will log to a file and another which will send an email via SMTP.

To create a persistent monitor, X-Force IR created the script PermServiceMonitor, which will create a permanent WMI Event Subscription, enabling event log monitoring that will persist system reboots. PermServiceMonitor will also log event log detections to a local file as well as send an email via SMTP.

With the WMI Event Subscription enabled, as event logs are created that match the conditions specified within the WMI Event Filter, the consumers will process their actions.

To test the monitoring, multiple jump commands were executed on a target host.

As the event logs are written to the collector server, the detections are created via the consumers.

Conclusion

Ransomware has changed the threat landscape by significantly increasing the scope of potential targets for financially motivated adversaries. Prior to ransomware, the more advanced financially motivated adversaries targeted specific organizations that allowed them to monetize a compromise through point-of-sale systems or credit card theft. Ransomware has changed the focus so that every organization is a potential target, and the adversaries have built the operations to monetize every successful compromise. On the other hand, the same operationalization of ransomware that has allowed the ransomware business to be so successful also leads to well-defined tactics, tools and procedures. X-Force IR will continue to provide research and highly effective controls and detections to better serve the security community.