Хорошо о 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/

Про трэкеры в письмах немножко. Фишка весьма известная, но не всем 🙂
Обычный 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/