[Emerging-Sigs] kazakaza.php trojan communications

Eoin Miller eoin.miller at trojanedbinaries.com
Wed Oct 13 20:22:35 EDT 2010


  On 10/13/2010 11:22 PM, waldo kitty wrote:
> On 10/12/2010 19:17, Matthew Jonkman wrote:
>> Ok, going with this:
>>
>> alert tcp $HOME_NET any ->   $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN ZeuS http client library detected"; content:"GET "; depth:4; content:"Accept|3a| */*|0D 0A|Connection|3a| Close|0d 0a|User-Agent|3a| "; classtype:trojan-activity; sid:2011811; rev:1;)
>>
>> If we do http_header as I understand the 0d 0a's will be normalized out.
> that's one of the things that i'm kinda curious about how we should handle them
> now... IIUC, snort is doing part of the work for us now?? how can it tell, for
> instance, if there's a space after the colon in the UA string or not like the
> recent rule that has been submitted?
>
I am pretty sure they aren't normalized out as I have lots of sigs we 
run (and submit here) that trigger just fine. You can't use the rawbytes 
modifier (which lets you look at raw packet data instead of anything 
that has been mucked around with by a preprocessor) on http_header, 
http_uri, http_* etc because those buffers are created out of the raw 
packet data and there isn't a method to backtrack to the raw stuff. 
However you can still search for straight up hex strings using things like:
content:"|0d 0a|foo"; http_header;

but you shouldnt be able to do:
content:"|0d 0a|foo"; rawbytes; http_header;

Or at least that is what I gather.

-- Eoin


More information about the Emerging-sigs mailing list