Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 27 min 37 sec ago

Keeping the RATs out: **it happens - Part 2, (Fri, Jul 18th)

Fri, 07/18/2014 - 06:40

As we learned in Part One of our exploration of Hazrat Supply's series of unfortunate events, our malicious miscreants favored multiple tools. We first discussed developing IOCs for HackTool:Win32/Zeloxat.A which opens a convenient backdoor on a pwned host. One note on that front, during analysis I saw network calls to zeroplace.cn (no need to visit, just trust me) and therefore added matching URI and DNS items to the IOC file. Again, I'll share them all completed for you in a day or two.
I know I promised you an analysis of the svchost dump file Jake provided using Volatility but unfortunately that effort did not bear much fruit; the imagecopy module didn't return actionable results. The actual svchost.exe sample is still an analysis work-in-progress as well given, while certainly malicious, the file we have was not an original payload and is exhibiting limited functionality. I do hope to have insight on that front tomorrow.
That said, one of the other tools that was found on the server by Jake was PWDump7. This is a commonly used tool and is often part of larger hacker or pentester kits; you should be detecting and blocking them both equally :-).
By definition, PwDump7.exe is not malware per se, it's simply a tool that can be used for malicious purposes. It doesn't make file system changes, it doesn't phone home, it doesn't change the registry, but it sure does dump password hashes as seen in Figure 1.

Figure 1

The first reader who emails me (russ @ holisticinfosec dot org) my clear text password from the 500 hash as seen in Figure 1 wins a prize of my choosing (probably shwag or a book), I'll Tweet out the winner. *UPDATE* - We have a winner as of 0146 PST last night, thank you, Martin R. The password for you all is IveBeenHacked.
In the absence of particularly interesting artifacts, can we still create IOCs for hack tools such as PwDump?
But of course!
File name, file size, and hashes are obvious, but what else can we use when so little presents itself with a hack tool that is standalone and basically just runs?
Tools such as PEStudio can give us additional options if we look beyond the obvious. PEStudio, by default, will sort by color coded (red), flagged items. Often this presents some obvious enough indicators but with PwDump7, not so much. But sorting by something different such as Value under Strings and Unclassified gives us a perfectly unique indicator not likely to occur very often, particularly in the context of established file name and hashes. Figure 2 exemplifies.

Figure 2

As such, our IOC elements would be derived as seen in Figure 3.

Figure 3

Can't miss with strings keywords like that. :-)
I'll leave you with this. As we've been learning from the kind transparency of Jake and Hazrat Supply, **it happens, it really does.
Just another reason not to tailgate.
Cheers!

Russ McRee | @holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Snort 2.9.6.2 is now available on Snort.org at https://www.snort.org/downloads, (Fri, Jul 18th)

Thu, 07/17/2014 - 17:14
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, July 18th 2014 http://isc.sans.edu/podcastdetail.html?id=4067, (Thu, Jul 17th)

Thu, 07/17/2014 - 13:27
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Cisco Wireless Residential Gateway Remote Code Execution Vulnerability - http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/ciscosa-20140716-cm, (Thu, Jul 17th)

Wed, 07/16/2014 - 20:44

Russ McRee | @holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, July 17th 2014 http://isc.sans.edu/podcastdetail.html?id=4065, (Wed, Jul 16th)

Wed, 07/16/2014 - 14:41
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Keeping the RATs out: an exercise in building IOCs - Part 1, (Wed, Jul 16th)

Tue, 07/15/2014 - 23:35

Reader Jake sent us an awesome bundle of RAT-related mayhem collected during performance of his duties while investigating the unfortunate and prolonged compromise of a company we'll fictitiously call Hazrat Supply.
Guess what?  The RAT that was plaguing the Hazrat Supply environment was proxying traffic back to a Chinese hosting company.
This is my shocked face.

Really, I'm shocked, can you tell?

With the plethora of malicious files shared with us in this package it represents a huge opportunity to create some related IOCs with Mandiant's IOCe as well as run some of this evil through my preferred toolkit with which to identify then build said IOCs. We'll do this in three parts as I'm handler on duty for the next three days (lucky you); there's lots here to play with (lucky me).

Let me give you a quick manifest first:

bybtt.cc3    MD5 c2f0ba16a767d839782a36f8f5bbfcbc
Backdoor:Win32/Zegost.B

mylcx.exe    MD5 4984fd547065ddcd781b068c4493ead6
HackTool:Win32/Zeloxat.A

PwDump7.exe    MD5 d1337b9e8bac0ee285492b89f895cadb
HackTool:Win32/PWDump

svchost.exe    MD5 20a6310b50d31b3da823ed00276e8a50
VirTool:Win32/Obfuscator.BL

Ironically the RDP server the attackers used, RemoteMany3389.exe, is not flagged as malicious by AV detection. Apparently it's a legitimate tool...in China. :-)
Seemingly so too is the file locker they used, xlkfs.sys, courtesy of XOSLAB.COM (signed by Yang Ping). Hey, thanks for signing it, I trust it more.
I'm going to go out on a limb here (not really) and say treat these files as flagrantly hostile.
Hit the big red button if they happen to be on your systems along with their malicious compatriots cited above.
Here are their hashes regardless:
RemoteMany3389.exe    MD5 c9913698afc7288b850f3af602f50819
xlkfs.sys        MD5 4aa2d2975d649d2e18440da0f3f67105

Building IOCs with Mandiant IOCe is in many ways straight forward for simple logic, you'll need to understand AND and OR substructures to build more complex logic branches.
Read the user guide that's installed with the editor.
I took just a few attributes (MD5, SHA1, file size) to start my IOC file for HackTool:Win32/Zeloxat.A as seen in Figure 1.

Figure 1

I'll be populating this further and sharing the full IOC file set for each of these samples upon request after Friday's shift.
Tweet me for them @holisticinfosec or email me via russ at holisticinfosec dot org.

Tomorrow, I'll run Jake's dump file for svchost.exe through Volatility to see what we can further learn and use to create additional IOCs.
Stay tuned.

Russ McRee | @holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, July 16th 2014 http://isc.sans.edu/podcastdetail.html?id=4063, (Tue, Jul 15th)

Tue, 07/15/2014 - 14:35
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Oracle July 2014 CPU (patch bundle), (Tue, Jul 15th)

Tue, 07/15/2014 - 14:29

In addition to the Java vulnerabilities that I covered earlier, there is at least one more vulnerability that warrants attention. CVE-2013-3751, a problem in the XML parser of Oracle Database. Reading the description, I had a bit of a déjà-vu, also because of the CVE number from last year. And digging into past alerts, I found that, yes, this has indeed been patched before:

 


Looks like the Oracle 12 code was forked before the 11g patch went in, and nobody ported it over, so Oracle 12 remained exposed to the same bug until now. This speaks volumes about Oracle's software development life cycle and security processes... Dear Larry Ellison: how about writing a "Trustworthy Computing" memo for your staff, and then following through on it? I'm sure Bill Gates won't mind much if you simply copy his from 2002 and do a little search-and-replace.

For other untrustworthy computing features brought to you by this month's CPU patch bundle, see https://blogs.oracle.com/security/ and http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Oracle Java: 20 new vulnerabilities patched, (Tue, Jul 15th)

Tue, 07/15/2014 - 12:09

Welcome to the n-th iteration of "patch now" for Java on Workstations. Oracle today published their quarterly patch bulletin, and Java SE is once again prominently featured. This Critical Patch Update (CPU) contains 20 new security fixes for Oracle Java SE.  Most of the vulnerabilities are remotely exploitable without authentication, and CVSS scores of 10 and 9.3 indicate that they can be readily exploited, and lead to full compromise. Which means that keystroke loggers, ebanking trojans, etc, will soon follow.

Oracle/Java is probably by now one of the most successful charities in the world, it continues to do an outstanding job at enabling significant wealth transfer to support poor cyber criminals and their families. Except that the sources of the funds usually have no idea, and didn't agree to donate directly from their bank accounts ...

After the past three years of repeated gaping holes in Java, we hope that by now you have found a way to remove Java from your computers entirely, or to at least no longer run the Java plugin within the web browser.  Otherwise, it is back to the hamster wheel, to yet again re-test all your applications that still require Java, to check for the inevitable incompatibilities with this latest release, and then to expedite the roll-out. This is definitely a patch that you don't want to skip or delay.

The full Oracle patch bulletin is available here: http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html#AppendixJAVA  .

The other Oracle patches (for database, etc) released in today's patch CPU are still under analysis here at SANS ISC. I'll post about them later, if warranted.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

AOC Cloud, (Tue, Jul 15th)

Mon, 07/14/2014 - 16:08

In matters of food and wine, the Europeans have this concept of "AOC", based on the originally French "Apellation d'origine contrôlée". It means that, say, Bordeaux wine actually comes from there, and is not re-bottled Malbec from Patagonia. The point I'm trying to make, albeit poorly, is that it is sometimes important to know where things are coming from, which implies traceability to the source.

In matters of IT, we are currently losing this AOC. Only three years ago, we likely knew exactly, down to the server room cabinet and shelf, where our mail server was located. These days, with "cloud" services proliferating rapidly, we might know who *sold* us the service, but we only have a vague idea of its real origin or location.

The question recently came to light again when Codespaces (http://www.codespaces.com/) went down after a hacking attack back in June. As they say on their web page "In summary, most of our data, backups, machine configurations and offsite backups were either partially or completely deleted". I wonder how many (if any) of Codespaces' customers had actually done the due-diligence, while signing up, to determine that all of Codespaces' services were hosted at Amazon EWS, *including* the backups. That's AOC!  You might know from where you buy your SVN or GIT hosting, but - unless you negotiate hard, forbid any sub-subcontracting, and ruthlessly enforce your right to audit - you might never learn where your SVN/GIT hoster actually hosts the service. And, not even with your right to audit, will you ever find out where *that* hoster draws their services from. Because you don't have a contract relationship with the hoster (only with the SVN service on top), and if the hoster, at their discretion, decide that they can operate more cheaply by re-selling Virtual Machines from Patagonia instead of running their own .. that's what's going to happen.

If you like this concept, I have a stellar 1961 Bordeaux that I'm willing to part with for a good price. Please don't worry about the penguins and the Spanish language on the label :).

In all seriousness though - it is overdue that "cloud" providers provide a bit less cloud, and a bit more sunlight. It might hurt their bottom line a little, but the kind of "AOC" end-to-end transparency, with traceability to the source, is vital and paramount for the customer to assess and mitigate any resulting risk.

If you have any stories on how you determine the "AOC" of your penguin wine (or not), please share below.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, July 15th 2014 http://isc.sans.edu/podcastdetail.html?id=4061, (Mon, Jul 14th)

Mon, 07/14/2014 - 14:07
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

E-ZPass phishing scam, (Mon, Jul 14th)

Mon, 07/14/2014 - 11:45

Over the last couple of days, we have been seeing a number of quite credibly looking phishing emails that impersonate toll-road providers in the US. The agency affected by the current wave is E-ZPass, a toll charging system used mainly in the Northeast. Adapting the template to match the colors and fonts of other organizations, like Florida's SunPass, would be easy to accomplish for the scammers though, so chances are that we will see more of this.

Since toll road agencies can impose stiff fines for violations or if road and bridge charges are not paid in time, people might fall for it and click on the link just to make sure. In the samples at hand, the link was pointing to www . ruckon . pl (spaces added to de-fang), and returned a ZIP with an EXE or directly an EXE. Hat tip to ISC reader Wayne for providing the latest sample.

 

If you receive similar emails that impersonate other toll road providers, please let us know.

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Oracle July 2014 Update Pre-Notification, (Sun, Jul 13th)

Mon, 07/14/2014 - 06:34

Oracle has released a preview of patches to be released, seen here, on Tuesday, July 15, 2014, and includes updates to business critical systems, such as Oracle Database, WebLogic server, and Fusion.  The most concerning aspect of the majority of vulnerabilities discussed is the one phrase “may be exploited over a network without the need for a username and password”.  The most critical update, imho, that is being released Tuesday is the Java fixes that are being released (20 security fixes!), which give the vulnerability a pristine CVSS Base Score of 10!!  Woohoo, way to go Oracle and Team Java!

But please don’t take my word for all of this, go take a look for yourself, and see what the week ahead has in store.

tony d0t carothers --gmail

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

The Internet of Things: How do you "on-board" devices?, (Mon, Jul 14th)

Mon, 07/14/2014 - 01:43

Certified pre-pw0ned devices are nothing new. We talked years ago about USB picture frames that came with malware pre-installed. But for the most part, the malware was added to the device accidentally, or for example by customers who later returned the device just to have it resold without adequately resetting/wiping the device.

But more recently, more evidence emerged that everything from network gear [1] to inventory scanners [2] may be infected deliberately in order to penetrate otherwise hard to reach networks. Typically, there is little a customer can do to verify that a device is not infected. Standard practices, like malware scanners and verifying installed software doesn't always work if you don't have "shell access" or the ability to install software on the device. 

This leaves careful network monitoring as one option to  detect and disrupt command and control channels used by these devices. However, in order to do so accurately, it is important to characterize "normal" network traffic from the device, which can be challenging in particular if the device connects to cloud services for updates or intentional data exchange.

The large number of these devices entering our networks asks for a scalable solution. We can't add security devices and personal proportional to the number of devices deployed. The security features included in these devices (host based firewalls, encryption technologies, ability to manage and limit installed software/"apps") varies widely and frequently there are no enterprise configuration tools available. 

What kind of network segmentation and on-boarding procedure do you apply to new devices introduced into the network? 

[1] http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/
[2] http://www.trapx.com/news/press/trapx-discovers-zombie-zero-advanced-persistent-malware/

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, July 14th 2014 http://isc.sans.edu/podcastdetail.html?id=4059, (Sun, Jul 13th)

Sun, 07/13/2014 - 15:15
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, July 14th 2014 http://isc.sans.edu/podcastdetail.html?id=4059, (Sun, Jul 13th)

Sun, 07/13/2014 - 15:15
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Metasploit Update Alert, (Fri, Jul 11th)

Fri, 07/11/2014 - 07:27

Update your metasploit instances to take advantage of the new "Reverse HTTP Hop Stager" for meterpreter payloads.  Because any day you can pivot is a good day, and if you can pivot through native web services, that's an awesome day!  Hop adds the ability to use any basic PHP host as a hop point for meterpreter by adding a new reverse_hop_http payload.

Details here ==> https://community.rapid7.com/community/metasploit/blog/2014/07/10/weekly-metasploit-update
Video here ==> http://youtu.be/FktILE206z0

===============
Rob VandenBrink
Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Egress Filtering? What - do we have a bird problem?, (Fri, Jul 11th)

Fri, 07/11/2014 - 06:48

One of the major tools that we have in our arsenal to control malware is outbound filtering at firewalls and other network "choke points".  
Over the years, it's become obvious that "enumerating badness" on the internet is next to impossible, it's generally much easier to enumerate "known good" traffic, and simply deny the rest as bad or at least suspect.  Often the management response is "we trust our people", but that's not really the point.  While maybe you can trust all of your people, you can't trust the malware they may have, or all the links they might click.  But let's be honest, it's likely that you can't trust all of your people to never install a bittorrent client or other higher-risk program.

So, as they say in the circus - "This Way to the Egress!"

An egress filter is generally put on your firewall, allowing known good traffic, and denying everything else outbound (and logging those attempts - hopefully you're monitoring your logs right?).  So, how do you go about setting up an egress filter?  You can't just list 10 protocols that you know are good and deny the rest - that's a good way to find out what OTHER protocols your business requires when you break those business processes - in other words, that's the hard way to do this.

We'll use the approach in the previous story to figure out what exactly we're running through the firewall, so we can then make go/no-go decisions about each one.

We can take a big chunk out of this by:
allowing DNS only from DNS Servers
Allow mail only from mail servers (permitted mail servers)
allow browser web traffic (either just from a proxy, or from all permitted workstations, depending on the organization)

So we can list the tcp protocols in play with:
D:\syslog\archive\2014-07-03>type SyslogCatchAll.txt | grep outbound | grep TCP | sed s/\t/" "/g | cut -d " " -f 12 | cut -d "/" -f 2 | grep -v 80 | grep -v 443  | grep -v 25 | sort | uniq -c | sort /R

This gives us the following output, listing the remaining protocols, in descending order.

    118 22
     81 1935
     80 8080
     79 993
     68 445
     66 843
     39 5228
     34 53
     28 5223
      4 52223
      3 135
      2 52165
      1 52222
      1 40009

Hmm - that gives us something to work with.  We can use the techniques covered in yesterday's story (https://isc.sans.edu/forums/diary/Finding+the+Clowns+on+the+Syslog+Carousel/18373) to dig deeper into these.

It turns out that the 135 and 445 traffic was drive maps through an inbound vpn session - no problem there.
The tcp/22 was sftp outbound - two business processes involving a transfer of financial information.  
For one, we allowed the outbound from the designated transfer host.  for the other, we allowed the outbound traffic to the designated destination.  Then denied 22 from others.
The "8080" protocol was an application (not a browser) using an outside proxy server.  This could as easily have been malware using a proxy, or someone using an "anonymizer" proxy or a "make it look like I'm in the US" proxy (we get some of that in Canada).

.. and so on.

Of course, you'll have to do the same for UDP also, and also the other protocols that aren't either tcp or udp.

So you'll have a list (in pseudo english / cisco speak) like:

ip access list extended ACL_INSIDE_OUTBOUND
permit dns from known dns servers, to the permitted dns forwarders only (we turned root hints off at the servers)
deny dns from anything else, and log the attempt
permit mail from the mail servers
deny mail from anything else, and log the attempt
permit http
permit https
permit tcp/22 from the one transfer client to anything
permit tcp/22 from anyone else to the second transfer server
deny tcp/22 from anything to anything else, and log the attempt
deny ip protocol 41 and log the attempt  (remember from yesterday that this is IPv6 Teredo tunneling)
 and so on
permit ip any any log

The last line is the critical one.  With that entry, you can then use the log mining techniques we've been discussing to mine the logs for just the entries that trigger that last line - the "permit ip any any log" line.  Eventually, you'll find that after whittling down the protocol list, you'll have a shorter and shorter list each day. At some point, you'll need to change that last line to a "deny any any log" at the bottom of the list.  Be sure that you've gone through a month end, and maybe even a year end before you add that last line. (the year end might be stretching it, unless your accounting year matches up with this project for you)

In answer to "we trust our people" - Those high port numbers in our initial list turned out to be bittorrent traffic - the giveaway was that it was from odd high ports to other odd high ports.  After digging through the logs a bit more, we identified the IP address that was running the protocol, and thought we'd be dealing with one of those uncomfortable "people problems".  Even better though - the source of this traffic turned out to be in the server IP range.  After some digging, it turned out to be a QNAP NAS that was used to store laptop images.  After cracking the manual, we found this box shared everything out via bittorrent via default.  At that point we were both saying - really?  This whole "collaboration / sharing" thing can go to far, and this was in fact too far!  Who's idea was it to make these NAS devices a "share all my data with the world" devices?

So maybe you can trust your people, but you can't trust them to read the manual !  And you can't trust them to always think about security before they plug new gear in.

Egress filters aren't 100% effective, but the are a critical part of your "defense in depth" strategy.  For instance, lots of malware (and bittorent clients and other apps too) will "hunt" until they find an open outbound port - so you'll often see them using ports like tcp/80, 443 or udp/53.  But with a proper egress filter, you'll quite often catch even this "port hunting" behaviour in the logs also.  If you are able to stand up a proxy server, often it's possible to deny almost all direct communication from the workstations, but really, that's just moving the same problem to the proxy server.

In newer architectures (those NGFW's we're all talking about), you'll find much more effective controls, but the concepts of filtering outbound traffic, and how to implement this, remain very much the same.  For instance, at home I've got a time-based ACL that allows my kid to play minecraft only in certain time windows (what can I say, it was fun to code that up). 

If you are doing egress filtering, what have you found in the process of putting them in?  What's the coolest thing you've caught after you've had it in place?   Let us know in our comment form.

If you're not doing egress filtering, why not?

===============
Rob VandenBrink
Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Egress Filtering? What - do we have a bird problem?, (Fri, Jul 11th)

Fri, 07/11/2014 - 06:48

One of the major tools that we have in our arsenal to control malware is outbound filtering at firewalls and other network "choke points".  
Over the years, it's become obvious that "enumerating badness" on the internet is next to impossible, it's generally much easier to enumerate "known good" traffic, and simply deny the rest as bad or at least suspect.  Often the management response is "we trust our people", but that's not really the point.  While maybe you can trust all of your people, you can't trust the malware they may have, or all the links they might click.  But let's be honest, it's likely that you can't trust all of your people to never install a bittorrent client or other higher-risk program.

So, as they say in the circus - "This Way to the Egress!"

An egress filter is generally put on your firewall, allowing known good traffic, and denying everything else outbound (and logging those attempts - hopefully you're monitoring your logs right?).  So, how do you go about setting up an egress filter?  You can't just list 10 protocols that you know are good and deny the rest - that's a good way to find out what OTHER protocols your business requires when you break those business processes - in other words, that's the hard way to do this.

We'll use the approach in the previous story to figure out what exactly we're running through the firewall, so we can then make go/no-go decisions about each one.

We can take a big chunk out of this by:
allowing DNS only from DNS Servers
Allow mail only from mail servers (permitted mail servers)
allow browser web traffic (either just from a proxy, or from all permitted workstations, depending on the organization)

So we can list the tcp protocols in play with:
D:\syslog\archive\2014-07-03>type SyslogCatchAll.txt | grep outbound | grep TCP | sed s/\t/" "/g | cut -d " " -f 12 | cut -d "/" -f 2 | grep -v 80 | grep -v 443  | grep -v 25 | sort | uniq -c | sort /R

This gives us the following output, listing the remaining protocols, in descending order.

    118 22
     81 1935
     80 8080
     79 993
     68 445
     66 843
     39 5228
     34 53
     28 5223
      4 52223
      3 135
      2 52165
      1 52222
      1 40009

Hmm - that gives us something to work with.  We can use the techniques covered in yesterday's story (https://isc.sans.edu/forums/diary/Finding+the+Clowns+on+the+Syslog+Carousel/18373) to dig deeper into these.

It turns out that the 135 and 445 traffic was drive maps through an inbound vpn session - no problem there.
The tcp/22 was sftp outbound - two business processes involving a transfer of financial information.  
For one, we allowed the outbound from the designated transfer host.  for the other, we allowed the outbound traffic to the designated destination.  Then denied 22 from others.
The "8080" protocol was an application (not a browser) using an outside proxy server.  This could as easily have been malware using a proxy, or someone using an "anonymizer" proxy or a "make it look like I'm in the US" proxy (we get some of that in Canada).

.. and so on.

Of course, you'll have to do the same for UDP also, and also the other protocols that aren't either tcp or udp.

So you'll have a list (in pseudo english / cisco speak) like:

ip access list extended ACL_INSIDE_OUTBOUND
permit dns from known dns servers, to the permitted dns forwarders only (we turned root hints off at the servers)
deny dns from anything else, and log the attempt
permit mail from the mail servers
deny mail from anything else, and log the attempt
permit http
permit https
permit tcp/22 from the one transfer client to anything
permit tcp/22 from anyone else to the second transfer server
deny tcp/22 from anything to anything else, and log the attempt
deny ip protocol 41 and log the attempt  (remember from yesterday that this is IPv6 Teredo tunneling)
 and so on
permit ip any any log

The last line is the critical one.  With that entry, you can then use the log mining techniques we've been discussing to mine the logs for just the entries that trigger that last line - the "permit ip any any log" line.  Eventually, you'll find that after whittling down the protocol list, you'll have a shorter and shorter list each day. At some point, you'll need to change that last line to a "deny any any log" at the bottom of the list.  Be sure that you've gone through a month end, and maybe even a year end before you add that last line. (the year end might be stretching it, unless your accounting year matches up with this project for you)

In answer to "we trust our people" - Those high port numbers in our initial list turned out to be bittorrent traffic - the giveaway was that it was from odd high ports to other odd high ports.  After digging through the logs a bit more, we identified the IP address that was running the protocol, and thought we'd be dealing with one of those uncomfortable "people problems".  Even better though - the source of this traffic turned out to be in the server IP range.  After some digging, it turned out to be a QNAP NAS that was used to store laptop images.  After cracking the manual, we found this box shared everything out via bittorrent via default.  At that point we were both saying - really?  This whole "collaboration / sharing" thing can go to far, and this was in fact too far!  Who's idea was it to make these NAS devices a "share all my data with the world" devices?

So maybe you can trust your people, but you can't trust them to read the manual !  And you can't trust them to always think about security before they plug new gear in.

Egress filters aren't 100% effective, but the are a critical part of your "defense in depth" strategy.  For instance, lots of malware (and bittorent clients and other apps too) will "hunt" until they find an open outbound port - so you'll often see them using ports like tcp/80, 443 or udp/53.  But with a proper egress filter, you'll quite often catch even this "port hunting" behaviour in the logs also.  If you are able to stand up a proxy server, often it's possible to deny almost all direct communication from the workstations, but really, that's just moving the same problem to the proxy server.

In newer architectures (those NGFW's we're all talking about), you'll find much more effective controls, but the concepts of filtering outbound traffic, and how to implement this, remain very much the same.  For instance, at home I've got a time-based ACL that allows my kid to play minecraft only in certain time windows (what can I say, it was fun to code that up). 

If you are doing egress filtering, what have you found in the process of putting them in?  What's the coolest thing you've caught after you've had it in place?   Let us know in our comment form.

If you're not doing egress filtering, why not?

===============
Rob VandenBrink
Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Apple pushes OS X update to block out of date Flash versions - http://support.apple.com/kb/HT5655, (Fri, Jul 11th)

Fri, 07/11/2014 - 06:09

=============== Rob VandenBrink Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts