D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Источник: https://enigma0x3.net/2017/09/11/lateral-movement-using-excel-application-and-dcom/
Перенёс: Эрмано
Специально для XSS.IS
Еще в январе я опубликовал две записи в блоге об использовании DCOM для бокового перемещения; в одной я использовал MMC20.Application, а в другой - о двух других приложениях DCOM, которые отображают методы "ShellExecute". В то время как большинство методов имеют один способ выполнения (WMI имеет метод Create(), psexec создает службу с пользовательским binpath и т. д.), DCOM позволяет использовать различные объекты, которые открывают различные методы. Это позволяет оператору выбирать, как они выглядят, когда попадают на удаленный хост, с точки зрения отношений родительского и дочернего процессов.
В этом посте я расскажу о том, как злоупотреблять DCOM-приложением Excel.Application для выполнения произвольного кода на удаленном хосте. Об этом же приложении DCOM недавно рассказывали в статье про боковое перемещением с помощью метода RegisterXLL, о котором вы можете прочитать здесь.
В этом посте я сосредоточусь на методе "Run()". Вкратце, этот метод позволяет выполнить именованный макрос в указанном документе Excel. Вы, наверное, понимаете, к чему я веду
.
Как вы, наверное, знаете, макросы VBA давно стали излюбленным приемом злоумышленников. Обычно злоупотребление VBA заключается в отправке фишингового письма с документом Office, содержащим макрос, а также заманчивым текстом, чтобы склонить пользователя к включению этого вредоносного макроса. Разница в данном случае заключается в том, что мы используем макросы для поворота, а не для первоначального доступа. Поэтому параметры безопасности Office Macro - это не то, о чем нам нужно беспокоиться. Наш вредоносный макрос будет выполняться независимо от этого.
На данный момент мы знаем, что Excel.Application открывается через DCOM. Используя OLEViewDotNet Джеймса Форшоу (@tiraniddo), мы видим, что нет никаких явных разрешений на запуск или доступ:
Если приложение DCOM не имеет явных разрешений на запуск или доступ, Windows позволяет пользователям группы Local Administrator запускать приложение и получать к нему удаленный доступ. Это происходит потому, что приложения DCOM имеют набор разрешений на запуск и доступ "по умолчанию". Если явные разрешения не назначены, используется набор "По умолчанию". Его можно найти в файле dcomcnfg.exe, и он будет выглядеть следующим образом:
Поскольку локальные администраторы могут удаленно взаимодействовать с Excel.Application, мы можем удаленно инстанцировать его через PowerShell с помощью [Activator]::CreateInstance():
Как видите, удаленное инстанцирование прошло успешно. Теперь у нас есть возможность удаленно взаимодействовать с Excel. Далее нам нужно переместить нашу полезную нагрузку на удаленный хост. Это будет документ Excel, содержащий наш вредоносный макрос. Поскольку VBA позволяет получить доступ к Win32 API, возможности различных шеллкодов безграничны. В данном примере мы будем использовать шеллкод, запускающий calc.exe. Если вам интересно, вы можете найти пример здесь.
Просто создайте новый макрос, назовите его как угодно, добавьте код и сохраните его. В данном случае имя моего макроса - "MyMacro", и я сохраняю файл в формате .xls.
Когда фактическая полезная нагрузка создана, следующим шагом будет копирование этого файла на целевой хост. Поскольку мы используем эту технику для Lateral Movement, нам нужны права Local Admin на целевом хосте. Поскольку они у нас есть, мы можем просто скопировать файл:
Когда полезная нагрузка находится в цели, нам остается только выполнить ее. Это можно сделать с помощью метода Run() DCOM-приложения Excel.Application, которое было инстанцировано ранее. Прежде чем мы сможем вызвать этот метод, приложение должно знать, в каком файле Excel находится макрос. Это можно сделать с помощью метода "Workbooks.Open()". Этот метод просто принимает локальный путь к файлу. Что же произойдет, если мы вызовем этот метод и передадим расположение файла, который мы только что скопировали?
Ну, разве это не интересно? Файл существует, но Excel.Application утверждает, что его нет. Почему так происходит? Когда Excel.Application инстанцируется через DCOM, он фактически инстанцируется через идентификатор Local System. Пользователь Local System по умолчанию не имеет профиля. Поскольку Excel предполагает, что он находится в интерактивном сеансе пользователя, он терпит неудачу не самым изящным образом. Как мы можем это исправить? Есть и более эффективные способы, но быстрое решение заключается в удаленном создании профиля Local System.
Путь для этого профиля будет таким: C:\Windows\System32\config\systemprofile\Desktop and C:\Windows\SysWOW64\config\systemprofile\Desktop.
Теперь, когда профиль Local System создан, нам нужно заново создать объект Excel.Application, а затем снова вызвать "Workbooks.Open()":
Как видите, теперь мы смогли открыть рабочую книгу, содержащую наш вредоносный макрос. Теперь все, что нам нужно сделать, это вызвать метод "Run()" и передать ему имя нашего вредоносного макроса. Если вы помните, я назвал свой макрос "MyMacro".
Вызов команды "Run(myMacro)" приведет к выполнению VBA в этом макросе. Чтобы убедиться в этом, мы можем открыть Process Explorer на удаленном хосте и проверить. Как вы можете видеть ниже, на этом конкретном узле установлен GPO "Disable VBA for Office Applications". Независимо от этого параметра безопасности макросу разрешено выполняться:
В данном примере я просто использовал шеллкод calc spawning, в результате чего под Excel.exe был порожден дочерний процесс. Помните, что, поскольку VBA предлагает много возможностей для взаимодействия с ОС, можно не порождать дочерний процесс и просто внедриться в другой процесс. Последними шагами будет удаленная очистка объекта Excel и удаление полезной нагрузки с целевого хоста.
Я автоматизировал эту технику с помощью PowerShell, которую вы можете найти здесь: https://gist.github.com/enigma0x3/8d0cabdb8d49084cdcf03ad89454798b
Чтобы смягчить этот вектор, можно вручную применить разрешения на удаленный запуск и доступ к объекту Excel.Application... но не забудьте посмотреть на все остальные приложения Office. Еще одним вариантом может быть изменение стандартных DACL удаленного запуска/доступа с помощью dcomcnfg.exe. Помните, что любые изменения DACL должны быть протестированы, поскольку такие модификации могут потенциально повлиять на легальное использование. Кроме того, включение брандмауэра Windows и уменьшение числа локальных администраторов на хосте также являются эффективными мерами по снижению риска.
Больше всего в этой технике выделяется то, что Excel и дочерний процесс будут запускаться под именем вызывающего пользователя. Часто такие процессы создаются под учетными записями пользователей, которые отличаются от пользователя, вошедшего в систему в данный момент. Если это только два процесса и используемая учетная запись пользователя обычно не входит в систему на этом хосте, это может быть тревожным сигналом.
Перенёс: Эрмано
Специально для XSS.IS
Еще в январе я опубликовал две записи в блоге об использовании DCOM для бокового перемещения; в одной я использовал MMC20.Application, а в другой - о двух других приложениях DCOM, которые отображают методы "ShellExecute". В то время как большинство методов имеют один способ выполнения (WMI имеет метод Create(), psexec создает службу с пользовательским binpath и т. д.), DCOM позволяет использовать различные объекты, которые открывают различные методы. Это позволяет оператору выбирать, как они выглядят, когда попадают на удаленный хост, с точки зрения отношений родительского и дочернего процессов.
В этом посте я расскажу о том, как злоупотреблять DCOM-приложением Excel.Application для выполнения произвольного кода на удаленном хосте. Об этом же приложении DCOM недавно рассказывали в статье про боковое перемещением с помощью метода RegisterXLL, о котором вы можете прочитать здесь.
В этом посте я сосредоточусь на методе "Run()". Вкратце, этот метод позволяет выполнить именованный макрос в указанном документе Excel. Вы, наверное, понимаете, к чему я веду
.Как вы, наверное, знаете, макросы VBA давно стали излюбленным приемом злоумышленников. Обычно злоупотребление VBA заключается в отправке фишингового письма с документом Office, содержащим макрос, а также заманчивым текстом, чтобы склонить пользователя к включению этого вредоносного макроса. Разница в данном случае заключается в том, что мы используем макросы для поворота, а не для первоначального доступа. Поэтому параметры безопасности Office Macro - это не то, о чем нам нужно беспокоиться. Наш вредоносный макрос будет выполняться независимо от этого.
На данный момент мы знаем, что Excel.Application открывается через DCOM. Используя OLEViewDotNet Джеймса Форшоу (@tiraniddo), мы видим, что нет никаких явных разрешений на запуск или доступ:
Если приложение DCOM не имеет явных разрешений на запуск или доступ, Windows позволяет пользователям группы Local Administrator запускать приложение и получать к нему удаленный доступ. Это происходит потому, что приложения DCOM имеют набор разрешений на запуск и доступ "по умолчанию". Если явные разрешения не назначены, используется набор "По умолчанию". Его можно найти в файле dcomcnfg.exe, и он будет выглядеть следующим образом:
Поскольку локальные администраторы могут удаленно взаимодействовать с Excel.Application, мы можем удаленно инстанцировать его через PowerShell с помощью [Activator]::CreateInstance():
Как видите, удаленное инстанцирование прошло успешно. Теперь у нас есть возможность удаленно взаимодействовать с Excel. Далее нам нужно переместить нашу полезную нагрузку на удаленный хост. Это будет документ Excel, содержащий наш вредоносный макрос. Поскольку VBA позволяет получить доступ к Win32 API, возможности различных шеллкодов безграничны. В данном примере мы будем использовать шеллкод, запускающий calc.exe. Если вам интересно, вы можете найти пример здесь.
Просто создайте новый макрос, назовите его как угодно, добавьте код и сохраните его. В данном случае имя моего макроса - "MyMacro", и я сохраняю файл в формате .xls.
Когда фактическая полезная нагрузка создана, следующим шагом будет копирование этого файла на целевой хост. Поскольку мы используем эту технику для Lateral Movement, нам нужны права Local Admin на целевом хосте. Поскольку они у нас есть, мы можем просто скопировать файл:
Когда полезная нагрузка находится в цели, нам остается только выполнить ее. Это можно сделать с помощью метода Run() DCOM-приложения Excel.Application, которое было инстанцировано ранее. Прежде чем мы сможем вызвать этот метод, приложение должно знать, в каком файле Excel находится макрос. Это можно сделать с помощью метода "Workbooks.Open()". Этот метод просто принимает локальный путь к файлу. Что же произойдет, если мы вызовем этот метод и передадим расположение файла, который мы только что скопировали?
Ну, разве это не интересно? Файл существует, но Excel.Application утверждает, что его нет. Почему так происходит? Когда Excel.Application инстанцируется через DCOM, он фактически инстанцируется через идентификатор Local System. Пользователь Local System по умолчанию не имеет профиля. Поскольку Excel предполагает, что он находится в интерактивном сеансе пользователя, он терпит неудачу не самым изящным образом. Как мы можем это исправить? Есть и более эффективные способы, но быстрое решение заключается в удаленном создании профиля Local System.
Путь для этого профиля будет таким: C:\Windows\System32\config\systemprofile\Desktop and C:\Windows\SysWOW64\config\systemprofile\Desktop.
Теперь, когда профиль Local System создан, нам нужно заново создать объект Excel.Application, а затем снова вызвать "Workbooks.Open()":
Как видите, теперь мы смогли открыть рабочую книгу, содержащую наш вредоносный макрос. Теперь все, что нам нужно сделать, это вызвать метод "Run()" и передать ему имя нашего вредоносного макроса. Если вы помните, я назвал свой макрос "MyMacro".
Вызов команды "Run(myMacro)" приведет к выполнению VBA в этом макросе. Чтобы убедиться в этом, мы можем открыть Process Explorer на удаленном хосте и проверить. Как вы можете видеть ниже, на этом конкретном узле установлен GPO "Disable VBA for Office Applications". Независимо от этого параметра безопасности макросу разрешено выполняться:
В данном примере я просто использовал шеллкод calc spawning, в результате чего под Excel.exe был порожден дочерний процесс. Помните, что, поскольку VBA предлагает много возможностей для взаимодействия с ОС, можно не порождать дочерний процесс и просто внедриться в другой процесс. Последними шагами будет удаленная очистка объекта Excel и удаление полезной нагрузки с целевого хоста.
Я автоматизировал эту технику с помощью PowerShell, которую вы можете найти здесь: https://gist.github.com/enigma0x3/8d0cabdb8d49084cdcf03ad89454798b
Чтобы смягчить этот вектор, можно вручную применить разрешения на удаленный запуск и доступ к объекту Excel.Application... но не забудьте посмотреть на все остальные приложения Office. Еще одним вариантом может быть изменение стандартных DACL удаленного запуска/доступа с помощью dcomcnfg.exe. Помните, что любые изменения DACL должны быть протестированы, поскольку такие модификации могут потенциально повлиять на легальное использование. Кроме того, включение брандмауэра Windows и уменьшение числа локальных администраторов на хосте также являются эффективными мерами по снижению риска.
Больше всего в этой технике выделяется то, что Excel и дочерний процесс будут запускаться под именем вызывающего пользователя. Часто такие процессы создаются под учетными записями пользователей, которые отличаются от пользователя, вошедшего в систему в данный момент. Если это только два процесса и используемая учетная запись пользователя обычно не входит в систему на этом хосте, это может быть тревожным сигналом.