ET Policy PE EXE or DLL Windows file download whitelisting question...

[Ian]

I've been trying to figure out how best to deal with the false positives that always show up when there are updates from Microsoft.

The rule is simple enough -- just search for the PE header:

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET POLICY PE EXE or DLL Windows file download"; flow:established,to_client; content:"MZ"; byte_jump:4,58,relative,little; content:"PE|00 00|"; distance:-64; within:4; flowbits:set,ET.http.binary; reference:url,doc.emergingthreats.net/bin/view/Main/2000419; classtype:policy-violation; sid:2000419; rev:22;)

What I'd like to do however is exempt something like "Host: au.download.windowsupdate.com" and I'd normally do that by modifying the rule in modifysid.conf, however, when this rule triggers, the captured packet doesn't have that host line -- that host line happens in an earlier separate packet.

Is there a way to reference that host line from a previous packet? Otherwise, how do you guys work around this type of false positive issue?

[Doug Burks]

Hi Ian,

Technically, this isn't a false positive, it's just a "less interesting" EXE :)

One option here is to disable/suppress this alert altogether and
instead rely on Bro's EXE detection and then use ELSA to stack the
relevant Bro logs looking for interesting sites. That's why we
provide by default an ELSA query called "HTTP - Top Sites Hosting
EXEs" because windowsupdate.com, java.com, adobe.com and other
"expected" download sites are going to bubble to the top of the
groupby allowing you to look towards the bottom of the list and find
the more suspicious sites. If you want to look beyond just HTTP
traffic, you can go to "Files - Top MIME Types", then click
"application/x-dosexec", then groupby source, and then drill into the
non-HTTP protocols.

> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.



--
Doug Burks

[Jon Mark Allen]

Ian,

I wrote a script to help me with this issue. It doesn't suppress the alerts, but it does help me triage them quickly. It also includes other SIDs alerting on similar activities.

https://geekcabi.net/article/security-onion-validate-exe-download-alerts/

Assuming I'm satisfied with the results, I can then go back into Squert and acknowledge any of the associated alerts.

The script does cheat a bit, since it's doing SQL queries in combination with grep'ing the Bro logs. We don't use ELSA, but once ELK is integrated into the Onion, I'm guessing I won't need this anymore, but for now it's worked for me. :-)

HTH,

JM

[Ian]

On Friday, June 23, 2017 at 6:01:59 PM UTC-7, Doug Burks wrote:
> Hi Ian,
>
> Technically, this isn't a false positive, it's just a "less interesting" EXE :)

Doesn't squert classify a match of this rule as malicious?

Has anyone messed with the flow/stream following that Suricata is supposed to do? I was wondering it is possible to create an additional rule where I can regex for hosts that are reasonably safe and somehow set a flag or variable. Then modify rules like "ET Policy PE EXE or DLL Windows file download" to check for that flag.

[Ian]

Jon,

I'll take a look at the script, thanks for that, but I'm looking to see if I can solve this in "real-time" if possible.

I did have a question about your grep line that matches for sids to search for. It looks like it matches lines like this:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ETPRO TROJAN Cerber Ransomware Macro EXE Download"; flow:established,to_server; content:"HEAD"; nocase; http_method; content:".mov"; http_uri; pcre:"/\.mov$/Ui"; content:"User-Agent|3a 20|Microsoft BITS/"; fast_pattern:7,20; classtype:trojan-activity; sid:2821344; rev:2;)

If a trojan is being downloaded, even from trusted hosts, I'd think I'd want to be notified regardless.

[Ian]

I think I can use something like this?

4.7. Flow Keywords
https://suricata.readthedocs.io/en/latest/rules/flow-keywords.html?highlight=flow

[JM]

Ian,

Yes, the grep to identify SIDs would match, but the goal of the script is only to help triage these alerts. I usually only run this script after I've already reviewed alerts that jumped out at me (like a Trojan download). But your point is fair.

If you wanted to exclude the ETPRO TROJAN sids, you could modify the grep line:

grep -Ei '(exe|dll).*download' /etc/nsm/rules/*.rules | grep -vi 'trojan' | grep -Po 'sid:[0-9]+' | cut -f2 -d: > ~/sids

But how would you define hosts "that are reasonably safe"?

If it's a small set you could set a local rules variable (e.g. SAFE_HOSTS) populated with your safe IPs and use modifysid to s/EXTERNAL_NET/!$SAFE_HOSTS/ and thus exclude those downloads. Of course, that's not a silver bullet, either.

> "If a trojan is being downloaded, even from trusted hosts, I'd think I'd want to be notified regardless."

Both flowbits or rule variables are vulnerable to this. If one of your "trusted hosts" were compromised and started serving malware, you still wouldn't see the alert.

The best real-time solution that doesn't succumb to this issue is an in-line antivirus/malware scanner/malware sandbox solution, in conjunction with the NIDS. (Not that those are without their problems either... :-)

JM

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---

You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/-ym8--LvZ0o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.

[Ian]

JM,

Some of the rules are looking for policy violations (This host is downloading executables!), and some are looking for malicious content (This host is downloading a virus (which may be an executable)!).

I'd only use this for the policy violation type rules. The assumption here is that if the exe is something more than an exe, the other rules will still trigger.

On Sunday, June 25, 2017 at 11:51:13 AM UTC-7, Jon Mark Allen wrote:

> But how would you define hosts "that are reasonably safe"?

> Both flowbits or rule variables are vulnerable to this. If one of your "trusted hosts" were compromised and started serving malware, you still wouldn't see the alert.