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

Обсуждение принципов прогруза

gribodemon

HDD-drive
Пользователь
Регистрация
12.05.2009
Сообщения
36
Реакции
0
Ну как так? Голимых 15 строк выдают результат в два раза выше чем лоадер!!! Ну где логика?
У меня есть предположение о том, что эксплоеты, входящие в состав связки, могут:
1.) Крэшить приложение, в АП которого они работают;
2.) Приводить к зависанию этого приложения (при использовании JIT-Spray'я, например); При этом, если это то приложение, с которым напрямую работает пользователь, то высока вероятность его закрытия;

Эти два фактора означают что чем меньше времени будет затрачено на скачивание payload-exe'шника из сети, тем выше будет отстук.

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

Размер обычного трояна + крипт (с нормализацией энтропии, как это обычно и делается) == ~120KB

Размер "стукача", наверно, ~1-2KB.

Я думаю, имеет смысл произвести след. эксперимент: "стукача" превратить в мини-лоадер (Добавить вызов CreateProcess() в код), который будет грузить основной exe (в данном случае, НЕmyLoader).

Думается мне, что таким образом удастся увеличить отстук любого подгружаемого софта. :D

P.S.: Так же, я испытываю негодование по поводу того, что в современных связках до сих пор нет шеллкодов со встроенными PE-лоадерами.
Т.е. всё-таки, тот же инжект в explorer из пробитого браузера всё-же будет намного менее палевен, чем запуск какого-то exe'шника из temp-диры тем же приложением (с точки зрения проактивных защит).

===

Кроме этого, существует фактор, снижающий отстук любого криптуемого софта.
И зависит он, от технологий, которые используются в крипторе.
Например, детект виртуальных машин и sandbox'ов.
Т.е. при минимальных условиях палевности (отсутствие AV & firewall'ов) отстук некриптованного "стукача" будет выше, чем у "криптованного" троя как раз по вышеописанной причине.
А в обзоре как раз ничего не было сказано о технологиях, используемых в крипторах.
 
P.S.: Так же, я испытываю негодование по поводу того, что в современных связках до сих пор нет шеллкодов со встроенными PE-лоадерами.
Т.е. всё-таки, тот же инжект в explorer из пробитого браузера всё-же будет намного менее палевен, чем запуск какого-то exe'шника из temp-диры тем же приложением (с точки зрения проактивных защит).
У карабаса уже есть готовое решение, которое с песком продирается в некоторые связки, конечно если уделять этому больше внимания, то и на минимальном наборе сплойтов можно получать результаты ВЫШЕ, гораздо выше чем на супернавороченных мегапаках :)
И размер кода тут все таки играет не такую уж и важную роль.
Приведу пример. Вот допустим если шелл пробитого ишака будет "качать" пэйлоад на тачку жертвы не через URLDownloadToFile, а используя "родное" апи, в частности wininet, то спалить такой шелл в адресном пространстве будет более чем сложно, при этом иметь обход всевозможных файеров, работающих на более низком уровне, чем разрешение доступа к сети софту по пути к исполняемому файлу :).

Подведу итог сказанному небольшой. Без тесного сотрудничества кодера связки и кодера лоадера толковых вещей вы никогда не получите. Связка должна работать как единый организм с модулем загрузчика, вплоть до принятия в качестве сигнлизации успешно пробитого браузера - отстука лоадера в админку.
 
Хотел бы провести подобные тесты при разных размерах стукача: 1) 5 кб 2) 40 кб 3) 100 кб
без проблем могу предоставить подобных стукачей + минискрипт. И наконец-то можно было бы получить ответ - имеет ли размер значение...

P.S.: Так же, я испытываю негодование по поводу того, что в современных связках до сих пор нет шеллкодов со встроенными PE-лоадерами.
Т.е. всё-таки, тот же инжект в explorer из пробитого браузера всё-же будет намного менее палевен, чем запуск какого-то exe'шника из temp-диры тем же приложением (с точки зрения проактивных защит).
все дело в том что некоторые эксплойты не используют шеллкод для пробива, а непосредственно выполняют через скрипты скачку+запуск екзешника, но, мне кажется, их доля не так уж велика. Но авторы связок, не особо переполнены оптимизмом что-либо менять или просто не понимают ценность этого , а те кто понял щас сливают сливки. Или просто рынок покамись не особо требует этого от них. По крайней мере можно было предусмотерть возможность сделать отдельно шеллкод который будет скачивать другой - свой шеллкод и выполнять его. Я когда еще выставлял первую версию своего лоадера - предусмотрел возможность использования его через связку - DownloadDll + LoadLibrary, но сколько людей ни стучало - никто ни разу не заикнулся про это фичу.

И зависит он, от технологий, которые используются в крипторе.
Например, детект виртуальных машин и sandbox'ов.
Т.е. при минимальных условиях палевности (отсутствие AV & firewall'ов) отстук некриптованного "стукача" будет выше, чем у "криптованного" троя как раз по вышеописанной причине.
не вижу проблем если все сделано очень корректно, хотя опять же все нужно проверять на тестах
 
Подведу итог сказанному небольшой. Без тесного сотрудничества кодера связки и кодера лоадера толковых вещей вы никогда не получите. Связка должна работать как единый организм с модулем загрузчика, вплоть до принятия в качестве сигнлизации успешно пробитого браузера - отстука лоадера в админку.
согласен,но чем больше людей, у которых разные цели, втянуто в сотрудничество - тем меньше вероятность, что что-нибудь получиться...Покамись на данном этапе, если бы в связках была доп фича - загрузка и запуск другого шеллкода , я думаю можно было бы избежать подобного коммунизма :)
 
gribodemon
А в обзоре как раз ничего не было сказано о технологиях, используемых в крипторах.
Так обзор-то и не по крипторам был, а по лоадеру. Если рассматривать все вами описанные вопросы - это надо садиться и делать очень серьезное исследование. И, замечу, очень затратное по деньгам и времени. А я все делаю на чистом энтузиазме.
Хотя вопросы вы подняли правильные.
 
karabas-barabas
Хотел бы провести подобные тесты при разных размерах стукача: 1) 5 кб 2) 40 кб 3) 100 кб
без проблем могу предоставить подобных стукачей + минискрипт. И наконец-то можно было бы получить ответ - имеет ли размер значение...
С меня - связка (Phoenix 2.4) и трафф.
С тебя - стукачи и стата.
Если интересно - стучи в icq: 457-11-22.
 
Зависимость отстука от размера EXE.

Покупался IFRAME MIX трафф по 5k и гнался на связку Phoenix 2.4.

Всего было 4 "стукача", разных размеров: 7KB, 45KB, 98.5KB и 165.5KB, особо не палящихся.

Результаты следующие:

1286736853-clip-14kb.png


Т.е., в среднем, между большим и малым EXE'шником - 6.5%.

Вывод: чем меньше размер подгружаемого EXE'шника, тем лучше отстук.
Конечно, я ожидал увидеть бОльшую разницу, но, 6.5% отстука - тоже, неплохой результат.

Размышления по теме:
Было бы намного лучше, если бы шеллкод эксплоета инжектился в какой-нибудь процесс, перед скачиванием EXE'шника. Т.е. я думаю, что основная причина падения отстука при увеличении размера EXE'шника заключается в том, что или используемые эксплоеты крэшат браузер, либо высока вероятность того, что пользователь просто закрывает браузер или его вкладку (в случае с Chrome, вкладка - это отдельный процесс).



Детальная инфа по тестированию тут и сами стукачи с дампами статы тут.


===

Да, и ещё:

Test3
Не понравилось мне что отстук со связки, оказался в районе 42%. Решил опять стукачом проверить все.
Ставлю для сравнения на связку стукача.

отгружено со связки: 108
Отстучалось в стату: 94
Отстук: 87%

Не было такого. Отстука в 87%. И причина заключается в том, что в стате, которую мне выдали, присудствовали дубли.
Собственно, при учёте отстука, я эти дубли поудалял. И, в самом хорошем варианте, отстук получился порядка 78%.
 
спасибо gribodemonу за то что помог провести исследование , честно говоря я тоже думал, что размер имеет большое значение , но разница между 7 kb и 165 кб составила 5% , отсюда вывод, что если размер имеет значение - то не такое фантастическое как некоторые думали , даже очень несущественное , хотя тут все факторы также невозможно учесть - например проактивки на екзе с разером в 7кб и размером 165 кб по разному смотрят.
 
хотя тут все факторы также невозможно учесть - например проактивки на екзе с разером в 7кб и размером 165 кб по разному смотрят.
Ох, не думаю я, что проактивки обращают какое-то внимание на размер exe.
По сути, они работают в ring0. И оттуда мониторят за тем, как работают такие сущности как потоки и процессы.

Да и вообще - если бы, обращали, то ... вряд ли они связывали бы такие вещи как размер exe и процесс, "рождённый" от этого exe, который ломится в сеть.
 
но разница между 7 kb и 165 кб составила 5%  ... , даже очень несущественное
5%?
Только не в случае, если трафф стоит 30$ за 1k, например.
Т.е. на 1k ботов теряется где-то 15$. =/
Если объёмы большие, то это ппц. =/
 
gribodemon
Не было такого. Отстука в 87%. И причина заключается в том, что в стате, которую мне выдали, присудствовали дубли.

Ну вы меня за тормоза не держите. В моих тестах тоже присутствовали дубли. Я их вырезал утилиткой Fast_Duplicates_Remover_v0.1.

:zns5: Скачать|Download

p.s. data.txt у меня так же сохранились. Могу для подтверждения выложить.
 
Ребята, моеё ИМХО в том, что размер имеет значение только на медленных линках у юзеров, а так.. не очень существенное...
Более актуально то, что сплойты крашат браузер и инжект шелла в другой, более стабильный процесс (например в проводника) может реально повысить отстук. На крайняк почему бы и не создавать новый процесс по всем правилам? Ведь он проживет не долго и наврядли кто то будет на него обращать особое внимание. Зато честное создание процесса не так сильно будет палиться...
 
инжект шелла в другой более стабильный процесс (например в проводника) может реально повысить отстук
хм на такое никто не пойдет ибо шеллкодес вырастет как на дрожжах, это нужно будет в шеллкодесе добавить около дестяка новых апишек и еще доп кода например по перебору процессов и получения pida. Классический шеллкод это 1) получение базы kernel32 2) своя GetProcAdress 3) реализация GetModuleHandle/loadLibrary urlmon 4) UrlDownloadTofile + WinExec/ShellExecute/Createprocess. Самый простой выход это подгрузка либы со связки или подгрузка доп шеллкода
 
Самый простой выход это подгрузка либы со связки или подгрузка доп шеллкода
Ну вот собственно о том и речь чтобы подгружать как то лоадер более интегрированный со связкой.
 
Ну вот собственно о том и речь чтобы подгружать как то лоадер более интегрированный со связкой.
Цитаты автора Phoenix'а:

!alexdudakov (19:19:56 10/10/2010)
вся ява которая щас в связке есть-на повышение привелегий 

!alexdudakov (19:20:03 10/10/2010)
т.е. браузер она не крешит 

!alexdudakov (19:20:15 10/10/2010)
тупо качает экзе в темп и запускает его своими силами 

gribodemon (19:20:36 10/10/2010)
Тогда, именно с помощью чего она качает ?

!alexdudakov (19:20:49 10/10/2010)
с помощью втроенных функций работы с файлами 

!alexdudakov (19:21:53 10/10/2010)
как я думаю палятся именно вызовы этих функций проактивками 

!alexdudakov (19:22:09 10/10/2010)
единственная ява которая раньше присутствовала с шеллкодом - java gsb 

Т.е. это означает, что ... возможно, основная причина падения отстука при увеличении размера exe в том, что JAVA сплоеты, испольуемые в связке, "барахлят". =)
По идее, по IP адресу можно было сравнить и идентифицировать пробитые машины. Млин. Жаль базу Phoenix'а потёр со пробивом ...

Надо всё по-новой делать, чтобы сказать в чём точно дело -- в шеллкоде сплоетов или в особенностях JAVA сплоетов ... :D
 
хм интересно , но до конца не ясно что ты этим хотел сказать.
Получается, если связка показывает одно число лоадов - то на самом деле их может быть гораздо меньше, т.к. java-функи блочатся и екзе так и не успевает запуститься ?
 
Хорошо, допустим тот же ишак запущен в своей песочнице, как тогда ява сможет подгрузить файл "куда надо" и исполнить его? Это актуально для вислы и 7...
 


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