【问题标题】:PsExec works only with "runas /netonly", not with -u and -p parametersPsExec 仅适用于“runas /netonly”,不适用于 -u 和 -p 参数
【发布时间】:2018-04-03 20:28:03
【问题描述】:

我的意思:

如果我...

  1. 运行runas /netonly /user:computername\username cmd

  2. 输入本地管理员帐户“用户名”的密码

  3. 然后输入psexec \\computername cmd

我现在有一个工作 shell,可以在远程机器上以本地管理员用户身份运行命令。

然而,尝试在 没有 runas... 的情况下运行这个 而不是 使用 psexec 的用户名和密码参数返回一个访问被拒绝错误。

下面的例子:

psexec \\computername -u username -p password cmd

Access Denied

注意:其他人似乎也有这个问题。 我提炼的问题:

  • 这是预期的行为吗?
  • 为什么还有-u-p

我还尝试在我的机器和目标机器上禁用防火墙,并添加列出的注册表项here

【问题讨论】:

    标签: cmd psexec sysinternals


    【解决方案1】:

    当您启动与PsExec.exe 的连接时,它会尝试使用您当前通过身份验证的凭据将PSEXESVC 复制到\\$machine\ADMIN$\System32 共享VIA SMB,从而启用通信使用您的PsExec.exe$machine 的服务。

    如果您当前登录的用户帐户无权访问\\$machine\ADMIN$\System32 并且无法安装/启动服务,那么这将不起作用。

    假设如果您可以使用您的用户帐户访问这将起作用。

    Here is a very interesting article from 2004 on reverse-engineering of the original implementation。我很确定它在那个时候随着 Windows 7 和 Windows 10 发生了变化。

    【讨论】:

    • 我明白了。这可以解释为什么使用 runas 有效。但是为什么还有一个选项可以将本地用户名和密码与 psexec 一起传递呢?
    • @MinimumEntropy 我真的不知道,但几周前我遇到了同样的问题,浪费了我很多时间。
    猜你喜欢
    • 2015-09-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-05-13
    • 2017-06-30
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多