• XSS.stack #1 – первый литературный журнал от юзеров форума

Отрубить AMSI и WLDP из VBScript'а

DildoFagins

TPU unit
Забанен
Регистрация
11.08.2020
Сообщения
4 315
Решения
2
Реакции
5 265
Пожалуйста, обратите внимание, что пользователь заблокирован
Есть ли способ отрубить AMSI и WLDP в контексте текущего процесса кодом на VBScript/JScript на горячую (без перезагрузки своего процесса)? Прямого доступа к памяти в VBS'е нет, как в том же Powershell'е, так что пропатчить функцию не получится. Понятно, что можно COM-хайджекинг сделать, но тогда будет нужно перезапускать процесс, а этого нельзя сделать по текущим условиям задачи. Больше пока ничего в голову не приходит. Подкиньте идею.
 
Написать шеллкод и из VBScript заинжектиться в интерпретатор, процес которого уже патчить.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Написать шеллкод и из VBScript заинжектиться в интерпретатор
Каким образом?


процес которого уже патчить
VBScript как бы и так исполняется в процессе, в котором загружается AMSI. Какой процесс?
 
Каким образом?



VBScript как бы и так исполняется в процессе, в котором загружается AMSI. Какой процесс?
on vrode hochet zainjektitsya/zaspawnit' process ps i ottuda otrubit' amsi poprobovat' na novie sistemi patcha netu po amsi, po krainei mere v pablike
 
Пожалуйста, обратите внимание, что пользователь заблокирован
on vrode hochet zainjektitsya/zaspawnit' process ps i ottuda otrubit' amsi poprobovat' na novie sistemi patcha netu po amsi, po krainei mere v pablike
Патчить свой процесс из другого процесса - это ну такое канеш, не элегантное решение.
 
Есть ли способ отрубить AMSI и WLDP в контексте текущего процесса кодом на VBScript/JScript на горячую (без перезагрузки своего процесса)? Прямого доступа к памяти в VBS'е нет, как в том же Powershell'е, так что пропатчить функцию не получится. Понятно, что можно COM-хайджекинг сделать, но тогда будет нужно перезапускать процесс, а этого нельзя сделать по текущим условиям задачи. Больше пока ничего в голову не приходит. Подкиньте идею.
У вас должно быть более 100 сообщений для просмотра скрытого контента.

Сталкивался с такой задачей.
1) на vbs/vba не писал, но вот видел и не раз в разных макрос билдерах под офисы функционал по запуску шеллкода. Вроде как даже Metasploit умеет выдавать такие шаблоны под офис. Грузишь свой шк, патчишь AmsiScanBuffer/AmsiScanString.
2) https://github.com/johnjohnsp1/Shellcode-Via-HTA/blob/master/BeaconMigrate.js.
Техника, которая используется в dotnet2jscript.
3) ActCtx. & dynamicwrapperx - ключевые слова для поиска. Если разберёшься как работает, сможешь адаптировать под себя. Как я понял, работа идёт с COM. По этому можно юзать с под js/vbs/...
———
Перечисленные выше варианты - это как способ добиться возможности работы с winapi. А дальше уже можешь мудрить с памятью как бы.
4) Самый сложный Amsi обход, это так то даже обходом особо не назовёшь, так как ты ничего не патчишь, однако ты обходишь архитектурно механизм рескана скриптов.
Вот чуть детальнее:
1)Интерпретаторы устроены таким образом, чтобы на каждый новый скриптблок порождать рескан контента(интерпретатор юзает COM интерфейс amsi и кидает ему на чек контент).
Что такое каждый новый скриптблок? Простыми словами каждый раз, когда по мнению интерпретатора происходит компиляция скрипта. Первый скан происходит в момент когда скрипт только начинает исполняться(тут ничего не сделаешь, скрипт в момент начала исполнения должен быть чист). Остальные ресканы происходят в моменты, когда к примеру юзаешь eval() в js.(вообще возьми frida-trace и сам посмотри в какие моменты происходит вызов AmsiScanBuffer)
. то есть с помощью eval() у нас загружается новый контент(даже если ты его дешифруешь перед этим, или его в момент доставки вообще нет в скрипте и тянешь его с сервера запросом - его все равно будет видно, поскольку, это считается новым скриптблоком).
Вот когда понимание, как работает этот механизм будет, напрашивается решение на реализацию - vm+компилятор. Схема такая - ты пишешь вредоносный код на js, компилятором(ты его должен будешь реализовать) превращаешь js код в опкоды своей vm. При этом вм должна быть написана тоже на jscript. Я пошёл этим путём. Компилятор из сорцов в опкоды вм делал с помощью Nodejs Babel(парсил AST). Сама вм - heap based. Че то показалось мне это проще, чем на регистрах или стеке, хотя по началу на них делать планировал.(Твой хип это просто массив в js, адреса - индексы массива)
Получается подобный набор инструкций
store 0,5
store 1,10
add 0,1,2
assign 3, 2
Что эквивалентно такому коду js
x = 5+10
Так вот подошли на этом этапе к архитектурному обходу. В чем фишка. Первоначально js кидает на скан только тело вм. Но по сути, тело вм не имеет в себе реальной информации о том, что она будет исполнять. Кроме самого тела вм - нечего детектить. А реальный твой код - это данные, которые ты вообще можешь получать в момент исполнения с сервера. А теперь фишка. Когда ты загружаешь опкоды вм в саму вм - ты не триггеришь ничего, что говорит интерпретатору jscript о том, что появился новый код(в обычном сценарии - не используя eval и его аналоги ты никак не загрузишь новый js код так, чтобы интерпретатор jscript об этом не узнал и не кинул его на скан). А в этом сценарии - конкретно нового js кода не появляется, нечего кидать на рескан. А новые опкоды для вм могут появиться в динамике, при этом рескана не произойдёт. Это и есть своеобразный обход. Рескана нет и не будет, пока не появится новый js код. А опкоды для вм это фактически новый язык поверх js.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
на vbs/vba не писал, но вот видел и не раз в разных макрос билдерах под офисы функционал по запуску шеллкода. Вроде как даже Metasploit умеет выдавать такие шаблоны под офис. Грузишь свой шк, патчишь AmsiScanBuffer/AmsiScanString.
Ну я не видел стейджеров таких, чтобы напрямую с VBScript или JScript запускали шелл-кодец. Все реализованы через DotnetToJScript и аналогичных техниках, загружая дотнетовские ассембли. Может ткнешь меня носов в такой?)

Техника, которая используется в dotnet2jscript.
Я в курсе, проблема в том, что вызов Assembly.Load будет просканирован AMSI и еще будет подвержен WLDP во фреймворке 4.8 (если память не изменяет). Вопрос именно в том, чтобы отрубить AMSI до загрузки собственно полезной нагрузки, тк в некоторых случаях (в зависимости от авера) эта самая нагрузка через AMSI интерфейс может улететь в облако.

ActCtx. & dynamicwrapperx - ключевые слова для поиска. Если разберёшься как работает, сможешь адаптировать под себя. Как я понял, работа идёт с COM. По этому можно юзать с под js/vbs/
Регистрировать дополнительные COM объекты не хотелось бы канеш. Такими темпами можно и Питоновский интерпретатор от ActiveState поставить как COM объект, и он наверное не будет подвержен AMSI, да и возможностей у него куча.

Схема такая - ты пишешь вредоносный код на js, компилятором(ты его должен будешь реализовать) превращаешь js код в опкоды своей vm.
Есть уже готовые виртуальные машины для разных языков внутри того же джаваскрипта, как например Батавия или как то так называлась вм для Питона в JS. Проблема в том, что это будет работать ровно до того момента, как через AMSI будет палиться код самой виртуальной машины. А это рано или поздно случится.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Да, Батавия: https://github.com/beeware/batavia - но совсем далеко не факт, что она заведется под ущербным JScript'ом. Там же вроде IE 8 совместимый движок под копотом. Но чисто теоретически такую машину лучше использовать, чем самописную, тк это легитимный оупенсорсный проект. На него опять же теоретически не должны клипать сигнатуры одни за одной.
 
Последнее редактирование:
Патчить свой процесс из другого процесса - это ну такое канеш, не элегантное решение.
nu ti patchish ne process, a amsiscanbuffer. esli est' dostup k failam -- mozhno napraymuu propatchit' dll. proshe obfuscirovat, ne rabotaet eto na svezhi versiyah windows
 
Да, Батавия: https://github.com/beeware/batavia - но совсем далеко не факт, что она заведется под ущербным JScript'ом. Там же вроде IE 8 совместимый движок под копотом. Но чисто теоретически такую машину лучше использовать, чем самописную, тк это легитимный оупенсорсный проект. На него опять же теоретически не должны клипать сигнатуры одни за одной.
Это ,конечно, все очень хорошо, но подозреваю будет проблема. Если говорить про простые операции типо add xor mul - тут проблемы вряд-ли будут. Чуйка говорит, что проблемы начнутся на этапе работы именно с окружением, в котором это все запущено. То есть проблемы с проксированием апи(или реализации своей стандартной либы). Будь то браузерный апи(в jscript его нет), или nodejs апи(у jscript иначе происходит взаимодействие с фс и в целом с системой, нежели у ноды - посредством activex.) По этому вангую, что вряд ли там проксирование апи заточено под механизмы jscript. Плюс учитывай стандарты версии jscript. Там большая часть обычных апи даже по работе со строками может работать не так, как в современном js. Ну или вот, например, конструкция
x = window[“alert”]
x(“hello”)
Сработает в оригинальном жс, но в jscript
x = WSH[“Echo”]
x(“hello”)
Уже не сработает. Только такой вариант в одну строку
WSH[“Echo”](“hello”).
По этому в целом, разумнее будет делать свою вм с правильной проксификацией апи, а она делается достаточно просто, к примеру с точки зрения вм и компиляторе конструкции вида:
x[“Echo”](“hello”)
И
WSH[“Echo”](“hello”)
Похожи, но разница в том, что х это будет скорее всего ранее созданный объект, именно нами в скрипте, по этому на него будет ссылка в хипе. (в компиляторе надо хранить dict вида identifier-addr чтобы в такие моменты понимать, идёт обращение к встроенному апи или раннее созданному в скрипте объекту. И если в дикте есть наш identifier x, то мы его резольвим в вм так
obj = heap[addr]
obj[property](call_args)
А WSH это как бы встроенный идентификатор. По этому его не будет в дикте. Значит его можно найти в this вот так(как и все встроенное апи)
obj = this[identifier]
//obj = WSH;
obj[property](call_args)
/*obj[“Echo”](“hello”)*/
По этому проксификация апи в таком случае будет делаться легко. Понятное дело в одном посте нереально описать все кейсы, но примерно по такой схеме можно двигаться дальше. И как бы вряд ли в ботавии эти моменты для jscript продуманы.
———
По поводу ав - ну вот я ща смотрю на вм и реально слабо понимаю, за что можно зацепиться, учитывая, что code flow вм можно поморфить(если вдруг ав за ифы и циклы захочет зацепиться). По весу же сама вм на jscript выходит под 30кб сорца.
 
Последнее редактирование:


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх