NetBIOS名称欺骗和LLMNR欺骗
目录
LLMNR和NetBios
什么是LLMNR和NetBIOS名称服务器广播？
当DNS名称服务器请求失败时，Microsoft Windows系统就会通过链路本地多播名称解析（LLMNR）和Net-BIOS名称服务（NBT-NS）试图在本地进行名称解析。
LLMNR和Netbios NS广播存在的问题
当DNS名称无法解析的时候，客户端就会将未经认证的UDP广播到网络中，询问它是否为本地系统的名称。 事实上，该过程是未被认证的，并会广播到整个网络，从而允许网络上的任何机器响应并声称是目标机器。
什么是LLMNR / NBT-NS欺骗？
通过侦听LLMNR和NetBIOS广播，攻击者可以伪装成受害者（客户端）要访问的目标机器，从而让受害者乖乖交出相应的登陆凭证。在接受连接后，攻击者可以使用 Responder 或 Metasploit 等工具将请求转发到执行身份验证过程的服务（如SMB）。 在服务身份验证过程中，受害者会向服务器发送用于身份认证的NTLMv2哈希值，这个哈希值会被攻击者接收并保存。之后就可以使用像Hashcat 或John Ripper（TJR）这样的工具在线破解，或直接用于 pass-the-hash 攻击。
在Windows中，LLMNR和NBT-NS是默认启用的，并且了解这种攻击的人很少，所以我们可以在内部渗透测试中利用该攻击来收集凭据。为此，我们可以在使用其他攻击手段进行测试的过程中，可以让Responder一直监听着。
Netbios(Network Basic Input Output System)：网络基本输入输出系统，NetBIOS协议是由IBM公司开发，主要用于20-200台计算机的局域网。Netbios是一种应用程序接口(API)，系统可以利用WINS服务、广播及Lmhost文件等多种模式将NetBIOS名解析为相应IP地址，实现信息通讯作用是为了给局域网提供网络以及其他特殊功能，几乎所有的局域网都是在NetBIOS协议的基础上工作的。在Windows操作系统中，默认情况下在安装 TCP/IP 协议后会自动安装NetBIOS。
查看局域网内其他主机的 NetBIOS Name ： nbtscan --r 10.96.10.0/24
LLMNR(Link-LocalMulticast NameResolution)：链路本地多播名称解析（LLMNR），是一个基于协议的域名系统（DNS）数据包的格式。当主机访问另外一台主机时，如果只知道对方的主机名，则会向局域网内广播请求，询问该主机名对应的ip地址，然后收到该请求的主机首先会判断自己的主机名是否是这个，如果是的话，则会回复一个ip地址，如果主机名不符合，则丢弃。LLMNR协议就类似于ARP协议。
NetBIOS 和 Link-LocalMulticast NameResolution（LLMNR）是Microsoft针对工作组和域设计的名称解析协议，主要用于局域网中的名称解析。当DNS解析失败时，Windows系统会使用 NetBIOS 和 LLMNR 搜索名称。这些协议只为本地连接设计。
NetBIOS 和 LLMNR在WindowsVista以后的系统中均实现，二者的主要区别在于：
- NetBIOS基于广播，而LLMNR基于多播；
- NetBIOS在WindowsNT以后的所有操作系统上均可用，而只有WindowsVista和更高版本才支持LLMNR；
- LLMNR还支持IPv6，而NetBIOS不支持，因此，在启用了IPv6，但对IPv6管理不如IPv4那样细致的复杂网络中，就可能发生更广泛的攻击。
攻击原理
NetBIOS和LLMNR协议对于没有DNS的工作站系统来说很有帮助，但也对攻击者大开方便之门。当人们输入不存在、包含错误或者DNS中没有的主机名时，就会使用这些协议在网络中搜索主机，这些协议的本质决定了本地网络上的任何主机都可以回答请求。这意味着作为攻击者，我们能够代替网络上任何不存在的主机回答请求，并诱导搜索内容的主机连接到我们。
更严重的是，当我们使用Metasploit和Responder等工具时，可以要求验证受害者主机的身份，而如果我们被认为是这些主机所在的本地网络中的一部分时，他们就会把自己进行哈希后的Windows凭据发给我们
Responder
Responder是由LaurentGaffie发布的一款功能强大且简单易用的内网渗透工具，将NetBIOS名称服务（NBNS）、LLMNR和DNS欺骗集成到一个工具中。Kali中默认安装了Responder
Responder的特性包括内置SMB认证服务器、MSSQL认证服务器、HTTP认证服务器、HTTPS认证服务器、LDAP认证服务器，DNS服务器、WPAD代理服务器，内建FTP、POP3、IMAP、SMTP服务器用于收集明文的凭据。
Responder会将所有抓取到的hash打印到标准输出接口上，同时会将抓取到的数据存储到 /usr/share/responder/logs/ 文件夹下。
所有的活动都会记录到Responder-Session.log,分析模式下的日志保存到Analyze-Session.log,毒化模式下的日志保存到Poisoners-Session.log.同时所有抓到的hash都会存储到我们在Responder.conf中配置的sqlite数据库中.
攻击过程
- 用户发送不正确的SMB共享地址 \\ SNARE01
- DNS服务器响应 \\SNARE01 - NOT FOUND
- 客户端进行 LLMNR / NBT-NS广播
- 攻击者告诉客户端它是SNARE01，并接受被害者发送用于认证的NTLMv2哈希值，保存于本地
- 响应者将错误发送回客户端，因此最终用户如果不是精于此道的话，通常不会引起警觉
攻击端输入：
responder -I eth0 -f #-I指定使用的网卡，-f允许攻击者查看受害者的主机指纹。
开启毒化，针对LLMNR、NBT-NS（NetBIOS名称服务）、DNS/MDNS的毒化攻击已经开启。靶机端只要随便输入不能解析的名称
可以看到，攻击端已经收到了靶机的NTLMv2版本的hash值，该值被存放到了 /usr/share/responder/logs/ 目录下
最后一步是破解NTLMv2哈希值，这一步成功与否与被害者密码的强弱和你的密码字典有关
最新文章
- js像素运算问题
- 由overflow-x:scroll产生的收获
- Windows2008 R2 Enterprise离线安装IE10和VS2015过程记录
- Nginx：Pitfalls and Common Mistakes
- MySQL分区表例子——List分区
- CPU卡读写程序
- Swift 面向对象解析（二）
- android使用TextView实现跑马灯的效果（1）
- Javascript及Jquery获取元素节点以及添加和删除操作
- Ubuntu问题：E45: 'readonly' option is set (add ! to override)错误解决
- ubuntu14.04上实现faster rcnn_TF的demo程序及训练过程
- pyinstaller打包错误 UnicodeDecodeError: 'gbk' codec can't decode byte 0xab in position 160:
- Java并发编程_synchronized关键字的用法（一）
- VSFTP服务配置
- Java 中转换为String类型的四种方法
- 自带hyper -v 或者 Vmware安装Linux centos
- 突发奇想之：源码及文档，文档包括源码---xml格式的源码，文档源码合并；注释文档化，文档代码化；
- nginx+redis+4个tomcat 负载均衡
- fastcgi_param解释
- Eclipse “cannot be resolved to a type” error