{
	"id": "43f53b89-a4ba-486b-95fa-9bd29803e83e",
	"created_at": "2026-04-07T15:35:15.64458Z",
	"updated_at": "2026-04-10T03:26:53.352907Z",
	"deleted_at": null,
	"sha1_hash": "ac3d7aa342977c2a8aade38dccebebec7c3e7af7",
	"title": "EternalBlue – Everything There Is To Know",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 211840,
	"plain_text": "EternalBlue – Everything There Is To Know\r\nBy deugenio\r\nPublished: 2017-09-29 · Archived: 2026-04-07 15:29:23 UTC\r\nResearch By: Nadav Grossman\r\nIntroduction\r\nSince the revelation of the EternalBlue exploit, allegedly developed by the NSA, and the malicious uses that\r\nfollowed with WannaCry, it went under thorough scrutiny by the security community. While many details were\r\nresearched and published, several remained in the dark, and an end-to-end explanation of the vulnerability and\r\nexploit is nowhere to be found.\r\nFor these reasons, we endeavored to conduct a comprehensive research of the vulnerabilities and exploitation\r\nrelated to EternalBlue, by using reverse engineering, kernel debugging and network analysis. The results of this\r\nresearch appear below. We hope that this paper will enhance the understanding of EternalBlue, and help the\r\nsecurity community combat it, and the likes of it in the future.\r\nBackground\r\nThe EternalBlue exploitation tool was leaked by “The Shadow Brokers” group on April 14, 2017, in their fifth\r\nleak, “Lost in Translation.”  The leak included many exploitation tools like EternalBlue that are based on multiple\r\nvulnerabilities in the Windows implementation of SMB protocol.\r\nEternalBlue works on all Windows versions prior to Windows 8. These versions contain an interprocess\r\ncommunication share (IPC$) that allows a null session. This means that the connection is established via\r\nanonymous login and null session is allowed by default. Null session allows the client to send different commands\r\nto the server.\r\nThe NSA created a framework (much like Metasploit) named FuzzBunch, which was part of the leak. The purpose\r\nof this framework is to configure, for example, set victim ip , and execute the exploitation tools.\r\nMicrosoft released patches for the vulnerabilities in the leak, under the MS17-010 (Microsoft Security Bulletin).\r\nCVE-2017-0144 is the CVE ID in MS17-010 that is related to EternalBlue.\r\nSMB Protocol\r\nServer Message Block (SMB), one version of which is also known as Common Internet File System (CIFS),\r\noperates as an application-layer network protocol mainly used for providing shared access to files, printers, and\r\nserial ports and miscellaneous communications between nodes on a network.\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 1 of 25\n\nIt also provides an authenticated inter-process communication mechanism. Most SMB use involves computers\r\nrunning Microsoft Windows, where it was known as the “Microsoft Windows Network” before the subsequent\r\nintroduction of Active Directory. Corresponding Windows services are LAN Manager Server (for the server\r\ncomponent) and LAN Manager Workstation (for the client component) [Wikipedia].\r\nBug Explanations\r\nEternalBlue exploits 3 bugs (named as Bug [A,B,C]) to achive RCE, the explanation for each bug are listed\r\nbelow:\r\nBug A (i.e. “Wrong Casting Bug”)\r\nBug B (i.e. “Wrong Parsing Function Bug”)\r\nBug C (i.e. “Non-paged Pool Allocation Bug”)\r\nBug A (i.e. “Wrong Casting Bug”):\r\nA bug in the process of converting FEA (File Extended Attributes) from Os2 structure to NT structure by the\r\nWindows SMB implementation (srv.sys driver) leads to buffer overflow in the non-paged kernel pool.\r\nA bit about FEA (File Extended Attributes):\r\nThe FEA structure is used to describe file characteristics. For more information, see\r\nhttps://en.wikipedia.org/wiki/Extended_file_attributes.\r\nYou can think about the FEA structure as key and value pairs, where the key is AttributeName and the value is\r\nAttributeValue .\r\nFor example:\r\nIn Os2 format, the struct looks like this:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 2 of 25\n\nAfter you convert the FEA from Os2 format to Windows format (Nt Format), the structure looks like this:\r\nNote– These structures are not valid Structs , because the length of the AttributeName and AttributeValue\r\nchanges (is not a constant). However, it’s simpler to understand the structures using this illustration.\r\nFunctionality:\r\nThe functions listed below are part of the srv.sys driver and they are related to the bug.\r\nSrvOs2FeaListToNt – Converts Os2 FEA List to NT FEA List.\r\nThe logics of this function are:\r\n1. Gets Os2FeaList\r\n2. Calls SrvOs2FeaListSizeToNT to get the appropriate size for NtFeaList .\r\n3. Allocates a buffer from the non-paged pool according to the size returned from SrvOs2FeaListSizeToNT .\r\n4. Iterates over the Os2FeaList until it reaches the SizeOfListInBytes (from Os2FeaList ). In each\r\niteration, it calls SrvOs2FeaToNT to convert the Os2Fea record to NT format and add it to NtFealist .\r\nSrvOs2FeaListSizeToNT – Calculates the size needed to convert Os2FeaList structures into the appropriate\r\nNtFeaList structures.\r\nThe logics of this function are:\r\n1. Calculates the needed buffer size for NtFeaList . The buffer size is calculated according to the required\r\nsize to convert Os2FeaList struct to NtFeaList struct (this is the return value from the function).\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 3 of 25\n\n2. Calculates how many records (in bytes) of Os2Fea from Os2FeaList should be converted to NtFea to\r\nstore them later (by SrvOs2FeaListToNt ) in NtFeaList . The result of the calculation is stored in the\r\nmember of Os2FeaList , named SizeOfListInBytes , by overwriting the previous value .\r\nNote – If there are no invalid Os2Fea records, the SizeOfListInBytes remains untouched.\r\nHowever, if there is an invalid\\overflowed Os2Fea record(s) in Os2FeaList, the value of\r\nSizeOfListInBytes is shrunk.\r\nFor example: If part of the FEA is in the range of the SizeOfListInBytes and the remainder of the FEA\r\nis “out of range” (bigger than SizeOfListInBytes ). It will ignore this FEA and any further “out of range”\r\nFEA and shrink the SizeOfListInByte to the size of all the “valid” FEAs.\r\nNote – SizeOfListInBytes doesn’t restrict the SMB packet size.\r\nSee the example / illustration below\r\nSrvOs2FeaToNT – Converts the Os2Fea record to an NtFea record. The structure is not identical to the NtFea ,\r\nbut it’s quite similar.\r\n*Note that the size of the NtFea record is bigger than Os2Fea because it contains another field named\r\nNextEntryOffset . There is also an alignment of 4 bytes between the NtFea records.\r\nSrvOs2FeaListSizeToNT shrinking illustration:\r\nBefore Shrinking:\r\nAfter Shrinking: if the size of SizeOfListInBytes is below 216:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 4 of 25\n\nAfter Shrinking (bug): if the size of SizeOfListInBytes is above 216\r\n:\r\nThe Buggy Code:\r\nIn a nutshell: There is a wrong casting in the SrvOs2FeaListSizeToNT function, in its second logic (shrinking the\r\nSizeOfListInBytes member of Os2FeaList ). That leads to a small buffer (i.e. NtFeaList ) and large data (out\r\nof buffer boundary) that will be stored on it after conversion (i.e. SizeOfListInBytes ).\r\nInstead of shrinking the SizeOfListInBytes , the function enlarges it.\r\nThe remainder SizeOfListInBytes indicates how many records (in bytes) of Os2Fea should be converted to\r\nNtFea .\r\nHowever, the size of the NtFeaList buffer that returns from the function ( NtFeaListSize ) is calculated\r\ncorrectly for the appropriate size to convert a shrunk Os2FeaList to NtFeaList .\r\nThis leads to a situation in which the size of bytes that should be copied to the buffer ( NtFeaList , which depends\r\non the updated value SizeOfListInBytes member of Os2FeaLis ) is bigger than the buffer size\r\n( NtFeaListSize ). This causes an Out of Bound write.\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 5 of 25\n\nMore details:\r\nSizeOfListInBytes is a DWORD size member of Os2FeaList . If shrinking is needed, the function treats\r\nSizeOfListInBytes as a Word member and it updates only the 2 bytes, instead of 4 bytes (with the shrunk size).\r\nThe 2 most significant bytes remain untouched. This bug causes SizeOfListInBytes to be enlarged instead of\r\nshrunk.\r\nIf the value of SizeOfListInBytes is in the range of 216, there is no problem and the function works as expected.\r\nHowever, if the value of SizeOfListInBytes is above the range of 216, it could be enlarged instead of shrunk.\r\nIn the 2 examples below, the first is of a normal scenario (if the bug wouldn’t have existed) and the second is of\r\nthe buggy scenario.\r\nFunctions pseudo code:\r\n* The important lines are marked in Yellow\r\nSrvOs2FeaListToNT :\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 6 of 25\n\nSrvOs2FeaListSizeToNT :\r\nLine 32 is the buggy line. It updates only the size of Word (LOWORD) from the Dword\r\nSizeOfListInBytes\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 7 of 25\n\nSrvOs2FeaToNT:\r\nBug B (i.e. “Wrong Parsing Function Bug”):\r\nWhen you transmit a file over SMB protocol, there are several data-related functions:\r\n1. SMB_COM_TRANSACTION2: Sub-commands provide support for a richer set of server-side file system\r\nsemantics. The “ Trans2 subcommands”, as they are called, allow clients to set and retrieve Extended Attribute\r\nkey/value pairs, make use of long file names (longer than the original 8.3 file format names), and perform\r\ndirectory searches, among other tasks.\r\n2. SMB_COM_NT_TRANSACT: Sub-commands extend the file system feature access offered\r\nby  SMB_COM_TRANSACTION2 , and also allow for the transfer of very large parameter and data blocks.\r\nIf the data sent via  SMB_COM_TRANSACTION2 or by  SMB_COM_NT_TRANSACT exceeds the  MaxBufferSize\r\nestablished during session setup, or total_data_to_send  is bigger than transmitted_data , then the transaction\r\nuses the  SECONDARY sub-command.\r\nEach sub-command has a corresponding sub-command _SECONDARY . This _SECONDARY is used when the data\r\nsent is too big for a single packet. It is therefore split over a few packets to fulfill “the total size of data to be sent”\r\nthat was declared in the first packet. The packets that follow the first sub-command have the corresponding\r\n_SECONDARY sub-command set as their command.\r\nExample:\r\nSMB_COM_NT_TRANSACT=\u003e SMB_COM_NT_TRANSACT_SECONDARY\r\nSMB_COM_TRANSACTION2=\u003e SMB_COM_TRANSACTION2_SECONDARY\r\nIn  SMB_COM_TRANSACTION2, the maximum data that can be sent is represented by a parameter in the header\r\nof  SMB_COM_TRANSACTION2 in the field of a Word size. The same is true for the\r\nSMB_COM_TRANSACTION2_SECONDARY .\r\nHowever, in  SMB_COM_NT_TRANSACT , the maximum data that can be sent is represented by a parameter in the\r\nheader of  SMB_COM_NT_TRANSACT in the field of Dword size. The same is true for the\r\nSMB_COM_TRANSACTION2_SECONDARY .\r\nTherefore, there is a difference between the amounts of data that can be sent in  SMB_COM_TRANSACTION2, where\r\nthe maximum data length is represented in a Word (max 0xFFFF ), and in  SMB_COM_NT_TRANSACT where the\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 8 of 25\n\nmaximum is represented in a Dword ( 0xFFFFFFFF ).\r\nHowever, as there is no validation for which function started the transaction ( SMB_COM_TRANSACTION2\r\n or  SMB_COM_NT_TRANSACT ), parsing is according to the last transaction type.\r\nThus, it’s possible to send:\r\nSMB_COM_NT_TRANSACT  followed by SMB_COM_TRANSACTION2_SECONDARY\r\nThis situation can lead to wrong data parsing, and this bug enables\r\nBug A by treating Dword as Word .\r\nIt happens when  SMB_COM_NT_TRANSACT ( Dword ) is followed by  SMB_COM_TRANSACTION2_SECONDARY  ( Word ).\r\nThis leads to parsing the data, wrongly, as if it originally came from a transaction of the SMB_COM_TRANSACTION2\r\ntype.\r\nBug C (i.e. “Non-paged Pool Allocation Bug”):\r\nIn a nutshell: There is a bug that lets you allocate a chunk with a specified size in the kernel non-paged pool with\r\nthe specified size. It is used in the heap grooming phase when creating a hole that later will be filled with a data\r\nsize that causes an out of bound write to the next chunk ( Bug A \u0026 Bug B ).\r\nAn SMB_COM_SESSION_SETUP_ANDX request MUST be sent by a client to begin user authentication on an SMB\r\nconnection and establish an SMB session.\r\nThis command is used to configure an SMB session. At least one SMB_COM_SESSION_SETUP_ANDX MUST be sent to\r\nperform a user logon to the server and to establish a valid UID.\r\nThere are 2 formats for an SMB_COM_SESSION_SETUP_ANDX request:\r\nThe first is used for LM and NTLM authentication , documented here. This is the format of the request:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 9 of 25\n\nThe second is used for NTLMv2 ( NTLM SSP ) authentication, documented here. This is the format of the request:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 10 of 25\n\nIn both formats, the request is split into 2 sections:\r\nSMB_Parameters – Contains parameters of sizes between 1-4 bytes. The WordCount field represents the\r\ntotal length of SMB_Parameters struct members in a Word size.\r\nSMB_Data – Contains data in a variable size. The ByteCount field represents the length of the SMB_Data\r\nstruct members section in bytes.\r\nSumming the size of the fields, in the first format, the  WordCount equals 13 and in the second format ( extended\r\nsecurity ), the WordCount equals 12.\r\nThe server does an integrity check, with a function named SrvValidateSmb , for SMB packets that include the\r\nformat of SMB_Parameters and SMB_Data .\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 11 of 25\n\nAlthough there is no bug in the SrvValidateSmb function, there is a bug in the extraction of SMB_DATA by a\r\nfunction named BlockingSessionSetupAndX .\r\nBy triggering the bug, the BlockingSessionSetupAndX function wrongly calculates  ByteCount , which leads to\r\nan allocation of controlled size – bigger than the packet data – in the non-paged pool.\r\nHere is the buggy part:\r\nThe SMB_COM_SESSION_SETUP_ANDX request is handled by the BlockingSessionSetupAndX function. Below is\r\npseudo code for handling both request formats (only the relevant part is shown).\r\nFrom the pseudo code above, we see that if we send an SMB_COM_SESSION_SETUP_ANDX request as Extended\r\nSecurity ( WordCount 12) with  CAP_EXTENDED_SECURITY , but without FLAGS2_EXTENDED_SECURITY , the request\r\nwill be processed wrongly as an NT Security request ( WordCount 13, marked in yellow).\r\nIn this case, the GetNtSecurityParameters function is called, but it calculates the  SMB_DATA  wrongly. The\r\nrequest is in  Extended Security  ( WordCount 12) format, but the function intends to parse it as NT Security\r\nrequest ( WordCount 13).\r\nAs a result, it reads  ByteCount  from the wrong offset in the struct, and allocates space in the non-paged kernel\r\npool for NativeOs and NativeLanMan unicode strings (see the structure above), according to the wrong offset of\r\nByteCount.\r\nThis bug allows you to send a small packet that leads to a big allocation in the non-paged pool, which is used to\r\ncreate a big allocation as a placeholder.\r\nThis allocation will later be freed (creating a HOLE ) and allocated again by an NtFea chunk that will overflow\r\nthe next chunk. This issue is explained further in the exploitation flow section.\r\nExploitation Technique\r\n* See the glossary section for an explanation of terms.\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 12 of 25\n\nPrimitives:\r\n1. MDL ( pMdl1 ) Overwrite – When we get a write primitive to an MDL , we can map an I/O data to a\r\nspecific virtual address. In the exploit we have an OOB (out-of-bound) write in srv allocation ( Bug A\r\nand Bug B ). We can therefore overwrite the header of srvnet chunk (using some sort of grooming).\r\nNote that in the header of srvnet chunk there is a MDL As explained in the glossary section, a virtual\r\naddress in the MDL maps the incoming data from the client to a specific virtual address. Therefore, if we\r\nchange it by some sort of overwriting, the data from the client is mapped to the address that would have\r\nbeen overwritten. It enables the client data (that we control) to be written wherever we want (controlling\r\nthe MDL ).\r\n2. pSrvNetWskStruct Overwrite –  pSrvNetWskStruct is located in the srvnet header struct and points to\r\nthe SrvNetWskStruct . This struct contains a pointer to the function HandlerFunction , which is called\r\nwhen the related srvnet connection is closed. If we overwrite the pointer to the SrvNetWskStruct struct\r\n( pSrvNetWskStruct ) with an address that contains a fake SrvNetWskStruct whose values we control, we\r\ncan control the value of the pointer to the function that is called when the srvnet connection is closed\r\n( HandlerFunction ), which leads to RCE.\r\nUsing the 2 primitives for RCE:\r\nAs explained earlier, if we overwrite the  MDL (primitive 1), we can control where the data under our control (data\r\nsent from the client to the server, over a connection that is related to srvnet ) would be written.\r\nIf we write (overwrite) in the virtual address ( StartVA  field) of the MDL a static address like an address\r\nwithin  HAL's Heap , the data that the client sends will be mapped to a virtual address within the  HAL's Heap .\r\n( HAL's Heap has execute permission in Windows versions prior to Windows 8).\r\nTo execute that data, which have been written to the HAL's Heap (by primitive 1) we must combine it with\r\nprimitive 2.\r\nIf we change the pointer to  SrvNetWskStruct ( pSrvNetWskStruct ) to point to the same address that was  crafted\r\nin the MDL (static address on the HAL's Heap ), in that address ( HAL's Heap ) we can create a fake\r\nstruct ( SrvNetWskStruct ) preceded by the shellcode. The shellcode would then be called upon closing the\r\nrelated srvnet connection, and we achieve RCE.\r\nNotes: The SrvNetWskStruct struct contains a pointer to a function ( HandlerFunction ) that is called when\r\nsrvnet connection is closed. The pointer to function ( HandlerFunction ) should point to our shellcode.\r\nExploitation Flow\r\nStep 0:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 13 of 25\n\nAssume that this is the initial state of the non-paged kernel pool and the HAL's Heap .\r\nStep 1:\r\nsrv allocation according to  Bug A and Bug B . In this step, only the connection for Os2Fea transmission is\r\nopened.\r\nStep 2:\r\nFills part of the OS2Fea first by SMB_COM_NT_TRANSACT . Later, it is filled by  SMB_COM_NT_TRANSACT_SECONDRY or\r\nSMB_COM_TRANSACTION2_SECONDARY as described in Bug A and Bug B , but without sending the last  SECONDARY\r\npacket (this does not yet trigger the OOB write).\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 14 of 25\n\nStep 3:\r\nOpen multiple srvnet connections to increase the chances of srvnet overwriting (overflow) by preceding the\r\nsrv allocation of converted OS2Fea to NtFea . Using  Bug A and Bug B , this leads to overflowing the next\r\nchunk ( srvnet Header ). This technique is also used as a grooming technique.\r\nStep 4:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 15 of 25\n\nAt this point, the attacker creates a chunk according to  Bug C . This chunk is used as a placeholder for the\r\nconverted Os2Fea to NtFea . It should be the same size as the overflowing NtFeaList (wrong calculation, due\r\nto Bug A ). This chunk is later freed by closing the connection, and NtFea (write out-of-bound) is allocated\r\ninstead (fills the hole).\r\nBefore it is freed, more srvnet chunks (new srvnet  connections) are allocated.\r\nIt is freed just before the final packet of srv allocation ( SMB_COM_TRANSACTION2_SECONDARY ) that allocates a\r\nchunk for storing the NtFea converted data.\r\nMost likely, this allocation is stored in this freed chunk. It’s part of the grooming technique.\r\nStep 5:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 16 of 25\n\nNew srvnet allocation (by a new connection). This srvnet chunk is located after “the chunk of Bug C .” If\r\nthe NtFea is located in the previous chunk (“the chunk of Bug C “), it would lead to an overflow of this\r\nsrvnet chunk.\r\nStep 6:\r\nThe “chunk of Bug C ” is freed.\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 17 of 25\n\nStep 7:\r\n1. The last Os2Fea data is sent (using  SMB_COM_TRANSACTION2_SECONDARY ). This leads to allocation to convert\r\nOs2Fea to NtFea .\r\n2. The NtFea is allocated at the free hole (previously was allocated with the chunk according to Bug C ).\r\n3. NtFea overwrites (overflow) the next chunk, which is a srvnet chunk. The srvnet header is overwritten\r\nand modifies these 2 header properties to point to the same address in the HAL's Heap :\r\n– pSrvNetWskStruct , the pointer to the struct that includes the function that is called when the connection is\r\nclosed.\r\n– MDL that is used to map the next incoming data (from the user) in this srvnet connection.\r\nStep 8:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 18 of 25\n\n1. Incoming data in the overflowed srvnet connection from the user arrives.\r\n2. Because of the previous overwrite of the MDL , this data is written to the HAL's Heap , instead of the\r\nreserve place in the kernel pool (the value of the MDL before the overwrite).\r\n3. The data from the user that was written to the HAL's heap contains a fake struct ( SRVNET_RECV ).\r\n4. pSrvNetWskStruct points to the fake struct ( SRVNET_RECV ) in the HAL's heap . When the connection\r\ncloses, the HandlerFunction from the fake struct is called.\r\n5. The data from the user after the fake struct contains the shellcode, DoublePulsar . It is written after the\r\nfake struct to the HAL's Heap .\r\nStep 9:\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 19 of 25\n\n1. All the srvnet connections are closed.\r\n2. In each srvnet connection, the HandlerFunction pointed at by the SRVNET_RECV  is executed.\r\nHowever, in the overflowed srvnet connection, the pointer to the SRVNET_RECV   ( pSrvNetWskStruct ) is\r\nfake and points to the fake struct in the HAL's heap .\r\n3. The fake HandlerFunction is executed, but this function is the shellcode.\r\nNetwork Analysis\r\nThis is an edited wireshark pcap of a successful exploitation on Windows 7. It includes only one exploitation try;\r\nin reality, it usually takes more than a single attempt. We added relevant filters, coloring and comments.\r\nResponses were omitted for readability.\r\nThe comments next to each packet explain the purpose of the packet in the exploitation flow.\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 20 of 25\n\nGlossary\r\nSMBv1:\r\nClient systems use the Common Internet File System (CIFS) Protocol to request file and print services from server\r\nsystems over a network. CIFS is a stateful protocol, in which clients establish a session with a server and use that\r\nsession to make a variety of requests to access files, printers, and inter-process communication (IPC) mechanisms,\r\nsuch as named pipes. CIFS imposes state to maintain an authentication context, cryptographic operations, file\r\nsemantics such as locking, and similar features.\r\nThe Server Message Block (SMB) Version 1.0 Protocol extends the CIFS Protocol with additional security, file,\r\nand disk management support. These extensions do not alter the basic message sequencing of the CIFS Protocol\r\nbut introduce new flags, extended requests and responses, and new information levels. All of these extensions\r\nfollow a request/response pattern in which the client initiates all of the requests.\r\nSMBv2:\r\nThe Server Message Block (SMB) Protocol Versions 2 and 3 supports the sharing of file and print resources\r\nbetween machines. The protocol borrows and extends concepts from the Server Message Block (SMB) Version\r\n1.0 Protocol.\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 21 of 25\n\nThese drivers are related to SMB protocols:\r\nsrv.sys – Related to SMBv1 protocol\r\nsrvnet.sys – Related to SMBv2 protocol\r\nsrv allocation:\r\nSome SMBv1 packets from the client to the server cause allocation in a paged or non-paged kernel pool.  Bug\r\nA  and  Bug B use the SMBv1 protocol that leads to srv allocation . The out-of-bound write happens in srv\r\nallocation .\r\nsrvnet allocation:\r\nSome SMBv2 packets from the client to the server cause allocation in a paged or non-paged kernel pool. In the\r\nexploit, the srvnet chunk is allocated, so we can overflow it with srv allocation . By doing this, we overwrite a\r\nstructure in the srvnet header that leads to RCE (Remote Code Execution)\r\nSRVNET_RECV Struct:\r\nThis struct is pointed to by the pSrvNetWskStruct  variable in the SRVNET_HEADER . This is used by srvnet.sys\r\nto call the handler function (which points to the shellcode address in the EternalBlue scenario) when the\r\nconnection is closed.\r\nSRVNET_HEADER Struct:\r\nThis struct resides in the beginning of the srvnet related chunk. In the exploitation, we use/manipulate it by\r\noverwriting these fields:\r\npSrvNetWskStruct : Pointer to the  SRVNT_RECV struct\r\npMdl1 : Pointer to a MDL . This maps received data to virtual address space.\r\nAfter the srvnet connection is established, it waits for another data packet from the client. When it arrives,\r\nit maps the received data to the address specified by the MDL .\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 22 of 25\n\nMDL:\r\nA memory descriptor list (MDL) is a system-defined structure (kernel structure) that describes a buffer by a set of\r\nphysical addresses. A driver performs direct I/O receives a pointer to an MDL from the I/O manager, and reads\r\nand writes data through the MDL.\r\nAn I/O buffer that spans a range of contiguous virtual memory addresses can be spread over several physical\r\npages, and these pages can be discontinuous. The operating system uses an MDL to describe the physical page\r\nlayout for a virtual memory buffer. For more info, see references 1, 2.\r\nControlling the MDL lets you “write-what-where” the primitive.\r\nWhen MDL is “locked”, specific physical pages are mapped to specific virtual address space.\r\nFor example: It is possible to map the entire virtual page range to one physical page. No copy is needed because\r\nevery request (for example, read/write) to a specific virtual range will fetch the same physical page.\r\nStructure\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 23 of 25\n\nIllustration\r\n[https://i-msdn.sec.s-msft.com/dynimg/IC454060.gif]\r\nHAL's Heap  – The Windows HAL’s heap is located at 0xffffffff’ffd00000 in 64-bit and at 0xffd00000 in 32-bit\r\n(the address was static until Windows10). This area is executable in Windows versions prior to Windows 8 /\r\nServer 2012.\r\nSummary\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 24 of 25\n\nIn this research paper, we attempted to shed light on important sections of the EternalBlue vulnerabilities and\r\nexploit, and provide a full step-by-step explanation of the causes for the vulnerabilities and their exploitation. It is\r\nour belief that with better understanding of the roots of EternalBlue, we will be able to improve the security of\r\nusers around the world.\r\nAs important as EternalBlue is, it is not the first, nor the last major exploit that enables hackers to take complete\r\ncontrol over entire networks. Unfortunately, nefarious exploits continue to appear, as was recently shown by\r\nMicrosoft itself. Users and organizations cannot wait for a second round against cyber threats, and must protect\r\nthemselves with the most up-to-date protections, capable of detecting and blocking any cyber-attack on its tracks.\r\nI would also like to thank my colleagues Omri Herscovici, Yannay Livneh, and Michael Kajiloti for their help in\r\nthis research.\r\nThe Check Point IPS blade provides protections against these threats:\r\nMicrosoft Windows EternalBlue SMB Remote Code Execution\r\nReferences\r\nhttps://gist.github.com/worawit/bd04bad3cd231474763b873df081c09a\r\nhttps://github.com/worawit/MS17-010\r\nhttp://blog.trendmicro.com/trendlabs-security-intelligence/ms17-010-eternalblue/\r\nhttps://www.rapid7.com/db/modules/exploit/windows/smb/ms17_010_eternalblue\r\nhttps://www.risksense.com/_api/filesystem/466/EternalBlue_RiskSense-Exploit-Analysis-and-Port-to-Microsoft-Windows-10_v1_2.pdf\r\nhttps://en.wikipedia.org/wiki/EternalBlue\r\nhttps://msdn.microsoft.com/en-us/library/windows/hardware/ff565421(v=vs.85).aspx\r\nhttps://msdn.microsoft.com/en-us/library/windows/hardware/dn614012(v=vs.85).aspx\r\nhttps://msdn.microsoft.com/en-us/library/cc246328.aspx\r\nhttps://msdn.microsoft.com/en-us/library/ee441849.aspx\r\nhttps://msdn.microsoft.com/en-us/library/cc246233.aspx#gt_e1d88514-18e6-4e2e-a459-20d5e17e9078\r\nhttps://msdn.microsoft.com/en-us/library/cc246233.aspx#gt_ee1ec898-536f-41c4-9d90-b4f7d981fd67\r\nhttps://msdn.microsoft.com/en-us/library/ee441741.aspx\r\nhttps://msdn.microsoft.com/en-us/library/ee915515.aspx\r\nhttps://msdn.microsoft.com/en-us/library/ff359296.aspx\r\nhttps://msdn.microsoft.com/en-us/library/ee441551.aspx\r\nhttps://msdn.microsoft.com/en-us/library/ee442101.aspx\r\nhttps://msdn.microsoft.com/en-us/library/windows/hardware/ff545793(v=vs.85).aspx\r\nhttps://en.wikipedia.org/wiki/The_Shadow_Brokers\r\nhttps://steemit.com/shadowbrokers/@theshadowbrokers/lost-in-translation\r\nSource: https://research.checkpoint.com/2017/eternalblue-everything-know/\r\nhttps://research.checkpoint.com/2017/eternalblue-everything-know/\r\nPage 25 of 25",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://research.checkpoint.com/2017/eternalblue-everything-know/"
	],
	"report_names": [
		"eternalblue-everything-know"
	],
	"threat_actors": [
		{
			"id": "d4f7cf97-9c98-409c-8b95-b80d14c576a5",
			"created_at": "2022-10-25T16:07:24.561104Z",
			"updated_at": "2026-04-10T02:00:05.03343Z",
			"deleted_at": null,
			"main_name": "Shadow Brokers",
			"aliases": [],
			"source_name": "ETDA:Shadow Brokers",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "171b85f2-8f6f-46c0-92e0-c591f61ea167",
			"created_at": "2023-01-06T13:46:38.830188Z",
			"updated_at": "2026-04-10T02:00:03.114926Z",
			"deleted_at": null,
			"main_name": "The Shadow Brokers",
			"aliases": [
				"Shadow Brokers",
				"ShadowBrokers",
				"The ShadowBrokers",
				"TSB"
			],
			"source_name": "MISPGALAXY:The Shadow Brokers",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775576115,
	"ts_updated_at": 1775791613,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ac3d7aa342977c2a8aade38dccebebec7c3e7af7.pdf",
		"text": "https://archive.orkl.eu/ac3d7aa342977c2a8aade38dccebebec7c3e7af7.txt",
		"img": "https://archive.orkl.eu/ac3d7aa342977c2a8aade38dccebebec7c3e7af7.jpg"
	}
}