Conti Ransomware malware leak WITH LOCKER
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 

98 lines
6.1 KiB

ПЛАН ТЕСТИРОВАНИЯ БК ПЕРЕД ВЫДАЧЕЙ
1. Определяем боевую группу, которую мы будем распространять.
Боевые группы имеют численное написание (1, 2, 3 итд) и предназначены только для боевого применения.
Тестовые группы имеют символьное написание (one, two итд) и предназначены для целей разработки, тестирования нового функционала, поиска ошибок, стабилизации кода итд.
2. Запрашиваем у кодера комплект софта боевых групп.
Всего должно быть 8 бинарей - 4 с логами и 4 без:
- по 2 бинарника для лоадера, 32/64
- по 2 бинарника для бота, 32/64
3. Те что с логами откладываем в сторону.
Они необходимы на случай, если обнаружится ошибка в функционале - тогда по этим бинарникам разработчику будет легче локализовать проблему.
4. Криптуем оба лоадера без логов
5. Подписываем оба лоадера и оба бота без логов
6. Заливаем в админку (в нужную группу!) подготовленные бинарники
6.1. Боевые версии софта (для боевых групп) в админку заливает только тестировщик!
6.2. При заливе файлов нужно для каждого бинарника прописать новый номер версии.
Номер версии должен быть указан разработчиком при выдаче.
7. На каждом АВ проводим дымный тест
7.0. не должно быть файлов логов!
лоадер: %HOMEPATH%\Desktop\dl2.log
бот: %HOMEPATH%\Desktop\bd2.log
лоадер: c:\temp\ld.log
бот: c:\temp\bd.log
Если файлы есть, значит мы тестируем версию с логами и ее выдавать нельзя!
7.1. нету детекта
7.2. бот отстучал
7.3. проходит команда System Info
7.4. если есть время, тестируем все команды. Если нету времени, ограничиваемся 7.3.
ПЛАН ТЕСТИРОВАНИЯ ОБЩИЙ
Проверяем всю систему в комплексе - резидентный загрузчик, бэкдор, админку.
В настройках антивируса нужно отключить отправку образцов и облачную защиту, во всяком случае на первых порах, дабы не слились образцы.
0. Получаем от разработчика комплект лоадеров - логированная и нелогированная версии, x86 и x64.
Сначала проверяем логированную версию, потом нелогированную. Проверяем на находящихся в сети виртуальных машинах.
Так делаем затем, чтобы на любую ошибку можно было показать лог и позвать разработчика на машину.
Если при проверке нелогированной версии возникла ошибка, пытаемся повторить ее на логированной.
Если на логированной повторяется, фиксируем лог и зовем разработчика.
Если на логированной НЕ повторяется, фиксируем что баг присутствует только на нелогированной версии.
Обязательное условие успеха теста на любом шаге - на экране целевой машины нет никакой активности (всплывающих окон, сообщений от АВ итд),
если иначе не оговорено (например, если это не специальная сборка, которая наоборот показывает запускаемые программы итд итп).
1. Запускаем на целевой ВМ лоадер.
2. Переходим в админку под ролью оператора, которому доступна группа этого бота.
Ждем отстука, в течение 5 минут. Если отстука нет, ошибка, стоп.
Бот должен отображаться как "online", если в течение хотя бы 15 последних минут с ним была связь.
3. Выполняем по очереди команды.
Первая команда может выполниться с задержкой (до 5 минут) - это нормально.
3.1. Get System Info
Должны получить инфу о системе в соотв.вкладке.
3.2. Run .exe с разными комбинациями полей Run Type, Host Process (Mask).
Выбираем для этого такой файл, который не требует сторонних .dll (статически скомпонованный). Например, pscp.exe.
Команда должна выполниться, в результатах выполнения команды должен быть текст вывода этой команды.
* при выборе поля timeout = background run, ответ на команду не ожидается - команда выполняется в фоне и судьба ее нас не интересует.
Бот немедленно готов к приему новых команд.
3.3. Run .dll
TODO
3.4. Run .bat
3.4.1. Вводим какую-нибудь отдельную команду, например hostname, whoami, date /t
Команда должна выполниться, в результатах выполнения команды должен быть текст вывода этой команды.
3.4.2. Заливаем подготовленный .bat-файл из нескольких команд. Тестировщик должен знать результат отработки этого файла на своей машине.
Скрипт должен выполниться, в результатах выполнения команды должен быть текст вывода этого скрипта.
3.5. Run PowerShell
3.5.1. Вводим какую-нибудь отдельную команду, например $PSVersionTable.PSVersion
(выводит версию Powershell)
Команда должна выполниться, в результатах выполнения команды должен быть текст вывода этой команды.
3.5.2. Заливаем подготовленный .ps1-файл из нескольких команд. Тестировщик должен знать результат отработки этого файла на своей машине.
Скрипт должен выполниться, в результатах выполнения команды должен быть текст вывода этого скрипта.
3.6. Reset
Перед выполнением этой команды, нужно запустить выполнение чего-либо длительного (можно попробовать run .bat timeout 10000),
что заблокирует выполнение команд ботом.
После выполнения Reset, предыдущая блокирующая команда должна быть помечена как done, бот готов к приему следующей команды.
3.7. Terminate Process
Команда убивает процесс по его номеру (pid)
Для этого нужно подготовить процесс-жертву (например запустить notepad.exe руками и посмотреть его номер в диспетчере задач).
После выполнения команды процесс должен завершиться.
3.8. Download File
Команда скачивает файл с целевой машины (размер до 10М)
Нужно ввести полный путь к файлу в соотв.поле.
После выполнения команды файл должен быть доступен для скачивания, ссылка должна присутствовать в результатах выполнения команды.
3.9. Suicide
Команда удаляет лоадер с целевой машины.
После перезагрузки машины бот не должен отстукивать.
4. Закрепление.
После перезагрузки машины бот должен отстучать в админку.
5. Детекты.
Не должно быть детектов ни на лоадер, ни на бот.
6. Обновление
6.1. Если запущен лоадер x86 на машине x64, он первым делом должен обновиться до x64 версии себя же,
и далее загружать только x64 бота.
Простыми словами - лоадер должен запускать бота максимально доступной разрядности.
6.2.1. Заходим в раздел админки под ролью QA (это человек, который отвечает за релизы и обновления)
6.2.2. Готовим комплект с новой версией бота и лоадера, в которых прошита та же группа, те же пути обновления.
6.2.3. УзнаЁм у разработчика строку с версией этого комплекта. Примечание: у каждого файла из комплекта может быть своя версия.
6.2.4. Заливаем в панели новые версии файлов, выставляем файлам узнанную на предыдущем шаге версию.
6.2.5. Перезагружаем целевую машину. Обновления должны попасть на машину.