snort-sigs February 2011 archive
Main Archive Page > Month Archives  > snort-sigs archives
snort-sigs: Re: [Snort-sigs] Coverage for the "Night Dragon

Re: [Snort-sigs] Coverage for the "Night Dragon" Trojan

From: Mike Cox <mike.cox52_at_nospam>
Date: Thu Feb 10 2011 - 23:23:13 GMT
To: Matt Olney <molney@sourcefire.com>

Onley is right here about this rule breaking Snort and I was incorrect
(a.k.a. "wrong") saying this does not break Snort. Apparently someone
commented out the "include $RULE_PATH/local.rules" line in my
snort.conf on the test box so my tests never invoked the rule. Sorry
guys. I'll look at it tomorrow and hopefully provide details (if I
have time :).

-Mike Cox

On Thu, Feb 10, 2011 at 3:20 PM, Matt Olney <molney@sourcefire.com> wrote:
> For example:
> alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Night
> Dragon C&C Communication Outbound"; content:"|68 57 24 13|"; offset:12;
> depth:4; http_body; pcre:"/[\x01\x03]\x50[\x00-\xff]+\x68\x57\x24\x13/P";
> classtype:trojan-activity;
> reference:url,www.mcafee.com/us/resources/white-papers/wp-global-energy-cyberattacks-night-dragon.pdf;
> sid:2011213456;)
> kpyke@vrt-dev-01:~$ stest -Kqn /nfs/saruman/vrtbuild/pcaps/nightdragon.pcap
>
> Unexpected errors:
> ERROR: /home/kpyke/etc/./rules/local.rules(7) Unknown rule option:
> 'http_body'.
> You know where to send the check.
> On Thu, Feb 10, 2011 at 4:17 PM, Matt Olney <molney@sourcefire.com> wrote:
>>
>> Send the bill for what, exactly?
>> Let me be especially clear about something. I've been a supporter of ET
>> for a while. When I'm asked at conferences what to use, I always say to
>> evaluate both sets and pick one or both depending on your needs. I honestly
>> believe that there is a place in an operations environment for both. I do
>> not and would not trash the ET project.
>> However, it would be a solid waste of my time to troll through the ET list
>> looking for sigs. The signatures are not written with the same goals we
>> have, we have an exceptional degree of information coming in that is
>> notpubliclyavailable and we don't have to do my collaboration over an
>> email list. I can turn around and talk to five people whose duties include
>> a substantial amount of daily rule writing. I have the Snort devs within 20
>> yards of me if I need them and at this point there is an exceptionally
>> limited set of people who know more about the engine than I do.
>> I felt in this case that the level of exposure and the fact that the rule
>> that was linked to would flat out not fire obligated me to say something.
>> People depend on your sigs, like they depend on mine. This issue was high
>> profile, and I"m not going to let petty competition cause people trusting
>> that rule to not be protected.
>> Matt
>> On Thu, Feb 10, 2011 at 4:01 PM, Mike Cox <mike.cox52@gmail.com> wrote:
>>>
>>> Hmmm ... this sounds like the sig I proposed to Emerging Threats this
>>> morning but got no feedback on.
>>>
>>> Sourcefire, please let me know where to send the bill.
>>>
>>> alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN
>>> Night Dragon C&C Communication Outbound"; content:"|68 57 24 13|";
>>> offset:12; depth:4; http_body;
>>> pcre:"/[\x01\x03]\x50[\x00-\xff]+\x68\x57\x24\x13/P";
>>> classtype:trojan-activity;
>>>
>>> reference:url,www.mcafee.com/us/resources/white-papers/wp-global-energy-cyberattacks-night-dragon.pdf;
>>> sid:2011213456;)
>>>
>>> -Mike Cox
>>>
>>> On Thu, Feb 10, 2011 at 2:27 PM, Matt Olney <molney@sourcefire.com>
>>> wrote:
>>> > Hey ET folks who are here...
>>> > If you guys could pass on this information:
>>> > The rules provided won't fire onNightDragon C&C traffic.. The
>>> > offset:66
>>> > is calculated from thebeginningof the Layer 2 portion of the packet.
>>> > The
>>> > data portion (what Snort looks at) starts at offset 54. The correct
>>> > offset
>>> > for the rule should be 12. Also, you probably want to add a depth:
>>> > qualifier of 3 bytes so you don't false positive further down the
>>> > packet.
>>> > Don't normally check in on you guys, but this was important enough to
>>> > check.
>>> >
>>> > Matt
>>> > On Thu, Feb 10, 2011 at 2:47 PM, evilghost@packetmail.net
>>> > <evilghost@packetmail.net> wrote:
>>> >>
>>> >> -----BEGIN PGP SIGNED MESSAGE-----
>>> >> Hash: SHA1
>>> >>
>>> >> On 02/10/11 13:41, Joel Esler wrote:
>>> >> > Registered users will have the normal 30 day wait.
>>> >>
>>> >> Joel, I think this is ok to post here...
>>> >>
>>> >> Those who are looking for coverage who are not VRT subscribers they're
>>> >> in
>>> >> Emerging-Threats (http://www.emergingthreats.net).
>>> >>
>>> >> There's an ongoing discussion here regarding several signatures which
>>> >> have
>>> >> been
>>> >> proposed for inclusion, see
>>> >>
>>> >>
>>> >> http://lists.emergingthreats.net/pipermail/emerging-sigs/2011-February/011896.html
>>> >>
>>> >> Disclaimer - I have no vested interest in EmergingThreats, I'm just a
>>> >> simple/normal community participant there.
>>> >>
>>> >> - --
>>> >> It has been said that "hate" is a powerful emotion, perhaps that's why
>>> >> I'm
>>> >> so
>>> >> strong.
>>> >>
>>> >> - -evilghost
>>> >> -----BEGIN PGP SIGNATURE-----
>>> >> Version: GnuPG v1.4.10 (GNU/Linux)
>>> >>
>>> >> iQIcBAEBAgAGBQJNVEDOAAoJENgimYXu6xOHeXYP+wUttel/Ao8ulybFgG1iS3ar
>>> >> z1lzjvTybh5DgGVIJZ5D7QyLgsaYN4A10p6TzV5a914TuL1eEGmZLxfNjPt/et+q
>>> >> NUE8dZy3jW8M5JTgVZ1tl/aBVp798XG5h5JE57yPWdzo0gzyiOkwiZponS/HS1Lj
>>> >> sSakxNLjWRLNhCifnREW7iNY9TOmRwuGNIcfkFs0SgCqOE+ED2aR7Ko0XEPKOaMf
>>> >> ghoystILWO1uc08dDbeRDPq4BrDoBQZ3/cUDeMb/MW/BNGPdHsxlpETVEbQCg4LV
>>> >> p7NgYjJOWr6xrUxg5AKwxGkDneJrv8lj0NGT2FgywvBKevPIs32UGEaqqyY7LDX/
>>> >> JGReyADfdBd/TvGFJYgQ5jlIYsRL34517/+sfImHd19Ys4nZck6RL2+L+IINVSgG
>>> >> nozZ+fqG46mmZgCiVHwF73AzvSNCbqfU34ZbS+H19sGLVBbS0wYoGEcwKFDbax6R
>>> >> Kw7Jbw8ecYrvH1izkE0exU8K2/1LoAptfn0Gz231MMpLg/ldInqj/jzW+FCfbvXJ
>>> >> BDZMn0rqah3kXEq+mtt3tVX2bCn/ODAJ0iNtuR55goNLsrGAy6imrpzJdTasQeHg
>>> >> I2Fsz9etzLlUeyAW726AdbBONTZtYIuY2QfwyFQaIc9fLlC0KZEoycK1srQJGeY+
>>> >> 1sA7AJfGJLvnEdRHpwbi
>>> >> =3lHv
>>> >> -----END PGP SIGNATURE-----
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>>> >> XE:
>>> >> Pinpoint memory and threading errors before they happen.
>>> >> Find and fix more than 250 security defects in the development cycle.
>>> >> Locate bottlenecks in serial and parallel code that limit performance.
>>> >> http://p.sf.net/sfu/intel-dev2devfeb
>>> >> _______________________________________________
>>> >> Snort-sigs mailing list
>>> >> Snort-sigs@lists.sourceforge.net
>>> >> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>> >> http://www.snort.org
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
>>> > XE:
>>> > Pinpoint memory and threading errors before they happen.
>>> > Find and fix more than 250 security defects in the development cycle.
>>> > Locate bottlenecks in serial and parallel code that limit performance.
>>> > http://p.sf.net/sfu/intel-dev2devfeb
>>> > _______________________________________________
>>> > Snort-sigs mailing list
>>> > Snort-sigs@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>> > http://www.snort.org
>>> >
>>> >
>>
>
>

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org