Посібник з CobaltStrike. №7 Malleable PE, Впровадження в процес та Пост-експлуатація

Malleable PE, Впровадження в процес та Пост-експлуатація

Ми розкриємо різні методи впровадження в процеси та надамо вам необхідні знання для успішного використання цієї техніки у вашій кібератакі. Крім того, наш посібник пропонує розширену інформацію про пост-експлуатацію, фазу, що настає після успішного проникнення в систему. Ви дізнаєтеся, як ефективно виконувати дії після проникнення, збирати інформацію, розширювати свій доступ та забезпечувати тривалу присутність в системі, уникнувши виявлення та блокування. Завдяки посібнику з CobaltStrike, ви отримаєте всю необхідну інформацію та навички, щоб успішно використовувати Malleable PE, впроваджуватися в процеси та проводити пост-експлуатацію в CobaltStrike. Посібник допоможе вам розширити ваші навички в галузі кібербезпеки та забезпечити успішність вашої кібератаки в цифровому світі. Отримайте доступ до посібника з CobaltStrike вже сьогодні та досягніть високих результатів у використанні Malleable PE, впровадженні в процеси та пост-експлуатації для забезпечення безпеки в цифровому просторі.

Malleable PE, Впровадження в процес та Пост-експлуатація

Огляд

Податливі профілі С2 – це більше, ніж комунікаційні показники. Податливі профілі C2 також контролюють характеристики маяка в пам’яті, визначають, як маяк вводиться в процес, і впливають на роботу Cobalt Strike після експлуатації. У наступних розділах описано ці розширення для гнучкої мови C2.

Світлодіоди PE та пам’яті

Сценічний блок у профілях Malleable C2 контролює, як маяк завантажується в пам’ять, і редагує вміст бібліотеки Beacon DLL.

stage {
set userwx "false";
set compile_time "14 Jul 2009 8:14:00";
set image_size_x86 "512000";
set image_size_x64 "512000"; set obfuscate "true";

transform-x86 {
prepend "\x90\x90";
strrep "ReflectiveLoader" "DoLegitStuff";
}

transform-x64 {
# преобразование x64 stage DLL
}

stringw "I am not Beacon";
}

Блок етапів приймає команди, які додають рядки до розділу .rdata Beacon бібліотеки DLL. Команда string додає рядок з нульовим терміналом. Команда stringw  додає широкий (закодований UTF-16LE)  рядок. Команда data  додає рядок таким, яким він є. 

Блоки  transform-x86 і transform-x64  розміщують і перетворюють відбивну DLL стадії Beacon. Ці блоки підтримують три команди: prepend, add і strrep.

  Команда prepend  вставляє рядок перед DLL “Відбиваючий маяк”. Команда додавання  додає рядок після DLL “Відбиваючий маяк”. Переконайтеся, що додані дані є правильним кодом архітектури етапу (x86, x64). Програма c2lint не забезпечує перевірку цього. Команда strrep  замінює рядок всередині DLL “Світловідбиваючий маяк”.

Блок етапів приймає кілька параметрів, які контролюють вміст бібліотеки Beacon DLL і надають підказки щодо зміни поведінки відбивного навантажувача маяка:

Параметри module_x86 та module_x64 тепер підтримують можливість задавати початкове порядкове значення для пошуку експортованої функції. Необов’язкова частина 0x## є початковим порядковим значенням, заданим цілим числом.

Якщо бібліотека встановлена і маяк не перезаписує себе в область пам’яті, то, ймовірно, бібліотека не має експортованої функції з  порядковим значенням від 1 до 15. Щоб вирішити цю задачу, визначте дійсне порядкове значення і вкажіть його за допомогою додаткового синтаксису, наприклад: setmodule_x64 “libtemp.dll+0x90”.

Клонування заголовків ПЕ

Сценічний блок має кілька параметрів, які змінюють характеристики DLL Reflective Beacon так, щоб вона виглядала як щось інше в пам’яті. Вони призначені для створення індикаторів, які підтримують аналітичні завдання та сценарії моделювання загроз.

Пакет Linux від Cobalt Strike включає інструмент peclone для вилучення заголовків з бібліотеки DLL і представляємо їх у вигляді готового до використання етапного блоку:

./peclone [/шлях/до/зразка.dll]

Ухилення і заплутування в пам’яті

Використовуйте  команду prepend блоку stage, щоб подолати аналіз, який сканує перші кілька байт сегмента пам’яті на наявність ознак вбудованої бібліотеки DLL. Якщо для пошуку агентів використовуються специфічні рядки, змініть їх за допомогою  команди strrep.

Якщо strrep недостатньо, встановіть sleep_mask  значення true. Це наказує маяку заплутати себе та свою купу в пам’яті, перш ніж заснути. Після сну Beacon деобфускує себе, щоб запитати та виконати завдання. SMB і TCP Beaons будуть заплутуватися під час очікування нового з’єднання або очікування даних з батьківського сеансу.

Вирішіть, наскільки ви хочете, щоб бібліотека DLL нагадувала себе  в пам’яті. Якщо ви хочете забезпечити легке виявлення, встановіть для параметра stomppe значення false. Якщо ви хочете легко заплутати DLL Beacon у пам’яті, встановіть для параметра stomppe  значення true. Якщо потрібно збільшити складність, встановіть  для obfuscate значення true. Цей параметр займе багато кроків, щоб заплутати ваш стаг маяка та кінцевий стан бібліотеки DLL у пам’яті.   

Одним із способів виявлення ін’єкцій пам’яті DLL є пошук чарівних байтів MZ і PE в їх передбачуваних місцях відносно один одного. Ці значення зазвичай не заплутуються, оскільки від них залежить процес відбивного завантаження. Параметр obfuscate не впливає на ці значення. Встановіть magic_pe для двох букв або байтів, які позначають початок заголовка PE. Встановити magic_mz_x86  щоб змінити ці чарівні байти в DLL x86 Beacon. Встановіть magic_mz_x64  для бібліотек DLL x64 Beacon. Інструкції, які змінюють стан процесора, супроводжуються інструкціями, які скасовують зміни. Наприклад, MZ – це легко впізнавана послідовність в заголовку, але вони також є дійсними інструкціями x86 і x64. Наступні RE (x86) та AR (x64) є дійсними інструкціями x86 та x64, які скасовують зміни MZ. Ці рекомендації змінять магічні значення в пакеті DLL Reflective Beacon і примусять процес відбивного завантаження  Використовуйте нові значення.

Встановіть  значення userwx  на false, щоб попросити завантажувач маяка не використовувати дозволи RWX. Сегменти пам’яті з цими дозволами привернуть підвищену увагу аналітиків і продуктів безпеки.

За замовчуванням завантажувач маяка виділяє пам’ять за допомогою VirtualAlloc. Використовуйте параметр allocator, щоб змінити це. Параметр HeapAlloc виділяє купу пам’яті для маяків з дозволами RWX. Розподільник MapViewOfFile виділяє пам’ять для маяка, створюючи анонімну область пам’яті відображеної області файлу в поточному процесі. Модуль тупцювання є альтернативою цим параметрам і способом змусити маяк запускатися з потрібного образу пам’яті. Встановити module_x86  для бібліотек DLL, які приблизно в два рази більше, ніж сама корисне навантаження. Завантажувач маяка x86 завантажить вказану бібліотеку DLL, знайде її розташування в пам’яті та перезапише.

Це спосіб розміщення маяка в пам’яті, який Windows пов’язує з файлом на диску. Важливо, щоб обрана вами бібліотека DLL не була потрібна додаткам, в яких ви збираєтеся розміщуватися. Варіант module_x64  – це та ж історія, але вона впливає на x64 Beacon.

Якщо вас турбує етап Beacon, який ініціалізує бібліотеку DLL Beacon у пам’яті, установіть для очищення значення true. Цей параметр звільнить пам’ять, пов’язану зі ступенем маяка, коли вона більше не потрібна.

Впровадження в процесі

Блок введення процесу в профілях Malleable C2 генерує введений вміст і контролює поведінку введення корисного навантаження Beacon. Він також контролює поведінку виконання об’єктних файлів маяка (BOF) у поточному маяку.

процес-ін'єкція {
# Налаштувати спосіб розподілу пам'яті у віддаленому процесі для вбудованого вмісту
набір розподільників "VirtualAllocEx";
# установка способу виділення пам'яті в поточному процесі для  вмісту конвертерного конвертера
набір bof_allocator «VirtualAlloc»; встановити bof_reuse_memory "true";
# Налаштування характеристик пам'яті для вбудованого вмісту та
Конвертерні конвертери
встановити min_alloc "16384"; встановити startrwx "true"; встановити userwx	"false";
# Перетворення вбудованого вмісту x86
transform-x86 {
претендувати "\x90\x90";
}
# Перетворення вбудованого вмісту x64
transform-x64 {
додати "\x90\x90";
}
# Визначте, як виконати вбудований код
виконати {
CreateThread "ntdll.dll! RtlUserThreadStart»; SetThreadContext;
RtlCreateUserThread;
}
}

Блок процес-інжекція приймає кілька параметрів, які контролюють процес введення в процес в маяк.

Блоки transform-x86 і transform-x64 містять вміст, вбудований маяком. Ці блоки підтримують дві команди: prepend і append. Команда Precedence вставляє рядок перед вбудованим вмістом. Команда add додає рядок після вбудованого вмісту. Переконайтеся, що додані дані є дійсним кодом для архітектури вбудованого вмісту (x86, x64). Програма c2lint не включає перевірку для цього.

Блок виконання  керує методами, які використовуватиме маяк, коли йому потрібно буде вставити код у процес. Маяк перевіряє кожен параметр у блоці виконання, щоб визначити, чи дійсний параметр для поточного контексту, пробує метод, якщо так, і переходить до наступного параметра, якщо виконання коду не відбулося. Параметри виконання включають:

Параметри CreateThread і CreateRemoteThread мають варіації, які очікують призупиненого потоку з адресою іншої функції, оновлюють призупинений потік для виконання вбудованого коду та відновлюють цей потік. Використовуйте “module!function+0x##”, щоб указати початкову адресу для підробки. Для віддалених процесів рекомендується використовувати тільки модулі ntdll і kernel32. Необов’язкова частина 0x## – це зміщення, додане до початкової адреси. Ці параметри працюють лише для x86 -> x86 і x64 -> x64.

Вибрані вами варіанти виконання повинні охоплювати різні побічні ситуації. Ці побічні ефекти включають самоін’єкцію, ін’єкцію в призупинені тимчасові процеси, ін’єкцію віддаленого процесу між сесіями, ін’єкцію x86->x64, x64->x86, а також ін’єкцію передавання або без аргументів. Інструмент c2lint попередить вас про контексти, які не охоплює ваш блок виконання.

Управління реалізацією процесів

Cobalt Strike 4.5 додає підтримку, яка дозволяє користувачам визначати власну техніку впровадження в процесі замість використання вбудованих методів. Це робиться за допомогою функцій підключення PROCESS_INJECT_SPAWN і PROCESS_INJECT_EXPLICIT. Cobalt Strike викличе один із цих хуків під час виконання команд після експлуатації. Таблицю підтримуваних команд див. у розділі підключень.

Два гачки охоплять більшість постпродакшн команд. Однак є деякі винятки, які не використовуватимуть ці хуки та продовжуватимуть використовувати вбудовану техніку.

Щоб реалізувати власну техніку ін’єкції, вам потрібно буде надати об’єктний файл Beacon (BOF), що містить виконуваний код для архітектур x86 та/або x64, а також файл сценарію агресора, що містить функцію перехоплення. Дивіться приклади хуків реалізації процесів у Community Kit.

Оскільки ви реалізуєте власну техніку ін’єкції, параметри ін’єкції процесу у вашому профілі Malleable C2 не використовуватимуться, якщо ваш конвертер не викличе функцію API BeaconInjectProcess або BeaconInjectTemporaryProcess. Ці функції реалізують ін’єкцію за замовчуванням і, швидше за все, не будуть використовуватися, якщо це не реалізація резервного методу за замовчуванням.

Генерація впровадження в процесі

Гачок PROCESS_INJECT_SPAWN використовується для визначення техніки реалізації в процесі fork &; run. Наступні команди Beacon, функції сценарію агресора та інтерфейси користувача, перелічені в таблиці нижче, будуть викликати гачок, і користувач може реалізувати власну техніку або використовувати вбудовану.

Зверніть увагу на наступне:

1. Команди elevate, runasadmin, &belevate,   &brunasadmin і [beacon]  -> Access -> Elevate використовуватимуть гачок PROCESS_INJECT_SPAWN лише тоді, коли вказаний експлойт використовує одну з функцій сценарію агресора, перелічених у таблиці, наприклад  &bpowerpick.

2. Для команд net та &bnet команда ‘domain’ не використовуватиме гачок.

3. Примітка “(використовувати хеш)” означає вибір облікових даних, які посилаються на хеш.

Типи робіт

 Явна реалізація в процесі

Гачок PROCESS_INJECT_EXPLICIT використовується для визначення техніки явної реалізації в процесі. Наступні команди Beacon, функції сценарію агресора та інтерфейси користувача, перелічені в таблиці нижче, викликатимуть гачок, і користувач може реалізувати власну техніку або використовувати вбудовану.

Зверніть увагу на наступне:

1. Доступ до інтерфейсу [Process Explorer] здійснюється через [beacon] -> Explore  -> Process List. Існує також багатоверсія цього інтерфейсу, доступ до якого здійснюється шляхом вибору декількох сеансів і використання одного і того ж меню інтерфейсу користувача. У провіднику процесів використовуйте кнопки для виконання додаткових команд для вибраного процесу.

2. Команди chromedump, dcsync, хешдамп, кейлоггер, logonpasswords, mimikatz, net, portscan, printscreen, pth, screenshot, screenwatch        ,  ssh  і ssh-key  . Также имеют версию fork&run. Для использования явной версии требуются аргументы pid и arch.

3. Для команд net та &bnet команда ‘domain’ не використовуватиме гачок.

Типи робіт

Післяопераційне управління

Великі функції Cobalt Strike для пост-експлуатації (наприклад, скріншот, кейлоггер, хешдамп і т.д.) реалізовані у вигляді бібліотек DLL Windows. Для виконання цих функцій Cobalt Strike породжує тимчасовий процес і вводить в нього функцію. Блок ін’єкцій процесу керує фазою реалізації процесу. Підрозділ post-ex керує змістом та поведінкою, характерними для післяопераційних функцій Cobalt Strike. У версії 4.5 ці функції після експлуатації тепер підтримують явне введення в існуючий процес при використанні аргументів [pid] і [arch].

post-ex {
# контроль тимчасового процесу, який ми породжуємо встановити spawnto_x86 "%windir%\\syswow64\\rundll32.exe"; встановити spawnto_x64 "%windir%\\sysnative\\rundll32.exe";
# зміна дозволів і вмісту наших бібліотек DLL після експлуатації
встановити заплутування "true";
# Зміна назв названих труб...
встановити ім'я труби "evil_####, stuff\\not_##_ev#l";

# передача покажчиків на ключові функції від маяка до його дочірніх завдань
встановити SmartInject "true";

# відключення AMSI в powerpick, execute-assembly і psinject
встановити amsi
{

Параметри spawnto_x86 та spawnto_x64  контролюють тимчасовий процес за замовчуванням, який Beacon генеруватиме для своїх післяопераційних функцій. Нижче наведено кілька порад щодо цих параметрів:

1. Завжди вказуйте повний шлях до програми, яку потрібно породити Маяк.

2. Змінні середовища (наприклад, %windir%) на цих шляхах допускаються.

3. Не вказуйте безпосередньо %windir%\system32 або c:\windows\system32. Завжди використовуйте syswow64 (x86) і sysnative (x64). Маяк відрегулює ці значення до system32, де це необхідно.

4. Для значення x86 spawnto необхідно вказати програму x86. Для значення x64 spawnto необхідно вказати програму x64.

5. Указані шляхи (за винятком автоматичної корекції syswow64/sysnative мають існувати як у x64 (нативному), так і в x86 (wow64) поданнях файлової системи.

Опція обфускації шифрує вміст постпродакшн DLL і поміщає ці функції в пам’ять більш безпечним способом OPSEC. Це дуже схоже на obfuscate і userwx, доступне для Beacon через сценічний блок. Деякі довготривалі бібліотеки DLL після виробництва маскують і демаскують свою таблицю рядків за потреби, коли встановлено цей параметр.

Використовуйте назву каналу, щоб змінити ім’я іменованих труб, які використовуються бібліотеками DLL для надсилання виводу назад до маяка. Цей параметр приймає список іменованих труб, розділених комами.

Cobalt Strike вибере випадково названий канал з цього параметра, коли буде встановлено завдання постпродакшену. Кожен # у назві каналу замінюється припустимим шістнадцятковим символом.

Параметр smartinject  наказує Beacon вбудовувати вказівники на ключові функції, такі як GetProcAddress та LoadLibrary, у свої бібліотеки DLL після експлуатації з однією аркою. Це дозволяє DLL після виробництва завантажувати себе в новий процес без поведінки, подібної до оболонки, яка виявляється та усувається шляхом моніторингу доступу до пам’яті PEB та kernel32.dll.

Параметр thread_hint  дозволяє багатопотоковим бібліотекам DLL постпродакшну чекати потоків із підробленою адресою запуску. Вкажіть мітку потоку як “module!function+0x##”, щоб визначити початкову адресу для спуфінгу. Необов’язкова частина 0x## – це зміщення, додане до початкової адреси.

Параметр amsi_disable  наказує powerpick, execute-assembly і psinject виправити функцію AmsiScanBuffer перед завантаженням коду .NET або PowerShell. Це обмежує видимість цих функцій AMSI (Antimalware Scan Interface).

Встановіть  параметр кейлоггера для налаштування кейлоггера Cobalt Strike. Параметр GetAsyncKeyState (за замовчуванням) використовує API GetAsyncKeyState для відстеження натискань клавіш. Параметр SetWindowsHookEx використовує SetWindowsHookEx для відстеження натискань  клавіш.

User Defined Reflective DLL Loader

Cobalt Strike версії 4.4 додає підтримку використання користувальницьких світловідбиваючих навантажувачів для Beacon. Користувальницький відбиваючий завантажувач (  UDRL) Kit – це вихідний код для демонстрації прикладу UDRL. Перейдіть в Help -> Arsenal і завантажте UDRL Kit.   Ліцензійний ключ обов’язковий.

ПРИМІТКА: Виконуваний код Reflective Loader – це витягнута секція .text з наданого користувачем скомпілюваного об’єктного файлу. Вилучений код, що виконується, повинен бути менше 100 Кб.

Реалізації

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

Наступні функції Aggressor Script призначені для вилучення виконуваного коду Reflective Loader (розділи .text) з скомпільованого об’єктного файлу та введення виконуваного коду в маяк:

Наступні функції сценарію агресора призначені для модифікації маяка використовуючи інформацію з профілю Malleable C2:

Наступна функція Aggressor Script призначена для отримання інформації про: Маяк для полегшення його модифікації:

Наступні функції скрипту агресора дозволяють виконувати користувацькі модифікації маяка:

ПРИМІТКА: Залежно від внесених користувацьких модифікацій (обфускація, маскування і т.д.), Reflective Loader’у може знадобитися скасувати ці модифікації під час завантаження.

Использование User Defined Reflective DLL Loader’ов

Створення/компіляція світловідбиваючих навантажувачів

Комплект UDRL, визначений користувачем (UDRL), є відправною точкою для демонстрації прикладу UDRL.

Зайдіть в Help -> Arsenal і завантажте UDRL Kit (потрібен ліцензійний ключ).  Далі йде процес приготування маяків:

Гачок BEACON_RDLL_SIZE називається при приготуванні маяків.

1. Це дає користувачеві можливість вказати, що його світловідбиваючий завантажувач зажадає більше 5 КБ місця.

2. Користувачі можуть використовувати маяки, які резервують місце для світловідбиваючого завантажувача розміром до 100 КБ.

3. Перекривши доступний простір відбивного навантажувача в маяках, маяки стануть набагато більшими. Насправді вони будуть занадто великими для стандартних артефактів, наданих Cobal Strike. Користувачам доведеться оновити свої процеси, щоб використовувати спеціалізовані артефакти зі збільшеним зарезервованим простором для великих маяків.

В якості даних про корисне навантаження до маяків додаються необхідні налаштування.

Наступні виправлення були внесені до маяків для UDRL:

1. Налаштування слухача.

2. Деякі параметри Malleable C2.

Використання sleepmask та userwx  вимагає світловідбиваючого завантажувача, здатного створювати пам’ять для виконуваного .text коду з дозволами RWX, інакше маяк вийде з ладу під час маскування/демаскування захищеної від запису пам’яті. Стандартні світловідбиваючі навантажувачі зазвичай виконують цю роботу.

Для використання sleepmask і obfuscate потрібен світловідбиваючий завантажувач, здатний видалити перший блок (заголовок) бібліотеки DLL розміром 4 КБ, оскільки заголовок не буде замаскований.

• Наступне НЕ виправлено в маяках для UDRL: Модифікації EP

• Зазвичай називається BEACON_RDLL_GENERATE. Гак

BEACON_RDLL_GENERATE_LOCAL спрацьовує при:

• Далі визначається, що його викликає: Податливий C2 має параметр “.stage.smartinject”.

• Використання функції extract_reflective_loader для видобування Світловідбиваючий навантажувач.

Використовуйте функцію setup_reflective_loader, щоб помістити витягнутий відбиваючий завантажувач у простір відбивного завантажувача в маяках. Якщо завантажувач занадто великий для обраного маяка, ви побачите таке повідомлення: o Reflective DLL Content length (123456) перевищує доступний простір (5120).

Використовуйте “BEACON_RDLL_SIZE” для використання маяків з більшими світловідбиваючими навантажувачами.

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

1. Гарантія заплутування

2. Обговоріть зміни, щоб підтримати розумне впровадження

Маяки перетворюються в артефакти.

1. Маяки, які були створені з більшим простором відбивного навантажувача (відповідно до параметра “BEACON_RDLL_SIZE” вище), повинні бути завантажені в спеціальні артефакти з місцем для зберігання великих маяків.

2. Перейдіть до Help -> Arsenal з ліцензійного Cobalt Strike, щоб завантажити

Набір артефактів.

Дивіться посилання на “stagesize” у цих файлах набору артефактів, наданих CobaltStrike:

1. Дивіться посилання на “stagesize” у сценарії для створення артефакту.

2. Дивіться посилання на “stagesize” у “script.example”.

Дякуємо різним посібникам, які знаходяться у різних відкритих джерелах.