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

nicenate at ...3844... nicenate at ...3844...
Fri Oct 4 23:37:06 EDT 2013

 Nathan replies:

You are correct that we have used enable|disablesid.conf with Pulledpork to enable manually most of these Malware-CNC rules.

If these rules fire we investigate why and then consider disabling rules if they seem like false positives or are too noisy for routine analysis and monitoring.
In the case of this rule we just have not seen any current discussion for this rule.  We are asking here if anyone knows more about why this rule has been placed back into the VRT snort rule set.

Also is anyone else using this rule and seeing it alert and knows why?

It has us baffled  so far...

Again thanks James.


On 10/04/13, James Lay wrote:

And FYI this is commented out in my rulesets�which I've not monkeyed with at all (either by hand or with PP). I'd take a peek at your pulled pork *sid.conf files.


On Oct 4, 2013, at 8:27 PM, nicenate at ...3844... wrote:

> On 10/04/13, James Lay wrote:
> On Oct 4, 2013, at 6:21 PM, "Mathewson, Nathan" <Mathewson at ...3842...> wrote:
> We have most of the Malware-CNC rules enabled and we installed the VRT rule update from 9-24-2013. We are now seeing alerts form this sig 1:27962. We see user machines sending from one to three TCP SYN packets out and receiving back RST/ACK packets with a reset cause ?Go away, we?re not home?, exactly as the rule requires. 
> This appears to be a ?new? snort vrt rule in this rule set yet it only references sources from 2008.
> We have not been able to find explanations for why one receives these unique RST/ACK packets. 
> Can anyone assist us with information regarding this sig, why this rule was seemingly just added, it?s current status, and what might be the cause[s] for these resets with this unique ?reset cause?.
> Attached file is a sample SYN ? RST/ACK, in pcap format.
> Appreciate your assistance.
> Nathan
> Take your pick on one of these:
> https://duckduckgo.com/?q=RST+ACK+%22Go+away+we%27re+not+home%22
> Interesting reading.
> James
> Thanks James.
> Am a big fan of duckduckgo and we also googled, a lot. Seen all of these... as this was one of our first searches.
> 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. 
> Anyone know of devices set to issue resets in this manner, i.e. with this reset cause phrase? 
> Anyone have an idea why the Snort VRT group decided to add this seemingly 'old rule' as a new rule in the 24 Sept rule set release? Was the VRT group aware of some 'new threat' out there acting like the old Storm C-and-C machines?
> Thanks, Nathan

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