Вопрос по размещению пейлоада

[Kernel32dll]

Всем привет!
Я совсем недавно в теме малвари, так что не знаю многих мелочей. Сейчас меня мучает один вопрос - как и где люди(предпочтительнее те, кто криптуют, скрывают ну или просто создают малварь) размещают полезную нагрузку(в моем случае - шеллкод) в компилируемом файле? Я знаю о существовании различных секций PE-файла, но не углублялся в ассемблер, и тем более в машинный код, слишком уж там страшно. Как на уровне кода(c/c++) скрыть пейлоад в какой-либо секции? Или просто создать char, а компилятор там уже сам разберётся? Использовать стеганографию, и впихнуть шелл в ресурсы, чтобы потом его исполнить? Есть ли какие то статьи/ресурсы именно по тематике размещения шелла в PE-файле?

 

[fadey_ldr]

fadey_ldr сказал(а):
Лучше сжимать пейлоад а потом шифровать его, но из-за шифрования портится энтропия, поэтому после шифрования ее нужно нормализовать, что вернет тебя к размеру примерно до сжатия, а может и больше. После этих манипуляций засовывай пейловд в ресурсы, например как картинку, заголовок стандартный от bmp подогнанный под размер пейлоада, а само "тело" картинки - твой шифрованный пейлоад. Что бы использовать пейлоад надо будет найти его в ресурсах, достать как картинку, распарсить заголовок bmp и извлечь тело картинки, тело расшифровать и разжать, и потом уже использовать пейлоад в памяти. Это достаточно краткая, но емкая инструкция, далее только фантазия.

Интересно! И что, детект в таком случае минимальный? А если еще использовать стеганографию и всунуть пейлоад в JPG файл?

 

[Kernel32dll]

Kernel32dll сказал(а):
Интересно! И что, детект в таком случае минимальный? А если еще использовать стеганографию и всунуть пейлоад в JPG файл?

детектов меньше по сравнению с предложенным способом не станет.
fadey_ldr
предложил хороший способ - при ПРАВИЛЬНОЙ реазизации будет ФУД даже при скане EDR

 

[KernelMode]

Или просто создать char, а компилятор там уже сам разберётся?

Какой у тебя шеллкод? Если а-ля exec/bind port, то там же от силы две-три сотни байтов. Так что вообще без разницы, где это хранить. Просто поксорь и допиши в секцию .code по смещению, которое сможешь вычислить во время исполниния.
С картинками еще проще. Можно заюзать exiftool и записать метаданные, либо свой энкодер/декодер PNG сделай. Спецификации всех форматов есть. Примеров реализации тоже навалом.


Компилятор по дефолту может поместить это в .data, а там неисполняемая секция. То есть шелл придется вытащить и загрузить в исполняемую секцию, во время выполнения.
Еще имеет значение где ты запускаешь шелл. В своем процессе или в чужом.
Так же важно сохранить регистры и вернуть управление назад, если это обычный JMP на начало шелла. А если у тебя отдельный поток, то нужно из него правильно выйти.
Некоторые шеллкоды юзают ExitProcess, об этом тоже нужно позаботиться.

Если боишься ассемблера, попробуй начать с уроков Нарвахи.
Последнее редактирование: 30.08.2023

 

[int3]

kubic сказал(а):
Какой у тебя шеллкод? Если а-ля exec/bind port, то там же от силы две-три сотни байтов. Так что вообще без разницы, где это хранить. Просто поксорь и допиши в секцию .code по смещению, которое сможешь вычислить во время исполниния.
С картинками еще проще. Можно заюзать exiftool и записать метаданные, либо свой энкодер/декодер PNG сделай. Спецификации всех форматов есть. Примеров реализации тоже навалом.


Компилятор по дефолту может поместить это в .data, а там неисполняемая секция. То есть шелл придется вытащить и загрузить в исполняемую секцию, во время выполнения.
Еще имеет значение где ты запускаешь шелл. В своем процессе или в чужом.
Так же важно сохранить регистры и вернуть управление назад, если это обычный JMP на начало шелла. А если у тебя отдельный поток, то нужно из него правильно выйти.
Некоторые шеллкоды юзают ExitProcess, об этом тоже нужно позаботиться.

Если боишься ассемблера, попробуй начать с уроков Нарвахи.
Нажмите, чтобы раскрыть...

Шелл действительно огромен. Txt файл с шеллом внутри весит 313 кб(учитывая то, что это шелл сжатой PE сборки). Я сейчас говорю про шелл, сгенерированный пончиком. И в крипте я думаю использовать классический process injection шеллкода.

 

[Kernel32dll]

kubic сказал(а):
Какой у тебя шеллкод? Если а-ля exec/bind port, то там же от силы две-три сотни байтов. Так что вообще без разницы, где это хранить. Просто поксорь и допиши в секцию .code по смещению, которое сможешь вычислить во время исполниния.
С картинками еще проще. Можно заюзать exiftool и записать метаданные, либо свой энкодер/декодер PNG сделай. Спецификации всех форматов есть. Примеров реализации тоже навалом.


Компилятор по дефолту может поместить это в .data, а там неисполняемая секция. То есть шелл придется вытащить и загрузить в исполняемую секцию, во время выполнения.
Еще имеет значение где ты запускаешь шелл. В своем процессе или в чужом.
Так же важно сохранить регистры и вернуть управление назад, если это обычный JMP на начало шелла. А если у тебя отдельный поток, то нужно из него правильно выйти.
Некоторые шеллкоды юзают ExitProcess, об этом тоже нужно позаботиться.

Если боишься ассемблера, попробуй начать с уроков Нарвахи.
Нажмите, чтобы раскрыть...

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

 

[Kernel32dll]

Kernel32dll сказал(а):
Но конкретно реализации "Что бы использовать пейлоад надо будет найти его в ресурсах, достать как картинку, распарсить заголовок bmp и извлечь тело картинки, тело расшифровать и разжать, и потом уже использовать пейлоад в памяти. Это достаточно краткая, но емкая инструкция, далее только фантазия." Я особо нигде не видел

Ну тут дело в том, что это достаточно замороченный способ, много шагов как на этапе скрытия, так и на этапе извлечения пейлоада, поэтому он не популярен, но как упомянул выше KernelMode - при правильной реализации можно добиться стабильного FUD

 

[fadey_ldr]

In my experience the shellcode can even be stored simply as an unsigned char [] without detections. What is relevant is that it well encrypted and then it can be stored anywhere.