[Emerging-Sigs] kazakaza.php trojan communications
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.
More information about the Emerging-sigs