The Glider

Reader Tom wrote in that he has noticed an upswing of scanning for port 23/TCP to a honeypot system. They are completing the 3 way handshake, then sending a FIN to shut it down. Dshield data confirms that others are seeing the same. Let us know if you are seeing anything interesting at our contact us page.

Cheers,

Adrien de Beaupr

EWA-Canada.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Chris wrote in and mentioned a talk at Auscert which highlighted that (Sender Policy Framework) SPF would have helped in the instance of an intrusion and suggested a diary outlining some of the things that can and can't be achieved using SPF. I have my own experiences with SPF and the effectiveness, but I'd like to hear you experiences with SPF, good or bad. so I can write a more complete diary on the topic.
For those that are not familiar with SPF. The idea behind it is to create a DNS entry that specifies those machines in your network that are allowed to send email from your domain. The receiving mail server checks this record and if it does not match it will drop the message. There is a little bit more to it, but hat is the crux of it. So if you have had any experiences with SPF (good or bad) please let me know via the contact form or directly markh.isc at gmail.com.
Thanks Chris for the idea and thanks in advance for your contributions. I'm aiming to get a diary out on this later this month.
Cheers
Mark H
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Part 3
In a continuation of previous entries (http://isc.sans.org/diary.html?storyid=8719 and http://isc.sans.org/diary.html?storyid=8863) I wanted to inject a little scope-creep and share what others have sent in.


Scope-Creep
Although the original question was about malicious websites which lent the proposed solution to favor malware intelligence, the framework should include more fraud and crime information. This need arose while considering how we would import DShield data. We will need to add a couple more categories:

Attacker/Scanner-- This would be the default category for DShield submissions due to the nature of the data sources. This could also be imported from your own environment's firewall logs and IDS.
Fruad-- To help encourage victim organizations and law-enforcement organization share details about where cyber-crime is being omitted from. This entry would require a timestamp of the incident.

The date/timestamp of the attack and particularly the fraud is especially important. Without this information, the report is largely un-actionable by most consumers. I will commonly receive a list of 100+ IP addresses that were involved in fraudulent transactions from some government or law-enforcement agency and it is largely a waste of time. Typically months have already passed since the fraud was committed and when the list is released. Compound that with the list being full of ISP-consumer IP addresses and all you are going to find are false-positives. Now, if there were date/timestamps provided in this list, one could then identify if they also had similar activity and provide a better-targeted list of accounts to flag and further inspect.
URLvoid
A few readers have recommended urlvoid.com as a VirusTotal for URLs. It does a nice job of interfacing with 20 or so URL-checkers. It's unclear if they share submissions with all of these vendors like VirusTotal does. If so, they're missing an opportunity to capture additional details from the submission.



Most users just want a good/bad or safe/dangerous determination. It's not always that easy, we'll see below.


Defining Bad
There are a lot of groups that collect this kind of information and they all have their own particular focuses. Mixing and matching the data from these various repositories can result in some unfortunate consequences. I'll continue to use DShield as an example. It is simply a list of dropped sessions, submitted from the public. It's easy to end up on this list since UDP is trivial to spoof, and folks running P2P applications cause afterglow that can result in dropped connection-attempts that get classified as malicious in some environments. As long as you're aware of how the data are collected, this isn't a problem-- until you blindly use it to block email.



Having access to the why helps you interpret the potential impact of blocks. Sometimes blocking the request isn't enough. Blocking an outbound connection to an exploit site is a good thing. Seeing blocked attempts out to a command-and-control server is a not-so-good thing.

(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Brian wrote in to remind me that on my shift 27-MAY-2010 Ifailed to mention VMware's release of VMSA-2010-0009 (http://lists.vmware.com/pipermail/security-announce/2010/000093.html) which addresses a number of security vulnerabilities (43 or so) in ESX/ESXi 4.0.
He also points out a handy resource for hardening vShere noted here: http://blogs.vmware.com/security/2010/04/vsphere-40-hardening-guide-released.html

(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

I always cringe when I get that call to assist with a relative or friend's PC that has fell victim to some version of rogue anti-virus.



Several media outlets are now reporting on a scareware Indictment that was released by the US Department of Justice on May 27th.



You can read the Official FBI DoJ press release here.



G.N. White
ISChandler on duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Ever on the search for useful tools, especially those for pulling files from pcaps, fellow handler, Raul Siles, e-mailed me today to let me know about this cool plug-in. I've just started playing with it, but it looks pretty cool.
Tool:http://www.taddong.com/tools/eo_smb.patch

Whitepaper:http://www.taddong.com/docs/WP_SMBPlugin.pdf
---------------

Jim Clausing, jclausing --at-- isc [dot] sans (dot) org

FOR 408 coming to central OH beginning 30 Sep, http://www.sans.org/mentor/details.php?nid=22353 (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

A Diary Entry that Writes Itself
On my last shift, a reader asked: How do I report Malicious Websites? (http://isc.sans.org/diary.html?storyid=8719) I provided three ways one could report malicious URLs, IP addresses or hosts and requested your comments. There were a lot of suggestions, so I wanted to do a quick round up on this shift.


Unfortunately it Became Complex.
There was a long list of sites where you could submit a URL to a particular product, some that focused on particular service-providers, others that focused on certain types of malware (e.g. Zeus) or crime (e.g. phishing.)



There was no simple one-stop-shop for the end customer to use. Some browsers and ad-ons gives something resembling that functionality, but it too is still limited to protecting the users of that tool.



Upon reflexion, I realize why a one-stop-shop doesn't exist. A single collection and repository of information is not the correct model. It wouldn't scale, it wouldn't be resilient, and it would be expensive. What I suggest is a framework for exchanging this information.


A Diversity of Clients
The ultimate client is the end-user. We all know how uniquely diverse this population is, especially with respect to their technical skills, and security-awareness. This requires a diversity of solutions to serve this population: browser ad-ins, client software, proxy-servers, specialized DNS clients, etc.


A Diversity of Sources
The intelligence comes from a similarly diverse collection of sources, end-users, help-desk technicians, incident-handlers, malware-researchers, etc. I'm stealing from the old saying: Timely, Accurate, Cheap-- pick two.
Consumers Define the Requirements
I consume a lot of malware-related IP addresses, domains and URL each day. This information comes in from a lot of sources: mailing lists, blogs, sandbox analysis reports, online repositories, etc. My focus is on protecting my users, so I look at this information in a certain light. For most users, a simple bad vs. good determination is good enough. I use the following classifications:

Suspicious this is the state that all reports start off with, it looks a little better than Unknown.
Exploit Site-- this is for links to exploit kits or sites that launch attacks
Download for URLs where downloaders or exploit-sites pull secondary payloads
Phone-Home/Command-and-Control-- this is for tracking the requests made by malware after it's installed.
Redirect/Compromised Site-- some systems get owned and get included in the long lists of intelligence that circulate

These classifications are important when an analyst is looking through alerts generated from this watchlist. For example, if a user hits what is classified as a Redirect/Compromised site, but the Exploit Site is blocked by the proxies, you don't have an incident, on the other hand, if you have a system that is consistently probing out to a Phone-Home site that is blocked by your proxies then you do have an incident.



For my purposes, the redirect/compromised site list is low priority. Now, if I were a hosting provider, that list would be of greater importance, but only if the entries were in my network. It is for precisely this reason why I avoid having a risk or severity rating associated with these entries.



What should it record? How should the records be organized? In my database I track based on individual IP or domain, because it's easy to search proxy and firewall logs via hostname, or IP address. I link the more verbose URL to the domain. In the framework that I propose, URLs would be classified as Suspicious, Exploit, Downloader, etc. while IP addresses, hostnames, and domain names would be their own records that link to these URLs.



For example, consider this fictitious exploit URL: hxxp://abcd.efghijkl.ab/invoice.pdf. In our data-set we could classify this URL was and Exploit URL. If we had better analysis we could tack on a sub-classification of the particular CVE that this exploit leverages. The URL would then link to the hostname of abcd.efghijkl.ab, the domain of efghijkl.ab, and at the time of the report abcd.efghijkl.ab resolved to 3 IP addresses 1.2.3.4, 1.2.3.7, and 8.5.6.4. and these may further link to a particular ASN.


Belief and Feedback
Just like in the IDS and AV worlds, this information has it's fair share of false-positives. This comes in mostly from automated sources-- simply because they don't know better. For example, a bot-client might reach out to myip.ru while another may make a google-search using a direct IP address call. Another pain-point is how advertisers redirect requests, examining the network trace of a web-exploit can sometimes lead an analyst down the rabbit-hole of researching the complexities of one of Doubleclick's competitors.



For this reason the framework would have to support multiple reports per URL, and cluster the URLs to account for unique elements in the URL. Additionally reports would have to identify their sources so consumers could rate sources, or filter out unwanted sources.
Why a Framework and Not a Centralized Repository?
Although the aim is interoperability, I understand that not everyone wants to share everything with everyone, so I imagine this resembling a number of diverse feeds that are consumed and transformed by vendors and end-users. Some services may evolve that correlate and fact-check a large number of feeds to provide a stable and reliable source of good versus bad decisions for end-users, while other vendors may pick and choose their sources to craft a unique solution for their market. Enclaves of researchers would form their own webs of trust via the feeds that they subscribe-to and self-produce.
I'm going to noodle a bit more on this, I welcome your feedback. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Naming and tracking different malware families still leaves much to be desired, so for lack of a better alternative, I'm using the term Sasfis. It's function appears to be a general bot-net and is mostly leveraged to install other malware such as key-logging/banking-trojans such as Zeus or scareware like the many variants of Fake Anti-virus that is currently in the wild.



I've been seeing this payload quite often this week. The most common way I see it is in fake shipping invoices. Today I received a well-targeted email using obviously-compromised user-contact data. It claimed to be from the state business tax department, and encouraged the recipient to install the (fake) secure-gateway software so that they could continue to pay their sales taxes online.



I'm being intentionally vague about the state since I'm haven't been able to contact them (abuse@$STATE$.gov bounces, for shame) but needless to say, if your state is distributing security software to you, it shouldn't be hosted in Moldova.



The detection of the malware was low, only 3 out of 40 at virus total. their reports of network behavior were obviously blocked, and I managed to get one of my test IP addresses similarly blocked while playing around with the code today. They're upping their game.
For those looking for this on their networks, look for HTTP-like activity out to v-medical.org and 89.187.53.203.
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Modularization of malware is something we have been seeing for quite some time already. Authors of malware often build various modules that allow them to extend functionality of malware but also to make analysis more difficult. The rationale behind this is pretty simple if this particular infected machine does not need the module that, for example, attacks a certain bank it will not be downloaded and installed. This makes it more difficult for the AV vendors to collect all samples of various modules as the attackers can target them. One example of such highly modular (and heavily protected) malware is certainly Clampi you can see a series of articles about this malware family posted on Symantec's web site.
The attackers can also use modularization to rapidly change fingerprints of malware if only one module is detected by an AV vendor, the attacker only has to modify that particular module. And if you've been following our diaries you already know how the AV vendors are lagging behind the attackers.
One very simple malicious file was submitted to us couple of days ago by our reader Tim. He found the file in the /Windows/SysWOW64 directory on his Windows 7 machine. The file was named netset.exe and it wasn't signed, so it immediately looked suspicious to Tim.

However, online malware scanners all happily declared the file safe when it was initially submitted to VirusTotal it resulted in 0 detections (yes 0 out of 40 AV programs on VirusTotal, see the report here).
After we received the file, one of the things I normally first use is Anubis, a service for analyzing malware available at http://anubis.iseclab.org/. However, Anubis also said that this file is safe and that it did not do anything suspicious. At that point in time I knew I had to dig manually into the file and this is what it is doing.

While not terribly malicious (meaning, it's not a trojan that will communicate with a CC), the file is obviously part of another malware. The sole purpose of this binary was to check if the user is running certain AV programs on his machine and, if yes, return that result as the exit code so presumably that other malicious program knows what to do. But the sneakiness around this was interesting.
First of all, the malware has to be started with a command line parameter it can be any parameter that starts with the letter s or t. If that character was not found, the malware will delete some files (dtnet.exe, plang.enu, dsten.log) and just exit. The code that checks the argument can be seen in the picture below:

If the correct parameter was found, the binary opens the HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Uninstall registry key which holds all installed applications on the system. It then goes through all the subkeys and compares them to the following list: avast, avg, avira, nod32, kaspersky, norton, mcafee, trend micro, comodo. It is now pretty obvious what it does. For any of these, an internal counter is incremented. Finally, when the binary exits the counter is used as the return code so, as I said above, I presume that some other piece of malware uses this to check if there is an AV program running on the machine.

This code is shown below too:

While this file is relatively simple, we can see on this example that the attackers are using those simple tricks to make automated analysis more difficult. Since even emulators such as Anubis, which execute the malware in an isolated environment, will not know which argument it needs, the file will appear to be benign. And judging by the VirusTotal results they have no problems with evading signature based scanning either.
--

Bojan

INFIGO IS

(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

New method for phishing discovered by Aza Raskin creative lead for firefox.



http://www.security.nl/artikel/33401/1/Duivelse_nieuwe_phishingaanval_gebruikt_tabs.html

I had to run this thru google translation service and it did a decent job but not perfect.

I modified it somewhat based on my understanding of the issue.

There is a good flash video that shows how the attack works.



Here are the steps as outlined in the translated version of his description.



User navigates to your normal looking site.



The phishing site detects when the page has lost focus and it hasn't been interacted with for a while.



Replace the favicon on the tab with the Google favicon, the title with Gmail: Email from Google, and the page with a Google log look-a-like. This can all be done with just a little bit of Javascript that takes place instantly.



The user scans their many tabs open, the favicon and title act as a strong visual cue and memory is malleable, moldable and the user will simply think that they will most likely left a Gmail tab open. When they click back to the fake Gmail tab, they'll see the standard Gmail login page, assume they've been logged out, and provide their credentials to log in. When they click back to the Gmail tab fake, they'll see the standard Gmail login page, Assuming they've logged out, and provide their credentials to login. The attack preys on the perceived immutability of tabs.



Assuming the user had left a Gmail tab open where they had previously correctly authenticated. Also assuming the user has entered their login information and you've sent it back to your server, the phishing site can now redirect you to Gmail because they were never logged out in the first place, it will appear as if the login was successful.



(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.