Archive | IOC RSS for this section

IOC_Gamaredon_181119

From Russia, with Love документами із піратським офісом*

Типовий день дослідника malware, поспішиш – закриють С2

Панове, бажаю здоров’я.

Вчора було зафіксовано розсилку шкідливих документів від угрупування Gamaredon APT, яке пов’язують з РФ.
Рівень загрози – високий.
Нагадую, що Gamaredon APT – команда, що спеціалізується на розповсюдженні імплантів в системах Українських організацій.

Схема:
————–
email attach .zip > .docx > xml.rels > GET .dot > macro > DROP vbs > WSH > 3d stage ..

Давайте розглянемо детально, які засоби застосовують проти нас люди з Gamaredon:

#1 Зміст документу-приманки

Підбирається під конкретну ціль. Ось кілька прикладів за осінь 2019го: (збільшене зображення по кліку)

Інформпривід або створюється штучно із залученням реальних прізвищ/посад , або ж за основу беруть документи з відкритого доступу. По рівню згенерованого контенту вони конкурують та значно випереджають те, що ми вже бачили у розсилках Sobaken.

#2 Перший файл – приманка

Конкретний зразок із розсилки за 18/11/19 є автоматично згенерованим на базі шаблону (час редагування – 2хв, дата збереження навмисно спотворена 1980й). *Також можна помітити, що пакет MS Office, в якому формували дану приманку зареєстрований на псевдо компанію “Reanimator Extreme Edition“, що є маркером піратської копії:

Документ містить вразливість CVE-2017-0199, у одному з його xml файлів вставили посилання на зовнішнє джерело:

Вразлива версія MS Office без виправлень при відкритті такого файлу одразу спробує завантажити файл за вказаним посиланням. Зауважте, що процес MS Word перед завантаженням перевіряє доступність файлу запитами із специфічним User Agent:

#3 Другий файл – dropper

Файл, який завантажується при обробці xml.rels, створений тим же “автором” у тому ж піратському офісі:

Цей файл містить макрос:

Завдання макросу – згенерувати VBS файл із унікальним посиланням для зв’язку з С2:

та забезпечує його закріплення в системі через каталог Startup:

Важливо – вони не використовують 11882, powershell чи закріплення через реєстр, бо ці трюки вже більшість ІТ\ІБ блокують або відстежують. Натомість Gamaredon намагається застосовувати старіші техніки, аби лишатися у тіні.

#4 Скрипт закріплення – downloader

VBS скрипт, який було згенеровано макросом із другого файлу відповідає за комунікацію із розгалуженою системою С2. Особливість у тому, що для з’єднання макрос на кожній системі генерує пару “Hostname+ID” і додає її у URL:

С2 використовують домени із зони ddns.net, ось частковий перелік “засвічених”:

unhcr.ddns.net
rnbo-ua.ddns.net
network-crash.ddns.net
checkhurl.site
get-icons.ddns.net
bitvers.ddns.net
shell-sertificates.ddns.net
bitread.ddns.net
sv-menedgment.ddns.net
lookups.ddns.net
libresoft.ddns.net
document-write.ddns.net
suipost.ddns.net
document-listing.ddns.net
list-sert.ddns.net
military-ua.ddns.net
const-gov.ddns.net
my-certificates.ddns.net
checkhurl.fun
libre-boot.ddns.net
kristo-ua.ddns.net
templates.hopto.org
checkhurl.website
constructor-word.ddns.net
creative-office.ddns.net
kornet-ua.ddns.net
duktas-dde.ddns.net
message-office.ddns.net
unhcr.ddns.net
shell-sertificates.ddns.net
network-crash.ddns.net
message-office.ddns.net
list-sert.ddns.net
libresoft.ddns.net
kristo-ua.ddns.net
kornet-ua.ddns.net
bitread.ddns.net
micro-office.ddns.net
get-icons.ddns.net
checkhurl.space
checkhurl.info
checkhurl.fun
checkhurl.site
underlord.site
underlord.fun
bitvers.ddns.net
sv-menedgment.ddns.net
lookups.ddns.net
document-write.ddns.net
suipost.ddns.net
document-listing.ddns.net
military-ua.ddns.net
rnbo-ua.ddns.net
const-gov.ddns.net
my-certificates.ddns.net
libre-boot.ddns.net
underlord.space
templates.hopto.org
checkhurl.website
constructor-word.ddns.net
creative-office.ddns.net
duktas-dde.ddns.net

#5 Імплант

С2 віддає імплант лише короткий проміжок часу та перевіряє параметри систем які звертаються до нього. Через це мені так і не вдалося отримати сам файл імпланту. На що це може бути схожим варто подивитися у дописі дослідника Vitali KremezDeeper Dive into Gamaredon Group Pteranodon Implant Version ‘_512’

Доречним буде скористатися YARA правилом:

rule apt_win32_gamaredon_pteranodon_initial_sfx {
   meta:
      author = "@VK_Intel"
      reference = "Detects Gamaredon Group Pteranodon Implant"
      date = "2018-12-27"
      type = "experimental"
   strings:
      $s0 = "cryptcp.exe" fullword wide
      $s1 = "SFX module - Copyright (c) 2005-2012 Oleg Scherbakov" fullword ascii
      $s2 = "7-Zip archiver - Copyright (c) 1999-2011 Igor Pavlov" fullword ascii
      $s3 = "RunProgram=\"hidcon" fullword ascii
      $s4 = "7-Zip - Copyright (c) 1999-2011 " fullword ascii
      $s5 = "sfxelevation" fullword wide
      $s6 = "Error in command line:" fullword ascii
      $s7 = "%X - %03X - %03X - %03X - %03X" fullword wide
      $s8 = "- Copyright (c) 2005-2012 " fullword ascii
      $s9 = "Supported methods and filters, build options:" fullword ascii
      $s10 = "Could not overwrite file \"%s\"." fullword ascii
      $s11 = "7-Zip: Internal error, code 0x%08X." fullword ascii
      $s12 = "@ (%d%s)" fullword wide
      $s13 = "SfxVarCmdLine0" fullword wide
      $s14 = "SfxVarCmdLine1" fullword wide
      $s15 = "SfxVarCmdLine2" fullword wide
      $cmd = ".cmd" fullword wide
condition: ( uint16(0) == 0x5a4d and filesize < 2000KB and 14 of them and $cmd) }

позичено у @VK_Intel

Аналітика:
————–

  • Зауважте, що 4 спроби аналізу не дали 3го кроку – саме тіло імпланту так і не було отримано
  • Те, що ви бачите о звіті – це лише перші 2 кроки інфікування
  • Доставка – через документи-приманки із вразливістю CVE-2017-0199 з подальшим довантаженням документу з макросом (AutoOpen)
  • Макрос виконує одну задачу – формує VBS файл з інструкціями (Downloader) та забезпечує його закріплення через каталог Startup
  • Зверніть прискіпливу увагу на мережеві маркери – за цими двома IP тягнеться шлейф різних доменів (різні профілі жертв)
  • Проблеми будуть утих, хто не оновлює MS Office та не контролює WSH (wscript.exe)
  • VBS формує унікальний URL для кожної інфікованої системи (ім’я + ідентифікатор)

Мережеві маркери:
————–
141.8.195.60 win-apu.ddns{.} net GET /apu.dot UA = Mozilla/4.0
2.59.41.5 get-icons.ddns{.} net GET /Host_ID//autoindex.php UA = Mozilla/4.0

Звіт:
————–
https://pastebin.com/Vhb4KF5L

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

  • Блок двох IP адрес, наданих вище та контроль спроб resolve сайтів з зони ddns.net
  • Оновлення MS Office, виправлення вразливості CVE-2017-0199 (патчі за 2017-й рік!)
  • Деактивація Windows Script Host або блок запуску ?script.exe або блок мережевого трафіку для ?script.exe (див. стаття#1 та стаття#2)
  • Заборона запуску макросів там, де вони не потрібні
  • Повне блокування доступу до Інтернет для MS Word, Excel та PowerPoint
  • Або ж блокування на Proxy специфічних User Agent MS Office Web-Dav
  • Контроль списку автозавантаження
  • Користувачі McAfee VSE/ENS у безпеці (GTI)

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

VR

Блок виклику WMI через OLE/Macros

“Нет на свете ничего такого, чего нельзя было бы исправить.”

Брати Стругацькі, “Пикник на обочине”

На мою думку, серед методів доставки malware, зараз основну і найбільшу небезпеку становлять … документи.
Погодьтеся, що і скрипти і примітивні SCR(EXE) можна заблокувати (майже) без суттєвих наслідків для бізнесу.
А от із документами біда.

Сьогодні я покажу вам як захиститися від документів, що викликають WMI.
Вперше такий спосіб доставки мені трапився 15/05/19 при аналізі #emotet.

Отже з чим ми маємо справу (свіжий документ за 27/09/19, знов #emotet):

В чому небезпека виклику WMI?

Стандартно запуск ланки інфікування такий:
winword/excel > macro > (cmd) > wscript/powershell
В даному випадку для захисту достатньо заборонити додаткам MS Office запускати дочірні процеси.

Ланка інфікування з WMI:
winword/execel > macro || (інший контекст) wmiprvse.exe > powershell > …
В цьому випадку заборона дочірніх процесів не спрацює.

Схожа схема із вразливістю редактору формул (11882). Але, якщо у випадку із 11882 нам достатньо просто заблокувати запуск eqnedt32.exe, то заборонити запуск сервісів WMI у корпоративному середовищі – не вихід.

Що ми можемо зробити, маючи на руках базовий ENS Threat Prevention без моїх User-defined правил AP?

Три простих, вбудованих(!) механізми, які по замовчуванню не активні:

1. EP – Enable Windows Data Execution Prevention
2. EP – сигнатура 6131 “Weaponized OLE object infection via WMI”
3. EP – сигнатура 6087 “Powershell Command Restriction – EncodedCommand”

Давайте перевіримо результат:

Активуємо EP – Enable Windows Data Execution Prevention і відкриваємо документ:

При спробі запустити макрос процес winword зупиняється з помилкою. Інфікування не пройшло:

Активуємо EP – 6131 “Weaponized OLE object infection via WMI” (DEP деактивовано для демонстрації) і відкриваємо документ:

Макрос відпрацьовує, але як тільки доходить до виклику WMI – він блокується. Інфікування не пройшло:

Активуємо EP – 6087 “Powershell Command Restriction – EncodedCommand” (DEP та 6131 деактивовано для демонстрації) і відкриваємо документ:

Макрос відпрацьовує, виклик WMI проходить, але виконання base64 на PowerShell блокується. Інфікування не пройшло:

Все. Результат досягнуто.

Ми не вимикали макроси повністю. Ми не блокували запуск WMI чи PowerShell повністю.

Ми просто активували три механізми захисту від нетипових макросів, WMI та PowerShell.

Сподіваюсь даний “рецепт” стане у нагоді та вбереже читачів від інцидентів із malware.

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

VR

Ліки від скриптів

“выигрывает вовсе не тот, кто умеет играть по всем правилам;
выигрывает тот, кто умеет отказаться в нужный момент от всех правил,
навязать игре свои правила, не известные противнику,
а когда понадобится — отказаться и от них..”
Брати Стругацькі, “Град обречённый”

* WSH – клас методів доставки malware, що використовує функціонал Windows Script Host (cscript/wscript)

Скрипти в якості засобу доставки шкідливого коду почали використовувати не вчора і навіть не рік тому (я почав відстежувати WSH ще у 2015му). Не дивлячись на наявність наведених способів боротьби із скриптами, я періодично отримую інформацію про інциденти з ransomware на різних українських підприємствах.

Останнього разу жертвами #troldesh #shade стала велика організація.
Кампанія з темою розсилки “о заказе” триває вже майже рік…
Коли я поцікавився чому не було вжито контрзаходів проти WSH, виявилося що “оце не можемо, а оце не хочемо, а про це не знаємо..”

Я вважаю, що у 19му році втрачати дані і час від Ransomware який зайшов через WSH – це нонсенс.
Нагадаю іще раз з чим ми маємо справу:

Це третя зміна тактики. Спершу були архіви у приєднанні. Потім архіви за посиланням. Тепер додали проміжний PDF.

Схема атаки: email attach .PDF > URL > .ZIP > .JS > GET .EXE > encrypt

Отже якщо з певних причин ви не можете, або не хочете повністю вимкнути WSH або хоча би заблокувати мережевий трафік для wscript/cscript чи посилити фільтрацію Web та Email, ось вам ще один спосіб:

Нам потрібно зробити так, аби жертва (користувач) не змогла клікнути і запустити скрипт на виконання. Скрипт жертва може отримати через пошту (приєднання) або ж через Web (посилання на архів).

Я буду це робити через Access Protection у McAfee ENS.

Спершу потрібно обрати єдиний архіватор для усіх систем. Приклад правила буде із використанням 7zip, але це можна модифікувати під інший додаток.

Єдиний архіватор потрібен для того аби присвоїти йому і тільки йому відкриття/розпаковку архівів різного типу (ZIP, RAR, LZH, 7Z etc):

Якщо ви користуєтеся McAfee VSE/ENS або просто уважно поставилися до моїх порад, тоді при зміні реєстрації типів файлів ви можете отримати помилку (як отримав я, коли готував цей матеріал):

Нічого страшного – нам просто потрібно _тимчасово_ вимкнути вбудоване правило Access protection:

І застосувати прив’язку розширень для усіх користувачів іще раз:

А тепер потрібно створити нове правило Access Protection, яке буде блокувати спробу архіватора записати на диск скриптові типи файлів:

Action: Block + Report

Executables: 

**\7z.exe
**\7zFM.exe
**\7zG.exe

User Names: (не вказуємо конкретні, усі)

subrules > type: File

Operations: Create

Targets:

**\Users\**\*.js
**\Users\**\*.jse
**\Users\**\*.vb
**\Users\**\*.vbs
**\Users\**\*.vbe
**\Users\**\*.ws
**\Users\**\*.wsf
**\Users\**\*.exe

Правило враховує роботу із 7zip, але замість нього можна взяти інший додаток.

Формуємо перелік типів файлів, які заборонено писати на диск процесам архіватора.

Я обрав основні типи WSH, але за бажанням список можна розширити.

Правило створене і активоване. Давайте застосуємо і перевіримо його:

Три архіви: документи, скрипти і запускний файл. Почнемо:

Документи розпаковуються без зауважень. А що буде із скриптами?

Скрипти блокуються згідно логіки правила. А що буде із ЕХЕшником ?

Запис ЕХЕ на диск блокований. Все. Результат досягнуто.

Ми не вимикали WSH. Ми не блокували запуск wscript/cscript.

Ми заборонили архіватору писати (видобувати) на диск скриптові файли.

Сподіваюсь даний спосіб стане у нагоді і вбереже читачів від інцидентів із malware.

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

VR

IOC_digest_05_2019

(Зразки за травень 2019го)

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

Наразі із публічних та реально шкідливих усього три (3) зразки, проте два із них – цікаві.

03/05/19

розсилали #coinminer (#bmcon),  .RAR > SCR > C:\Intel\*   , звіт

*схема 1:1 схожа із попереднім випадком, тому окремого звіту не робив

 

07/05/19

розсилали #formbook,  .doc (RTF) > 11882 > msiexec GET msi > install , звіт

 

15/05/19

розсилали #emotet,  .doc > macro > WMI > powershell -enc > GET 5 URL > \Users\%name%\206.exe > \Users\%name%\AppData\Local\?\?.exe , звіт

– – – – – – – – – – – – – – – – – – – – – – –

Аналітика

Методи доставки

Якщо розбити по категоріям, тоді отримаємо

Для обходу фільтрів були застосовані наступні кроки:

  • обфускація команд PowerShell (1) + документи з макросами (1)
  • (!) конвертування exe (payload) у MSI

Тенденції

  • Низькопробні розсилки із примітивним EXE/SCR не збавляють обертів
  • Вразливість 11882 уже 2 рік продовжує домінувати серед приманок-офісних документів
  • Там, де заборонено завантажувати .EXE намагаються пройти через .MSI
  • Base64 + Powershell залишається своєрідним еталоном доставки

Цікавими з технічної точки зору виявилися 2 зразки:

  • #formbook, доставку якого загорнули у RTF із 11882, але в кінці був не .EXE, а MSI (!)
  • #emotet, який передавав Base64 на PowerShell через WMI (!)

Трюк з MSI дозволив зловмисникам обійти фільтри і запустити інсталяцію – потрібно зробити висновки.

Кодовані команди на PowerShell уже давно не новина, проте використання WMI може порушити логіку блокувань – потрібно зробити висновки.

– – – – – – – – – – – – – – – – – – – – – – –

Загалом, усе, що присилали в травні могло створити інциденти тим організаціям які:

  • не оновлюють MS Office та ОС
  • не блокують запуск макросів
  • не відмовилися від RTF
  • не заборонили виклик PowerShell та інших вбудованих механізмів ОС (mshta, cmd etc)
  • не контролюють GET запити на Proxy по User Agent
  • не блокують завантаження EXE та MSI у явному вигляді

Узагальнені контрзаходи

  • встановлення виправлень MS Office
  • посилена фільтрація вмісту приєднань – як по типу так і по розширенню
  • заборона запуску cmd, powershell та ?script для рядових користувачів
  • блокування web запитів з пустим або застарілим полем User Agent

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

VR

malware#2

Невивчені уроки або логи антивірусних війн #2

(першу частину можна почитати тут)

22/02/19 доповідав про наші досягнення у розрізі аналізу malware та методів доставки.

Контент суто технічний. Без прив’язки до конкретних вендорів чи рішень.

Презентацію можна переглянути/взяти тут

Основні тези:

  • зміни по кількості та якості атак
  • актуальні методи інфільтрації систем захисту
  • приклади атак трьох різних рівнів
  • висновки

На прикладі #shade, #emotet та #sobaken пояснив можливі контрзаходи.

Кому зі slideshare не зручно – беріть у вигляді PDF (~1,1 Mb)

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

VR

IOC_digest_04_2019

(Зразки за квітень 2019го)

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

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

08/04/19

розсилали #AZORult, .ZIP > .LNK > GET .HTA > PowerShell > GET .GIF(EXE) > %Public%\???.exe > %AppData%\0mbii\gsir.exe , звіт

11/04/19

розсилали #revengeRAT, .xlam / .doc > mshta GET pastebin1 > powershell > GET pastebin2 (base64) > run decoded exe in memory(!) , звіт

22/04/19

розсилали #formbook, attach .RAR > .EXE  , звіт

25/04/19

розсилали #nanocore, attach .doc (RTF) > OLE > 2 excel > macro_URLDownloadToFileA > GET 1 URL > .exe , звіт

– – – – – – – – – – – – – – – – – – – – – – –

Аналітика

Методи доставки

Якщо розбити по категоріям, тоді отримаємо

  • exe/scr (без приманки) – 1 розсилка
  • RTF (OLE) – 2 розсилки
  • макроси – 2 розсилки
  • powershell2 розсилки

Схоже, що документи із вразливістю 11882 та скрипти WSH втрачають позиції. Або просто на них вже не звертають уваги.

Для обходу фільтрів були застосовані наступні кроки:

  • обфускація команд PowerShell (2);
  • Документи з макросами (1) та документи з OLE (1)

Тенденції

  • PowerShell залишається одним із основних інструментів доставки та виконання payload
  • Доставку та трафіку зі С2 все частіше переводять на HTTPS або ж кодують через B64/XOR
  • Крім 1 зразка, усі інші, залишають сліди через закріплення в реєстрі ОС
  • Посилюється роль додатків MS Office в завантаженні payload

Цікавими з технічної точки зору за березень виявилися два випадки:

  • #revenge #RAT за 11/04 – powershell декодував payload і виконував його в своєму контексті
  • #nanocore #RAT за 25/04 – приманка була подвійною, у RTF файлі через OLE були дві таблиці Excel із макросами

Загалом, усе, що присилали в березні могло створити інциденти тим організаціям які:

  • не оновлюють MS Office та ОС
  • не блокують запуск макросів
  • не відмовилися від RTF
  • не заборонили виклик PowerShell та інших вбудованих механізмів ОС (mshta, cmd etc)
  • не контролюють GET запити на Proxy по User Agent

Узагальнені контрзаходи

  • встановлення виправлень MS Office
  • посилена фільтрація вмісту приєднань – як по типу так і по розширенню
  • заборона запуску cmd, powershell та ?script для рядових користувачів
  • блокування web запитів з пустим або застарілим полем User Agent

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

VR

RevengeRAT або пацюк від Gorgon Group

“Я, видите ли, давно уже отвык рассуждать о человечестве в целом.

Человечество в целом слишком стационарная система, ее ничем не проймешь.”

(c) Валентин Пильман, “Пикник на обочине”

Усім доброго дня.

Продовжуємо розбирати цікаві, нетипові методи зараження.

Цього разу нашим піддослідним буде #RevengeRAT

#1 Метод доставки

З першого погляду цей лист було дуже легко сплутати з масовим фішингом який мав принести типовий #LokiBot, #Trickbot або ж #ursnif

  • підпис відсутній
  • два приєднання, одне з яких .xlam (!)
  • домен відправника не викликає довіри

 

#2 Інфікування

Якщо поштові фільтри не спрацювали належним чином і жертва, не дивлячись на ознаки обману, відкриє будь-яке із приєднань, відбувається виклик службової утиліти mshta, яка призведе до завантаження першої частини інструкцій. Цього разу код розмістили на відомому сервісі pastebin. Обфускація мінімальна:

Як можна помітити  з коду, нападники розраховували заразити системи з антивірусом Avast і сподівалися на те, що приманку запустить користувач з привілеями адміністратора. Поки усе начебто стандартно, але зверніть увагу на виклик PowerShell:

forfiles /c “”cmd /c powershell -noexit [ReFlEcTiOn.AsSeMbLy]::LoAd([CoNvErT]::FrOmBaSe64StRiNg…

Таак, а це вже цікаво. По-перше, знову декодування із Base64 за другим посиланням (теж на pastebin):

Але важливіше інше – ключ -noexit. Значить декодувати зібралися не інструкції для PowerShell а саме тіло основної частини.

Що це їм дає? Обробка першої частини інструкцій спричиняє запуск Powershell, а далі…

На відміну від попередніх прикладів, цього разу дочірнього процесу не з’являється:

Ще раз – за другим посиланням powershell забирає та декодує тіло основної частини.

Але не пише її на диск і продовжує виконувати її у своєму контексті.

Збоку це виглядає як проведення усіх операцій від імені довіреного системного процесу powershell:

Зауважте також елегантне закріплення – через довірений системний mshta із посиланням не на файлову систему (як ми уже звикли)а на друге посилання.

Тобто, при перезавантажені ОС основне тіло буде щоразу збиратися знову з “0”.

Це дозволяє досягти одразу 2х цілей:

  • захист від очистки файлової системи
  • оперативна заміна функціоналу шляхом заміни коду за посиланням

 

#3 Комунікація із С2

Кодована і відбувається по не шифрованому каналу:

 

#4 Висновки

Повний звіт із маркерами по даному зразку тут https://pastebin.com/JKMHyvgx

Отже, якщо не брати до уваги досить явні приманки (xlam та RTF) і не враховувати явних спроб зупинити процеси Avast і Windows Defender, то слід виділити наступні речі:

  • використання pastebin для хостингу інструкцій та payload
  • доставка через два документи (макрос та RTF з OLE) з передачею команд на mshta та powershell
  • mshta > powershell але без запуску окремого процесу для payload
  • закріплення не через файлову систему, довантаження з мережі
  • інфікування проходить з правами звичайного користувача

Проблеми будуть у тих, хто:
– Не контролює запуск mshta та powershell від імені користувача
– Не блокує макроси та не оновлює пакет MS Office

 

– – –  // Бонусний контент для уважних та допитливих

Практичні контрзаходи по цьому зразку (в порядку протікання зараження):

  1. Посилена фільтрація приєднань як за типом так і за розширенням (xlam, dotm і таке інше)
  2. Використання sandbox
  3. Навчання користувачів протидії фішингу
  4. Заборона активації макросів
  5. Оновлення пакету MS Office та ОС
  6. Відмова від RTF як застарілого та небезпечного формату
  7. Контроль/заборона виклику mshta
  8. Контроль/заборона виклику Powershell
  9. Блокування мережевого трафіку для Powershell
  10. Контроль/заборона GET запитів із нетиповим/пустим полем User Agent на рівні Web Proxy
  11. Контроль за зміною параметрів автозавантаження додатків (реєстр, задачі, служби)

– – –  // Бонусний контент для уважних та допитливих

 

Ось і все. До наступного зразка.

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

VR