Обход Windows Defender (10 способов)

Регистрация
09.01.23
Сообщения
4
Реакции
8
Баллы
3
Обход Защитника Windows (10 способов)

Введение

В этой статье я расскажу о 10 способах/техниках обхода полностью обновленной системы Windows с актуальными данными Windows Defender с целью выполнения произвольного кода (кроме разрешений/ACL).



Для тестирования использовалась следующая конфигурация:

  • AWS EC2 с Ubuntu Linux AMI в качестве атакующего C2-сервера.
  • AWS EC2 с Windows Server 2019 AMI в качестве машины жертвы.
  • Локальная машина Windows 10 с Visual Studio 2022 Community для разработки/компиляции вредоносного ПО.
  • Локальная машина Kali Linux для атаки.
Обратите внимание, что я не буду слишком углубляться во многие концепции и в основном буду исходить из базовых знаний. Кроме того, я не стал выбирать слишком сложные техники, например, прямые вызовы системы (direct syscalls) или аппаратные точки останова (hardware breakpoints), поскольку это чрезмерно для антивирусов, и в любом случае их лучше описать в отдельной статье, посвященной EDR.



Отказ от ответственности: Информация, представленная в этой статье, предназначена исключительно для образовательных и этических целей. Описанные техники и инструменты предназначены для законного и ответственного использования с явного согласия владельца целевой системы. Любое несанкционированное или злонамеренное использование этих техник и инструментов строго запрещено и может привести к юридическим последствиям. Я не несу ответственности за любой ущерб или юридические проблемы, которые могут возникнуть в результате неправильного использования предоставленной информации.



1. In-Memory AMSI/ETW patching



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



AMSI, или AntiMalware Scan Interface, - это независимый от производителя элемент управления безопасностью Windows, который сканирует PowerShell, wscript, cscript, макросы Office и т.д. и отправляет телеметрию поставщику безопасности (в нашем случае Defender), чтобы тот решил, является ли она вредоносной или нет.



ETW, или Event Tracing for Windows, - это еще один механизм безопасности, который регистрирует события, происходящие в пользовательском режиме и драйверах ядра. Поставщики могут анализировать эту информацию, полученную от процесса, чтобы решить, имеет ли он вредоносные намерения или нет.



К сожалению, Windows Defender работает с очень малым количеством телеметрии, поступающей от сеансов PowerShell. В частности, исправление AMSI для текущего процесса позволит нам выполнять любые вредоносные программы без файлов, включая инструменты (Mimikatz, Rubeus и т.д.) и ревер-шеллы.



Для доказательства концепции я буду использовать встроенную функцию evil-winrm Bypass-4MSI, но очень легко создать собственный патчер AMSI/ETW в виде сценария PowerShell или исполняемого файла, как мы увидим позже.



Таким образом, цепочка kill для дампа In-Memory logons с Mimikatz из процесса LSASS работает следующим образом:



In-Memory AMSI Patching PoC

e6dfa1329d7d940d1128c.png

Для лучшего понимания набор команд может быть объяснен на более высоком уровне следующим образом:

  • Попробуйте написать известный триггер "Invoke-Mimikatz" как способ проверить, активен ли Defender.
  • Выполните функцию evil-winrm Bypass-4MSI для исправления AMSI в текущем сеансе PowerShell.
  • Снова вызовите триггер AV, чтобы проверить, работает ли телеметрия AMSI (как мы видим, уже нет).
  • Загрузите реальный модуль Invoke-Mimikatz PowerShell в память с помощью Invoke-Expression.
  • Выполните Mimikatz для дампа паролей входа в систему из LSASS.
Обратите внимание, что выполнение Mimikatz было просто в демонстрационных целях, но вы можете делать практически все, что хотите из терминала PowerShell без телеметрии AMSI.



2. Обфускация кода



Обфускация кода обычно не нужна или не стоит тратить на нее время для изначально компилируемых языков, таких как C/C++, поскольку компилятор в любом случае будет применять множество оптимизаций. Но большая часть вредоносных программ и инструментов написана на C# и, иногда, Java. Эти языки компилируются в байткод/MSIL/CIL, который легко поддается реверс-инженерии. Это означает, что вам придется применить некоторую обфускацию кода, чтобы избежать обнаружения сигнатур.



Существует множество обфускаторов с открытым исходным кодом, но я буду основывать доказательство концепции этого раздела на инструменте обфускатора InvisibilityCloak C# от h4wkst3r.



Например, используя инструмент GhostPack's Certify, который обычно используется для поиска уязвимых сертификатов в домене, мы можем использовать вышеупомянутый инструмент для обхода защитника следующим образом.



Убедитесь, что Defender запущен и блокирует сборку Certify по умолчанию

fcfec81eb5eeef87c8955.png

Обфускация кода Certify с помощью InvisibilityCloak

594fa2b29dcf32b04e4c6.png


Попытайтесь запустить обфусцированный Certify

1a94f7909c90c1f4227e5.png


Мы видим, что теперь все работает без проблем, однако выдает ошибку, поскольку виртуальная машина не подключена к домену или не является контроллером домена.



Мы можем сделать вывод, что все получилось, однако, обратите внимание, что некоторые инструменты могут нуждаться в более глубокой обфускации, чем другие. Например, в данном случае я выбрал Certify вместо Rubeus, поскольку это было проще для простых демонстрационных целей.



3. Обфускация во время компиляции



Для изначально компилируемых языков, таких как C, C++, Rust и т.д., вы можете использовать обфускацию во время компиляции, чтобы скрыть реальное поведение подпрограмм и общий поток инструкций.



В зависимости от языка, могут существовать различные методы. Поскольку для разработки вредоносных программ я использую C++, я расскажу о двух из них, которые я пробовал: обфускация LLVM и метапрограммирование шаблонов.



Для обфускации LLVM самым большим публичным инструментом в настоящее время является Obfuscator-LLVM. Этот проект представляет собой форк LLVM, который добавляет уровень безопасности через обфускацию к создаваемым двоичным файлам. В настоящее время реализованы следующие дополнительные возможности:

  • Подмена инструкций. Обфускация инструкций ассемблера для получения эквивалентного поведения при большей вычислительной сложности.
  • Поддельный поток управления. Добавление нежелательных блоков инструкций для скрытия оригинального потока кода инструкций.
  • Сглаживание потока управления. Делает ветвления и переходы более трудно предсказуемыми для того, чтобы скрыть намеренный поток инструкций.
В заключение можно сказать, что инструмент генерирует двоичные файлы, которые в целом гораздо труднее поддаются статическому анализу человеком/антивирусами/EDRs.



С другой стороны, метапрограммирование шаблонов - это техника C++, которая позволяет разработчикам создавать шаблоны, генерирующие исходный код во время компиляции. Это дает возможность генерировать различные двоичные файлы при каждой компиляции, создавать бесконечное количество ветвей и блоков кода и т.д.



Два общедоступных фреймворка, которые я знаю и использовал для этой цели, следующие:



Для данного PoC я буду использовать второй, так как считаю его более простым в использовании.



Более того, для PoC я буду использовать AMSI_patch от TheD1rkMtr в качестве двоичного файла по умолчанию для обфускации, так как это довольно простой проект на C++. Код обфусцированного двоичного файла можно найти здесь.



Сначала давайте посмотрим на базовое дерево бинарных функций под Ghidra.



Дерево двоичных функций по умолчанию

9779d2de2a2734d62b04b.png

Как мы видим, его не так уж сложно проанализировать. И вы можете найти главную функцию под 3-й рутиной FUN_.



Главная функция бинарной функции по умолчанию

f8bba9e48e3d1a987e03a.png


Которая выглядит довольно простой для анализа и понимания ее поведения (патч AMSI через AMSIOpenSession в данном случае).



Теперь давайте посмотрим на обфусцированное дерево бинарных функций.



Обфусцированное дерево бинарных функций

0c6bdfca2c68e1972ef9c.png

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



Обфусцированная бинарная функция мусора

ff93fba9036467706e384.png

Это простые junk-функции, но очень полезные для сокрытия реального поведения.



Теперь для финального теста давайте попробуем это на реальной системе Windows для PoC. Обратите внимание, поскольку двоичный файл исправляет AMSI для данного процесса через PID в качестве параметра, PoC будет очень похож на первый метод; исправление AMSI для текущего сеанса PowerShell, чтобы обойти сканирование Defender в памяти.



Обфускация во время компиляции PoC

81162bfdc16559f2828ab.png


И, как мы видим, это сработало, Defender не остановил бинарник ни статически, ни во время выполнения, что позволяет нам удаленно исправлять AMSI для процесса.



4. Обфускация/упаковка бинарных файлов



Когда вы уже сгенерировали двоичный файл, ваши опции, в основном, сводятся к следующему:

  • Обфускация ассемблерных инструкций двоичного файла.
  • Упаковка двоичного файла(-ов).
  • Шифрование содержимого двоичного файла для его расшифровки во время выполнения.
  • Как вариант, преобразование в шеллкод для последующей манипуляции и инъекции.
Начиная с первого, у нас есть несколько вариантов с открытым исходным кодом, включая, например:



На высоком уровне, Alcatraz работает путем изменения сборки двоичного файла несколькими способами, такими как обфускация потока управления, добавление нежелательных инструкций, неоптимизация инструкций и скрытие реальной точки входа до выполнения.



С другой стороны, Metame работает, используя случайность для генерации различных сборок (хотя всегда с эквивалентным поведением) при каждом запуске. Это более известно как метаморфический код и часто используется в настоящих вредоносных программах.



Наконец, ROPfuscator работает, как видно из названия, используя программирование, ориентированное на возврат, для создания ROP-гаджетов и цепочек из исходного кода, таким образом скрывая исходный поток кода от статического анализа и, возможно, даже динамического, поскольку эвристикам будет сложнее анализировать последовательные вредоносные вызовы. Следующее изображение лучше описывает весь процесс.



Архитектура ROPfuscator

87912a1cf9104cd8b9472.png


Источник: ropfuscator/architecture.svg at master · ropfuscator/ropfuscator



Продолжая тему бинарной упаковки, базовая архитектура упаковщика может быть описана следующим изображением.



Архитектура упаковщика PE

72c4aeeb8eaffcde5a9e1.png



Источник: https://www.researchgate.net/public...ked_executables_using_support_vector_machines



В этом процессе данный инструмент упаковщика встраивает скомпилированный PE в другой исполняемый файл, который содержит информацию, необходимую для распаковки исходного содержимого и его выполнения. Пожалуй, самым известным упаковщиком, который даже не предназначен для вредоносных целей, является пакет UPX от Golang.



Более того, PE Crypter работает путем шифрования содержимого исполняемого файла и создания исполняемого файла, который расшифровывает оригинальный PE во время выполнения. Это очень полезно против антивирусных программ, поскольку большинство из них полагаются на статический анализ, а не на поведение во время выполнения (как EDR). Таким образом, полное сокрытие содержимого исполняемого файла до времени выполнения может быть очень эффективным, если только AV не сгенерировал сигнатуры против методов шифрования/дешифрования, что и произошло в случае, когда я пробовал использовать nimpcrypt.



Наконец, у нас также есть возможность преобразовать нативный PE обратно в шеллкод. Это можно сделать, например, с помощью инструмента hasherezade's pe_to_shellcode.



Объяснив теперь все возможные способы обхода антивирусных программ, начиная с исполняемого файла, я хотел бы упомянуть фреймворк, объединяющий все шаги в одном инструменте: inceptor от KlezVirus. Инструмент может оказаться очень сложным, и большинство шагов не нужны для простого обхода Defender, но его можно лучше объяснить с помощью следующего рисунка:



Архитектура Inceptor

4e646185fb50b70135592.png

Источник: GitHub - klezVirus/inceptor: Template-Driven AV/EDR Evasion Framework



В отличие от предыдущих инструментов, Inceptor позволяет разработчику создавать собственные шаблоны, которые будут модифицировать двоичный файл на каждом этапе рабочего процесса, так что, даже если подпись генерируется для публичного шаблона, вы можете иметь свои собственные частные шаблоны для обхода хуков EDR, исправления AMSI/ETW, использования аппаратных точек останова, использования прямых системных вызовов вместо DLL в памяти и т.д.


5. Зашифрованная инъекция шеллкода



Инъекция шеллкода - это очень известная техника, которая заключается во вставке/инъекции позиционно-независимого шеллкода в данный жертвенный процесс, чтобы в итоге выполнить его в памяти. Это может быть выполнено различными способами. Смотрите следующее изображение для хорошего обзора общеизвестных способов.



Методы инъекции в процесс

Продолжение : Card Company - Переход🛑
 
первый же способ помог, спасибо
 
не первый раз выручаете, спасибо
 
Обход Защитника Windows (10 способов)

Введение

В этой статье я расскажу о 10 способах/техниках обхода полностью обновленной системы Windows с актуальными данными Windows Defender с целью выполнения произвольного кода (кроме разрешений/ACL).



Для тестирования использовалась следующая конфигурация:

  • AWS EC2 с Ubuntu Linux AMI в качестве атакующего C2-сервера.
  • AWS EC2 с Windows Server 2019 AMI в качестве машины жертвы.
  • Локальная машина Windows 10 с Visual Studio 2022 Community для разработки/компиляции вредоносного ПО.
  • Локальная машина Kali Linux для атаки.
Обратите внимание, что я не буду слишком углубляться во многие концепции и в основном буду исходить из базовых знаний. Кроме того, я не стал выбирать слишком сложные техники, например, прямые вызовы системы (direct syscalls) или аппаратные точки останова (hardware breakpoints), поскольку это чрезмерно для антивирусов, и в любом случае их лучше описать в отдельной статье, посвященной EDR.



Отказ от ответственности: Информация, представленная в этой статье, предназначена исключительно для образовательных и этических целей. Описанные техники и инструменты предназначены для законного и ответственного использования с явного согласия владельца целевой системы. Любое несанкционированное или злонамеренное использование этих техник и инструментов строго запрещено и может привести к юридическим последствиям. Я не несу ответственности за любой ущерб или юридические проблемы, которые могут возникнуть в результате неправильного использования предоставленной информации.



1. In-Memory AMSI/ETW patching



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



AMSI, или AntiMalware Scan Interface, - это независимый от производителя элемент управления безопасностью Windows, который сканирует PowerShell, wscript, cscript, макросы Office и т.д. и отправляет телеметрию поставщику безопасности (в нашем случае Defender), чтобы тот решил, является ли она вредоносной или нет.



ETW, или Event Tracing for Windows, - это еще один механизм безопасности, который регистрирует события, происходящие в пользовательском режиме и драйверах ядра. Поставщики могут анализировать эту информацию, полученную от процесса, чтобы решить, имеет ли он вредоносные намерения или нет.



К сожалению, Windows Defender работает с очень малым количеством телеметрии, поступающей от сеансов PowerShell. В частности, исправление AMSI для текущего процесса позволит нам выполнять любые вредоносные программы без файлов, включая инструменты (Mimikatz, Rubeus и т.д.) и ревер-шеллы.



Для доказательства концепции я буду использовать встроенную функцию evil-winrm Bypass-4MSI, но очень легко создать собственный патчер AMSI/ETW в виде сценария PowerShell или исполняемого файла, как мы увидим позже.



Таким образом, цепочка kill для дампа In-Memory logons с Mimikatz из процесса LSASS работает следующим образом:



In-Memory AMSI Patching PoC

e6dfa1329d7d940d1128c.png

Для лучшего понимания набор команд может быть объяснен на более высоком уровне следующим образом:

  • Попробуйте написать известный триггер "Invoke-Mimikatz" как способ проверить, активен ли Defender.
  • Выполните функцию evil-winrm Bypass-4MSI для исправления AMSI в текущем сеансе PowerShell.
  • Снова вызовите триггер AV, чтобы проверить, работает ли телеметрия AMSI (как мы видим, уже нет).
  • Загрузите реальный модуль Invoke-Mimikatz PowerShell в память с помощью Invoke-Expression.
  • Выполните Mimikatz для дампа паролей входа в систему из LSASS.
Обратите внимание, что выполнение Mimikatz было просто в демонстрационных целях, но вы можете делать практически все, что хотите из терминала PowerShell без телеметрии AMSI.



2. Обфускация кода



Обфускация кода обычно не нужна или не стоит тратить на нее время для изначально компилируемых языков, таких как C/C++, поскольку компилятор в любом случае будет применять множество оптимизаций. Но большая часть вредоносных программ и инструментов написана на C# и, иногда, Java. Эти языки компилируются в байткод/MSIL/CIL, который легко поддается реверс-инженерии. Это означает, что вам придется применить некоторую обфускацию кода, чтобы избежать обнаружения сигнатур.



Существует множество обфускаторов с открытым исходным кодом, но я буду основывать доказательство концепции этого раздела на инструменте обфускатора InvisibilityCloak C# от h4wkst3r.



Например, используя инструмент GhostPack's Certify, который обычно используется для поиска уязвимых сертификатов в домене, мы можем использовать вышеупомянутый инструмент для обхода защитника следующим образом.



Убедитесь, что Defender запущен и блокирует сборку Certify по умолчанию

fcfec81eb5eeef87c8955.png

Обфускация кода Certify с помощью InvisibilityCloak

594fa2b29dcf32b04e4c6.png


Попытайтесь запустить обфусцированный Certify

1a94f7909c90c1f4227e5.png


Мы видим, что теперь все работает без проблем, однако выдает ошибку, поскольку виртуальная машина не подключена к домену или не является контроллером домена.



Мы можем сделать вывод, что все получилось, однако, обратите внимание, что некоторые инструменты могут нуждаться в более глубокой обфускации, чем другие. Например, в данном случае я выбрал Certify вместо Rubeus, поскольку это было проще для простых демонстрационных целей.



3. Обфускация во время компиляции



Для изначально компилируемых языков, таких как C, C++, Rust и т.д., вы можете использовать обфускацию во время компиляции, чтобы скрыть реальное поведение подпрограмм и общий поток инструкций.



В зависимости от языка, могут существовать различные методы. Поскольку для разработки вредоносных программ я использую C++, я расскажу о двух из них, которые я пробовал: обфускация LLVM и метапрограммирование шаблонов.



Для обфускации LLVM самым большим публичным инструментом в настоящее время является Obfuscator-LLVM. Этот проект представляет собой форк LLVM, который добавляет уровень безопасности через обфускацию к создаваемым двоичным файлам. В настоящее время реализованы следующие дополнительные возможности:

  • Подмена инструкций. Обфускация инструкций ассемблера для получения эквивалентного поведения при большей вычислительной сложности.
  • Поддельный поток управления. Добавление нежелательных блоков инструкций для скрытия оригинального потока кода инструкций.
  • Сглаживание потока управления. Делает ветвления и переходы более трудно предсказуемыми для того, чтобы скрыть намеренный поток инструкций.
В заключение можно сказать, что инструмент генерирует двоичные файлы, которые в целом гораздо труднее поддаются статическому анализу человеком/антивирусами/EDRs.



С другой стороны, метапрограммирование шаблонов - это техника C++, которая позволяет разработчикам создавать шаблоны, генерирующие исходный код во время компиляции. Это дает возможность генерировать различные двоичные файлы при каждой компиляции, создавать бесконечное количество ветвей и блоков кода и т.д.



Два общедоступных фреймворка, которые я знаю и использовал для этой цели, следующие:



Для данного PoC я буду использовать второй, так как считаю его более простым в использовании.



Более того, для PoC я буду использовать AMSI_patch от TheD1rkMtr в качестве двоичного файла по умолчанию для обфускации, так как это довольно простой проект на C++. Код обфусцированного двоичного файла можно найти здесь.



Сначала давайте посмотрим на базовое дерево бинарных функций под Ghidra.



Дерево двоичных функций по умолчанию

9779d2de2a2734d62b04b.png

Как мы видим, его не так уж сложно проанализировать. И вы можете найти главную функцию под 3-й рутиной FUN_.



Главная функция бинарной функции по умолчанию

f8bba9e48e3d1a987e03a.png


Которая выглядит довольно простой для анализа и понимания ее поведения (патч AMSI через AMSIOpenSession в данном случае).



Теперь давайте посмотрим на обфусцированное дерево бинарных функций.



Обфусцированное дерево бинарных функций

0c6bdfca2c68e1972ef9c.png

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



Обфусцированная бинарная функция мусора

ff93fba9036467706e384.png

Это простые junk-функции, но очень полезные для сокрытия реального поведения.



Теперь для финального теста давайте попробуем это на реальной системе Windows для PoC. Обратите внимание, поскольку двоичный файл исправляет AMSI для данного процесса через PID в качестве параметра, PoC будет очень похож на первый метод; исправление AMSI для текущего сеанса PowerShell, чтобы обойти сканирование Defender в памяти.



Обфускация во время компиляции PoC

81162bfdc16559f2828ab.png


И, как мы видим, это сработало, Defender не остановил бинарник ни статически, ни во время выполнения, что позволяет нам удаленно исправлять AMSI для процесса.



4. Обфускация/упаковка бинарных файлов



Когда вы уже сгенерировали двоичный файл, ваши опции, в основном, сводятся к следующему:

  • Обфускация ассемблерных инструкций двоичного файла.
  • Упаковка двоичного файла(-ов).
  • Шифрование содержимого двоичного файла для его расшифровки во время выполнения.
  • Как вариант, преобразование в шеллкод для последующей манипуляции и инъекции.
Начиная с первого, у нас есть несколько вариантов с открытым исходным кодом, включая, например:



На высоком уровне, Alcatraz работает путем изменения сборки двоичного файла несколькими способами, такими как обфускация потока управления, добавление нежелательных инструкций, неоптимизация инструкций и скрытие реальной точки входа до выполнения.



С другой стороны, Metame работает, используя случайность для генерации различных сборок (хотя всегда с эквивалентным поведением) при каждом запуске. Это более известно как метаморфический код и часто используется в настоящих вредоносных программах.



Наконец, ROPfuscator работает, как видно из названия, используя программирование, ориентированное на возврат, для создания ROP-гаджетов и цепочек из исходного кода, таким образом скрывая исходный поток кода от статического анализа и, возможно, даже динамического, поскольку эвристикам будет сложнее анализировать последовательные вредоносные вызовы. Следующее изображение лучше описывает весь процесс.



Архитектура ROPfuscator

87912a1cf9104cd8b9472.png


Источник: ropfuscator/architecture.svg at master · ropfuscator/ropfuscator



Продолжая тему бинарной упаковки, базовая архитектура упаковщика может быть описана следующим изображением.



Архитектура упаковщика PE

72c4aeeb8eaffcde5a9e1.png



Источник: https://www.researchgate.net/public...ked_executables_using_support_vector_machines



В этом процессе данный инструмент упаковщика встраивает скомпилированный PE в другой исполняемый файл, который содержит информацию, необходимую для распаковки исходного содержимого и его выполнения. Пожалуй, самым известным упаковщиком, который даже не предназначен для вредоносных целей, является пакет UPX от Golang.



Более того, PE Crypter работает путем шифрования содержимого исполняемого файла и создания исполняемого файла, который расшифровывает оригинальный PE во время выполнения. Это очень полезно против антивирусных программ, поскольку большинство из них полагаются на статический анализ, а не на поведение во время выполнения (как EDR). Таким образом, полное сокрытие содержимого исполняемого файла до времени выполнения может быть очень эффективным, если только AV не сгенерировал сигнатуры против методов шифрования/дешифрования, что и произошло в случае, когда я пробовал использовать nimpcrypt.



Наконец, у нас также есть возможность преобразовать нативный PE обратно в шеллкод. Это можно сделать, например, с помощью инструмента hasherezade's pe_to_shellcode.



Объяснив теперь все возможные способы обхода антивирусных программ, начиная с исполняемого файла, я хотел бы упомянуть фреймворк, объединяющий все шаги в одном инструменте: inceptor от KlezVirus. Инструмент может оказаться очень сложным, и большинство шагов не нужны для простого обхода Defender, но его можно лучше объяснить с помощью следующего рисунка:



Архитектура Inceptor

4e646185fb50b70135592.png

Источник: GitHub - klezVirus/inceptor: Template-Driven AV/EDR Evasion Framework



В отличие от предыдущих инструментов, Inceptor позволяет разработчику создавать собственные шаблоны, которые будут модифицировать двоичный файл на каждом этапе рабочего процесса, так что, даже если подпись генерируется для публичного шаблона, вы можете иметь свои собственные частные шаблоны для обхода хуков EDR, исправления AMSI/ETW, использования аппаратных точек останова, использования прямых системных вызовов вместо DLL в памяти и т.д.


5. Зашифрованная инъекция шеллкода



Инъекция шеллкода - это очень известная техника, которая заключается во вставке/инъекции позиционно-независимого шеллкода в данный жертвенный процесс, чтобы в итоге выполнить его в памяти. Это может быть выполнено различными способами. Смотрите следующее изображение для хорошего обзора общеизвестных способов.



Методы инъекции в процесс

Продолжение : Card Company - Переход🛑
отлично
 
спасибо, не с первого раза, но помогло
 
Назад
Верх Низ