Flame: реконструкция ООП фреймворка

Уже много слов было сказано про червя Flame (Win32/Flamer), но почему то никто не публикует результаты более детального изучения кода этой вредоносной программы. А код у Flame между тем очень интересен и таит в себе еще не мало открытий для вдумчивых и усидчивых исследователей. Ведь не спроста он оставался незамеченным на атакованных системах долгое время, причем на этих системах стаяло антивирусное ПО некоторых известных вендоров, но сейчас все же не об этом ;)

Итак, в чем же связь между Flame, Duqu и Stuxnet? Так как нами были проанализированы все три вредоносные программы, то мы решили не просто описать свои внутренние ощущения, а подтвердить это родство техническими фактами.

Начнем с того, что код Win32/Flamer анализировать не очень приятно, даже при отсутствии жесткой обфускации. Объектно-ориентированный код схож с тем, что уже встречалось ранее в Stuxnet и Duqu, но однозначного сходства не так уж и много. В основном схожесть кроется в стиле кодирования и архитектуре этих вредоносных программ. Если в случае Stuxnet и Duqu ООП архитектура была построена на одном фреймворке и концепциях, то у Flame есть отличия. У всех трех вредоносных программ реализована сложная логика работы, а использование ООП концепций, реализованных на C++, заставляют разбираться в работе не только самой вредоносной программы, но и компилятора тоже. В качестве наглядного примера посмотрите на реконструкцию вызова метода Rc4_GetBufferSize() в модуле mssecmgr.ocx:

Обнаружен новый драйвер для Duqu

Обнаружен новый драйвер (mcd9x86.sys) для Duqu, у которого дата компиляции соответствует концу февраля текущего года. До этого момента наборы компонентов Duqu, которые были у нас в распоряжении, датировались: 2010-11-03/2010-11-03/2011-10-17.

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

ZeroNights: глазами докладчика

Наконец-то нашлось время для того, чтобы как то упорядочить свои впечатления от прошедшей на днях конференции ZeroNights. Организаторам совершенно однозначно удалось достичь высокого уровня докладов и актуальности рассмотренных тем. Так как в этом году мне довелось посетить большое количество зарубежных конференций со всей ответственностью, могу заявить, что ZeroNights был на уровне. Но с точки зрения организации были конечно моменты, которые я озвучу лично оргам и которые хотелось бы избежать в будущих мероприятиях. Мне большего всего не хватало атмосферы "хакерской конференции", как это было на Ekoparty или Confidence.

Мое участие началось с доклада "Современные тенденции развития вредоносных программ для систем ДБО", в котором было рассказано о последних тенденциях и эволюции в разработке банковских троянов, заточенных под Россию. Если охарактеризовать текущую ситуацию одним слайдом, то это будет выглядеть примерно так:

ESET на ZeroNights

Осталось всего несколько дней до основного мероприятия этой осени для исследователей в области ИБ. Мы, как компания с большим штатом ресечеров просто не могли пройти мимо и решили поддержать ZeroNights став основным спонсором мероприятия. Для нашей компании это уже сложившаяся практика поддержки практических конференций. На нашем счету уже такие мероприятия, как PHD, Confidence, Ekoparty, REcon.

В рамках программы мероприятия от нас будет два доклада:

• Современные тенденции развития вредоносных программ для систем ДБО
• Win32/Duqu: инволюция червя Stuxnet (FastTrack)

А еще всех участников конференции ждет новый увлекательный квест по реверсингу, с главным призом Amazon Kindle DX. Подходите к нашему стенду, регистрируйтесь и участвуйте! Правила конкурса простые, кто первый сломал того и Kindle =)

Win32/Duqu REsearch: что скрывает RPC

Мы продолжаем исследование Win32/Duqu, в этом посте поговорим об особенностях использования RPC-протокола. Во-первых, сразу хочу отметить,  что реализация RPC-протокола еще раз подтверждает сходство кода Duqu и Stuxnet. RPC-протокол, был одной из наиболее интересных частей Stuxnet. В Duqu используется, лишь часть от полного функционала этого протокола, который подробно описан в нашем исследовании "Stuxnet under the Microscope" (стр. 56-57).

Проанализировав реализацию RPC-сервера в одном из компонентов Duqu, который реализует лишь локальную часть протокола и сравнив в BinDiff две основные процедуры, мы получили интересные результаты:

Как определить точную дату заражения Win32/Duqu

После того, как появилась первая информация о Win32/Duqu мы не могли пройти мимо, так как нам было очень интересно составить собственные впечатления об этой угрозе (да и challenge со Stuxnet напомнило). Начали копать, оказалось, что код Duqu имеет очень много общего со своим старшим братом Stuxnet. В процессе анализа складывается впечатление, что некоторые части просто полностью повторяют код из Win32/Stuxnet. Код драйверов практически идентичен, еще из наблюдений скорее всего для обоих разработок был использован какой то общий фреймворк для разработки всякого.

С того момента, как мы начали исследовать Win32/Duqu, нас интересовал вопрос, каким образом можно идентифицировать точную дату заражения компьютера этой вредоносной программой (т.к. дроппер нам до сих пор найти не удалось). Такая информация, прежде всего, полезна для проведения криминалистической экспертизы и восстановления картины произошедших событий. У нас появилась идея о том, что если Duqu хранит информацию о моменте своего самоудаления, то должна быть информация, с которой начинается этот отсчет (варианта могло быть два, либо счетчик, либо дата заражения). Нам удалось обнаружить интересную вещь, на данный момент у нас есть несколько наборов сэмплов с различных зараженных машин. И оказалось, что в процессе заражения формируется так называемая main.dll, в которой сохраняется точная дата заражения в UTC-формате. Ниже мы приводим декомпилированный код, осуществляющий проверку этой самой даты:

Win32/Duqu: новый виток развития истории со Stuxnet

Буквально несколько часов назад компания Symantec обнародовала довольно интересный исследовательский отчет "Duqu: the precursor to the next Stuxnet". Собственно повествует он о вредоносной программе, которая своей реализацией сильно напоминает все известный Stuxnet. Причем настолько напоминает, что местами, кажется, что этот код писала одна и таже группа разработчиков. Сценарий работы очень схож со Stuxnet, но кода много и поэтому на 100% процентов для себя еще не подтвердил идентичность авторов. Из интересного вот такая вот сравнительная таблица: