Conference

SANS Ransomware Summit 2022, Can You Detect This?

This report is a companion to the SANS Ransomware Summit 2022 “Can You Detect This” presentation today 6/16/22 @ 14:40 UTC (10:40 AM ET).

Slides: SANS Ransomware Summit 2022 – Can You Detect This
Recording: {should be available within 48 hours}

The 2021 Year In Review report provided insights into common MITRE ATT&CK techniques observed across our cases, and some opportunities for detection. In this report we will review a collection of actionable detections based on threat actor behavior in intrusions we have investigated over the past year.

Shout out to @_pete_0 and @yatinwad for presenting and writing this companion report.

As with all forms of detection content, its important to understand the nature of the detection and the target environment. This includes data sources, related configuration, and tuning for normal behaviors in your environment. It is recommended any detection is tested prior to deployment on a production system.

Detection Methodology

The DFIR Report analysts use several approaches for developing detection content, our repo is https://github.com/The-DFIR-Report. This could be in Sigma for log source data, YARA for host based artifacts, or Snort/Suricata for network. Sigma provides a solution agnostic approach for expressing detection logic that can be translated into a taxonomy understood by SIEMs, data definition applications etc.

To validate our detection’s, we either use the original case dataset, or develop representative data in our labs. We then replay this dataset into the likes of something like F-Secure’s Chainsaw – if using Windows event source data. Chainsaw also supports Sigma, and can be customized via mappings. More details on Chainsaw here: https://github.com/countercept/chainsaw

We have a customized mapping for Chainsaw that supports Sysmon Event ID 22. The mapping file is available on our GitHub. You can find our detections repo here.

Intrusion Detections aligned to the MITRE ATT&CK framework

Initial Access

In the past year or so, we have observed malware variants such as IcedId and Trickbot being embedded into macro-based Office documents and delivered as email attachments.

In majority of those intrusions, the Office (Excel or Word) document spawns suspicious processes such as Living-of-the-land binaries (regsvr32.exe, rundll32.exe) and Windows Command Line shell (cmd.exe, powershell.exe).

Example:

Process Chain – XLSB file weaponized with Trickbot

The below Sigma rules can be used for creating detection rules:

Office Applications Spawning LOL Bins:

Office Applications Spawning WMI Command Line:

Excel Proxy Executing Regsvr32 with Payload:

Office Applications Spawning Windows Shell:

Office Applications MS Office Product Spawning Exe in User Dir:

Recently, there has been an increase in the use of “ISO” image containers to deliver the initial payload to evade Mark-of-the-Web (MOTW).

 

For detecting mounting of ISO images, we can look into “Microsoft-Windows-VHDMP/Operational” log source.

Event IDs: 1 and 12

Sigma Rules:

ISO Image Mount:

ISO or Image Mount Indicator in Recent Files:

Rundll32 From Abnormal Drive

Persistence:

After establishing the initial foothold, threat actors deploy multiple techniques to maintain access to the victim environment. As highlighted in “2021 Year in Review”, scheduled tasks were deployed by threat actors in more than 50% of the intrusions.

Scheduled Tasks:

Suspicious Scheduled Task Creation to execute LOLbins

Rare Scheduled Task Creations

BITS Job:

In our “Diavol Ransomware” case, a new BITS job was created to execute the malicious DLL from mounted ISO image every 3 hours.

Web Shells:

In the “Exchange Exploit Leads to Domain Wide Ransomware” intrusion, multiple web shells were dropped on the infected Microsoft Exchange system. These shells were later used for performing discovery activity.  

Sigma Rules:

Webshell Detection With Command Line Keywords

Shells Spawned by Web Servers

Exchange Webshell creation

Remote Access Tools:

A recent trend by the threat actor, once a foothold has been established, is to maintain long term persistence using third party remote services, such as those provided via Splashtop, AnyDesk, NetSupport, etc.

From a recent case (illustration below), Splashtop was deployed, and provided the operator with access to the network using legitimate services. As this is a remote service, there will be a mix of process and network activity that should be very visible.

We’ve created two Sigma rules for Splashtop covering both process creation and network activity. Splashtop is a legitimate application, however it should be investigated if its not part of your software baseline.

Both process and network events will be detected:

 

Similarly, the AnyDesk Sigma rule also covers network activities.

Our SplashTop and AnyDesk Sigma rules can be found within our GitHub repo at:

AnyDesk Network:

SplashTop Network

SplashTop Process:

Privilege Escalation:

The threat actors want to elevate their privileges to follow through on their objectives. One technique used is Cobalt Strike’s “GetSystem” functionality to achieve SYSTEM privileges.

There is a great article from Red Canary which talks about this functionality present in various offensive tools and hunting tips.

Credential Harvesting:

After escalation of privileges, threat actors target the LSASS process. The primary methods they deploy are:

Accessing the LSASS process using CS or initial malware:

Threat actors also commonly dump the LSASS process with the help of utilities such as Procdump and Task Manager.

Sigma Rules:

Suspicious Use of Procdump on LSASS

LSASS credentials dump via Task Manager (file)

LSASS Memory Dump

LSASS Memory Dump

LSASS Process Memory Dump Files

Invocation of Ntdsutil:

Invocation of Active Directory Diagnostic Tool (ntdsutil.exe)

Dumping of Registry Hives:

Grabbing Sensitive Hives via Reg Utility:

Accessing of LSASS by Mimikatz:

Defense Evasion:

While performing their activities, threat actors do take certain measures to avoid getting caught. Most common being disabling of Windows Defender AV.

Sigma Rules:

Microsoft Defender critical security components disabled (command)

Microsoft Defender critical security components disabled (PowerShell)

Windows Defender Threat Detection Disabled

Discovery:

Threat actors rely on Windows built-in utilities for performing initial discovery activity.

Sigma Rules:

Domain Trust Discovery

Suspicious Reconnaissance Activity

Local Accounts Discovery

Net.exe Execution

Whoami Execution

Windows Network Enumeration

CHCP CodePage Locale Lookup

They also deploy 3rd party tools such as Adfind for further enumeration.

Sigma Rules:

AdFind Discovery

Advanced IP Scanner:

Lateral Movement:

To achieve their objectives, the threat actors pivot to multiple systems such as Domain Controllers, Backup Servers and File Shares using various tools/techniques:

  • Sysinternals PsExec
  • Post-Exploitation Framework, Cobalt Strike
  • Remote WMI Execution

Sigma Rules

WMIC:

Suspicious WMI Execution

WMI Remote Command Execution

PsExec:

PsExec Tool Execution

PsExec Tool Execution

PSEXEC Custom Named Service Binary

Copy to Admin Shares:

Cobalt Strike:

Collection & Exfiltration:

Once the threat actors have pivoted to systems of their interest, they gather the data present on them and attempt to exfiltrate it out of the victim environment with the help of utilities such as Rclone, WinSCP and FileZilla.

Rclone:

Rclone being utilized to exfiltrate the data towards “MEGA” cloud storage services.

Sigma Rules:

Rclone Execution via Command Line or PowerShell

Rclone config file creation

DNS Query for MEGA.io Upload Domain

A good reference on Rclone/Mega: https://redcanary.com/blog/rclone-mega-extortion/

In the past, we have seen Ransomware operators upload the LSASS dump file to ufile.io.

While uploading the file, a DNS request is made to “ufile.io” subdomain based on the geographical location.  

Example:

Sigma Rule:

Operator Bloopers

We reported that its not uncommon for threat actors to make mistakes when conducting hands-on keyboard actions on endpoints. Whilst an operator will follow a playbook – that details the procedure to follow, sometimes mistakes will occur.

We have two Sigma detection rules that detect Cobalt Strike operator errors, where Cobalt Strike specific commands or modules are inadvertently entered directly on the host via the shell.

Both Sigma rules are based on popular Cobalt Strike commands or have observed operators utilizing in various cases.

For example:

 

If an operator entered commands, and this was captured on the endpoint via Sysmon for example, it would be possible to detect this action.

For example, if the operator entered ‘av_query’, (we have observed such mistakes in past cases), using the Sigma rule, we could observe the following output.

 

Our ‘Operator Bloopers…’ Sigma rules can be found within our GitHub repo as:

Operator Bloopers Cobalt Strike Modules

Operator Bloopers Cobalt Strike Commands

Bring Your Own Tools (BYOT)

Custom Tools

In various intrusions we observe operators deploying custom tooling directly from endpoints or staging files locally.

Sometimes we see the same filenames for scripts, or very specific command-line parameters being utilized across cases. A frequent script, is ‘adf.bat’, that packages together a number of ADFind commands together.

The following Sigma rule detects several .BAT files we have observed being executed. Examples files are listed below – its not difficult to figure out the intent:

  • adf.bat
  • adfind.bat
  • locker.bat
  • kill.bat
  • def.bat
  • start.bat
  • shadow.bat
  • logdelete.bat
  • closeapps.bat

The Sigma rule:

Our ‘BYOT’ Sigma rule can be found within our GitHub repo as:

Operator Bring Your Own Tools

Summary

The above provides a number of detections that could be deployed to detect malicious and suspicious activity that could be indicative of intruder actions.

Its important to note whilst the detections aim to detect actions, its not a substitute for preventing such activity from occurring in the first place. As mentioned in our previous report, following good practices such as hardening, maintaining software updates and provision of an anti-virus solution should stop initial access and establish foothold stages from materializing.