Hi, I've checked the attack type from this packet (721619.pcap) and now I'm impossible to identify this attack or behavior. Help me to understand. Cloudshark link ( https://www.cloudshark.org/captures/50e23e13bb31 ). ip.src == 172.17.107.32 && ip.dst == 25.4.5.116 Can anybody clarify me the attack type and way of identifying simply ? I have no idea on this
asked 09 Feb '16, 12:39  Bhagya |
One Answer:
A display filter answered 09 Feb '16, 13:32  sindy showing 5 of 6 show 1 more comments |
So this could be a spam mail ?
Can you explain what is called here as "Spurious re-transmission" ?
Those packet doesn't shown details in Follow TCP stream. But Statistics>Conversations>IPv4 show Bytes are delivered from B -> A. So which could be taken from here.
The key here is the context. As the whole capture is full of SMTP transmission attempts, mostly rejected with reference to spamming databases, and as the SYN packet is sent towards TCP port 25 which is the standard port on which a SMTP service listens, you can reasonably assume that the SYN was an attempt to send an email using SMTP. Whether it would have been spam or not is another issue and you can only suppose here.
As for explanation of what Wireshark means by a "spurious retransmission", @Jasper has written a nice article explaining the topic - in your case, the 172...32 sends a SYN from the same source port to the same destination socket although it has already received a response to it before (the RST, ACK packet from the 25...116).
Why the 172...32 behaves like this is something what Wireshark cannot tell you. Wireshark always only shows you what has happened.
I got cleared. First would like to thanks for kind response. It's great help for me.
So, this is transferred to both sides but 25.4.5.116 is not sent SYN-ACK packets. But RST, ACK is showing that connection Reset (terminated) and again 172..32 has sent same packet (Spurious re-transmission). Right ?
So this could be a spam attempt to enter to mail server ?
or another party is getting attempt to handle the mail server as d-Dos attack ?
what is called from tcp.stream == 507 ?
Wireshark's tcp dissector numbers the individual tcp sessions (streams) as it finds their first packets in the capture. So tcp.stream == 507 shows all packets of the 507th tcp session which the dissector has found.
Again: this can only be guessed in the context of the rest of the capture. Without the context, it may be:
an attempt of 172...32 to send (forward) a "legal" e-mail message to/via 25...116, which has failed because the destination server has a temporary problem or wrong configuration or has the public IP behind which the 172...32 is hidden on a blacklist
an attempt of 172...32 to send (forward) a spam e-mail message to/via 25...116, which has failed because the destination server has a temporary problem or wrong configuration or has the public IP behind which the 172...32 is hidden on a blacklist
an attempt to DDoS the 25...116
When taking the context into account, the most likely case becomes the second one. The capture shows many messages to be sent to different SMTP servers, which is very suspicious unless the 172...32 is a SMTP server itself (see my response to your other question regarding the same capture); if it would be a DDoS attempt, I would expect to see much more than just three SYN attempts towards the 25...16 during the 1'45" of the capture.
I'll try to reword what you wrote: the capture shows traffic going in both directions but 25.4.5.116 does not accept the connection by responding the SYN with SYN-ACK. Instead, it rejects the connection by responding with a RST, ACK packet. Due to the fact that there was the response, the Wireshark tcp dissector analyzes the next transmission of the SYN packet from the same source socket to the same destination socket with the same absolute sequence number as a spurious retransmission; if there would have been no response, the dissector would have marked the retransmission of the SYN as a plain, not spurious, one.
Thanks a lot. It's marvelous answer for me and good fit to the question.
Anyway I was in analyzing these today and finally it was easy to understand that spam emails sending attempt was taken and but it wasn't succeeded due to the server rejections.
According to response reset packets have sent and connection terminated. So could not be established connection and 3 attempts were useless. Briefly I think it could be the scenario here ?
Briefly - yes.