Software microsoft windows nt currentversion image file execution options lsass exe

Время на прочтение
14 мин

Количество просмотров 49K

Если вы много занимаетесь отладкой приложений под Windows — вы, возможно, слышали о таком замечательном механизме, как Image File Execution Options (IFEO). Одна из предоставляемых им возможностей позволяет отлаживать приложение в условиях, более приближенных к боевым. Записав в нужное место в реестре специальный ключик, мы можем вместо программы автоматически запускать её отладчик, позволяя ему делать свои отладочные дела. Однако кто сказал, что этот механизм (фактически — перехвата запуска чего угодно) можно использовать только в подобных целях? Эта статья вовсе не об использовании вещей по назначению.

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

Вообще говоря, идея эта не нова. Я знаю как минимум три программы, которые используют этот механизм для не-отладочных целей: широко известные Process Explorer и Process Hacker — для замены стандартного диспетчера задач; и AkelPad — для замены блокнота. Но я решил пойти немного дальше.

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

Что можно полезного сделать, обладая такими возможностями? Первое, что пришло мне в голову: спросить пользователя — а действительно ли он хочет, чтобы этот процесс запускался? Быстро разобравшись, как прописать себя в IFEO я смастерил крохотную утилиту с диалоговым окошком и кнопками Да/Нет, которая запускает перехваченную программу только при согласии пользователя. Сразу после запуска я осознал всю глубину своей наивности. Уже догадываетесь, что произошло при выборе «Да»? Конечно же, я снова запустил себя и получил новое окно с запросом подтверждения, и здесь можно продолжать до бесконечности. Перехват сработал отлично.

Не уверен, насколько полезным оказался бы этот механизм, если бы не было возможность его обойти: отладчику-то нужно запустить отлаживаемый процесс. Так что в Image File Execution Options есть одно исключение. Начнём с того, что в пользовательском режиме есть всего два метода запуска процессов: CreateProcess и ShellExecuteEx. Да и то, второй, в конце концов, тоже вызывает CreateProcess, но об этом позже. Так вот, исключение же это заключается в том, что запуски процессов с флагом DEBUG_PROCESS не перехватывается. Это и решает проблему с отладчиками, но, в моём случае, это также означает, что на IFEO нельзя полагаться полностью. И тем не менее, я не знаю ни одной программы (кроме отладчиков, разумеется), которые пользовались бы этим флагом. Нельзя просто поставить этот флаг и наслаждаться: понадобится дополнительный код, чтобы всё заработало.

Регистрация файла в IFEO

Если вы проследите с помощью Process Monitor’а за тем, что происходит при вызове функции CreateProcess — вы, вероятно, найдёте много чего интересного. Помимо коррекции ошибок в имени файла, о которой мы поговорим чуть позже, вы обнаружите обращение в реестр за настройками IFEO. Как это выглядит:

Если этот ключ будет найден, то также будет проверено наличие определённых полей, в том числе строкового поля Debugger. Оно-то нам и нужно. В нём хранится путь к отладчику, или, в нашем случае, к программе, запускаемой вместо данной.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\YourExecutable.exe]
"Debugger" = "C:\Path-to-debugger\Debugger.exe"

Стоит заметить, что здесь есть свои ограничения:

• Проверяется исключительно имя исполняемого файла. Это значит — никаких масок. Нельзя просто взять, и перехватить вызов *.exe.
• Действие для всех программ с одинаковым именем исполняемого файла будет одинаковым. До тех пор, пока мы не воспользуемся ключом UseFilter. Тогда, да, можно назначать конкретный отладчик для конкретного исполняемого файла, основываясь на его полном пути. Опять же — без масок.

Назначение стандартных действий

Изначальный смысл этой затеи для меня был в том, что, узнав про IFEO, я решил написать программу, которая предлагала бы пользователю набор типичных действий (реализованных в виде маленьких утилит), назначаемых для других программ. Это было ещё до того, как я решил написать статью, осознав, сколько тут занятных вещей можно рассказать. А потому, используем эти утилиты в качестве наглядного и практического примера для повествования. Итак, на что хватило моего воображения:

• Ask.exe — оповещает пользователя о попытке запуска и спрашивает разрешения;
• Deny.exe — отказывает в запуске. При этом может как оповещать пользователя, так и делать это молча. Очень удобно, если надо запретить винде запускать какую-нибудь телеметрию
• Elevate.exe — всегда запрашивает UAC для повышения прав до Администратора;
• Drop.exe — понижает привилегии процесса. Это просто венец творения. По смыслу аналогичен утилитам DropMyRights и PsExec с флагом -ℓ. Но в сочетании с IFEO — гораздо эффективнее;
• PowerRequest.exe — не даёт компьютеру заснуть / погасить экран до тех пор, пока программа не завершится.

Для регистрации этих действий было написано две версии представленной на скриншоте программы: GUI и консольная. Здесь и рассказывать не о чем. Просто читаем/пишем в реестр.

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

• Точно такая-же структура STARTUPINFO, установка флага bInheritHandles, и такая же рабочая директория;
• Ожидание завершения запускаемого процесса для получения его кода возврата и передачи по цепочке;
• И… ещё один трюк, о котором я расскажу чуть позже.

Хорошо. А как мы узнаем, что запускать-то?

Оценим возможности

Пусть в IFEO в качестве отладчика для программы A.exe прописано следующее:

"C:\My-Path\B.exe" /param

Если кто-то попытается создать процесс «C:\Folder\A.exe» с параметром -a то будет создан процесс B.exe cо следующей командной строкой:

"C:\My-Path\B.exe" /param "C:\Folder\A.exe" -a

Поскольку мы сами пишем код для B.exe — мы без проблем разберём командную строку на составляющие части и вполне можем запустить A.exe с теми же параметрами, с каким его хотел запустить этот безымянный кто-то. Здесь-то у нас и появляется полноценная свобода. Хотим — запускаем с другими привилегиями, захотим — сможем и передаваемые параметры поменять.

Любопытно во всём этом вот что: как, по-вашему, реагирует на столь вольное обращение контроль учётных записей? Правильный ответ: а никак. Если в проводнике выбрать «Запуск от имени Администратора» на файле A.exe, то в сообщении UAC будет показываться информация именно о файле A.exe, и именно его цифровая подпись будет определять цвет окна. А то, что вместо него будет запущен B.exe — это дело десятое. Нет, здесь нет особых проблем с безопасностью: запись в IFEO сама требует административных привилегий. Для нас это значит нечто иное: записав наши утилиты в IFEO мы вообще не будем смущать пользователя неверными сообщениями контроля учётных записей. Ведь с его точки зрения — так оно и должно выглядеть.

Как обычно запускают процессы

С появлением контроля учётных записей в Windows Vista запуск процессов стал более сложным. Дело в том, что теперь для запуска некоторых программ вызов CreateProcess может оказаться неудачным по причине недостатка прав. В этом случае GetLastError возвращает ERROR_ELEVATION_REQUIRED. На такой случай в Windows встроено даже специальное исправление проблем с совместимостью, хотя я так и не заметил, чтобы оно хоть что-то исправляло. Современные же программы в ответ на эту ошибку должны вызывать ShellExecuteEx с действием «runas» для запроса повышения привилегий. Это значит, что типичный код создания процесса теперь выглядит так:

if not CreateProcess(…) then
else if GetLastError = ERROR_ELEVATION_REQUIRED then
  ShellExecuteEx(…) // с действием "runas"
else
  // обработка других ошибок

Поскольку наши утилиты должны работать всегда, они не будут требовать повышенных привилегий для запуска, а значит тот процесс, который попытается запустить A.exe (и вместо него запустит наш B.exe) никогда не получит ERROR_ELEVATION_REQUIRED. Вроде бы: и ладно, ничего страшного, мы и сами cможем запросить повышение прав для него, если потребуется. А теперь представим себе, что так и произошло. Вот запустил кто-то A.exe, вместо него запустились мы, а поскольку A.exe требователен к привилегиям — мы не можем запустить его CreateProcess’ом, а потому должны использовать ShellExecuteEx. Уже догадались? ShellExecuteEx же всегда перехватывается IFEO, там нет флага DEBUG_PROCESS, который мог бы нас спасти. В результате мы снова запустим самого себя. Правда, на этот раз у нас уже хватит привилегий использовать CreateProcess для запуска A.exe. И всё это без каких-либо видимых следов со стороны UAC! Можно мозг сломать, не правда ли? Я и сам не до конца привык к концепции «почти всеобъемлющего перехвата своих же действий».

По этой причине в утилите Elevate.exe нельзя обойтись одним лишь ShellExecuteEx’ом — мы просто не сможем обойти IFEO. В случае же Ask.exe это добавляет ещё одну проблему. Вот спросили мы пользователя, подтвердил он запуск. А затем ShellExecuteEx’ом в сочетании с IFEO мы запустили снова себя. Что, опять спрашивать будем? Пришлось добавить подавление вторичного вопроса. А ведь это невозможно сделать простым дописыванием специального параметра: куда бы мы его не дописали, мы же всё равно собираемся запускать A.exe, так что он будет неотличим от его собственных параметров. Это весьма неплохое упражнение для ума — попытаться заранее предугадать все эти сложности.

Отличие CreateProcess от ShellExecuteEx

Вы читали документацию на CreateProcess? Там есть один момент, который многие упускают, потенциально создавая некоторую уязвимость в безопасности своих приложений. Это же относится и к устаревшей функции WinExec, являющейся обёрткой над CreateProcess’ом. Два первых параметра функции определяют, что и с какими аргументами будет запускаться. Это lpApplicationName и lpCommandLine. Вот перевод куска текста из MSDN:

Параметр lpApplicationName может иметь значение NULL. Тогда имя исполняемого файла должно быть первой отделенной пробелом подстрокой в lpCommandLine. Если вы используете длинные имена файлов, которые могут содержать пробелы, воспользуйтесь кавычками для указания, где заканчивается имя файла и начинаются аргументы. В противном случае имя файла является двусмысленным.

Почему люди продолжают забывать ставить кавычки? Так ведь и так работает — в CreateProcess встроен механизм коррекции ошибок. Установим lpApplicationName в NULL и попытаемся запустить программу передав в lpCommandLine имя её исполняемого файла: C:\Program Files\Sub Dir\Program Name. Что будет делать CreateProcess? Искать в строке то, что можно запустить, пока не найдёт, да ещё и подставляя расширение файла:

C:\Program Files\Sub Dir\Program Name
C:\Program.exe Files\Sub Dir\Program Name
C:\Program Files\Sub Dir\Program Name
C:\Program Files\Sub.exe Dir\Program Name
C:\Program Files\Sub Dir\Program Name
C:\Program Files\Sub Dir\Program.exe Name
C:\Program Files\Sub Dir\Program Name

Если хотите поэкспериментировать — создайте файл C:\Program.exe у себя на компьютере и посмотрите, попадётся ли какая из программ на это. У себя я поймал на этом Process Hacker (fix уже есть в ночной сборке), Punto Switcher (надо бы мне им тоже написать), и один из плагинов к Far Manager. Кстати, проводник Windows тоже знает об этой проблеме:

Возвращаясь к вопросу: а что это значит для нас? Из IFEO мы получаем именно lpCommandLine. Да, мы можем просто передать его в CreateProcess — если там и была такая проблема — она останется, здесь мы бессильны. Но также нам может понадобиться передавать его в ShellExecuteEx, а там, упс, такой коррекции ошибок нету. Там отдельно lpFile и отдельно lpParameters. Придётся самостоятельно разбирать строку по пробелам и искать имя первого существующего исполняемого файла также, как это делает CreateProcess. Супер.

А сейчас мы немного отвлечёмся и поговорим о других любопытных вещах. Я собираюсь рассказать о том, как работает одна из утилит.

Понижая привилегии

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

SetEnvironmentVariable('__COMPAT_LAYER', 'RunAsInvoker');

Это заметно снижает число случаев, когда CreateProcess не сможет запустить программу и вернёт ERROR_ELEVATION_REQUIRED. Но это работает не всегда. Например, над этим методом имеют приоритет *.sdb патчи.

Ещё есть специальные утилиты, которые умеют запускать процессы с Elevated-токеном (т.е. как-бы от имени администратора), но при этом вырезают все соответствующие привилегии. Это DropMyRights, написанная Майклом Ховардом из Microsoft, и PsExec из широко известного комплекта Microsoft Sysinternals, запускаемая с ключом -ℓ. Как ни странно, но эти утилиты добиваются своего разными путями.

Мне больше по душе оказался метод, используемый в DropMyRights. Да и исходники у него открытые. Используется там Windows Safer API, который позволяет буквально в несколько строк кода вычислять токен с урезанными привилегиями, который можно сразу использовать в CreateProcessAsUser. Эх, хотел бы я, чтобы все писатели инсталляторов знали, как это просто, и не запускали программы с максимальными правами по окончании установки…

А теперь объединим оба упомянутых подхода, совместив их с IFEO. В результате получаем автоматическое понижение прав и минимум запросов к контролю учётных записей. Не знаю как вам, но мне это очень нравиться. А поскольку повышение прав путём вызова ShellExecuteEx’а перехватывается всегда, то, насколько я понимаю, у программы, находящейся под действием нашей утилиты, нет шансов самостоятельно выбраться до тех пор, пока пользователь не подтвердит UAC для другого исполняемого файла, находящегося в кооперации с ограничиваемым. Но для действительно серьёзных случаев — пользуйтесь песочницами вроде Sandboxie. Или виртуальными машинами, если на то пошло.

Обход IFEO

Возвратимся к основной теме. Я вот всё говорю, мол, запустим процесс с флагом DEBUG_PROCESS и будет нам счастье, на свои грабли сами не попадёмся. Но для того, чтобы всё заработало, необходимо сделать ещё кое-что. С этим флагом мы запустим процесс под отладкой, а значит, нам будут приходить отладочные события. Если их не обработать — процесс так и останется висеть неподвижно. Для их обработки понадобятся всего две функции: WaitForDebugEvent и ContinueDebugEvent.

Однако не все программы нормально относятся к отладчикам, верно? Не то, чтобы я специально делал исключение ради вирусов, но отсоединение отладчика действительно будет лучшей идеей. Мы ведь здесь не ради написания отладчика собрались. А вот тут, неожиданно, наступает сложность: это действие, вероятно, относится к недокументированным возможностям, ибо на MSDN я его не нашёл. А потому будем пользоваться документацией Process Hacker’a. Итак, нам потребуется функция NtRemoveProcessDebug из ntdll.dll. Ей же нужен DebugObjectHandle, который можно получить с помощью NtQueryInformationProcess, запросив у неё ProcessDebugObjectHandle = 30 в качестве ProcessInformationClass. Вот и всё. Хотя… Лучше не делайте так с чужими процессами: их отладчик может в этот момент ждать отладочное событие, а для них самих может быть включён kill-on-close.

UPD.
Я был неправ, и потому пошёл более сложным путём. Документированная функция для этого есть, это DebugActiveProcessStop. Вместе с ней рекомендуется использовать DebugSetProcessKillOnExit.

Стоит заметить, что здесь имеется особенность, связанная с разрядностью операционной системы: 32-битный процесс не может запускать 64-битный процесс с флагом DEBUG_PROCESS. Зато 64-битный может запускать кого угодно.

Ах да, вы ещё помните? Выше я обещал рассказать про ещё один трюк, позволяющий добиться чуть лучшей совместимости при последующем запуске перехватываемых процессов.

Магия контроля учётных записей

Я уже говорил, что контроль учётных записей вообще никак не реагирует на происходящее. И если вы ещё тогда задались вопросом «А почему?», то вам точно сюда.

Как работает UAC и каким образом позволяет повышать привилегии? Хорошо ответ на этот вопрос дан в англоязычной статье Vista UAC: The Definitive Guide. Если коротко: ShellExecuteEx, пробиваясь через дебри вызовов COM, обращается к сервису AppInfo. Тот создаёт процесс consent.exe, который и выводит то окно с предложением подтвердить запуск, и, при необходимости, ввести пароль. Само создание процесса, естественно, происходит уже после всего этого. И используется там самый обычный CreateProcessAsUser. Именно на этом этапе срабатывает IFEO, и, перехватывая создание процесса, запускает нас. Именно поэтому контроль учётных записей ничего об этом не знает.

Самые догадливые уже должны были задаться вопросом: если процесс создаётся кем-то другим, то как получается, что его родительским процессом всё равно оказывается инициатор запроса?

Начиная с Windows Vista в CreateProcess вместо STARTUPINFO можно подсунуть STARTUPINFOEX (если воспользоваться флагом EXTENDED_STARTUPINFO_PRESENT). Он содержит всю ту же информацию + lpAttributeList со списком атрибутов процесса. Этот список атрибутов надо создать, вызвав InitializeProcThreadAttributeList, а затем обновить средствами UpdateProcThreadAttribute. Подменить родительский процесс можно, указав флаг PROC_THREAD_ATTRIBUTE_PARENT_PROCESS и предоставив дескриптор нужного процесса. О чём тут стоит помнить:

• Дескриптор процесса, которого мы делаем новым родителем, должен иметь права PROCESS_CREATE_PROCESS и жить вплоть до вызова DeleteProcThreadAttributeList;
• Следует установить значение поля cb вложенного STARTUPINFO в SizeOf(STARTUPINFOEX).

Готовый пример на C# есть на StackOverflow.

Часто ли вы при анализе, например, подозрительной активности на компьютере исходите из того, кто какой процесс запустил? О, теперь вы точно не станете так делать.

Тут есть некоторые любопытные особенности. Мне вспоминается шутливая фраза из одного мультика, звучит она примерно так: «да что там, даже при моём рождении не присутствовал ни один из моих родителей…». Как ни странно, но здесь возможно нечто подобное. Если между вызовом OpenProcess’a и самим созданием процесса назначаемый родитель будет завершён — не беда. Просто дочерний процесс будет «как бы» создан родителем после своего завершения. Почему бы и нет.

Всё бы хорошо, но этот трюк не сработает с ShellExecuteEx’ом — там всё просто: кто вызвал, тот и родитель. Однако поскольку у нас включён IFEO — финальное слово всегда остаётся за CreateProcess’ом: без него мы не выберемся из перехвата. Так что, пройдясь по цепочке процессов можно найти того, кто всё это затеял изначально, и назначить его родителем. Возможно, результат теперь не так красиво выглядит в Process Explorer’е и Process Hacker’е, зато с точки зрения чужого процесса всё будет в порядке. Ну, за исключением, разве что, «внебрачных» детей, которые появились при запуске и ожидают кода возврата перехваченного процесса. Тут уж ничего не поделать.

На картинке схема того, как я из Far.exe запускаю nsx.exe, на который назначено действие Ask.exe, и которому для запуска требуются повышенные привилегии.

Если честно, я думал, что идея с подменой родительского процесса — просто ещё одна прикольная возможность, не больше. Однако она действительно исправила несколько проблем. Так, тот же Far Manager может создавать второй процесс для выполнения более привилегированных действий, а при наличии перехвата эта функциональность ломалась. Подмена же родителя вновь починила это.

Чего делать не стоит

Я довольно долго не решался проверить это у себя на компьютере, ибо разворачивать виртуальную машину было лень: что будет, если в качестве запускаемой при перехвате программы установить её же саму? К счастью, ничего страшного. Но дальше я решил проявить благоразумие и не стал у себя на компьютере проверять гипотезы вроде «ой, а если попробовать создать цикл A → B → A…». Также, думаю, не стоит пытался устанавливать перехват важных системных процессов (я встроил их список в утилиту регистрации с подтверждением действия). Хотя, мне и любопытно, что произойдёт. Ибо всё, что я запускал от имени SYSTEM перехватывалось. Так что я добавил подавление всех диалоговых окон в нулевой сессии, ну, чтобы не зависеть в подобных случаях от сервиса UI0Detect.

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

Нерешённые проблемы

В Windows сосуществуют сразу несколько подсистем для исполняемых файлов. Три самых известных это Native (драйвера), Windows CUI (консольные приложения), и Windows GUI (графические приложения). Поскольку драйвера нас сейчас совершенно не интересуют — нам надо разобраться в различиях между вторым и третьим вариантом, и выбрать как компилировать наши утилиты. Вот здесь и начинаются проблемы — как мы хотим: красиво или удобно? Различия между этими подсистемами не столь велики, поскольку консольное приложение может создавать окна, а графическое — консоль. Да и то, GUI даже не всегда означает взаимодействие с пользователем: фоновые сервисы запускаются в svchost.exe, который работает в подсистеме Windows GUI.

Для нас существенным отличием являются начальные условия при запуске. За исключением особых случаев, приложения из консольной подсистемы при старте уже имеют консоль, притом видимую. Даже если первым делом при старте программы мы её спрячем, то она успеет появиться перед исчезновением. Хотим ли мы пугать неискушённого пользователя такими вещами? Наверное, нет. Я надеялся, что в исправлениях совместимости из Application Compatibility Toolkit найдётся что-то, что сможет исправить эту проблему, но, судя по всему, там нет функции «спрятать консоль по умолчанию». А потому, для себя я выбрал графическую подсистему. Всё бы хорошо, но у неё есть заметный минус. Если вы активно пользуетесь приложениями из консольной подсистемы, то сразу обратите внимание: все консольные программы, на которые назначено какое-либо стандартное действие, создают новую консоль, а не пользуются имеющейся. Это не критично, хотя и не всегда приятно. Если вам вдруг захочется сделать другой выбор в этом вопросе, а Delphi под рукой нет — просто пропатчите нужные файлы, отвечающие за стандартные действия: замените 02 на 03 по смещению 0x15C.

Заключение

Я надеюсь, что этот «экскурс в 1001 любопытный факт о работе Windows» оказался действительно любопытным и даже полезным. Я знаю, не все здесь жалуют Delphi, но уж с почти чистым WinApi, холиваров, надеюсь, не возникнет.

Код получившихся программ и бинарники доступны на Гитхабе. Программа тестировалась на Windows 7 и выше, про Windows Vista — без понятия. Ниже — однозначно нет.

P. S. Если у вас сложилось мнение, что в каком-то вопросе я основательно заблуждаюсь — не кидайтесь помидорами сразу, давайте сперва разрешим это недоразумение, и исправим неточности в статье. Спасибо.

Microsoft introduced a process called Local Security Authority (LSA) a while back for Windows 8.1. LSA performs security related tasks such as the verification of logon attempts and password changes. It also creates access tokens, enforces local security policies, and protects and adds security protection for stored credentials. With the growing threat landscape out there, it’s a good thing to enable for your Windows desktops and servers.

The good news is that LSA protection is enabled by default for devices running Windows 11, 22H2 that meet the following conditions:

• Windows 11, 22H2 was newly installed on the device and not upgraded from a previous release
• The device is enterprise joined be it AD domain joined, Azure AD domain joined or a hybrid configuration.

While Microsoft advocates enabling LSA across your enterprise, they recommend that you first identify all LSA plug-ins and drivers that are in use within your organization and ensure that they are digitally signed with a Microsoft certificate and perform as expected. You can refer to this document for more information.

As of right now, there is no way to enable/disable LSA using Intune. Your three available management options for now are Windows Security, the registry, and Group Policy.

Enabling LSA on a Local Device

If you just have a few computers to manage, you can enable them locally on the desktops themselves by going to Windows Security > Device security > Core isolation details and enable the toggle under the Local Security Authority protection section. In the screenshot below, LSA is currently disabled.

Registry

You can manage LSA through the registry, either using the local registry editor or a GPO using Group Policy Preferences. The required key path is as follows:

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe.

If you want to enable LSA using Auditing mode, click on the LSA key and create a value called AuditLevel. Select REG_DWORD as the value type and type 00000008 in the value data box. This is a good option to identify LSA plug-ins and drivers that will fail to load in LSA Protection mode.

To fully enable LSA, create a value key called RunAsPPL, choose REG_DWORD and type 00000001 as shown in the screenshot below.

You can create a GPO and use Group Policy Preferences to push out these registry values. Go to Computer Configuration > Preferences > Registry > right click and choose “New registry item” and input the required values as shown below.

Group Policy ADMX

You can enable/disable LSA using Group Policy as well. In Group Policy Management Editor go to Computer Configuration > Administrative Templates > System > Local Security Authority. The setting you want is “Configure LSASS to run as a protected process.” In the screenshot below you will notice a down arrow beside the setting title. The down arrow indicates that the setting is a preference setting and not stored in the typical group policy location in the registry.

Group Policy ADMX

You can enable/disable LSA using Group Policy as well. In Group Policy Management Editor go to Computer Configuration > Administrative Templates > System > Local Security Authority. The setting you want is “Configure LSASS to run as a protected process.” In the screenshot below you will notice a down arrow beside the setting title. The down arrow indicates that the setting is a preference setting and not stored in the typical group policy location in the registry.

Conclusion

Hackers are constantly trying to subvert the Windows logon process which is why you need to protect it from hackers as much as possible. LSA is a great out-of-the-box utility to help you achieve that.

• Lsass.exe audit mode
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe\AuditLevel
• Lsass.exe audit mode
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe\AuditLevel

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---