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

loader

Вроде как задача лоадера скачать и запустить, иначе это уже не лоадер.
Еще на лоадер разумно возложить анализ компа на тему а стоит ли сюда вообще что то скачивать...но здесь уже есть но.
Остальное все уже не хорошо для лоадера.
А еще лоадер это то что сразу без вариантов попадет в хонипоты и будет изучено и быстро внесено в базы, и зачем такое закреплять в винде?
В идеале лоадер(не пытаясь делать хитрых манипуляций) качает шеллкод(который естесно нет надобности дропать на хдд), шеллкод проводит анализ
компа и если все ок может сделать хитрые мангипуляции для обеспечения наиболее мягкого старта для бота, потом качает и запускает бот, который уже инсталлируется.
Анализ и и хитрые манипуляции в шеллкоде для того что бы они если и попали на разделочный стол к аверу то не сразу и что бы разбираться с ним было максимально не комфортно(те добавили лоадер в базу и на этом тупо забили).
 
Последнее редактирование:
Посоветую четко определиться что нужно.
Лоадер? Лоадер+шелл? Лоадер+шелл+бот?
Ну что для начала разобраться что и для чего нужно...какой то продукт не могу посоветовать =)... особенно свой.
Но мне было бы интересно узнать о ваших мечталках и хотелках, и во что вы их будете оценивать =)
 
Пожалуйста, обратите внимание, что пользователь заблокирован
В идеале лоадер(не пытаясь делать хитрых манипуляций) качает шеллкод(который естесно нет надобности дропать на хдд), шеллкод проводит анализ
компа и если все ок может сделать хитрые мангипуляции для обеспечения наиболее мягкого старта для бота, потом качает и запускает бот, который уже инсталлируется.
И да и нет. Норм лоадер собирает инфу (разную) и отправляет на сервер. На той стороне уже решается скидывать боевой софт или нет. Ну это я просто рассуждаю. Просто если ты скинеш шелл код на машину (длл не важно), его сдампят, поймут твой хитрый план и таки стянут твой мега страшный софт, фуд которого ты делал долго долго =)
 
О этот толстый 1% все еще с нами =)
Собирает инфу о компе тоже шеллкод.
Сдампить шеллкод задача непростая для автоматических систем, тем более присвоить такому дампу статус необходимости изучения специалистом...здесь ведь уже про человекочасы работы а сталобыть и деньги.
 
О этот толстый 1% все еще с нами =)
Собирает инфу о компе тоже шеллкод.
Сдампить шеллкод задача непростая для автоматических систем, тем более присвоить такому дампу статус необходимости изучения специалистом...здесь ведь уже про человекочасы работы а сталобыть и деньги.
А не подскажешь, есть ли в паблике наработки для автоматического "выцепления" шк ? Чтобы не изучать тупо весь сэмпл, а перейти к наиболее "вкусной" части ;)
 
Похоже что вы спросили не вполне понимая суть мною написанного и я распишу подробнее, это может быть полезно кому нибудь.
Итак наш лоадер скачал шеллкод, причем именно шеллкод а не длл, и произошло это на машине где установлена автоматическая система отловли малвари.
Поскольку шеллкод был скачан в зашифрованном виде то дам трафика мало что даст и ведь заранее неясно что это был шеллкод а дампить весь трафик
с пометкой к изучению специалистом явно непродуктивно.
Далее нам нужно поместить расшифрованный шеллкод в память где его можно будет выполнить,
для этого мы можем например загрузить какую то ненужную нам из системных длл и вписать шеллкод поверх ее кода,
а можем без затей аллочить RWX и помещать наш шелл туда.
На этом этапе автоматической системе тоже не понять что есть некий шеллкод который нужно дампить(если она конечно не трассирует лоадер, что врядле).
Далее мы выполняем наш шелл.
И вот когда наш шелл выполняет какую то тревожную апи, автоматическая система может смотреть адрес возврата и если это страница выполнимой памяти не принадлежащая ни одному из модулей
то автоматическая система может дампить все RWX страницы не принадлежащие модулям(все потому что вызов апи может быть сделан через гейт в другой странице).
Но что если гейт расположен в одной из длл, или цепочка таких гейтов, или шелл прописан в ту самую системную длл которую можно оверврайтить?
для определения что этот вызов был из шеллкода придется проверить много всего а это медленно, очень медленно(попробуйте запустить утилиту pc hunter она находит все хуки и патчи но скорость такова что вы сразу поймете почем ав так не делают).
Исходя из вышенаписанного автоматическая система может сделать дамп памяти процесса который ее чем то смутил но вероятность того что специалист сядет копаться в этом дампе выискивая шеллкод минимальна, это кропотливая ручная работа а значит это очень дорого.
Просто внесут в базы экзешник лоадера да и все.
Ковырять взрослый шеллкод который серьезно обфусцирован и морфлен и апи в котором либо по хешам либо сисколлами вам точно не понравиться, 100кб шеллкода можно морфом и обфускацией раздувать до любых объемов и грамотную обфускацию так просто скриптами не вычистить
(cmp [xxxx], xxx jne xxxx - попробуй вычисти такое..может это фейк а может нет, и вот когда весь код так разорван на кусочки то в IDA вам будет пичально), а еще могут быть обфусцированные вм и конечные автоматы =)...короче поймать сам шеллкод не просто а найти основания для его изучения еще сложнее.
 
Похоже что вы спросили не вполне понимая суть мною написанного и я распишу подробнее, это может быть полезно кому нибудь.
Итак наш лоадер скачал шеллкод, причем именно шеллкод а не длл, и произошло это на машине где установлена автоматическая система отловли малвари.
Поскольку шеллкод был скачан в зашифрованном виде то дам трафика мало что даст и ведь заранее неясно что это был шеллкод а дампить весь трафик
с пометкой к изучению специалистом явно непродуктивно.
Далее нам нужно поместить расшифрованный шеллкод в память где его можно будет выполнить,
для этого мы можем например загрузить какую то ненужную нам из системных длл и вписать шеллкод поверх ее кода,
а можем без затей аллочить RWX и помещать наш шелл туда.
На этом этапе автоматической системе тоже не понять что есть некий шеллкод который нужно дампить(если она конечно не трассирует лоадер, что врядле).
Далее мы выполняем наш шелл.
И вот когда наш шелл выполняет какую то тревожную апи, автоматическая система может смотреть адрес возврата и если это страница выполнимой памяти не принадлежащая ни одному из модулей
то автоматическая система может дампить все RWX страницы не принадлежащие модулям(все потому что вызов апи может быть сделан через гейт в другой странице).
Но что если гейт расположен в одной из длл, или цепочка таких гейтов, или шелл прописан в ту самую системную длл которую можно оверврайтить?
для определения что этот вызов был из шеллкода придется проверить много всего а это медленно, очень медленно(попробуйте запустить утилиту pc hunter она находит все хуки и патчи но скорость такова что вы сразу поймете почем ав так не делают).
Исходя из вышенаписанного автоматическая система может сделать дамп памяти процесса который ее чем то смутил но вероятность того что специалист сядет копаться в этом дампе выискивая шеллкод минимальна, это кропотливая ручная работа а значит это очень дорого.
Просто внесут в базы экзешник лоадера да и все.
Ковырять взрослый шеллкод который серьезно обфусцирован и морфлен и апи в котором либо по хешам либо сисколлами вам точно не понравиться, 100кб шеллкода можно морфом и обфускацией раздувать до любых объемов и грамотную обфускацию так просто скриптами не вычистить
(cmp [xxxx], xxx jne xxxx - попробуй вычисти такое..может это фейк а может нет, и вот когда весь код так разорван на кусочки то в IDA вам будет пичально), а еще могут быть обфусцированные вм и конечные автоматы =)...короче поймать сам шеллкод не просто а найти основания для его изучения еще сложнее.
Обфускация, морфинг - не помеха. Требуется именно выцеплять "сладкие вещи" и автоматизировать ковыряние сэмплов.
Самое сильное решение, что встречал "Platform for Architecture-Neutral Dynamic Analysis" - сборка на основе гипервизора QEMU. Вкратце, полностью записывает цикл исполнения на ОС(опкоды, состояния регистров и т.п).

Ссылку прикладываю:
 
Ну давайте будем считать сладкими вещами эксплуатацию уязвимостей.
Что именно вы хотите выцепить автоматом и как это должно выглядеть?
Ну допустим одна уязвимость базируется на SetWindowLong и вкусное действо происходит гденибудь в explorer.
Другая в хитрой конфигурции структур передаваемых в ядро серией функций Nt...
А третья в какомнибудь COM интерфейсе и все странное случаеться в svchost.
Во первых все интересности случаются не в процессе лоадера, они там только инициируются,
во вторых а как вы следя за процессом лоадера поймете что случилось чтото интересное когда оно случилось в другом процессе или ядре?
в третьих а что вы собственно хотите получить? рисунок апи вызовов? или километры трасировки обфусцированного кода?
Получаеться задача понять что случилось нечто вкусное, а уже имея это понимание начинать нудное разгребательство говна в ручную так сказать от обратного,
тоесть от процесса где вкусное прозошло.
Но перед вкусным скорее всего будет детект пристального наблюдения...выполнение серии операций и замер таймингов.
Вы размышляете об автоматизации процессов которые оч хреново автоматизируются, гораздо проще создать ии который будет клепать бестселлеры в жанре лит рпг =)
Вы обязательно учитываейте что в автоматический анализатор сваливается тонна говна и на эту тонну говна приходиться 1грамм с вкусным а значит пристально наблюдать за каждым граммом не получиться.
Просто подумайте каково это снимать логи со всего ядра..ну потому что шелл может юзать сисколлы и похучить нтдлл не вариант, да и поять же хучить нтдлл это кричать о пристальном наблюдении.
Здесь все как с брутфорсом биткойнов, одновременно и все реально технически и не реально фактически.
Возьмите панду, поставьте старую винду, семпл кого нибудь лоадера который юзает старую уязвимость, +500 неинтересных семплов, соберите эти вкусные логи исполнения опкодов всея ос по каждому из пациентов..
на террабайты дисковго пространства..хотя там пожалуй на каждом пациенте выйдут террабайты и многие сутки.
Короче брутить биткойны гораздо меньше помех чем вкатить в рай на этом чудном мишке.
 
Похоже что вы спросили не вполне понимая суть мною написанного и я распишу подробнее, это может быть полезно кому нибудь.
Итак наш лоадер скачал шеллкод, причем именно шеллкод а не длл, и произошло это на машине где установлена автоматическая система отловли малвари.
Поскольку шеллкод был скачан в зашифрованном виде то дам трафика мало что даст и ведь заранее неясно что это был шеллкод а дампить весь трафик
с пометкой к изучению специалистом явно непродуктивно.
Далее нам нужно поместить расшифрованный шеллкод в память где его можно будет выполнить,
для этого мы можем например загрузить какую то ненужную нам из системных длл и вписать шеллкод поверх ее кода,
а можем без затей аллочить RWX и помещать наш шелл туда.
На этом этапе автоматической системе тоже не понять что есть некий шеллкод который нужно дампить(если она конечно не трассирует лоадер, что врядле).
Далее мы выполняем наш шелл.
И вот когда наш шелл выполняет какую то тревожную апи, автоматическая система может смотреть адрес возврата и если это страница выполнимой памяти не принадлежащая ни одному из модулей
то автоматическая система может дампить все RWX страницы не принадлежащие модулям(все потому что вызов апи может быть сделан через гейт в другой странице).
Но что если гейт расположен в одной из длл, или цепочка таких гейтов, или шелл прописан в ту самую системную длл которую можно оверврайтить?
для определения что этот вызов был из шеллкода придется проверить много всего а это медленно, очень медленно(попробуйте запустить утилиту pc hunter она находит все хуки и патчи но скорость такова что вы сразу поймете почем ав так не делают).
Исходя из вышенаписанного автоматическая система может сделать дамп памяти процесса который ее чем то смутил но вероятность того что специалист сядет копаться в этом дампе выискивая шеллкод минимальна, это кропотливая ручная работа а значит это очень дорого.
Просто внесут в базы экзешник лоадера да и все.
Ковырять взрослый шеллкод который серьезно обфусцирован и морфлен и апи в котором либо по хешам либо сисколлами вам точно не понравиться, 100кб шеллкода можно морфом и обфускацией раздувать до любых объемов и грамотную обфускацию так просто скриптами не вычистить
(cmp [xxxx], xxx jne xxxx - попробуй вычисти такое..может это фейк а может нет, и вот когда весь код так разорван на кусочки то в IDA вам будет пичально), а еще могут быть обфусцированные вм и конечные автоматы =)...короче поймать сам шеллкод не просто а найти основания для его изучения еще сложнее.
Нужно где-то взять пустой кусок памяти, записать в него шеллкод и выполнить его. Это разве не вызовы палевных апи? Все тут понятно и ловится.
 
Нужно где-то взять пустой кусок памяти, записать в него шеллкод и выполнить его. Это разве не вызовы палевных апи? Все тут понятно и ловится.
Ого! От это поворот! А можно список палевных апи которыми вы будете выполнять кусок памяти?...а то мне не все понятно. Жги еще комрад. Аверам рекомендую присмотреться к гражданину Dummy, перспективный и явно ценный кадр.
 
Ого! От это поворот! А можно список палевных апи которыми вы будете выполнять кусок памяти?...а то мне не все понятно. Жги еще комрад. Аверам рекомендую присмотреться к гражданину Dummy, перспективный и явно ценный кадр.
Давайте разберем стандартный случай:
1. Выделение памяти - VirtualAllocEx
2. Запись шеллкода - WriteProcessMemory
3. Исполнение кода - CreateRemoteThread
Хотите сказать не палевные апи? Или аверы инжекты не ловят?
 
оставим глупости, пошлости и последствия алкоголиьной и наркотической интоксикации
и разберем 2 стандарных случая

случай 1 с аллоцированием памяти для шеллкода
аллокация памяти под шеллкод: NtAllocateVirtualMemory PAGE_EXECUTE_READWRITE
копирование шеллкода в память: rep movsb
исполнение шеллкода:
call shell addr
/
jmp shell addr
/
push shell addr
retn

случай 2 с маппингом шелла в какуюто чужую память
NtProtectVirtualMemory PAGE_EXECUTE_READWRITE
копирование шеллкода в память: rep movsb
исполнение шеллкода:
call shell addr
/
jmp shell addr
/
push shell addr
retn

Желание исполнить шелл через создание треда вызывают недоумение.
И совсем не понял причем здесь инжекты?

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

случай 1 с аллоцированием памяти для шеллкода
аллокация памяти под шеллкод: NtAllocateVirtualMemory PAGE_EXECUTE_READWRITE
копирование шеллкода в память: rep movsb
исполнение шеллкода:
call shell addr
/
jmp shell addr
/
push shell addr
retn

случай 2 с маппингом шелла в какуюто чужую память
NtProtectVirtualMemory PAGE_EXECUTE_READWRITE
копирование шеллкода в память: rep movsb
исполнение шеллкода:
call shell addr
/
jmp shell addr
/
push shell addr
retn

Желание исполнить шелл через создание треда вызывают недоумение.
И совсем не понял причем здесь инжекты?

коды для сисколлов можно посмотреть здесь
Вы собрались шеллкод выполнять в контексте собственного процесса? Какой в этом смысл?
Как вы к чужой памяти собрались обращаться, если процессы изолированы друг от друга? Скорее, вы имели ввиду регион памяти, пренадлежащий секции легитимной библиотеки в своем же процессе.
И что мне дадут эти коды сисколов? У всех солидных защитных решений давно есть свой гипервизор, сисколы перехватываются. Детектирование вызова системного сервиса возможно и из юзермода, выполнение инструкции из недоверенного источника.
 
Вы собрались шеллкод выполнять в контексте собственного процесса? Какой в этом смысл?
Как вы к чужой памяти собрались обращаться, если процессы изолированы друг от друга? Скорее, вы имели ввиду регион памяти, пренадлежащий секции легитимной библиотеки в своем же процессе.
И что мне дадут эти коды сисколов? У всех солидных защитных решений давно есть свой гипервизор, сисколы перехватываются. Детектирование вызова системного сервиса возможно и из юзермода, выполнение инструкции из недоверенного источника.
Вы в посте n13 цитировали мой пост n10 и где там речь шла о выполнении шеллкода не в собственном процессе?
В чем смысл расписано было начиная с первого моего поста в топике.
А вот в чем ваш смысл цитировать пост где про инжекты ни слова, писать какие то глупости по инжект шеллкодов, мне не понятно.
А еще что бы заинжектить и выполнить шеллкод в чужом процессе крейт ремот тред не нужен от слова совсем, и даже аллокация не обязательна, достаточно одного лишь врайта.
И да вы несомненно правы, сисколы вам ничего не дадут.
 
оставим глупости, пошлости и последствия алкоголиьной и наркотической интоксикации
и разберем 2 стандарных случая

случай 1 с аллоцированием памяти для шеллкода
аллокация памяти под шеллкод: NtAllocateVirtualMemory PAGE_EXECUTE_READWRITE
копирование шеллкода в память: rep movsb
исполнение шеллкода:
call shell addr
/
jmp shell addr
/
push shell addr
retn

случай 2 с маппингом шелла в какуюто чужую память
NtProtectVirtualMemory PAGE_EXECUTE_READWRITE
копирование шеллкода в память: rep movsb
исполнение шеллкода:
call shell addr
/
jmp shell addr
/
push shell addr
retn

Желание исполнить шелл через создание треда вызывают недоумение.
И совсем не понял причем здесь инжекты?

коды для сисколлов можно посмотреть здесь
Дорогой Whisper(шептун?), у меня назрел вопрос. Зачем нужны таблицы сисколов, если их можно получать в рантайме для текущей загруженной ntdll? Ведь это будет overhead'ом вшивать для каждой версии Windows свою таблицу сисколов. Интересует ваше мнение.

P.S Архитектура с шеллкодом хороша. Мне понравилось.
 
Вы в посте n13 цитировали мой пост n10 и где там речь шла о выполнении шеллкода не в собственном процессе?
В чем смысл расписано было начиная с первого моего поста в топике.
А вот в чем ваш смысл цитировать пост где про инжекты ни слова, писать какие то глупости по инжект шеллкодов, мне не понятно.
А еще что бы заинжектить и выполнить шеллкод в чужом процессе крейт ремот тред не нужен от слова совсем, и даже аллокация не обязательна, достаточно одного лишь врайта.
И да вы несомненно правы, сисколы вам ничего не дадут.
Вы же понимаете, что это заведомо провальная цепочка? Обращение к серверу/выполнение чувствительного кода из ненадежного источника.
Можно без удаленного потока, но экзекутор должен быть, иначе код не будет запущен.
 


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