Экспресс-анализ вредоносных файлов, прежде всего, обфусцированных вредоносных скриптов (свежих, с пылу с жару) — пример как заинтересовать студентов вопросом [де]обфускации кода.
Глубокий и кропотливый анализ с простроением блок-схем алгоритмов и маршрутов выполнения (а-ля РД контроль НДВ ГТК) — не здесь.

Вместо введения


Искусственные примеры, характерные для многих учебников, часто, к сожалению, отбивают желание разобраться в вопросе. Также плохо, когда первая же учебная задача по изучаемому вопросу настолько сложна, что можно потерять нить рассуждений (при отсутствии опыта, а его, ясно, ещё нет) и вместе с ней — интерес.
Отталкиваясь от вышесказанного и помня, что преподнесение материала — задача и ответственность преподавателя — появилось желание продемонстрировать экспресс-анализ обфусцированных вредоносных скриптов. Благо, достать это «добро» не такая уж большая проблема: целая индустрия исправно трудится на созданием и распространением.
Было получено: внушительная подборка из карантина за предыдущую неделю и скромная подборка скриптов с зараженных сайтов (за 2015 год).
С чего начать? С предварительной подготовки полученного «добра».

Шаг первый (подготовительный)


Распаковываем все архивы, точнее, пробуем архиватором (в данном случае использовался 7zip) распознать и распаковать архивы. Прочему пробуем? Потому что в полученной коллекции файлы с самыми разнообразными расширениями (zip, rar, arj, lzh, ace, exe, uue и др.) могут оказаться архивом.
файл *.zip не всегда zip-архив
На имеющейся коллекции ярко проявилась ситуация, когда внутри файла с расширением характерным для одного архиватора, данные запакованы алгоритмом от другого архиватора. Приблизительно 50% файлов, расширения которых характерны для различных архивов, внутри содержали rar архив.
Расчет понятен: на типовом рабочем месте пользователя (если его рассматривают как цель атаки), как правило, установлен архиватор, который анализирует не только расширение, но и заголовок файла, а значит распакует содержимое, с другой стороны, это может затруднить работу простых защитных систем, которые обрабатывают файлы ориентируясь только по расширению.
Эффективность такой методики для сокрытия кода от антивирусов на промежуточных узлах, вероятно, около нулевая.

Удаляем все дубликаты, т.к. нас не интересует количественный показатель. Запомним полученный на данном этапе список, точнее — имена файлов, он нам ещё понадобится.

Шаг второй (сортировочный) или по стопам Менделеева


Получили список файлов, что же дальше? Разделим файлы по типам:
  • все выявленные архивы (теперь это просто транспортные контейнеры) отдельно;
  • все откомпилированные исполняемые файлы (их анализ, как правило, сложнее, требует больше времени и отладчик) отдельно. Из имеющихся сюда попали только exe и scr (был один exe файл с расширением com);
  • все скрипты, причем каждый тип отдельно. В коллекции было не так много типов, всего 4: js, php, vbs, wsf;
  • в последнюю группу попал единственный файл формата html. Файл не содержал скриптов, поэтому не был включен в предыдущие группы.

Повторимся, количественные показатели — каких типов файлов больше — нас не интересуют. Чтобы представить с какого конца браться, необходимо как-то упорядочить то, что получили. Вспомнив Менделеева, упорядочиваем по «массе»:
  • каждую группу файлов сортируем по размеру;
  • сортируем имена файлов по длине, отбросив расширения (здесь и пригодится общий список файлов).


Шаг третий (анализ) или «метод пристального вглядывания»


Применяя «метод пристального вглядывания» к списку файлов, упорядоченных по длине:
  • сразу бросаются в глаза лидеры, длина которых более 100 символов. Таким образом вредонос скрывает расширение файла, т.к. увидеть его, если не задаться такой целью специально, практически невозможно;
    Пример очень длинных имен
    Акт сверки с приложенным реестром первичной документации на 14.03.2016г. Выгружено из 1С Бухгалтерия _xlsx
    новый документ от 16.03.2016 года актуальная версия для сверки и печати на дату проверено антивирусом ок

  • привлекает внимание значительное количество файлов с одинаковой длиной, если приглядеться — видна структура построения имени. Возможно эти файлы объединяет ещё что-то;
    3 буквы и 10 цифр
    GUA1343958710
    RQQ7223899805
    VII964085171413
    YAF3892579406

  • среди имен с длиной 8 и 10 символов очень много дат в различных форматах, но эта информация мало что нам дает.


Без использования отладчиков из откомпилированных исполняемых файлов обзорно получено следующее:
  • в подавляющем большинстве случаев иконки заменены на иконки документов (от doc(x), xls(x), pdf, иконки характерные для Libre/OpenOffice не встретились ни разу) или мультимедиа (от jpeg, mp3 и др.);
  • некоторые файлы содержали электронную подпись (якобы даже от Microsoft), но недействительную.


Прежде чем переходить к большой группе скриптов рассматриваем единственный файл формата html. Ничем действительно интересным он не порадовал: удаленные символы перевода строки и много комментариев. Это легко вычищается и сразу явно виден прием, который хотели использовать злоумышленники.
html
<meta http-equiv='refresh' content='0; url=http://bad.url/' />

Прием простой, понятный и давно известный.


В wsf скриптах ничего интересного обнаружено не было. После элементарного удаления многострочных комментариев оставался один и тот же код (требующий расшифровки, но ей не занимались).
wsf
<job>
<script language="JScript.Encode">
#@~^+goAAA==&JNi ... DAA==^#~@
</script>
</job>



Деобфускация JS — тема неоднократно раскрыта на Хабре и повторяться особо смысла нет. В коллекции встречались разные приемы.

Интересным и наглядным было более пристальное внимание к группе файлов «3 буквы и 10 цифр». Структура файлов была схожа, если переменным дать одинаковые имена и выполнить ещё некоторые «косметические» преобразования (выровнять отступы, выполнить арифметические операции над числами [чтобы 1+4+1 = 2+2+2 = 3+2+1 = 6]), то схожесть файлов становилась очевидной. Файлы явно были обработаны одним обфускатором. Это продемонстрировало, возможность из потока файлов выявлять группы схожих и, выполнив доскональный анализ отдельных файлов, делать выводы о группах.

Отдельные приемы вредоносов с архивами


Изменение расширения архива уже отмечено выше.
Встречаются вложенные друг в друга архивы как с корректными расширениями, так и нет. Вложенность зависит от фантазии автора и преследует две возможные цели:
  • скрыться от антивирусной проверки (для экономии ресурсов антивирусы, как правило, ограничивают глубину вложенности проверяемых архивов);
  • спровоцировать пользователя [даже осторожного] запустить на выполнение вредоносную нагрузку. Пользователь несколько раз кликает мышью (или нажимает Enter в оболочке) на вложенном архиве, чтобы он открылся, и, с высокой вероятностью, на автомате выполнит то же действие на вредоносной нагрузке.

Прием простой обфускации с использованием функции архивирования был выявлен в php файле. Помимо обфускации и игры в прятки с антивирусом в данном случае сжатие давало и значительную экономию на размере файла.
php
eval(gzinflate(...));

Небольшая модификация кода, которая не выполняет, а сохраняет результат, позволяет за несколько итераций добраться до содержимого. Задачка не сложная и решить её сможет каждый студент. Как результат из изначальных 10k получается скрипт на php на 30k. Скрипт содержит блок авторизации с проверкой хэша пароля, но ещё одна небольшая модификация отключает проверку (или заменяет хэш) и можно посмотреть «настоящий живой хакерский shell-код» в действии: мини файловый менеджер с удобным интерфейсом и с возможностью возможностью выполнения вводимых команд.

Комментарии (11)


  1. vilgeforce
    12.04.2016 17:31
    -2

    Скажите честно: вам не страшно работать с файлами, которые можно случайно запустить? Если да — почему ни слова о переименовании в безопасные расширения?


    1. nvv
      12.04.2016 18:06
      +1

      Вы это серьёзно?
      С потенциально опасными файлами следует работать в соответствующем окружении, а не администратором на ХР на основном рабочем месте, согласен.


      1. vilgeforce
        12.04.2016 20:28
        -2

        С чего бы это? Та же IDA и так далее установлены на хосте, виртуалка только для запуска.


        1. nvv
          12.04.2016 22:42

          Виртуалка — удобно (относительно безопасно, легко откатиться и, главное, дает возможность запустить нужную ОС с набором инструментов).
          Вам же не страшно, что в анализируемом вредоносе будет закладка на побег из виртуального/отладочного окружения? Атака не на пользователя, а на безопасника/аналитика не невозможна.


          1. vilgeforce
            13.04.2016 05:44

            И когда вы в последний раз видели такое?


            1. nvv
              13.04.2016 07:57

              Только синтетические примеры встречал.


              1. LoadRunner
                13.04.2016 10:23

                А если запускать в Wine на Linux? Или и там есть теоретическая возможность «сбежать и навредить»?


                1. nvv
                  13.04.2016 11:11
                  +1

                  Теоретическая возможность есть всегда, вопрос в том насколько она реальна и стоит ли её учитывать.
                  Рассмотрим вектор атаки — вредонос генерирует трафик, который, независимо от того где запускается исследуемый образец, с высокой вероятностью анализируется Wireshark. Не всегда установлены Wireshark и все его плагины самой последней версии (а уязвимости могут быть и в актуальных). В результате может быть выполнение кода с правами пользователя, от которого запущен Wireshark, а это, скорее всего, безопасник/аналитик.


                1. ZyXI
                  13.04.2016 17:38

                  Здесь «теоретических» возможностей вагон и маленькая тележка: Wine создавался не для того, чтобы что?то изолировать. А для того, чтобы запускать приложения для одной ОС как родные в другой.


                  Да тут даже «по?умолчанию» создаётся «диск» под корень всей вашей файловой системы! Конечно, доступ будет как у пользователя, который запускает Wine, но и этого обычно достаточно.


    1. hungry_ewok
      13.04.2016 09:28
      +1

      /флегматично/
      Как уже верно заметили — от этого страховаться надо виртуалкой и снапшотами а не игрой в переименвание.
      Впрочем и на рабочем месте — если для «посмотреть» применять правильный инструмент, тот же старый-добрый фар, то чтобы случайно что-то запустить надо сильно постараться…


  1. icoz
    14.04.2016 23:26

    А вывод-то из статьи какой? Вывалили некое количество информации… и что? Что сказать-то хотели?