[Emerging-Sigs] [Rule Update Proposal] "ET CURRENT_EVENTS Ghost Click DNSChanger DNS Request (UDP)" [2013906]

Christopher Granger chrisgrangerx at gmail.com
Mon Feb 27 23:28:19 EST 2012


Correction:

alert udp !$DNS_SERVERS any -> [
85.255.112.0/20,67.210.0.0/20,93.188.160.0/21,77.67.83.0/24,213.109.64.0/20,64.28.176.0/20]
53 (msg:"ET CURRENT_EVENTS Ghost Click DNSChanger DNS Request (UDP)";
threshold:type threshold, track by_src, seconds 2, count 2; reference:url,
www.fbi.gov/news/stories/2011/november/malware_110911/DNS-changer-malware.pdf;
classtype:trojan-activity; sid:2013906; rev:2;)

Thanks again,
-Chris

On Mon, Feb 27, 2012 at 11:17 PM, Christopher Granger <
chrisgrangerx at gmail.com> wrote:

> I have a better idea since that content match could be pretty costly in
> some environments -- this should detect timed-out retry queries (one to the
> primary and secondary server at about the same time), expected post-Mar-8,
> and cover cases where infected clients can now query and receive replies
> from the ISC name servers:
>
> alert udp !$DNS_SERVERS any -> [
> 85.255.112.0/20,67.210.0.0/20,93.188.160.0/21,77.67.83.0/24,213.109.64.0/20,64.28.176.0/20]
> 53 (msg:"ET CURRENT_EVENTS Ghost Click DNSChanger DNS Request (UDP)";
> threshold:type limit, track by_src, seconds 2, count 2; reference:url,
> www.fbi.gov/news/stories/2011/november/malware_110911/DNS-changer-malware.pdf;
> classtype:trojan-activity; sid:2013906; rev:2;)
>
> Thanks,
> -Chris
>
>
> On Mon, Feb 27, 2012 at 10:18 PM, Christopher Granger <
> chrisgrangerx at gmail.com> wrote:
>
>> Hi Everyone,
>>
>> The theshold setting will shortly be too high to detect infections,
>> barring an extension to the March 8, 2012 planned take down date of the ISC
>> maintained name servers:
>> http://www.infosecisland.com/blogview/20509-DNSChanger-March-8th-and-You.html
>>
>>
>> Actually, because the malware sets both primary and secondary "rogue" DNS
>> server IPs for infected machines to use, adding a condition that 2 distinct
>> IPs within the ranges of interest be queried, post-March 8th -- maybe using
>> flowbits rules(?) -- would be a way to bolster this detection, since
>> infected machines will persistently requery two IPs within these ranges
>> once the servers go offline, although at a much lower rate than the
>> threshold logic in the rule reflects.
>>
>> For now, however, this detection is ineffective except in cases where
>> infections can unfetteredly query the ISC name servers and/or other
>> legitimate (i.e. not formerly "rogue") DNS servers within these IP ranges,
>> and do so fairly rapidly. On the other hand, in the case of most infected
>> Windows machines for which egress DNS is filtered, for example, retried
>> queries are sent to two of the ISC name servers w/in the suspect IP space
>> at a rate of about one to each IP, every two minutes.  I assume this
>> default rate is within the ball park of values used by other affected
>> platforms.
>>
>> Regarding the !$DNS_SERVER var and the reliability of the detection, this
>> should be unnecessary and the reliability boosted, by restoring the content
>> match (or a portion thereof), to establish that the traffic is a standard
>> query, and in particular, that the Recursion Desired flag is set:
>>
>> content:"01 00 00 01 00 00 00 00 00 00"; offset:2;depth:10;
>>
>> The only FPs that could arise in the case of a RD flag check, would be
>> from either frighteningly misconfigured internal DNS servers (which would
>> be worth FPing to discover) or in cases where trusted DNS servers used by
>> clients within the monitored network to make recursive queries, happen to
>> have IP addresses within the suspect ranges captured in the IP logic of the
>> rule.
>>
>> Thanks -
>>
>> Best regards,
>> -Chris
>>
>> On Sun, Jan 1, 2012 at 6:27 PM, Martin Holste <mcholste at gmail.com> wrote:
>>
>>> That would definitely help.
>>>
>>>
>>> On Sunday, January 1, 2012, Matt Jonkman <jonkman at emergingthreatspro.com>
>>> wrote:
>>> > These are wide swaths of IP space, so you will likely hit good things
>>> there.
>>> >
>>> > Perhaps we need to go !$DNS_SERVERS in there so we just catch clients,
>>> > not servers....
>>> >
>>> > Matt
>>> >
>>> > On 1/1/12 3:02 PM, Russell Fulton wrote:
>>> >> HI Folks!
>>> >>
>>> >> All our local DNS servers are querying these suspect servers --
>>> presumably there are legit domains hosted on them or should I be worried.
>>> >>
>>> >> Russell
>>> >> _______________________________________________
>>> >> Emerging-sigs mailing list
>>> >> Emerging-sigs at emergingthreats.net
>>> >> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>> >>
>>> >> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>> http://www.emergingthreatspro.com
>>> >> The ONLY place to get complete premium rulesets for Snort 2.4.0
>>> through Current!
>>> >
>>> > --
>>> >
>>> > ----------------------------------------------------
>>> > Matt Jonkman
>>> > Emerging Threats Pro
>>> > Open Information Security Foundation (OISF)
>>> > Phone 866-504-2523 x110
>>> > http://www.emergingthreatspro.com
>>> > http://www.openinfosecfoundation.org
>>> > ----------------------------------------------------
>>> >
>>> > _______________________________________________
>>> > Emerging-sigs mailing list
>>> > Emerging-sigs at emergingthreats.net
>>> > http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>> >
>>> > Support Emerging Threats! Subscribe to Emerging Threats Pro
>>> http://www.emergingthreatspro.com
>>> > The ONLY place to get complete premium rulesets for Snort 2.4.0
>>> through Current!
>>> >
>>>
>>> _______________________________________________
>>> Emerging-sigs mailing list
>>> Emerging-sigs at emergingthreats.net
>>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>>
>>> Support Emerging Threats! Subscribe to Emerging Threats Pro
>>> http://www.emergingthreatspro.com
>>> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
>>> Current!
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20120227/9b256807/attachment.html


More information about the Emerging-sigs mailing list