Argus detecting historical APT1 activity #3 cont

[Carter Bullard]

Hey Craig,
Don't get me wrong, anything that can help find the bad guy/girl/whatever,
is a good thing, but Argus is a very specific implementation of comprehensive
network auditing, a fundamental security mechanism.  IDS's and anomaly
detectors are not fundamental security mechanisms, they are interesting
technology, that support a single phase of the Cyber Security Incident
lifecycle, penetration identification.  If you've already been penetrated, or
if its an insider, like 80% of incidents are, these methods are theoretically
useless, because there isn't anything for them to detect.

Argus isn't trying to be an IDS, or an anomaly detector, its trying to be a
good network audit system, and I think its a good one of those.  It works
for many sites because it contributes to all of the phases of Cyber Security
Incident Response, as well as basic network management for 
Operations and Performance.

Many sites run Snort, Bro and Argus on the same box, and for many of
those sites, Argus data is used for false positive rejection.  A few very
prominent sites use Argus alone, as IDS is irrelevant for them.  Some of
these are more interested in the results of the break in, not the method
of the break in.  Some are interested in zero day events, as they can
be more important to worry about.  Some sites that use Argus are ISPs,
who don't have any ownership of the traffic contents,  but they sure do
want to know a lot about the transport traffic they support, and some have
so much encryption that content inspection isn't going to happen, except
to demonstrate that the contents are, indeed, encrypted.  Neither Snort
nor Bro offer anything for these guys.

If you wanted to build a network behavioral anomaly detector, whether
its for Cyber Security, or for performance or operations management,
Argus audit data is a great data starting point. You will need all the
fields and the ones that are coming out this year.

Carter



On Apr 13, 2013, at 8:32 PM, Craig Merchant <cmerchant at responsys.com> wrote:

> No apologies necessary, Carter.  I've got a pretty thick skin and a ton of gratitude for all the help you've provided thus far.
>  
> I wasn't trying to frustrate you and I definitely wasn't advocating pattern matching as an exclusive (or even primary) cyber security awareness tool.  In my experience, it does have *some* usefulness.  If I discover a file that I know infected a user with malware, I can search AV or application whitelisting logs and see if other users executed the same thing so their machines can be reimaged.  I’m not sure I’ve ever seen a file hash collision yet.
>  
> Our company provides a SaaS platform for companies to manage relationships with their customers across email, social media, mobile, and banner ads.  We only work with clients whose users "opt in", so our customers have hundreds of thousands to tens of millions of valid email addresses in their database.  We're a huge target for spammers and are frequently subject to directed malware and spear phishing attacks.
>  
> The last round of spear phishing emails we suffered had an exe in a zip file attachment sent to hundreds of users.  The attachment contained a wide variety of different file names, but the hash was the same.  Even though, as you point out, a hash is pretty easy to defeat.  Many of our attackers seem to be either dumb or lazy.  I just need to be sure they don't get lucky.
>  
> As to why I might want the ability to grab hashes of executable content off the wire...  There are a number of websites (isthisfilesafe.com, virustotal.com, team-cymru.org) that offer some kind of programatic lookup of hashes.  If all three of those sites said an exe file I saw a user execute contained malware, it might make the most sense to just have the machine re-imaged and forgo an extensive investigation.  If only one of those sites classified the file as malware, it might make sense to look at IDS logs, argus flow data, AV logs, etc. and see if any other security tools see that host as having some level of elevated risk associated with its behavior.  It just seems to me like a pretty easy way to identify known-bad files, freeing me up to spend my time looking for unknown-bad files through behavioral analysis.
>  
> It’s not like developing a functional model for detecting anomalies across dozens of different data types is quick or easy (at least not for somebody who isn’t a quant and a developer).
>  
> FireEye and Palo Alto Networks both now have cloud services that will upload all executable content their appliances see (presumably smaller than a certain size), execute it in some kind of virtual environment and then analyze it for malicious behavior -- does it look for a running debugger?  Modify startup registry keys?  Attempt access to protected memory?  Perform a callback to a known bad host? 
>  
> Those appliances tend to be quite expensive.  If we can't afford one at the four person remote office in Timbuktu and I could use something like Argus to capture the file hashes of executable content, I could at least query those services APIs to see if they are known-bad or use a system management tool to collect the file for a manual analysis.  But from what previous people said in response to my note, it sounds like Bro can already do this.  I was just curious as to what kind of effort it would take for Argus to do the same thing...  Trying to avoid the proliferation of tools…
>  
> And I agree with you completely that pattern matching IDS systems, like Snort, aren't terribly effective or useful.  But unfortunately for me, I've yet to see a prospective customer security questionnaire or a customer security audit checklist that didn't include some kind of checkbox for IDS.  As much as I'd like to give them an impassioned speech about how the time spent managing the IDS system would be better spent on various anomaly detection efforts, they aren't terribly interested in having a philosophical discussion about their boilerplate vendor security checklist. 
>  
> One of the things I've noticed with Snort is that the shellcode signatures generate a mountain of false positives.  I'm working on some searches in Splunk that will cross-reference any Snort shellcode event against data from an Argus search that looks for reverse keystrokes. 
>  
> Now, as far as those example pattern matches I included...  I just randomly pulled a couple examples out of my Snort rules.  From what I've seen when visually inspecting the shellcode rules, a lot of them are either “|some_hex_values|” or a bunch of stuff that looks similar to:  \x00\x28\x3c\x26…  So, if I was going to word that question more clearly…  Based on your experience, what types of textual patterns in a data payload would you consider as worthy inputs to some kind of anomaly engine/logic? 
>  
> And to generalize that even further, if you were going to build an anomaly detection tool within Argus, which of the hundred plus Argus data fields would consider most valuable for detecting anomalies? 
>  
> Thanks for your thoughtful (and honest) reply.  Hope you have a good weekend!
>  
> Craig
>  
> -----Original Message-----
> From: Carter Bullard [mailto:carter at qosient.com] 
> Sent: Saturday, April 13, 2013 10:32 AM
> To: Craig Merchant
> Cc: Argus
> Subject: Re: [ARGUS] Argus detecting historical APT1 activity #3 cont
>  
> Hey Craig,
> Seems that half the time I'm responding to your email, I feel like I need to beat you up.
> Before I do that in this email, I'll apologize from the beginning, so sorry.  I'm going to
> be somewhat forceful to emphasis some extremely important issues in Cyber
> Situational Awareness, to point out the biggest problem out there, which is the
> issue of human awareness in Cyber Security. But then I'll let you off the hook,
> so hopefully this isn't going to be brutal.
>  
> Why on earth would you want to reassemble every executable file from HTTP
> connections, generate an MD5 checksum and then go look the MD5 up
> in someone else's database ?   Is this going to be helpful ???   Really ????
> MD5 checksums, easy to change those ?  Adding an additional space to
> the executable, kinda makes this method pretty useless ?  And the better
> question, are you authorized to capture this type of data ?  Really ??  Are
> you sure ???
>  
> Pattern recognition has proven to be the WORST strategy for detecting Cyber
> Security related events.  They cost an amazing amount of money, they don't
> scale, they are remarkably unreliable, use an amazing amount of electricity,
> don't do anything else for you other than look for small byte segments,
> and generate so much heat and wasted time.   So much wasted time,....,
> chasing down the amazing amount of false positives.  But even worse,
> the false negatives are completely un-calculable.  This is just not a good
> thing to evolve toward, in so many dimensions.
>  
> Some large users use argus just to do false positive rejection of Snort and
> Suricata alarms.  And its not surprising.  You had in your example, a
> " Heap spray " Snort signature, looking for " |5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c| ".
> Do you know if that is a good signature?  It is now an old signature,
> I believe that Microsoft has a fix in and the current pattern should be
> ' unescape("%u4141%u4141") '.    i'm sure in another 5 weeks, there
> will be another string, then another ......  Looking for the string " unescape "
> is probably a strategy that is bit more sustainable, than the actual bit pattern
> test, and maybe a bit more reliable.  Who uploads " unescape " to a
> browser?
>  
> Isn't it more important to see what it is that the Browser does once its been
> corrupted by something like a Heap Spray technique than to simply set off a
> " bell " every time you see " x0c|5C|x0c|5C " on the wire ??????
>  
> The point is that Cyber Security SHOULD NOT be a pattern recognition
> discipline.
>  
> Our imaginations are great, and the attackers imagination is probably better,
> since he/she is motivated in a different way than we are.  However, only
> a small number of attack ideas are actually useful, and the number of
> attack defenses is even smaller.   We should be designing protection
> strategies and mechanisms that are based on the actual theories of
> Cyber Security.  Bell-LaPadula, now there is a starting point.
>  
> OK, to let you off the hook, argus is designed as a data reduction audit engine.
> The idea is we don't capture everything, we capture a minimum to enable
> a large number of forensics capabilities.  We capture controlled samples of
> transport data to enable content type identification / recognition.   In many cases,
> our controlled sample strategy does capture enough payload to do all that
> Snort, Suricata and Bro are designed to do, but in some cases we don't
> grab enough to do complete Deep Packet Inspection, which I believe is a
> forensics rat hole.    So, ..., if you want to grab all the packet contents with
> argus, we provide all the bells and whistles to do so.  You can do packet capture,
> and you can extend the amount of user data sampling to get almost all of it.
>  
> But I'd recommend that you just run Snort or Suricata along side argus.
> Most vendors are supporting that type of multi-product strategy.
>  
> But to put the argus angle on this, more interestingly, the total number
> of app bytes uploaded to a browser to perform a " heap spray " is as
> sensitive an indicator of an exploit as the MD5 checksum over the contents.
> And much more resilient to genetic mutation of the code.
>  
> Behavioral analytics, I believe are going to be more useful than pattern
> recognition for Computer Network Defense, and that historical audit data
> is the best data to base such systems.
>  
> Sorry if I was a bit too negative, hopefully this has been helpful.
>  
> Carter
>  
>  
>  
> On Apr 12, 2013, at 5:56 PM, Craig Merchant <cmerchant at responsys.com> wrote:
>  
> > Carter, thank you very much for writing such thorough and thoughtful emails on this subject.  I’ve shared them with the entire security team at work.
> > 
> > I’ve been thinking a bit on how Argus could be used to do more proactive alerting of these kinds of threats.  As you know, I’m not a programmer *at all*.  I had a couple of ideas and was wondering what it would take to implement them.
> > 
> > How difficult is it to reassemble a file from payload data?  I’m imagining being able to reassemble executable files from HTTP connections to external hosts, generating an MD5 of that file, and then use dig to query the malware database from:
> > 
> > http://www.team-cymru.org/Services/MHR/#dns
> > 
> > For APT threats that don’t drop a file and write directly to some vulnerable part of memory, what kind of payload data would be indicative of that kind of attack?  Looking through some of our Snort rules, I see patterns that look like:
> >  
> > Heapspray example:
> > |5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|5C|x0c|
> > 
> > Shellcode examples:
> > |90 90 90 E8 C0 FF FF FF|/bin/sh
> > |6a 43 59 e8 ff ff ff ff c1 5e 30 4c 0e 07 e2 fa 6b 63 5b 9d|
> > \x00\x00\x00[\x00\x01].{4}\x00\x01\x00\x01lanattacks_(start_dhcp|reset_dhcp|set_dhcp_option|stop_dhcp|dhcp_log|start_tftp|reset_tftp|add_tftp_file|stop_tftp)
> > 
> > How would you use Argus to detect those types of attacks without generating a ton of false positives?  It doesn’t seem like the types of patterns above should be all that common in normal HTTP traffic.
> > 
> > How much of the payload would Argus need to look at to reliably identify those types of attacks?
> > 
> > Thanks.
> >
> > Craig
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130416/ea97a4ce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2589 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130416/ea97a4ce/attachment.bin>