What are the top security concerns when setting up a PXE (Preboot Execution Environment) booting environment, ordered by severity of a possible exploitation?

Things that I thought of are (in no particular order):

  • Rogue DHCP takeover
  • Man-in-the-Middle attacks on the NBP load over TFTP

The question is meant to look at the general protocol and its possible weak points and is not restricted to a certain setup concerning equipment or attacker.

If anyone wants to help me bring this question in a more suited format, you are welcome.

  • Could you precise who is expected to legitimately access/manage which components of your setup, and what you expect adversaries to be capable of? Aug 8, 2014 at 4:30
  • @SteveDL I added a paragraph in the question to answer your question (hopefully).
    – RikuXan
    Aug 8, 2014 at 7:26
  • TFTP does not need a man in the middle it is trivial as in no authentication thus the first T in TFTP.
    – zedman9991
    Aug 8, 2014 at 13:16
  • @zedman9991 But wouldn't I still have to be "in the middle" to block the real TFTP's answer to prevent a race condition and secure my answer to be the client's accepted one? Also in most situation by sniffing the client's traffic to see when he requests the NBP I'm usually in the middle as far as I know. Maybe I'm not completely understanding what you mean.
    – RikuXan
    Aug 9, 2014 at 1:21
  • Sorry to not be clearer my point was the attacker does not need to hijack your TFTP session he can just initiate one himself at will.
    – zedman9991
    Aug 11, 2014 at 12:57

4 Answers 4


In a PXE environment, as a pentester, I have 2 major classes of attack I can choose from.

1: I can capture a full machine image. Do your systems automatically connect to the domain controller after setting up the machine? If so, this image probably has domain controller credentials on it, that I can capture and use elsewhere.

2: I can manipulate images on a restored machine. After capturing, I can make an image that has, say, the corporate image with AV disabled and malware pre-installed, then MITM someone's system for a persistent foothold in the company. Since PXE isn't encrypted or authenticated in any way, this is trivial to do with physical access, a few seconds of privacy, and something like a pwn plug or a raspberry pi.

  • Thank you for the answer, very cool to see someone bring real-world experience into this. Your first point is one I hadn't really thought about yet, the possibility of the supplied images containing critical data.
    – RikuXan
    Aug 13, 2014 at 6:12
  • I do have one question about point 2 though: I generally assumed MITM attacks on PXE are possible due to it being unencrypted. However, I just realized that on a switched network I don't know how one would block the broadcasts being sent to exchange them with malicious ones. So are PXE/any broadcast protocol MITM attacks always linked to race conditions? Or is there another way to ensure that the malicious answer gets preferred?
    – RikuXan
    Aug 13, 2014 at 6:18
  • @Ryan you blame PXE for an altered image in a PXE restore process when it is the restore application and no PXE the one that has to check the image's integrity. PXE is a part of the provisioning equation, we have to be very cautious and see if we talk about the "security of the provisioning equation" or the "security of PXE"; they are different things.
    – Pat
    Aug 13, 2014 at 9:23
  • 1st off: If I can get physical access in the environment, I can plug something between the computer and the switch that can manipulate traffic. Therefore, that device would just need to capture and not re-propigate broadcasts. No race condition necessary. Aug 13, 2014 at 22:00
  • @Pat I'm not blaming PXE at all for this. I'm just saying that since this environment exists, that is a place I can inject myself. These sort of attacks are usually possible with other network-based provisioning systems, as long as I can adequately spoof enough of a corporate system to allow me to download the image. Aug 13, 2014 at 22:04

The top security concern is that the only protection of traditional PXE booting is physical security. There is no encryption or authentication anywhere in the process from power-on to OS start.

The basic PXE process:

  1. Computer makes a DHCP request
  2. DHCP server responds with address and PXE parameters
  3. Computer downloads boot image using TFTP over UDP

The obvious attacks are a rogue DHCP server responding with bad data (and thus hijacking the boot process) and a rogue TFTP server blindly injecting forged packets (hijacking or corrupting the boot image).

UEFI secure boot can be used to prevent hijacking, but a rogue DHCP or TFTP server can still prevent booting by ensuring the computer receives a corrupted boot image.

  • Thank you for your answer, to translate your answer into possible attack vectors it would mean MitM-Attacks due to lack of encryption (sniffing is kind of irrelevant since PXE usually doesn't transmit critical data, but only binaries) and illegal access to the booting system due to the lack of authentication, am I seeing this correctly?
    – RikuXan
    Aug 8, 2014 at 7:34
  • @RikuXan, I've expanded my answer. Everything takes place over UDP, so "MitM" attacks are simply a matter of ensuring the attacker's packets arrive before the honest packets.
    – Mark
    Aug 8, 2014 at 8:21
  • This answer is not correct. a rogue DHCP can be detected in a manner of seconds, PXE authentication can be granted by DHCP MAC address and architecture; alarm of duplicated MAC addresses can also be easily triggered. PXE security can be easily improved just taking care of it. Today WDS/MDT/SSCM are mostly PXE based and are widely used in a corporate environment
    – Pat
    Aug 12, 2014 at 15:03
  • Unless you're actively scanning for a rogue server, the first you'll know about it is when a DHCPDISCOVER receives two DHCPOFFER packets in response. Sure, at that point you can go hunting for it, but the PXE software already has the bad response.
    – Mark
    Aug 12, 2014 at 17:53
  • @Pat I realize there are many security precautions in different PXE implementations like WDS or even gPXE/iPXE, but my question actually aims for weaknesses in the protocol rather than in specific implementations. I'm trying to get an overview on possible security problems and looking at every single implementation would only over-complicate this.
    – RikuXan
    Aug 13, 2014 at 6:11

There are some specific vulnerabilities associated with PXE boot images.

  1. Unauthenticated Images. If someone gets onto your network, it's trivial to boot a PXE image from VirtualBox or VMWare. Which means that you now have a rogue host on your network, loaded with all your proprietary software.
  2. Local Administrator exploits. (Windows only) Since this someone has physical access to the image, they can pull password hashes off of the disk image and crack them or pass them. If you have a fleet of PXE-configured images with shared credentials, you've just handed a ton of hosts over to an attacker. At the least, they have a pivot point into the rest of the network.
  3. Unattend.xml. (Windows Only) This file is an answer file that provides information Windows Deployment needs for domain joining and other setup tasks. This file can contain product keys and passwords to an account with at least domain-join privileges! And if you're really silly, that account is a domain admin.
  • Note that this only applies to Windows systems (and I'm not sure it even applies to all of them). If you were to set up a rogue host on my network, you'd find yourself running a rather generic Linux system. Access to the interesting parts of the network filesystem requires a valid user (not admin) account.
    – Mark
    Feb 16, 2016 at 20:01

The implementation of PXE in a corporate environment may raise concerns about security. This document shows why these concerns are mostly unfounded.



I'd like add that PXE is only a part of the provisioning equation then talking about the "security of the provisioning equation" and talking about the "PXE security" are different things.

PXE is not a "protocol"; it is an environment made of several protocols; PXE does not have its own boundaries that's why we must be really cautious when trying to assess PXE security.

  • 2
    I'm sorry, but I'm getting a 410 Gone error message for the page you posted, is the link broken or is this some kind of hidden paywall?
    – RikuXan
    Aug 12, 2014 at 14:58
  • no hidden paywall; just a missing character when pasting the link; please check it now.
    – Pat
    Aug 12, 2014 at 15:07
  • 1
    Thanks, it worked. Just to recapitulate and link the article with my question, the three risks mentioned are: 1. Unauthorized PXE servers allowing clients to boot unauthorized/unmanaged images; 2. Forging packets of any kind to corrupt the boot process/manipulate the images; 3. Unauthorized PXE clients booting from the system due to a lack of authorization mechanics
    – RikuXan
    Aug 12, 2014 at 16:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.