恒美微站
首页
关于我们
建站服务
主题模板
案例展示
资讯中心
联系我们
Layer子域名挖掘机4.2实战:离线字典爆破与泛解析过滤
首页
资讯中心
/
Layer子域名挖掘机4.2实战:离线字典爆破与泛解析过滤
Layer子域名挖掘机4.2实战:离线字典爆破与泛解析过滤
发布时间:2026/10/21 2:57:58
简介Layer子域名挖掘机4.2纪念版是一款面向网络安全从业者、渗透测试人员及安全研究学习者的子域名发现工具主要用于在渗透测试、漏洞排查与资产梳理场景中快速定位目标主域名下可能被忽视的子域名帮助识别未公开的安全入口与潜在脆弱点。压缩包共5个文件约4MB以exe主程序为核心配合dll运行库、xml配置说明及txt字典文件结构精简、开箱即用便于在本地环境快速部署。目前已有714人学习下载具备一定的实践参考热度。工具通过整合DNS记录、WHOIS信息与爬虫结果等多源数据进行匹配筛选扫描后可列出子域名及其解析IP、SSL证书等信息并支持批量扫描、结果过滤与导出等操作方便安全人员进一步开展漏洞扫描与指纹识别。对于希望掌握子域名挖掘技术、完善网络资产管理的读者这份资源提供了可直接上手的实用工具与操作思路。1. 子域爆破这活为什么我最后还是留了一把趁手的家伙做资产测绘的兄弟都懂子域名收集是整个信息收集链条里最脏最累的一环。你手里可能有一堆 API 接口、证书透明日志、被动 DNS 数据源但真到了要挖某个目标边缘资产的时候最踏实的还是本地跑一遍字典爆破。Layer 子域名挖掘机 4.2 纪念版就是干这个的——它不依赖任何在线接口纯本地字典枚举把 DNS 解析、泛解析识别、结果去重和存活探测串成一条流水线。适合谁用做渗透测试前期踩点的、搞 SRC 漏洞挖掘的、以及需要定期梳理自身资产面的运维安全同学。这工具不花哨但胜在稳定、离线可用、结果直观尤其适合那些不想把目标域名往第三方平台扔的场景。下面我按实际拆包和跑测的流程把它的能力边界和参数调优讲透。2. 拆开压缩包目录结构、运行依赖与字典逻辑2.1 文件构成与运行环境确认拿到 Layer 子域名挖掘机 4.2 纪念版.zip 之后第一步别急着双击 exe。我一般先解压到独立目录用tree /f看一眼结构。典型布局是主程序一个 exe同级放一个dict文件夹里面按域名类型分了好几个字典文件比如subdomains_top10000.txt、subdomains_top50000.txt可能还有一个泛解析白名单.txt。另外会有一个config.ini或者setting.json用来存并发数、超时时间和 DNS 服务器地址。运行环境上这类工具通常是 Windows 原生编译依赖 .NET Framework 4.0 以上或者 VC 运行库。如果你在 Windows 10/11 上跑报缺 dll先装一遍微软常用运行库合集别去折腾兼容模式。我实测在 Windows Server 2019 上也能直接跑但要注意如果系统开了 DNS Client 服务缓存爆破结果可能受本地缓存影响建议跑之前ipconfig /flushdns清一下。注意解压时如果杀软报毒先看是不是误报。这类工具因为要高频发 DNS 包行为特征容易被标记。我一般会加白名单目录再解压避免文件被隔离导致字典丢失。2.2 字典分级策略与泛解析识别原理Layer 的核心逻辑其实就三件事读字典、拼域名、发 DNS 查询。但真正决定结果质量的是它对泛解析的处理。所谓泛解析就是目标把*.target.com解析到同一个 IP这时候你字典里随便一个abc.target.com都能解析出结果爆破就失去了意义。它的做法是先随机生成一个不可能存在的子域比如randomstring123.target.com查它的 A 记录。如果这个随机域名也解析到了 IP说明目标开了泛解析。接下来工具会把泛解析 IP 记下来后续所有解析到同一 IP 的结果都标记为「疑似泛解析」或者直接过滤掉。这个逻辑在 4.2 纪念版里做了优化支持多 IP 泛解析识别比早期版本只认单 IP 要准不少。字典分级上我习惯先用 top10000 跑一遍快速摸底拿到一批有效子域后再换 top50000 做深度补充。不要一上来就上百万字典DNS 查询有速率限制跑太久容易被目标封禁或者触发告警。下面这段伪代码展示了泛解析检测的核心逻辑你可以对照工具行为理解import dns.resolver import random import string def check_wildcard(domain, resolver_ip): # 生成随机前缀长度 12 位避免碰撞 rand_prefix .join(random.choices(string.ascii_lowercase string.digits, k12)) test_domain f{rand_prefix}.{domain} resolver dns.resolver.Resolver(configureFalse) resolver.nameservers [resolver_ip] resolver.timeout 3 resolver.lifetime 3 try: answers resolver.resolve(test_domain, A) wildcard_ips {rdata.address for rdata in answers} return wildcard_ips # 返回泛解析 IP 集合 except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer, dns.resolver.Timeout): return set() # 无泛解析这段代码的关键参数是k12随机串太短可能撞到真实子域太长没必要。timeout和lifetime设 3 秒是平衡速度和准确率内网 DNS 可以降到 1 秒。拿到wildcard_ips后后续爆破结果里凡是解析 IP 落在这个集合内的都要人工复核别直接当成有效资产。2.3 并发参数与 DNS 服务器选择Layer 界面上一般有「线程数」和「超时时间」两个输入框。线程数不是越大越好我踩过的坑是设到 200 以上本地路由器先扛不住丢包率飙升结果反而漏报。比较稳的区间是 50 到 100 线程配合 3 秒超时。如果你用公共 DNS比如 223.5.5.5 或者 119.29.29.29并发可以开到 80如果是走本地递归 DNS建议降到 30 以内避免把内网 DNS 打挂。DNS 服务器选择上工具默认可能用系统配置。我一般手动指定成多个公共 DNS 轮询比如阿里、腾讯、114 混着用。这样做的目的是防止单一 DNS 对泛解析判断出现偏差同时也能绕过某些 DNS 的速率限制。但要注意不同 DNS 返回的 CDN 节点 IP 可能不同如果你在结果里看到同一子域解析出好几个不同 IP先别慌大概率是 CDN 调度不是泛解析。3. 实战跑测从命令行到结果过滤的完整链路3.1 启动参数与配置文件详解虽然 Layer 有图形界面但 4.2 纪念版保留了命令行调用能力方便做自动化。我一般会先看config.ini里有哪些可调项。常见的配置项包括配置项含义推荐值备注threads并发线程数60超过 100 易丢包timeoutDNS 超时秒数3内网可设 1retry重试次数2太高拖慢整体dns_server指定 DNS223.5.5.5可逗号分隔多个wildcard_filter泛解析过滤true必开output_format输出格式csv方便后续处理如果你要批量跑多个域名可以写一个简单的批处理脚本循环调用主程序并传入不同域名参数。下面是一个示例echo off set toolC:\Tools\Layer\Layer.exe set dictC:\Tools\Layer\dict\subdomains_top10000.txt set dns223.5.5.5 for /f %%d in (domains.txt) do ( echo [*] 正在爆破 %%d %tool% -d %%d -f %dict% -s %dns% -t 60 -o result_%%d.csv timeout /t 2 nul )这段脚本里-d指定目标域名-f指定字典路径-s指定 DNS-t是线程数-o是输出文件。timeout /t 2是每个域名之间停 2 秒给本地网络一个缓冲避免连续高频查询触发运营商限流。domains.txt里一行一个根域名不要带http://前缀。3.2 结果去重与存活验证跑完字典后你会得到一个 CSV 或者 TXT里面可能有几千行。别急着全导进漏洞扫描器先做两件事去重和存活验证。去重是因为字典里可能有重复条目或者不同字典合并后产生重复。存活验证是因为 DNS 能解析不代表 HTTP 服务还活着很多子域是历史遗留解析还在但服务早下线了。我一般用一段 Python 脚本做二次处理import csv import socket import concurrent.futures def check_alive(subdomain, port80, timeout2): try: # 先解析 IP确认 DNS 有效 ip socket.gethostbyname(subdomain) # 再尝试 TCP 连接判断端口是否开放 with socket.create_connection((ip, port), timeouttimeout): return subdomain, ip, port, True except Exception: return subdomain, None, port, False # 读取 Layer 输出的 CSV假设第一列是子域名 subdomains [] with open(result_target.csv, r, encodingutf-8) as f: reader csv.reader(f) for row in reader: if row and row[0].strip(): subdomains.append(row[0].strip()) # 去重 subdomains list(set(subdomains)) print(f[*] 去重后共 {len(subdomains)} 个子域) # 并发验证 80 和 443 端口 alive_results [] with concurrent.futures.ThreadPoolExecutor(max_workers50) as executor: futures [] for sub in subdomains: futures.append(executor.submit(check_alive, sub, 80)) futures.append(executor.submit(check_alive, sub, 443)) for future in concurrent.futures.as_completed(futures): sub, ip, port, alive future.result() if alive: alive_results.append((sub, ip, port)) # 输出存活结果 with open(alive_target.csv, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([subdomain, ip, port]) writer.writerows(alive_results) print(f[*] 存活子域 {len(alive_results)} 条已写入 alive_target.csv)这段脚本里max_workers50是并发验证的线程数和爆破线程分开控制。timeout2是 TCP 连接超时公网服务建议设 3 秒内网可以设 1 秒。注意socket.gethostbyname只返回一个 IP如果目标用了多 IP 轮询可能会漏掉部分节点更严谨的做法是用dns.resolver拿全部 A 记录再逐个验证。3.3 与被动收集工具的结果合并Layer 是主动爆破结果受字典覆盖度影响。实际项目中我一般会把它和被动收集的结果合并。被动收集可以用证书透明日志、公开的 DNS 数据集或者一些在线的 API。合并的时候注意格式统一都整理成「子域名,来源」两列然后按子域名去重。这样做的目的是主动爆破能发现一些不在证书日志里的内部命名被动收集能覆盖字典里没有的冷门子域两者互补。合并后我会按来源打标签比如layer、ct、api后续如果某个子域出问题能快速回溯是哪个环节发现的。这个习惯帮我省过很多事有一次一个边缘业务子域只在被动数据里出现Layer 字典没覆盖到合并后才发现。4. 避坑指南泛解析误报、DNS 限流与字典陷阱4.1 泛解析误报现象是结果里突然多出几百条同一 IP 的子域现象很直观跑完字典结果列表里几百个子域全解析到同一个 IP而且这些子域名字看起来毫无规律比如a1b2c3.target.com、x9y8z7.target.com。原因就是目标开了泛解析而工具的泛解析过滤没生效或者被绕过了。常见情况是你手动指定了多个 DNS其中某个 DNS 对泛解析的响应和其他 DNS 不一致导致过滤逻辑判断失误。解决办法分两步第一跑之前先用nslookup random123.target.com 223.5.5.5手动确认泛解析是否存在第二如果确认有泛解析在工具里把「泛解析过滤」勾上并且只用一个 DNS 做解析不要多 DNS 轮询。如果工具版本不支持多 IP 泛解析识别那就把结果里同一 IP 的子域全部导出人工抽查几个确认是泛解析后整批丢弃。4.2 DNS 限流现象是跑着跑着解析全部超时这个坑我踩过不止一次。表现是前几分钟跑得好好的突然所有查询都超时工具日志里一片 timeout。原因是你用的公共 DNS 对单一来源 IP 有 QPS 限制比如某些公共 DNS 限制每秒 20 次查询你开 100 线程瞬间就打满了。另一个可能是本地运营商对 UDP 53 端口做了限速。解决办法把线程数降到 30 以下超时时间调到 5 秒并且在配置文件里加多个 DNS 轮询让查询分散到不同服务器。如果还是不行就换一个时间段跑避开网络高峰。我一般会在凌晨跑大字典白天只跑小字典做补充。另外如果你有内网递归 DNS优先用内网的没有限流问题。4.3 字典陷阱现象是跑了几十万字典有效结果个位数这种情况通常不是工具的问题而是字典选错了。比如你拿一个通用字典去跑一个内部业务系统内部命名规范可能是业务名-环境.内网域名通用字典里根本没有这种模式。另一个常见错误是字典里包含了大量无意义的数字组合跑了几万条全是 NXDOMAIN浪费时间。解决办法先分析目标可能的命名习惯。如果是互联网公司试试dev、test、staging、api、admin这类前缀如果是传统企业试试oa、mail、vpn、erp。Layer 的字典文件夹里一般有分类字典按场景选。另外可以先用小字典跑一遍观察有效子域的命名模式再根据模式生成针对性字典比盲目上大字典效率高得多。4.4 输出编码问题现象是 CSV 打开乱码Windows 下用 Excel 打开 CSV 乱码是老问题了。Layer 默认输出可能是 GBK 或者 UTF-8 无 BOMExcel 按系统默认编码读中文就乱了。解决办法很简单用记事本打开 CSV另存为 UTF-8 with BOM 格式再用 Excel 打开。或者直接用 Python 的 pandas 读指定encodingutf-8或encodinggbk别用 Excel 硬开。4.5 杀软拦截现象是程序跑一半突然消失前面提过这类工具容易被杀软盯上。表现是程序启动后几秒进程就没了或者字典文件被删。原因就是行为特征被判定为恶意。解决办法把整个工具目录加到杀软白名单包括 exe 和字典文件夹。如果公司有终端管控策略提前和 IT 报备别偷偷跑不然被断网还得写报告。5. 进阶技巧把 Layer 塞进自动化流水线5.1 用 Python 调度 Layer 并解析结果单次手动跑效率太低我一般会把 Layer 封装成一个 Python 函数输入根域名和字典路径输出结构化结果。这样就能和后面的端口扫描、指纹识别串起来。下面是一个调度示例import subprocess import csv import os def run_layer(domain, dict_path, output_dir, threads60, dns_server223.5.5.5): # 构造输出文件路径 output_file os.path.join(output_dir, flayer_{domain}.csv) # 调用 Layer 命令行参数按实际工具调整 cmd [ rC:\Tools\Layer\Layer.exe, -d, domain, -f, dict_path, -t, str(threads), -s, dns_server, -o, output_file ] # 超时设 600 秒防止卡死 result subprocess.run(cmd, capture_outputTrue, textTrue, timeout600) if result.returncode ! 0: print(f[!] {domain} 爆破失败: {result.stderr}) return [] # 解析 CSV跳过表头 subdomains [] if os.path.exists(output_file): with open(output_file, r, encodingutf-8, errorsignore) as f: reader csv.reader(f) next(reader, None) for row in reader: if row and row[0].strip(): subdomains.append(row[0].strip()) print(f[*] {domain} 发现 {len(subdomains)} 个子域) return subdomains # 批量调用 targets [example.com, test.org] all_results {} for t in targets: subs run_layer(t, rC:\Tools\Layer\dict\subdomains_top10000.txt, rC:\Output) all_results[t] subs这段代码里subprocess.run的timeout600是防止某个域名卡死导致整个流水线阻塞。errorsignore是应对编码问题避免解析 CSV 时因为个别乱码字符报错。拿到all_results后你可以直接丢给 nmap 或者 httpx 做下一步。5.2 结果去重合并与资产标签化多个域名跑完后把所有子域合并到一个列表按根域名分组然后打标签。我一般会生成一个assets.csv字段包括子域名、根域名、发现来源、解析 IP、是否存活、首次发现时间。这个表就是后续所有工作的基础。每次跑完 Layer和上一次的结果做 diff新增的子域重点看消失的子域也记录一下可能是业务下线或者解析变更。5.3 定期复跑与变更监控资产不是静态的子域名会新增也会消失。我习惯每周跑一次小字典每月跑一次大字典结果自动 diff。新增子域第一时间做存活和指纹识别消失子域确认是否业务调整。这个习惯帮我提前发现过几个测试环境暴露到公网的情况都是新上线的子域没做访问控制。从那以后我每次跑完 Layer都会强制走一遍「去重 → 存活验证 → 来源标签 → 与上次 diff」这四步少一步心里都不踏实。工具是死的流程是活的把流程固定下来才能把漏报和误报压到最低。希望帮到你。本文还有配套的精品资源点击获取