Сегодня, 29 мая, день рождения у моего школьного друга, Алексея Таранцева. Со времен школы Алексей был творческой личностью, свою песню, которую я предлагаю вашему вниманию, Алексей написал еще в 11-м классе, я прекрасно помню, как весной наш класс был дежурным по школе, мы стояли на центральной лестнице, и Леша дорабатывал текст.

Музыкально здесь можно услышать влияние Deep Purple, Led Zeppelin и, конечно, The Beatles (я действительно учил английский по текстам полюбившихся групп, в то время английский я выучил бы только за то, что на нем разговаривал Леннон).
Почти всю жизнь играю на гитаре, но за все это время я так и не научился играть прилично, поэтому попросил своего коллегу Андрея мне аккомпанировать. Андрей - замечательный гитарист с абсолютным слухом (да, да, как у скрипача!). Я же, опять же, не смотря на то, что всю жизнь с музыкой, пою не сильно лучше, чем играю, поэтому все мои вокальные косяки прекрасно отражаются на лице Андрея. Но, несмотря ни на что, мне нравится эта вещь, как музыкально, так и по части связанных воспоминаний, а все мои другие версии этой песни - без Андрея, а, следовательно, хуже.

Итак, поздравляю автора песни, Алексея, с днем рождения, а подарок нам всем - его песня, написанная в далеком 1996-м

#музыка

Уязвимость CVE-2024-21378 позволяет выполнить произвольный код в системе, где установлен MS Outlook. А всё потому, что Exchange и Outlook, общаясь по протоколу MAPI, могут пересылать друг другу всякое разное и вообще немыслимое.

Например, можно создать собственный тип сообщения и указать клиенту Outlook, что для отрисовки этого сообщения следует использовать некую особую форму. И эту форму тоже можно передать адресату: такому сообщению соответствует класс IPM.Microsoft.FolderDesign.FormsDescription. А сама форма представляет собой DLL-библиотеку, которая хранится как вложение в сообщении.

Чтобы эксплуатировать уязвимость, злоумышленник отправляет жертве форму, которая открывает определённый класс сообщений. А затем отправляет письмо-триггер, принадлежащее к этому классу сообщений. В результате Outlook загружает вредоносную форму (см. скриншот).

Наш эксперт Александр Родченко проанализировал процесс эксплуатации этой уязвимости и написал утилиту, которая сканирует скрытые сообщения и выявляет попытки атаки. Подробности – по ссылке.

Отличная статья от Стэнтфорда про относительно новую тему с Machine unlearning и отравление данных. Чем больше мы полагаемся на ML/DL, тем лучше нам надо понимать их слабости. Всем кто занимается ML/DL/AI обязательно для ознакомления!

#mdr

А помните я говорил, что критерий профессионализма - это способность корректного предсказания?

Не заметил, что наши коллеги писали об этом аж в 2021.

Спасибо подписчику про напоминание!

За годы работы заметил следующее: если кто-то из C-level начал много внимания уделять "личному бренду", т.е. рассказывать о своих достижениях и всчески намекать на то, какой он высокоэффективный, супер успешный менеджер, это значит, что он собирается покинуть текущее место работы. Далее здесь развилка: (а) либо он решил сам, либо (б) благодаря его эффективным решениям, у компании начались проблемы, и пришла ему пора катапультироваться.
Конкретный вариант (а) или (б) можно распознать, отслеживая карьреный путь нашего героя: если он постоянно прыгает из контры в контору, то мы имеем вариант (а). Если же наш герой не замечен в частой смене работодателя, то, скорее всего, мы столкнулись с вариантом (б).

#пятница #управление

Неплохая подборка техник на AD CS , полезно сделать review своих «хантов»

#mdr

SeTrustedCredmanAccessPrivilege - удивительная привилегия, я не знал

Надо отслеживать ее присвоение наряду со «стандартными» debug, backup, takeOwnership, restore, loadDriver, createToken, impersonate и т.п.

#mdr

В новой заметке порассуждал о сценариях использования BAS: в каких сценариях он неэффективен и даже вреден, а в каких он полезен.

Уровень ожиданий относительно этой технологии, как мне кажется, неоправданно завышен, да и сами ожидания часто удивляют так, что нет слов: кто-то произносит BAS в одном предложении с пентестами и red team, а, как известно, странные вещи, сказанные много раз, перестают казаться странными - так сдвигается наше понимание "нормальности", "адекватности" и т.п.
Есть риск, что мне не удалось "вспомнить все", пройтись по всем сценариям, поэтому, комментируйте, критикуйте, по мотивам ваших возражений, вполне возможно, напишу продолжение.

#vCISO

Захожу я в Ютьюб и вижу своё интервью про гибридные SOC-и!

Смотрите, критикуйте, предлагайте альтернативные мнения!

Интервью записывалось в начале апреля, до эфира этого AM live, тогда я ещё не знал, что гибридный SOC - это когда SIEM - заказчика, а команда - MSSP, обсуждение этого постулата, безусловно, оживило бы беседу... Но буду надеяться, что и без обсуждения этого любопытного взгляда интервью не будет бесполезным

#vCISO #mdr

Хорошая подборка базовых сценариев атак на контейнеры. Да и вообще, ресурс неплохой

#mdr

Когда-то мы говорили об Vulnerability Management, но для реализации атаки не всегда требуется наличие уязвимости, поэтому стали оперировать более широким понятием - Attack Surface Management (ASM), которое, лично мне нравится больше, так как лучше отражает все эти сценарии с легитимным доступом с помощью легитимных инструментов с нелегитимными намерениями. Но вот мне на глаза попался док с новым для меня словосочетанием - Exposure Management, что похоже на ASM, но немного другими словами. Говоря об ASM мы обычно имеем в виду про атаки с периметра (хотя, я не видел явно такого ограничения этого понятия), Exposure management рассматривает и сценарии развития по локальной сети, например, в AD, что более чем популярно, тем более в парадигме Assume breach, и с учетом того, что T1078 уже который год в топе по статистикам MDR и DFIR.

В доке много маркетинга и рекламы продукта, собственно, автора доки, однако, есть и ряд интересных цифр.

#vCISO

M-Trends Executive Edition 2024

Коротко, на 4 страницах, для тех у кого нет возможности читать огромные отчеты

- основные числа: dwell time - 10, а для шифровальщиков dwell time - 5 дней; в 70% случаях шифровальщиков не заметили сами; основные вектора: эксплоиты - 38%, фишинг - 17%, не дочистили старые взломы - 15%, ворованные креды - 10%; 52% - финансовая мотивация, 10% - шпионаж

- что надо делать: проактивный threat hunting, red teaming, TTX и традиционная кибергигиена

- бояться: китайцев, зеродеев, фишинга, облаков, ИИ

#vCISO

Прямо сейчас проходит конференция Бекон. Если я ничего не путаю, ребята из Luntry обещали, что видео будет, но слайды уже сейчас публикуются в канале. Я планирую отсмотреть их все, а по интересным\не понятным позже посмотреть запись (если действительно будет)

#mdr

Карьера в ИБ

Обширное описание карьерного пути в безопасности с перечнем релевантных знаний, взятое мною отсюда. Может быть крайне полезно для ознакомления молодежи, как минимум, перед походом ко всяким карьерным консультантам и коучам. Там много Positive Technologies, так как автор там работает, и отсутствуют программы, например, от ЛК, но, как начало погружения - отличный документ, за что стоит сказать спасибо Дмитрию Федорову, тем более, если ребятам хватит мотивации продолжить обновлять свой ресурс.

За 20+ лет в отрасли я не помню, чтобы кто-то сказал, что на рынке хватает специалистов, и единственный выход из этой ситуации - выращивать, инвестировать в образовательные программы, работа с молодежью. Дока - хороший старт для формирования понимания направлений, хотя бы базовых

Spray passwords, avoid lockouts

В статье рассказывается как грамотно перебирать пароль в AD, чтобы не блокировать учетные записи. В конце приводится ссылочка на инструмент.
Практически всегда на пентестах наблюдаем password spraying , поэтому полезно Синим знать как это делать правильно с т.з. Красных и соответствующим образом подстроить свой Detection Engineering

#mdr

Много шума наделала уязвимость фича Recall , не могу и я обойти тему стороной.
С одной стороны ребята из MS не выглядят столь непрофессионалами, чтобы реализовывать функции stalkerware в своих самых популярных продуктах, с другой стороны, подобные "новшества" от MS не впервые. В этой заметке я ссылался на статью Шнайера про умышленное ослабление безопасности, в целом, вполне можно сослаться и здесь. Думайте сами, решайте сами, а пока поделюсь интересными ссылками по теме:

Stealing everything you’ve ever typed or viewed on your own Windows PC is now possible with two lines of code — inside the Copilot+ Recall disaster - почитать

TotalRecall - a 'privacy nightmare'? - тул

DisableAIDataAnalysis - отключение, ну так, по крайней мере, утверждает разработчик

Жаль что сегодня не #пятница

Мой коллега, Артем Баранов, подготовил хрестоматию Windows руткитов. Обязательно для ознакомления

#mdr

Интересный отчет выпустили ребята из РТ о вредоносном ПО. Он быстро читается, содержит интересные числа, и, вроде как, все выглядит логично, но несколько моментов меня стриггерили, и так как сегодня #пятница попробую о них рассказать.

Во-первых, в моем понимании malware - это инструмент проведения атаки. Работая в какой-либо области, нам нужны инструменты: чтобы подметать улицу нам нужна метла, чтобы воспроизводить слова на бумаге нам нужен карандаш, а чтобы компрометировать информационные системы (ИС) нам также нужны инструменты и ими является вредоносное ПО (malware). Т.е. если мы имеем дело с компрометацией ИС практически всегда мы сталкиваемся с malware, так как это - инструмент. За редким исключением, вроде социальной инженерии, когда креды не надо было воровать, а пользователь сам их куда-то вбил, или DOS (или удаленная эксплуатация уязвимостей), когда, безусловно, тоже используются инструменты, тоже malware, но их вряд ли удастся найти и обезвредить в сети жертвы, поэтому с позиции сети жертвы можно их классифицировать как не связанные с malware, но это не значит, что инструментов (malware) не было вообще. Заметил, что у меня нет заметки про классификацию инцидентов по источнику, только по критичности, исправлюсь в ближайших статьях.

Во-вторых, в разделе "ЧТО ПОМОЖЕТ ЗАЩИТИТЬСЯ ОТ ВПО" удивительно не увидеть anti-malware engine. По-моему, очевидно, что в борьбе с malware поможет ani-malware engine (AM). Очень важный момент, что Песочница и AM по отдельности имеют противоположные проблемы, и только их комбинация более-менее эффективна. В частности, Песочница - искусственная среда, и продвинутое ВПО может вполне себе эффективно это определять и пытаться обходить (правда, частенько ровно за такого рода проверки ее и детектят), тогда как AM работает на реальной системе, и ВПО там проявит себя "во всей красе", что значительно повысит шансы успешного обнаружения. С другой стороны, AM имеет ресурсные ограничения, но их не имеет Песочница. Об этом я рассказывал здесь (кстати, можно и весь доклад посмотреть, я старался, чтобы было интересно, правда, было это 6 лет назад, что-то уже подустарело).

В-третьих, мне немного резануло расписывание действий ВПО на техники MITRE. Боюсь, что я не смогу быстро объяснить в чем здесь проблема, и, если это требуется пояснять, то это будет отдельная статья, но попробую кратенько. Проблема в том, что я не смог понять практическую выгоду из информации что данная malware использует вот такой список техник. У нас есть ТТР, причем malware - это конкретная реализация техники, P- Procedure. Допустим, я занимаюсь Detection engineering-ом, как я могу использовать информацию, что какая-то malware/Procedure (которых современный AM-вендор детектит новых 400+к ежедневно) реализует определенный список техник? Если я антивирусный вендор, и мой продукт успешно, автоматически, обезвреживает эту malware, это означает, что мой продукт покрывает эти техники MITRE? (а если я детекчу миллионы разных образцов ВПО и эти миллионы ВПО покрывают вообще все техники MITRE, это означает, что я антивирусом полностью покрываю ATT&CK??). Более того, основные техники, реализуемые в malware, уже указаны в классификации: стилеры будут использовать T1555, T1556 и т.п., вымогатели и вайперы - T1490, T1486, T1561 и т.п. Расписывать техники важно когда мы имеем дело с человекоуправляемой атакой, но натягивать на техники на атоматическое ВПО ... - не знаю. В общем, я не придумал что с этим делать, напишите ваши идеи, пожалуйста, в комментариях, - век живи, век учись!

Мы строили, строили и наконец-то построили :) Книга «Охота на электроовец: большая книга искусственного интеллекта» вышла из печати и доступна к заказу. Полные электронные версии книги (epub, docx, pdf) можно скачать с сайта бесплатно: https://markoff.science#book

«Мифы и заблуждения об искусственном интеллекте, страхи, насущные проблемы, перспективные направления исследований — обо всём этом вы узнаете из «Большой книги искусственного интеллекта»

TI, популярность и задачи для машобуча

Обнаруживать угрозы, а возьмем шире, управлять угрозами, невозможно без данных Threat intelligence (TI). TI для MDR можно сравнить с опытом и мудростью для человека, - в обоих случаях требуется время на его сбор, а точнее, кропотливая работа в течение долгого времени: анализ ВПО и новых техник атак, обнаружение и расследование инцидентов.

Популярность - маленькая частичка TI, но с ее помощью можно творить великие дела. Если вы обладаете огромной базой данных о популярности файлов в Мире, то из этого можно находить, как минимум, следующее:
- непопулярные файлы. Несмотря на то, что ВПО очень много, легитимных файлов радикально больше. Непопулярность файла в комбинации с неизвестной репутацией, источника появления файла на системе, подозрительности пути расположения и т.п. факторами - вполне инструмент для поиска супер-целевых APT
- переименованные файлы. Миллионы легитимных файлов, как правило, имеют постоянные имена и здесь можно триггериться на множество разных сценариев: непопулярное имя, у файла слишком много разных имен и т.п.
- перенесенные файлы или файлы по нестандартным путям - подмножество предыдущего случая, и сценарии схожие - сравниваем фактический путь файла с наиболее популярным
- DLL Hijacking - фактически, непопулярный сценарий загрузки DLL в процесс, напишу об этом чуть более подробно в отдельной заметке
- Process Injection - опять же надо рассматривать непопулярные IPC, концептуально похоже на DLL Hijacking
- Похожие файлы - немного другая задача, здесь мы ищем не изгоев, а кластеры, разделяющие те или иные атрибуты (поиск атрибутов автоматизируется ML), соответственно, если мы обнаруживаем объект с похожими атрибутами, скорее всего, он повторяет назначение соответствующего кластера

В MDR также имеет смысл "частная популярность", и, если компания имеет много ПО собственной разработки, это позволит аккуратно пофильтровать сценарии непопулярности ПО в Мире с одновременной популярностью в данной конкретной инфраструктуре.

Имея огромную базу TI можно вполне эффективно обучать различные ML-модели, которые будут с низким FPR находить аномалии, релевантные реальным атакам, поднимать алерты, а ребята из SOC далее уже примут решение. Причем, эти технологии, так или иначе основанные на популярности, а также Похожесть и Threat Attribution Engine, уже давно используются в боевых условиях, для MDR любая технология, способная расширить возможности по обнаружению, только приветствуется.

Буду признателен, если в комментариях к этой заметке вы поделитесь своими идеями задач для ML/DL на данных TI.

#mdr