Антивирусы и прочие EDR (те же антивирусы, но в профиль) жить не могут без того чтобы не наставить хуков (user mode hooks) 💩 на вызовы native api (да и не только там). Обходится это самостоятельным вызовом syscalls. Но, как всегда, есть нюанс: индексы системных вызовов могут меняться от сборки к сборке Windows. Где-то эти индексы хардкодятся, где-то просто читается ntdll с диска и в ней по сигнатурам ищется необходимый индекс. В общем, вот интересная статья про это с не менее интересными ссылками внутри: https://www.mdsec.co.uk/2022/01/edr-parallel-asis-through-analysis/

Лонгрид о многим известной атаке "человек посередине" (Man-In-The-Middle или, сокращённо, MITM). Про то, что это такое и как реализуется, можно прочитать примерно везде, поэтому смысла объяснять математику нет.

Однако стоит отметить, что эту атаку используют как плохие парни, так и хорошие. Плохие парни MITM-ят, чтобы получить credentials пользователей и напихать в трафик своего контента, хорошие - чтобы бороться со злом (а не примкнуть к нему 😜 ). MITM используют, например, DLP-системы для анализа трафика. А ещё MITM нередко используют антивирусы.

А теперь следим за руками: раз антивирус ставится на ПК пользователя (endpoint) и MITM-ит там же, то где-то на этой же тачке лежит и закрытый ключ! Сертификат открытого ключа находится, понятно, в хранилище доверенных сертификатов. Антивирус туда его сам же и инсталлирует. А закрытый ключ, по идее, должен быть спрятан, заобфусцирован, пошифрован, прибит гвоздями и охраняться солдатом с ружьём, потому что, если он утечёт, то злоумышленник может подписывать им сертификат любого сайта и этой подписи система будет доверять!

И здесь самое интересное! Мы исследовали несколько антивирусов и вот что мы обнаружили, например, у Avast:
1. certutil -repairstore root <serial number>
2. Экспорт сертификата с приватным ключом в pfx с помощью certmgr
3. С помощью openssl вытаскиваем приватный ключ
4. Подписываем сгенерированный нами же сертификат для, например, happy_bank.ru извлечённым в п.3 приватным ключом
5. Модифицируем hosts, чтобы перенаправить запрос к happy_bank.ru на наш IP-адрес. На модификацию hosts Avast почему-то тоже не среагировал :)
6. Profit! Если пользователь идёт на happy_bank.ru, то попадает к нам и в браузере зелёный замочек при полностью включенной защите.

Ну и понятно, что так можно подписать сертифкат от любого ресурса: MITM поверх MITM-а, получается. Получение pfx при этом только штатными средствами, что потрясающе!

Avast на это нам ответил, что не считает это проблемой. Ну ок. Зато там есть майнер! 😜

Напрашиваются следующие очевидные выводы и вопросы:
1. Если реализуешь MITM, то логично проверять, что прилетающий серт не подписан тобой же, потому что такого не должно быть.
2. Приватный ключ нужно защищать лучше, чем ... никак
3. Зачем вообще MITM на endpoint-е?

Кстати, исследование под нашим чутким руководством проводит наш замечательный студент-стажёр из Калужской Бауманки - Максим Гейко.

Исследование продолжается. Оставайтесь с нами!

Многие ИБ-решения для защиты конечных точек (антивирусы, HIPS и т.п.) так или иначе используют whitelisting - реализацию техники защиты "что не разрешено, то запрещено". Т.е. есть список разрешённых приложений, DLL, скриптов (белый список), которым на хосте выполняться можно. Выполнение остальных либо блокируется, либо выдаётся уведомление, либо генерируется событие о подозрительном действии. Списки такие составлять долго и муторно, плюс, можно ошибиться и уронить систему. Сами так делали не раз 😜 Поэтому, как правило, ограничиваются фильтрами по наличию и корректности подписи Authenticode, плюс, фильтруют по издателю.
И всё было бы хорошо (как любят нам рассказывать производители Endpoint-защит), если бы не было так плохо 😉
В той же Windows существует масса входящих в поставку приложений, библиотек и скриптов, с помощью которых можно выполнять нужные действия - whitelisting bypass.
А вот и актуальный списочек: https://github.com/LOLBAS-Project/LOLBAS

Хорошая шпаргалка для пентестеров и прочих аудиторов Windows-систем: https://casvancooten.com/posts/2020/11/windows-active-directory-exploitation-cheat-sheet-and-command-reference/

Про трэкеры в письмах немножко. Фишка весьма известная, но не всем 🙂
Обычный e-mail может содержать однопиксельное изображение, которое в автоматическом режиме загружается клиентом электронной почты (переход по ссылке из параметра src тэга img). Например,
<img alt='' style='display: none' src='https://adverts.com?id=123'/>
В таком виде изображение не видно при прочтении письма, но парсер почтового клиента видит ссылку src и осуществляет переход по ней. Остаётся зафиксировать время перехода и дополнительную инфу о поьзователе: IP-адрес, страну, почтового клиента, всякое интересное в headers. В общем, эта техника позволяет узнать, открыл ли письмо получатель и узнать о нём что-то. Этим трюком часто злоупотребляют рекламщики и прочие фишеры (ищем слово gophish в поисковике - этот фреймворк так умеет).
К счастью, крупные сервисы типа Яндекса и подобных самостоятельно парсят сообщения на предмет изображений, попросту "забирая" их себе и пережимая, чтобы в итоге отдать пользователю ссылку на себя, а не на ресурс отправителя. Пользователям веб-клиента, в принципе, можно выдохнуть (а потом сразу же вдохнуть, ибо всегда надо быть начеку 😜). Ну а пользователем "толстых" почтовых клиентов (типа всяких The Bat и подобных) в любом случае стоит позаботиться о том, чтобы автоматическая загрузка изображений была отключена. Сответствующую настройку можно найти во всех почтовых клиентах.

Хороший материал про Active Directory: https://rootdse.org/categories/active-directory/

Забавное вспомнилось. Серьёзная криптографическая конференция. Слушатели и участники - преимущественно математики, криптографы, ИБ-специалисты, инженеры. Коммерческий доклад. Выступает бойкий российский представитель западной антивирусной компании: "Число вирусных угроз выросло экспоненциально!".
Оратор делает картинную паузу и многозначительно обводит тревожным взглядом аудиторию. Далее поясняет: "Т.е. не НА сколько, а ВО сколько!"
Потом было не очень интересно :)

Хороший совершенно бесплатный вводный курс в современную криптографию: https://intensecrypto.org/public/index.html
Боаз Барак - математик, знаменитый прежде всего тем, что в одной из своих работ доказал, что blackbox-обфускация в общем случае невозможна, чем индуцировал некоторый шум в профессиональном сообществе. Обфускация - запутывание кода и данных. Black box - чёрный ящик. Анализировать черный ящик можно только по входам и выходам. Так вот - Боаз Барак доказал, что нельзя запутать любую программу так, чтобы изучение её запутанного кода давало информацию большую, чем изучение её входов и выходов.
Если очень грубо свести то самое доказательство к одному предложению: нельзя запутать программу, которая выводит свой исходный текст на экран, например.
Курс лекций действительно интересный

Добавили комментарии

Хороший список статей (и не менее хороший блог про offensive security) про использование Windows Management Instrumentation (WMI) в offensive-целях: https://0xinfection.github.io/posts/wmi-basics-part-1/

Потрясающее описание свеженьких уязвимостей CVE-2022-25165 и CVE-2022-25166 в AWS VPN Client
Обе ошибки логические. Первая связана с гонками (race condition), вторая с путями UNC, которые мы тоже очень любим :)
Подобного рода ошибки не найдёт никакой сканер кода. Только ручной аудит

https://rhinosecuritylabs.com/aws/cve-2022-25165-aws-vpn-client/

В Windows есть такая замечательная штука - Antimalware Scan Interface (AMSI). Используется антивирусами для анализа поведения PowerShell-скриптов, например. Подробнее, что это за технология и как это обходится (спойлер: dll-ка в user mode 😉) можно почитать, например, здесь: https://www.hackingarticles.in/a-detailed-guide-on-amsi-bypass/

Пара слов про эвристический анализ исполняемых файлов. Про нечёткие хэши я уже говорил ранее: https://t.me/recryptor/9. Очень важным показателем является информационная энтропия по Шеннону. Что это такое и как её считать - скажет поисковик, но одним предложением можно сказать, что это мера случайности информации. Измеряется она в битах. Максимальное значение - 8 бит. Если энтропия исполняемого файла или весомой его части (например, секции) близка к максимальному значению, это значит, что применялось либо сжатие, либо шифрование. Но, как правило, исполняемые файлы не могут иметь сильно высокой энтропии и, если она всё-таки высока, то это, как минимум, подозрительно, о чём эвристик антивируса заботливо проинформирует, уложив параллельно файлик в карантин. Именно поэтому прежде всего антивирусы крайне болезненно реагируют на защищённый протекторами софт.
Если хочется иметь поменьше проблем с ложноположительными реакциями антивирусов (false positives), но при этом страсть как неймётся что-то пошифровать, можно "сбить" энтропию. Для этого каждому байту зашифрованного массива ставится в соответствие какой-то уникальный набор байт (назовём его словом). Происходит замена байтов на слова. Исходный массив в результате распухнет, но энтропия упадёт. Перед расшифрованием просто применим обратное преобразование: заменим слова на байты. Ну а потом уже можно расшифровывать. Ложноположительных реакций станет меньше, но они всё равно будут :) Я позже расскажу почему ;)

Ещё одна очень хорошая книга по криптографии, а именно - по математике, которая лежит в основе криптографических алгоритмов: https://link.springer.com/book/10.1007/978-0-387-77993-5

Достаточно глубоко и при этом в доступной форме рассматриваются подходы как к созданию шифров, так и к криптоанализу с использованием решёток. Например, после прочтения станет понятно, в чём архитектурная уязвимость криптосистемы, основанной на задаче о рюкзаке с использованием гипервозрастающей последовательности. Хорошо описан алгоритм редукции базиса решётки LLL, часто используемый в криптоанализе (в том числе и RSA) и предпосылки к его созданию. Ну и криптосистемы на базе решёток, включая NTRU, рассмотрены достаточно хорошо.
Очень рекомендую!

Очередной метод инжекта DLL в другой процесс: https://www.x86matthew.com/view_post?id=import_dll_injection
Оригинальность в модификации IAT вместо запуска удалённых потоков. При загрузке этой DLL отработает PloadImageNotifyRoutine. Плюс, подозрителен запуск процесса с флагом CREATE_SUSPENDED. А так - интересная и даже оригинальная вариация на тему

Про защиту от роботов. Я сейчас не про терминатора или капчу с выбором автобусов на картинках 🙂 Я говорю про детект автоматических сканеров/скрэпперов/утилит для осуществления автоматических запросов к веб-ресурсам. Прошло то время, когда безнаказанно можно было собирать информацию с ресурсов или же осуществлять автоматизацию работы, например, по сбору цен из интернет-магазинов. Сейчас на страже веба стоят антибот-системы. Антибот-системы - это проблема, на самом деле, большинства защитных систем, заявляющих, что у них реализован DPI с использованием SSL-MITM. Причём они могут работать совершенно по-разному: могут вообще не давать использовать обычную версию сайта, а могут отдавать совершенно другое - что-то, например, заобфусцированное, чтобы помешать боту получать информацию со страницы. Рассмотрим каждый из этих вариантов. В первом случае очень известна антибот-система (здесь должно быть название, но мы в последний момент решили его убрать, поэтому назовём просто - XXX), которая отслеживает автоматические системы и блокирует (на самом деле нет 🙂 ) использование ресурса. Строго говоря, она, определяя бота, отдаёт javascript-код, который должен подтвердить догадки системы. В общем случае Антибот неким образом определяет, человек перед ним или нет (и даже смена/установка User-Agent не помогает). И мы бы были не мы (момент рекламы: проводим качественный глубокий аудит безопасности ваших проектов и помогаем решать всякие умные задачки 😉 https://re-crypt.com ), если бы не разобрались, как же эта система работает 🙂 На самом деле, выдать бота может не только User-Agent, но и просто состав Client Hello части установления SSL/TLS соединения. В данном случае разработчики XXX собрали некоторое количество отпечатков (fingerprint) современных браузеров и, получая запрос от клиента, определяли версию по User-Agent, а дальше просто сравнивали то, что пришло, с тем, что у них имелось. В состав fingerprint вошли такие параметры как: минимальная и максимальная поддерживаемая версия TLS, используемые алгоритмы шифрования, включаемые расширения. В итоге, если клиент сможет жонглировать этими параметрами, появляется возможность полноценно представиться взрослым браузером и избежать детекта Антибот-системы. Про второй случай расскажем несколько позже, подписывайтесь и включайте оповещения, чтобы не пропустить следующий пост.
P.S. Кстати, для разработчиков на Go есть прекрасная библиотека, которая обладает очень широкими возможностями по взаимодействию с Client Hello:
https://github.com/refraction-networking/utls

С антивирусом AVG то же самое :)
https://t.me/recryptor/12

Видео с OffensiveCon 2022. Налетай ;)
https://youtube.com/playlist?list=PLYvhPWR_XYJnPvrhXE4RYvwZhV26nYTIp

Про защиту .Net-сборок от компьютерного пиратства (протекторы .Net) и ложноположительные реакции антивирусов пара слов. Принцип работы эвристика антивирусного движка на самом деле имеет много общего с антибот-системами, о которых говорилось выше: https://t.me/recryptor/26
Если .Net-сборка была модифицирована или создана с использованием стороннего инструментария, то ряд антивирусов может на это нервно реагировать. Просто структура выходного файла, собранного с помощью компилятора от Microsoft, отличается от выходного файла, обработанного тем же ConfuserEx, использующим dnlib, без применения какой-либо обфускации, шифрования и т.д. Просто две практически пустые сборки имеют лёгкие отличия в своей структуре: в порядке следования секций и т.п. При этом дизассемблированный код обеих сборок идентичен с точностью до метаданных.
Лечится компиляцией сборок с использованием средств Microsoft
BTW. Речь не о водяных знаках, конечно

Лонгрид про NGAV и ошибки антивирусов при классификации софта. Один движок, например, считает все пустые .Net-сборки для платформы x86 подозрительными. Другой нервно реагирует на используемые обычным приложением функции. Порой, бывают совершенно немыслимые ляпы и реакции на сочетание совершенно немыслимых признаков, которые объяснить человеческой логикой попросту невозможно. Ответ кроется в том, что это на самом деле не человеческая логика.

В последние годы популярной стала аббревиатура NGAV (Next Generation Antivirus). Всё, что цепляет на себя эту бирку, гордо заявляет об использовании ИИ-технологий для выявления угроз. Это стильно, модно, молодёжно, звучит технологично и малопонятно, иногда реагирует на файлики. В общем, всё, что нужно, чтобы это продавать 😜

Что там под капотом на самом деле, хорошо описывает книга Introduction to Artificial Intelligence for security professionals от команды датасатанистов специалистов по Data Science из Cylance. Да и не только она. Есть масса статей про использование ИИ для классификации малвари. Суть всех этих подходов в том, что берётся большой размеченный датасет малвари (например, датасет от Sophos: https://ai.sophos.com/2020/12/14/sophos-reversinglabs-sorel-20-million-sample-malware-dataset/), в дополнение к нему берётся датасет нормального софта, выбираются признаки вручную (чаще всего) либо автоматически (есть работы по feature selection), эти признаки выдёргиваются из каждого исполняемого файла и происходит обучение некого ИИ-движка.

Признаками часто являются: энтропия файла и его частей, размеры и именование секций, целевая платформа, содержание ресурсов, импортируемые функции, наличие и распределение релокаций, наличие специфических строк, наличие сигнатур криптоалгоритмов, наличие и валидность подписи Authenticode, издатель. В общем, берём поисковик, фразу malware classification ML и наслаждаемся.

Плюсы тут очевидны: дёшево и сердито получается эвристический движок, который будет реагировать на любые аномально выглядящие файлики на ПК. А т.к. создатели малвари часто используют крипторы и обфускаторы для сокрытия сигнатур, этот эвристический движок имеет неплохие шансы такую обработанную малварь всё-таки обнаружить. Т.е. супер-дёшево удаётся существенно повысить detection rate. Ну и вообще не нужны тонны вирусных аналитиков: их заменит небольшая команда специалистов по Data Science, которая создаст наборы классификаторов для статической структуры, для трафика, поведения и т.д.

Но есть нюансы. Полноценный антивирус работает, как правило, на локальной машине пользователя, а это значит, что засунуть туда полноценную нейронку не получится. Поэтому в этом случае речь идёт не о Deep Learning, а о Machine Learning. Часто используются решающие деревья и случайный лес (Random Forest). Да и признаки файла должны легко извлекаться и подсчитываться, что тоже не прибавляет точности. В результате мы получаем что-то типа overfitting-а (слово "переобучение" мне не нравится здесь). И тут начинаются фокусы с ложноположительными реакциями. Я даже не говорю про всякого рода протекторы для защиты софта от пиратства. Они для любого антивируса, как красная тряпка, ибо то, что ими обработано, выглядит крайне аномально. Речь о совершенно безобидных программах, на которые антивирус начинает, внезапно, нервно реагировать. При этом банальная смена опции компиляции и сборки может эту реакцию убрать (зато начнёт реагировать другой антивирус 😜). То же самое и про ИИ-анализ поведения.

Что из этого следует... Да в общем - ничего особенного 😁 Все стараются экономить и ИИ - это, несмотря на заверения продавцов, в первую очередь про экономию, а не про качество. Достаточно поглядеть, сколько NGAV развелось за последние лет 5 - 7. При этом малвари тоже меньше не становится и способы обхода NGAV-движков известны: https://www.youtube.com/watch?v=RhB6Sqz-eLw

#почитать #антивирус

Задорная картинка к предыдущему посту :)