Анализ бэкдора группы TeleBots

    27 июня компании на Украине и в других странах стали жертвами масштабной кибератаки шифратора DiskCoder.C (он же ExPetr, PetrWrap, Petya или NotPetya). Малварь маскируется под обычный вымогатель – шифрует данные и требует выкуп за ключ расшифровки. Но, поскольку авторы стремятся нанести максимальный ущерб, шансы на восстановление данных сведены к минимуму.


    В прошлом отчете мы указали на связь эпидемии DiskCoder.C с кибергруппой TeleBots и другими атаками на украинские компании. В этой статье раскроем детали о начальном векторе заражения.

    История о вредоносных обновлениях


    Департамент киберполиции Национальной полиции Украины подтвердил информацию ESET и других антивирусных вендоров о том, что легитимное ПО M.E.Doc использовалось злоумышленниками для запуска DiskCoder.C на начальном этапе атаки. Однако до сих пор не было подробностей о том, каким образом реализована эта операция.

    В ходе нашего исследования мы обнаружили сложный скрытый бэкдор, внедренный в один из легитимных модулей M.E.Doc. Маловероятно, что злоумышленники сделали это, не имея доступа к исходному коду M.E.Doc.

    Имя файла модуля бэкдора – ZvitPublishedObjects.dll. Он написан с использованием .NET Framework. Это файл размером 5 Мб, он содержит легитимный код, который может быть вызван другими компонентами, включая основной исполняемый файл M.E.Doc ezvit.exe.

    Мы изучили все обновления M.E.Doc, выпущенные в 2017 году, и обнаружили, что как минимум три апдейта содержали модуль бэкдора:

    • 10.01.175-10.01.176 от 14 апреля
    • 10.01.180-10.01.181 от 15 мая
    • 10.01.188-10.01.189 от 22 июня

    Сверяем даты. Атака с Win32/Filecoder.AESNI.C (XData) началась через три дня после обновления 10.01.180-10.01.181; DiskCoder.C – через пять дней после апдейта 10.01.188-10.01.189. Четыре обновления в период с 24 апреля по 10 мая и семь – с 17 мая по 21 июня не содержали вредоносный модуль.

    Интересный момент связан с шифратором AESNI.C. Обновление M.E.Doc от 15 мая содержало бэкдор, а следующее, от 17 мая, – нет. Возможно, с этим связано сравнительно небольшое число заражений – атакующие запустили шифратор 18 мая, когда большинство пользователей M.E.Doc уже установили безопасное обновление.

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


    Рисунок 1. Временная метка компиляции модуля обновления с бэкдором, выпущенного 15 мая.

    Рисунок 2 показывает различия между списком классов версий модуля ZvitPublishedObjects.dll с бэкдором и без, с использованием ILSpy .NET Decompiler.


    Рисунок 2. Список классов модуля с бэкдором (слева) и без (справа).

    Класс, содержащий основной бэкдор, называется MeCom, он расположен в пространстве имен ZvitPublishedObjects.Server.


    Рисунок 3. Класс MeCom с вредоносным кодом, как показано в ILSpy .NET Decompiler.

    Методы класса MeCom вызываются из методаIsNewUpdate в пространстве имен UpdaterUtils и ZvitPublishedObjects.Server. Метод IsNewUpdate вызывается периодически, чтобы проверить, доступно ли обновление. Модуль с бэкдором от 15 мая реализован несколько иначе и имеет меньше функций, чем модуль от 22 июня.

    Каждой украинской компании присваивается идентификатор юридического лица – код по ЕДРПОУ (Единому государственному реестру предприятий и организаций Украины). Это полезно для атакующих – по коду можно идентифицировать организацию, использующую версию M.E.Doc с бэкдором. Далее атакующие могут использовать различные тактики для работы с ее сетью – все зависит от целей.

    Поскольку M.E.Doc используется для бухгалтерского учета, можно предположить, что коды ЕДРПОУ будут найдены на машинах, на которых установлено это ПО. Вредоносный код, инжектированный в метод IsNewUpdate, собирает коды из приложения. Одна учетная запись в M.E.Doc может использоваться для бухгалтерского учета нескольких организаций, поэтому код бэкдора собирает все возможные коды ЕДРПОУ.


    Рисунок 4. Код, собирающий коды ЕДРПОУ.

    Помимо кодов ЕДРПОУ, бэкдор собирает из приложения M.E.Doc информацию о настройках прокси и почтовой службы, включая логины и пароли.

    Внимание! ESET рекомендует всем пользователям M.E.Doc сменить пароли прокси-серверов и учетных записей электронной почты.

    Вредоносный код записывает информацию, собранную в реестр Windows под ключ HKEY_CURRENT_USER\SOFTWARE\WC, используя имена значений Cred и Prx. Если эти значения существуют на компьютере, вполне вероятно, что на нем побывал бэкдор.

    И самая интересная часть. Бэкдор не использует внешние серверы в качестве C&C, их роль выполняют запросы M.E.Doc к своему официальному серверу upd.me-doc.com[.]ua для проверки наличия обновлений. Единственное отличие от легитимного запроса в том, что бэкдор отправляет в cookie собранную информацию.


    Рисунок 5. HTTP запрос бэкдора, который содержит в cookies коды ЕДРПОУ.

    Мы не проводили ретроспективный анализ сервера M.E.Doc. Тем не менее, как мы сообщили в прошлом отчете, есть признаки того, что он был скомпрометирован. Поэтому мы предполагаем, что злоумышленники задействовали серверное ПО, что позволило различать запросы от скомпрометированных и чистых машин.


    Рисунок 6. Код бэкдора, который добавляет cookies в запрос.

    Безусловно, авторы бэкдора предусмотрели возможность управления зараженной машиной. Код получает двоичный blob с официального сервера M.E.Doc, расшифровывает его с помощью алгоритма Triple DES, а затем распаковывает с помощью GZip. Результатом является XML-файл, который может содержать сразу несколько команд. Возможность удаленного управления превращает бэкдор в полнофункциональную платформу для кибершпионажа и саботажа.


    Рисунок 7. Код бэкдора расшифровывает поступившие команды операторов.

    В таблице ниже представлены возможные команды:



    Стоит отметить, что команда 5, названная авторами малвари AutoPayload, полностью соответствует тому, как DiskCoder.C запускался на «нулевых пациентах» – машинах, с которых начиналось заражение сети.


    Рисунок 8. Функция AutoPayload использовалась для выполнения DiskCoder.C.

    Выводы


    Как показывает исследование, операция была тщательно спланирована и реализована. Мы предполагаем, что атакующие имели доступ к исходному коду приложения M.E.Doc. У них было время изучить код и встроить в него скрытый сложный бэкдор. Размер приложения M.E.Doc около 1,5 Гб, и у нас пока не было достаточно времени проверить, нет ли в нем других бэкдоров.

    Нам все еще предстоит ответить на ряд вопросов. Как долго использовался бэкдор? Какие команды и вредоносное ПО, помимо DiskCoder.C и AESNI.C, были направлены через этот канал? Какие еще инфраструктуры скомпрометированы, но пока не использовались кибергруппой, которая стоит за этой атакой?

    Благодарим за помощь коллег Frédéric Vachon и Thomas Dupuy.

    Индикаторы заражения (IoC)


    Детектирование продуктами ESET:
    MSIL/TeleDoor.A

    Легитимный сервер, используемый авторами вредоносного ПО:
    upd.me-doc.com[.]ua

    Ключ реестра:
    HKEY_CURRENT_USER\SOFTWARE\WC

    SHA-1 hashes:
    7B051E7E7A82F07873FA360958ACC6492E4385DD
    7F3B1C56C180369AE7891483675BEC61F3182F27
    3567434E2E49358E8210674641A20B147E0BD23C
    ESET NOD32
    180,00
    Компания
    Поделиться публикацией

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

    Комментарии 10

      –4
      Ну и зачем дублировать статьи с гиктаймса на хабр?
      0
      Я, конечно, извиняюсь за свой вопрос, но где был Eset 27-го числа?
      Сейчас все один впереди другого расследования ведут. Тоже нужное дело, конечно, но 27-е было показательным.
        0
        А что антивирус мог сделать? Сигнатур бэкдора еще ни у кого не было, его функционал идентичен любому другому модулю обновлений, так что по поведению все чисто. Расположен был в легитимном месте. Сам шифровальщик/вайпер — другое дело, в статье не о нем.
          0
          Это все правильно, я с этим согласен.
          Но если смотреть на конечный результат — картинка печальная. Ведь народ покупает антивирусы не для того, чтоб они что-то там ловили, а чтоб защитить компьютер, защитить информацию.
          Да и шифровальщик тот-же — хотя бы его остановили.
            0
            Шифровальщик большинство антивирей не видело вообще, так как медок большая часть юзеров добавила в исключения. По советам самого медка.
              0
              Шифровальщик вроде не из медка стартовал?
              С другой стороны, встроенный в винду антивирь с базами полуторагодичной давности смог найти этого Петю. У меня есть непонимание — что мешало остальным сигнатуры добавить.
                0
                На входе в предприятие стартовал из медка, а потом — нет, на других машинах никаких исключений не стояло.
                Кстати, да. Только MS Security Essentials и Windows Defender среагировали во время атаки. Да и то на запись в MBR, которую определили как Petya.A, что и дало название эпидемии. Шифровальщик файлов же свою работу выполнил, как и mimikatz с PsExec или WMI.
        0
        del
          0
          ого! чем дальше в лес, тем интереснее. интересно, что теперь будет с владельцами/администраторами медка — поимеют они проблем с законом или соскочить получится у них?

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

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