[Snort-sigs] Weevely PHP Backdoor - Rule Proposal

Anestis Bechtsoudis bechtsoudis.a at ...2420...
Sun Nov 20 17:53:30 EST 2011

Thanks for the feedback.

I wasn't familiar with the http_header modifier at all.

You proposed some additions to the content strings based on the fact
that the composed refer urls are the weevely defaults following the
official format. What about the case that they aren't (minor string
changes to the value names bypass the rule) ?

Is there any google referer url validator rule?

Thanks for the feedback.

A. Bechtsoudis

On 11/21/2011 12:08 AM, Martin Holste wrote:
> Interesting stuff, nice write-up on the blog.  On the rules:
> Limit the content to just the HTTP header by adding the "http_header"
> modifier after the content match.
> Don't use nocase, as base64 encoding is case-sensitive, so we want
> exact matches.
> Add on the restriction that we must have "&ei=" as a URI param to
> anchor the match.
> Add on the restriction that Google must be in the header, but make
> sure we don't match on that first because it will be so common.  We do
> this by adding fast_pattern to the more unique match.
> So you end up with a rule like this:
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"Weevely
> PHP backdoor detected (system() function used)";
> flow:to_server,established; content:"&ei=QHN5c3Rl"; http_header;
> fast_pattern; content:"http://www.google.com/url?sa="; http_header;
> reference:url,bechtsoudis.com/security/put-weevely-on-the-your-nids-radar;
> classtype:web-application-activity; sid:100001; rev:1;)
> That kit definitely has a subtle backdoor, so these are good rules to
> have--nice work!
> On Sun, Nov 20, 2011 at 3:19 PM, Anestis Bechtsoudis
> <bechtsoudis.a at ...2420...> wrote:
>> I work in the NOC team at a University Campus in Greece, and recently i
>> have noticed a noticeable increase in web hacking incidents. In many of
>> them the attackers used the weevely*1 php backdoor to maintain access to
>> the hacked system.
>> I have searched around the net for some relative snort rules but i
>> didn't find a match. So i decided to write my own. I thought these rules
>> might pose an interest to the community so i decided to share them in
>> this list (see the attachment).
>> A detailed analysis of how i concluded to these content patterns can be
>> found in my blog post*2.
>> I admit that i'm not a Snort expert, so any propositions are welcome.
>> *1 http://code.google.com/p/weevely/
>> *2 http://bechtsoudis.com/security/put-weevely-on-the-your-nids-radar/
>> --
>> ===============================================
>> * Anestis Bechtsoudis                         *
>> * Undergraduate Student                       *
>> *                                             *
>> * Network Operation Center (NOC Group)        *
>> * Dept. of Computer Engineering & Informatics *
>> * University of Patras, Greece                *
>> *                                             *
>> * Website: https://bechtsoudis.com            *
>> ===============================================
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Snort-sigs mailing list
>> Snort-sigs at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>> http://www.snort.org
>> Please visit http://blog.snort.org for the latest news about Snort!

More information about the Snort-sigs mailing list