R0 CREW

Malware Analysis Tutorial 33: Evaluation of Automated Malware Analysis System I (Anubis) (Перевод: coldfire)

Перейти к содержанию

Цели урока:

  1. Попрактиковаться в двоичном патчинге
  2. Понять основные принципы построения автоматизированных систем анализа вредоносных программ
  3. Получить опыт работы с Anubis

1. Введение

Так как мы изучили полностью код Max++/ZeroAccess, настало время оценить множество систем автоматизированных систем анализа вредоносных программ. Этот урок рассказывает о нашем опыте работы с такой системой автоматизированного анализа вредоносных программ, как Anubis(так же известный как TTAnalyze). Веб сайт Anubys предоставляет возможность загрузки бинарный исполняемых файлов Windows (http://anubis.iseclab.org/).

Anubis использует API хук для контроля системных вызовов, вызываемых вредоносной программой(и процессов, стартуемых вредоносной программой). Оснащенный парсером структур данных, он может извлекать множество смысловой информации с параметров функции системных вызовов(такой как значения регистров и имена файлов). Это позволяет предоставлять детальный отчет поведения вредоносной программы.

2. Первый запуск Anubis

Для проверки функциональности и достоверности Anubis’а, мы сначала запустим int2d.exe (используемую в уроке 4) в Anubis. Int2d.exe — простой исполняемый файл, который вызывает printf() для того, что бы напечатать 2 строки. Так как этот файл загружен первый раз в Anubis, то процесс создания детального отчета займет около 7.5 мин. Рис.1 демонстрирует детали отчета.

Рис. 1. Anubis анализирует int2d.exe

Как видно на рис. 1, int2d.exe идентифицирован как не вредоносный файл. Он не генерирует подозрительных файлов, данных в реестре или сетевой активности.

3. Первый запуск Max++

Теперь продолжим работать с Max++. В этот раз, генерация отчета в Anubis займет 10 секунд, потому что он его возьмет с его репозитория, основываясь на md5 сумме бинарного файла(т.е., даже если мы изменим имя, то получим тот же отчет). Как показано на рис.2, первый раз Мах++ был загружен в Anubix в ноябре 2010.

Рис. 2. Закешированный отчет о Мах++

Рис. 3 показывает результат анализа Max++. В нем мы видим, что Мах++ имеет подозрительные файлы, создает данные в реестре и создает свои процессы. Конретно, Мах++ порождает 2 процесса: dwwin.exe и drwtsn32.exe. Это очень интересно, потому что мы не наблюдали такой активности на протяжении нашего анализа его. Стало известно, что dwwin.exe и drwtsn32.exe файлы, который относятся к Dr. Watson( часть утилиты по отправке разнообразных отчетов в microsoft). Однако, неизвестно, в этом случаи, если эти файлы уже в системе Anubis, или они поддельные файлы, загруженные Мах++. Мы должны глубже изучить отчет.

Рис. 3. Краткие выводы о работе Max++

Далее Anubis предоставляет детальный отчет о деятельности выполняемой Мах++ и о процессах создаваемых им. Мы сейчас кратко рассмотрим их:

Runtime DLL Activities: Как показано на рис.4, Anubis успешно видит, что lz32.dll загружается во время выполнения, но информация про внедрение и перезапись контента DLL отсутствует.

Рис. 4. Run-time DLL Activities

Операции проводимые с реестром: используется только для чтения значение, не для записи, как видно из отчета.

Операции с файлами. Рис. 5 показывает файловые операции, зарегистрированные в Abubis. Они отличаются от тех, что мы получили в результате нашего анализа. Во-первых, Anubis не отметил, что файлы и драйвера устрой св были модифицированы Max++ и таким образом все операции на скрытом устройстве (и соответственно операции работы с файлами) не были выявлены в Anubis. Во-вторых, зарегистрированные операции (такие как создание временного файла и модификация PIPE\lsarpc [используемая для Local Security Authority] не были отмечены в нашем анализе. Мы подозреваем, что эти операции были сделаны drwtsn32.exe.

Рис. 5. Операции с файлами

Операции с процессами. Рис.6 демонстрирует операции с процессами. Снова, этот отчет отличается от нашего ручного анализа. Отметим, что Мах++ пишет в память других областей(смотри подсвеченные области на рис.6). Мы предполагаем, что это похоже на внедрение удаленного потока существующего процесса(smss.exe), как в нашем анализе.(см. Урок 15). Так как процесс подбирается случайно, то возможно, что drwtsn.exe был выбран во время выполнения. Однако, предназначенное поведение, т. е., удаление max++_download_2010.exe не отображено в отчете в Anubis.

Рис. 6. Операции с процессами

Структурированные исключения. Рис. 7 показывает отчет о операциях, производимых с SEH. Anubis перехватил одну из многих операций с SEH, тем не менее, он не произвел детальный анализ обработчика исключения после того, как исключение было обработано. Например, один, что мы обнаружили в урок 11 не был в отчете.

Рис. 7. Структурированные исключения

Заключение: непонятно для нас в данный момент: если служба Dr. Watson захвачена Max++, или она просто запускается, потому что Max++ падает, как указано в отчете Anubis также содержится скриншот скриншота службы Dr. Watson. Чтобы прояснить этот вопрос, мы должны обеспечить Anubis новым экземпляром Max++ (вместо получения отчетов на основе контрольной суммы MD5).

Рис. 8. Скриншот Dr. Watson

4. Второе испытание. Отчет Anubis на модифицированный Max++

Для того, что бы заставить запустить Мах++ на Anubis, мы намеренно изменяем исполняемый файл, таким образом, что бы изменился его контрольная сумма MD5(которая уже сохранена в Anubis), Следуйте инструкциям ниже, что бы изменить Max++:

Рис. 9. Изменение бинарного файла Max++

  1. Выберите инструкцию, которая никогда не будет выполнена (например, одна из них по адресу 0x00413BD7 на рис. 9).
  2. Сделайте правый клик на панели с кодом → Assemble → NOP.
  3. Правый клик -> Copy to Executable ->All Modified -> Copy All -> нажмите кнопку "close в правой части диалога и потом нажмите «save».

Потом загрузите модифицированный Max++ в Anubis. Генерация отчета займет теперь около 8 минут. Интересно, что отчет остался тем же. Это подтверждает, что Max++ не был загружен в Anubis и он был прекращен досрочно drwtson32.exe.

© Translated by coldfire from r0 Crew

UP