Програми-вимагачі 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/rules/:
# touch /var/ossec/etc/rules/lynx_ransomware_rules.xml2. Додати наступні правила виявлення до файлу /var/ossec/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/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, ознайомтеся з офіційною документацією, статтями в блозі та спільнотою для отримання підтримки та оновлень.
