名字的来源与背景

FontOnLake这个名字来源主要延用了ESET的一篇文章，URL:https://www.welivesecurity.com/2021/10/07/fontonlake-previously-unknown-malware-family-targeting-linux/，因为在企业内部有命中相关的IOC之后，我们开始关注到这一个组织。通过这一年的观察分析发现，该组织主要以游戏行业为目标，以web打点手法为主，主要目标为游戏公司。采用公网打点、内网横向拓展，其目标主要为窃取jenkins、gitlab、svn包含企业核心源码资产。本文也讲述了我们与其一年多来与其对抗及其进行安全建设短板补齐的漫漫长路。

攻击溯源的慢慢长路-2022年

原始攻击事件-事件1-公网入侵

这是一个我还没入职之前的应急事件，通过翻阅该报告，我得知了一些线索：

1.公司之前被该组织入侵过，xxxxxxx（此处打码）

2.攻击者已经掌握了部分我司的敏感信息。

以下是事件1详细信息

攻击行为:NC反弹导致HIDS告警

攻击者通过利用网站远程命令执行漏洞在某个子域名进行nc反弹，并且获取到shell权限。并且在该网站留下来webshell后门一句话。

并且在容器内下载并且使用了内网穿透工具nb。

通过进程信息发现将内网某个机器进行了转发

该业务为我们的核心业务gitlab，同时发现丢失了部分账号，例如，s****、ladp****。

处置方法：封禁已知IOC出网，下线被攻击域名进行漏洞修复，对已泄露密码进行更改。

原始攻击事件-事件2-内网扫描

收到其他部门业务通知，发现我司资产在对内网ssh有扫描行为，开始了排查。

攻击行为：收到通知发现正在扫描

依旧发现了这个名为nb的工具，并且进行了外网转发，通过排查发现该机器存在弱口令情况。

处置：封禁已有IOCIP出网，弱口令机器密码整改。

原始攻击事件-事件3-威胁情报命中

通过dns威胁情报发现恶意域名访问记录，由此我们也是确定了这个组织的身份叫FontOnLake。

通过机器进行上机排查发现有落地木马文件

并且通过排查发现丢失原因依旧为内网机器弱口令，以及部分gitlab账号密码丢失情况

处置措施：对已有IOC进行IP封禁，进行内网网段弱口令扫描，针对已知弱口令机器进行处理。

以上应急事件也是在我入职之前发生的， 按照安全部门入职惯例，每次来新人之前我们都会遭受一波攻击，我来的时候也不例外。那时候老板想让我提前入职来解决问题，但是那时候我沉迷于老头环因此并未采纳这个想法，所以也间接的导致了木马其实没有清理干净，由此也拉开了我们与该组织的漫漫攻防之路。

事件4-HIDS告警-1

通过HIDS获取到攻击事件告警

从这个告警进行一步步的溯源发现，攻击者此次利用了两个漏洞进行攻击

1.YII2反序列化-CVE-2020-15148

2.SSRF漏洞

主要行为特征是：

1.利用SSRF漏洞结合之前攻击获取到的redis密码进行redis的rce操作，但是大部分被waf拦截了，因此判断为失败。

2.通过利用反序列化漏洞进行进行获取机器权限，并且因为机器出网进行了上线C2操作，同时通过代理进入内网进行扫描行为。

处置：

SSRF漏洞修复、YII2框架漏洞修复，并且针对其他采用相同框架漏洞进行排查修复。由于接入了waf，排查为何waf没有拦截这么明显的攻击时发现，在当时的状态下面该类攻击被waf判断为中危告警，但是我们并未针对中低危进行拦截。因此我们也对waf规则进行了调整优化，并且针对攻击者后续操作进行了行为分析，处置了数台失陷机器。处置方法也算是比较粗暴，但是处理不干净我们直接选择了重装失陷的机器，这里也需要感谢运维部门积极配合。

事件5-安全厂商通告

本次事件可以追溯到2020-2021年期间，由于一些供应链原因导致内部机器失陷，并且在被外部安全厂商通知有winnit组织在内部进行活跃，通过给到的回连进行分析发现。该组织已经在我们这里处于backup状态，通过之前以及后续的研判发现，FontOnlake也可能归因于winnit，属于他们的一个分支状态？这里仅仅持一个怀疑状态。但是通过排查发现，失陷机器并未处于活跃状态，并且我们未能发现的原因在于该机器dns使用了公网公用Dns，并未使用公司自有的Dns服务器，同时通过分析恶意木马文件分析发现以下行为：

1.伪装成内核进程

2.获取CC地址建立连接并且接受CC指令

接受的指令比如有：ptythread建立双向通信通道，执行文件相关操作，端口映射转发，隐藏进程等操作。

同时发现该木马会替换系统本身常见命令文件，进行埋入后门操作等。因此在应急响应中，建议自带busybox进行命令执行排查。

处置：

此次主要深度分析了该木马如何运行并且释放文件之后的一些操作，因为处于休眠状态所以在联合安全厂商分析完成并且打包了相关样本之后直接粗暴的删除了该机器。

事件6-HIDS告警-2

本次事件正好也是在我们进行更换HIDS期间，我们正好也在属于现有新的HIDS设备时发现有一则内网爆破行为。这里我们也推荐一波字节出品的ELKEID-HIDS安全产品，比较符合安全人员的思维。

通过该告警我们排查发现，该机器归属于一位已离职的同事，并且该机器并未在我们的标准化范围里面，密码也未进行统一管理，因此明显存在着弱口令机器。并且通过排查发现该同事下属的所有测试机均为同一弱口令，并且已经处于失陷状态。

并且碰到了我们的老朋友工具：nb

并且在进一步的排查发现，机器一部分存在被基于密钥登陆过，并且在这里我们发现了失陷了一堆机器，全部都是基于密钥登录之后失陷。同时也发现公司内部存在违规使用FRP代理向公网暴露应用情况。

处置：在针对排查之后，将判定为失陷的机器进行处理，重装或清理木马操作。同时针对服务器管理混乱的情况进行整改，针对前面应急中存在大量资产未进行标准化以及安装HIDS操作进行整改。对员工离职后，服务器资产未进行闭环操作进行整改，将禁止使用隧道等私自将内网暴露在公网的操作纳入到日常监控范围。

由于部分日志缺失，因此并未溯源到实际攻击源头，因此只是针对此次事件发现机器拓展出来的机器进行处理。

事件7-HIDS告警-3

通过新的HIDS接入飞书告警之后，在飞书告警中发现有机器又在进行ssh爆破操作，因此产生了本次应急。

在应急初期发现linux基本命令有被篡改痕迹，因此采用了自带的busybox进行排查，并且成功发现了回连的恶意IP

同时利用HIDS的网络日志进行分析发现拓展是否有别的机器进行外连行为拓展。

通过往上溯源发现该失陷机器曾经被vpnIP连接过，通过日志进一步定位发现一个敏感账户丢失。

通过上图获取到的real_ip(即本次攻击IP)进行进一步拓展发现其他丢失账户，并且关联出新的恶意IP

处置：对相关机器进行处置，针对失陷账号进行处理，重新划分相关应用关联的账号。

同时在这里我们也产生了一个疑问，登录VPN需要进行双因素的验证，但是攻击者为什么能通过双因素验证进入内网。是否是双因素验证失效？

Ldap账户另外一个身份是域管账户，在后续的日志分析中发现，我们的域控hash有被dump的迹象。。。。

于是，我们又有了下面的故事。

事件8-全流量告警

通过前面的事件，由于当时上海在众所周知的原因，我们无法沟通到新安全设备，因此在idc里面启用了一个很久没有启用的全流量设备。并且本次安全事件中，也是利用全流量发现了攻击产生了应急。

你可能会有疑问，这个告警跟该组织有什么关系，但是通过这个告警我们关联到这个来源IP其实是我们公司的出口，我们公司出口对外有rsync攻击。通过继续跟进下去发现有一个kdebug文件在流量中传输并且报毒

让我来看看都有谁下载了这些文件！

由于这个IP是nat后的地址，经过一系列的操作查询之后我们得到了真实的内网IP，打开history我们发现了攻击者的一些操作。

另外基于HIDS的网络日志查询发现有一个IP高度可疑：8.218.59.26

通过查询该IP对应解析地址为：html.tashidaneicun.com，该域名在历史FontOnLake报告中并未发现该域名，但是我们通过多次数据关联后分析发现，该域名可能为FontOnLake新启用的一个域名，木马行为特征以及攻击手法高度相似，因此判断归因到FontOnLake。

处置：针对获取到的多个Kdebug文件进行hash计算，在所有机器上进行hash扫描，排查失陷主机，针对涉及到的公钥文件进行删除，并且在流量侧进行多日观察、监控以此来判断是否清理干净。同时在IDC、办公网出口防火墙进行相关域名IP封禁处理。

疑问和反思：私有云可以进行利用边界防火墙设备进行拦截封禁操作，但是涉及到公有云如何进行快速批量的进行封禁或者采用操作，安全组、iptables对于运维来说工作量还是较为巨大。

同时在应急中发现，有些部分涉事机器已经提出回收申请，但是迟迟未删除机器，这也是后续要整改的一些问题。

另外如何快速的在每次应急中批量筛选存在相同公钥在.ssh/目录下面的一个问题。

事件9-蜜罐之VPN

此次事件缺少详细记录，所以大部分采用文字叙述方式进行。

通过之前应急，我们也不断的在反思和总结，正好发现微步发布了开源的HFish蜜罐，因此我们在内网选择了一些点位进行部署。在部署之后没多久我们就迎来了第一次基于蜜罐攻击的告警。

攻击路径:蜜罐发现VPN网段进行扫描192.168/16网段。

在获取到VPN相关IP之后，我们也并未急于把攻击者断线操作，我们对该vpn进行了一段时间的tcpdump流量抓包之后才断开了该IP。

并且我们在流量包中分析到了新失陷的账号，以及我们核心的域管用户账号丢失。同时我们也发现了，我们核心的二次验证服务器也在此次事件中丢失，因此我们选择了重建了相关服务器，并且开始把预警信息开始全员通知。准备着手全员密码更改。针对域管此次丢失账户，我们也深入的进行了设备查杀，清理了相关可疑程序。

事件10-蜜罐之内网扫描

通过基于蜜罐的告警，我们又成功的捕获了一次攻击。

由于凌晨应急不太好联系到人，因此我们在进行了一个简单的处理之后就又舒舒服服睡大觉了，可惜谁知道六点多又来了，三点失陷的机器排查发现利用python读取了相关的shellcode并且执行。

这也是我们距离攻击者最近的几次之一：

我们凌晨在简单的处理之后，攻击者再度重新登录上来进行操作。由于本次失陷机器是jira，所以在数据库中捞了用户的异常登录日志，发现有大量运维账户异常登录。在这里我们可以比较明显的知道了，在VPN那次事件中，我们的域用户hash可能真的丢失了。

同时我们确定了其他丢失的机器都是由于48这个IP访问发起的，因为是精准的采用了密码登录，所以我们当时并未发现48是怎么丢失的。但是我们基于此次事件注意到了我们曾经忽视的一个地方，那就是exchange邮箱。

处置：相关恶意IP在墙上封禁，用户登录方式集中至跳板机，收紧root密码范围，SVN代码拉取异常告警，以及邮箱相关日志进行收集。

以及在综合分析下来之后我们做出了全员修改密码的决定，强制每个用户在一定的时间内修改密码，并且不能跟之前密码相同。

邮箱以及OTP揭秘

在分析了邮箱的日志之后，我们发现了一个涉及VPN丢失的攻击链路

攻击链路：历史原因->0428事件中ldap丢失，获取到域hash->通过公网imap登录用户邮箱（imap未启用二次验证）->获取失陷账户OTP的手机令牌绑定二维码->通过账号密码+OTP进行VPN登录。

在这里我们发现了一个致命的问题，OTP在用户申请手机令牌时，会向用户邮箱发送一个二维码进行手机令牌绑定，但是该二维码永不失效并且可以重复绑定。这就导致了用户在使用了之后，攻击者在看到该邮件时也可以进行绑定，导致了攻击者可以直接无视二次验证登录VPN。并且在以往丢失的账号中发现了一个特征，这些账户其实并不都是个人在使用，大量的失陷账户都是公共账户，这种不在密码三月一次更改范围之内，属于漏网之鱼。因此导致这些账户在不出事的时候就不会想到更改密码的操作。

处置：联动厂商修补二次验证绑定问题，并且关闭了邮箱IMAP外网访问等操作。

反思：非人账户的管理以及安全管控。由于非人账户的问题，我们在后面也吃过一次亏，针对邮箱的诈骗中也是因为公共账户导致的垃圾邮件问题。所以在甲方安全中，公共账户如何更好的保护？

事件11-HIDS告警4

我们在之前的应急中也不断的吸取教训，不断的在完善HIDS覆盖以及服务器标准化的覆盖，此次也算是在覆盖中发现了新的攻击行为

在发现了相关的操作后发现，最后该机器回连了一个域名hm2.yrnykx.com，这个对应上了开头ESET报告中的IOC。并且在此次应急中发现，攻击者利用了常见的内网扫描工具fscan针对内网横向，同时依旧进行ssh进行爆破，爆破不单单是利用密码，也会把自己收集到的私钥加入到扫描中以此来拓展相关机器。

处置：封禁相关恶意IP，删除相关涉事密钥，删除涉事主机（因为已经无用）

反思：此次丢失的都是一部分僵尸资产，因此在实际的安全运营中也需要考虑一些僵尸资产在内网的失陷。同时如何发现无用以及僵尸资产也是在甲方的日常运营中可以做的一个模块，在降本增效的今天发现僵尸资产不仅可以节约一些成本也可以降低机器失陷的概率。

事件12-Fscan的疯狂

基于HIDS的监控，发现两台机器被下载了fscan并且发起了B段的扫描行为，同时下载地址的IP又能跟0413事件中的IP对应上因此又时归因于FontOnlake。

基于失陷机器，我们查询了hids的login登录日志

发现也是基于密钥方式登录

另外一台机器也是基于密钥登录，由于这两台失陷机器也有公网IP，因此导致机器直接被从公网采用密钥的方式登录进来。

本次也是很及时的发现，并且在机器上直接获取到了攻击者在机器上留下的文件，并且在留下的文件中成功得到了我司大量的私钥文件。

处置：清理相关涉事密钥，继续推进HIDS以及标准化覆盖。

基于攻击者遗留的工具以及文件，针对我司所有的资产进行排查扫描，排查出来的全部进行进行处理，进一步的缩小了能给到攻击者的攻击面。

同时在此次的事件中已经发现，我们丢失的网段逐渐从核心网段慢慢开始往外部隔离网段转移，每次进来获取的内容已经是寥寥无几或者说已经开始碰不到核心了。这也是一个逐渐向好的征兆。

反思：由于HIDS每日产生的告警会有一定的数量级，导致在日常的安全运营中会有一部分疲劳，因此HIDS告警的准确性需要在后期逐渐的拉升。

事件13-最后的疯狂

由于前期的应急处置以及整改，导致攻击面在大量的收缩之后，我们已经快完成90天无FontOnLake应急响应事件的小目标的时候，他们又来了。

通过HIDS的告警，我们发现此次的攻击路径是基于腾讯云的Accesskey泄露导致的。

异常目录/tmp/tat_agent为腾讯云自动化助手目录，查看该目录下告警脚本为反弹shell脚本，base64解码后发现外连IP：34.150.19.57，该IP最早于0621事件中登录VPN记录中发现。

处置：排查GITLAB仓库中所有现存AK信息，并且针对AK进行重置。将代码中存在的密码以及AK纳入到治理日常，考虑采用配置中心存储敏感信息，取消在代码中直接明文存储。

总结

经过22年一年的对抗，以及在23年的维护，我们总算是将FontOnLake从我们的内网中逐步的清除出去，同时我们也大力的收缩了攻击面。虽然胜利来之不易，但是我相信也只是暂时的，我们只有保持运营闭环，针对告警及时分析、处理，关联相关IOC以及联动其他厂商同步情报，才能将包括FontOnLake在内的更多的攻击长久的拒之门外。