Detecting Lynx ransomware with Wazuh

February 24th 2025 | by Obinna Uchubilo | Wazuh 4.10.1

Lynx ransomware is a sophisticated malware threat that has been active since mid-2024, with over 20 victims across various industries. It primarily targets Windows operating systems, encrypting files using the Advanced Encryption Standard (AES) with a 128-bit key in CTR mode, and employs double extortion, threatening to leak stolen data.

Operated by the Lynx ransomware group, the ransomware targets diverse industries and spreads via phishing emails, software exploits, or malicious adverts. The ransomware drops ransom notes demanding cryptocurrency payments. Branding itself as “ethical”, it claims to avoid healthcare and government sectors, focusing instead on corporate entities.

This blog shows how to detect and respond to Lynx ransomware using Wazuh SIEM and XDR.

Lynx ransomware behavior

Lynx ransomware allows attackers to tailor their execution by using arguments supplied during the runtime. The ransomware enables attackers to target specific files and directories, encrypt network drives, and terminate services and processes. When Lynx ransomware infects a Windows endpoint, it performs the following actions:

Terminate services: The Lynx ransomware terminates the following services if found on the affected system: Backup, Exchange, SQL, Notepad, Veeam, and Java.
Encrypt files: The Lynx ransomware encrypts files on the affected endpoint excluding those with .dll, .exe, .msi, and .lynx extensions. It also skips files within the $RECYCLE.BIN, appdata, program files, and program files (x86) folders. The encrypted files are identified by the .LYNX file extension.
Create ransom note: A ransom note README.txt is created in every folder scanned by the malware.

Analyzed sample

Type	Value
SHA256	d5ca3e0e25d768769e4afda209aca1f563768dae79571a38e3070428f8adf031
SHA1	6732c71c51a2ad68771984231f696f6e46708297
MD5	31a77e0d1c1b91eebec1f7cdcc1ab8b8

Infrastructure

We use the following infrastructure to demonstrate the detection of Lynx ransomware with Wazuh:

A pre-built, ready-to-use Wazuh OVA 4.10.1 which includes the Wazuh central components (Wazuh server, Wazuh indexer, and Wazuh dashboard). Follow this guide to download and set up the Wazuh virtual machine.
A Windows 11 victim endpoint with the Wazuh agent 4.10.1 installed and enrolled to the Wazuh server.

Detection techniques

In this blog post, we use the following techniques to detect the presence of Lynx ransomware on a Windows endpoint:

Using custom detection rules: We create custom rules to detect the encryption of user files and the creation of the README.txt files.
Using Constant Database (CDB) list: We create a CDB list containing the known hashes of Lynx ransomware to detect the ransomware executable on the monitored endpoint.

Using custom detection rules

We monitor system events on the Windows endpoint using Sysmon and create custom rules on the Wazuh server to detect Lynx ransomware behavior.

Windows endpoint

Follow the steps below to configure Sysmon on the monitored endpoint and forward logs in the Sysmon event channel to the Wazuh server for analysis.

1. Download the latest version of Sysmon from the Microsoft Sysinternals page.

2. Extract the compressed Sysmon file to your preferred location.

3. Download the Sysmon configuration file – sysmonconfig.xml using PowerShell as an administrator. Replace <SYSMON_EXECUTABLE_PATH> with the path to your Sysmon executable.

> wget -Uri https://wazuh.com/resources/blog/emulation-of-attack-techniques-and-detection-with-wazuh/sysmonconfig.xml -OutFile <SYSMON_EXECUTABLE_PATH>\sysmonconfig.xml

4. Switch to the directory containing the Sysmon executable. Run the command below to install and start Sysmon:

> .\Sysmon64.exe -accepteula -i sysmonconfig.xml

5. Add the following configuration within the <ossec_config> block of the C:\Program Files (x86)\ossec-agent\ossec.conf file to forward Sysmon events to the Wazuh server:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

6. Monitor the Downloads folder of all users in real-time by adding the below configuration within the <syscheck> block of the C:\Program Files (x86)\ossec-agent\ossec.conf file:

<directories check_all="yes" realtime="yes">C:\Users\*\Downloads</directories>

Note: In this blog post, we only monitored the Downloads directory of all users. However, you can configure other directories you wish to monitor. The check_all option ensures Wazuh checks all file attributes including the file size, permissions, owner, last modification date, inode, and hash.

7. Restart the Wazuh agent to apply the changes:

> Restart-Service -Name wazuh

Wazuh server

In this section, we create rules to detect the activities of Lynx ransomware on the monitored Windows endpoint.

1. Create a file lynx_ransomware_rules.xml in the /var/ossec/etc/rules/ directory:

# touch /var/ossec/etc/rules/lynx_ransomware_rules.xml

2. Add the following detection rules to the /var/ossec/etc/rules/lynx_ransomware_rules.xml file:

<group name="lynx,ransomware,">
  <!-- Detects when Lynx creates ransom notes -->
  <rule id="100101" level="12" timeframe="100" frequency="2" ignore="300">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.image" type="pcre2">(?i)[C-Z]:.*\\\\.*.exe</field>
    <field name="win.eventdata.targetFilename" type="pcre2">(?i)\C:.*.README.txt</field>
    <description>The file $(win.eventdata.targetFilename) has been created in multiple directories. Possible ransomware attack detected.</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>

  <!-- Detects when Lynx encrypts a file in a monitored directory -->
  <rule id="100102" level="15" timeframe="100" frequency="2" ignore="300">
    <if_sid>550,554</if_sid>
    <field name="file" type="pcre2">(?i).LYNX</field>
    <description>File encrypted by Ransomware. Lynx ransomware detected.</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>
 </group>

<group name="ransomware,ransomware_detection">
  <rule id="100104" level="12" timeframe="300" frequency="2" ignore="300">
    <if_matched_group>lynx</if_matched_group>
    <if_sid>100101,100102</if_sid>
    <description>Ransomware activity detected.</description>
  </rule>
</group>

Where:

Rule ID 100101 is triggered when two README.txt ransom notes are created within 100 seconds.
Rule ID 100102 is triggered when the Lynx ransomware encrypts the user files in the monitored Downloads folder.
Rule ID 100104 is triggered when multiple ransomware execution activities are detected, denoting a ransomware activity.

Using Constant Database (CDB) list

With the known file hashes for Lynx ransomware, we detect the ransomware by adding the file hashes to a CDB list. The Wazuh File Integrity Monitoring (FIM) module compares the checksums of files in a monitored directory with the hashes in the CDB list. Follow the steps below to create a CDB list and configure a malware detection rule using a CDB list.

Wazuh server

1. Create a CDB list lynx-malware-hashes that will contain known Lynx ransomware hashes and save it to the /var/ossec/etc/lists directory on the Wazuh server:

# touch /var/ossec/etc/lists/lynx-malware-hashes

2. Add the known Lynx ransomware hashes to the lynx-malware-hashes file as key:value pairs:

11cfd8e84704194ff9c56780858e9bbb9e82ff1b958149d74c43969d06ea10bd:Lynx
64b249eb3ab5993e7bcf5c0130e5f31cbd79dabdcad97268042780726e68533f:Lynx
589ff3a5741336fa7c98dbcef4e8aecea347ea0f349b9949c6a5f6cd9d821a23:Lynx
9a47ab27d50df1faba1dc5777bdcfff576524424bc4a3364d33267bbcf8a3896:Lynx
1754c9973bac8260412e5ec34bf5156f5bb157aa797f95ff4fc905439b74357a:Lynx
fcefe50ed02c8d315272a94f860451bfd3d86fa6ffac215e69dfa26a7a5deced:Lynx
d5ca3e0e25d768769e4afda209aca1f563768dae79571a38e3070428f8adf031:Lynx
ca9d2440850b730ba03b3a4f410760961d15eb87e55ec502908d2546cd6f598c:Lynx
b378b7ef0f906358eec595777a50f9bb5cc7bb6635e0f031d65b818a26bdc4ee:Lynx
4e5b9ab271a1409be300e5f3fd90f934f317116f30b40eddc82a4dfd18366412:Lynx
ecbfea3e7869166dd418f15387bc33ce46f2c72168f571071916b5054d7f6e49:Lynx
f96ecd567d9a05a6adb33f07880eebf1d6a8709512302e363377065ca8f98f56:Lynx
eaa0e773eb593b0046452f420b6db8a47178c09e6db0fa68f6a2d42c3f48e3bc:Lynx
31de5a766dca4eaae7b69f807ec06ae14d2ac48100e06a30e17cc9acccfd5193:Lynx
85699c7180ad77f2ede0b15862bb7b51ad9df0478ed394866ac7fa9362bf5683:Lynx
869d6ae8c0568e40086fd817766a503bfe130c805748e7880704985890aca947:Lynx
571f5de9dd0d509ed7e5242b9b7473c2b2cbb36ba64d38b32122a0a337d6cf8b:Lynx
82eb1910488657c78bef6879908526a2a2c6c31ab2f0517fcc5f3f6aa588b513:Lynx

The keys are the SHA256 hashes of the ransomware.

Note: You can add other SHA256 hashes of the ransomware in the wild.

3. Edit the Wazuh server /var/ossec/etc/ossec.conf configuration file and add the etc/lists/lynx-malware-hashes list to the <ruleset> section as shown below:

<ruleset>
  <list>etc/lists/lynx-malware-hashes</list>
</ruleset>

4. Add the custom rule below to the /var/ossec/etc/rules/lynx_ransomware_rules.xml file:

<group name="lynx,ransomware,">
<!-- Detects Lynx ransomware executable -->
  <rule id="100103" level="15">
    <if_sid>554, 550</if_sid>
    <list field="sha256" lookup="match_key">etc/lists/malware-hashes</list>
    <description>Lynx ransomware executable detected: $(file)</description>
    <mitre>
      <id>T1204.002</id>
    </mitre>
  </rule>
</group>

Rule ID 100103 is triggered when a file is added to the Downloads folder and its SHA256 hash matches an entry in the CDB list.

Note: Wazuh triggers rule 554 when a user or process adds a new file to a monitored directory and rule 550 when a user or process modifies a file.

5. Restart the Wazuh manager to apply changes.

# systemctl restart wazuh-manager

Wazuh dashboard detection alerts

Follow the steps below to view the alerts generated on the Wazuh dashboard when the Lynx ransomware is executed on the Windows endpoint.

1. Navigate to Threat intelligence > Threat Hunting.

2. Click + Add filter. Then filter by rule.id.

3. In the Operator field, select is one of.

4. Search and select 100101, 100102, 100103, and 100104 in the Values field.

5. Click Save.

Ransomware protection with Wazuh Active Response

In this section, we leverage the Wazuh Command module and the built-in Volume Shadow Copy Service (VSS) on Windows to create automated file snapshots, serving as recovery points for file restoration. The Wazuh Command and Active Response modules are configured to automatically restore files upon detecting Lynx ransomware execution.

Windows endpoint

On the Windows endpoint, we configure a Wazuh Active Response script and Command module.

Wazuh Command module configuration

Perform the steps below to configure the Wazuh Command module.

1. Append the following configuration to the C:\Program Files (x86)\ossec-agent\ossec.conf local configuration file:

<ossec_config>
  <wodle name="command">
    <disabled>no</disabled>
    <tag>vss</tag>
    <command>C:\Windows\SysNative\WindowsPowerShell\v1.0\powershell.exe -c "net stop VSS ; sc.exe config VSS start=Demand ; net start VSS ; WMIC shadowcopy call create Volume=C:\ ; net stop VSS ; sc.exe config VSS start=disabled"</command>
    <interval>12h</interval>
    <run_on_start>yes</run_on_start>
    <timeout>300</timeout>
  </wodle>
</ossec_config>

This configures a command that does the following:

Changes the startup configuration of the volume shadow service to Demand. This prevents the service from starting on its own when the system boots. Instead, it will only start when a user or another process explicitly requests it.
Runs a command that takes a volume shadow copy of the endpoint using vssadmin.
Stops the volume shadow service and sets its startup type to disabled. This action protects the volume shadow copies from being deleted.

Note: VSS does not save copies of mapped network shares. Change the drive letter in the command if your endpoint does not use C:\ drive.

The frequency at which the shadow copies are taken is 12 hours. You can adjust this setting by changing the value of <interval> to your preferred frequency.

Wazuh Active Response script configuration

To recover encrypted files, we use a custom Wazuh Active Response script rollback.ps1 that recovers our files into a backup folder.

1. Create a rollback.ps1 script in the C:\Program Files (x86)\ossec-agent\active-response\bin\ directory and add the below script to it. This script recovers files from the volume shadow copies:

# Define the base paths
$EncryptedPath = "C:\users"
$RecoveryPath = "C:\Recovered_Files"  # Default recovery path, change as needed

# Paths to ignore during restoration and deletion
$IgnorePaths = @(
    "C:\Windows",
    "C:\Program Files",
    "C:\Program Files (x86)",
    "C:\C:\Recovered_Files"  # Add more paths as needed
)

# Log file location
$LogFile = "$RecoveryPath\RecoveryLog.txt"

# Ensure the log file directory exists
$LogFileDirectory = [System.IO.Path]::GetDirectoryName($LogFile)
if (-not (Test-Path -Path $LogFileDirectory)) {
    New-Item -Path $LogFileDirectory -ItemType Directory -Force
}

# Clear or create the log file
if (Test-Path -Path $LogFile) {
    Clear-Content -Path $LogFile
} else {
    New-Item -Path $LogFile -ItemType File
}

# Function to log messages
function Log-Message {
    param (
        [string]$Message
    )
    $Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    Add-Content -Path $LogFile -Value "$Timestamp - $Message"
    Write-Host "$Timestamp - $Message"
}

try {
    Log-Message "Starting recovery process..."

    # Run vssadmin list shadows and capture the output
    start-sleep 120
	cmd /c sc config VSS start=Demand
    cmd /c net start VSS
    start-sleep 5
    Log-Message "Listing shadow copies..."
    
    # Extract the shadow copy volume path using Select-String
    $ShadowCopyVolumes = C:\Windows\SysNative\WindowsPowerShell\v1.0\powershell.exe -c "Get-WmiObject -Query 'SELECT * FROM Win32_ShadowCopy' | Select-Object -ExpandProperty DeviceObject"

    if ($ShadowCopyVolumes.Count -gt 0) {
        $ShadowCopyVolume = $ShadowCopyVolumes[-1]  # Select the last shadow copy volume
        Log-Message "Latest Shadow Copy Volume found: $ShadowCopyVolume"
    } else {
        throw "Unable to find Shadow Copy Volume path in vssadmin output."
    }

    # Ensure ShadowCopyVolume ends with a backslash
        $ShadowCopyVolume += "\"

    # Log the adjusted ShadowCopyVolume path
    Log-Message "Adjusted Shadow Copy Volume path: $ShadowCopyVolume"

    # Create symbolic link between shadow copy and backup folder
    $LinkPath = Join-Path -Path $RecoveryPath -ChildPath "backup"
    Log-Message "Creating symbolic link at $LinkPath..."

    # Remove any existing symbolic link or folder
    if (Test-Path -Path $LinkPath) {
        Remove-Item -Path $LinkPath -Recurse -Force
        Log-Message "Existing symbolic link or folder removed at $LinkPath"
    }

    # Create the symbolic link
    $linkCmdOutput = cmd /c mklink /d "$LinkPath" "$ShadowCopyVolume"
    Log-Message "Symbolic link command output: $linkCmdOutput"

    # Verify symbolic link creation
    if (-not (Test-Path -Path $LinkPath)) {
        throw "Failed to create symbolic link at $LinkPath"
    }
    Log-Message "Symbolic link created successfully: $LinkPath -> $ShadowCopyVolume"

    Write-Host "Files restore completed."
    "Wazuh_Ransomware_Protection: File restore completed for $($env:computername) at $(Get-Date)" | Out-File -FilePath "C:\Program Files (x86)\ossec-agent\active-response\active-responses.log" -Append -Encoding UTF8
}
catch {
    $ErrorMsg = $Error[0].ToString()
    Log-Message "Error: $ErrorMsg"
    Write-Error "An error occurred: $ErrorMsg"
}

    # Stop VSS service
    cmd /c sc config VSS start=disabled
    cmd /c net stop VSS
    start-sleep 5
    Log-Message "Turned off VSS service..."

2. Create a rollback.bat script in the C:\Program Files (x86)\ossec-agent\active-response\bin\ directory and add the below script to it. This script executes the rollback.ps1 script via Windows Batch launcher as the Wazuh Active Response module cannot execute PowerShell scripts directly:

@echo off
Powershell -ExecutionPolicy bypass -File "C:\Program Files (x86)\ossec-agent\active-response\bin\rollback.ps1"

3. Restart the Wazuh agent using PowerShell with administrative privilege to apply the configuration changes:

> Restart-Service -Name wazuh

Wazuh server

We configure the Wazuh Active Response module to trigger the rollback script when ransomware execution is detected.

Custom decoders configuration

We add the following decoders to decode logs generated by the rollback.bat Wazuh Active Response script.

1. Add the following decoders to the /var/ossec/etc/decoders/local_decoder.xml file to decode the logs generated by the rollback.ps1 Wazuh Active Response script:

<decoder name="Wazuh_Ransomware">
  <prematch>Wazuh_Ransomware_Protection:</prematch>
</decoder>

<decoder name="Wazuh_Ransomware_child">
  <parent>Wazuh_Ransomware</parent>
  <regex type="pcre2">Wazuh_Ransomware_Protection: (.*)</regex>
  <order>rollback_status</order>
</decoder>

Custom rules configuration

Perform the following step to add a custom rule.

1. Add the following custom rule to the /var/ossec/etc/rules/local_rules.xml rule file.

<group name="ransomware,ransomware_rollback,">
  <rule id="100105" level="5">
    <field name="rollback_status">completed</field>
    <description>Wazuh_Ransomware_Protection: Files restored successfully.</description>
  </rule>
</group>

Rule ID 100105 is triggered when the files are recovered successfully

Wazuh Active Response module configuration

Perform the following steps to configure the Wazuh Active Response module.

1. Add the following configuration within the <ossec> block of the /var/ossec/etc/ossec.conf file to configure the Wazuh Active Response command:

<command>
  <name>rollback_windows</name>
  <executable>rollback.bat</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <command>rollback_windows</command>
  <location>local</location>
  <rules_id>100104</rules_id>
</active-response>

The rollback_windows command is executed when the custom rule 100104 is triggered. This triggers the Wazuh Active Response script to recover our files from the last stored volume shadow copy. The recovered files are stored in a folder located at C:\Recovered_Files.

2. Restart the Wazuh manager to apply the configuration changes:

# systemctl restart wazuh-manager

Visualizing the Alert

Running Lynx ransomware on the monitored Windows endpoint generates alerts on the Wazuh dashboard.

Once the ransomware execution is detected, the Wazuh Active Response script triggers and recovers the encrypted files as seen below.

The following alert triggers when the Wazuh Active Response script successfully recovers encrypted files.

Conclusion

In this blog post, we successfully demonstrate how Wazuh can detect and respond to Lynx ransomware on a Windows endpoint. We leveraged the Wazuh constant database (CDB) list and ruleset to detect the Lynx ransomware based on its behavior. We also show how you can protect your backups and recover files encrypted by ransomware on Windows endpoints leveraging the Wazuh Command and Active Response module.

To learn more about Wazuh capabilities, check out our documentation, blog posts, and our community for support and updates.

Reference

Detecting Lynx ransomware with Wazuh

Lynx ransomware behavior

Analyzed sample

Detection techniques

Using custom detection rules

Windows endpoint

Wazuh server

Using Constant Database (CDB) list

Wazuh server

Wazuh dashboard detection alerts

Ransomware protection with Wazuh Active Response

Windows endpoint

Wazuh Command module configuration

Wazuh Active Response script configuration

Wazuh server

Custom decoders configuration

Custom rules configuration

Wazuh Active Response module configuration

Visualizing the Alert

Related content

Detecting Brain Cipher ransomware with Wazuh

Detecting compromised accounts with HIBP and Wazuh

Detecting Razr ransomware with Wazuh

Detecting DeerStealer malware with Wazuh

Use cases

Malware Detection

Threat Hunting