文章总结： 本文介绍BlackHatUSA2026议题LANJack，展示如何通过广告投放分发DNSRebinding攻击，探测用户局域网内的路由器、摄像头等IoT设备。攻击分六个阶段，利用隐藏iframe、DNS缓存预热、时序侧信道和DNS重绑定等技术，无需用户交互即可实施。文章同时给出广告供应链准入控制、DNS解析防护、设备管理面加固等防御建议。
综合评分： 85
文章分类： 红队,内网渗透,IoT安全,漏洞分析
Black Hat USA 2026：LANJack局域网侦察
原创
Max Luo
Max Luo
白帽子罗棋琛
2026年9月28日 09:19
中国香港
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
LANJack：广告如何变成局域网 IoT 侦察工具
Black Hat USA 2026 议题笔记：LANJack: Turning Ads into IoT Recon Tools
打开一个带广告的网页，通常被认为是“访问公网内容”。LANJack 展示了另一种边界：广告脚本在浏览器里执行后，可以借助隐藏 iframe、Local Network Access 时序差异、DNS Cache Priming 和 DNS Rebinding，探测用户局域网里的路由器、摄像头和其他 IoT 设备。
它不要求用户点击，也不需要先在终端落地恶意程序。浏览器本身就是执行环境和网络入口，广告平台则提供受众定位、实时投放和大规模分发。
图 1：LANJack 议题课件封面
课件将 LANJack 定义为首个已知的大规模 DNS Rebinding Campaign，并称其通过广告投放、在真实浏览器中运行，目标包括多家厂商的网络设备和摄像头。配套 Whitepaper 进一步拆解了主 Campaign、RTSP 变体和 CSP 登录探测变体。
下面只讨论攻击面和防御实现，不提供可直接复用的攻击脚本。
1、广告供应链天然具备攻击分发条件
现代实时竞价广告允许第三方 JavaScript 在页面中执行。为了提高转化，广告系统还掌握地理位置、设备类型、操作系统、浏览器、语言和用户行为等定向条件。
图 2：第三方可执行代码、弱 CSP/Sandbox、动态内容和复杂供应链叠加
这套能力对攻击者很有吸引力：
- 规模：同一 Creative 可以触达大量浏览器；
- 定向：只向特定国家、设备或浏览器返回攻击代码；
- 隐蔽：对审核器、安全厂商和非目标访问返回正常素材；
- 上下文：脚本运行在用户正在使用的浏览器中，天然位于内网一侧；
- 供应链距离：网站所有者未必知道最终由哪一层竞价方提供脚本。
课件指出，实时广告生态每天带来数十亿次第三方脚本执行。安全边界却常停留在“广告不能读取宿主页面 Cookie”，没有覆盖“广告能否借浏览器探测局域网”。
页面侧应把广告放入独立 Origin，并使用最小 Sandbox：
html
<iframesrc="https://ads.example.invalid/render"sandbox="allow-scripts"referrerpolicy="no-referrer"allow="camera 'none'; microphone 'none'; geolocation 'none'"width="300"height="250"></iframe>
不要同时给广告 iframe 加上 allow-scripts 和 allow-same-origin 后又让它与站点同源；这会显著削弱 Sandbox 的隔离效果。广告域名也不应与企业应用共享 Cookie、Service Worker Scope 或 CSP 信任列表。
2、LANJack 的目标不是浏览器，而是浏览器后面的内网
主 Campaign 不是传统 Drive-by Download。课件归纳的特点包括：通过广告分发、无用户交互、无前置恶意软件，并针对内部服务和 IoT 设备。
图 3：广告脚本被用作面向内网设备的浏览器原生攻击入口
这里需要区分两个边界：
- Same-Origin Policy 约束网页读取其他 Origin 的响应；
- 但浏览器仍可能发出网络连接，连接是否成功、耗时多久、是否发生重定向，都可能暴露信息。
LANJack 把这些信息拼成一条阶段化流程：攻击触发、DNS Cache Priming、LAN Reconnaissance、DNS Rebinding、IoT Fingerprinting/Exploitation Preparation，以及 DNS Cache Pollution/Forensic Evasion。Whitepaper 说明，第六阶段的代码已经实现，但在分析 Campaign 时没有观察到实际触发，应与前五个阶段分开看待。
3、第一阶段：用定向投放和隐藏 iframe 触发
攻击脚本先检查 HTTP 可达性和目标条件，再加载下一阶段。为避免用户察觉，代码把扫描页面放进尺寸极小的隐藏 iframe；同时准备强制跳转作为备用路径。
图 4：地理定向、Cloaking、隐藏 iframe 和强制跳转共同触发后续阶段
广告审核很容易被 Cloaking 绕过：分析节点的地理位置、User-Agent、Cookie、访问频率或网络归属不符合条件时，只看到正常广告。解决这个问题不能只靠单次抓取，应保留多地区、多浏览器和多时间段的 Creative 回放。
广告平台可以在投放侧增加行为门禁：
yaml
creative_policy:deny:-hidden_iframe_to_unapproved_origin-navigation_to_ip_literal-request_to_private_address_space-dynamic_script_from_unregistered_domain-high_cardinality_subdomain_generationrequire:-immutable_creative_hash-declared_network_destinations-reproducible_review_payload
这不是浏览器安全策略的替代，而是广告供应链自己的准入控制。审核版本与实际竞价返回版本必须使用同一内容摘要，否则签过名的只是展示样本。
4、第二阶段：Cache Priming 为 DNS Rebinding 准备窗口
现代浏览器会进行 DNS Pinning，并且浏览器、操作系统、本地 Resolver 和上游递归 DNS 都可能各自缓存结果。攻击者不能简单把同一域名的 A 记录立即从公网地址切到私网地址，然后期待浏览器马上采用。
LANJack 先生成大量带 UUID 的子域名和常见 IoT 端口，将它们加载进隐藏 iframe。Whitepaper 记录的实现构造了 175 个 URL，并以轮转方式预加载和清理，用于估计缓存状态和后续重绑定时机。
图 5：唯一子域名、常见 IoT 端口和隐藏 iframe 用于预热缓存
防守侧可以从高基数 DNS 行为入手。同一页面进程短时间查询大量随机子域名，并集中访问 80、81、8080、8554、9000 等设备常用端口，不符合普通广告的网络画像。
sql
SELECT browser_process_id, registrable_domain, count(DISTINCT fqdn) AS unique_subdomains, count(DISTINCT destination_port) AS unique_ports, min(event_time) AS first_seen, max(event_time) AS last_seen FROM browser_network_event WHERE event_time >= now() -interval'2 minutes'GROUPBY browser_process_id, registrable_domain HAVINGcount(DISTINCT fqdn) >=50ANDcount(DISTINCT destination_port) >=5;
阈值需要按浏览器和业务基线校准。CDN、广告测量和反欺诈脚本也会产生大量子域名，但通常不会同时访问多组内网设备端口。
5、第三阶段：LNA 弹窗没有消除时序侧信道
Chrome 等浏览器正在引入 Local Network Access 权限，阻止公网网页静默访问私网资源。课件展示的攻击仍然可以利用连接时间差：不存在的内网地址通常等待更久才超时，在线设备则更快返回连接成功、拒绝或其他网络错误。
图 6：即使内容不可读，连接时序仍可能泄露设备是否在线
攻击代码使用 no-cors、no-store 并忽略响应内容，只测量请求生命周期。这正是很多防守方案的盲点：CORS 阻止读取响应，不阻止所有连接，也不保证错误时间一致。
浏览器遥测应把以下组合视为局域网扫描候选：
text
公网 Origin + 访问 RFC1918 / localhost / link-local 地址 + 多个相邻 IP 或多个常见管理端口 + 请求主体不读取响应 + 单次超时接近固定值 + 隐藏 iframe 或后台 WebView
企业终端代理还可以直接阻断浏览器进程访问管理 VLAN，只允许经过受控代理或指定应用访问。这样即使浏览器权限模型存在侧信道，网络层也不会把用户浏览器当成内网扫描器。
6、第四阶段：DNS Rebinding 借同一 Origin 指向私网
Same-Origin Policy 判断的是 Scheme、Host 和 Port，不是首次解析得到的 IP。DNS Rebinding 的核心，是让攻击域名先解析到攻击者服务器并加载脚本，之后再把相同 Host 解析到已发现的私网设备。对浏览器而言 Origin 没变，后续请求却到达了内网。
图 7：同一子域名在缓存到期后被重新解析到私网地址
企业 DNS Resolver 应启用 Rebinding Protection，拒绝公共域名返回私网地址。以 Unbound 为例：
conf
server: private-address: 10.0.0.0/8 private-address: 172.16.0.0/12 private-address: 192.168.0.0/16 private-address: 127.0.0.0/8 private-address: 169.254.0.0/16 # 只有企业明确管理的内部域名可以返回私网地址。 private-domain: "corp.example"
这项控制要求客户端实际使用企业 Resolver。DoH、VPN、移动网络和应用自带 Resolver 都可能绕开它，因此还需要终端策略统一 Secure DNS 配置，并监控公网域名解析结果从公网地址切换到 RFC1918 的行为。
sql
SELECT current.fqdn, previous.answer_ip, current.answer_ip FROM dns_answer currentJOIN dns_answer previous ON previous.client_id = current.client_id AND previous.fqdn = current.fqdn AND previous.observed_at < current.observed_at WHERE current.answer_ip <<= inet '10.0.0.0/8'ANDNOT previous.answer_ip <<= inet '10.0.0.0/8'AND current.observed_at - previous.observed_at <interval'5 minutes';
实际查询要同时覆盖全部私网、Loopback 和 Link-local 网段，并处理多 A/AAAA 记录。
7、第五阶段：用 Favicon 和页面特征识别设备
重绑定成功后，LANJack 请求设备根页面和 /favicon.ico，计算 Hash，与硬编码表匹配，再发送厂商特定请求。课件将这一阶段称为 IoT Fingerprinting & Exploitation Preparation。
图 8：根页面、Favicon Hash 和厂商特定请求用于确认设备型号
IoT 管理面不应把“在内网”当作身份。最低限度需要：
- 所有状态变更接口要求认证，不接受默认密码；
- 校验
Origin，拒绝来源为外部站点或null的管理请求； - 使用不可预测 CSRF Token，不能只依赖 Cookie；
- Host Header 只接受设备配置的主机名/IP，防止重绑定域名；
- 管理接口与媒体流量分离，限制浏览器直接访问；
- Favicon、Server Header 和错误页避免暴露精确型号与固件版本。
一个简单的服务端入口检查可以先挡住多数浏览器跨站管理请求：
python
ALLOWED_ORIGINS = {"https://admin.device.local"} ALLOWED_HOSTS = {"admin.device.local", "192.168.50.10"} defvalidate_browser_request(headers: dict[str, str]) -> None: host = headers.get("host", "").split(":", 1)[0].lower() origin = headers.get("origin", "") fetch_site = headers.get("sec-fetch-site", "") if host notin ALLOWED_HOSTS: raise PermissionError("unexpected Host header") if origin and origin notin ALLOWED_ORIGINS: raise PermissionError("cross-origin management request") if fetch_site in {"cross-site", "none"}: raise PermissionError("invalid fetch context")
Origin 和 Fetch Metadata 是附加信号，不是唯一认证。非浏览器客户端可以伪造这些 Header，真正的管理操作仍应使用会话认证或双向 TLS。
8、噪声生成和 CSP 报告都可能被反向利用
主 Campaign 的代码包含 DNS Cache Pollution 阶段：向 5000 个以上随机子域名发起 Broken Image 请求，试图污染 DNS 与浏览器缓存、干扰取证。Whitepaper 说明，分析时没有观察到这一阶段实际触发。
图 9：大量随机子域名和 Broken Image 请求制造浏览器噪声
这种噪声反而容易形成统计特征：单个页面、短时间、高唯一子域名比例、大量 NXDOMAIN/失败图片请求。DNS 检测不要只把它聚合成“访问某主域名”，应保留完整 FQDN 和父页面进程。
Whitepaper 还分析了一个持续约一周的第三变体：攻击者在 iframe 中加载 Google、Facebook 页面，利用登录状态导致的重定向差异触发 CSP Violation Report，再通过 report-uri 收集结果。它不读取跨域页面内容，却把浏览器的安全报告机制变成登录状态侧信道。
身份服务应使用 frame-ancestors 'none' 和 X-Frame-Options: DENY，并让登录与未登录状态尽量返回一致的可观察嵌入行为。CSP Report 接收端也不应默认信任报告内容，必须做来源、速率和字段校验。
9、WebView 会让浏览器控制变得不一致
标准浏览器逐步加入 Mixed Content、Private Network Access、Local Network Access、DNS Pinning、CSP、Sandbox 和 Fetch Metadata。嵌入 App 的 WebView 可能继承应用本身的局域网、Wi-Fi Multicast、Bluetooth 或媒体权限，策略版本也可能落后。
如果 WebView 允许 JavaScript Interface 调用 Native 网络库，请求甚至不会经过浏览器完整的网络安全路径。此时 Same-Origin、CSP 和 DNS Pinning 的假设都可能失效。
移动 App 应将第三方广告 WebView 视为不可信执行环境：
kotlin
webView.settings.javaScriptEnabled = false webView.settings.allowFileAccess = false webView.settings.allowContentAccess = false webView.settings.mixedContentMode = WebSettings.MIXED_CONTENT_NEVER_ALLOW // 不向广告 WebView 暴露 addJavascriptInterface。// 需要交互时使用严格校验 Origin 的消息通道。
如果业务必须启用 JavaScript，应使用单独进程、独立数据目录、域名 Allowlist 和 URL 拦截器，并在 App 网络层拒绝 RFC1918、Loopback、Link-local 和非预期协议。不要依赖 WebView 版本自动继承桌面 Chrome 的全部保护。
10、检测与缓解要覆盖四个控制面
图 10：第三方代码信任、控制不一致、Cache、时序、DNS 和弱 IoT 接口共同组成攻击链
LANJack 能工作，不是因为某一个浏览器漏洞，而是多个合法机制组合后跨越了边界。落地时可以按四个控制面拆解：
- 广告平台：Creative 不可变、目的域名申报、多地区回放、隐藏 iframe 和高基数 DNS 行为检测；
- 浏览器/终端：LNA 默认拒绝、浏览器到管理网段的网络隔离、WebView 最小能力、统一 DNS；
- DNS/网络：Rebinding Protection、公网域名返回私网地址告警、浏览器进程内网扫描检测；
- IoT 设备：认证、Origin/Host 校验、CSRF、管理 VLAN、固件更新和可审计日志。
检测侧可以把完整链条表达成相关规则：广告 iframe 生成大量随机子域名，随后浏览器对多个 RFC1918 地址产生固定超时请求；同一域名的 DNS Answer 又从公网切到私网；最后出现针对设备管理端口和 Favicon 的请求。每一项单独看都可能是噪声，按同一浏览器进程和短时间窗关联后，置信度会明显提高。
这份材料最重要的提醒很朴素：浏览器能访问的网络，就是页面中第三方代码可能触达的网络。把广告当成图片、把 IoT 管理面当成“内网服务”、把 WebView 当成标准浏览器，都会低估真实攻击面。
资料来源
- Moriya Pedael，Black Hat USA 2026：《LANJack: Turning Ads into IoT Recon Tools》
- Black Hat 官方 Session 页面
原始会议材料（仓库内）
- 演讲课件 PDF
- 配套白皮书 PDF
开源资料与原始议题 PDF
本文对应的 Markdown 原稿、Black Hat 原始议题 PDF 与配图已整理到 GitHub，可按文章编号查找和下载。
https://github.com/cybermaxluo/black-hat-usa-2026-talks
也可以点击文末“阅读原文”进入仓库。欢迎 Star、提交 Issue 或参与勘误。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：白帽子罗棋琛 Max Luo
Max Luo《Black Hat USA 2026：LANJack局域网侦察》