案例分析 Charter Communication 电信公司
有了先前的知识，我们在这一小节进行一个案例分析，对 Charter Communication 电信公司进行 OSINT 侦查。这一节虽然是案例分析，但并不是把这章节之前的内容生搬硬套就行，而是需要灵活新增侦查手段，创造性地搜集信息。
既然是 OSINT，那么意味着我们与目标的交互需要是被动的，包括但不局限于使用搜索引擎搜索有关目标公司的信息、查看社交媒体、whois 查询等。为了降低一点难度，我们可以与目标进行正常的交互，例如浏览网站。但是以下是不能进行的：nmap扫描、漏洞扫描、对公司员工进行社会工程学攻击、利用漏洞等。
我们目前只有目标企业的名称，即 Charter Communication Inc.。首先，我们要确定 Charter 公司在公网的网段，这个我们可以通过查询 Charter 公司的 ASN 编号。Charter 这样的大型企业，可能拥有多个 ASN (自治域) 编号，并且每个 ASN 编号都有大量的公共网段。至于ASN，是一个全球唯一标识符，它定义了一组一个或多个 IP 前缀，这些前缀由一个或多个网络运营商运行，这些网络运营商维护一个明确定义的路由策略。这些 IP 前缀组称为自治系统。ASN 允许自治系统与其他自治系统交换路由信息，世界各地的网络运营商都需要自治系统编号来控制其网络内的路由以及与其他网络运营商交换路由信息。
我们可以通过一些在线工具根据企业域名或者企业名称来查询 ASN 编号，例如 https://bgp.he.net/search?search%5Bsearch%5D=charter+communication&commit=Search。
但是，单个来源获取到的 ASN 编号肯定是不全甚至不准确的，我们需要从多个来源搜集相对完整的 ASN 编号。此外，有的 ASN 编号也可能不再活跃，即没有网段与之关联。这里，我提供几个有效的 ASN号码：AS12271，AS11427，AS20115，AS33363。
然后，我们根据 ASN 编号得到尽可能完成的网段。比如，我们可以通过在线网站查询 AS12271 的网段 https://asnlookup.com/asn/AS12271/。同样的，我们需要集中多个来源的数据以尽可能减少遗漏，同时，可能一些网站因为更新不及时等原因，会有一些不再属于该 ASN 编号的网段，我们需要注意。在合法的红队行动或者渗透测试中，如果我们确定了错误的范围，那么在后续的过程中可能无意众对非范围内的目标进行攻击，即未授权的行动。所以，相比添加错了的目标，宁愿遗漏一些。当然，最好也不要遗漏。
除了过时的数据，我们还需要注意区别出客户资产！！！考虑到 Charter 是一家很大的电信企业，在有些服务上也充当着运营商或者服务提供商的身份，因此有些资产可能是客户的，并非 Charter 自身的。如何准确区分这些资产，是难以三言两语总结的。我们简单看 2 个例子作为对比。下图是 shodan 搜索的一个结果，我们看到该结果的主机名是 mail.wonsbackgroundchecks.com。
查询一下 wonsbackgroundchecks.com 的 whois 信息，我们没有发现有关 charter.com 的字样，那么有可能是 charter.com 客户的资产。
其网站主页揭露了该公司是从事背景调查的，与电信关系不大，因此，作为子公司或母公司的概率也很小。
查看一下 Charter 的子母公司，也确实没有发现其踪迹。我们发现 Spectrum 是 Charter 收购的一家公司。
那么下图所示的结果，因为其主机名在 spectrum 域之下，很有可能是属于 Charter 的资产了。
查询 spectrum.com 的 whois 信息，也能确认这一点。总之，对于资产的确认，我们务必要十分小心，不然很容易进行未授权操作。
得到了 ASN 以及对应的网段后，尽管我们不可能搜集完整 (甚至企业自己都理不清全部资产)，接下来可以搜集顶级域名 TLD 了。顶级域名例如 charter.com，spectrum.com。我们可以优先从字母公司入手，另外一个很快捷的方法是逆向 whois 查询，即我们根据 whois 信息中的某个信息进行逆向查询，有哪些域名包含了特定的关键字。我们可以尝试的逆向查询内容可以是邮箱 (charter.com)、域名服务器 (ns1.charter.com)。便捷的在线网站有 https://viewdns.info/reversewhois/?q=charter.com，https://hackertarget.com/find-shared-dns-servers 等。
我们也是得到了海量的输出，因为 Charter 也是服务供应商，这是可以预期的，我们需要手动筛选。并且在上图中我们可以看到，即便是 charter.com 主站，也有一些变种，例如 charter-business.com 。当我们层层筛选后，可以将 TLD 列表输入给各种子域名枚举工具，这类工具我们之前已经介绍过一些了，这里我再介绍一款 ReconFTW (https://github.com/six2dez/reconftw)。这款工具十分强大，但具体强大之处请自行参考文档以及探索，这里不占用篇幅了。
接下来，是本节最核心的内容，是之前几节难以覆盖到的内容，请系好安全带，让我带你们从 OSINT 到 shell。当搜索引擎与特定的查询相结合的时候，可以辅助我们找到有趣的资产，比较知名的是 Google Dorking。除此之外，还有 Shodan dorking，Github Dorking 等。这些平台的具体侧重点有所不同或略有不同，但背后的宗旨都是一样的，利用现成的语法，组合成特定且精确的搜索语句。比如，在 Github 上，我们可以通过 Dorking 找到包含有明文凭证硬编码的文件，Google 上，我们可以找到开放目录站点，在 Shodan 上，我们可以找到 RDP 暴露于公网的主机。虽然这些 Dorking 都有一定的用途且都很有趣，为了能对我们的红队行动帮助最大，我们主要借助于 Shodan，Fofa，Quake 这 3 款搜索引擎。这 3 款搜素引擎功能是一致的，在具体能力上各有高低，此外，并且还存在着其他同类型的搜索引擎。
简述一下这 3 款搜索引擎的特点和优缺点
Shodan
Fofa
1000 元即可终身会员
能识别大量的应用和组件
有限的 banner 信息
如果使用 API，一次最多返回 100 条
只要频率控制在 1 秒 2 条请求以内，那就没有额度可言
Quake
1000 元即可终身会员
能识别大量的应用和组件
有限的 banner 信息
有搜索次数和请求次数的额度，但一般够用
在探讨各个搜索引擎的语法以及特别的搜索语句之前，我们需要知道我们搜索的宗旨，我们想要得到的是其他搜索引擎难以提供的 quick win。
1: 高风险 CVE 漏洞
未认证 RCE
目录遍历
任意文件读写
更多
2: 配置不当的服务
可读可写 SMB 共享目录
不需要认证的 rsync
不需要认证的 VNC
不需要认证的 X11
开放目录
暴露在公网的域主机
暴露在公网的域控制器
默认凭证
更多
3: 信息搜集
NetBIOS-SSN
SMB
RDP
MSSQL
WinRM
SNMP
更多
4: 企业中常被利用的应用和组件
Outlook
Tomcat
Jenkins
Fastjson
Log4j
Spring
ManageEngine Products
Weblogic
Vmware Products
Struts2
Gitlab
Nexus
JFog
更多
考虑到我们有特定的目标，即 Charter，那么我们每次搜索的时候都需要把目标带上。幸运的是，这 3 款搜索引擎都帮我们整理好了 Organization 以及 ASN。考虑到 Charter 有多个活跃 ASN，那么我们就以组织名为准好了 (Fofa 对于一些 ASN 识别的结果与其他 2 款搜索引擎不一致，因此组织名也有所不同)。时刻记得判断目标结果是否为 Charter 自身的资产。
接下来，我们就可以构造特定的搜索语句了，我个人建议从精确、quick-win的开始，即找到大概率能提供给我们 shell 的资产。这样的案例可以为具有永恒之蓝 MS17-010 漏洞的主机，目前只有 shodan 能精确查找到，语句为 org:"Charter Communications Inc" vuln:ms17-010。
shodan 找到了 16 台具备条件的资产，但是从下图中的结果的域名来看，有可能是 Charter 客户的，我们往下翻一翻。
我们看到这个结果，域名是 spectrum 的，很有可能是 Charter 自身的资产，即在范围内。但请别过于激动，我们不应当实际进行攻击。并且攻击也可能因为其他原因导致失败，例如安全产品的部署、网络防火墙、补丁和系统加固等。
另外一个例子是 VsFTPd 2.3.4 后门 RCE。在 3 款不同搜索引擎下，语句是这样的：
FOFA: org="CHARTER-20115" && banner="vsFTPd 2.3.4"
Shodan: org:"Charter Communications Inc" vsFTPd 2.3.4
Quake: org: "Charter Communications Inc" AND response:"vsFTPd 2.3.4"
我们可以确认该漏洞 (https://www.exploit-db.com/exploits/49757) 利用难度很低，并不需要提供凭证即可执行远程代码。唯一需要注意的是，如果后续我们在利用的时候，目标主机会被开启一个端口，然后我们正向连接该端口。实际利用的成功与否，需要考虑到防火墙的因素。
