Nyetya (він же Petya) — руйнівний варіант програми-здирника, який зачепив багато українських організацій та міжнародних корпорацій, що працюють в Україні. У співпраці із командою реагування на інциденти Cisco Advanced Services підрозділ Talos ідентифікував декілька ключових аспектів атаки.
В процесі розслідування було виявлено атаку на ланцюжок поставок (supply chain) програмного забезпечення M.E.Doc, яке розповсюджувало деструктивний програмний код, замаскований під здирника. Використовуючи вкрадені облікові дані, зловмисники змогли маніпулювати сервером оновлень M.E.Doc для проксі-з’єднань із підконтрольним їм сервером. Виходячи з отриманих даних, Talos впевнився в тому, що напад мав саме руйнівний характер. І він набув широкого поширення — українська кіберполіція підтверджує понад 2000 постраждалих компаній лише в Україні.
Деталі
Для Talos день 27 червня 2017 року розпочався з повідомлення від наших співробітників в Україні. Вони просили про допомогу — відбулася масована атака з використанням ransomware, програм для вимагання викупу. Зловмисники розповсюдили свій код серед комп’ютерних систем користувачів найпопулярнішого в Україні ПЗ для бухгалтерської звітності, у тому числі до міжнародних корпорацій, які працюють у країні. Вони вирішили використати цю вразливість для шифрування критичних файлів та жорстких дисків без можливості дешифрування.
З моменту атак BlackEnergy наприкінці 2015 року Talos співпрацює з публічними та приватними організаціями в Україні в рамках протидії кібернападам. Раніше в цьому році Talos вже доводилося допомагати організаціям, проти яких були вжиті деструктивні заходи. Цікаво, що в цих випадках до системи внесли шкідливий код для знищення даних, дуже схожий на попередній (від Black Energy). Та після його блокування за допомогою нашого Advanced Malware Protection (AMP) зловмисники повернулися до варіанту ransomware, намагаючись перешкодити діяльності організацій. Пам’ятаючи про останній випадок, ми майже одразу зрозуміли, що події, які відбуваються цього разу, є чимось більшим, ніж звичайна ransomware-атака.
Зв’язковий M.E.Doc
Вже із самого початку стало зрозумілим, що хоча більшість минулих випадків були зареєстровані в Україні, під вплив шкідливого ПЗ потрапили організації, які не мали прямого зв’язку із цією країною. Через вочевидь великий масштаб події Talos активував внутрішню систему реагування TaCERS (Talos Critical Event Response System). Система TaCERS розподіляє активності між командами аналітики, аналізу телеметрії, реверсної інженерії, детектування та зовнішніх комунікацій. Дослідники й інженери Talos з усього світу об’єдналися для боротьби з новою загрозою.
Завдяки телеметрії кінцевих точок було з’ясовано, що центром активності стало українське бухгалтерське програмне забезпечення M.E.Doc. Як і у випадку з WannaCry, були повідомлення про наявний поштовий вектор атаки. Справа в тому, що на деяких з перших заражених машин були одночасні інфекції Lokibot з індикаторами поштового вектору розповсюдження. Шляхом ретельного дослідження Talos дійшов висновку, що при розповсюдженні шкідливого коду Nyetya всі інсталяції були отримані через систему апдейтів M.E.Doc.
M.E.Doc — широко розповсюджене програмне забезпечення, створене українською компанією «Інтелект-Сервіс». Програма використовується для взаємодії з українськими податковими системами. На момент виявлення джерела загрози ми мали змогу безпосередньо зв’язатися із розробниками M.E.Doc та запропонувати допомогу.
У M.E.Doc швидко пристали на нашу пропозицію. В рамках глобальної реакції Cisco на подію ввечері 29 червня до України прибули два фахівці з реагування на інциденти з групи Advanced Services. Ще один фахівець дистанційно підтримував розслідування з Великої Британії. Співробітники M.E.Doc були виключно відкритими з точки зору надання доступу до своїх інженерів та адміністраторів, які ознайомили команду із системою та надали доступ до лог-файлів і коду. Вони також погодились поділитися результатами нашого дослідження.
У кожному дослідженні Cisco у будь-якій точці світу команді реагування надається спеціальний ресурс Talos для координування аналізу даних, залучення реверсивної інженерії й аналізу телеметрії. При цьому дві команди постійно працюють одночасно. Такий досвід був повною мірою використаний і в цьому випадку.
На ранньому етапі дослідження було виявлено web shell (шкідливий скрипт) за адресою
http://www.me-doc[.]com[.]ua/TESTUpdate/medoc_online.php. Часова позначка файлу — 31 травня 2017 року, 14:45. Наш аналіз показує, що це — дещо модифікована версія web shell PAS із відкритим кодом на PHP. Скрипт зберігається у зашифрованому вигляді та вимагає для розшифрування парольної фрази, яка задається у змінній HTTP POST. Результатом розшифрування є повнофункціональний web shell PAS.
Зв’язковий M.E.Doc
Як тільки наша команда з реагування отримала доступ до логів і додаткових даних, їх завантажили до Talos. Це відкрило 24-годинний цикл, і коли в Україні настав вечір, команда реагування Cisco розповіла Talos про свої знахідки та нові дані. Пізніше, коли українці збиралися на роботу, Talos уже брифував команду реагування Cisco, звітуючи про свої нічні знахідки.
Майже одразу були визначені індикатори проблеми. Під час брифінгу о третій ранку 1 липня команда Talos пройшлася по ключових доказах, знайдених у логах. Ми побачили наступне:
Зв’язковий M.E.Doc
Невідомі зловмисники викрали облікові дані адміністратора M.E.Doc. Вони увійшли в сервер, отримали root-привілеї та почали модифікувати файл конфігурації веб-серверу NGINX. Нам не вдалося відновити файл nginx.conf, оскільки він був послідовно перезаписаний, тому додаткові log-файли були важливими для розуміння того, що саме було змінено. Ми знайшли тисячі помилок подібних до цієї:
[error] 23401#0: *374685644 upstream timed out (60: Operation timed out) while connecting to upstream, client: , server: upd.me-doc.com.ua, request: «GET /last.ver?rnd=1b2eb092215b49f5b1d691b5c38e3a74 HTTP/1.1», upstream: «http://176.31.182.167:80/last.ver?rnd=1b2eb092215b49f5b1d691b5c38e3a74», host: «upd.me-doc.com.ua»
Сервер NGINX переконфігурували таким чином, що будь-який трафік до upd.me-doc.com.ua перенаправлявся у режимі проксі через апдейт-сервер до хоста в IP-просторі OVH з IP-адресою 176.31.182.167. Подальше дослідження виявило, що цей сервер керувався реселлером thcservers.com і був стертий того ж дня о 19:46 UTC.
Коли ми порівняли час першого й останнього upstream-повідомлення про помилку з нашою локальною телеметрією кінцевих точок, з’ясувалося, що вони можуть слугувати маркерами початку та кінця активної фази інфікування. Початкове повідомлення логу було датоване 9:11:59 UTC, а останнє — зареєстровано о 12:31:12 UTC. У нашій телеметрії ми не бачимо нових організацій, інфікованих поза межами цього часового проміжку.
Ми знайшли ще один доказ на підтвердження того, що подію було завершено близько 12:30 UTC. Часова позначка файлу nginx.conf на момент проведення нашого аналізу — 27 червня 12:33 UTC. У цей час зловмисники повернули конфігурацію NGINX до її оригінального стану. Окрім цього, залишився лише один вартий уваги індикатор — латвійська IP-адреса, яка від’єдналася від системи о 02:11:07 UTC:
Received disconnect from 159.148.186.214: 11: FlowSshClientSession: disconnected on user’s request
У M.E.Doc підтверджують, що ні OVH-сервер, ні латвійська IP-адреса не мають жодного стосунку до M.E.Doc.
На цьому етапі ми зрозуміли, що зловмисники отримали доступ до більшої частини мережі та систем M.E.Doc за допомогою компрометованих облікових даних. Питання, які залишались нез’ясованими: що вони робили під час контролю сервера оновлень та як саме було надіслано шкідливе програмне забезпечення?
Хоча на момент проведення розслідування це було невідомо, зараз ми можемо підтвердити дослідження ESET щодо бекдору, який внесли до програмного забезпечення M.E.Doc. Код .net у файлі ZvitPublishedObjects.dll зазнав неодноразових модифікацій, що дозволило зловмисникам збирати дані, завантажувати та виконувати довільний код:
Зв’язковий M.E.Doc
Дивлячись у більш ранні логи, надані M.E.Doc, можна побачити таку саму «upstream-активність» 22-го червня. На жаль, ми на маємо логів за травень або квітень, але розумно буде припустити, що подібне траплялося і раніше.
Зв’язковий M.E.Doc
Аналіз бекдору у ZvitPublishedObjects.dll
Бекдор був внесений до функції ZvitPublishedObjects.Server.UpdaterUtils.IsNewUpdate function у файлі ZvitPublishedObjects.dll:
Зв’язковий M.E.Doc
Між рядками 278 та 279, наведеними ліворуч, праворуч ви бачите код, який було внесено для отримання ЄДРПОУ та назви кожної організації. Потім створюється новий об’єкт MeCom та потік для нього, який зв’язується з
http://upd.me-doc.com.ua/last.ver?rnd=<GUID> кожні дві хвилини. Також він використовуватиме цей URL для надсилання відповідей.
Якщо проксі-сервер був налаштований, після створення об’єкт MeCom на рядку 288 праворуч продовжує роботу і отримує хост, порт, ім’я користувача та пароль проксі-сервера:
Зв’язковий M.E.Doc
Потім він витягує SMTP-хост, ім’я користувача, пароль та email-адресу для кожної організації в базу даних програми:
Зв’язковий M.E.Doc
Також він записує попередньо зібраний проксі-сервер до ключа реєстру: HKCU\SOFTWARE\WC. Ім’я користувача і пароль проксі-сервера зберігаються в підключі Cred, а повна інформація проксі-сервера — у Prx.
На рядку 294 у IsNewUpdate присутній виклик meCom.CreateMeainThread. Код створює потік, який виконує MainAction. Цей потік буде послідовно опитувати URL запиту (
http://upd.me-doc.com.ua/last.ver?rnd=<GUID>), шукаючи команди, а потім стартує на виконання новий потік, по одному на кожну нову команду, очікуючи максимум по 10 хвилин до завершення виконання потоку. Після того він відправляє результат потоку за адресою відповіді, яка в цьому випадку збігається з адресою запиту:
http://upd.me-doc.com.ua/last.ver?rnd=<GUID>.
Функція GetCommandsAndPeriod отримує команди із веб-запиту:
Зв’язковий M.E.Doc
Під час надсилання запиту у файлах cookie будуть передані ЄДРПОУ та ім’я користувача, з яким виконується програма. З відповіді зчитуються перші 8 байт як вектор ініціалізації для шифрування. Решта даних зашифровується за допомогою TripleDes із використанням 24-символьного ключа: \x0 до \x17 (тобто символи від 0 до 23). Команди до виконання дешифруються, розпаковуються та десеріалізуються. Також отримується інформація про те, як довго потрібно чекати до наступного запитування команд (на початку при створенні об’єкта цей інтервал встановлено на 2 хвилини).
Зв’язковий M.E.Doc
SendAnswer надсилає чисельні веб-запити, максимум 2048 щоразу, результат виконання команди зберігається в cookie-файлах. Ці дані шифруються так само, як при отриманні команд, із використанням випадкового 8-байтового IV та 24-символьного ключа 0-23.
Це функції шифрування та дешифрування:
Зв’язковий M.E.Doc
Зв’язковий M.E.Doc
Зв’язковий M.E.Doc
Нарешті, об’єкт Worker (див. рядок 372 функції MainFunction) обробляє виконання команд. Усього є шість команд, які може виконувати Worker.
Команда 0 зчитує параметри та таймаут у хвилинах, а потім виконує cmd.exe із цими параметрами. Результат виконання команди повертається на веб-сервер.
Команда 1 записує дані до файлу з можливістю використання змінних середовища для прописування коректного шляху (наприклад, %SystemRoot%\filename).
Команда 2 повертає раніше отриману інформацію (дані Proxy та SMTP, у тому числі користувачі та паролі), а також інформацію про версію ОС та архітектуру, чи є користувач адміністратором, з яким рівнем токену виконується процес та чи активовано UAC.
Команда 3 читає будь-який файл із файлової системи та завантажує його на сервер.
Команда 4 подібна до команди 1 в тому, що вона записує файл до файлової системи, але також вона відразу виконує цей файл як новий процес. Коли його завершено, файл перезаписується випадковими даними, а потім видаляється.
Нарешті, команда 5, яку обробляє функція AutoPayload, подібна до команди 4, але завантажений файл запускатиметься з rundll32.exe.
Зв’язковий M.E.Doc
Що тепер?
В минулому Talos спостерігав зловмисників, які націлювались саме на українські установи, намагаючись використати вайпер BlackEnergy для знищення даних, а у випадку невдалої спроби переходили на варіант з ransomware у якості заміни. Нами також вже задокументовано, що «зважаючи на обставини цієї атаки, Talos із високою впевненістю оцінює, що наміри зловмисників, які стоять за Nyetya, є руйнівними, а не економічно вмотивованими». Нарешті, коли ми підтвердили, що вектором інсталяції був M.E.Doc, можна визначити, що цілями цієї атаки були Україна та ті організації, які ведуть тут бізнес.
Наша команда з дослідження та ліквідування загроз (Threat Intelligence and Interdiction) занепокоєна тим, що зловмисники під час атаки «спалили» значний ресурс. Вони скомпрометували як свій бекдор у програмному забезпеченні M.E.Doc, так і здатність маніпулювати конфігурацією сервера оновлень.
Загалом, зловмисники відмовилися від можливості доставляти довільний код у 80% українських компаній, які використовують M.E.Doc в якості бухгалтерського ПЗ, разом з міжнародними корпораціями, що використовували це програмне забезпечення. Це — істотна втрата оперативного потенціалу. Команда Threat Intelligence and Interdiction із поміркованою впевненістю робить висновок, що малоймовірно з їхнього боку втрачати цю можливість без впевненості в тому, що вони мають або можуть легко отримати аналогічні можливості в цільових мережах з найвищим пріоритетом для зловмисників.
Виходячи з цього, Talos радить будь-якій організації, що має зв’язки з Україною, з особливою обережністю ставитися до програмного забезпечення, подібного до M.E.Doc, та систем в Україні, оскільки вони є пріоритетними цілями для осіб, які реалізують загрози високого рівня виконання. Заходи з убезпечення містять надання їм окремої мережевої архітектури, посилену активність з моніторингу та пошуку загроз в цих системах і мережах, а також надання лише такого рівня доступу, який є абсолютно необхідним для ведення бізнесу. Патчі та оновлення мають бути пріоритетними для цих систем, і клієнтам рекомендовано перейти на Windows 10 відповідно до інструкцій від Microsoft щодо убезпечення цих систем. Додаткові вказівки щодо базової лінії безпеки мережі також доступні на сайті Cisco. Необхідно розгорнути мережеву IPS для українських філій і підключень до інших частин міжнародних організацій, також слід негайно встановити захист кінцевих точок на всіх українських системах.
