Вредоносы в SYSVOL: ищем источник 😐

Допустим, мы расследуем инцидент с шифровальщиком. Для запуска шифровальщика хакеры использовали групповую политику (например, прописали задачу планировщика). Сам вредонос они положили в папку SYSVOL на контроллере домена (DC).

🥷 Как понять, откуда действовал хакер? В этом посте сфокусируемся на файловом следе.

Логика простая: чтобы положить файл в SYSVOL, хакер должен был так или иначе «зайти» на DC. Поэтому смотрим, когда был создан файл (кстати, поэтому важно сначала собрать данные для расследования, а потом уже зачищать системы), и соотносим эту информацию с входами в систему.

Кажется, все просто, но есть нюанс: содержимое каталога SYSVOL реплицируется между DC с помощью DFSR (Distributed File System Replication). То есть хакеру достаточно положить вредоносный файл на один DC, а дальше система автоматически распространит его по всем остальным. Как понять, какой DC был исходным, особенно если DC много?

Посмотрим отладочные логи DFSR на произвольном DC из тех, на которых вредонос попал в папку SYSVOL. Обычно эти логи находятся в папке %systemroot%\debug, имена файлов имеют вид Dfsrxxxxx.log и Dfsrxxxxx.log.gz (.gz в Windows? Да!). Логи текстовые, вполне поддаются грепу, но при этом некоторые события имеют многострочный формат, — учитывайте это, если не хотите потерять контекст.

Поищем в логах имя нашего вредоноса (пусть это будет badfile.exe). Если мы нашли исходный DC с первого раза, мы должны найти в логах подобное сообщение:

20250526 02:44:24.906 5628 USNC  2871 UsnConsumer::CreateNewRecord LDB Inserting ID Record:
+  <...>
+  name                            badfile.exe

Если коротко, то оно свидетельствует о появлении нового файла в реплицируемой папке, то есть искомый файл был изначально размещен на этом DC. В этом случае можно переходить к последнему абзацу в посте ниже 🙂

Можно на всякий случай перепроверить это в журнале $UsnJrnl:$J:

badfile.exe,.exe,132035,6849,257939,4,.\Windows\SYSVOL\domain\scripts,52168700184,2025-05-25 23:44:23.6245532,FileCreate,Archive,436154648

Видно, что файл создается на файловой системе (FileCreate).

Если бы файл был реплицирован, это выглядело бы так:

2025-03-25 23:44:25 +0000 UTC,badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,System Volume Information\DFSR\Private\{F0285778-7EF8-4808-85D7-68223AA11FB5}-{24DC8227-6461-4D16-96D5-537D78549536}\Installing\badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,FILE_CREATE,archive,7|109885

2025-05-25 23:44:25 +0000 UTC,badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,System Volume Information\DFSR\Private\{F0285778-7EF8-4808-85D7-68223AA11FB5}-{24DC8227-6461-4D16-96D5-537D78549536}\Installing\badfile-{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456.exe,RENAME_OLD_NAME,archive,7|109885

2025-05-25 23:44:25 +0000 UTC,badfile.exe,Windows\SYSVOL\domain\scripts\badfile.exe,RENAME_NEW_NAME,archive,5|269425

Видно, что файл сначала создается в папке DFSR, а потом уже переносится в SYSVOL.

Если же вредонос был реплицирован на исследуемый DC, мы увидим в логах DFSR подобное сообщение:

20250526 02:44:24.949 4452 INCO  3065 InConnection::ReceiveUpdates Received: uid:{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456 gvsn:{D5B54C1C-F832-4838-ABC8-C5027E7F9F51}-v123456 fileName:badfile.exe session:86382 connId:{C62DFB26-63FA-4E9F-B533-0F487BF8E043} csId:{F0285778-7EF8-4808-85D7-68223AA11FB5} csName:SYSVOL Share

Очень интересно, но ничего не понятно.

Продолжение в следующем посте 🔽

#ir #dfir #DFSR
@ptescalator

Продолжаем искать файловый след из поста выше 🐾

Чтобы понять, с какого DC реплицировался файл, нужно узнать, какому хосту соответствует указанный connId (это значение статично и соответствует однонаправленной связи между двумя машинами).

Как это сделать

1️⃣ Можно посмотреть таблицу соответствия в файле \System Volume Information\DFSR\Config\Replica_<GUID группы репликации>.XML. Поищем в нем наш connId и увидим примерно следующее:

<DfsrConnection>
  <ConnectionGuid>C62DFB26-63FA-4E9F-B533-0F487BF8E043</ConnectionGuid>
  <...>
  <PartnerName>DC02</PartnerName>
  <...>
  <PartnerDns>dc02.corp.local</PartnerDns>
  <...>
</DfsrConnection>

2️⃣ Можно поискать в логах DFSR события, содержащие одновременно интересующий нас connId и слова "partnerDns", "partnerName" или "partnerAddress". Можем обнаружить что-то типа:

20250314 01:22:31.307 6304 DOWN  3959 [ERROR] DownstreamTransport::EstablishConnection EstablishConnection failed. Check that the connection partner is valid. If not then recreate the connection with valid partner. connId:{C62DFB26-63FA-4E9F-B533-0F487BF8E043} rgName:Domain System Volume partnerName:DC02 partnerDns:dc02.corp.local

3️⃣ Если DC «живы», то информацию о GUID’ах можно извлечь с помощью утилиты Dfsradmin. Этот способ разбирать не будем — более подробно про логи DFSR можно почитать по ссылке.

Итак, в ходе расследования мы выяснили, что изначально вредоносный файл был размещен на DC02.

Дело за малым — узнать, кто и откуда заходил на этот DC и положил туда этот файл. Журналы ОС и SUM в помощь — никто не обещал, что будет легко! 🙂

#ir #dfir #DFSR
@ptescalator

Собеседование → ПО на iPhone от «работодателя» → у вас больше нет смартфона 👋

Новая старая схема блокировки iPhone через «режим пропажи» снова в ходу. Только теперь она стала изощреннее: в начале поста — реальный пример многоходовочки, который мы подробно описали в статье на Хабре.

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

😎 Бонус: мы подготовили наглядную схему восстановления доступа к iPhone. Она доступна в формате PDF с кликабельными ссылками — скачивайте и сохраняйте на разные устройства (на всякий случай).

#ios #dfir #mobile
@ptescalator

Страсти вокруг PyPI: 🪰⮕🐘?

На прошлой неделе CNews выпустили новость: "Россиян погнали из сообщества Python. Пока только избранных, но критерии отбора до предела странные". В ней выясняется, что Python Package Index (PyPI), крупнейшее хранилище пакетов Python, запретила регистрацию новых пользователей с указанием почты на домене inbox.ru.

В официальном заявлении сказано, что с почтовых ящиков inbox.ru пришла волна спама – пользователи с такой почтой создали 250 профилей и добавили к ним свыше полутора тысяч проектов, которые якобы «обманывают пользователей и представляют угрозу безопасности» (leading to end-user confusion, abuse of resources, and potential security issues).

Блокировка россиян в различных комьюнити — животрепещущая тема. Её процитировали и другие издания.

@banksta:

Россиян изгоняют из сообщества программистов Python. Им запретили пользоваться репозиторием PyPI с пакетами для Python. Ограничения коснулись только тех, кто создает новый аккаунт с привязкой почты на inboxru и тех, кто хочет добавить такую почту в уже существующий профиль. Домен принадлежит Mailru.

@imaxairu:

Россиянам запретили пользоваться репозиторием PyPI с пакетами для Python

Ограничения коснулись только тех, кто создает новый аккаунт с привязкой почты на inbox .ru и тех, кто хочет добавить такую почту в уже существующий профиль

Домен принадлежит Mail .ru. На другие домены компании лимиты пока не распространяются

Команда Supply Chain Security активно сотрудничает с PyPI в области обнаружения троянов. Мы решили провалидировать, были ли действия администрации репозитория обоснованными.

#ti #pypi #pyanalysis #scs
@ptescalator
Пост 1/4
Продолжение⬇️

Даём оценку официальным заявлениям

CNews ссылаются на статью в блоге PyPI, выпущенную 15 июля 2025. В ней говорится, что, руководствуясь практикой блокировки мусорных почтовых доменов, они закрывают регистрацию новых пользователей в Python Package Index с использованием почты на домене inbox.ru.

Схожее решение администрация PyPI выносила и год назад, 16 июня 2024, в отношении доменов outlook.com и hotmail.com (принадлежат Microsoft) — они стали излюбленным решением для злоумышленников из-за простоты массовой регистрации доменов.

Следует уточнить, что для скачивания пакетов не требуется регистрация. Учётная запись нужна для публикации своих проектов.

PyPI приводит статистику:

9 июня: появилась первая учётная запись кампании.
11 июня: за 3 часа было создано 46 учётных записей.
24 июня: за 4 часа было создано 207 учётных записей.
С 26 июня по 7 июля ими было создано 1525 проектов:
2025-06-26  9
2025-06-27  295
2025-06-28  39
2025-06-29  119
2025-06-30  740
2025-07-01  249
2025-07-02  46
2025-07-10  16
2025-07-11  12

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

Обращаем внимание на последний абзац поста на PyPI (ниже перевод):

Надеемся, что мы сможем отменить это решение в будущем, когда будем более уверены в способности этого провайдера электронной почты предотвращать злоупотребления. Если вы работаете в этом провайдере, пожалуйста, напишите нам по адресу [email protected], чтобы обсудить это решение.

Давайте разберемся с кампанией.

#ti #pypi #pyanalysis #scs
@ptescalator
Пост 2/4
Продолжение⬇️

Оправдано ли внесение почты @inbox.ru в чёрный список?

В настоящее время при создании почтового ящика на @inbox.ru требуется номер телефона или учётная запись VK. Есть упоминание, что два года назад можно было обойтись без почты. Также можно создать до 10 анонимных ящиков к своей основной почте в рамках официального функционала mail.ru.

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

Зарегистрированных на PyPI разработчиков, привязавших почту @inbox.ru, "репрессии" не касаются — были заблокированы только "пользователи", участвовавшие в кампании. Нельзя создавать новые учётные записи или привязывать эти ящики к существующим аккаунтам.

Подводя итог

Ограничение создания новых учётных записей с использованием почты на @inbox.ru — закономерная реакция на кампанию, в рамках которой пара сотен учётных записей, зарегистрированных за короткое время, начинает творить беспредел.

Почтовые домены от Microsoft также год назад попали под блокировку, это дополнительно уменьшает вероятность, что в этих действиях выражается какое-либо предвзятое отношение.

Получился опенсорсный myth busters 👀

#ti #pypi #pyanalysis #scs
@ptescalator
Пост 4/4

Уязвимости типа Pass Back: что это такое и насколько опасны 🧐

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

Примером такой уязвимости является LDAP Pass Back (CVE-2024-32122), которую зарегистрировал ведущий специалист отдела наступательной безопасности PT ESC Владислав Дриев совместно со специалистом по анализу защищенности УЦСБ Олегом Лабынцевым.

Эта уязвимость позволяет получить учетные данные (УД) от LDAP в открытом виде (зачастую это УЗ AD), злоумышленнику нужно лишь частично изменить конфигурацию коннектора. Уязвимость встречается в разных видах и в самых разных устройствах и программных продуктах.

Атакующий может получить УД в открытом виде или в виде хеша с захваченного устройства или софта. Ярким примером таких устройств, конечно, являются МФУ, но точно не ограничиваемся только ими. Уязвимыми также могут быть домофоны, камеры, сетевое оборудование. Если говорить про ПО, то чаще всего это CMS.

В чем конкретно проблема 🤔

Проблема в том, что атакующий может влиять на конфигурацию устройства, в которой есть УД. Чтобы было еще понятнее, приведем пример. Настроили МФУ, чтобы оно могло отправлять сообщения по SMTP на почту, также настроили аутентификацию по LDAP, чтобы динамически загружался список контактов, а еще — SMB, чтобы сразу можно было складывать отсканированные документы в сетевую папку.

Далее рассмотрим ситуацию, когда атакующий смог получить доступ к веб-интерфейсу с помощью УД по умолчанию. В таком случае он может попробовать изменить IP-адрес конфигурации, которая содержит УД, поменяв в ней IP-адрес на подконтрольный ему. Что это даст и почему это вообще возможно? Опыт показывает, что в большинстве случаев смена только IP-адреса в конфигурации разрешена. Соответственно, УД будут использованы валидные. Таким образом, злоумышленник сможет получить обращение с корректными учетными данными на свой IP-адрес, где сможет достать их из трафика либо в открытом виде, либо в виде хеша.

• SMTP (без TLS) зачастую позволяет получить УД в открытом виде.
• LDAP позволяет получить данные в открытом виде.
• SMB позволяет получить хеш (часто NetNTLMv1, с которого можно выполнить NTLM Relay).
• другое (УД для IP-телефонии, которые обернуты в Base64).

Что здесь небезопасного, ведь доступ ко всем конфигам скрыт за аутентификацией? Да, но не всегда все так. Способы получения доступа к конфигурациям:

• УД по умолчанию.
• IDOR (выделен отдельно от уязвимостей, потому что встречается часто).
• Уязвимость для получения доступа к веб-интерфейсу администратора.

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

Так или иначе атакующий получит доступ к устройству. После этого скомпрометирует УД и начнет развивать атаки на смежные сервисы, в частности на AD. Кроме того, среди этого всего бывают уникальные и выдающиеся случаи:

• CMS работает с учетной записью администратора домена.
• МФУ работает с учетной записью администратора домена.

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

Итак, как этого избежать 🧐

Самый простой способ — при любом изменении конфигурации УД запросить ввести их заново. Если конфигурацию меняет администратор, для него это не будет проблемой. А если атакующий, то он ничего не получит. Понятно, что на софт не всегда можно повлиять, тогда перед тем, как войти под своей УЗ на какое-то новое устройство, можно самостоятельно проверить, как оно ведет себя с разными конфигурациями, нет ли возможности извлечь УД из него.

Более того, такие УЗ следует ограничивать в правах, брать на мониторинг. Если от имени УЗ началась разведка в домене — это явный признак компрометации устройства. Ну и конечно, нужно защищать устройства и ПО: менять пароли по умолчанию, регулярно устанавливать обновления.

#CVE #offensive
@ptescalator