Программы-вымогатели Lynx – это сложное вредоносное программное обеспечение, активное с середины 2024 года, жертвами которого стали более 20 компаний в различных отраслях. Оно нацелено прежде всего на операционные системы Windows, шифрует файлы с помощью Advanced Encryption Standard (AES) с 128-битным ключом в режиме CTR и использует двойную схему вымогательства, угрожая утечкой похищенных данных.
Группа программ-вымогателей Lynx нацелена на различные отрасли и распространяется с помощью фишинговых электронных писем, программных эксплойтов или вредоносной рекламы. Программы-вымогатели рассылают записки с требованием уплатить выкуп в криптовалюте. Позиционируя себя как “этичные”, они заявляют, что избегают секторов здравоохранения и государственного управления, вместо этого сосредотачиваясь на корпоративных организациях.
В этой статье показано, как обнаруживать и реагировать на программы-вымогатели Lynx с помощью Wazuh SIEM и XDR.
Поведение программ-вымогателей Lynx
Программы-вымогатели Lynx позволяют злоумышленникам настраивать их работу, используя аргументы, передаваемые во время выполнения. Они позволяют злоумышленникам атаковать определенные файлы и каталоги, шифровать сетевые диски, а также завершать работу служб и процессов. Когда программа-вымогатель Lynx атакует конечную точку Windows, она выполняет следующие действия:
- Прекращение работы служб: При обнаружении на пораженной системе программа-вымогатель Lynx завершает работу следующих служб: Backup, Exchange, SQL, Notepad, Veeam и Java.
- Шифрование файлов: Программа-вымогатель Lynx шифрует файлы на пораженной конечной точке, исключая файлы с расширениями .dll, .exe, .msi и .lynx. Она также пропускает файлы в папках $RECYCLE.BIN, appdata, program files и program files (x86). Зашифрованные файлы идентифицируются расширением .LYNX.
- Создание записки с требованием выкупа: в каждой папке, которую сканирует программа, создается файл README.txt с требованием выкупа.
Проанализированный образец
| Тип | Значение |
| SHA256 | d5ca3e0e25d768769e4afda209aca1f563768dae79571a38e3070428f8adf031 |
| SHA1 | 6732c71c51a2ad68771984231f696f6e46708297 |
| MD5 | 31a77e0d1c1b91eebec1f7cdcc1ab8b8 |
Инфраструктура
Для демонстрации обнаружения программ-вымогателей Lynx с помощью Wazuh используется следующая инфраструктура:
- Предварительно собранная, готовая к использованию последняя доступная версия Wazuh, которая включает центральные компоненты Wazuh (сервер Wazuh, индексатор Wazuh и дешборд Wazuh). Следуя этим инструкциям, можно загрузить и настроить виртуальную машину Wazuh.
- Конечный компьютер Windows 11 с установленным агентом Wazuh последней доступной версии и зарегистрированным на сервере Wazuh.
Методы обнаружения
В этом блоге рассматриваются следующие методы обнаружения наличия программы-вымогателя Lynx на компьютерах с ОС Windows:
- Использование пользовательских правил обнаружения: Создание собственных правил для обнаружения шифрования пользовательских файлов и создание файлов README.txt.
- Использование списка постоянных баз данных (CDB): Создание списка CDB, содержащего известные хеши программ-вымогателей Lynx, для обнаружения исполняемого файла программы-вымогателя на контролируемой конечной точке.
Использование пользовательских правил обнаружения
Для обнаружения поведения программы-вымогателя Lynx отслеживаются системные события на конечной точке Windows с помощью Sysmon и создаются кастомные правила на сервере Wazuh.
Конечная точка Windows
Нужно выполнить приведенные ниже шаги, чтобы настроить Sysmon на контролируемой конечной точке и перенаправить журналы в канале событий Sysmon на сервер Wazuh для анализа.
1. Загрузить последнюю версию Sysmon со страницы Microsoft Sysinternals.
2. Распаковать сжатый файл Sysmon в нужное место.
3. Загрузить файл конфигурации Sysmon – sysmonconfig.xml, используя PowerShell от имени администратора. Заменить <SYSMON_EXECUTABLE_PATH> на путь к исполняемому файлу Sysmon.
> wget -Uri https://wazuh.com/resources/blog/emulation-of-attack-techniques-and-detection-with-wazuh/sysmonconfig.xml -OutFile <SYSMON_EXECUTABLE_PATH>\sysmonconfig.xml4. Перейти в каталог, содержащий исполняемый файл Sysmon. Запустить команду ниже, чтобы установить и запустить Sysmon:
> .\Sysmon64.exe -accepteula -i sysmonconfig.xml5. Добавить следующую конфигурацию в блок <ossec_config> файла C:\Program Files (x86)\ossec-agent\ossec.conf для перенаправления событий Sysmon на сервер Wazuh:
<localfile>
<location>Microsoft-Windows-Sysmon/Operational</location>
<log_format>eventchannel</log_format>
</localfile>6. Мониторинг папки Downloads всех пользователей в режиме реального времени, путем добавления приведенной ниже конфигурации в блок <syscheck> файла C:\Program Files (x86)\ossec-agent\ossec.conf:
<directories check_all="yes" realtime="yes">C:\Users\*\Downloads</directories>Примечание: В этом блоге отслеживается только каталог Downloads всех пользователей. Впрочем, можно настроить другие директории. Параметр check_all гарантирует, что Wazuh будет проверять все атрибуты файлов, в частности размер, разрешения, владельца, дату последней модификации, индексный дескриптор (inode) и хеш.
7. Перезапустить агент Wazuh, чтобы применить изменения:
> Restart-Service -Name wazuhСервер Wazuh
В этом разделе созданы правила для обнаружения активности программы-вымогателя Lynx на отслеживаемом компьютере с ОС Windows.
1. Создать файл lynx_ransomware_rules.xml в каталоге /var/ossec/etc/etc/rules/:
# touch /var/ossec/etc/rules/lynx_ransomware_rules.xml2. Добавить следующие правила обнаружения в файл /var/ossec/etc/etc/rules/lynx_ransomware_rules.xml:
<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>Где:
- Правило с ID 100101 срабатывает, когда в течение 100 секунд создается два файла README.txt с требованием выкупа.
- Правило с ID 100102 срабатывает, когда программа-вымогатель Lynx шифрует пользовательские файлы в контролируемой папке Downloads.
- Правило с ID 100104 срабатывает, когда обнаружено несколько действий по выполнению программы-вымогателя, что указывает на активность программы-вымогателя.
Использование списка постоянных баз данных (CDB)
Имея известные хеши файлов для программ-вымогателей Lynx, их обнаруживают, добавляя хеши файлов в список CDB. Модуль мониторинга целостности файлов Wazuh (FIM) сравнивает контрольные суммы файлов в контролируемом каталоге с хешами в списке CDB. Необходимо выполнить приведенные ниже действия, чтобы создать CDB-список и настроить правило обнаружения вредоносного программного обеспечения с использованием CDB-списка.
Сервер Wazuh
1. Создать CDB-список lynx-malware-hashes, который будет содержать известные хеши программ-вымогателей Lynx, и сохранить его в каталоге /var/ossec/etc/lists на сервере Wazuh:
# touch /var/ossec/etc/lists/lynx-malware-hashes2. Добавить известные хеши программ-вымогателей Lynx в файл lynx-malware-hashes в виде пар key:value:
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Ключи – это хеши SHA256 программы-вымогателя.
Примечание: Можно добавить другие хеши SHA256 программы-вымогателя в свободном доступе.
3. Отредактировать конфигурационный файл сервера Wazuh /var/ossec/etc/ossec.conf и добавить список etc/lists/lynx-malware-hashes в раздел <ruleset>, как показано ниже:
<ruleset>
<list>etc/lists/lynx-malware-hashes</list>
</ruleset>4. Добавить приведенное ниже пользовательское правило в файл /var/ossec/etc/rules/lynx_ransomware_rules.xml:
<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>Правило с ID 100103 срабатывает, когда файл добавляется в папку Downloads и его хэш SHA256 совпадает с записью в списке CDB.
Примечание: Wazuh запускает правило 554, когда пользователь или процесс добавляет новый файл в контролируемый каталог, и правило 550, когда пользователь или процесс изменяет файл.
5. Перезапустить менеджер Wazuh, чтобы применить изменения.
# systemctl restart wazuh-managerУведомления об обнаружении на дешборде Wazuh
Следует выполнить следующие действия, чтобы просмотреть уведомления, которые появляются на дешборде Wazuh, когда программа-вымогатель Lynx выполняется на компьютере с Windows.
1. Перейти к Threat intelligence > Threat Hunting.
2. Нажать + Add filter. Затем отфильтровать по rule.id.
3. В поле Operator выбрать is one of.
4. Найти и выбрать 100101, 100102, 100103 и 100104 в поле Values.
5. Нажать Save.
Защита от программ-вымогателей с Wazuh Active Response
В этом разделе используется модуль Wazuh Command и встроенная служба Volume Shadow Copy Service (VSS) в Windows для автоматического создания снимков, служащих точками восстановления файлов. Модули Wazuh Command и Active Response настроены на автоматическое восстановление файлов при обнаружении выполнения программы-вымогателя Lynx.
Конечная точка Windows
На конечной точке Windows настраивается скрипт Wazuh Active Response и модуль Command.
Настройка модуля Wazuh Command
Чтобы настроить модуль Wazuh Command, необходимо выполнить приведенные ниже действия.
1. Добавить следующую конфигурацию в локальный конфигурационный файл C:\Program Files (x86)\ossec-agent\ossec.conf:
<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>Эта конфигурация задает команду, которая выполняет следующие действия:
- Изменяет параметры автозапуска службы Volume Shadow Copy Service (VSS) на Demand. Это предотвращает автоматический запуск службы при загрузке системы. Она будет запускаться только в случае явного запроса пользователем или другим процессом.
- Выполняет команду создания теневой копии тома на конечной точке с помощью vssadmin.
- Останавливает службу Volume Shadow Copy Service и меняет ее тип запуска на disabled. Это помогает защитить теневые копии тома от удаления.
Примечание: VSS не сохраняет копии отображенных сетевых ресурсов. Следует изменить букву диска в команде, если конечная точка не использует диск C:\.
Периодичность создания теневых копий составляет 12 часов. Можно изменить этот параметр, изменив значение параметра <interval> на нужную частоту.
Настройка скрипта Wazuh Active Response
Для восстановления зашифрованных файлов использован специальный скрипт Wazuh Active Response rollback.ps1, который восстанавливает файлы в резервную папку.
1. Создать скрипт rollback.ps1 в директории C:\Program Files (x86)\ossec-agent\active-response\bin\ и добавить к нему приведенный ниже скрипт. Этот скрипт восстанавливает файлы из теневых копий томов:
# 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. Создать скрипт rollback.bat в директории C:\Program Files (x86)\ossec-agent\active-response\bin\ и добавить в него приведенный ниже скрипт. Этот скрипт выполняет rollback.ps1 через Windows Batch launcher, поскольку модуль Wazuh Active Response не может напрямую запускать PowerShell-скрипты:
@echo off
Powershell -ExecutionPolicy bypass -File "C:\Program Files (x86)\ossec-agent\active-response\bin\rollback.ps1"3. Перезапустить агента Wazuh с помощью PowerShell с правами администратора, чтобы применить изменения конфигурации:
Restart-Service -Name wazuhСервер Wazuh
Настраивается модуль активного реагирования Wazuh для запуска скрипта отката при обнаружении выполнения программы-вымогателя.
Настройка кастомных декодеров
Добавляются следующие декодеры для декодирования журналов, генерируемых скриптом Active Response Wazuh rollback.bat.
1. Добавить следующие декодеры в файл /var/ossec/etc/decoders/local_decoder.xml для декодирования журналов, созданных скриптом rollback.ps1 Wazuh Active Response:
<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>Настройка пользовательских правил
Чтобы добавить кастомное правило, нужно выполнить следующий шаг.
1. Добавить следующее пользовательское правило в файл правил /var/ossec/etc/etc/rules/local_rules.xml.
<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>Правило с ID 100105 срабатывает при успешном восстановлении файлов.
Настройка модуля Wazuh Active Response
Чтобы настроить модуль Wazuh Active Response, нужно выполнить следующие шаги.
1. Добавить следующую конфигурацию в блок <ossec> файла /var/ossec/etc/ossec.conf, чтобы настроить команду Wazuh Active Response:
<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>Команда rollback_windows выполняется, когда срабатывает пользовательское правило 100104. Это запускает скрипт Wazuh Active Response для восстановления файлов из последней сохраненной теневой копии тома. Восстановленные файлы сохраняются в папке, расположенной в C:\Recovered_Files.
2. Перезапустить менеджер Wazuh, чтобы применить изменения конфигурации:
# systemctl restart wazuh-managerВизуализация уведомлений
Запуск программы-вымогателя Lynx на контролируемой конечной точке Windows генерирует уведомление на дешборде Wazuh.
После обнаружения выполнения программы-вымогателя запускается скрипт Wazuh Active Response, который восстанавливает зашифрованные файлы, как показано ниже.
Следующее уведомление срабатывает, когда скрипт Wazuh Active Response успешно восстанавливает зашифрованные файлы.
Заключение
В этой статье было успешно продемонстрировано, как Wazuh может обнаруживать и реагировать на программы-вымогатели Lynx на компьютерах с Windows. Были использованы список постоянной базы данных (CDB) Wazuh и набор правил для обнаружения программы-вымогателя Lynx на основе ее поведения. Также показано как можно защитить резервные копии и восстановить файлы, зашифрованные программой-вымогателем на конечных точках Windows, используя модули Wazuh Command и Active Response.
Чтобы узнать больше о возможностях Wazuh, ознакомьтесь с официальной документацией, статьями в блоге и сообществом для получения поддержки и обновлений.
