Выполнить команду на удаленном компьютере и показать пользовательский интерфейс для вошедшего в систему пользователя

Вы обнаружите, что это будет чрезвычайно сложно, если вообще возможно. Вы могли подумать, что это будет легко, но это не так. Microsoft намеренно усложнила эту задачу, потому что она раскрывает тип уязвимостей безопасности («разрушительные» атаки), если вы можете манипулировать оконным менеджером в контексте безопасности другого пользователя.

В Сессия 0 Изоляция функция, представленная в Windows Vista, затрудняет выполнение служебной программы (например, PsExec) для взаимодействия с консолью. Когда служба обнаружения интерактивных служб запущена, при попытке службы взаимодействовать с консолью пользователю будет предложено переключиться на безопасный рабочий стол для взаимодействия с графическим интерфейсом службы.

Есть некоторые обсуждение Stackoverflow это немного углубляется в детали архитектуры.

Лучшим способом справиться с этим было бы, чтобы пользователь запускал процесс, который прослушивает какой-либо тип межпроцессного взаимодействия и действует соответственно. Если вы хотите стать действительно хакерским, вы можете запустить простой сценарий VBScript или Powershell, который работал в фоновом режиме, когда пользователь вошел в систему и ждал записи файла / реестра / TCP-соединения / и т. Д., А затем принимал меры. Вы можете довольно быстро сколотить что-то подобное в качестве доказательства концепции.

спасибо за советы и подсказки - я сделал следующее

function startChromeRemotely($client) {
    $desktopSession = query user /server:$client | Select-String -Pattern Active
    $desktopSessionId = ($desktopSession -split '\s+')[3]
    .\PsExec.exe -i $desktopSessionId -d \\$client -u someuser-p somepassword "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
}

Итак, в основном то, что я делаю, - это сначала вызываю сеанс рабочего стола зарегистрированного («активного») пользователя, а затем «вставляю» хромированный экран прямо в сеанс пользователя. Если он выполняется как администратор домена, это работает нормально, но почему-то кажется странным / нестабильным. Может кто-нибудь сказать мне, почему ?

Еще раз спасибо :)

Как сказал Эван, это намеренно затруднено, потому что это очень легко использовать и использовать злонамеренно.

Но вы можете это сделать, если у вас достаточно преданности делу и вы готовы запачкать руки.

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

Ключ - это CreateProcessAsUser Функция API из Advapi32.dll.

И чтобы использовать эту функцию, вы должны иметь возможность «украсть» первичный токен доступа вошедшего в систему пользователя. И для этого вы можете использовать WTSQueryUserToken Функция API из Wtsapi32.dll.

Одним из ограничений использования вышеупомянутого API является то, что его можно вызывать только из контекста безопасности локальной системы - вот почему PsExec.exe -si 2 \\Test-CLI-01 calc.exe работает на вас - потому что -s переключатель там указывает PsExec работать как локальная система.

Это, естественно, один из тех случаев, когда ваша служба Windows будет выполняться как локальная система, поскольку она вам потребуется, если вы хотите использовать WTSQueryUserToken. Следует отметить, что запуск программы или службы в качестве локальной системы, как правило, является плохой идеей, потому что локальная система имеет неограниченный доступ к машине, на которой она выполняется, поэтому, если хакер использует уязвимость в вашей программе, он или она может использовать этот эксплойт, заставляющий ваш код выполнять некоторые действия со всеми привилегиями безопасности, которые предоставляет контекст безопасности локальной системы. (т.е. все они.)

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

Несколько полезных примеров, взятых из некоторого C #, которое я написал некоторое время назад:

Получение токена первичного доступа пользователя:

WTSQueryUserToken((uint)session.SessionId, out userPrimaryAccessToken) 

Использование этого основного токена доступа для запуска процесса в своем сеансе от имени этого пользователя:

CreateProcessAsUser(userPrimaryAccessToken, null, cmdLine, ref saProcessAttributes, ref saThreadAttributes, false, 0, IntPtr.Zero, null, ref si, out pi)

Это просто вызовы Windows API ... вы можете воспроизвести его на любом языке, который захотите.