[Snort-users] Payload not fitting rule content detection on snort + snorby

[Txalin]

First of all let me say hi to this mailing list as this is my first message here :) and quickly introduce myself, i'm a spaniard security freak now dealing with snort + tons of other things and tools.

Right now i am running a snort v 2.9.6.2 GRE + barnyard2 v2.1.13 build 327 + Snorby 2.6.2 with ET pro, community and several custom rules, and i have detected several times an strange behavior in snort.

When one rule has been triggered, sometimes i found that the data in the payload field doesn't match with the detecction patterns in the rule, let me show you and example:

# cat snort.rules | grep "MALWARE-TOOLS Win.Trojan.Dridex dropper message"

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"MALWARE-TOOLS Win.Trojan.Dridex dropper message"; flow:to_server,established; file_data; content:"X-mailer: Synapse - Pascal TCP/IP library by Lukas Gebauer"; fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service smtp; reference:url,www.virustotal.com/en/file/d56e7dea0e119f9a37f2cb7915c3aca0056064a8cc2bd373f2a9a8d97d548c43/analysis/; classtype:trojan-activity; sid:34945; rev:1;)

The payload shown on Snorby is:

Return-Path:.<envio.elet...@gmail.com>

.Received:.from.[1.1.1.1].by.server.mailprovider.com.id.94/98-03819-BCE0AE55;.Fri,.04.Sep.2015.21:36:11.+0000

.X-Env-Sender:.envio.eletronico.cte@gmail.com

.X-Msg-Ref:.server.mailprovider.com!1441402569!47224666!1

.X-Originating-IP:.[2.2.2.2]

.X-SpamReason:.No,.hits=0.0.required=7.0.tests=SUBJECT_EXCESS_QP

.X-StarScan-Received:

.X-StarScan-Version:.6.13.16;.banners=-,-,-

.X-VirusChecked:.Checked

.Received:.(qmail.1237.invoked.from.network);.4.Sep.2015.21:36:09.-0000

.Received:.from.mail-qk0-f172.google.com.(HELO.mail-qk0-f172.google.com).(2.2.2.2)

...by.server.mailprovider.com.with.RC4-SHA.encrypted.SMTP;.4.Sep.2015.21:36:09.-0000

.Received:.by.qkdv1.with.SMTP.id.v1so14169723qkd.0

.........for.<c...@onecompany.com>;.Fri,.04.Sep.2015.14:36:09.-0700.(PDT)

.DKIM-Signature:.v=1;.a=rsa-sha256;.c=relaxed/relaxed;

.........d=gmail.com;.s=20120113;

.........h=message-id:from:to:subject:date:mime-version:reply-to:content-type

..........:content-description;

.........bh=vVNiQkcbDuIiHCOOoLSG5c8UydaAvY8BiM5JM7lmFt8=;

.........b=MP/tJcqgJ4tn5zaVJbis3NaM34oAsBVrcWfTz+F2jlBnLNpEl2sPFQkrLXGBOFjO8a

..........ns2w6shY+ySFWRQcR2D9lYdht0TK5CTWeXxsW0I3WURt+k7BGC8kQEvTipuQmsQ68C/g

..........xDuihRZt/j/qP0rKX7tnuiboWQxbEqEVYWpoPuGJUUiBVo/BNlgMwRaeScC/Ol+k6rPT

..........lWQvdEEdPfTcsRDDaTLxsPBqbM7Flmir06+4X9gbX/m0mDTArCmogEXgYUsV7kPdo1VC

..........li

As you can see in the payload, the pattern "X-mailer: Synapse - Pascal TCP/IP library by Lukas Gebauer" is not being shown in the payload, which makes me think in two possibilities:

a) Snorby is not showing all the payload data

b) Snort is not forwarding all the data to Snorby.

Did someone here found similar behavior? Any hints about the cause of it and how to fix it? I was looking for a configuration file where i can modify the payload size but i didn't found anything yet.

Kind regards.

[Joel Esler (jesler)]

The "file_data;" keyword in the rule tells me that the rule is looking for that content in the attachment to the email itself.  

--

Joel Esler 

Manager, Threat Intelligence and Open Source

Talos Group

Sent from my iPhone

------------------------------------------------------------------------------

_______________________________________________
Snort-users mailing list
Snort...@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!

[Al Lewis (allewi)]

Since this is mail traffic my guess is that the data is base64 endcoded so snort is decoding the packet THEN alerting. Do you have a pcap of the traffic you can share?

 

If not…. test it on opensource alone vs what you see in snortby.

 

That should tell you if snortby is not showing the data (your point # 1) or if snort is not capturing/forwarding the data (your point #2).

 

As a side note.. upgrade to 2.9.7… 2.9.6 has been gone for some time… ;-)

 

Cheers!

 

Albert Lewis

QA Software Engineer

SOURCEfire, Inc. now part of Cisco

9780 Patuxent Woods Drive
Columbia, MD 21046 

Phone: (office) 443.430.7112

Email: all...@cisco.com 

[waldo kitty]

On 09/07/2015 03:45 AM, Txalin wrote:
> # cat snort.rules | grep "MALWARE-TOOLS Win.Trojan.Dridex dropper message"
> alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"MALWARE-TOOLS
> Win.Trojan.Dridex dropper message"; flow:to_server,established; file_data;
> content:"X-mailer: Synapse - Pascal TCP/IP library by Lukas Gebauer";
> fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy
> security-ips drop, service smtp;
> reference:url,www.virustotal.com/en/file/d56e7dea0e119f9a37f2cb7915c3aca0056064a8cc2bd373f2a9a8d97d548c43/analysis/

> <http://www.virustotal.com/en/file/d56e7dea0e119f9a37f2cb7915c3aca0056064a8cc2bd373f2a9a8d97d548c43/analysis/>;

> classtype:trojan-activity; sid:34945; rev:1;)

while i cannot help with your problem, i do want to point out that the content
stream that rule is using is an extremely poor choice to be using for detection
of dridex or any other malware... that string is the default value for the
X-Mailer field in that popular free open source PASCAL code library... i use the
very same library here in my own projects... the library, itself, has nothing to
do with malware of any type... the coder(s) of the malware in question simply
have not placed a proper name for the mailer in their project... that or they
are rotating valid strings like is seen with user agent strings...

[sarcasm] i'm sure that lucas gebauer will be overjoyed to see his name abused
like that... [/sarcasm]

--
NOTE: No off-list assistance is given without prior approval.
*Please keep mailing list traffic on the list* unless
private contact is specifically requested and granted.