正文
攻击者的签名非常有趣，因为他们通过同一台设备上进行了许多不同的不法活动，而且显然在过去的3年中并没有被暂停。很难搞清楚他们在Adidas、ISG Latam和调制解调器黑客事件中的意图，因为它们都来自同一个IP地址。这个IP地址可能已经在多年中几经易手，但又似乎不太可能，因为各个事件之间的间隔很长，而且不太可能立即重新分配给另一个不法团伙。
此时，我突然想起被感染的设备仍在运行，于是我走过去，拔下插头，然后把它放进了一个纸箱。
4、提供证据
我使用的调制解调器是Cox Panoramic Wifi网关。
在得知该设备很可能被入侵后，我去了当地的Cox商店，向他们展示了我的设备，并要求换一个新的设备。
这个请求的唯一问题是，为了换取新的调制解调器，我必须交出旧的。
可悲的是，这台设备并不是我的财产，而是我跟ISP租来的。
我向Cox的员工解释，我想要保留这台设备，并实施逆向工程。
他们瞪大了双眼。
看似他们并不想把设备还给我。
我问道：
“我不能保留这台设备吗？
”ISP的代表说：
“不行，我们必须拿走旧设备，才能给您一台新设备”。
没有商量的余地。
尽管我很想拆开设备，转储固件，看看能否发现任何潜在的被入侵痕迹，但可惜我已经把设备交给了员工。
于是，我拿起新设备离开了商店。
我感到很失望，因为我没法进行进一步的调查了。
设置好新的调制解调器后，以前的行为完全停止了。
我的流量不会再被重复发送了。
日志中也没有“其他IP”。
一切看似都修好了。
我已经无法调查自己的调制解调器是如何被入侵的，我有点失望。
因为我已经把设备交给了ISP，并换取了新设备，所以我只能检查电脑是否被入侵，除此之外，什么都做不了。
我放弃查找原因。
至少短期内只能这样了。
5、三年后
三年后，也就是2024年初，我和一些从事网络安全工作的朋友一起去度假。
晚餐期间，我向他们讲述了这个故事。
他们饶有兴致，要求我详细讲述所有细节，而且他们认为亲自调查一次会很有趣。
引起他们注意的第一件事是两个邮件服务器域名的格式（limit742921.tokyo 和 jingoism44769.xyz）。他们提取了limit742921.tokyo的mx1子域名的IP地址，然后对所有曾经指向同一个IP地址的域名进行了反向IP搜索。结果发现有超过1,000个域名都遵循完全相同的模式……
他们找到的每一个IP地址注册的域名都使用了相同的命名规则：
[1个单词][6个数字].[顶级域名]
由于注册地址的域名和算法结构的数量很大，我们认为这是恶意软件运营商使用的域名生成算法，用于轮转解析C＆C服务器的地址，以达到混淆视听的目的。反复发送我的流量的IP地址很有可能是一个C&C服务器，我认为是邮件服务器的两个域名实际上是算法生成的指向C&C服务器的指针。
有些令人失望的是，这些域名都已成为历史，最后一个注册于2023年3月17日。我们无法再解析这些域名，也找不到任何类似的注册到同一个IP地址的域名。
鉴于我之前的调制解调器被入侵了，而新设备是同一型号，我很好奇攻击者是否找到了重新入侵的方法。在网上快速搜索了一番后，我了解到我的调制解调器型号并没有公开的漏洞，如今已事隔三年，如果存在漏洞，他们也做好了保密工作。
另一种可能性是，他们利用的漏洞并非出自通用路由器，而且看似这种可能性更大。我非常好奇，想要调查一下我的设备可能是如何被入侵的。
6、利用TR-069协议攻击REST API
回到家后，恰好一位好朋友要搬家，问我能否帮忙。
我帮他转移了Cox调制解调器，在连接到光纤线路后，我拨打了ISP支持电话，询问他们能否推送更新，以便设备可以在新位置上工作。
代理确认他们可以远程更新设备设置，包括更改WiFi密码和查看连接的设备。
支持代理能够控制设备的能力引起了我的兴趣，尤其是他们几乎可以更新设备上的任何东西。
这种广泛的访问是通过一种名为TR-069的协议实现的，该协议于2004年实现，允许ISP通过7547端口管理其网络内的设备。
此协议已成为多个技术大会的演讲主题，而且没有对外公开，所以我对发现该协议的漏洞并不感兴趣。
但是，我对支持代理用来管理设备的工具非常感兴趣。
理论上，如果我是一名想要入侵我的调制解调器的黑客，我可能会瞄准代理使用的支持工具底层的基础设施。支持代理可能会使用管理设备的内部网站，后台由一个API提供支持，可以执行任意命令并更改或查看客户设备的管理设置。如果我能找到某种方法访问这些功能，就能发现我最初被黑的真相，或者至少能杜绝一种入侵我的调制解调器的途径。
7、入侵数百万台调制解调器
我决定首先查看Cox Business的门户网站。
该网站有很多有趣的功能，可以远程管理设备、设置防火墙规则和监控网络流量。
虽然没有Cox Business的账号，但我打开了门户网站的登录页面，并抓取了一个名为main.36624ed36fb0ff5b.js的文件，其中提供了网站的一些核心功能。在格式化该文件后，我解析出了所有的路径并浏览了一遍：
有100多个不同的API调用都使用了相同的基础路径/api/cbma/。由于这个路径提供的功能似乎大部分都与设备相关，所以我认为值得调查一下/api/cbma/端点是否是另一个主机的反向代理。为了验证我的想法，我发送了以下请求：
不以api/cbma开头的HTTP请求（返回301）：
以api/cbma开头的HTTP请求（返回500）：
