Archive | 23/03/2018

IOC_vba_d0c_worm_140318

14го березня було зафіксовано масове зараження документів MS Office троянським шкідливим кодом.

Рівень загрози для організацій що використовують макроси – високий.

Для тих, хто врахував наші попередні рекомендації – низький.

Рекомендуємо ознайомитися особливо тим, у кого макроси не вимкнуті.

Чому така затримка із остаточними результатами?

Аналіз зайняв більше часу, оскільки спершу зразок не запускався як слід на різних тестових ВМ (включаючи хмарні sandbox).

Ми навіть зібрали фізичний стенд навмисне для аналізу цього зразка, але і на ньому з першого разу не отримали чітких результатів.

Та от нарешті уся інформація була зібрана і ми ділимося нею з вами. Зразок не є чимось дуже небезпечним, але його механіка нетипова і відрізняється від того, що нам надсилали на аналіз останнім часом.

Трохи аналітики:

  • Мережевих з’єднань не здійснює. Взагалі. Жодних.
  • Запуск основної частини не залежить від прав користувача та параметрів UAC
  • Збій в роботі основного тіла який ми отримали на ВМ був спричинений версією MS Office
  • З іншою (новішою) збіркою MS Office зразок без проблем працює як на фізиці та і у ВМ
  • Перевірки віртуалізації немає, це була не цільова атака
  • Призначений для запуску на Windows NT6.x, на ХР по замовчуванню відсутній каталог C:\Public (відповідно макрос не спрацьовує)
  • Регіональні параметри (локалізація, розкладки клавіатури) на виконання не впливають
  • Якщо з обмеженими правами відкривати інфікований документ -не додає себе у автозавантаження (логічно, HKLM)
  • Якщо з обмеженими правами запускати основне тіло – файли не інфікуватиме
  • Зразок модифікує лише файли старого типу, а саме MS Word 2003 (.doc), інші – не чіпає
  • Пошук файлів здійснюється за розширенням
  • Основне тіло здійснює пошук файлів по каталогу користувача (тобто і Робочий стіл І Мої документи та далі по списку)
  • Зміст документів не спотворюється, додається лише VBA код
  • Зразок вперше було помічено 2,5 роки тому (тому відкидаємо припущення про цільову атаку)
  • Механізм доставки наразі не встановлено (ймовірно інфікований документ із макросом)
  • Основне тіло записується та запускається із C:\Users\Public\ctrlpanel.exe

Результат інфікування наведено нижче.

Погляньте на тестові документи до зараження:

 

А ось ті ж самі файли вже після запуску основного тіла:

На перший погляд все нормально, проте зверніть увагу на розмір документу Test clean file2.doc У нього інжектовано VBA код.

Його відкриття запустить процес знову.

Теж саме ще раз:

На знімку екрану чітко видно збільшений розмір doc3

(98 Кб при початкових 22 Кб) – результат інжекту VBA коду.

Нижче наведений граф зв’язків інфікування чистого документу (doc2) через відкриття зараженого (infected):


Маркери IOC:

Основна частина:

SHA-256        10e720fbcf797a2f40fbaa214b3402df14b7637404e5e91d7651bd13d28a69d8
File name   ctrlpanel.exe
File size      34.5 KB

Активність по процесам:

Після відкриття інфікованого документу макрос видобуває основне тіло, записує його на диск та запускає

"C:\Program Files\Microsoft Office\Office15\WINWORD.EXE" /n /dde
c:\Users\Public\ctrlpanel.exe

Основна частина проводить закріплення через реєстр

HKLM\Software\Microsoft\Windows\CurrentVersion\Run\CtrlPanel

Далі зразок розпочинає пошук документів у каталозі користувача та інжектує код VBA знайдені документи

C:\Users\%name%\*.doc

Паралельно ініціюється запуск другого екземпляру Winword

"C:\Program Files\Microsoft Office\Office15\WINWORD.EXE" /Automation -Embedding

Знайдені *.doc файли переписуються в каталог %temp% де модифікуються другим процесом Winword, далі ctrlpanel заміняє зміст почткових документів (дописує).


Механізм інфікування (повна ланка)

Winword(1st) > open infected.doc > VBA > C:\Public\ctrlpanel.exe > query C:\Users\%name%\*.doc >

Winword(2nd)_ invoked by ctrlpanel > copy *.doc to %temp% > inject VBA > rewrite source *.doc (cycle)

 

Жертва відкриває інфікований документ.

Якщо макроси дозволені або жертва погодилася на активацію – макрос записує основне тіло у C:\Public\

Після запуску процес основного тіла намагається закріпитися через реєстр та шукає *.doc у каталозі користувача

Паралельно із пошуком процес ctrlpanel ініціює запуск другого екземпляру Winword але не як батьківський процес

Другий екземпляр winword запускається від імені svchost.exe (DCOM Server) без GUI. Ключова відмінність наявність параметрів /Automation -Embedding

Потім знайдені *.doc файли (включаючи інфікований) копіюються процесом ctrlpanel у %temp%, де модифікуються другим процесом Winword.

Після інжекту VBA коду, зміст початкових файлів перезаписується процесом ctrlpanel.

Далі іде цикл (безперервне виконання на одній із ВМ протягом 1 години і довше)


Механізм інфікування (запуск лише основного тіла)

C:\Public\ctrlpanel.exe > query C:\Users\%name%\*.doc >

Winword(2nd)_invoked by ctrlpanel > copy *.doc to %temp% > inject VBA > rewrite source *.doc (cycle)

 

Після запуску процес основного тіла намагається закріпитися через реєстр та шукає *.doc у каталозі користувача

Паралельно із пошуком процес ctrlpanel ініціює запуск другого екземпляру Winword але не як батьківський процес

Другий екземпляр winword запускається від імені svchost.exe (DCOM Server) без GUI. Ключова відмінність наявність параметрів /Automation -Embedding

Потім знайдені *.doc файли копіюються процесом ctrlpanel у %temp%, де модифікуються другим процесом Winword.

Після інжекту VBA коду, зміст початкових файлів перезаписується процесом ctrlpanel.

Далі іде цикл (безперервне виконання на одній із ВМ протягом 1 години і довше)

 


Висновки:

  1. Інфікує тільки *.doc файли у каталозі користувача
  2. Системи із ХР не інфікуються, проте можуть виступати у якості вектору
  3. Крім інжекту VBA коду в документи іншої шкоди не зафіксовано
  4. Спроб мережевих комунікацій чи модифікації параметрів ОС (крім закріплення) не зафіксовано
  5. Це не цільова атака, враховуючи давність зразка швидше за все хтось відкопав старий інфікований документ

Контрзаходи:

  • В черговий раз звертаємо увагу на макроси. Вимикайте їх якщо вони не є критичним для штатного режиму роботи.
  • Блокування створення та запуску нових .exe файлів за шляхом C:\Users\**\*.exe (користувацьке правило Access Protection)
  • Заборона створення усіх дочірніх процесів для додатків MS Office крім виключень (користувацьке правило Access Protection)
  • Заборона запуску winword від імені svchost (користувацьке правило Access Protection)
  • Заборона реєстрації в переліку автозавантажень (вбудоване правило Access Protection)
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

У зв’язку із даним інцидентом ще раз звертаємо вашу увагу на покрокову інструкцію по ENS (користувачі VSE можуть налаштувати Access Protection по аналогії).

Не чекайте сигнатур. Перевірте, чи вжили ви усіх пересторог аби макроси не наробили вам біди?

Будьте уважні та обережні.

VR