The Glider

Top-level domains are taking a new turn today with ICANN announcing the new TLDs using non-Latin characters.For exampleEgypt: (Egypt). It will be interesting to see how this will be used. I wouldn't know where to begin typing on my keyboardso I would have to rely on links to get me to some sites. As we know clicking links blindly on the internet is always a great idea, especially in emails. -) (http://www.icann.org/en/announcements/announcement-05may10-en.htm).
Cheers
Mark
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Tor sent in a link to a Google code page on Web Security. This page provides links to several good web app pen testing and defense resources. The most intriguing of which is the Jarlsberg codelab. Essentially Jarlsberg is a buggy web app that you can hack to learn web app pen testing and defense.
From the Jarlsberg introduction page:
This codelab is built around Jarlsberg /yrlz'brg/, a small, cheesy web application that allows its users to publish snippets of text and store assorted files. Unfortunately, Jarlsberg has multiple security bugs ranging from cross-site scripting and cross-site request forgery, to information disclosure, denial of service, and remote code execution. The goal of this codelab is to guide you through discovering some of these bugs and learning ways to fix them both in Jarlsberg and in general.
Sounds like fun.

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

Tonight is the night that DNSSECis enabled between the DNSroot servers. I am not going to go into detail since the good people at the other ISChave already done a wonderful job of that in their posting.
Lots of the usual hype in the usual places including The Register, slashdot, etc. The fact is that this really only affects the way your ISPs talk DNS to the root servers. I suspect most users are using their ISPs DNS servers which will continue to talk to their customers the old way. It may cause problems for some users who are hosting their own DNSservers behind antiquated firewalls, but for the most part this will be a non-event.



What I find interesting is that using the resolver test at RIPE, my OpenDNS provided resolvers fail.
Hopefully that will be fixed before the big event.

Update: OpenDNSresponded to my query with a pointer to a forum article. It seems they are just fine.

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

We have received a number of emails from readers pointing us to news articles indicating that the USTreasury is in the process of cleaning up malicious iFrame that have infected a number of their sites. We have also received one report that this particular iFrame redirect has also been found at other sites and that perhaps this may be another registrar related compromise.
If anyone has any further information on whether or not this is bigger than just the USTreasury, we would love to hear it.
As usual you can send us feedback through the comments to this diary, or via our contact page.

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

Russ McRee over at holisticinfosec.org has once again written an excellent ISSAToolsmith article. This article is a review/tutorial of SIFT - SANSInvestigative Forensic Toolkit. SIFTis Rob Lee's open source forensic toolkit used for the SANSSEC508. Daniel Wesemann announced the availability of SIFTin a previous diary.
As usual Russ provides good insight into the high points of SIFTincluding how to install and configure SIFT. He then walks you through some of the features of SIFTby performing a basic investigation of a memory image.
While the article only scratches the surface it is definitely worth the read if you are interested in forensics using open source tools.

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

Following up on yesterday's social engineering post, the banking scammers don't just rely on ZBot -- the good old paper based advance fee or fake letter approaches still work, too.
ISC reader David, for example, got a fedex envelope with an unexpected check over 2'850$, with him as recipient. Diligent security specialist that he is, he called the issuing bank .. and found out that the account against which the check was drawn had zero funds. The way this works is that the bad guys follow up the first letter with a second, where they apologize for the mistake, ask the victim to wire back 2500$ and keep the 350$ for your trouble. If you go ahead with this, by the time the check bounces, you have wired the money, and wired money is gone or at least very very hard to get back. Given that the crooks incur quite some expense and risk in this scenario (fedex isn't cheap and often traceable back to the source) they must still be making a killing out of this scam.
The second scheme is phishing via old-fashioned paper mail. You get a letter stating that for security reasons calling the bank now requires a pin code, included below. Follows a pin code of a length and complexity that makes it unlikely anyone would want to remember it, and two lines down, the helpful comment that the pin code can be changed by calling 1-800-whatever. You do so, and here's what happens next:
Voice: Please enter your account number, followed by the pound key[you type]

Voice: Please enter your current telephone access code[you type in the access code in the letter]

Voice: This access code is incorrect. Please try again.[you type - correctly again]

Voice: This access code is incorrect. Please hold for an operator.[you hold]

Operator: XYZ Bank, my name is QRS, how may I help you[you explain]

Operator: To identify you, we have to ask a couple of security questions. What are the last four digits of your social security number ?
Yep. You get the drift. After this exchange, they have everything they need.
Lesson learned: Do not ever call your bank on a telephone number included in a letter, email or left on your voice mail. Get to know some employees at the bank branch you do business with, and call them with any questions you might have. Recognizing someone's voice beats a security pin code any day.

Update: Apparently, a bank in the US is currently sending out letters about phone pin codes that look a lot like the fraudulent fakes described above - including both an unsolicited new pin code and an 800 number to call to change it. If you received one of these letters, call your bank branch (as mentioned above) or check that the telephone number on the letter matches the 800 number the bank has listed under contact on their (real) web page. Trust, but verify was yesteryear. Nowadays, the rule in banking matters changed to Don't trust, always verify. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Have you updated your awareness program lately? A sample of the new email used to social engineer the new Zbot variance, crossed my desk recently and prompted me to wonder if our security awareness had a variance to include this type of attack? Do your users know that no one will send a password over clear text? Do your users know the difference between plain text and encrypted text?



The tactic being used is skillful and easy to fall prey to. Are your users aware of this method?

Dear Prey,
Your account has been deactivated for whatever reason and requires you to download and execute the following file. The password for the file is 12345.
Thank you for your prompt attention to this Zbot social engineering email!
Reputable Company

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

The past 24 hours have been somewhat uneventful. Perhaps it's because today is May Day, a traditional holiday in many countries. Perhaps it's because the Kentucky Derby was today. Who knows. Regardless, we are happy to report that we've only noted one item worthy of mentioning and that's a lapse in the Snort digital certificate. Two readers let us know that it had expired on April 30th. It looks like the issue has been resolved - the current certificate is good until June of next year.
Marcus H. Sachs

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

Malware Forensics at Large Firms
The malware forensics work-cycle is fairly tight at the day job. It focuses more on answering questions like:



What are we dealing with? (e.g. an adware like Monkif, or an information stealer like Zeus?)

Grab a sample to submit to the AV vendor

Identify network behavior so we can identify infected machines on the wire

How did it get in?



Depending on the workload, resources, etc. we dont always get to answer all of the questions before the demands of keeping the business running or more severe incidents reallocates the response staff.


Smells Like Zeus
Last week, a sharp-eyed user noticed that their on-line bank was asking more questions than they usually do when they log in. During the initial triage I noted that it smelled like Zeus. Once we had got onto the box with EnCase we immediately looked for, and found, c:windowssystem32sdra64.exe on the system. Sure, case-closed. Submit the sample to AV to get them to update their signatures, examine the users proxy logs to identify the phone-home behavior and make signatures from that. There, the organization is protected.


But How Did It Get In?
The final-step in incident handling and the most-often ignored is the root-cause analysis or lessons-learned. With this particular case, I had a timestamp of when sdra64.exe was dropped on the box (if I trusted the MAC times) and could start digging through the web proxy logs for that machine at that time. That sounds like a lot of something-that-isnt-much-fun.



You know what sounds like more fun? Timeline analysis.



(For more on doing your own Timeline Analysis in your environment, I recommend starting here: http://blogs.sans.org/computer-forensics/2010/03/19/digital-forensic-sifting-super-timeline-analysis-and-creation/)



In EnCase its not too hard to organize the view of the file system to track what files were modified or added around the time of sdra64.exe. I was at first interested in the files in the Temporary Internet Folders location of the user, since it will help me narrow down what website was hosted the exploit.


Java Applet Cache Files
In addition to the HTML and image files in the Temporary Internet Folders there were also files created in c:Documents and Settings[victim]Application DataSunJavaDeploymentcache[numbers]



There were files that had hash-like names, some with no extension, some with .idx, some with .hst.



The extentionless file is a zip archive of the .class files or bytecode of the java applets downloaded to the system. The .idx file looks suspiciously like the HTTP session used to pull it down, and .hst was the IP of the source.



Thats pretty handy information to have on hand. But what is the significance of java applet? On a whim, I submitted it to virustotal and it tells me that its an exploit for CVE-2009-3867. Neat, now I know how it got in and where it came in from.


Prefetch Files
With the tight deadlines, and the rushed process of identifying the process generating the bot-net traffic, or what dll is getting injected into iexplore.exe I know that Im missing a lot of the other files that get dropped onto the system. If were lucky enough to get a memory snapshot of the system while its doing its evil I can use something like volatility to tell me what files a process has open. If its after-the-fact, I can glean some of that information from the prefetch files. In our zeus case while jumping into look directly for sdra64.exe I also saw SDRA64.EXE-[hash].pf.



The normal forensic value of prefetch files is it will tell you how many times an executable has been run and the last time that it was executed (I refer you to Harlan Carveys Windows Forensic Analysis DVD Toolkit pp 226 in the first edition, pp296 in 2nd ed) The real purpose of a prefetch file is to improve the efficiency of the OS so it tracks what files are opened by the executable. Using something like BinText you can see the list of files open by the application. This gives me an additional list of files to check against the whitelist for. In this particular example the .pf file also had a bit of HTML in there that looked like an iframe, Im not sure if thats a fluke or not, but it held additional clues about the exploit.

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

A reader reports that a new version of the Opera browser has been released today for Mac and Windows. The release notes are available here: http://www.opera.com/docs/changelogs/windows/1053/
The notes are simple, this is a security update to address a security vulnerability detailed here: http://www.opera.com/support/kb/view/953/
This is likely handled as an auto-update in most installations. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.