Для авера одна и та же суть, вредоносное поведение выполняется в легитимном подписанном процессе. И опять же от поведения зависит. Та же история может быть с COM-хайджекингом или TypeLib-хайджекингом. В общем случае обход рантайм детектов обфускацией там, чисткой сигнатур или елочками не сделать, потому, что детект происходит по поведению левого неподписанного процесса.
Как раз таки нет, авер намного лояльнее относится к тому же поведению в подписанном процессе. Хочешь реальный кейс, который легко воспроизвести - ок, повершелл. Исполни один и тот же код в его контексте и вне его контекста, результаты удивят.
Блет, а я тебе о чем говорю, внимательно читай.
это ошибочное мнение сигнатуры не только скантайм но и рантайм проверяются
все довольно просто как ты думаешь))) да елочками не отделаться тут)) если как ты говоришь что рантайм обойти вообще не реально то тогда как же его обходят та по твоему ты ведь говоришь что не обойти но по факту та ты не прав рантайм обойти можно и мне похуй на твои елочки и так далее просто нельзя делать поспешные выводы. Я знаю ты молодец написал много интересных статей за это + тебе
Бремя доказательства лежит на том, кто доказывает, а не на том, кто отрицает. Это еще в римском праве было прописано. Я говорю о том, что в общем случае невозможно обойти рантайм детект с помощью обфускации. В частном случае может быть все, что угодно. Тот же предметный авер может быть неправильно сконфигурирован, или просто быть гавном. Статьи про рансомварщиков если почитать, то можно заметить, что весь их "пентест с постоплатой" строиться на таких частных случаях.
А Вообще какие есть пути обхода проактивного скана кроме SLEEP. то что обфускацией обойти рантайм скан то как его вообще обходить переписывать сорцы для каждого ав проактивки ?
Зависит от авера и от того, что ты хочешь сделать. Я писал уже первом сообщении тут. Для каких-то из них может хватить анхуков или вызова сисколлов, вместо апи функций. Инжект в легитимный процесс (если сам не спалиться) может помочь, так как многие аверы относятся поспокойнее к подписанным процессам операционной системы (ну ладно, ладно, еще к этому можно отнести dll/com/typelib хайджекинги, не орите). Запуск бесфайлого - код в технически легитимном процессе (хотя я бы на месте аверов куда пристальнее смотрел на powershell и mshta) и на файловой системе его нет - аверу может быть не понятно, что палить. Если это в принципе возможно, то можно попробовать распределить малварь на отдельные процессы: образно, один процесс выделяет память для инжекта, второй записывает нагрузку в эту память, третий создает удаленный поток. Возможно, что проактивка авера не осознает, что все три процесса вредоносные. Всякие процесс холловинги для лоудеров могут чем-то помочь, в частности создание нового процесса через секцию, когда авер в ядре получит оповещение о попытке запуска нового процесса, исполняемого файла этого процесса уже не будет на NTFS-файловой системе. Ну придумать что-то можно почти всегда, но это все будут частные случаи.
Давай вкратце. Всратая проактивка: заинжектит в твой процесс длл или шелл, перехватит апи функции и будет сидеть и мониторить, какие функции твоя малварь вызывает. Более менее нормальная: будет сидеть в ядре и анализировать события с помощью коллбеков, ну и/или сидеть и анализировать ETW-события (для примера, насколько я помню procmon делает также). Убер проактивка: будет сидеть на уровне гипервизора и хер ты ее обойдешь даже из ядра (я хз, существуют ли такие в природе сейчас, одно время Касперский себя тапком в грудь бил за это, но что-то давно уже ничего об этом не слышал).
---
---https://xss.pro/threads/62594/ ----
--Идея витает в воздухе, согласен. Но чё-та я не слышал ни об одном ВПО, которое действует таким образом. Возможно, проблема в синхронизации, раз до сих пор нет подобного решения на рынке?
Ну я не вижу проблем организовать синхронизацию. Помимо того, что ты сказал можно оконные сообщения использовать или DCOM.
Я в это не вникал особо, я в ядре не шарю, но то, что у Касперского неплохая проактивка - это факт. Как минимум, как я говорил уже тут, она умеет строить трассы взаимодействия процессов и вычислять вредоносные удаленные потоки, что довольно клевая фича.
Вроде да, проблем нет в синхронизации. Но и продуктов нет!
Наверное, кто-то что-то знает... Опять же, как предположение: на подобное поведение проще детект повесить.Эту тему исследовать можно, но я скажу честно дальше довольно поверхностного статического анализа и прочтения парочки пеперов не ушел. Поверхность атаки однозначно имеется, можно написать логгер и посмотреть что передается в параметрах KseInitialize->KseKasperskyInitialize->KseRegisterShim->KseRegisterShimEx, потом пореверсить что аргументы могут значить, это все андок. Как минимум драйвер каспера потенциально может хукать в ядре memmove (такой шим имеется) и анализировать память, правда вопрос насколько это сказывается на производительности и оправдано ли вообще.
Так и есть, ведь программа (и проактивка) нематериальна. Надо понять, что заставляет божество прогневаться. Например, если calc.exe, получает хендл файла pussycat.jpg, это уже подозрительно - зачем калькулятору такая картинка? Если calc.exe после открытия файла его читает, то это не добавляет подозрений - логично, что файл открывали для чтения и пока ничего страшного не случилось. А вот если после этого происходит запись, да ещё первые байты отличаются от FF D8 FF - это явно ахтунг, поскольку расширение jpg подразумевает формат содержимого JFIF, а не что попало. Надо тормозить поток и сообщить пользователю, что он подвергся хеккерной атаке. Наиболее продвинутое божество проверит, запущена ли VisualStudio, не находится ли calc.exe в папочке bin/Debug, и отправит товарищу майору телеметрию, а "пользователю" покажет сообщение, что он нуб и опозорился.
Интересно, как было определено время? Половинным делением (сначала час, потом полчаса, потом 45)? Откуда разработчики взяли именно 45 мы вряд ли узнаем.
Как я помню, джанк помогает только в скантайме, рантайму похуй
Когда мы видим рядом слова "итерации" и "виртуальная машина", надо полагать, речь идёт о следующем (упрощённо) цикле: сначала читается байт исполняемого файла, после чего следует switch на 38 страниц. Таким образом происходит исполнение команд IA32 или AMD64 без запуска, одним словом - эмуляция. Такая штука может раскрутить простейший "криптор" и просканировать результат на наличие сигнатур. Понятно, что бесконечно долго она работать не может, потому есть предел. После которого может начаться собственно исполнение. Runtime детекты возможны начиная с этого момента - это так по определению (и если какой-то антивирус при клике на экзешник тормозит его основной поток и начинает производить вышеописанное - возникает вопрос - о чём он раньше думал?)
если же вместо запуска в песочнице ничего страшного не произошло за 45 минут, процесс маркируется как белый и пушистый - это понятно. При чём тут итерации - не очень понятно. Кстати при статическом анализе Sleep(45000) выглядит малость подозрительно, а вот при исполнении сложнее, т.к. не ясно, откуда такое большое число взялось.
