反向探测互联网扫描器

渗透技巧 2年前 (2021) admin

1,481 0 0

微信又改版了，为了我们能一直相见

你的加星和在看对我们非常重要

点击“长亭安全课堂”——主页右上角——设为星标?

期待与你的每次见面～

如果能知道扫描器是fofa/zoomeye/…，能否定向欺骗呢？

在几个月之前研究tls指纹的时候想到，互联网扫描器是否有特殊的tls指纹呢？

如果有，那厂商的各个扫描节点指纹肯定也是一样的，是不岂不是能观测到厂商的全部扫描节点呢？

这里有一个问题，那么多扫描器如何区分厂商的扫描器，还是脚本小子乱扫的呢？

于是我设计了一个小实验，有以下假设

1.扫描器的tls指纹应该是相同的

也就是说可以通过tls指纹聚合扫描器

2.扫描器在遇到https服务时，会提取证书中的信息

3.扫描器提取出域名后，会尝试使用这个域名再次扫描

这里再次扫描可能有两个动作

3.1 扫描器对这个IP使用，用证书中的域名填充host头再次扫描

3.2 扫描器尝试解析这个域名，去扫描解析的结果

后续实验证明很多扫描器都没有做假设3的动作，其实我觉得作为一个扫描器应该做到，后面看是谁做到了吧

基础设施

开了两个服务器，考虑分布式扫描器可能有根据区域就近分配任务的功能（可能也没有吧），为了能捕获到更多的IP，两个服务器分开部署一个在香港，一个在美国，为了好记，一个叫hk服务器，一个叫us服务器

us 配置 domainincertnodnsrecord.xlab.app 证书 domainincertnodnsrecord.xlab.app 并没有dns记录

只是一个假域名，只有证书用来捕获假设3.2的动作

hk 配置 longsubdomainwaitscan.xlab.app 证书将longsubdomainwaitscan.xlab.app 解析到us服务器

可以认为hk是一个真实业务服务器，而us是hk前置的“cdn” 用来捕获假设3.1的动作（其实us也可以）

为了方便区分服务器到底怎么被扫了，给nginx配置了不同的日志，不同的server_name写到不同的日志里

https://segmentfault.com/a/1190000015681272

申请证书使用txt验证，实验期间不产生任何dns查询，避免被被动dns捕获

日志分析

通过分析日志对互联网扫描器进行分类

实验一共持续了一个多月（然后本文又拖了一个月现在才写

扫描策略

上线差不多10天的时候，在us上longsubdomainwaitscan.xlab.app域名被访问了

34.x.x.16 - - [21/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 400 255 "-" "Expanse indexes the network perimeters of our customers. If you have any questions or concerns, please reach out to: [email protected]" "-"

这个域名和us服务器的关系只有dns记录，意味着扫描器从某个地方知道了这个超长的域名，并通过dns记录找到了us服务器

直到实验结束，在us上访问longsubdomainwaitscan.xlab.app域名的所有记录，都是这个厂商

一共5条日志，有5个IP

34.x.x.16 - - [21/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 400 255 "-" "Expanse indexes the network perimeters of our customers. If you have any questions or concerns, please reach out to: [email protected]" "-"34.x.x.11 - - [24/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 400 255 "-" "Expanse indexes the network perimeters of our customers. If you have any questions or concerns, please reach out to: [email protected]" "-"34.x.x.17 - - [28/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 400 255 "-" "Expanse indexes the network perimeters of our customers. If you have any questions or concerns, please reach out to: [email protected]" "-"34.x.x.12 - - [30/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 400 255 "-" "Expanse indexes the network perimeters of our customers. If you have any questions or concerns, please reach out to: [email protected]" "-"34.x.x.0 - - [12/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 400 255 "-" "Expanse indexes the network perimeters of our customers. If you have any questions or concerns, please reach out to: [email protected]" "-"

那么可以有以下猜测

扫描器应该是有假设3.2的扫描策略
执行假设2和假设3的扫描节点不同，意味着在在这个策略上有某种扫描调度逻辑

其中捕获到了一个tls指纹14fbddc85522dba426ae572ff2f04372

在ja3er上搜了下

Mozilla/5.0 (compatible; Nimbostratus-Bot/v1.3.2; http://cloudsystemnetworks.com) (count: 1, last seen: 2019-11-26 10:12:57)

好像都是做网络扫描的，但ua不一样，这个ua也没有出现在我的日志里

关联一下这个tls指纹的日志，查到不少IP

time="2021-09-18Tx:x:x+08:00" 34.x.x.31time="2021-09-21Tx:x:x+08:00" 34.x.x.12time="2021-09-24Tx:x:x+08:00" 34.x.x.24time="2021-09-29Tx:x:x+08:00" 34.x.x.10time="2021-10-02Tx:x:x+08:00" 34.x.x.25time="2021-10-06Tx:x:x+08:00" 34.x.x.21time="2021-10-08Tx:x:x+08:00" 34.x.x.0time="2021-10-13Tx:x:x+08:00" 34.x.x.31

time="2021-09-15Tx:x:x+08:00" 34.x.x.27time="2021-09-17Tx:x:x+08:00" 34.x.x.25time="2021-09-21Tx:x:x+08:00" 34.x.x.17time="2021-09-24Tx:x:x+08:00" 34.x.x.6time="2021-09-29Tx:x:x+08:00" 34.x.x.1time="2021-10-02Tx:x:x+08:00" 34.x.x.2time="2021-10-06Tx:x:x+08:00" 34.x.x.17time="2021-10-08Tx:x:x+08:00" 34.x.x.21time="2021-10-12Tx:x:x+08:00" 34.x.x.11time="2021-10-15Tx:x:x+08:00" 34.x.x.18

IP重复率极低，18条日志，17个独立IP

其实这个厂商ua特征比较明显，通过ua查询，去重，一共23条日志，21个独立IP，也是集中在3个c段里，估计这几个c段都是他们的扫描器吧

34.x.x.034.x.x.1234.x.x.1734.x.x.1834.x.x.2534.x.x.3134.x.x.134.x.x.1134.x.x.1734.x.x.2434.x.x.3134.x.x.1034.x.x.234.x.x.2134.x.x.2534.x.x.2734.x.x.6

捕获17/21=80%的扫描节点

那么假设3.1呢

也就是：扫描器会证书中的域名填充host头再次扫描

在这一点上，hk和us服务器是平等的，没有什么区别

209.x.x.65 - - [20/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Chrome/54.0 (Windows NT 10.0)" "-"209.x.x.193 - - [20/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"205.x.x.89 - - [20/Sep/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"209.x.x.193 - - [11/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Chrome/54.0 (Windows NT 10.0)" "-"205.x.x.25 - - [11/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"209.x.x.65 - - [11/Oct/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"

同时查询使用IP访问的日志

205.x.x.25 - - [20/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"209.x.x.193 - - [20/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"209.x.x.65 - - [20/Sep/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"209.x.x.193 - - [11/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"209.x.x.193 - - [11/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"

这样可能看着比较难受，那么根据时间排序，前面备注上访问的是域名还是IP

hkip 205.x.x.25 - - [20/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"hkip 209.x.x.193 - - [20/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"hkip 209.x.x.65 - - [20/Sep/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"hk 209.x.x.65 - - [20/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Chrome/54.0 (Windows NT 10.0)" "-"hk 209.x.x.193 - - [20/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"hk 205.x.x.89 - - [20/Sep/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"hkip 209.x.x.193 - - [11/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"hkip 209.x.x.193 - - [11/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"hk 209.x.x.193 - - [11/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Chrome/54.0 (Windows NT 10.0)" "-"hk 205.x.x.25 - - [11/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"hk 209.x.x.65 - - [11/Oct/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"

us也是一样

usip 205.x.x.184 - - [19/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"usip 209.x.x.193 - - [19/Sep/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"us 209.x.x.112 - - [19/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Chrome/54.0 (Windows NT 10.0)" "-"us 209.x.x.193 - - [19/Sep/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"us 209.x.x.193 - - [19/Sep/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"usip 209.x.x.193 - - [08/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"usip 205.x.x.89 - - [08/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 404 555 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"usip 209.x.x.193 - - [08/Oct/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"us 205.x.x.184 - - [08/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Chrome/54.0 (Windows NT 10.0)" "-"us 205.x.x.89 - - [08/Oct/2021:x:x:x +0000] "GET / HTTP/1.1" 200 615 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "-"us 209.x.x.65 - - [08/Oct/2021:x:x:x +0000] "GET /favicon.ico HTTP/1.1" 404 555 "-" "Chrome/54.0 (Windows NT 10.0)" "-"

可以看出来符合假设3.1，而且存在一定的任务调度，比如205.x.x.89在没有IP访问记录的情况下直接使用域名访问，推测是基于前面的扫描结果触发的

再关联这些IP与tls指纹，一共有两个指纹，但这两个指纹的差异就是有sni和无sni，也就是对应域名访问和IP访问，与上面的日志匹配

有sni: df669e7ea913f1ac0c0cce9a201a2ec1

无sni: 89be98bbd4f065fe510fca4893cf8d9b

同时在tls指纹库中对比查到这是Golang的tls指纹，也就是说扫描器是Golang写的，唯一性不是很强

tls指纹库是我自己建的，是指纹与应用的映射

暂且认为这是同一个厂商吧，叫厂商a吧

JARM

不了解的可以之前写的TLS指纹学习整理

JARM是一个扫描tls服务的策略，使用10个特殊的tls请求，获取服务器响应，这也导致它也有独特的tls指纹

按顺序10个指纹

db8d4ad49cb378fa370b43a61a9b06b603a3ad27040f733ee5c9915e0903d028013c30c8ce44c8b27e9ceb2a14db7283a96dc3876784813c57d302241e620acd1289771a3fce256d5fb4cb5c95b43ee6006315b3ad276906ff11527f9594e5badb8d4ad49cb378fa370b43a61a9b06b6013c30c8ce44c8b27e9ceb2a14db7283917fde1bf3bcb67f961b77b18d9ee14a7f9ae904ef5a8d37a4028ce5c57bc099

互联网扫描器应该有不少支持上了吧，理论上只要挑一个指纹就可以了（没有扫描器只实现了10步中的一部分吧

选了03a3ad27040f733ee5c9915e0903d028，去重一共9个IP，全都是新IP，意味着上面两个厂商可能都没有支持

125.x.x.138125.x.x.143125.x.x.144198.x.x.120206.x.x.172209.x.x.9209.x.x.11634.x.x.8268.x.x.95

再继续反查IP的全部tls指纹，找到它们独特的tls指纹，对IP进行分类

//19e29534fd49dd27d09234e639c4057e125.x.x.138125.x.x.144
//89be98bbd4f065fe510fca4893cf8d9b125.x.x.14334.x.x.82
//89be98bbd4f065fe510fca4893cf8d9b,20c9baf81bfe96ff89722899e75d0190198.x.x.120206.x.x.172209.x.x.9209.x.x.11668.x.x.95

有两个tls指纹推测是调用的扫描组件不一样导致的

由于 89be98bbd4f065fe510fca4893cf8d9b 已知是golang的tls指纹，暂时不看

剩余两个指纹，可能是两个厂商

19e29534fd49dd27d09234e639c4057e 是无sni的，对应有sni版本是 473cd7cb9faa642487833865d516e578 ，有sni的版本没有日志

在ja3er上搜了下，似乎与l9tcpid有关，估计扫描器是基于l9tcpid做的，叫厂商b吧

20c9baf81bfe96ff89722899e75d0190是有sni的，对应无sni的版本是cba7f34191ef2379c1325641f6c6c4f4，找到两个新IP

139.x.x.250165.x.x.172

这两个IP有且仅有cba7f34191ef2379c1325641f6c6c4f4这一个指纹，也可能是另一个厂商，叫厂商c吧

在ja3er上搜了下，这两个指纹似乎与zgrab有关，估计扫描器是基于zgrab改的，里面还有一些自己的golang逻辑，叫厂商d吧

验证

对比收录时间和日志，可以定位到扫描IP，侧面验证上面的聚类，以及对应的厂商

zoomeye

有准确的收录时间，很方便定位

us 125.x.x.138hk 125.x.x.144

对应上面tls指纹19e29534fd49dd27d09234e639c4057e，也就是厂商b

fofa

虽然没有准确的收录时间，但可以估计服务器响应的Date看出来时间

us 106.x.x.117 35fa0a83e466acbec1cfbb9016d550abhk 45.x.x.151 89be98bbd4f065fe510fca4893cf8d9b

都是新IP，还得到了一个新的指纹 35fa0a83e466acbec1cfbb9016d550ab ，在ja3er上没看到什么信息，反查IP

106.x.x.172106.x.x.117222.x.x.2355.x.x.202

其中 5.8.10.202 还有另一个指纹 f7e86b32bc0db5b6a594afac7cfc570c

在ja3er上看到可能是fasthttp（golang的一个http库）

quake

同fofa

us 206.x.x.172hk 68.x.x.95

对应上面tls指纹 20c9baf81bfe96ff89722899e75d0190 ，也就是厂商d

最后

依据tls指纹分类特定厂商的扫描节点是可行的，还可以设计特定的扫描策略“陷阱”去分类

expanseinc 会根据证书中的域名，通过dns对这个域名进行扫描

厂商a 会根据证书中的域名，填充host，再次对这个IP进行扫描

zoomeye 有jarm扫描，可能基于l9tcpid

fofa 没有什么特别的信息

quake 有jarm扫描，可能基于zgrab

为什么没有shodan？

可能是因为https服务不在443端口吧，shodan没有收录

服务器包月，为什么是一共跑了一个多月呢？

其实跑了一个月就差不多了，但又想看看能不能捕获到其他厂商，就又续了一个月，但后来看日志都差不多，费用破百了，就给停了hhh

最开始搞的时候还没出fapro，其实这个可以用fapro，监听443端口，再搞一次，有兴趣的师傅可以试试，出数据记得叫我

https://nosec.org/home/detail/4890.html

https://mp.weixin.qq.com/s/pQZKTg1hFdHj9_Uv8MoQvQ

区分厂商的扫描器应该还有很多方法，这只是我在研究tls指纹的时候想到的

点分享

点收藏

点点赞

点在看

原文始发于微信公众号（长亭安全课堂）：反向探测互联网扫描器

版权声明：admin 发表于 2021年12月7日上午10:00。
转载请注明：反向探测互联网扫描器 | CTF导航

逻辑漏洞之全面总结

admin

怎么在无EXECUTE权限的内存上执行shellcode

admin

225

蓝军技术推送——武器化AV驱动程序、Spring Core RCE、Windows Rootkit

admin

896

攻击技术研判 | 上游供应商沦陷典例-3CX供应链攻击事件

admin

381

一些你可能不知道但是有用的 chrome 调试技巧

admin

747

Discord钓鱼攻击案例分析

admin

724

暂无评论

您必须登录才能参与评论！

立即登录

暂无评论...

反向探测互联网扫描器

那么假设3.1呢

每日安全动态推送(12-07)

grafana最新任意文件读取分析以及衍生问题解释

相关文章

暂无评论

相关文章

反向探测互联网扫描器

那么假设3.1呢

每日安全动态推送(12-07)

grafana最新任意文件读取分析以及衍生问题解释

相关文章

暂无评论

广告位

相关文章