[Snort-sigs] Snort Rule 40755 and Shockwave Flash detection

Al Lewis (allewi) allewi at ...3865...
Wed Jan 11 20:17:34 EST 2017


If possible it would help if you shared the packet information. It will be hard to tell if this is a false positive or not without it.


Albert Lewis
SOURCEfire, Inc. now part of Cisco
Email: allewi at ...3865...<mailto:allewi at ...3865...>

From: "Jonathan A. Yee" <jyee at ...4215...<mailto:jyee at ...4215...>>
Date: Wednesday, January 11, 2017 at 7:44 PM
To: "snort-sigs at lists.sourceforge.net<mailto:snort-sigs at lists.sourceforge.net>" <snort-sigs at lists.sourceforge.net<mailto:snort-sigs at lists.sourceforge.net>>
Subject: [Snort-sigs] Snort Rule 40755 and Shockwave Flash detection

Hi all,

Apologies of this is posted to the incorrect mailing list.

One of our SourceFire boxes has been getting many alerts in relation to SID 40755 "FILE-FLASH Adobe Flash EnableDebugger2 obfuscation attempt" on seemingly innocuous Shockwave Flash sites.  The entire rule is:

alert tcp $EXTERNAL_NET $FILE_DATA_PORTS -> $HOME_NET any (msg:"FILE-FLASH Adobe Flash EnableDebugger2 obfuscation attempt"; flow:to_client,established; file_data; content:"FWS"; depth:3; content:"|1F 10 75 19 24 31 24|"; content:"|00|"; within:1; distance:25; metadata:policy balanced-ips drop, policy security-ips drop, service ftp-data, service http, service imap, service pop3; reference:url,www.virustotal.com/en/file/1613acd34bfb85121bef0cd7a5cc572967912f9f674eefd7175f42ad2099e3d1/analysis/<http://www.virustotal.com/en/file/1613acd34bfb85121bef0cd7a5cc572967912f9f674eefd7175f42ad2099e3d1/analysis/>; classtype:attempted-user; sid:40755; rev:1; )
After examining the packet information, I can't seem to find a single occurrence of either the string or binary data within any of the frames.  However, the rule does seem to be triggering at seemingly random intervals.  I've tried going to the specific URIs and have not been able to forcibly trigger the rule.  I've checked the hash of each SWF file it's triggering on and not a single one matches the reference found in VT.  This leads me to believe that the rules is too broadly written and is causing false positives.

I was wondering if anyone had seen something similar or might have some insight for why this rule might be triggering on different SWF files.

Thanks in advance.

Jonathan (Jay) Yee
New Professional
Network Monitoring Team at SSCPAC
RDT&E Network Security, Code 82900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20170112/70811a79/attachment.html>

More information about the Snort-sigs mailing list