Во фреймворке для описания хакерских атак MITRE ATT&CK завели новую технику T1090.003 (Multi-hop Proxy) после расследования, проведённого нашими экспертами. В общем случае техника состоит в использовании цепочки множественных прокси для того, чтобы скрыть источник вредоносного трафика. А в том конкретном кейсе, который расследовали наши аналитики, малвара использовала технологию NKN (New Kind of Network). Это децентрализованная P2P-сеть на основе блокчейн-протокола.

Разобранный имплант NKAbuse создаёт в сети NKN новый аккаунт и нового мульти-клиента. Это позволяет передавать сообщения через разных клиентов, и таким образом обеспечивать устойчивую связь с C2. Наличие NKN-протокола в сети вашей организации должно быть подсказкой.

Хронология добавления техники в MITRE:
– 4 месяца от запроса до публикации,
– отказ упоминания компании в контрибуторах,
– автора оставили: Eduardo Chavarro Ovalle.

Подробности: https://securelist.com/unveiling-nkabuse/111512/

Техника атаки Pass the Ticket не нова, однако всё ещё популярна для горизонтального перемещения внутри домена. Одним из способов получения билета чужого пользователя является кража билета из-под соседней LUID-сессии с последующем кэшированием для текущей активной сессии атакующего. Существует множество инструментов, позволяющих это осуществить: Rubeus, TGSThief, kekeo и т.д.

Детектировать подобную активность можно, например, через просмотр всех закэшированных билетов для текущей сессии пользователя – командой klist. Если имя пользователя в билете не совпадает с именем пользователя активной сессии, такая активность подозрительна.

Но на практике даже легитимный пользователь может применять несколько дополнительных учёток для администрирования. Конечно, подобную активность можно отфильтровать вручную, однако придётся это делать снова и снова, с приходом каждого нового пользователя. Поэтому для решения проблемы можно задействовать машинное обучение (ML).

Рассмотрим на примере нашей агрегации (скриншот выше). Здесь видно, что пользователи petrov и sidorov имеют дополнительные учётки, билеты которых хранятся у них в закэшированном виде. Данная активность постоянная, что можно понять по общему количеству срабатываний правила. А вот пользователь bob имеет три разных закэшированных билета, и ранее подобная активность не наблюдалась. Это может свидетельствовать о том, что данная учётка могла быть скомпрометирована.

ML-cистемы поведенческого анализа могут выявлять схожие аномалии в телеметрии и определять возможные украденные kerberos-билеты из-под сессии пользователей. Подробнее о кейсах с использованием ML в работе SOC будем говорить на грядущем PHDays 23-26 мая. Ищите в программе конференции наш трек «Восстание машин: возможно ли заменить аналитика SOC искусственным интеллектом?».

Архитектура Windows позволяет неплохо противодействовать установке и использованию неизвестных, неподписанных, а стало быть, потенциально опасных драйверов. Но наличие уязвимостей даже в легитимных драйверах перечеркивает все изобретенные митигации и дарует нам атаку Bring Your Own Vulnerable Driver (BYOVD).

Множество софта, написанного за долгую историю доминирования Windows на пользовательском рынке, создаёт колоссальную поверхность атаки с минимальными возможностями предсказания, где и как будут проведены такие атаки. Жирным бонусом от эксплуатации уязвимостей в kernel-драйверах является получение привилегий уровня ядра ОС. А это даёт возможность отключить (либо изящно обойти) практически любой механизм защиты и мониторинга, установить руткит, бэкдор, или даже поиграться с заражением BIOS/UEFI.

Пример подобной атаки через уязвимый драйвер описали наши эксперты в детальном разборе TTP группировки вымогателей CUBA. Вот показательный кусочек кода из bat-скрипта, используемого этой группировкой:

sc.exe create aswSP_ArPot2 binPath= C: \windows\temp\aswArPot.sys type= kernel
sc.exe start aswSP_ArPot2

Здесь aswArPot.sys – это легальный антируткит-драйвер Avast, содержащий две уязвимости: CVE-2022-26522 и CVE-2022-26523. Они позволяют создать и запустить службу уровня ядра от имени пользователя с ограниченными правами. Цель – завершить процессы EDR-агентов (в конфиге ВПО был целый список с наиболее «любимыми» ею EDR-процессами) и совершенно незаметно приступить к следующей стадии деплоя рансомвары.

Что делать защите? Вот парочка полезных опенсорсных проектов-репозиториев, где собирается инфа про уязвимые драйвера: LOLDrivers (www.loldrivers.io) и Kernel Driver Utility (github.com/hfiref0x/KDU). Настраиваем фиды к себе в SIEM – и простым правилом помечаем любой чих со стороны тех сомнительных драйверов, с которыми приходится уживаться в силу невозможности обновления.

Распознавание лица для организации физического контроля доступа – это удобно. Если вчера опух, то можно показать свою (или чужую) фотографию. А можно просто надеть футболку со специальным QR- кодом, и биометрический сканер тебя пропустит.

Если покопаться внутри устройства, то открываются новые просторы для атак. Не только доступ в помещение, которое «охранял» взломанный сканер, но и закрепление на устройстве без мониторинга, для последующего развития атаки.

Рассказываем подробности анализа защищённости биометрического считывателя крупной международной компании на докладе Георгия Кигурадзе «Без лица: предъявите вашу кавычку», который начнётся 23 мая в 11:00 на конференции PHDays.

В апреле мы показывали вам годовые аналитические отчёты наших команд MDR и IR. Там были красивые картинки с котиками, а также много интересной статистики по инцидентам прошедшего года. Одновременно наши коллеги Сергей Солдатов и Константин Сапронов провели вебинар «Сезон киберохоты», где комментировали эту статистику и отвечали на вопросы.

Но вопросов было много, ответить на все за время вебинара не успели. Зато ответили после! Весь Q&A можно найти по ссылке. Спасибо за хорошие вопросы, вытянувшие из наших экспертов такие знания:

– Да, зиродеи – это плохо. Но большая часть атак проводится с использованием хорошо известных уязвимостей с публичными эксплоитами (1-day).
– На реальных инцидентах lsass дампят 1001 способом, включая довольно «свежие» (например, LSA Whisperer)
– Да, нужно читать угрозные отчеты (TI) и писать на их основании правила обнаружения. Но все отчёты не прочитать, все угрозы не покрыть, все правила не написать: приоритизация очень важна и считается отдельной дисциплиной – угрозный аналитик (CTI analyst). Не забывайте использовать тесты в любом BAS для проверки пула своих детектирующих правил.

И лучший вопрос с лучшим ответом:

Q: По вашим наблюдениям, существует ли феномен "фишингового вторника": преобладание начала фишинговых атак во вторник?
A: По нашим наблюдениям, существует феномен обращений за расследованием инцидентов в пятницу вечером! Даже если инцидент случился в понедельник, вечер пятницы – это самое частое время обращений за услугой.

В полном файле Q&A отмечены три лучших вопроса, которые выбрали наши эксперты, проводившие вебинар. Авторы этих вопросов могут получить подарки от экспертов, если напишут по адресу rub2b@kaspersky.com.

Представьте, что вы проводите Red Teaming, и уже получили сетевой доступ к контроллеру домена. Для развития атаки можно посмотреть в сторону доменных учётных записей со слабыми паролями. Но как их выявить, не привлекая внимания санитаров специалистов SOC?

Вы можете точечно проверить отдельные дефолтные аккаунты, такие как test или it-admin. Однако устроить перебор всех возможных доменных пользователей не так просто. Можно попробовать преаутентификацию в Kerberos – но это слишком шумно, и вас точно засекут.

Есть менее заметный метод. Давайте обратимся к древнему интерфейсу MS-NRPC, используя уровень доступа RPC_C_AUTHN_LEVEL_NONE (то есть без авторизации). А затем вызовем функцию Opnum 34 (DsrGetDcNameEx2) – которая проводит проверку существования указанного аккаунта в домене. Скормив этой функции дефолтный список всевозможных имён, получим список существующих доменных аккаунтов. Обнаружить такую активность совсем непросто, поскольку она не оставляет какого-либо специального типа события в журнале безопасности Windows.

Дальше остаётся только устроить перебор паролей (password spraying) по полученному списку аккаунтов. Наверняка хоть кто-нибудь использовал P@$$w0rd или May_2024.

Более подробный анализ безопасности MSRPC-интерфейсов – в исследовании Хайдара Кабибо.

Автор исследования также написал утилиту для демонстрации описанных возможностей:
https://github.com/klsecservices/NauthNRPC

Новые-старые подходы вымогателей: использование BitLocker. Это встроенное в Windows средство шифрования по идее должно защищать пользовательские данные от кражи – но может с таким же успехом защитить компьютер от его владельца! Наши эксперты проанализировали новую атаку, где злоумышленники научились ещё лучше прятать ключи криптозащиты и затруднять работу реагирования на инцидент.

Интересно, что перед шифрованием хакеры конфигурируют машину в очень безопасное состояние. Примерно так и нужно конфигурировать компьютер для защиты… а здесь это делают атакующие, чтобы "защитить" захваченную машину:

fDenyTSConnections = 1: отключает удалённый доступ по RDP
scforceoption = 1: требует аутентификацию по смарт-карте
UseAdvancedStartup = 1: требует BitLocker PIN для перезагрузки
UsePIN = 2: требует стартовый PIN с доверенным модулем (TPM)
... и так далее.

Отсюда удивительный совет для защитников: ловите изменения в реестре, которые выглядят как слишком хороший харденинг. Особенно подозрительно, если после такой безопасной конфигурации с компьютера перестала приходить телеметрия.

Подробности работы трояна-шифровальщика на основе BitLocker:
https://securelist.ru/ransomware-abuses-bitlocker/109591/

Мы уже пугали вас атаками через подрядчиков-аутсорсеров – когда рассказывали, как хакеры закрепляются в инфраструктуре жертв, используя ngrok или AnyDesk. И эти страшилки неслучайны: по данным нашей IR-команды, в 2023 году атаки через «доверительные отношения» вошли в тройку самых популярных векторов.

А теперь коллеги выкатили подробный инструктаж на эту тему: как чаще всего организован доступ между целевой организацией и поставщиком услуг, какими способами злоумышленники получают доступ в сеть поставщика и как развивают атаку в сторону его клиентов. И главное – что делать, чтобы такого не случилось у вас.

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

Полный текст исследования "Trusted Relationship Attack: доверяй, но проверяй":
https://securelist.ru/trusted-relationship-attack/109620/

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

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

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

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

Некоторые умельцы до сих пор используют старую уязвимость Windows, связанную с групповыми политиками. Механизм Group Policy Preferences (GPP) позволяет админам добавлять новых локальных пользователей на каждый хост в домене. Пароли при этом шифруются, но их можно найти и расшифровать (подтехника T1552.006). Невзирая на патч MS14-025, инциденты по-прежнему случаются.

Наша рекомендация по детекту: создайте учётку-ловушку, подложив её данные в xml-файл на SYSVOL. И мониторьте использование этой учётки. Подробности – в статье Глеба Иванова.

Большинство ИБ-экспертов с удовольствием применяют фреймворк MITRE ATT&CK в семейных отношениях (Initial Access, Defense Evasion, Command&Control) и на работе. Но Матрица большая, и у каждого Нео возникают вопросы: как её всю покрыть, и надо ли всю, и с чего начать, и с какой скоростью и с какой глубиной покрывать?

О том, как приоритизировать эти задачи, мы расскажем в отдельной статье и на вебинаре. А сейчас – основные полезные идеи.

Чтобы измерить ваш уровень ATT&CK-успеха и его неминуемый будущий рост, нужно сначала все записать и посчитать. Например, ваш SOC может автоматизировать оценку источников данных и покрытия по техникам MITRE в вашей организации, используя инструмент DeTT&CT. А затем полученные данные можно визуализировать с помощью MITRE ATT&CK Navigator: он покажет, какие техники ваш SOC может обнаружить при текущем наборе источников данных. Пример – на скриншоте выше. Закрашенное – это ваши возможности по детектированию, а незакрашенное – возможности для неизбежного личностного роста.

А когда вы понимаете эти возможности в комбинации с актуальными угрозами (ваш threat intelligence, ну или просто возьмите рансомвару для начала), то можете сформировать приоритеты разработки детектов, на основе уже посчитанных параметров visibility_score и attacker_score:

(1) Самые релевантные и критичные техники MITRE (из вашего TI), для детектирования которых ничего не нужно менять в ваших подходах журналирования.
(2) Критичные техники, но для их детектирования необходимо добавить логов, написать коннекторов и прочее.
(3) Менее популярные техники с уже готовыми журналами.

Более подробно о том, как формировать и приоритизировать бэклог разработки детектов по MITRE, мы расскажем на вебинаре, который пройдёт 9 июля в 16:00 МСК на платформе BrightTalk (после будет и статья): https://kas.pr/o1os

Операционка Windows даёт возможность зарегистрировать как службу исполняемый файл или скрипт для закрепления в системе и обеспечить стабильность восстановления в случае его завершения. Но не только добрые IT-специалисты пользуются этим удобством.

Злоумышленники в своих атаках применяют для решения этой задачи легитимные утилиты, например NSSM, SRVANY из набора Microsoft Windows Resource Kit, или SRVANY-NG. Эти утилиты регистрируются в системе в качестве сервиса и берут на себя роль управления запуском, привилегиями, зависимостями и восстановлением исполняемого файла. А ещё эти утилиты позволяют скрыть целевой исполняемый файл или выполняемую команду в событии создания службы в журналах Windows — чтобы обойти детектирование со стороны SOC.

Как же их детектировать? Нужно мониторить не только события создания сервисов, но и ключи реестра, связанные с параметрами сервисов. Подробности — в статье Дмитрия Лифанова.

Сейчас расскажем, как мы починяем детектирующие правила (ханты) с помощью их конверсии – то есть знаний о том, насколько правила проваливаются в алерты, которые говорят о настоящем инциденте. Повышение конверсии позволяет уменьшить объём работы аналитика и чётче найти инцидент.

На одну и ту же реализацию техник атакующих мы разрабатываем N правил обнаружения, основанных на разных подходах: на продуктовых детектах, на TTPs, с применением ML, и так далее. Такой метод затрудняет обход обнаружения. Очевидная идея для повышения конверсии – найти такие комбинации правил, которые по отдельности показывают плохую конверсию, но в комбинации с другими – практически никогда не ошибаются.

Примерами правил с околонулевой конверсией (из нашей работы) могут быть suspicious_process_spawning_as_trusted_installer, unusual_dynamic_assemblies, regsvr32_execute_from_public_directory и другие (см. скриншот выше).

А вот пример комбинации. Монтирование папки ADMIN$ (mount_remote_admin_share_as_disk) само по себе демонстрирует нулевую конверсию. Однако в комбинации с использованием psexec и сбором информации о сети (mount_remote_admin_share_as_disk, network_connections_discovery, process_started_by_psexec) это правило даёт конверсию 100%.

В статье Сергея Солдатова более детально показано, как мы ищем кандидатов на комбинацию с низкоконверсионными правилами, чтобы оправдать расход электричества при использовании этих правил на обработке телеметрии.

Экспертов по безопасности тоже иногда атакуют. А для атак через Visual Studio есть целая россыпь векторов.

Недавно наши аналитики разбирали атаку, направленную на SUO-файлы, где хранятся различные параметры и настройки пользователя проектов VS. Парсится файл с использованием BinaryFormatter.Deserialize() – и можно применять Ysoserial. Это приводит к тому, что при запуске проекта VS (даже такого, в котором не содержится ни строчки кода) будет запускаться пейлоуд, что содержится в SUO-файле. Сам Microsoft предусмотрительно не рекомендует использовать подобные методы обработки данных, но для себя они делают исключение.

Скачали VS проект? Удалите SUO-файл (...\.vs\[Project name]\v17\.suo). Часто открываете внешние проекты? Настройте trusted locations для VS IDE. Подробный разбор атаки и защиты – в статье Глеба Иванова.

Иногда наши эксперты разговаривают не только кодами, но и голосом. В подкасте «Смени пароль» – серьёзный разговор про становление героя, который более 20 лет занимается оффенсивом (конечно же, только этические пентесты и «красные команды»). Как всё начиналось, как устроена эта профессия сейчас и с какими проблемами сталкиваются пентестеры в своей работе – рассказывает Александр Зайцев:

«В школе тебе дарят 286 компьютер, работающий на частоте 12,5 МГц, его потенциально можно подключить к Интернету по диалапу на скорости 9600 бод. Правда, диалап очень платный, надо искать демо-доступы, обзвонить кучу систем, найти гейты в сеть X.25, оттуда искать возможность зацепиться по PPP и вообще понять, где ты находишься и куда тебя выпустит… Тогда это был необходимый клубок вещей, которые нужно знать, если ты хотел получать доступ к растущим объёмам недоступной ранее информации. Сама среда задавала высокий порог входа.»

Слушать тут: https://podcast.ru/e/7Y9dddSWOjk

А другой выпуск того же подкаста посвящён тяжёлой доле специалистов по AppSec, которые анализируют защищённость веб-приложений:

«Печально, когда заказчик не верит в уязвимость и не может понять, как воспроизвести атаку. Ему уже и скрипт скинули, а он всё говорит, что у него есть защита от такого брутфорса. Приходится очень долго объяснять, даже записывать видео с атакой».

Слушать тут: https://podcast.ru/e/9dn8sQEP7wP

Повысить привилегии через Active Directory Certificate Services (ADCS) можно с помощью многих разных техник. Сегодня разбираем, как детектировать атаку ADCS ESC13.

Вкратце: класс Issuance Policy в Active Directory содержит атрибут msDS-OIDToGroupLink, и этот атрибут можно использовать для линковки Issuance Policy с группой AD. Таким образом, системы будут авторизовать пользователей, как будто они включены в группу. Работать это будет в случае, если пользователь предоставит сертификат с необходимой Issuance Policy.

Из-за схожести таких билетов с золотыми, для их выявления можно воспользоваться утилитой FindGT Александра Родченко. Либо использовать скрипт Check-ADCSESC13 для аудита небезопасных конфигураций в AD, который предлагают сами авторы техники ESC13.

А чтобы детектировать атаку во время эксплуатации, нужно наблюдать за изменениями соответствующих объектов AD и ADCS. В частности, можно получить событие добавления Issuance Policy в Certificate Template – и посмотреть, есть ли у него линк с какой-то группой. Также необходимо следить за изменением атрибута msDS-OIDToGroupLink. И ещё полезно проверять опубликованные Certificate Templates с потенциально эксплуатируемой конфигурацией, содержащие Issuance Policy – и следить, какие пользователи их запрашивают.

Подробнее об этой атаке и методах детектирования – в статье Дмитрия Щетинина.

Если вы по-прежнему мечтаете разложить потенциальные угрозы для вашей организации по матрице MITRE ATT&CK, оценить покрытие и приоритизировать задачи, но при этом вы пропустили наш вебинар по этой теме – не отчаивайтесь!

Теперь полную инструкцию можно прочитать в статье Андрея Тамойкина и Романа Назарова:
https://securelist.ru/detection-engineering-backlog-prioritization/109883/

Мы уже рассказывали про туннель через QEMU, а теперь – ещё одна интересная техника туннелирования от атакующих, с использованием VSCode (Visual Studio). Работает так:

– Злоумышленник включает опцию «Туннель разработки» из графического интерфейса VSCode на скомпрометированной машине, либо включает эту опцию с помощью консольной версии (её легче загрузить на хост без VSCode):

code.exe tunnel [service install] [--name "tunnel-name"] 

– Поднимается туннель с легитимными серверами Microsoft Azure (домен *.tunnels.api.visualstudio.com).

– Атакующий подключается по ссылкам вида vscode.dev/tunnel/<victim's hostname>/<tunnel name>.

– IP атакующего не видно, а сам трафик зашифрован внутри SSH-over-HTTPS.

Что ловить защитникам:
– Запуски code.exe с ключиком tunnel в командной строке
– Создание файла code_tunnel.json в %UserProfile%\.vscode-cli\
– Цепочку процессов code.exe -> cmd.exe -> node.exe -> winptyagent.exe
– Домены в трафике или резолвах DNS *.tunnels.api.visualstudio.com и *.devtunnels.ms

Больше деталей про туннели через VSCode и не только – на конференции OFFZONE 23 августа в 13:00, в докладе Кирилла Магаськина "LOLApps: подножный корм хакера".

А помните, мы упоминали инцидент, когда атакующий получил доступ к почте сотрудника, и дождавшись переписки с аттачем, добавил вредоносный макрос в документ? Очень аккуратная атака: никаких подозрительных ссылок, никаких посторонних адресов. Просто один реальный сотрудник пишет в рассылке «пришлите ваши правки к документу», а другой сотрудник посылает в ответ тот же документ с правками. После этого в корпоративную сеть попадает бэкдор, и атакующий развивает атаку.

В рамках этого инцидента было одно событие, которое часто приводит к дискуссиям: всегда ли заход с non-Windows хоста на Windows-систему по RDP является алертом? Понятно, что так могут делать и легитимные админы. Однако подобные заходы всегда привлекают внимание ИБ-экспертов.

Как обнаружить такую активность? Это непросто:

– Вследствие различий в реализации определённых протоколов на Linux и Windows можно искать такие аномалии в трафике с помощью IDS.
– Некоторые утилиты могут оставлять артефакты в штатных событиях Windows (например, имя хоста-источника в событиях логона).
– Перспективным выглядит использование ML для определения нестандартных (новых) пользователей и источников логона на хосте. Или просто чётко заданные правила с источниками админских машин, а всё остальное – алерт.
– Лучше всего иметь инвентаризацию для обогащения источника и назначения событий ИБ типом ОС.

Остальные детали инцидента и расследования – в докладе Алины Сухановой «Взлом через MS Exchange» (OFFZONE, 23 августа, 13:40)