In a situation, where the spoofed IP is a real existing remote IP and it is found that the TCP 3-way handshake has been made with a server.

The MiTM machine sends the packet with spoofed IP to the server. Does the real IP acknowledge the ACK sent back from the server to real IP and receive the response packet from the server followed by the acknowledgement?

EDIT: As the brief above was not clear, here I try to be as descriptive as possible.

Client A with real IP has connected with server S completing the TCP 3-way handshake and transferring data packets like a regular connection. Now, the attacker machine M sends a packet spoofing the IP address of A and once this packet is received by the server, it sends back the ACK flag/field to A. Please correct me if I am wrong with this part of ACK flag/field here.

Now my questions here are:

  1. Will the ACK flag/field from server S be accepted by A?
  2. The packet sent by M with spoofed IP of A gets a response from S to A. Will this response be accepted by A?
  • Your question is currently unclear. Please edit the question to better outline. Perhaps a 1.2.3. sequence of packets sent, clearly indicating the destination and recipient, so you can tell us which step in the sequence you have a question about. Commented Oct 11, 2016 at 14:06
  • I hope this edit now is more clear. Not sure why someone gives a downvote if they can't understand the question while some others can.
    – WCO
    Commented Oct 12, 2016 at 13:48
  • Thanks, this is much easier to understand. I'm expert enough to answer. However, your question was was very difficult to follow. (before the edit) I don't want to answer incorrectly because of misunderstanding. Ideally you want a clear question so more people, not just some will understand easily. Commented Oct 12, 2016 at 14:01

3 Answers 3


First of all, every TCP packet has a sequential identifier, which starts at a random position. (explained briefly in this discussion) So if the attacker is spoofing (non-SYN) packets (trying to hijack an existing connection), then all of those spoofed packets will be ignored or refused (depending on the type of packet) because they will be out of sequence.

So, in order for the attack to be successful, he will have to be eavesdropping on the connection so he can find out what the sequential identifier should be.

After determining the sequence. (via Passive Eavesdropping) It is easy to get the server to accept in-sequence data.

Client A with real IP has connected ... Now, the attacker machine M sends a packet spoofing the IP address of A ... Will the ACK flag/field from server S be accepted by A?

The Acknowledgement packet will have the same sequential identifier as the Data packet sent.

The client A will not accept the Acknowledgement because the Data was sent from attacker M. (so the client is not anticipating an Acknowledgement yet)

(Unless of course this were an Active (non-passive) attack which gives the attacker more options, such as true MiTM)

However, the server will still accept the data.

Even if the client does not accept Acknowledgement of spoofed data packet, the connection will remain open. The client could even send another Data packet. The server will ignore the second Data packet because it has the same sequential identifier, but will probably repeat the Acknowledgement back to the client which would be none-the-wiser. I'm not 100% sure of this so I posted a specific question on that point just to be sure.

The packet sent by M with spoofed IP of A gets a response from S to A. Will this response be accepted by A?

Yes, The Input and Output streams will increment their sequential identifiers separately.

Using a secure connection such as TLS will detect such TCP spoofs quite easily, so that is usually the recommended solution.


The question is a bit unclear yet I will try to make some assumptions and answer something.

Let's assume that A is the attacker and R is the real IP. S is the server.

Things to remember.

  • TCP packets, be it handshakes or other packets, will have a sequence number and an acknowledgement number which will help the communicating parties in identifying the session.
  • A three way handshake happens only in the beginning of a TCP connection, not with each data packet.

So coming to your question,

  1. R has an existing connection with S
  2. A sends a SYN to S with the IP of R as source address
  3. S sends a SYN-ACK to R.
  4. Depending on the configuration R will not respond or respond with an RST as it will not be able to match the sequence and acknowledgement number of the received packet with what is expected from any of the connections which it previously initiated.

Spoofing is possible if the system produce predictable TCP sequence numbers.

  • Apologies for not being clear in my first attempt at this question.
    – WCO
    Commented Oct 12, 2016 at 13:45
  • No, A does not send a SYN to S as the connection is already formed between R and S. It just sends a packet to S with spoofed IP address of R.
    – WCO
    Commented Oct 12, 2016 at 13:46
  • @user2075687 In that case unless A is able to predict the sequence & acknowledgement number of the communication between R and S, it will not be able to send a valid TCP packet to S. This analogous to session handling in web applications. A's packet will be like an http request without a valid session cookie.
    – hax
    Commented Oct 12, 2016 at 15:32

I am not sure if I clearly understand you but in a scenario where a legal entity Le communicates with a server S using TCP, then they establish end-to-end communication.

Now if a spoofer-attacker A, uses the IP of Le and contacts S then the packet would be handled in the context of communication between Le and S. However keep in mind that TCP maintains packet ordering and this is sth that A should take into consideration before sending the packet, thus making the effort a little harder but not impossible. So maybe the answer won't be an ACK after all..

To restrict access to the TCP connection you must use authentication e.g., at the application layer.

This is a link I found interesting: TCP description

  • You understood the situation right. The link shared is surely of help. Didn't get the part where you say about authentication at the application layer. How is this a part of this situation?
    – WCO
    Commented Oct 12, 2016 at 13:42
  • It is not part of the situation as you describe it in your question, but I included as an interesting point on how to defend against your attacker
    – jedidog
    Commented Oct 12, 2016 at 14:11

You must log in to answer this question.

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