[Snort-sigs] Request assistance regarding VRT sig 1:27962 (MALWARE-CNC Win.Trojan.Storm botnet connection reset)

nicenate at ...3844... nicenate at ...3844...
Sat Oct 5 21:41:08 EDT 2013

 Reply By Nicenate:

Thanks for your attention wkitty42,
The URL you mentioned is the only reference I found that mentioned current hardware actually rsponding with that phrase in the 'reply cause' of the a RST ACK packet.

"The root of that cryptic response seems to be how the AT&T UVerse 2Wire gateway responds to traffic it drops."

So the author of this blog post feels that the AT&T UVerse 2Wire gateway responds this way.

Our machines are sending a syn packet to a internet address, often to a what looks like users of FiOS, AT&T, or Comcast as ISPs from the reverse lookup of the destination IPs.  The src port is in the 30,000-35,00 range and the dst port is usually in the 50,000+ range.  A SYN out and a RST ACK back with this phrase.

So far we have not seen what or even if there is a DNS query for an A record.  In these cases the reverse lookup name is usually not the dns A record used if in fact a dns lookup was made.

SO, the only current hardware that I have found a reference to, from the URL you mentioned, that may be sending these phrases when resetting s connection is this AT&T UVerse 2Wire gateway.  Anyone else have experience with hardware acting like this in current times???

Thanks ALL and wkitty42!!


On 10/05/13, wkitty42 at ...3507... wrote:

On Friday, October 4, 2013 10:27 PM, nicenate at ...3844... wrote: 
> So far, I think the most likely cause seems to be that some machines -for some 
> unknown reason- are trying to make connections to IPs running a cable-modem 
> router-nat-box which when replies with this response in the Rset ACK packet. Of 
> course there are two obvious questions, one bing why is one of our machines 
> trying to make the TCP connection at all; and secondly, what device is set to 
> send tcp reset-acks with this phrase as the reset cause. 

on why machines may be attempting these connections, did you happen to see and read this item linked to 3rd or 4th in the google search for the given search terms?


the short of it is that they found old registry entries for mapped printers and the OS was attempting to connect to them as directed... i can see this happening with any mapped objects... not just printers but also drives and anything else that can be mapped over the network...

the results of seeing this response allows one to be alerted to why there may be random traffic on their network and for them to determine what that traffic is and stop it...

as for devices that respond in this manner, i don't know of any list but i'm just a little fish ;)

VRT will have to answer for themselves, if they deign to do so, as to why they recently included this rule...

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
Snort-sigs mailing list
Snort-sigs at lists.sourceforge.net

Please visit http://blog.snort.org for the latest news about Snort!

More information about the Snort-sigs mailing list