I genuinely looked for an answer to this but my terminology is lacking. If an attacker was in a MiTM position running a proxy, wouldn't it be possible for them to detect a binary like an .exe or .pdf and either implant some malicious instructions or completely swap the file with something evil?

To clarify: Do you know of any software, paper or talk regarding this.


4 Answers 4


Yes. It can be done. I've done it personally with python, using a script that I wrote called the-backdoor-factory and implementing a proxy in python. Once you have the the patching system in place almost any proxy will work. You will just need to look for the application/octet-stream in the html, retrieve the binary, patch it, and forward to the client. I'll post a full write up online once I have stable program for community testing.

So here a video of the POC that I'm working on: http://www.youtube.com/watch?v=qPCy2IDaEOI

What you are seeing in the video is my POC on the left written in python and the 'victim' on the right browsing through the proxy. The proxy looks for binaries and only intercepts PE/COFF at the moment. After the binary is patched, it forwards the binary to the user, as you can tell, it's really fast.


Yes they would. I'd say injecting malicious code into a .exe or a .pdf would be difficult without damaging the file integrity to the point it breaks the file, more likely an outright replacement would be smarter, but it would need to have a similar file size or might arouse suspicion. As the target is expecting a file suspicions would be low.

  • Instead of injecting malicious code, you could just wrap the original binary. And if the proxy also tampers with the preceding communication then changing the file size would be tranparent to the user.
    – Perseids
    Commented Sep 10, 2012 at 19:40
  • Absolutely true, although it would be difficult to write software that would be able to interpret a web page and determine where to tamper with file sizes.
    – GdD
    Commented Sep 11, 2012 at 8:51
  • I'm considering building a proof of concept, do you know if this has been done? Commented Sep 11, 2012 at 12:31
  • If you are referring to a proxy that replaces files with malicious ones then not as far as I know. I'm sure someone has done something like that for research or financial gain, but I doubt if they'd share any code.
    – GdD
    Commented Sep 11, 2012 at 12:43
  • There are easy mechanisms to alter an exe on the wire to do malicious things. (Such as hyjacking a return operation and injecting additional code at the end of the file with a jump in the code.) A PDF would be trickier as it is something normally read rather than executed. Commented Sep 11, 2012 at 17:41

In general, you can't trust anything on an unsecured connection on any network where a MITM could be present (ie, you don't have complete physical control and security of the routing and wiring). A Man in the Middle could monitor and alter any unsecured connection by pretending to be you to the host and pretending to be the host to you. Neither system would be aware of the presence. The file could be entirely replaced or executable could be altered or replaced to do malicious things quite easily.

There are, however, a number of ways to prevent this. Authenticated connections such as HTTPS guarantee that only two end points (at least one of which is trusted) can communicate. In brief, HTTPS works by the server having a special piece of information that the browser can validate is the server you think it is. That information can then be used to send a key generated by your client to the trusted server in a way that only the server can understand. Because the MitM doesn't know the newly shared key, the server can then respond using that key to encrypt the connection and the MitM can no longer observe or alter the meaningful contents of that communication and any alterations would cause it to appear as gibberish (or possibly be detected based on the protocol in use).

Another technique is called checksums. A checksum is a small piece of information that can be independently provided to validate a much larger file. It generally consists of a hash of the file that is being sent which can then be rehashed after receipt in order to ensure the file didn't have any errors in transmission. If the checksum and the file are obtained from different connections, it is a little more difficult for the MitM to alter both, however it could still be possible for both to be altered. The checksum could also be cryptographically signed by the file distributor to ensure the checksum can not be altered by the MitM.

The best method is to combine the two approaches and include a cryptographically signed checksum that validates that the file came from the sender while also communicating the file over a secure connection. This ensures that the data isn't corrupted during transmission and also ensures that it comes from the expected host.


Man in the middle can do pretty much anything with data that passes through. The only defense is use of key/signatures that didn't pass through attacker - for example was delivered before injection or by another medium. Of course you should remember that keys could be compromised at some point in future too.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .