Wednesday, September 28, 2011

Phishing Phindings

Today I received a phishing email trying to get my mail username and password. The attacker was assuming several things, including that I use webmail to check my email.

Let's take a look at this attack and see what we can find out from this email.

First, we are going to look at the full headers of the email. The headers give us information about the sender, the route, and the recipient of the email.



<original message>

Return-path: <shenningdong@96818.com.cn> <-- The return path is from a Chinese domain

Delivery-date: Tue, 27 Sep 2011 01:07:44 -0400

Received: from vhosting2.netsite.com.br (189-112-034-215.static.netsite.com.br [189.112.34.215]) <-- The host that is being used to relay this phishing attempt is in Brazil

by mx.xxxx.xxx (node=mxus1) with ESMTP (Nemesis) id 0LfDKC-1QolSp32eO-00pH6z for user@taget_domain.com; Tue, 27 Sep 2011 01:07:44 -0400

Received: from vhosting2.netsite.com.br (unknown [127.0.0.1]) by vhosting2.netsite.com.br (Postfix) <- The relay is using Postfix

with ESMTP id EB964EC1D7; Tue, 27 Sep 2011 01:32:11 +0000 (UTC)
Received-spf: none (no valid SPF record)

Received: from User (unknown [151.83.78.83]) <- IP originates from Milan, Italy
by vhosting2.netsite.com.br (Postfix) with ESMTP; Tue, 27 Sep 2011 01:32:11 +0000 (UTC)

Reply-to: <switchwebmail@webname.com> <- Registered to World Media in New Jersey and is NOT my hosting provider.

From: Webmaster <shenningdong@96818.com.cn> <- Chinese domain
Subject: Email Shutdown Notice
Date: Tue, 27 Sep 2011 03:32:10 +0200 (09/26/2011 08:32:10 PM)
Mime-version: 1.0
Content-type: text/plain; charset="Windows-1251"
Content-transfer-encoding: 7bit
X-priority: 3
X-msmail-priority: Normal

X-mailer: Microsoft Outlook Express 6.00.2600.0000 <- The attacker runs Windows

X-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-id: <20110927013211.EB964EC1D7@vhosting2.netsite.com.br> <- Again, Brazil

To: undisclosed-recipients : ;
Envelope-to: user@target_domain.com
X-evolution-source: imap://user%40target_domain.com@imap.target_domain.com/

Now, let's dig through the body of the message to see what we can find...

Dear Webmail User,


This message is from the Webmail Support team to all email users. We are currently carrying out an upgrade on our system, hence it has come to our notice that one of our subscribers Infected our Network with a worm like virus and it is affecting Our database.


Apparently the "Webmail Support team" is different from the email team, although it would seem that the Webmail team speaks for both. Right off the bat, this email appears disjointed.

Capital letters of place ("Infected", "Network" and "Our")

Upgrades don't let you know that you have a virus, per se.

There is a "worm like virus and it is affecting Our database."  This sentence alone raises a red flag due to it's structure.

We are also having congestions due to the anonymous registration of email accounts, so we are shutting down email accounts deemed to be inactive. Your email account is listed among those requiring update.

Misspellings and improper grammar are signs that an email is not legitimate (ie: having "congestions" and "requiring update."). 

Why the mention of anonymous email accounts? If they offer a service like Gmail, etc. then all of their clientèle would be anonymous. A pay service would typically not host anonymous accounts. My server is hosted by a company that I pay to host it. There are no anonymous accounts here.

To resolve this problem, simply click to reply this message and enter your User Name here
(_____________) And Password Here (___________) to have your email account Cleared against this virus.


Failure to comply will lead to the termination of your Email Account.

More use of improper capitalization ("User", "Name", "And", "Here", "Cleared", "Email" and "Account")

It should be noted that again, careful reading of the mail raises red flags as it feels disjointed.

Another big flag here is that a hosting provider (or credit card company, bank, etc.) will NEVER ask you for your username and password in an email.

Hoping to serve you better.


Alice Hobbs
Webmail Support


******************************************************************************************************************************************************
</original message>

Reading this all and putting it together brings me to the following conclusion; If I give then my user name and password, my anonymous account will be cleared of the virus that is affecting their database.

Takeaways:
  • Full email headers can provide a lot of valuable information as to the source and path of the message that you just received.

  • There are often little nuances, such as spelling, grammatical or capitalization errors that can tip you off that the email that you are reading isn't legitimate. 

  • Emails that ask for usernames, passwords, social security numbers, bank account numbers, etc. are bogus.

  • A lot of phishing attempts come from other countries, so the grammar or overall "feel" of the email may be off. These are signs to run!

One can avoid becoming the victim of a phishing attack if you take the time to look at emails carefully, especially those that ask for specific information or those that send you a link to verify "something".

Sunday, September 25, 2011

Nashville InfoSec CTF Recap

On September 15, my colleagues and myself hosted a Capture The Flag event (CTF) at Nashville InfoSec 2011 at the Nashville Convention Center.

The CTF consisted of a vulnerable network environment that was designed to be exploited to gain access to different areas where flags will were hidden.

The goal of the game was to provide a fun and slightly competitive atmosphere for those who were interested in performing penetration testing roles. The game was designed for a wide range of skill sets with the end result being a better understanding of how attacks are performed, and thus, how to better defend against them.



Along the course of the game, the flags (strings) were hidden in files as well as in other strategic locations which are sort of milestones within the event. In addition, the event was not set up in a linear fashion, so there were several ways with which to achieve the flags, which were weighted based upon level of difficulty in finding it. The game was created so that all of the vulnerabilities were common and real world examples. The tools used to exploit the vulnerabilities were also common and were included in BackTrack 5, which was provided to anyone who needed it.

We started right around 8:30 and ran until lunch break at 11:50am. Five teams showed up and competed in this years event with the goal of being the team with the most points (maximum of 40) at the end of the time limit

The comments that we heard from both the teams and the spectators was that the event was very fun and educational. One team leader remarked that this was the best training that his team could receive.

If you or team participated in the CTF and would like to give us your thoughts/write-ups of the event, please send them to wraith@digitaloverdrive.org or post them in the comments below.

Saturday, September 10, 2011

Book Review: Practical Packet Analysis (Second Edition)

I recently had the privilege to review a copy of Practical Packet Analysis (Second Edition) by Chris Sanders. This book, which is published by No Starch Press, takes a straight-forward approach to analyzing network traffic with  Wireshark, a free and open-source packet analyzer.

This book contains an in-depth approach to packet sniffing, a necessary skill needed by all administrators and engineers, that makes it easy for people from all knowledge levels from the beginner to the network engineer to learn something from the concepts that are taught.

The topics in the book range from the basics of network fundamentals and how to sniff a network to analysis of more complex topics such as man-in-the-middle attacks and wireless analysis.

Additionally, Chris' easy to follow, down to Earth writing style, combined with the ability to plainly explain the concepts that he was presenting in the book, make this an incredible learning tool.

In addition to all of the information that is presented in the book, one of the best value-adds is that all of the capture files that are used in the examples are available from the No Starch Press website, so that one can load them into Wireshark and follow along. This really helped as it provided for a real, hands-on approach to understanding the presented concepts.

After reading this book and following along with the files and real-world examples, I felt as though I had attended a week-long class on packet analysis. 

Practical Packet Analysis is a must have for both the person just starting out in network troubleshooting as well as the seasoned professional who would like to refine their skillset.