Хорошо о Component Object Model (COM) на английском: https://www.youtube.com/watch?v=8tjrFm2K30Q
Без понимания COM в безопасности (особенно - в offensive) и в системном программировании под Windows делать нечего.
Кстати, для тех, кто понимает C++, пожалуй, лучшее про COM на русском: Дейл Роджерсон, Основы COM

И вдогонку к предыдущему - как COM используется для закрепления в системе: https://www.youtube.com/watch?v=svFundrBIiQ

Старый, но не бесполезный (с) :)
Хороший разбор старой, но эффективной техники регистрации сервиса через native api: https://www.inversecos.com/2022/03/windows-event-log-evasion-via-native.html

GitLab CVE-2022-1162. Обидная логическая ошибка и большой вопрос к тестированию, аудиту и вообще к SDLC: при регистрации через OmniAuth устанавливался вшитый пароль 123qweQWE!@#000000000

К слову сказать, когда делаем аудит кода, находим разное и ни разу не было так, чтобы даже после тестирования и обкатки клиентом, мы не находили что-нибудь эдакое. Были и посерьёзнее баги. Аудит обязателен!

https://gitlab.com/gitlab-org/gitlab/-/commit/e2fb87ec5d4e235d6b83454980cec9c049849a1c#f4d654b98cc11d931e3f77ee61318adc95a52f12

Нет, сканеры кода не умеют искать логические ошибки. Это кропотливая ручная работа. Равно как и качественный пентест - это далеко не только про сканеры уязвимостей

Не секрет, что в offensive security обфускация нужна для того чтобы сбивать сигнатуры и делать каждый заобфусцированный образец непохожим на другие: из одного источника наплодить много непохожих друг на друга сущностей (бинарей, скриптов, да чего угодно) с одним и тем же функционалом. Однако всё-таки антивирусы умеют каким-то образом относить, казалось бы, совершенно разные образцы к одному классу без всякой эмуляции и прочих песочниц. Как они это делают? Ответ: нечёткие хэши (fuzzy hashes). Нечёткие хэши - это, если одним предложением, такая свёртка от распределения вероятности встречаемости слов (наборов байт в нашем случае). Обфускаторы в 99% случаев используют шаблоны: одной инструкции соответствует несколько других. Плюс, обфускаторы используют, как правило, достаточно ограниченный набор инструкций, что имеет выраженное влияние на статистику встречаемости слов. Получается эдакий вероятностный цифровой след. Т.е. высока вероятность, что все семплы, обработанные конкретным обфускатором, будут иметь очень похожие фаззи хэши: они становятся статистически похожими. Вся нужная теория хорошо гуглится по фразе "fuzzy hashes".
Хорошая библиотека, которая умеет считать фаззи хэши, есть у Trend Micro:
https://github.com/trendmicro/tlsh

Приходящие к нам новички и стажёры всегда спрашивают: "А что бы почитать?" Хорошая математическая база в нашем нелёгком, но увлекательном деле строго необходима. В самом начале пути рекомендуем к прочтению вот эту книгу, где доступным языком изложены азы, на которых строится настоящая, а не бумажная, информационная безопасность: https://www.ozon.ru/product/vvedenie-v-teoriyu-chisel-algoritm-rsa-34351300
Читается легко, знания полезны. Тем, кто так или иначе начинает играться с криптографией и обфускацией, очень полезны. Рекомендуем!
BTW. В электричках, автобусах и прочих метро читается на ура. Сам так делал 15 лет тому назад :)

Антивирусы и прочие 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/