Aslr windows 10 что это

Ключевая защитная функция в Windows 10 бесполезна в ряде случаев

16:23 / 20 ноября, 2017
2017-11-20T16:23:01+03:00

Проблема с реализацией технологии ASLR присутствует еще со времен Windows 8.

---

Цифровые следы — ваша слабость, и хакеры это знают. Подпишитесь и узнайте, как их замести!

---

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

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

Мы уже неоднократно упоминали ASLR, по справедливому замечанию MS, эта технология позволяет сделать разработку эксплойтов гораздо более дорогостоящим мероприятием, поскольку кроме эксплуатации самой уязвимости в ПО злоумышленнику нужно опереться на те или иные предсказуемые адреса в памяти в момент эксплуатации, которых ASLR его лишает. Как мы видим, в последнее время, в том числе, и с выпуском новейших Windows 8/8.1 MS решили более серьезно подойти к развертыванию данной особенности в системе. Если в узком смысле ASLR понимается как просто перемещение образа по непредсказуемым адресам с каждой перезагрузкой, то в более общем смысле эта возможность на уровне системы должна лишить атакующих любой возможности зацепится за те или иные адреса функций системных библиотек и иных системных объектов (ASLR bypass mitigation / Address Space Information Disclosure Hardening) в тех нескольких десятках байт шелл-кода, который может быть исполнен минуя DEP (ROP).

Мы не будем касаться истории ASLR, которая известна уже почти всем, отметим лишь некоторые не совсем очевидные возможности, которые Microsoft использует для улучшения ASLR в своих флагманских ОС Windows 7-8-8.1.

ASLR rules

Microsoft использует по отношению к ASLR схожий c DEP подход, т. е. разрешать его использование по мере необходимости, если приложение скомпилировано с поддержкой. Такая практика применяется в виду очевидных проблем совместимости, которые могут возникнуть при работе программ с технологиями, на которые они могут реагировать неадекватно. Но в случае с ASLR эта ситуация работает с большими ограничениями. Например, на современных выпусках Windows 8/8.1 DEP включен всегда для приложений вне зависимости от того, скомпилированы они с его поддержкой или нет (по крайней мере на 64-битном процессоре и вне зависимости от разрядности ОС и параметра загрузчика). С ASLR ситуация иная, даже работая на Windows 8/8.1 он опирается на правила его поддержки самим приложением и не включает рандомизацию образа, если в заголовке нет этого флага.

Атакующие могут использовать «преимущества» системной библиотеки, которая не скомпилирована с поддержкой ASLR, для своих целей, например, для реализации стабильной цепочки ROP, которая будет работать во всех поддерживаемых ОС. Как показывает практика последних лет, такая возможность использовалась не один раз при организации таргетированных атак. Ниже указаны такие эксплуатируемые in-the-wild уязвимости типа RCE (drive-by download).

Как видно, библиотека MS Office (hxds.dll) не поддерживает ASLR (Office 2007-2010) и атакующие смогли воспользоваться ее не меняющимся адресом загрузки для успешной эксплуатации уязвимости. В рамках декабрьского patch tuesday компания закрыла эту оплошность (которая называется Security Feature Bypass) с помощью MS13-106, обеспечивая пользователей Windows, которые работают с этой версией Office, должным уровнем защиты.

Одной из основных возможностей по поддержке ASLR, которую MS внесла с Windows 8, является функция принудительного ASLR (Force ASLR). Эта функция чем-то напоминает параметр OptIn политики DEP для всей системы. Теперь используя раздел реестра Image File Execution Options (IFEO) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options и параметр MitigationOptions пользователь может вручную включать ASLR для исполняемых PE файлов. Ниже в таблице приводится поведение ОС при загрузке в память исполняемого файла с ForceASLR и без него.

Подобная функция доступна и для пользователей Windows 7 при установке опционального обновления KB2639308.

Для того чтобы сделать Internet Explorer (10+) более безопасным, компания ввела поддержку функции принудительного применения ASLR (на Windows 8+ и для Windows 7 с установленным KB2639308) для всех библиотек, загружаемых в адресное пространство процесса браузера (ForceASLR). Таким образом, если какая-то из библиотек или плагинов изначально скомпилирована без поддержки этой функции, она будет применена к ней в принудительном порядке.

Атакующие используют преимущества Windows, которая применяет некоторую оптимизацию при работе с виртуальной памятью через последовательное выделение смежных регионов нужного размера для клиентов (процессов) через VirtualAlloc. Приложение может запросить способ выделения блока виртуальной памяти как снизу-вверх (по умолчанию), сверху-вниз (MEM_TOP_DOWN) или по фиксированному адресу (указанный функции адрес). По умолчанию Windows использует метод выделения снизу-вверх, т. е. от младших адресов к старшим она будет искать блок необходимого размера для того, чтобы отдать его приложению.

Начиная с Windows 8 на выделение виртуальной памяти может воздействовать ASLR. Такая политика до Windows 8 уже применялась для выделения блоков памяти на куче, при резервировании блоков для стеков потоков, а также TEB и PEB. Последние две структуры являются очень полезными для атакующих поскольку потенциально содержат определенное количество указателей на различные системные функции, раскрывая таким образом расположение библиотек в памяти. В Windows 8 VirtualAlloc также различает опции выделения сверху-вниз и снизу-вверх, но теперь базовый адрес начала этих выделений фиксируется ASLR при каждой загрузке ОС, т. е. не может быть предсказуем. Очевидно, что в адресном пространстве невозможно выделять память совсем хаотично ввиду быстрой фрагментации, поэтому через ASLR фиксируется именно базовый адрес начала выделения блоков для процессов. Согласно MS для процесса такая опция включается только в случае соответствующей поддержки ASLR его исполняемым файлом (/DYNAMICBASE).

High Entropy ASLR

ASLR потенциально может работать эффективнее в 64-битном адресном пространстве, поскольку там существует гораздо большая возможность по произвольному размещению памяти в таком большом адресном пространстве. Очевидно и само его использование уже является усложняющим фактором для heap spray. См. Internet Explorer EPM для Windows 7 x64. В то же время ОС до Windows 8 не используют ASLR на x64 самым полноценным образом. Главным образом это касается возможности энтропии (т. е. степени произвольности/предсказуемости выбора адреса) и сколько бит адреса будут использоваться для вычисления произвольности этого размещения. В Windows 8 такая возможность получила название High Entropy Randomization.

Windows 8+ содержит возможности, реализующие High Entropy Randomization и эта технология распространяется как на выделяемые процессом блоки виртуальной памяти, так на и загружаемые исполняемые файлы. Для 64-битных приложений, скомпонованных с флагом /LARGEADDRESSAWARE, Windows 8 выделяет для использования 8 TB виртуальной памяти (128 TB в Windows 8.1). Для сравнения, у 32-битных приложений размер пользовательской части адресного пространства ограничивается 2 GB. В таком случае возможность High Entropy Randomization позволяет применять ASLR для базового адреса отсчета выделений памяти типа снизу-вверх, используя 24 бита адреса для получения энтропии и для выделений типа сверху-вниз 17 бит адреса для энтропии. Для использования такого уровня ASLR и при использовании выделений снизу-вверх (по умолчанию) 64-битное приложение должно быть скомпилировано с флагами /HIGHENTROPYVA и /DYNAMICBASE.

Следует отметить, что сам /HIGHENTROPYVA используется как режим ограничения OptIn использования HEASLR в ОС. То есть VirtualAlloc в своем обычном поведении (выделения блоков снизу-вверх) на Windows 8 не будет использовать усиленный ASLR для приложений, которые скомпилированы без этого флага. Такое ограничение связано с вопросами совместимости и возможным непредсказуемым поведением этих приложений в данной ситуации. Как указано выше, возможность High Entropy Randomization применима и к 64-битным исполняемым файлам.

Браузер Internet Explorer 10+ использует режим High Entropy ASLR (x64). Ниже показано свойство его запущенного процесса на Windows 8. Отметим, что все системные исполняемые файлы, которые Microsoft поставляет в Windows 8, используют HEASLR.

ASLR bypass mitigations (aka Address Space Information Disclosure Hardening)

С выпуском Windows 8 компания постаралась пойти по стратегии сокрытия различных адресов системных функций и объектов. Некоторые из этих возможностей доставлялись как обновления и для Windows 7. Присутствие подобной информации по предсказуемым для атакующих адресам сильно снижает возможности существующих технологий DEP&ASLR и повышает возможность успеха атакующих к эксплуатации.

Одним из ярких примеров является обновление MS13-031, которое вводит ограничение на выделение памяти по нулевой странице (Windows 7+). Размещение кода на этой странице с последующей эксплуатацией уязвимости в драйвере используется атакующими как LPE, т. е. поднятие своих привилегий до системных и исполнение своего кода в режиме ядра. Ядро использует поле EPROCESS!LowVaAccessible для регулирования подобных ситуаций, а именно, для обнаружения минимального адреса, с которого можно резервировать регионы виртуальной памяти.

Другим примером является обновление MS13-063 для Windows Vista+ (Windows 8 по умолчанию). Это обновление убирает из UserSharedData (KUSER_SHARED_DATA) указатель на ntdll!LdrHotPatchRoutine, который использовался для быстрой загрузки необходимой атакующим библиотеки в память. UserSharedData очень полезна для атакующих, поскольку доступна по одному и тому же адресу во всех процессах, а также используется в режиме ядра.

В Windows 8.1 появилась возможность скрывать информацию об адресах объектов ядра для недоверенных приложений (чей Integrity Level < Medium). Более подробно об этой фукнции мы писали здесь. Важные функции ntoskrnl возвращают статус ошибки на запрос получения информации об адресах различных объектов ядра.

P. S. Вы можете воспользоваться бесплатным инструментом BinScope от Microsoft для проверки модулей ваших программ на поддержку ASLR (iTunes взят в качестве примера).

blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx

С выхода Windows 2000 прошло больше двадцати лет, и все десять лет, что официально Microsoft поддерживала ее расширенную версию, разработчики только тем и занимались, что выпускали очередные заплатки. Если вы до сих пор где-то ее используете, все обновления можно просмотреть через systeminfo в командной строке. Пройти мимо очередного сервис-пака было опасно – никто знал, во что могут вылиться незакрытые гештальты проблемы с безопасностью.

Чтобы хоть немного подняться в глазах простых сисадминов, Microsoft выводит на рынок новую ОС, которая… оказывается практически полным клоном Win2000 и, конечно, повторяет ее судьбу. И вместо того, чтобы чистосердечно раскаяться, разработчики в очередной раз переводят стрелки на грозных хакеров. Хотя на самом деле хакеры не мешали, а наоборот, помогали создавать что-то более стабильное и безопасное.

Тем временем в Microsoft продолжили искать обходные механизмы. Одним из них должен быть стать DEP (Data Execution Prevention). Он появился в XP, но так и не оправдал надежд. Следующая попытка была сделана уже в Win7, где реализовали функцию ASLR (Address Space Layout Randomization). На нее возлагали много надежд, но скоро стало понятно: ASLR так же уязвима, как и предыдущие решения.

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

Как работает DEP

Защиту от исполнения данных можно реализовать двумя способами: программным и аппаратным. Первый, он же software-enforced, подходит только для 32-битных версий Windows, у второго (hardware-enforced) область применения чуть шире: все та же 32-битная ось, но уже 64-битные чипы. Подобное разделение легко объяснить: DEP прямо соотносится с 63-м битом в записях виртуальных страниц PTE (Page Table Entry), которого нет в 32-битных ОС. Поэтому для последних доступен только один вариант – с эмуляцией и подключением ядра Ntkrnlpa.exe.

Допустим, основное (Ntoskrnl.exe) и альтернативное ядра находятся в папке \windows\system32. Если в boot.ini установить флаг /РАЕ (Physical Address Extension), то ось будет грузиться с альтернативного ядра, пока основное будет простаивать. РАЕ помогает сделать так, чтобы у обычного процессора на 32 бита было в распоряжении не 4 Гб адресного пространства, а 64 Гб.

На левом скрине у нас PDT (каталог виртуальных страниц), на который указывает регистр управления CR3 текущего процесса. В каталоге находятся ровно 1024 (или 10 бит) записей Entry, каждая – по 32 бита. На каждую запись приходится одна из 1024 таблиц PT, в которой, в свою очередь, тоже 1024 записи PTE. И, наконец, PTE указывают на одну из 1024 страниц виртуальной памяти по 4 Кб. Итого суммарно мы получаем 4 ГБ памяти (результат умножения 1024 на 1024 на 4096).

На правом скрине видно, что в ядре РАЕ с 32 до 52 бит выросла разрядность записей Entry, но их количество сократилось вдвое: было 1024, стало 512, то есть теперь у нас девять бит вместо десяти. Благодаря тому, что в записях теперь есть дополнительные разряды, можно создавать в два раза больше таблиц PT и каталогов PDT. У любой страницы по-прежнему 4 Кб, но количество страниц просто гигантское. Также возможны иные режимы, когда вместо 4-килобайтных страниц мы получаем 2- и даже 4-мегабайтные.

32-битные записи PTE заполнены информацией по максимуму, и свободных битов в них нет. Но если разрядность повысить до 64 бит (а мы помним, что полезных там только 52 бита), появляется 12 свободных бит. Их можно закодировать под что-то полезное.

Что мы здесь видим: в РАЕ-режиме длина записи увеличилась вдвое. Это позволило нам поместить в старший (63-й) бит защиту от исполнения NX. Если записать туда единицу, то мы защитим от исполнения страницу, у которой базовый адрес хранится в записи PTE таблицы РТ (и это та самая запись, значение бита которой мы меняем). Максимум, что будет доступно для этой страницы – запись или перезапись (write/rewrite). В ntoskrnl.exe ядро non-PAE таким битом не располагает, поэтому и DEP для него не доступен, как и для всего 32-битного семейства Windows XP без РАЕ.

На 64-битных осях все иначе. Так как им не нужно ядро РАЕ, то оно не входит в состав операционной системы, а сама она функционирует в режиме AWE (Address Windowing Extensions). На схеме ниже показано, как в этом случае происходит трансляция виртуального адреса.

Поддержка DEP

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

Первая конфигурация: AlwaysOff = 0

Аппаратный DEP деактивирован для всех элементов ОС, а сама она работает на базовом ядре Ntoskrnl.exe без РАЕ.

Вторая конфигурация: AlwaysOn = 1

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

Третья конфигурация: OptInt = 2

DEP на аппаратном уровне распространяется только на компоненты ОС. Эта модель по умолчанию используется на клиентских версиях Windows. Если нужно отключить DEP для отдельных приложений/процессов, это можно сделать программным способом.

Четвертая конфигурация: OptOut = 3

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

Не рекомендую относиться к DEP как к надежному средству защиты. Судя по конфигурациям, им легко управлять на программном уровне. А если вспомнить про VirtualProtect(Ex), с которой можно «поиграть» атрибутами страниц виртуальной памяти, механизм защиты выглядит еще более хрупким. Единственное, что достойно внимания, – это вторая конфигурация. С ней попытки сломить защиту закончатся фейлом. Минус в том, что работает это только на серверных системах, а на клиентских даже при такой конфигурации DEP может легко отключить вполне безобидное приложение вроде архиватора (легального, между прочим!).

Полезное для работы с DEP

Эти функции собраны в библиотеке kernel32.dll, и их можно использовать с правами администратора.

1. GetSystemDEPPolicy() – вызывает параметры системной политики DEP. У этой функции нет дополнительных аргументов, и все, на что она способна, – это вернуть порядковый номер выбранной DEP конфигурации. Сама конфигурация выбирается на этапе загрузки операционной системы, а для ее изменения придется обратиться к boot.ini. Чтобы активировать DEP на глобальном уровне, нужен бит (11) MSR-регистра 0xC0000080, который называется IA32_EFER.NXE.

2. GetProcessDEPPolicy() – делает запрос параметра DEP для выбранного процесса. Если операция успешная, функция возвращает TRUE, в противном случае – FALSE=0.

3. SetProcessDEPPolicy() – задает параметры DEP для выбранного процесса. Доступен всего один аргумент – флаг предыдущей функции Get(). Результат работы функции зависит от общесистемной политики DEP (два варианта: OptInt или OptOut). Работать с DEP можно только тогда, когда GetProcessDEPPolicy() периодически возвращает FALSE.

Ниже привожу код утилиты, которая будет вызывать перечисленные функции. Для вывода строк рекомендую использовать «таблицы переходов», чтобы избежать ненужных проверок в цикле CASE.

А здесь показываю, что возвращает Windows XP на ядре Ntoskrnl.exe, если отключить DEP (в Windows 7 используется другое ядро – Ntkrnlpa.exe). Системный статус – AlwaysOff=0, потому что DEP отключен на аппаратном уровне.

Мой вывод: с DEP все не так однозначно. Он, конечно, в какой-то мере выполняет свою функцию, но далеко не всегда. В Microsoft так и не исправили ошибки прошлого, зачем-то оставив VirtualProtectEx() и VirtualAlloc(), которые так «играют» с атрибутами страниц, что польза от DEP начинает стремиться к нулю. Будем считать это очередным неудачным экспериментом разработчиков, который все никак не завершится хэппи-эндом.

Как работает ASLR

ASLR в операционной системе Windows 7 рандомно меняет базу образа в памяти. System files в этой ОС по умолчанию запускаются с включенной ASLR, но у других приложений, запущенных пользователем, этот механизм может быть отключен. Чтобы исправить ситуацию и принудительно включить ASLR для наших программ, понадобится файл компиляции /DYNAMIC_BASE.

Базы образов по-разному вычисляются для образов ПО разного типа. У прикладных программ это происходит случайно при каждом запуске exe-файла, у системных – только один раз, на старте ОС. Это нужно для того, чтобы код системных DLL можно было использовать совместно, не исправляя указатели на функции API для всех процессов по отдельности.

Возвращаемся к ASLR. Он случайным образом меняет базу образа, базу стека и базу кучи Heap в блоках памяти процесса. Так как у нас 8-битный механизм выбора, то нам доступна любая из 256 баз образа. В случае со стеком и кучей рандом поменьше – всего лишь 5-битный. Соответственно, разрядность будет ниже и нам доступно всего 32 базовых адреса.

Если какому-то приложению нужно находиться в памяти под чутким контролем ASLR, об этом должен заранее позаботиться разработчик: при компиляции присвоить в РЕ-заголовке определенный перечень флагов. Первое 16-битное поле (Characteristics) расположено по смещению РЕ.16h. В каждом из его 16 бит зашифрованы определенные данные, а в целом от набора флагов напрямую зависят основные параметры исполняемого файла.

Вот несколько бит, которые могут вас заинтересовать:

Устанавливается в значение «1», если файл не содержит данных о перемещениях и должен попасть в базу по умолчанию. Если она окажется занятой, загрузчик выдаст сообщение об ошибке.

Устанавливается в значение «1», если это действительно исполняемый файл, который можно запустить.

Операционная система сама уменьшит количество памяти для процесса, разбив его на несколько страниц. Такой бит есть у процессов-демонов (они редко проявляют активность).

Указывает, что программа поддерживает работу с памятью объемом от 2 Гб.

Указывает, что файл принадлежит к системным (например, драйверам).

Указывает, что файл попадает в категорию DLL-библиотек.

Наибольший интерес представляет только нулевой бит. У DLL-ок он обычно сброшен, у исполняемых файлов – возведен. Второй случай легко объяснить: когда запускается процесс, вначале в памяти оказывается именно исполняемый файл, который оказывается в предпочтительной базе. А затем он постепенно подтягивает другие файлы приложения, причем начинает действовать принцип «кто первый встал, того и тапки база». Если какая-то DLL окажется неперемещаемой, базовые адреса EXE и DLL начнут конфликтовать.

Увидеть, в каком состоянии находятся флаги, можно с помощью небольшой утилиты РЕ Explorer, которая умеет редактировать их биты.

Бит (0) – далеко не все, что нужно ASLR. Обратите внимание на поле DLL-characteristics – здесь находятся ключи, которые можно задать компилятору на этапе сборки исходного exe-файла. Чтобы ASLR обратил внимание на исполняемый файл, компилятору нужно прямо указать на ключ /DYNAMIC_BASE, иначе переместить образ не получится даже при активном ASLR.

Если у нас есть привилегия Debug плюс права администратора, мы можем последовательно пройтись по всем системным файлам и сбросить те биты ASLR, которые нам не нужны (точнее, мешают). Чтобы обойти открытые файлы, чьи образы нельзя перезаписать, достаточно дескриптора открытых файлов функциями OpenProcess() с последующим DuplicateHandle(). Пара простых манипуляций, и мы получаем родительские права на любой объект.

Базу образа также можно отыскать динамически, как это делает вредоносное ПО поколения Next, а жесткую привязку через PE-заголовки сейчас мало кто практикует. Но если вы хотите потренироваться, предлагаю написать небольшую программу. Она пройдется по текущей директории, найдет там exe-шники и покажет, какие из них поддерживают ASLR. Для этого достаточно проверить флаг DLL_DYNAMIC_BASE в поле РЕ.5Еh:

Допустим, у каких-то файлов обнаружился ASLR и вы хотите его отключить. Для этого надо сбросить флаг DynamicBase. Да, у ASLR при этом будут незавершенные роли, но они абсолютно не мешают работе процессов.

Тем, кто планирует глубже вникнуть в работу защитных механизмов операционной системы, рекомендую 7-е издание книги М. Руссинович «Внутреннее устройство Windows». Захотите обсудить механизмы защиты с единомышленниками – приглашаю на форум Codeby, у нас очень много полезного! А прокачать знания помогут наши обучающие курсы по анонимности и безопасности в интернете (Paranoid I/II) и по тестированию веб-приложений на проникновение с нуля.

Windows 8, Windows 8.1 и последующие версии Windows не могут правильно применить настройку ASLR, что делает эту важную функцию безопасности Windows совершенно бесполезной. В этой статье я покажу как включить защиту от атак ASLR, добавив небольшое изменение в реестре.

Еще по теме: Защита от атаки SMB Relay

Что такое ASLR

Рандомизация размещения адресного пространства (ASLR) — это технология, применяемая в операционных системах, при использовании которой случайным образом изменяется расположение в адресном пространстве процесса важных структур данных, а именно образов исполняемого файла (Wikipedia).

В первые ASLR появилась в OpenBSD, в далеком 2003 году, и с тех пор она была добавлена ​​во все популярные операционные системы, включая Linux, Android, MacOS и Windows.

Microsoft добавила ASLR в Windows с выпуском Vista в 2006 году. Чтобы включить эту функцию, пользователям пришлось установить Microsoft EMET и использовать ее графический интерфейс для включения ASLR в общесистемных и / или конкретных приложениях.

С выпуском Windows 10 ASLR был добавлен в «Центр безопасности защитника Windows», и теперь пользователи могут включить его в разделе «Управление приложениями и браузером», а затем «Параметры защиты от эксплойтов».

ASLR в Windows

Изучая недавно обнаруженную 17-летнюю уязвимость, влияющую на редактор формул Microsoft Office, специалист в области информационной безопасности Уилл Дорманн обнаружил, что в определенных условиях ASLR не рандомизировала местоположения объектов в памяти.

Согласно Dormann, включение общесистемной защиты ASLR, приводит к ошибке в реализации этой функции в Windows. Исследователь говорит, что эта проблема затрагивает только Windows 8 и более поздние версии, поскольку Microsoft изменила значения реестра, с помощью которых включается ASLR.

Защита от атаки ASLR в Windows

Ожидается, что Microsoft в будущем патче исправит данную проблему. В настоящее же время единственным способом активации функции ASLR на Windows является ручное изменение реестра Windows.

Ниже приведен легкий, временный способ защититься от атаки ASLR:

1. Создайте пустой текстовый файл и введите следующий текст:

   Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] «MitigationOptions»=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

2. Сохраните файл с расширением .reg, например ASLR.reg.
3. Откройте редактор реестра Windows, выполнив поиск по слову «regedit» в меню «Пуск» или с помощью комбинации WIN + R.
4. Выберите пункт меню «Файл» и выберите импортировать REG-файл, который вы только что создали.

Для особо ленивых вот готовый reg-файл.

Еще по теме: Атака Pass the hash и защита от нее