27 июня компании на Украине и в других странах стали жертвами масштабной кибератаки шифратора DiskCoder.C (он же ExPetr, PetrWrap, Petya или NotPetya). Малварь маскируется под обычный вымогатель – шифрует данные и требует выкуп за ключ расшифровки. Но, поскольку авторы стремятся нанести максимальный ущерб, шансы на восстановление данных сведены к минимуму.
![](https://habrastorage.org/r/w780q1/web/ca5/6e2/f35/ca56e2f35d9a470e9f43ae5435b27ce8.jpeg)
В прошлом отчете мы указали на связь эпидемии DiskCoder.C с кибергруппой TeleBots и другими атаками на украинские компании. В этой статье раскроем детали о начальном векторе заражения.
Департамент киберполиции Национальной полиции Украины подтвердил информацию ESET и других антивирусных вендоров о том, что легитимное ПО M.E.Doc использовалось злоумышленниками для запуска DiskCoder.C на начальном этапе атаки. Однако до сих пор не было подробностей о том, каким образом реализована эта операция.
В ходе нашего исследования мы обнаружили сложный скрытый бэкдор, внедренный в один из легитимных модулей M.E.Doc. Маловероятно, что злоумышленники сделали это, не имея доступа к исходному коду M.E.Doc.
Имя файла модуля бэкдора –
Мы изучили все обновления M.E.Doc, выпущенные в 2017 году, и обнаружили, что как минимум три апдейта содержали модуль бэкдора:
Сверяем даты. Атака с 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 уже установили безопасное обновление.
Временные метки изученных файлов позволяют предположить, что они были скомпилированы в тот же день или днем раньше.
![](https://habrastorage.org/r/w1560/web/afb/90f/892/afb90f89298540f1b5e3defe21f15b8c.png)
Рисунок 1. Временная метка компиляции модуля обновления с бэкдором, выпущенного 15 мая.
Рисунок 2 показывает различия между списком классов версий модуля
![](https://habrastorage.org/r/w1560/web/295/c9d/b66/295c9db66fdf4fbb9fa465b3d4e543eb.png)
Рисунок 2. Список классов модуля с бэкдором (слева) и без (справа).
Класс, содержащий основной бэкдор, называется
![](https://habrastorage.org/r/w1560/web/408/bc4/b6d/408bc4b6da414e6383d595d86ceaea53.png)
Рисунок 3. Класс MeCom с вредоносным кодом, как показано в ILSpy .NET Decompiler.
Методы класса MeCom вызываются из метода
Каждой украинской компании присваивается идентификатор юридического лица – код по ЕДРПОУ (Единому государственному реестру предприятий и организаций Украины). Это полезно для атакующих – по коду можно идентифицировать организацию, использующую версию M.E.Doc с бэкдором. Далее атакующие могут использовать различные тактики для работы с ее сетью – все зависит от целей.
Поскольку M.E.Doc используется для бухгалтерского учета, можно предположить, что коды ЕДРПОУ будут найдены на машинах, на которых установлено это ПО. Вредоносный код, инжектированный в метод
![](https://habrastorage.org/r/w1560/web/b72/ac2/b37/b72ac2b371404847b38e7a088f4adc3a.png)
Рисунок 4. Код, собирающий коды ЕДРПОУ.
Помимо кодов ЕДРПОУ, бэкдор собирает из приложения M.E.Doc информацию о настройках прокси и почтовой службы, включая логины и пароли.
Внимание! ESET рекомендует всем пользователям M.E.Doc сменить пароли прокси-серверов и учетных записей электронной почты.
Вредоносный код записывает информацию, собранную в реестр Windows под ключ
И самая интересная часть. Бэкдор не использует внешние серверы в качестве C&C, их роль выполняют запросы M.E.Doc к своему официальному серверу upd.me-doc.com[.]ua для проверки наличия обновлений. Единственное отличие от легитимного запроса в том, что бэкдор отправляет в cookie собранную информацию.
Рисунок 5. HTTP запрос бэкдора, который содержит в cookies коды ЕДРПОУ.
Мы не проводили ретроспективный анализ сервера M.E.Doc. Тем не менее, как мы сообщили в прошлом отчете, есть признаки того, что он был скомпрометирован. Поэтому мы предполагаем, что злоумышленники задействовали серверное ПО, что позволило различать запросы от скомпрометированных и чистых машин.
![](https://habrastorage.org/r/w1560/web/e55/2af/275/e552af2758a648d79dcabaab293637a3.png)
Рисунок 6. Код бэкдора, который добавляет cookies в запрос.
Безусловно, авторы бэкдора предусмотрели возможность управления зараженной машиной. Код получает двоичный blob с официального сервера M.E.Doc, расшифровывает его с помощью алгоритма Triple DES, а затем распаковывает с помощью GZip. Результатом является XML-файл, который может содержать сразу несколько команд. Возможность удаленного управления превращает бэкдор в полнофункциональную платформу для кибершпионажа и саботажа.
![](https://habrastorage.org/r/w1560/web/52d/67a/07d/52d67a07dd0a44e7b3786d2ee6d990d0.png)
Рисунок 7. Код бэкдора расшифровывает поступившие команды операторов.
В таблице ниже представлены возможные команды:
![](https://habrastorage.org/r/w1560/web/89d/e1d/f09/89de1df09d0e4c7085a0c35a174364b2.png)
Стоит отметить, что команда 5, названная авторами малвари AutoPayload, полностью соответствует тому, как DiskCoder.C запускался на «нулевых пациентах» – машинах, с которых начиналось заражение сети.
![](https://habrastorage.org/r/w1560/web/159/2af/7a0/1592af7a02264e91a3626539bee4c237.png)
Рисунок 8. Функция AutoPayload использовалась для выполнения DiskCoder.C.
Как показывает исследование, операция была тщательно спланирована и реализована. Мы предполагаем, что атакующие имели доступ к исходному коду приложения M.E.Doc. У них было время изучить код и встроить в него скрытый сложный бэкдор. Размер приложения M.E.Doc около 1,5 Гб, и у нас пока не было достаточно времени проверить, нет ли в нем других бэкдоров.
Нам все еще предстоит ответить на ряд вопросов. Как долго использовался бэкдор? Какие команды и вредоносное ПО, помимо DiskCoder.C и AESNI.C, были направлены через этот канал? Какие еще инфраструктуры скомпрометированы, но пока не использовались кибергруппой, которая стоит за этой атакой?
Благодарим за помощь коллег Frédéric Vachon и Thomas Dupuy.
Детектирование продуктами ESET:
Легитимный сервер, используемый авторами вредоносного ПО:
Ключ реестра:
SHA-1 hashes:
![](https://habrastorage.org/web/ca5/6e2/f35/ca56e2f35d9a470e9f43ae5435b27ce8.jpeg)
В прошлом отчете мы указали на связь эпидемии 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 уже установили безопасное обновление.
Временные метки изученных файлов позволяют предположить, что они были скомпилированы в тот же день или днем раньше.
![](https://habrastorage.org/web/afb/90f/892/afb90f89298540f1b5e3defe21f15b8c.png)
Рисунок 1. Временная метка компиляции модуля обновления с бэкдором, выпущенного 15 мая.
Рисунок 2 показывает различия между списком классов версий модуля
ZvitPublishedObjects.dll
с бэкдором и без, с использованием ILSpy .NET Decompiler. ![](https://habrastorage.org/web/295/c9d/b66/295c9db66fdf4fbb9fa465b3d4e543eb.png)
Рисунок 2. Список классов модуля с бэкдором (слева) и без (справа).
Класс, содержащий основной бэкдор, называется
MeCom
, он расположен в пространстве имен ZvitPublishedObjects.Server
.![](https://habrastorage.org/web/408/bc4/b6d/408bc4b6da414e6383d595d86ceaea53.png)
Рисунок 3. Класс MeCom с вредоносным кодом, как показано в ILSpy .NET Decompiler.
Методы класса MeCom вызываются из метода
IsNewUpdate
в пространстве имен UpdaterUtils
и ZvitPublishedObjects.Server
. Метод IsNewUpdate
вызывается периодически, чтобы проверить, доступно ли обновление. Модуль с бэкдором от 15 мая реализован несколько иначе и имеет меньше функций, чем модуль от 22 июня. Каждой украинской компании присваивается идентификатор юридического лица – код по ЕДРПОУ (Единому государственному реестру предприятий и организаций Украины). Это полезно для атакующих – по коду можно идентифицировать организацию, использующую версию M.E.Doc с бэкдором. Далее атакующие могут использовать различные тактики для работы с ее сетью – все зависит от целей.
Поскольку M.E.Doc используется для бухгалтерского учета, можно предположить, что коды ЕДРПОУ будут найдены на машинах, на которых установлено это ПО. Вредоносный код, инжектированный в метод
IsNewUpdate
, собирает коды из приложения. Одна учетная запись в M.E.Doc может использоваться для бухгалтерского учета нескольких организаций, поэтому код бэкдора собирает все возможные коды ЕДРПОУ. ![](https://habrastorage.org/web/b72/ac2/b37/b72ac2b371404847b38e7a088f4adc3a.png)
Рисунок 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 собранную информацию.
![](https://habrastorage.org/web/31f/daf/b92/31fdafb9243e4d499ed3c09c61f3bba7.png)
Рисунок 5. HTTP запрос бэкдора, который содержит в cookies коды ЕДРПОУ.
Мы не проводили ретроспективный анализ сервера M.E.Doc. Тем не менее, как мы сообщили в прошлом отчете, есть признаки того, что он был скомпрометирован. Поэтому мы предполагаем, что злоумышленники задействовали серверное ПО, что позволило различать запросы от скомпрометированных и чистых машин.
![](https://habrastorage.org/web/e55/2af/275/e552af2758a648d79dcabaab293637a3.png)
Рисунок 6. Код бэкдора, который добавляет cookies в запрос.
Безусловно, авторы бэкдора предусмотрели возможность управления зараженной машиной. Код получает двоичный blob с официального сервера M.E.Doc, расшифровывает его с помощью алгоритма Triple DES, а затем распаковывает с помощью GZip. Результатом является XML-файл, который может содержать сразу несколько команд. Возможность удаленного управления превращает бэкдор в полнофункциональную платформу для кибершпионажа и саботажа.
![](https://habrastorage.org/web/52d/67a/07d/52d67a07dd0a44e7b3786d2ee6d990d0.png)
Рисунок 7. Код бэкдора расшифровывает поступившие команды операторов.
В таблице ниже представлены возможные команды:
![](https://habrastorage.org/web/89d/e1d/f09/89de1df09d0e4c7085a0c35a174364b2.png)
Стоит отметить, что команда 5, названная авторами малвари AutoPayload, полностью соответствует тому, как DiskCoder.C запускался на «нулевых пациентах» – машинах, с которых начиналось заражение сети.
![](https://habrastorage.org/web/159/2af/7a0/1592af7a02264e91a3626539bee4c237.png)
Рисунок 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