[Emerging-Sigs] Strange UDP Trojan check-in

Martin Holste mcholste at gmail.com
Tue Oct 4 16:38:39 EDT 2011

I sat down and finally got familiar with all of the byte_* operators,
and I think this one will work the best (confirmed against pcap):

alert udp $HOME_NET any -> $EXTERNAL_NET !53 (msg:"ET TROJAN ZeuS P2P
Communication"; byte_extract:4,63,padding; byte_test:4,=,padding,67;
dsize:72; sid:1; rev:1;)

This checks that the UDP payload is exactly 72 bytes and that the
bytes 63-66 match bytes 67-71 (eight bytes in a row that are
identical).  It should be pretty accurate and very fast.  I put in the
not DNS port there since only high ports are used and this should make
the load essentially non-existent.  That should also alleviate FP's,
though I doubt there will be many if any.

On Tue, Oct 4, 2011 at 3:13 PM, Nathan <nathan at packetmail.net> wrote:
> On Tue, 4 Oct 2011 13:20:17 -0500 Martin Holste <mcholste at gmail.com> wrote
>> Does anyone have some advice on a signature for the UDP last nine bytes?
> Here is my attempt, caveat, it may not even run, I'm shooting from the hip for
> discussion.  The PCRE back reference should be good to match the last 9 bytes
> repeating, until end of string.  I feel good about the PCRE.
> The dsize and byte_jump are suspect, dsize should be ok it's byte_jump and
> doe_ptr with respect to PCRE /R that I'm unsure about.
> Do we need to adjust dsize for UDP header size?
> Does doe_ptr become relative to PCRE /R?  If not, we need to drop it.
> Do we also need the /O flag for PCRE?
> I believe /B is needed as is /s but I am open to correction.
> #Does 1023: here make sense?
> alert udp $HOME_NET 1023: -> $EXTERNAL_NET 1023: (msg:"ET CURRENT_EVENTS ZeuS
> P2P Communication over UDP"; dize:114; byte_jump:1,70; pcre:"/(.)\1{8}$/BRs";
> classtype:trojan-activity; sid:x; rev:1;)
> PCRE version 8.02 2010-03-19
>  re> /(.)\1{8}$/
> data> abcdefghi
> No match
> data> aaaaaaaaa
>  0: aaaaaaaaa
>  1: a
> data> aaabbaaaa
> No match
> data> hoorayaaaaaaaaa
>  0: aaaaaaaaa
>  1: a
> data>
> Thanks,
> Nathan

More information about the Emerging-sigs mailing list