Не так давно был пост про подделку ярлыка для бокового перемещения. Теперь предлагаю рассмотреть, как это выглядит со стороны синей команды🛡.

Мы обнаружили подозрительные события перехода по SMB на неизвестный никому адрес. Определив источник событий находим неприметный .lnk файл. По событиям 4663 или 5145 журнала Security можем определить, когда именно и кем данный файл был помещен в систему.

Анализировать ВПО на рабочем\личном устройстве очень плохая идея, так что нам нужна своя лаборатория для анализа. Существует отличный проект с открытым исходным кодом - Flare VM, инструкция по установке есть в файле README и неплохая пошаговая инструкция на youtube

Анализ файлов состоит из двух частей: статический и динамический

1. Статический анализ🔬.

Подразумевает сбор информации о файле без его запуска:
- Метаданные (имя, размер, дата создания, дата изменения, дата доступа, информация о создателе)
- Хэш-суммы
- Структура файла (например, PE для исполняемых файлов Windows, ELF для Linux, PDF, DOCX и др.)
- Содержимое и код (дисассемблированный код для анализа логики работы приложения)
Для начала этого достаточно.

Для некоторых типов файлов есть уже готовые утилиты для анализа.
Вот какую информацию позволяет получить LECmd:

Name: Просмотр веб-страниц
Relative Path: ..\..\..\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
Working Directory: C:\Program Files (x86)\Microsoft\Edge\Application
Icon Location: \\1.45.136[.]217\share

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

Сам ярлык ведет к браузеру Microsoft Edge🌍.

Так же получаем информацию об имени устройства и MAC Address, на котором данный файл был создан (полезно, если устройство в домене):

Tracker database block
   Machine ID:  hostname
   MAC Address: c4:03:a8:ce:c0:00
   MAC Vendor:  (Unknown vendor)
   Creation:    2023-09-20 16:15:08

Все необходимые данные мы получили, приступаем к следующему этапу анализа

2. Динамический анализ🧑‍💻.

В рамках динамического анализа производится запуск файла для выявления следующих ключевых аспектов:
- Поведение программы
- Сетевое поведение
- Изменения в файловой системе
- Изменения в реестре
- Используемые системные ресурсы
- Процессное дерево
- Статистика и логирование
- Взаимодействие с другими программами и системами

Учитывая специфику нашего файла интереснее всего взглянуть на сетевой трафик при помощи Wireshark

Находим пакет Session Setup Request, NTLMSSP_AUTH, User: .\tim и видим в нем следующую информацию:

Domain name: DESKTOP-2Q3SAD1
User name: tim
Host name: DESKTOP-2Q3SAD1
NTLMv2 Response: 561393d6c45c520cf59b0f2164a44b53:010100000000000080cc3abb5aeada011c521ff2286be6fe000000000100100052006a00620052006a006900760051000300100052006a00620052006a006900760051000200100041005a0076005100490074006d006d000400100041005a0076005100490074006d006d000700080080cc3abb5aeada0106000400020000000800300030000000000000000100000000200000ec56f98273b68c776c7aa89b1329e54f290cd1254c2586ac939288f6bd63d2370a001000000000000000000000000000000000000900260063006900660073002f003100340037002e00340035002e003100330036002e003200310037000000000000000000

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

На этом можно было бы и закончить, но важно понимать, что злоумышленники могут предпринять, имея на руках NetNTLM хэш и принять соответствующие меры, а именно:

- Сбросить пароли для учетных записей пользователей, хэши чьих паролей были переданы
- Заблокировать УЗ пользователя создавшего .lnk файл
- Изолировать от сети хост (если это возможно), на котором .lnk файл был модифицирован
#blueteam

Привет, а мы сегодня на Offzone.

Доклады неплохие, и конкурсы интересные. Не хватает только бесплатной еды (бесплатная вода есть)

Так уж получилось, что мы попали под недавнюю багу в обновлении windows. Мы, настроенные порешать таски на второй день, решили взять ноут, но вот обновлять винду было ошибкой. Grub перестал загружаться, и выяснялось это как раз в тот момент, когда сели решать таски. 😥

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

🎉 Друзья, а тем временем нас уже более 500! 🎉

Большое спасибо каждому из вас за то, что вы с нами! 💖 Ваша поддержка и активность вдохновляют нас делать контент еще лучше!

Оставайтесь с нами, впереди много интересного! 🙌

#REDtalk

💥 Привет, недавно я делал пост про странную логику Bloodhound-CE при работе с Owned и High Value пользователях.
Проблема была в кривом отображении UI и сбросе данных после перезагрузки при ручной пометке через Neo4j.

Я пошел смотреть исходники и обнаружил преинтереснейшую вещь — В отличии от предыдущего бладхаунда, тут, помимо приложухи и Neo4j в стек добавилась Postgres. Если раньше аутентификация проводилось только через bolt в Neo4j, то тут добавляется еще и аутентификация в саму GUI. Вот эта инфа, и другие настройки, типа Custom Queries хранятся в постгресе.

И (уже не первый раз) я удивился, когда увидел, что там в отдельной таблице хранятся данные об Owned и High-Value нодах.

bloodhound=# select * from asset_group_selectors;
---+------------------+------------------+---+----+-------------------------------+------------------------------
 1 | S-1-<SNIP>-17251 | S-1-<SNIP>-17251 | f |  1 | 2024-09-02 09:34:55.977957+00 | 2024-09-02 09:34:55.977957+00
 1 | S-1-<SNIP>-7261  | S-1-<SNIP>-7261  | f |  3 | 2024-09-02 10:51:05.968531+00 | 2024-09-02 10:51:05.968531+00
 1 | S-1-<SNIP>-13965 | S-1-<SNIP>-13965 | f |  4 | 2024-09-02 10:51:10.386376+00 | 2024-09-02 10:51:10.386376+00
 1 | S-1-<SNIP>-21856 | S-1-<SNIP>-21856 | f |  5 | 2024-09-02 11:29:49.443476+00 | 2024-09-02 11:29:49.443476+00
(4 rows)
bloodhound=# select * from asset_groups;
      name       |     tag      | system_group | id |          created_at           |          updated_at           
-----------------+--------------+--------------+----+-------------------------------+-------------------------------
 Owned           | owned        | t            |  1 |                               | 
 Admin Tier Zero | admin_tier_0 | t            |  2 | 2024-08-28 12:34:58.093203+00 | 2024-08-28 12:34:58.093203+00
(2 rows)

Из запроса можно увидеть 2 таблицы, одна из которых (нижняя) содержит теги и ID этих тегов, вторая (верхняя) совмещает SID объектов AD с этими ID. То-есть у меня в бладхаенде есть 4 пользака, помеченные как Owned.

И после перезагрузки все свойства system-tags, что было отмечено в Neo4J обнуляются и устанавливаются вот эти четыре.
Нет слов, одни эмоции, не знаю, зачем разработчики сделали такую логику. Наверное стоит завести Issue на гитхабе

#redteam

SOC на аутсорсе 💰 или in-house SOC 🧃
Что бы выбрали вы?
Мы как то рассказывали, что это такое и в чем отличия, поговорим теперь о работе в данных организациях с точки зрения сотрудника, понятно, то что есть в одной компании, будет отсутствовать в другой, но так как я поработал и там и там расскажу о тех моментах, с которыми мне пришлось столкнуться.

Начнем с SOC-а на аутсорсе.

Плюсы➕:

1. Четкое разграничение ответственности
Моя первая работа в качестве SOC аналитика началась именно там, поначалу безумно нравилось тем, что при заключении договора, есть четкая документация, в рамках которой ты работаешь, в целом все понятно и прозрачно, кому что писать, у кого что спрашивать;

2. Работодатель более охотно оплачивает курсы, платные митапы
Компания заинтересована в вашем развитии, т.к. вы тот актив, который приносит деньги, и от качества предоставляемой услуги, зависит удовлетворенность заказчика и следовательно продление\подписание новых контрактов;

3. Большая команда
Как правило именно тут команда SOC будет больше, т.к. такой SOC создается под несколько компаний, а следовательно больше людей - больше компетенций.

Минусы➖:

1. Не вовлеченность заказчика
Как и многие мои коллеги, я столкнулся с проблемой, что услуга SOC приобреталась с целью отчета перед регулятором о том, что инфраструктуру мониторят, а если это так, то у вас целый букет проблем
Запросы о предоставлении дополнительной информации, необходимой для расследования инцидента, могут висеть неделями, рекомендации об устранении инцидента могут игнорироваться, а сбор дополнительных событий будет расцениваться как попытка саботажа и отвергнута по причине излишней нагрузки на сеть;

2. Ощущение работы в пустую
Вытекает из предыдущего минуса, и начинаешь ощущать это тогда, когда хочешь сделать что то хорошо, тратишь на решение какой то проблемы время, но от твоих идей отказываются за ненадобностью;

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

Итог:
На мой взгляд, это отличное место для старта карьеры, как правило, в таких SOC-ах, большая часть процессов выстроена и следовательно не нужно изобретать велосипед. Сотрудников больше чем в in-house, следовательно всегда есть человек, который может что-то подсказать. Но я там не смог долго проработать по ряду причин, одна из которых это ощущение работы в пустую.

Был ли у вас опыт работы в SOC-е на аутсорсе, и с какими нюансами работы сталкивались вы?

В следующей статье, расскажу про нюансы работы в in-house SOC-е
#SOC #blueteam #REDtalk