Всем привет. Сегодня решил ознакомиться со скриптовой малварью. В целом, почитав документацию и сделав несколько тестов - не понял одного: каковы её преймущества по сравнению с бинарщиной? Спасибо.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Скриптовая малварь
- Автор темы panarames
- Дата начала
Можно в fileless.
Ну и скрипт проще обфусцировать, чем бинарь (но это не точно, ибо AMSI).
Ну и скрипт проще обфусцировать, чем бинарь (но это не точно, ибо AMSI).
Точно.
Последнее редактирование:
Подкиньте документацию
Простота разработки, возможность использовать смесь winapi & .NET в одном продукте и возможность обхода всех топ аверов в рантайме. Абсолютная незащищённость домашних вин машин от такого типа атак. Всего лишь.
Последнее редактирование:
- Автор темы
- Добавить закладку
- #6
А как же windef с процессингом скриптовых ЯП? Он выносит подобное в два счета. Или же нет?Простота разработки, возможность использовать смесь winapi & .NET в одном продукте и возможность обхода всех топ аверов в рантайме. Абсолютная незащищённость домашних вин машин от такого типа атак. Всего лишь.
- Автор темы
- Добавить закладку
- #7
Плюс нашёл такую статью за 2018 год.
Нет, не так это работает. В самом интерпретаторе встроено обращение к COM AMSI. Сначала идет инициализация сессии Amsi, после этого идет передача контекста выполнения аверу, тому, кто подписан на такие «события» с другой стороны. Обработчиком этих событий может быть как windef, так и любой авер, даже по сути самописный софт, если он реализует нужные интерфейсы. Тут основную роль играет то, КАК интерпретатор процессит контекст с помощью этого интерфейса и ЧТО конкретно он процессит. На основе этих 2 переменных и мутятся разного рода обходы ав в скриптовом векторе. И он не выносит подобное в два счета. Вообще не выносит.
Последнее редактирование:
Простота разработки, возможность использовать смесь winapi & .NET в одном продукте и возможность обхода всех топ аверов в рантайме. Абсолютная незащищённость домашних вин машин от такого типа атак. Всего лишь.
А какие существенные минусы у скриптовой малвари?
Конкретно у пш - 1) кривая работа с потоками. Надо прям задрочиться чтобы нормально все было.2) Нужен лаунчер. Так или иначе что-либо, что запустит в системе ехе powershell и передаст в аргументах скрипт на исполнение. Сама передача управления в дефолтных вариантах палится. То есть, если стартер у тебя js wsh, то не выйдет так просто взять и через activexobject wscript.shell запустить пш с аргументами. Даже, если сам скрипт пш чист, то может дать детект только на такую передачу управления. 3) Скорость работы. Как не крути, любой интерпретатор будет медленнее с++ в какой то мере. 4) Утечки памяти на ровном месте. GC.Collect отчасти спасает ситуацию, но не всегда.(да, лол, надо иногда самому триггерить gс). 5) может сожрать при работе много оперативы. 6) для некоторых - синтаксис языка. Много решений, которые казалось бы зачем сделаны. Например работа с return value в функциях с пш. 7) сервер сайд powershell для Линукс имеет некоторые отличия (баги), от пш для винды. Я помню ахуел дебажить ошибку дня 2. А оказалось ошибки нет. Просто пш для сервера на линуксе и для винды по разному кастовали тип. х#й знает почему. 8) нет нормального ide. 9) ебанутый immutable ast. который в management.automation, который возвращает родной парсер пш. Когда писал обфускатор, столкнулся с этим. Для того, чтобы изменить какое то значение найденное в ast, нужно получать позицию искомого элемента в теле скрипта и мануально заменять подстроку в строке. Только прикол в том, что меняя значение элемента на новое - ты изменяешь позиции остальных элементов на разницу длины контента старого значения и нового. И по сути нужен перепарс аста, для получения актуальных позиций элементов. Короче говоря, для более менее сложных техник обфускации сложно сделать за 1 парсинг скрипта в аст изменения N элементов, где N > 1.
10) чтобы малварь работала с вин 7. Надо разрабатывать функционал для powershell v2. А там много чего нет, что есть в 5 и выше.
11) так, как это текст, а не бинарная форма, скорее всего не выйдет продавать «побилдово», понятно почему.
Пока все, что вспомнил.
- Автор темы
- Добавить закладку
- #11
Окей. Haunt, спасибо за ответ. Тогда вопрос к тебе, можешь посоветовать какую-то литературу/курсы, дабы освоить ПШ? Я с ним не особо дружу.
Stackoverflow driven development
Ну вообще по сути надо начинать с изучения в целом .NET возможностей и апи. Синтаксис дело второе. Если есть опыт в изучении языков, то это вообще не проблема. Из необычного cmdletы и пайпы. И cmdletы в пайпах. Но это я бы отнёс по сути к функциональщине. Ниче сложного так то. Какие то интересующие примеры отлично гуглятся. А если в контексте малвари - на гитхабе полно примеров на пш и обходов юака, и lpe, и loadpe/runpe, кейлоггеров, что хочешь вообще. Ну вот на основе этих примеров и учишь, сначала синтаксис разбираешь, а потом эти примеры. Разберёшься с апи дотнета, поймёшь как инвокать винапи и кучу других tips & tricks, сможешь написать что то своё. По сути если ты умеешь че то на C# сбахать, то перенести это на powershell не составит труда. А на с# ещё больше примеров на гитхабе. Самое сложное будет пока для тебя это понять принципы экосистемы, что откуда вызывается и почему. Потому что принципы разработки несколько отличаются от чисто нативной разработки . То есть понять типы в .NET, а шо делать с условным getprocaddress и тем что оно возвращает, как декларировать winapi структуры, где хранить хэндлы, зачем вообще нужны IntPtr и делегаты, в чем разница сборки с /unsafe .net бинарей ну и прочее, прочее.
Последнее редактирование: