RemoteMonologue: как заставить Windows сдать пароли без вирусов

Добро пожаловать на наш форум!

Спасибо за посещение нашего сообщества. Пожалуйста, зарегистрируйтесь или войдите, чтобы получить доступ ко всем функциям.


Gibby

Автор
Команда проекта

Регистрация
Сообщений
1,971
Репутация
53
Сделок
2.jpg

Знаменитые времена, когда получить учетные данные с помощью Mimikatz было проще простого, стремительно уходят в прошлое. Microsoft продолжает усиливать защиту от кражи учётных данных, а EDR-системы становятся всё более проницательными. Поэтому привычные для Red Team методы — от перемещения по сети до работы с LSASS — всё чаще вызывают тревогу у защитных решений. Однако креатив у исследователей не иссяк: они переориентируются на менее заметные, но не менее эффективные способы атаки.

Одним из таких способов стало использование технологии COM и её распределённой версии DCOM. Хотя эти механизмы существуют в Windows с конца прошлого века, их атаки до сих пор остаются редкостью из-за сложности архитектуры. COM позволяет приложениям взаимодействовать друг с другом, а DCOM — делать это через сеть. Однако при определённых условиях они могут стать инструментами для захвата сессий и принудительной аутентификации NTLM.

Ключевым элементом здесь является параметр RunAs, который задаёт, от имени какого пользователя будет выполняться объект DCOM. Особый интерес представляет значение «Interactive User» — это позволяет объекту запускаться от имени того, кто в данный момент вошёл в систему. Если изменить соответствующую запись в реестре, можно «подсунуть» DCOM-объект, который выполнится в контексте другого пользователя. Хотя права TrustedInstaller по умолчанию мешают вносить такие изменения, у локального администратора есть SeTakeOwnershipPrivilege, позволяющая обойти ограничения.

Один из описанных подходов — принуждение пользователя к NTLM -аутентификации без запуска вредоносных файлов. Такой метод позволяет перехватывать NTLM-хэши и либо пытаться взломать их офлайн, либо сразу транслировать в другие сервисы вроде LDAP или SMB. Это снижает риски детектирования и исключает работу с LSASS. Особенно эффективно это работает при использовании NTLMv1, взлом которого значительно ускоряется благодаря общедоступным радужным таблицам.

Одним из инструментов атаки стал COM-объект ServerDataCollectorSet. Его метод Extract позволяет указать путь к CAB-файлу, причём можно использовать UNC-адрес, что инициирует сетевую аутентификацию. Если объект запускается от имени другого пользователя (благодаря изменению RunAs), хэш можно перехватить. Аналогичный эффект был достигнут с объектом FileSystemImage, где достаточно изменить значение свойства WorkingDirectory. Наконец, UpdateSession продемонстрировал интересное поведение: даже при запуске от имени пользователя, сетевые операции выполняются от имени SYSTEM.

Специалисты IBM нашли способ автоматизировать данный процесс, включая возможность выбора используемых DCOM-объектов и активацию службы WebClient для осуществления HTTP-аутентификаций. Также можно использовать функции перебора учётных данных и изменения параметров системы для перехода на использование NTLMv1.

Что касается защиты, то стоит обратить внимание на несколько направлений. Во-первых, рекомендуется включить обязательную подпись LDAP и SMB, а также отключить NTLMv1. Во-вторых, важно отслеживать изменения в реестре, связанные с RunAs и LmCompatibilityLevel, а также мониторить запуск WebClient и обращения к конкретным DCOM-объектам. Это позволит выявить аномалии на раннем этапе.
 
Сверху