- Специальный корреспондент
Вы ещё верите своим сессиям? Лучше не надо.
Знаменитые времена, когда получить учетные данные с помощью 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-объектам. Это позволит выявить аномалии на раннем этапе.
Знаменитые времена, когда получить учетные данные с помощью 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-объектам. Это позволит выявить аномалии на раннем этапе.
