Отчеты о целевых атаках (APT)

Фреймворк Duqu: задача решена

В поисках решения

В предыдущем блогпосте про Фреймворк Duqu я писал про одну из нерешенных нами задач — определение языка, на котором написан необычный код, отвечающий за общение Duqu с C&C серверами. Нам, техническим специалистам, задача показалась очень интересной, и мы решили предложить IT-сообществу поучаствовать в ее решении.

Мы получили намного больше ответов, чем ожидали — более 200 комментариев и 60+ писем с указанием различных языков и фреймворков, которые могли быть использованы при создании кода Фреймворка Duqu. Мы хотим поблагодарить всех, кто участвовал в решении и помогал идентифицировать загадочный код.

Самыми популярными вариантами, которые вы предложили, были:

  • LISP (различные диалекты)
  • Forth
  • Erlang
  • Google Go
  • Delphi
  • OO C
  • Старые компиляторы C++ и других языков

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

igorsk
Simple Object Orientation (for C)

It seems someone over at reddit (http://www.reddit.com/r/ReverseEngineering/) hit the jackpot: the code snippets look _very_ similar to what this would produce: http://daifukkat.su/wiki/index.php/SOO
There are a few other OO frameworks for C, but they don’t match as well: http://ooc-coding.sourceforge.net/ http://sooc.sourceforge.net/

Jonwil
Re: Other C/C++ compiler?

I have seen how GCC works internally and its ABI (for a number of different versions) and I can confirm that the Duqu code is definitely not generated by GCC. I don’t know how other C++ compilers work but the things I see in the ASM (like where the pointers to the functions go, the way the «this» pointer is passed etc) do not suggest C++ to me but something else entirely. (such as the aforementioned «object-oriented» frameworks for C that exist)

igorsk
Re: Other C/C++ compiler?

I’m 99% sure the machine code was generated by MSVC. It’s something you get a feel with experience, but I can point out two things that are quite characteristic of MSVC: 1) it uses esi as the first candidate for temporary storage; 2) «pop ecx» instead of «add esp, 4».

Мы также получили два письма, в которых Pascal Bertrand и другой автор, пожелавший остаться анонимным, предположили, что код Фреймворка Duqu был создан с помощью одного из объектно-ориентированных диалектов языка С, называемых обычно «OO C».

Все эти комментарии оказались очень важными, они позволили точно определить компилятор, который был использован авторами Duqu, — компилятор из поставки Microsoft Visual Studio. После нескольких экспериментов с различными версиями MSVC и опциями компиляции мне удалось воспроизвести код функции конструктора, о котором я писал в предыдущем посте, и получить из этого кода бинарный код, совпадающий с найденным в Duqu.

Результат дизассемблирования кода Duqu: функция конструктора класса связного списка

Восстановленный вручную код этой функции на языке С

При компиляции указанного выше кода на С с помощью компилятора из поставки MSVC 2008 с опциями /O1 (оптимизация по размеру) и /Ob1 (разворачивать только __inline функции) получается машинный код, совпадающий с оригинальным кодом этой функции в Duqu. Следует заметить, что другие опции компиляции, а также изменение порядка операции и if/else блоков изменяет конечный код; компилятор MSVC 2005 также генерирует другой код. Из этого следует, что, скорее всего, Фреймворк Duqu был скомпилирован MSVC 2008 с опциями /O1 /Ob1 из исходного текста на языке С.

Благодаря полученным данным мы можем выделить два наиболее вероятных решения исходной задачи:

  1. Код был написан с использованием объектно-ориентированной надстройки С, основанной на макросах или стороннем препроцессоре. Это решение было предложено и в ваших комментариях, т.к. это стандартный способ реализации объектно-ориентированного подхода в С.
  2. Код был написан на чистом С с использованием объектно-ориентированных методов. Мы не можем полностью отрицать этот вариант, т.к. технически почти невозможно отличить препроцессор от программиста, практикующего разработку в режиме копирования/вставки.

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

В настоящее время существует несколько «ОО С» фреймворков с открытым исходным кодом, причем некоторые из них генерируют код, близкий к коду Duqu. Наиболее похожий код создается с помощью SOO (Simple Object Orientation for C), однако вряд ли именно он был использован — проект появился в то время, когда Duqu уже атаковал первые компьютеры-жертвы.

Независимо от того, какой из вариантов решения является правильным, можно сделать определенные выводы. В Payload DLL содержится 95 Кб событийно-ориентированного кода, написанного на ОО С, — языке без автоматического управления памятью, с небезопасными указателями. Подобный стиль программирования присущ серьезным «гражданским» программным проектам, но не встречается в современном вредоносном ПО. Более того, событийно-ориентированная модель была разработана как часть Duqu или его ОО расширения С.

Трудно однозначно определить причины использования ОО С вместо С++. Мы попробовали найти причины этого, опираясь на описания других ОО С проектов и пообщавшись с профессионалами, использующими подобные методы разработки. Наиболее вероятными причинами представляются:

  1. Недоверие к компиляторам С++. Это типично для разработчиков с многолетним опытом, которые начинали с ассемблера, а затем постепенно перешли на С. Когда появился С++, многие отказались от его использования из-за неявного управления памятью и запутанных конструкций, вызывавших неявное выполнение кода (конструкторы, операторы и т.п.).
  2. Широкая переносимость. Многие годы не было общего для всех компиляторов стандарта С++, возникали проблемы совместимости с компиляторами различных производителей. Если нужно было обеспечить компилируемость различными средствами разработки под несколько платформ, нужно было использовать С.

Обе причины явно указывают, что код Фреймворка был написан разработчиками «старой школы» с многолетним опытом работы.

Выводы

  • Фреймворк Duqu был написан на C и скомпилирован с помощью MSVC 2008 с опциями «/O1» и «/Ob1».
  • При разработке, скорее всего, использовалось собственное объектно-ориентированное расширение языка С, обычно называемое «ОО С».
  • Событийно-ориентированная архитектура была разработана как часть Фреймворка или в рамках расширения ОО С.
  • Код общения с C&C мог быть позаимствован из другого программного проекта и затем адаптирован к задачам проекта Duqu.

Мы полагаем, что разработка велась профессионалами, использующими наработки программистов «старой школы». Подход, который использовали авторы Duqu, обычно встречается в серьезных программных проектах, и почти никогда — во вредоносных программах. Это ещё раз указывает на то, что Duqu, как и Stuxnet, — уникальная разработка, выделяющаяся на фоне всех вредоносных программ.

Фреймворк Duqu: задача решена

Ваш e-mail не будет опубликован. Обязательные поля помечены *

 

Отчеты

StripedFly: двуликий и незаметный

Разбираем фреймворк StripedFly для целевых атак, использовавший собственную версию эксплойта EternalBlue и успешно прикрывавшийся майнером.

Азиатские APT-группировки: тактики, техники и процедуры

Делимся с сообществом подходами, которые используют азиатские APT-группировки при взломе инфраструктуры, и подробной информацией о тактиках, техниках и процедурах (TTPs) злоумышленников, основанной на методологии MITRE ATT&CK.

Как поймать «Триангуляцию»

Эксперты «Лаборатории Касперского» смогли получить все этапы «Операции Триангуляция»: эксплойты нулевого дня для iOS, валидаторы, имплант TriangleDB и дополнительные модули.

Подпишитесь на еженедельную рассылку

Самая актуальная аналитика – в вашем почтовом ящике