自动化巡检弱口令/空口令需先确认服务暴露面再针对性验证，聚焦高危端口与账户，按服务类型选工具+精简字典，人工复核结果确保准确。
用自动化巡检工具定位弱口令和空口令账户，核心是“先确认服务暴露面，再针对性爆破验证”，不是盲目扫。重点在于控制范围、匹配场景、规避误报，而不是追求一次扫全。
先做端口与服务识别
弱口令检测必须建立在真实开放的服务基础上。空口令只存在于特定服务（如Telnet、某些老版FTP、未设密的Redis），不连上就无从判断。
- 用 nmap 快速摸清目标开放了哪些服务及端口：
nmap -sS -p 21,22,23,80,443,3306,6379,1433,1521,3389,5900,27017 --open -T4 192.168.1.0/24只扫常见高风险端口，加--open跳过关闭端口，大幅提速 - 对返回 banner 的服务（如 SSH、FTP、Redis），提取版本信息，判断是否默认配置或已知存在空口令风险（例如 Redis 未配置
requirepass且监听公网） - 跳过无响应或超时严重的主机，避免工具卡死；内网可加
-Pn直接跳过主机发现阶段
按服务类型选工具+精简字典
不同服务的认证机制、响应逻辑、容错策略差异很大，混用字典或强行通用工具容易漏报或触发账号锁定。
-
Linux/SSH 类：优先用 John the Ripper 处理已获取的
/etc/shadow哈希（需 root 权限导出），比在线爆破更准、不扰服务。本地跑john --wordlist=rockyou.txt --format=sha512crypt shadow.txt即可识别空口令（NO PASSWORD）和弱哈希 - Windows/RDP/SMB 类：用 SNETCracker（Windows 平台），支持空口令自动探测（勾选“空密码”选项），对域控、文件共享类账户效果直接；注意设置合理延时（RDP 建议 ≥8 秒），避免因 DNS 解析慢导致误判
-
数据库/中间件：MySQL、Redis、MongoDB 等，SNETCracker 内置模块已覆盖。Redis 检测空口令只需尝试
redis-cli -h x.x.x.x -p 6379 ping，返回PONG即为空口令，无需字典 - 字典务必裁剪：删除重复项、剔除明显无效组合（如纯数字＜6位）、按目标环境补充定制项（如公司名+年份、系统默认账号名）
聚焦高危账户与空口令特征
不是所有账户都值得扫。应优先筛查那些权限高、历史久、易被忽略的账户。
- 系统级默认账号：root、admin、administrator、guest、test、oracle、mysql、redis、daemon —— 这些是攻击者第一目标，也是空口令高发区
- 检查
/etc/passwd中 shell 不为/sbin/nologin或/usr/sbin/nologin的非系统用户，特别是 UID < 1000 但能登录的账户 - 空口令典型表现：
passwd -S 用户名显示Password: LK（锁定）或Password: NP（No Password）；或chage -l 用户名中 “Password expires” 为 “never” 且 “Last password change” 是 “password must be changed” - 对 Web 应用后台（如 phpMyAdmin、Tomcat Manager），单独用 Burp Suite + Intruder 配合简单字典（admin/admin、admin/空、root/空）快速验证，比通用工具更可控
结果归并与可信确认
自动化工具会报一堆“疑似弱口令”，但很多是误报（如响应码相同、服务主动断连、WAF拦截）。必须人工复核关键结果。
- 把各工具输出的“成功登录”记录按 IP+服务+账户去重，生成清单
- 对每条结果，手动复现一次：用相同账号密码连接对应服务，观察是否真能执行命令或读取数据（如 Redis 执行
INFO、MySQL 执行SHOW DATABASES） - 标记“空口令”账户时，必须确认其实际权限：能否写文件？能否提权？能否访问敏感数据？不能仅凭登录成功就判定高危
- 输出报告中区分“已验证弱口令”“疑似空口令（待复核）”“服务开放但未发现有效凭证”三类，避免安全团队误判
