Эксперты вычислили скорость шифрования файлов десяти нашумевших вымогательских семейств

[Zeronight]

Скорость шифрования файлов вымогательским ПО имеет большое значение для команд реагирования на угрозы.

Исследователи компании Splunk провели эксперимент, в ходе которого протестировали десять вымогательских программ с целью установить, как они шифруют файлы, и как быстро нужно реагировать на их атаки.

Программа-вымогатель – вредоносное ПО, которое перечисляет файлы и каталоги на скомпрометированной машине, выбирает подходящие для шифрования, а затем шифрует, из-за чего они становятся недоступными без соответствующего ключа дешифрования.

Скорость шифрования файлов вымогательским ПО имеет большое значение для команд реагирования на угрозы. Чем быстрее его удастся обнаружить, тем меньший ущерб оно причинит, и подлежащих восстановлению данных будет меньше.

Исследователи Splunk провели 400 тестов с использованием десяти различных вымогательских семейств, по десять программ в каждом семействе, на четырех различных хостах Windows 10 и Windows Server 2019 с разной производительностью.

В ходе тестирований специалисты определили скорость шифрования 98 561 файла общим объемом 53 ГБ с помощью различных инструментов, таких как Windows logging, Windows Perfmon statistics, Microsoft Sysmon, Zeek и stoQ.

Общее среднее время для всех ста программ-вымогателей на тестовых установках составило 42 минуты 52 секунды. Однако, как показано в представленной ниже таблице, некоторые образцы значительно отклонялись от этого медианного значения.

Самым быстрым о опасным оказалось семейство вымогателей LockBit, которому удалось зашифровать все файлы в среднем всего за 5 минут 50 секунд. Самый быстрый представитель семейства шифровал файлы со скоростью 25 тыс. в минуту.

Ранее популярное вымогательское ПО Avaddon зашифровало файлы за 13 минут, REvil – за 24 минуты, а BlackMatter и Darkside – за 45 минут. А вот нашумевший вымогатель Conti явно отстает от них – на шифрование 53 ГБ данных у него ушел почти час. Среди отстающих также оказались Maze и PYSA, которым потребовалось целых два часа.
Подробнее: https://www.securitylab.ru/news/530765.php

 

[Quake3]

Исследователи компании Splunk провели эксперимент

Эксперимент проплачен локбитом? Шучу. Реально, видимо там оптимизации какие-то, локбит как софт был всегда интересным (хотя первая версия вроде как была медленнее).

Хотя эти тесты, в целом понятие относительное. Как замерить скорость шифрования данных? На чем?

 

[Rehub]

А говорили код бабука говно))

 

[drunken master]

А где ссылка на архив с ПО? )

 

[Rehub]

Где ссылка на архив с ПО? )))

бабук был здесь в архиве /threads/64701/

 

[camawe]

Эксперимент проплачен локбитом? Шучу. Реально, видимо там оптимизации какие-то, локбит как софт был всегда интересным (хотя первая версия вроде как была медленнее).

Хотя эти тесты, в целом понятие относительное. Как замерить скорость шифрования данных? На чем?

Вероятно использовали одинаковые виртуальные машины и засекали время от запуска

 

[Quake3]

А говорили код бабука говно))

Кто говорил? Ну его автор не профи, как бы он это не скрывал; но в плане скорости - бабук очень быстрый. В удаленной теме его продажника я это писал, что по скорости там все очень круто. Просто есть такой момент - вот допустим Ревил на каждый файл (!) вызывал функцию, которая принудительно меняла владельца файла. Как понимаете, это достаточно накладная процедура, в том плане что 2 апи вызывают еще чето, + доп. обращение к диску (смена DACL) и т.д. и т.п. Но зато у них выполнялся сброс прав доступа практически на все файлы (не помню уже точно). Что эффективнее, не знаю, я не пентестер.

одинаковые виртуальные машины и засекали время от запуска

Если на отдельных ВМ , то да; потому что допустим если взять даже одну виртуалку, сделать снепшот и запускать софт (восстанавливая снимок), могут выйти разные результаты. В зависимости от загруженности хостовой машины.

 

[tuda]

ну так еще надо учитывать методы шифрования, ктото шифрует тока начало файла, ктото пятнами а ктото фулл крипт, такие как maze. Ясен хер он будет самым долгим

 

[camawe]

Кто говорил? Ну его автор не профи, как бы он это не скрывал; но в плане скорости - бабук очень быстрый. В удаленной теме его продажника я это писал, что по скорости там все очень круто. Просто есть такой момент - вот допустим Ревил на каждый файл (!) вызывал функцию, которая принудительно меняла владельца файла. Как понимаете, это достаточно накладная процедура, в том плане что 2 апи вызывают еще чето, + доп. обращение к диску (смена DACL) и т.д. и т.п. Но зато у них выполнялся сброс прав доступа практически на все файлы (не помню уже точно). Что эффективнее, не знаю, я не пентестер.


Если на отдельных ВМ , то да; потому что допустим если взять даже одну виртуалку, сделать снепшот и запускать софт (восстанавливая снимок), могут выйти разные результаты. В зависимости от загруженности хостовой машины.

an-empirically-comparative-analysis-of-ransomware-binaries.pdf - AnonFiles

anonfiles.com

Methodology

To test our hypothesis, we needed to execute a variety of ransomware strains in a controlled environment, gather
native Windows performance telemetry data back from endpoint hosts, and analyze the data. We selected 10
ransomware families with 10 separate binaries from each of those families in order to prevent clustering illusion,
the tendency to see patterns where none exist, and confirmation bias, the tendency to seek out information
that supports one's beliefs. For each Windows endpoint type and resource specification, a single Amazon Web
Services (AWS) Virtual Private Cloud (VPC) was created for each family and each individual binary ran on its own
host specifically created for its evaluation. The results were forwarded to a central Splunk instance for analysis.
Every host had 98,561 files placed in 100 directories. These file types were sourced from the Digital Corpora and
deemed by the authors to be the most likely file types for ransomware binaries to encrypt.10,11,12 These files were made
available under the CC0 license and sourced from public U.S. government websites. Finally, we enabled Event ID
4663 on Windows hosts in order to see encryption on files and baseline the speed of each ransomware family.

The Lab

As previously mentioned, the research was conducted against ransomware binaries executed in a controlled
environment. The performance of the ransomware was gathered using native Windows auditing and logging
capabilities that forwarded the results back to a Splunk instance. Details on the telemetry setup are covered in more
detail in the Experiment Procedure section. Each ransomware sample ran inside an independent, self-contained
environment. The Splunk instance in each ransomware environment forwarded the events to a single Splunk
instance for comparing, analyzing, and reporting. We created the lab by modifying Splunk’s open-source Attack
Range tool for our experiment (fig. 3).14 Attack Range allows network defenders to dynamically create small networks
in AWS with Splunk software and logging preconfigured using a combination of Terraform and Ansible.

The hosts on this range had specifications that aligned with many modern laptop or server builds according to
organizations that we gathered anecdotal feedback from and popular websites like PC Mag.15 These hosts had
Microsoft Defender uninstalled, and no additional anti-virus (AV) or endpoint detection and response (EDR) tools
installed. We installed additional tools including a Splunk agent to send information back to Splunk and the Microsoft
application Sysmon.16 Finally, to detect any worming or remote mapped file encryption, these hosts were joined
to a Windows domain with an open network share (C Drive) on the domain controller. More information about the
host specifications and the logging configurations can be found in the appendices A and B. In order to capture file
encryption events, we enabled object level auditing on the test directory and all sub-directories for both successful
and failed access attempts. By enabling object level auditing, Event Code 4663 events were generated each time
the ransomware binary attempted to encrypt a file. The final 4663 event to conclude a successful encryption of a
file was DELETE, which is what we used to track encryption speed. While this event was seen consistently across the
families we tested, this DELETE event may not be present in other families. If this is the case, a different marker might
be needed to measure TTE.

Experiment Procedure

To best emulate modern ransomware campaigns, we executed the ransomware across 10 Windows 10 hosts and 10
Windows Server 2019 hosts via a remote PowerShell script located on the Windows Server 2019 Domain Controller.
This remote PowerShell method was used to initiate the ransomware infection as opposed to a user having to manually
execute the binary. This methodology had the added benefit of emulating modern ransomware campaigns where
ransomware is executed by human operators via scripts rather than by victims on desktops. Furthermore, it reduced
some overhead of “human interaction,” which allowed the ransomware to utilize more system resources than would have
otherwise been available. We did not pass any flags to the ransomware when it executed. The only ransomware variant
that we executed in a different manner was Babuk, as it would not run reliably using the remote PowerShell method, and
we therefore started Babuk interactively on each host. Two different hardware profiles for each operating system were
used to evaluate ransomware performance. The exact specifications for these profiles can be found in Appendix B.
The PowerShell script allowed us to select the ransomware sample we wanted to run. The script would then iterate
through the number of Windows 10 or Windows Server 2019 hosts in the domain and initiate downloads of the
ransomware binaries via a remote web server. Each test run was either on a Windows 10 or Windows Server host,
never both at the same time.
When the download finished on each host, the PowerShell script launched each ransomware binary remotely, except
for Babuk. We were then able to analyze the speed that each variant encrypted files using Windows security event
logs. Event Code 4663 (an attempt was made to access an object) was required to capture the encryption events
reliably. We enabled file system auditing for the 100 test directories on the Windows 10 and Windows Server 2019
hosts in order to generate the required event logs.

The Ransomware Binaries

The 100 ransomware samples across 10- ransomware families were sourced from VirusTotal. We solely leveraged
Microsoft Defender detections from VirusTotal for ransomware family attribution. The ransomware families were
selected due to their prevalence over the past 12 to 24 months.

The VirusTotal detection strings and SHA256 hashes of each binary tested in each family can be found in Appendix C.

 

[LockBitSupp]

Эксперимент проплачен локбитом?

Да, 2000 долларов заплатил. (спиздили мою таблицу с блога)

Как замерить скорость шифрования данных? На чем?

Я просто шифровал одну и туже виртуалками разными билдами и смотрел во сколько зашифрован первый файл и последний.

А говорили код бабука говно))

Главное не локер, а репутация партнёрки, шифровать можно чем угодно, но только будут ли платить за это и сколько проживёт партнёрка и не заскамит ли она кого-то, вот что главное.

Вероятно использовали одинаковые виртуальные машины и засекали время от запуска

Да.