其可用命令为攻击者提供了对受感染系统的实用控制能力,包括:
其中,upload命令尤其值得注意。它可以从攻击者指定的URL下载一个可移植可执行文件,将其以DLL形式保存到用户本地的OneDrive目录,然后停止OneDrive进程,利用合法的OneDrive可执行文件加载这个恶意库。已报告的样本会将文件命名为wtsapi32.dll,并放置在%LocalAppData%\\Microsoft\\OneDrive下。
这是一种DLL侧载技术:恶意代码被放在可信程序附近,借助程序原本的库加载行为执行。防守方不应仅因为系统安装了OneDrive就判定异常,更有价值的检测信号是:合法OneDrive程序从异常的用户可写目录加载了不应出现的DLL,或随后启动了异常子进程。
C2Looper会在运行时使用XOR解密字符串,据报道重复使用一个8字节密钥;同时还会通过LoadLibrary和GetProcAddress动态解析Windows API。这些做法可能降低单纯静态分析的效果,也使终端检测与响应(EDR)系统收集的运行时行为更加重要。
每台受感染主机都会被分配一个独立的仓库目录。植入程序读取其中的cmd.json,执行文件中指定的操作,再将输出写入同一目录下的result.json。这为攻击者提供了一种基于文件的工作流:通过GitHub下发命令,并回收执行结果,无需维护一个明显的专用C2服务器。
由于GitHub同时也是合法的开发和企业服务,单纯依靠域名封锁可能难以有效应对这种方式。更实际的做法是进行行为分析:调查并不需要开发服务的终端为何周期性访问GitHub仓库或API,同时区分可疑的按主机划分的JSON活动与正常的开发、自动化或CI/CD流量。
ThreatLabz以低到中等置信度评估,C2Looper可能通过多阶段ClickFix感染链投递。在这类攻击中,受害者可能看到伪造的验证提示、浏览器错误、CAPTCHA验证码或“系统修复”信息,随后被诱导将一条命令复制并运行到PowerShell、Windows“运行”对话框或其他命令界面中。
这使得用户操作本身成为重要的拦截点。正常的网站或浏览器提示不应要求用户为了完成验证或修复问题,把命令粘贴到PowerShell、Terminal或“运行”窗口中。
相关报道还讨论了Teams语音钓鱼(vishing)和Quick Assist滥用等更广泛的社会工程活动。但现有材料并不能证明所有这类活动都投递了C2Looper,因此这些联系应被视为可能存在的背景,而不是已经确认的同一攻击活动。
与其试图封锁所有可能被滥用的工具和服务,组织不如围绕以下高价值行为进行检测:
/api/beacon和/api/result/的请求,并将其与新出现或可疑的进程关联分析。cmd.json和result.json的按主机划分目录。不要无差别封锁GitHub,应先纳入正常开发和自动化工作流进行区分。cmd.exe、“运行”对话框活动、系统信息收集、分阶段下载,以及新出现二进制文件发起的Shell执行。技术控制需要与社会工程防护同时推进。在业务允许的情况下,组织应限制或严格管理用户发起的PowerShell、脚本宿主、未签名二进制文件,以及从用户可写目录执行程序的行为。应用程序白名单也能进一步降低下载载荷成功运行的概率。
安全团队还应培训员工和帮助台人员:网站、CAPTCHA页面、浏览器错误提示或未经请求的“技术支持”联系人,都不应要求用户粘贴并执行命令。远程支持工具应纳入批准流程,使用经过验证的支持渠道、强身份认证、会话记录,并及时复核异常远程连接。
网络分段、最小权限、多因素认证、及时修补互联网暴露系统,以及经过测试的离线或不可变备份,都能在C2Looper建立据点后限制潜在损失。如果终端出现可疑信标、Shell活动或DLL侧载,应立即隔离该设备,同时保留终端日志、网络记录,并在适当情况下采集内存以供调查。
C2Looper的关键意义,在于它正从相对直接的HTTP后门,发展为能够利用GitHub仓库承载运营流程的更灵活植入程序。其远程Shell、主机侦察、文件下载和更新能力,使其可能成为勒索软件相关入侵的初始据点。但现有证据仍不足以给出确定归属,相关研判应保持谨慎。
对组织而言,最有效的防守组合是:建立抵御ClickFix的用户操作规范,同时持续追踪异常命令执行、OneDrive DLL侧载、高频HTTP轮询,以及没有业务理由的GitHub仓库活动。