Author Topic: Compromising network DiskCryptor PXE-bootloader (the encryption key).  (Read 3026 times)


  • Sr. Member
  • ****
  • Posts: 418
The following written was obvious for me. However, as it turns out, the obvious to one is not always obvious to all. Therefore, the following steps will be described, as a demonstration, you can call it a proof of concept.


I used three virtual machines for testing:
1 - DHCP- and TFTP-server with a network DC-loader file.
2 - DC encrypted workstation, the victim computer to be compromised.
3 - Attacker workstation, which conducted monitoring of network activity.
All three machines are on the same local network.The network address/mask is

The first machine is Windows Server 2003 SP2 installed, installed and configured a standard DHCP-server with ip.

As a TFTP/DHCP-server software used TFTP32/64 ( Additionally, check the operation of the standard Microsoft DHCP-server.
Settings of MS DHCP and TFTP in the picture SRV1-CONF.png, tftpd32 additional configuration as DHCP-server in the picture SRV2-CONF.png.
In this case, DHCP is configured so that it provides only for loading configuration selected MAC-address of encrypted machine. The options (PCXX Properties) central to this case are parameters 066 Boot Server Host Name and 067 Bootfile Name - TFTP-server IP-address ( and PXE-loader filename (PX1NET-OPENKEY.IMG).

The second machine running Windows 7 x64 SP1, the network address is automatically assigned. The configuration of the hard disk, DiskCryptor PXE-loader options are in the picture VICTIM1-CONF.png,
Additional boot loader configuration in the picture VICTIM2-CONF.png.
Both hard disk partitions are encrypted same blank password with the same keyfile. In the BIOS Setup set the booting via the network interface first.
Options of PXE-boot loader are pointed to start using the built-in keyfile without a password. The keyfile is presented in the form of an explicit character string [THIS IS SECRET NETWORK KEYFILE, PLAIN TEXT, UNSECURED DATAFILE] It is solely for the convenience and clarity.
In the picture VICTIM-PXE-START.png presented by the time the operating system starts, see the posts from the PXE-BIOS module.

And the third machine running Windows Server 2003, installed a network analyzer WireShark ( With it going packets passing on the network at the start of the second workstation.

So as in the experiment used a virtual environment, the Wireshark can collect all packets going between server and the victim workstation. In reality, it is certainly not the case, and the analyzer can only see packets addressed directly to the attacker site or broadcasting messages. But as it turned out, and such data is sufficient for a successful attack.

For convenience, first consider the "easy" option to the full packet dumps to visualize what and when transmitted on the network. In our case, this is achieved by switching the mode of the network adapter Wireshark settings in Promiscuous mode.

A picture WIRE-PROMIS-GENERAL.png shows the general sequence of packets in the case of regular use DHCP (Microsoft) and TFTP32 on the "server".
Packets 1 - 6 - obtaining of the network settings from DHCP-server by the victim computer.
Packets 7 - 88 - TFTP-session, a DC-loader file transfer to PXE-client, direct transfer of the body of the file is in 11-88 packets. Its alternate with blocks of data from the server to the client and the responses acknowledgments from the client to the server.
Packets 90 and following - this network activity is already loaded Windows 7.
Packets 90 and 91 - this is secondary DHCP-request from OS. Visible characteristic delay time between 89 and 90 packets needed to OS boot.

A picture WIRE-PASSIVE-GENERAL.png shows the same sequence of packets for the same case, it will observe the following picture a hypothetical attacker, if he is connected to a local area network for surveillance. Here are only visible broadcasts packets:
Packets 1 - 5 - PXE-booting
Packets 6 and following - boot and use the OS.

Actually, for a successful attack must be received PXE-bootloader file and get to know IP-address of the TFTP-server. The keyfile is retrieved from the body of the loader, it
has a length of 64 bytes, and is offset by 0326eh from the beginning of the file for this version of DC (1.1.846.118).

Additionally, it may require a MAC-address of the NIC of the victim machine, it may only be necessary for the correct network interface emulation victim computer
with the aim of provide access to the TFTP-server. But, usually, as such, TFTP-servers do not have such protection.

In picture WIRE-DHCP-OFFER.png shows where extracted all data of interest:
Packet 2, a DHCP offer, issued by the server to the client, and in which everything is:
Your (client) IP address: - proposed by the IP-address of the client.
Next server IP address : - this option is IP-address of the TFTP-server, also known as option 066 Boot Server Host Name.
Client MAC address: vmware_e0:e0:48 (00:0c:29:e0:e0:48) - MAC address of the client, it is also seen in other places saved session.
Bootfile name = "PX1NET-OPENKEY.IMG" - the name of the image file PXE-boot stored on the TFTP-server, it is option 067 Bootfile Name.
The network can be several DHCP-server, so you need to consider all types of packages DHCP Offer from different DHCP-server and take into account such, which is the answer from the DHCP-server DHCP ACK (the packet number 4) - it is a preliminary proposal will be accepted by the client.
It is also possible to take into account the packets 5 and 6 - ARP-packets. By deciphering the 5th packet shows that the client has received the address (and all the proposed settings) from the DHCP server address

More picture WIRE-TFTP-KEY.png:
This shows exactly where the key file is transmitted in the loader (TFTP-session). Diskcryptor "lucky", the key file is not broken packets, lies entirely within one of the packets. Again, this is the perfect academic case, in reality what the transmission can be intercepted only if the local network is implemented on non-switched devices that have probably now do not produce and do not use.

So, after receiving the initial data, the attacker can immediately try to get the bootloader, using the knowledge. Typically, TFTP-server is not protected against access by IP-address.

in the picture TFTP-IMAGE-KEY.png illustrates the process of preparation. I used the built-in TFTP client. For Windows 7,8,10 it is added via the Control Panel (Add/Remove Windows components).
The command line to get loader in our case is tftp.exe -i GET PX1NET-OPENKEY.IMG
After receiving are available and extract the keyfile from the known displacement. The displacement if it is unknown (eg a different version of the loader), it is calculated:
after the key sequence are error messages loader (partition unbootable, I/O Error etc.), and the start key is preceded by zero bytes.

It was the first version of the attack, when the attacker workstation is set to watch, made the collection and analysis of network packets that need to filter on specific attributes (DHCP Discover / DCHP Offer).

The second version follows from the knowledge gained in the first example:
To carry out a successful attack requires a knowledge of the encrypted MAC-address of the computer. Is no need to wait for the start of its real. Sometimes, the MAC address is printed on the motherboard or labels, but we consider the real case where additional information can not be. Technically, this is achieved by connecting the computer to the victim network controlled by an attacker with a dummy DHCP-server. According to the log files obtained by DHCP-server attacker can get the network's MAC address of victim. This MAC-address is included in the network card settings controlled dummy workstation. Ideal - is a computer with a network analyzer, and Virtual Machine, in which you can easily change the MAC address. In written logs analyzer obtain real data from the responses of the real DHCP-server, and further with a dummy workstation (MAC changed as in victim) is downloaded the PXE-loader.


Only a few methods to help reduce the likelihood of breaking partially, but not fully exclude, such as:
- Setting DHCP-server so that the network settings required to run the encrypted station issued solely on the MAC-address of the requestor. This can be attributed to the mandatory action, because if this is not done, the attacker does not need virtually no tricks - just download a request from any computer - any workstation get identical setting data.
The program tftpd32, where there is the possibility of using the built-in DHCP-server, just no dedicated settings for a particular pair of MAC-IP, the only thing that there is - it is the appointment of a particular MAC static IP.
- Turning on TFTP-server (or turning on access to the bootloader) only for a certain time, ideally - at the request of the user (user authentication using any additional hardware and software solutions).
- Since TFTP-server has no built-in security, the provision of protection from unauthorized access to the software level by restricting access via firewall ("whitelist" IP, MAC) and transport layer, that is, for example, with the help of managed switches to provide access to the port connected to the TFTP-server, only to the ports, which are connected to the encrypted workstations. Disadvantage - need expensive additional equipment and software, and increasing the likelihood of abduction key encrypted with the number of workstations. Again, the situation is not excluded that the use is dedicated to the workstation port by attacker.

In any of the options, the result will be the same clear: Booting encrypted workstation on the network with ONLY authentication key file - it does not secure.

Simply adding authentication keys and PASSWORDS negates the above steps, in any case seriously hamper or compromise a delay.

Automatic authentication without human intervention is doomed to failure and compromise. Conversely, the introduction of human control difficult to access.

The attached files have archive with everything related to the text - the boot files, keyfiles, the network recorded session and illustration.


  • Sr. Member
  • ****
  • Posts: 418
Re: Compromising network DiskCryptor PXE-bootloader (the encryption key).
« Reply #1 on: December 11, 2015, 01:08:48 pm »
Pictures - continuing


  • Sr. Member
  • ****
  • Posts: 418
Re: Compromising network DiskCryptor PXE-bootloader (the encryption key).
« Reply #2 on: December 11, 2015, 01:10:28 pm »
Pictures - ending.