Анализ Outlook-бэкдора кибергруппы Turla

    Turla (Snake, Uroboros) – кибершпионская группа, получившая известность в 2008 году после взлома защищенных объектов, включая сеть Центрального командования ВС США. С тех пор специализируется на атаках на военные объекты и дипломатические ведомства по всему миру. Среди известных жертв – Министерство иностранных дел Финляндии в 2013 году, швейцарская оборонная корпорация RUAG в период с 2014 по 2016 гг. и правительство Германии в конце 2017 – начале 2018 гг.


    После последнего инцидента несколько СМИ опубликовали информацию о методах атакующих – использовании вложений электронной почты для управления вредоносной программой и передачи украденных данных из системы. Тем не менее, технической информации о бэкдоре представлено не было. В этом отчете мы публикуем результаты анализа бэкдора Turla, который управлялся с помощью PDF-вложений в электронной почте.



    По данным СМИ, бэкдором было заражено несколько компьютеров Министерства иностранных дел Германии. По всей видимости, атака началась в 2016 году и была обнаружена службами безопасности в конце 2017. Первоначально атакующие скомпрометировали Федеральную высшую школу государственного управления (Hochschule des Bundes), после чего перемещались внутри ее сети, пока не получили доступ в сеть МИД в марте 2017 года. Операторы Turla имели доступ к некоторым конфиденциальным данным (например, электронной почте сотрудников МИД Германии) около года.


    Наше расследование также показывает, что это вредоносное ПО, нацеленное на Microsoft Outlook, использовалось против различных политических и военных ведомств. Мы убедились, что министерства иностранных дел двух других европейских стран и крупный оборонный подрядчик также были скомпрометированы. Наше расследование позволило установить десятки адресов электронной почты, зарегистрированные операторами Turla для этой кампании, и использовавшиеся для получения эксфильтрованных данных жертв.


    1. Основные тезисы


    Outlook-бэкдор группы Turla имеет две функции.


    Во-первых, это кража исходящих писем, которые пересылаются атакующим. Преимущественно затрагивает Microsoft Outlook, но актуально и для The Bat!, популярного в Восточной Европе.


    Во-вторых, использование писем как транспортного уровня своего С&С протокола. Файлы, запрашиваемые посредством команды бэкдора, эксфильтруются в специально созданных PDF-документах во вложении к письмам. Команды для бэкдора также направляются в PDF-вложениях. Это позволяет обеспечить скрытность. Важно отметить, что атакующие не используют какие-либо уязвимости в PDF-ридерах или Microsoft Outlook. Вредоносное ПО может декодировать данные из PDF-документов и интерпретировать их как команды.


    Цели кампании типичны для Turla. Мы определили несколько европейских госструктур и оборонных компаний, скомпрометированных этим бэкдором. Вероятно, злоумышленники используют его для обеспечения персистентности в сетях ограниченного доступа, где хорошо настроенные фаерволы или другие средства сетевой безопасности эффективно блокируют традиционные коммуникации с С&С серверами через НТТР(S). На рисунке ниже перечислены строки кода бэкдора, в которых упоминаются некоторые правительственные домены верхнего уровня. mfa – домен МИД, .gouv – субдомен французского правительства (.gouv.fr), ocse – Организации по безопасности и сотрудничеству в Европе.



    Рисунок 1. Домены, связанные с госслужбами, найденные в коде малвари


    На основе анализа и данных телеметрии мы установили, что данный бэкдор распространялся in the wild минимум с 2013 года. Как всегда с Turla, мы не можем ориентироваться на временные метки компиляции, так как их обычно подделывают. Тем не менее, мы считаем, что первые версии были скомпилированы раньше 2013 года, поскольку версия этого года была уже довольно продвинутой. После этого мы находили версию, больше похожую на базовую, компиляция которой была датирована 2009 годом. Определить точную дату релиза пока не представляется возможным. Хронология ниже основана на нашей телеметрии и данных из открытых источников:


    2009: Временная метка компиляции (может быть поддельной) базовой версии Outlook-бэкдора. Только снимок email-контента.
    2013: Улучшено: бэкдор может выполнять команды. Они отправляются по электронной почте в формате XML.
    2013: Последняя известная версия, ориентированная на The Bat!..
    2016: Улучшено: команды отправляются во вложениях в специально созданных PDF-документах.
    2017: Улучшено: бэкдор способен создавать PDF-документов для эксфильтрации данных атакующим.
    Март 2018: Сообщение о компрометации сети правительства Германии.
    Апрель 2018: Улучшено: бэкдор может выполнять команды PowerShell, используя Empire PSInject.


    2. Глобальная архитектура


    В последних версиях бэкдор представляет собой автономную DLL, в которой есть код для самоустановки и взаимодействия с почтовыми клиентами Outlook и The Bat!, даже если реализована только установка для Outlook. Его с легкостью может сбросить любой компонент Turla, позволяющий выполнять дополнительные процессы.


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


    2.1. Установка


    Чтобы установить бэкдор, атакующие выполняют экспорт DLL под названием Install или регистрируют ее с помощью regsvr32.exe. Аргументом является целевой почтовый клиент. На рисунке ниже показаны возможные значения. В последних версиях реализована только установка для Outlook.



    Рисунок 2. Возможные аргументы для установки


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


    2.1.1. Microsoft Outlook


    Разработчики Turla полагаются на захват СОМ-объектов (COM object hijacking), чтобы обеспечить персистентность вредоносного ПО. Это известный метод, используемый in the wild на протяжении многих лет, в том числе и группой Turla. Суть метода – перенаправление СОМ-объекта, используемого целевым приложением, посредством модификации соответствующей записи CLSID в реестре Windows.


    В нашем случае в реестре Windows внесены следующие изменения:


    HKCU\Software\Classes\CLSID\{49CBB1C7-97D1-485A-9EC1-A26065633066} =
    Mail Plugin
    HKCU\Software\Classes\CLSID\{49CBB1C7-97D1-485A-9EC1-A26065633066}\InprocServer32  = 
    [Path to the backdoor DLL] 
    HKCU\Software\Classes\CLSID\{49CBB1C7-97D1-485A-9EC1-A26065633066}\InprocServer32\ThreadingModel =
     Apartment
    HKCU\Software\Classes\CLSID\{84DA0A92-25E0-11D3-B9F7-00C04F4C8F5D}\TreatAs = 
    {49CBB1C7-97D1-485A-9EC1-A26065633066}

    {84DA0A92-25E0-11D3-B9F7-00C04F4C8F5D} – захваченный CLSID. Он соответствует Outlook Protocol Manager и в теории загружает легитимную DLL Outlook OLMAPI32.DLL. {49CBB1C7-97D1-485A-9EC1-A26065633066} не связан с каким-либо известным ПО. Это значение CLSID является произвольным и используется только в качестве заполнителя для перенаправления СОМ.


    Когда модификация выполнена, DLL бэкдора будет загружаться каждый раз, когда Outlook загружает свой объект СОМ. По нашим наблюдениям, это происходит во время запуска Outlook.


    Перенаправление СОМ не требует прав администратора, поскольку применяется только для текущего пользователя. Для предотвращения таких вредоносных переадресаций предусмотрены меры защиты. Согласно MSDN: "С Windows Vista и Windows Server 2008, если уровень целостности процесса выше среднего, среда выполнения СОМ игнорирует конфигурацию СОМ пользователя и получает доступ только к конфигурации СОМ для каждой машины".


    Процесс Outlook работает на среднем уровне целостности, как показано на рисунке ниже. Таким образом, он не защищен от переадресации СОМ для каждого пользователя.



    Рисунок 3. Уровень целостности процесса Outlook


    Наконец, использование захвата СОМ-объектов позволяет бэкдору избегать обнаружения, поскольку путь к бэкдору (C:\Users\User\Documents\mapid.tlb в нашем примере) не отображается в списке плагинов, как показано на следующем рисунке.



    Рисунок 4. Список плагинов Outlook – mapid.tlb не отображается


    Даже если вредоносная программа не отображается в списке надстроек, для взаимодействия с Outlook используется стандартный Microsoft API – MAPI (Messaging Application Programming Interface).


    2.1.2. The Bat!


    Как уточнялось в хронологии, последние версии бэкдора больше не включают код для регистрации плагина The Bat!.. Тем не менее, весь код для управления почтовыми ящиками и сообщениями все еще существует. При необходимости его можно настроить вручную.


    Для регистрации в качестве плагина для The Bat! вредоносная программа изменяла файл %appdata%\The Bat!\Mail\TBPlugin.INI. Это легитимный способ регистрации плагина для The Bat!, некоторые плагины (например, антиспам) также используют его.


    После регистрации при каждом запуске The Bat! вызывается DLL бэкдора. На рисунке ниже показано, как DLL реализует экспорт, необходимый для плагинов.



    Рисунок 5. Стандартный экспорт для плагина The Bat!


    2.2. Взаимодействие с почтовым клиентом


    Взаимодействие с почтовым клиентом зависит от цели.


    2.2.1. Microsoft Outlook


    Microsoft поддерживает Messaging Application Programming Interface (MAPI), который позволяет приложениям взаимодействовать с Outlook. Бэкдор Turla использует этот API для доступа и управления почтовыми ящиками пользователя/пользователей скомпрометированной системы.


    Во-первых, бэкдор подключается к системе обмена сообщениями, используя MAPILogonEx, как показано на рисунке.



    Рисунок 6. MAPI logon


    Второй параметр (lpszProfileName) пуст, задан флаг MAPI_USE_DEFAULT. Согласно документации: "Подсистема обмена сообщениями должна подменять имя профиля по умолчанию для параметра lpszProfileName. Флаг MAPI_EXPLICIT_PROFILE игнорируется, за исключением случаев, если lpszProfileName имеет значение NULL или пуст".


    Напротив, флаг MAPI_NEW_SESSION не задан. Согласно документации: "Параметр lpszProfileNameигнорируется, если существует предыдущий сеанс под названием MapiLogonEx с заданным флагом MAPI_ALLOW_OTHERS и если флаг MAPI_NEW_SESSION не установлен".


    По нашему мнению, Outlook открывает сеанс по умолчанию с флагом MAPI_ALLOW_OTHERS. Таким образом, бэкдор будет использовать ранее открытый сеанс, чтобы получить доступ к дефолтному профилю почтового ящика. Это объясняет отсутствие запроса имя пользователя и пароля при инициализации плагина бэкдора.


    Сделав это, бэкдор получит доступ к почтовому ящику и сможет легко управлять им с помощью других функций MAPI. Он будет выполнять итерации через различные хранилища сообщений, анализировать письма и добавлять обратный вызов входящих и исходящих сообщений. Лог-файл отображает этот процесс (изменено имя пользователя и адрес):


    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
     ========= Analyzing msg store ( 1 / 1 ) =========
    Service name:MSUPST MS
    Pst path:C:\Users\[username]\Documents\Outlook Files\[email address].pst
        Wait main window before open current store
         Loop count = 46
    This is default message store
     PUSH store to list
     >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
     _____________ FOLDERS _____________
     Setting sink on folders in 1 stores.
     ========Process msg store ( 1 / 1 ) =========
     Account: [email address]
     Successfull set sink on Outbox folder of current store.
    Successfull set sink on Inbox folder of current store.

    Он устанавливает обратный вызов в каждой папке входящих и исходящих сообщений, используя функцию HrAllocAdviseSink, как показано на рисунке.



    Рисунок 7. Регистрация обратного вызова в папке «Исходящие»


    2.2.1.1. Обратный вызов в папке входящих сообщений


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


    RECIVE ->{
      From: sender@example.com
      To:   receiver@example.net
      Cc:  
      Bcc: 
      Subj: Mail subject
      Att:  an_attachment.pdf
    }

    Затем он анализирует письмо и вложения на предмет команд от атакующих. Эта функция описана в разделе 2.3.


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


    2.2.1.2. Обратный вызов в папке исходящих сообщений


    Как и в папке входящих сообщений, в исходящих записываются метаданные всех отправляемых писем. Генерируется следующая запись (адрес оператора изменен):


    21:57:56
    SEND <-{
      From:
      To:   recipient@example.com
      Cc:
      Bcc:
      Subj: My title
      Att:  [1] "last_presentation.pdf"
    }
    21:57:56 Sending data message
    21:57:56 Message ENTRYID: [Message ENTRYID]
    21:57:56 Data message was send. To: [redacted]@gmx[.]com From:  Subj: My title
    21:57:56 Set last time.
    21:57:56 Spawned thread for cleaning up outgoing messages (id 2848)
    21:58:34 Ending work, client: Outlook
    21:58:34 Number of messages to remove: 1
    21:58:34 Message ENTRYID: [Message ENTRYID]
    21:58:34 DeleteMessages executed successfully.
    21:58:34 Number of not removed messages: 0

    Вы можете заметить, что он пересылает каждое исходящее сообщение на адрес атакующих, […]@gmx[.]com. GMX – популярный бесплатный почтовый сервис; вероятно, атакующие выбрали его, поскольку организации обычно не блокируют домен gmx.com.


    Этот адрес электронной почты жестко закодирован в образце, который мы изучали, как показано на рисунке ниже. Однако его можно обновить с помощью одной из функций бэкдора. Кажется, атакующие регистрируют хотя бы один адрес электронной почты для каждой целевой
    организации, используя формат firstname.lastname@gmx[.]com с именем реального сотрудника. Это позволяет избегать обнаружения, поскольку зачастую сложно отличить такой адрес от реально существующего личного ящика сотрудника. На момент анализа образца в июне 2018 года адрес был недоступен.



    Рисунок 8. Жестко закодированный адрес операторов


    Бэкдор отправляет на адрес операторов отчеты с определенными интервалами. В отчет входят уникальные идентификаторы, включая МАС адрес, полный файл журнала и результаты выполнения команд, если таковые имеются. Затем он шифрует данные, используя MISTY1, как описано далее в разделе 2.3.2.2, и создает валидный PDF-файл с зашифрованным контентом. Перед данным зашифрованным блобом данных документ содержит белое изображение 1x1 в jpeg, жестко закодированное во вредоносной программе. Это позволяет создавать валидный PDF, который при открытии отображает только одну пустую страницу.


    Наконец, бэкдор прикрепляет PDF и отправляет письмо на адрес атакующих. Рисунок ниже – пример PDF-файла, созданного бэкдором.



    Рисунок 9. Начало PDF-документа, созданного бэкдором для эксфильтрации данных


    Отчет отправляется с помощью функции обратного вызова в папке исходящих сообщений. Это означает, что письмо уйдет одновременно с отправкой легитимных сообщений пользователя. Бэкдор не может отправлять письма с украденными данными в нехарактерное для пользователя время и потому избегает детектирования. Благодаря скрытности данный механизм управления и контроля очень сложно обнаружить in the wild.


    2.2.2. Маскировка вредоносного поведения от пользователя


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


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



    Рисунок 10. Непрочитанное сообщение


    Во-вторых, бэкдор перехватывает функцию CreateWindowsEx, как показано на рисунках ниже. Это предотвращает создание окон типа NetUIHWND, используемых Outlook для уведомлений, которые отображаются в нижней правой части экрана.



    Рисунок 11. Настройка перехвата функции CreateWindowsEx



    Рисунок 12. Перехват CreateWindowsEx


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



    Рисунок 13. Уведомление о новом сообщении


    2.2.3. The Bat!


    Несмотря на то, что функции регистрации плагина для The Bat! больше не существует, есть унаследованный код, который выполняет те же функции, что и для Outlook, используя API The Bat!..


    Как показано на следующем рисунке, бэкдор использует канал коммуникаций с The Bat!, чтобы получать информацию пользователей, читать и отправлять письма. Однако все остальные функции, например, использующиеся для логирования писем или выполнения команд, идентичны Outlook.



    Рисунок 14. Канал The Bat!


    2.3. Бэкдор


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


    2.3.1. PDF-формат


    В начале 2018 года несколько СМИ заявили, что операторы Turla используют вложения в электронной почте для управления зараженными компьютерами. СМИ были правы. Анализ Outlook-бэкдора Turla позволил выяснить, как он отправляет и интерпретирует команды.


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


    Из PDF-документов бэкдор может восстановить то, что операторы называют в журналах контейнером. Это блоб со специальным форматом, который содержит зашифрованные команды для бэкдора. На рисунке ниже показана процедура, отвечающая за извлечение этого контейнера. Технически приложение не должно быть валидным PDF-документом. Единственное требование – он включает контейнер в правильном формате.



    Рисунок 15. Извлечение контейнера команд из PDF


    Контейнер имеет сложную структуру с множеством различных проверок. Он мог быть разработан для предотвращения ошибок связи, но мы полагаем, что структура создана преимущественно для противодействия реверс-инжинирингу. Структура контейнера показана на рисунке ниже.



    Рисунок 16. Структура контейнера команд


    Непосредственно перед вектором инициализации имеется список дескрипторов команд. Различные значения ID представлены в таблице:




    Дескрипторы ID 2 и 4 используются для извлечения функций шифрования и декомпрессии, как показано на следующем рисунке. Однако во вредоносной программе реализован только один алгоритм шифрования и один алгоритм сжатия. Таким образом, единственное назначение этих полей – усложнять анализ бэкдора.



    Рисунок 17. Смещение функций декомпрессии и расшифровки


    Команды находятся в последней части структуры. Они зашифрованы с помощью MISTY1 и сжаты с bzip2. В одном и том же PDF-файле может быть много разных команд, и каждая может иметь несколько аргументов.


    2.3.2. Криптография


    Здесь мы опишем используемые алгоритмы шифрования.


    2.3.2.1. XOR шифрование


    Часть контейнера (начиная с первого CRC32) зашифрована с XOR с байтовым потоком, генерируемым пользовательской функцией. Требуется начальное число (seed), которое передается в srand, чтобы генерировать второе число путем вызова rand. Второе начальное число используется в функции, показанной ниже, в качестве аргумента с данными в XOR.


    int __usercall F_bytestream_xor@<eax>(unsigned int len@<edx>, int ciphertext@<ecx>,
    unsigned int seed)
    {
    unsigned int v3; // ebx
    int v4; // esi
    unsigned int v5; // edi
    int result; // eax
    unsigned int v7; // ecx
    char *v8; // edx
    unsigned int v9; // esi
    byte key[512]; // [esp+Ch] [ebp-204h]
    char *v11; // [esp+20Ch] [ebp-4h]
    v3 = len;
    v11 = (char *)ciphertext;
    srand(seed);
    v4 = 0;
    v5 = 0;
    do
    {
     result = rand();
     *(_DWORD *)&key[4 * v5++] = result;
    }
    while ( v5 < 128 );
    v7 = 0;
    if ( !v3 )
     return result;
    v8 = v11;
    do
    {
     v8[v7] ^= key[v4];
     v9 = v4 + 1;
     result = -(v9 < 512);
     v4 = result & v9;
     ++v7;
    }
    while ( v7 < v3 );
    return result;
    }

    2.3.2.2. MISTY1


    Разработчики Turla предпочитают использовать менее распространенные или модифицированные алгоритмы шифрования в своих бэкдорах:


    • в Carbon и Snake – CAST-128
    • в Gazer – кастомная реализация RSA
    • в Mosquito – Blum Blum Shub в качестве генератора случайных чисел для байтового потока XOR
    • в рутките Uroburos – модифицированная версия ThreeFish

    В Outlook-бэкдоре они внедрили MISTY1 – симметричный алгоритм шифрования, разработанный криптографами Mitsubishi Electric в 1995 году. Он обладает следующими свойствами:


    • является симметричным
    • имеет 128-битный ключ
    • использует две предварительно вычисленные таблицы: s7 (128 байт) и s9 (2048 байт)
    • использует три функции: FL, FO, FI
      o FL выполняет некоторые операции XOR между записью байта и расширенным ключом
      o FO выполняет операции XOR между записью и расширенным ключом, а также использует FI
      o FI выполняет нелинейную подстановку, используя s7 и s9
    • оперирует блоками по 64 бита
    • выполняет восемь циклов (цикл – вызов функции FO)
    • использует шифр Фейстеля


    Рисунок 18. MISTY1



    Рисунок 19. Восемь циклов для шифрования блока


    Разработчики Turla немного модифицировали алгоритм:


    • добавили две операции XOR в функцию FI, как показано на рисунке ниже
    • 128-битный ключ генерируется из двух жестко закодированных 1024-битных ключей плюс 2048-битный вектор инициализации
    • изменили таблицы s7 и s9. Это нарушает работу всех инструментов, которые распознают криптографические алгоритмы, основанные на значениях s-таблиц. И модифицированные, и оригинальные s-таблицы содержат одни и те же значения, их просто перетасовали


    Рисунок 20. Сравнение функций FI (слева оригинал, справа разработка Turla)


    2.3.3. Функции


    В бэкдоре реализовано множество функций – от эксфильтрации файлов до выполнения команд. Описание различных функций – в таблице ниже.




    Для функции 0x29 разработчики Turla скопировали код из проекта Empire PSInject. Это позволяет запускать код PowerShell в специальном исполняемом файле под названием PowerShell Runner без вызова powershell.exe. Основное преимущество в том, что вредоносное ПО все еще может выполнять команды PowerShell, даже если файл powershell.exe заблокирован на скомпрометированном компьютере.


    После анализа бэкдора нам удалось создать PDF-документ, который может быть успешно интерпретирован вредоносной программой. На следующем рисунке показано выполнение MessageBox и запуск калькулятора (calc.exe) после того, как Outlook получил электронное письмо, содержащее этот PDF-документ. Это демонстрирует, что бэкдор, вероятно, предназначенный для получения команд в PDF-вложениях, является функциональным и может управляться любым, кто разберется в этом кастомном формате.



    Рисунок 21. Выполнение команд, заданных в PDF-документе


    2.4. Дополнительные функции


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


    2.4.1. Виртуальная файловая система


    Вредоносная программа не использует какие-либо файлы конфигурации, но поддерживает небольшую виртуальную файловую систему в разделе реестра Windows HKCU\Software\Microsoft\Windows\CurrentVersion\Settings\ZonePolicy\. Другие бэкдоры Turla, например, Gazer, также сохраняют виртуальную файловую систему в реестре Windows. Мы смогли определить некоторые значения реестра, как показано в следующей таблице.



    2.4.2. Журналы


    Как было сказано ранее, программа сохраняет журнал, который регулярно пересылается оператору электронной почтой в специально созданном PDF-документе. Он хранится в %appdata%/Microsoft/Windows/scawrdot.db и шифруется с помощью жестко закодированного 512-байтного ключа XOR. Файл журнала очищается после каждой эксфильтрации операторам. Таким образом, в ходе криминалистической экспертизы было бы невозможно увидеть все прошлые действия бэкдора, только последние.


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



    Рисунок 22. Расшифрованный файл журнала


    3. Выводы


    Отчет показал, что разработчикам Turla хватает идей, когда они разрабатывают бэкдоры. Насколько нам известно, Turla – единственная кибершпионская группа, которая в настоящее время использует бэкдор, полностью управляемый через электронную почту, точнее, PDF-вложения.


    Бэкдор Turla не первым использует реальный почтовый ящик жертвы для получения команд и эксфильтрации данных. Однако это первый изученный бэкдор, использующий стандартный API (MAPI) для взаимодействия с Microsoft Outlook. Это существенная доработка в сравнении с прежней версией, которую мы изучили, которая использовала Outlook Express. Напротив, новый бэкдор Turla работает даже с последними версиями Outlook.


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


    Наше исследование показывает, что за скомпрометированными организациями может следить не только Turla, внедрившая бэкдор, но и другие кибергруппы. Бэкдор просто выполняет любые команды, которые получает, не имея возможности распознать оператора. Вполне возможно, что другие злоумышленники уже выполнили реверс-инжиниринг бэкдора и выяснили, как им управлять и использовать в своих целях.


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


    Специалисты ESET продолжают следить за разработками Turla, чтобы помочь специалистам по безопасности защищать сети организаций.


    Индикаторы компрометации доступны также на GitHub.


    4. Индикаторы компрометации


    4.1. Хеши


    8A7E2399A61EC025C15D06ECDD9B7B37D6245EC2 — бэкдор Win32/Turla.N; время компиляции (GMT) 2013-06-28 14:15:54
    F992ABE8A67120667A01B88CD5BF11CA39D491A0 — дроппер Win32/Turla.AW; GMT 2014-12-03 20:50:08
    CF943895684C6FF8D1E922A76B71A188CFB371D7 — бэкдор Win32/Turla.R; GMT 2014-12-03 20:44:27
    851DFFA6CD611DC70C9A0D5B487FF00BC3853F30 — бэкдор Win32/Turla.DA; GMT 2016-09-15 08:14:47


    4.2. Имена файлов


    %appdata%/Microsoft/Windows/scawrdot.db
    %appdata%/Microsoft/Windows/flobcsnd.dat
    mapid.tlb


    4.3. Ключи реестра


    HKCU\Software\Microsoft\Windows\CurrentVersion\Settings\ZonePolicy\
    HKCU\Software\Classes\CLSID{49CBB1C7-97D1-485A-9EC1-A26065633066}
    HKCU\Software\Classes\CLSID{84DA0A92-25E0-11D3-B9F7-00C04F4C8F5D}

    ESET NOD32

    118,00

    Компания

    Поделиться публикацией

    Похожие публикации

    Комментарии 1
      +1
      Мда, «круто». Наверно вариант как отследить эту заразу, если она работает — каким-то образом скриптами сравнивать состояние локального почтового ящика (OST/PST) и журналов на Exchange'е. Раз малварь подтирает свои принятые мейлы с командами и отосланные мейлы с украденной информацией/статусами — все равно эти письма прошли через Exchange и до туда малварь дотянуться не может. Значит есть дельта. Но отслеживать такое, если ящиков/пользователей тысячи… Хотя если все можно делать со стороны Exchange — может и не так уж нереально. Если то что у пользователя в Outlook (в OST файле) «видно» со стороны сервера — тогда можно сравнивать с журналами транспорта, тогда все реализуемо. Поправьте если не так.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое