Эксплойт LegacyHive обходит защиту Windows через манипуляцию профилями пользователей

Авторы публичного доказательства концепции (PoC) намеренно ограничили его возможности: для успешной атаки требуется контроль над низкопривилегированной учётной записью и знание пароля так называемой вспомогательной учётной записи. Тем не менее сама техника представляет интерес для защитников, поскольку может быть адаптирована под другие сценарии. Специалисты по кибербезопасности из компании LevelBlue (ранее известной как AlienVault) воспроизвели цепочку атаки на полностью обновлённых системах с патчами июля 2026 года и подтвердили её работоспособность.

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

На втором этапе злоумышленник размещает в созданной иерархии символические ссылки. Это не обычные ярлыки или точки соединения NTFS, а объектные ссылки, создаваемые через низкоуровневый API Windows. Они становятся прослойкой для перенаправления путей. Сочетание вызовов для создания каталога и символических ссылок в одном процессе - крайне редкое поведение для легитимного программного обеспечения.

Третий этап - наиболее важный с точки зрения криминалистики. Вместо изменения активного реестра эксплойт открывает файл ntuser.dat целевой учётной записи напрямую и модифицирует его в автономном режиме с помощью официального офлайн-API реестра Microsoft. В разделе, отвечающем за папки пользователя, значение Local AppData заменяется на путь, ведущий в объектный менеджер, а не в обычную файловую систему. После изменения куст сохраняется на диск и заменяет оригинал. Такое вмешательство оставляет сильный след: любые значения Local AppData, содержащие ссылки на объектный менеджер, должны вызывать подозрения.

Четвёртый этап использует механизм пакетной оппортунистической блокировки (oplock) на файле UsrClass.dat. Вместо того чтобы полагаться на случайное совпадение по времени, эксплойт задействует встроенное средство синхронизации Windows для приостановки собственного выполнения до того момента, когда система начнёт загружать профиль. Это изящное решение - атака не борется с Windows, а использует её собственные механизмы для управления последовательностью событий.

На пятом этапе, после установки блокировки, эксплойт запускает процесс от имени целевой учётной записи с помощью функции CreateProcessWithLogonW с флагом LOGON_WITH_PROFILE. Цель - не выполнение кода, а принудительная загрузка профиля "помощника". Когда профиль загружается, модифицированный куст реестра активируется, и перенаправление путей вступает в силу.

Шестой этап - проверка успешности. Эксплойт открывает раздел реестра UsrClass.dat целевой учётной записи. Если система отдаёт изменённый куст, атака состоялась. На седьмом этапе удаляются временные файлы, но ключевые изменения - модифицированный реестр и объектные ссылки - остаются. Это даёт злоумышленнику постоянный доступ к данным другой учётной записи.

Как выяснили аналитики LevelBlue, наиболее надёжные сигналы для обнаружения атаки - вызовы низкоуровневых функций NtCreateDirectoryObjectEx и NtCreateSymbolicLinkObject из пользовательского режима. В нормальной работе они почти не встречаются. Если оба вызова зафиксированы от одного процесса, это однозначно требует расследования. Даже без телеметрии на уровне системных вызовов остаётся характерная цепочка событий: офлайн-доступ к файлам ntuser.dat или UsrClass.dat, модификация кустов через офлайн-API, запрос пакетной блокировки и запуск профиля через CreateProcessWithLogonW. Каждая операция по отдельности легитимна, но их комбинация в коротком окне времени - явная аномалия.

После загрузки изменённого куста перенаправление проявляется в ключе Volatile Environment, где переменная %LOCALAPPDATA% вместо обычного файлового пути указывает на объектный менеджер. Кроме того, поскольку эксплойт копирует файлы кустов в рабочий каталог вне стандартных расположений профилей, необычные пути доступа к ntuser.dat или UsrClass.dat также являются детектируемым признаком.

Для защиты от подобных атак организациям следует обратить внимание на несколько мер. Во-первых, регулярное обновление системы до последних патчей критически важно, хотя в данном случае патчи не закрывают саму технику - она использует легитимные механизмы. Во-вторых, необходим мониторинг вызовов низкоуровневого API, особенно создания каталогов объектного менеджера и символических ссылок. В-третьих, стоит контролировать доступ к офлайн-API реестра (offreg.dll) и ограничивать использование CreateProcessWithLogonW с флагом LOGON_WITH_PROFILE для учётных записей с низкими привилегиями. В-четвёртых, полезно настроить оповещения на необычные значения Local AppData в пользовательских кустах реестра.

Хотя текущая реализация PoC требует предварительной компрометации системы и знания пароля вспомогательной учётной записи, сама техника может быть адаптирована. Будущие варианты могут изменить способ загрузки профиля или выбрать другие кусты реестра, но основные строительные блоки - офлайн-модификация кустов, манипуляция объектным менеджером, контролируемая загрузка реестра и аномальная инициализация профиля - останутся неизменными. До тех пор пока Microsoft не внедрит целенаправленные смягчающие меры, защитникам следует опираться именно на эти поведенческие паттерны, а не на детали конкретного PoC.