Выполнение краткого встроенного сценария asm для динамического анализа - PullRequest
0 голосов
/ 02 ноября 2018

Есть ли какая-либо веская причина не запускать краткий неизвестный (30-строчный) встроенный скрипт сборки в программе пользовательского режима c для динамического анализа прямо на моем ноутбуке?

Существует только один системный вызов времени, и на данный момент я могу сказать, что это функция, которая принимает строку переменного тока и ее длину, и выполняет какое-то шифрование в ней в цикле, который выполняет итерацию только по строке как говорит аргумент длины.

Я знаю, что скрипт (предположительно) написан на вредоносном коде, но я не могу придумать, каким образом он мог бы ударить мой компьютер, исключая какую-то аппаратную ошибку (которая кажется маловероятно, учитывая, что цикл имеет длину ~ 7 инструкций, а самая странная инструкция во всем скрипте - shr).

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

Ответы [ 2 ]

0 голосов
/ 02 ноября 2018

Да, вы можете, но я не буду рекомендовать это.
Проблема не в том, насколько опасен код на этот раз (при условии, что вы действительно поймете все кода и сможете предсказать исход любого системного вызова), проблема в том, что это скользкий склон и он не стоит с учетом того, что поставлено на карту.

Я провел довольно много анализа вредоносных программ и редко случалось, что фрагмент кода застал меня врасплох, но это случилось .
К счастью, я работал на виртуальной машине в изолированной сети: я просто восстановил последний снимок и более тщательно прошел код.
Если вы проведете этот анализ на своей реальной машине, вы можете принять привычку , и однажды это откусит вас назад.
Работа с виртуальными машинами, хотя и не такая удобная, как использование встроенного графического интерфейса операционной системы, - вот путь.

Что может пойти не так с запуском фрагмента сборки из 7 строк?
Я не знаю, это действительно зависит от кода, но есть несколько моментов, которые следует соблюдать осторожность:

  1. Исключения. Инструкция может преднамеренно ошибиться, чтобы передать управление обработчику исключений. Вот почему очень важно, чтобы вы полностью поняли код: и инструкцию, и данные.
  2. Системные вызовы эксплойтов. Специально созданный вход для системного вызова может вызвать 0-дневную или не исправленную уязвимость в вашей системе. Вот почему важно, чтобы вы могли предсказать исход каждого системного вызова.
  3. Анти-отладочные приемы. Существует много способов, которыми кусок кода мог бы избежать отладчика (я думаю, что отладка Windows здесь), трудно запомнить их все, с подозрением относиться ко всему.

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

Наконец, если вы собираетесь запускать вредоносное ПО (поскольку я предполагаю, что работа по извлечению кода и его контекста является слишком обременительным) до точки останова на вашей машине, подумайте о том, что поставлено на карту . Если вы поставите точку останова не на ту точку, если вредоносная программа выберет другой путь, или если отладчик имеет сбойный графический интерфейс, вы можете потерять ваши данные или конфиденциальность вашей машины.
Я по моему мнению не стоит.


Я должен был сделать эту предпосылку ради общности, но мы все чем-то грешим, не так ли?
Я никогда не запускал вредоносные программы на своей машине, но прошел через виртуальную машину, напрямую подключенную к сети компании.
Это был контролируемый шаг, ничего не случилось, компетентный персонал получил совет, и это был счастливый конец.
Это вполне может быть ваш случай: это может быть просто алгоритм расшифровки и ничего более.
Тем не менее, только вы несете окончательную ответственность, чтобы судить, допустимо ли использовать фрагмент кода или нет.
Как я уже отмечал выше, в общем, это не очень хорошая идея, и она предполагает, что вы действительно понимаете код (что-то, что трудно сделать и быть честным). Если вы считаете, что все эти предварительные условия выполнены, то продолжайте и сделайте это .

До этого я бы: 1058 *

  1. Создайте непривилегированного пользователя и запретите ему доступ к моим данным и общим папкам (в идеале запрещайте все, кроме того, что необходимо для работы программы).
  2. Резервное копирование критических данных, если таковые имеются.

Опционально

  1. Сделать точку восстановления.
  2. Возьмите хеш системных папок, список установленных служб и значение обычных ключей реестра для запуска (у Sysinternals есть инструмент для перечисления их всех).

После анализа вы можете убедиться, что ничего важного для всей системы не изменилось.
Может быть полезно subst создать папку и поместить туда вредоносную программу, чтобы обход фиктивного пути прекратился в этой папке.


Нет лучшего решения?
Мне нравится использовать виртуальные машины для их возможностей создания снимков, хотя вы можете наткнуться на проверку анти-VM (но это действительно глупые проверки, поэтому их легко пропустить).

Для сборки из 7 строк я бы просто переписал ее как функцию JS и запустил прямо в консоли браузера.
Вы можете просто преобразовать каждый регистр в переменную и расшифровать код, вам не нужно понимать его глобально, а только локально (т.е. каждую инструкцию).
JS удобен, если вам не нужно работать с 64-битными величинами, потому что у вас есть переводчик прямо сейчас:)
В качестве альтернативы я использую любой язык программирования, который у меня есть под рукой (Однажды, даже собирая его самостоятельно, это кажется парадоксальным, но из-за неприятного трюка мне пришлось преобразовать 64-битный фрагмент кода в 32-битный и патчить вредоносное ПО с ним ).

0 голосов
/ 02 ноября 2018

Вы можете использовать Unicorn , чтобы легко эмулировать процессор (если архитектура поддерживается) и играть с вашим шеллкодом без какого-либо риска.

...