Loading...


Mar 31, 2011

Hacking a Server Remotely Through Remote Desktop

I mentioned the other day that a local business owner whom I barter services with called me to take a look at his domain controller because he could no longer login to the domain with any domain accounts.

It turns out that his server was hacked into by a mischievous hacker, and they did some minor destructive things to make this particular business owner’s life a little harder than it needed to be. Well after getting his domain back using this domain administrator password reset technique, I started looking into other things this hacker did, and it seemed like the hacker probably got in using Remote Desktop (RDP) over the internet.

How is that possible you ask? Well, for one, RDP was open to the internet to that particular server, but mainly because there was no strong password policy or password lockout policy to prevent any type of guessing attack. Because of that, it actually made it pretty easy for them to get in.

I’m assuming the tool they probably used was a little beauty called TSGrinder. Here is a description from Virtualization Admin:

TSGrinder is a command line tool which very basically allows automating password guessing via RDP connections. TSGrinder is a "dictionary" based attack tool, supports multiple attack windows from a single dictionary file (you can specify this on the program command line).

A very interesting option in the program is the “leet” function. This leet function enables the program to cope with a popular development in password-land. What I mean is that, from the knowledgeable user up, people tend to secure their passwords by replacing letters with well-known symbols. For example, password becomes p@ssw0rd (replacing a’s with @’s and o’s with 0’s). This is a very well thought thorough option because as we will see trying these passwords does not require you to change your dictionary file.

For a quick example on how to use TSGrinder, here is a clip from Hak5 Episode 423 where Darren Kitchen shows us how TSGrinder is used, and gives us ways to protect against it.

What I did to fix up the business owner, was I closed RDP access from the internet to his server, and setup a VPN connection instead. That way the owner could still access his network remotely without the worry of some TSGrinder happy script kiddie. I also setup a strong password policy with password lockouts. That is good because if someone tries to do a password guessing attack on an account, the account will lock out and the bad guy can’t get in. Finally I renamed the administrator account and the guest account to something else and created fake account in their place with denied access.

Nothing is fool proof. If a really good hacker wants in, they are going to get in. Our jobs as administrators is to make getting in a little harder. By sacrificing security for ease of use, you really are leaving yourself open to an attack.

Mar 30, 2011

PWN3D! Resetting The Domain Administrator Password After You’ve Been Hacked!

So I have this deal with a local business near me. I fix their computers, and take care of their network for them and they give me and my family free stuff. Fair trade right?

Well, a few months ago I rebuilt their network, and domain controller and upgraded them from a Windows 2000 domain to Windows 2003. After the upgrade I noticed that they had very weak password policy. In fact, they had no password policy and they never changed their passwords. I told them they should consider going with a stronger password policy, but they were more concerned with ease of use. Ok, at lease I warned them!

Well I got a call on Monday from the frantic business owner. His server was no longer accessible and none of his domain passwords worked any more. One thing he had set up on his router was RDP access to his server from the Internet. Normally not a terrible thing if you have good passwords, and account lockouts, but like I said before, he didn’t.

hackerWhen I finally showed up to his office to assess the situation, my account was no longer active either. Your network is only as secure as your weakest link. The weak link in this network was passwords.

Anyway, I had to get them back up and running because without their server their business could not function. I will mention some of the things I ran into, but will go into how I addressed them in different posts. This post is about recovering a domain password after it’s been compromised.

Apparently this will work on a Windows 2008 and 2008R2 Domain Controller too. Anyway, I did the following:

  • Rebooted the domain controller into Directory Services Restore mode by pressing F8 at boot up
  • Logged into the server with the local administrator account and the Directory Services Recovery password. (If you don’t know it, follow my video here to reset it as it works on all versions of Windows)
  • Downloaded SRVANY.exe and INSTSRV.exe from the Microsoft Resource kit (Here)
  • I extracted the above files to d:\recover
  • I opened a command prompt and changed into d:\recover then ran the following:

    instsrv PassRecovery "d:\recover\srvany.exe"

  • The above created a new service that runs as a local service which when started in normal mode will have full domain admin access
  • Next I went into services, and went into the properties of my PassRecovery service, made sure it was set to automatic start, and on the logon tab I checked the box to allow interaction with the desktop.
  • Next I opened the registry and navigated to:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PassRecovery

  • From there I created a new sub-key called Parameters
  • Within Parameters I added the following values:


    name: Application
    type: REG_SZ (string)
    value: c:\windows\System32\cmd.exe


    name: AppParameters
    type: REG_SZ (string)
    value: /k net user administrator n3wP@55w0rd! /domain



  • Make sure to change the above password to something you can remember
  • Now reboot, and the service should start up and reset your domain administrator password

After you are able to login to your domain as Administrator, run the following from command line to remove the PassRecovery service we created:

net stop PassRecovery
sc delete PassRecovery

Also go ahead and delete the d:\recover directory, and reset the Administrator password if you want.

Something to note on this is whomever hacked in was not a fool. They were smart enough to delete the net.exe application from the System32 directory so at first this trick didn’t work. I had to go back into Directory Services Recovery Mode and copy net.exe from a different Windows 2003 server to the System32 directory on the hacked server. After that the trick worked fine.

Another thing the hacker did, that I noticed after I finally got in, was delete the gpedit.msc snap-in so I couldn’t modify Group Policy. I did the same thing as I did with net.exe, and copied it from another server. Easy fix.

Some other things they did was:


  • Created 4 back door accounts
  • Deleted several user accounts
  • Created a startup script that recreated back door accounts at boot up and put them in the Domain Admins group

I am also fairly sure they got in using RDP and an RDP brute force/dictionary attack tool like TSGrinder. I will discuss what I did to mitigate that stuff in future articles.

Also to touch back on the password weaknesses, I enabled a good strong password policy and lockout policy which should help against brute force and dictionary attacks.

It’s sad to say that sometimes being the victim of a hack like this is a good lesson in password security, and how important it is. This situation could have been much worse if this hacker wanted to be really malicious. The next time an administrator tells you that your password or your password policy is not strong enough, you may want to listen.


[Via Petri IT Knowledge Base]


Mar 28, 2011

Error Upgrading Exchange 2010 Unified Messaging To SP1

You ever go to patch a server late one evening, after hours so as not to bother the users, and after about two hours into the upgrade everything goes to hell in a hand basket? Good, so I’m not the only one. In fact, you are probably reading this right now because of that very same scenario.

Anyhoo, so what happened to me was I finally got around to upgrading my Exchange 2010 server to Service Pack 1. When running through the install everything checked out. All perquisites were green, and so I proceeded with the upgrade. Everything was going well until it got to the Unified Messaging Role. About 75% in the install failed with the following error:

Unable to remove product with code 84a6e864-10a5-47c0-ac31-426fe71e4906. Fatal error during installation. Error code is 1603. Last error reported by the MSI package is 'There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.

WTF!? I figured it was just a fluke, so I rebooted and tried the upgrade again with the same issue. The real sucky part was that the upgrade up to the failure took about 3 hours! That was 6 hours of my life wasted! Plus I had to work on this sucker until about 4am. I was friggin’ tired! Anyway, despite the failed upgrade, Exchange still worked so I went to bed, and showed up late to work the next day.

When I finally got to work, I started researching and could find nothing online about how to fix this for Exchange 2010. I did find some useful things related to Exchange 2007 though. It wasn’t quick enough though because I found out that since the pooched upgrade, voicemail no longer was working. Shit! I needed to fix this fast! Here is what I had to do.

First I had to trick Exchange into thinking that Unified Messaging wasn’t installed. To do that, I followed the advice of Nick Whittome of The Naked MVP:

Kick up ADSIEdit and go to ADSIEDIT->Configuration -> Services -> Microsoft Exchange -> [Org Name] -> Administrative Groups -> Administrative Group Name -> Servers-> [server name] -> Properties and look for the attribute msExchCurrentServerRoles

exchange1

Edit this and subtract the UM Role Value (16) from the currently set value (54).   So 54–16=38

Enter that value (38)

exchange2

Reboot the server….

Reinstall the service pack…..

That fixed the first problem. It got the upgrade to complete, but Unified Messaging was still broken. In order to upgrade it, I first had to remove it. To do that I had to undo what we did in the last section and in ADSI Edit set the msExchCurrentServerRoles value back to 54, then reboot Exchange.

Then I had to go into the registry on Exchange using regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\UnifiedMessagingRole and delete the "Action"="BuildToBuildUpgrade" key.

After that, from Programs and Features I was able to uninstall Unified Messaging. Once it was removed, I rebooted again for good measure then using a slip-streamed version of Exchange 2010 with SP1, I ran the following from the root of the install media:

setup.com /mode:Install /roles:UM

Boom! Everything was right as rain again! Exchange 2010 was fully upgraded to Service Pack 1!

Did you have a similar issue with your Exchange 2010 SP1 upgrade? Did you fix it differently? What did you do that worked? Let us know in the comments.

 

Mar 25, 2011

History of The Internet

Despite what Al Gore says, he did not invent the Internet. In fact, the Internet has been around for a lot longer than you think! When your parents were smokin' pot, and dropping acid at Woodstock, early computer scientists were transmitting some of the earliest packets across the country's phone lines.

Here is an interesting infographic that I found while surfing on Stumbleupon showing the timeline of the Internet's history up to 2009!

MBA Online

[Source: OnlineMBA.com]

Mar 8, 2011

Upgrading MS-DOS 5.0 Through Windows 7

I know what you are thinking, someone had a lot of time on their hands. I am inclined to agree with you there. Still though, it's fascinating to see someone take the time to install every major version of Windows starting with MS-DOS 5.0 (Because early versions of Windows required it) and continue through to Windows 7 using only the upgrade processes.

I first saw this on Facebook as it was posted by a former boss, and good friend of mine named Justin. Me being a big geek, I watched it and thought it was great! The guy performing the experiment is Andrew Tait of Andy’s Tech Experiments, and took him about 3 days to do it. Why did he do it? According to Andy:

I got the idea from a 90s computer magazine article I vaguely remember (possibly from PC Format?), which essentially did the same procedure but only from Windows 3.0 to Windows 98. Since virtual machine technology is much more mature now, and there are four additional versions of windows, I thought it would be a great time to repeat the experiment. I installed Doom 2 and Monkey Island as tester applications, as I found the installation disks for them while I was looking for Windows disks, and those were two of my favourite games from the period (and still are).

Here is the video:

Chain of Fools : Upgrading through every version of windows

 

From Andy’s blog, here are some FAQ’s about the experiment:

FAQ
Why Didn't you Install Windows ME?
Since Windows ME cannot be upgraded to 2000, I chose to install 2000 straight from 98 as it was chronologically the next release. I might do an "alternate history" version to see what going from 98 to ME to XP looks like.
Did Doom 2 and Monkey Island work in Windows 7?
Yes. Sorry I didn't point that out explicitly in the video.
Can you do the same thing with Mac OS?
I don't know enough about Mac OS to be able to say, and I would not be the best person to do that experiment as I have never been a Mac user.
Where are you from?
Scotland.
What's that beeping noise in the background?
My smoke detector - its battery is flat :)

What do you think about the experiment? Awesome? Waste of time? Let us know in the comments!

[Via Andy’s Tech Experiments]

Mar 1, 2011

How To Set Multiple Password Policies in AD

I’m sure like many of you in your organization you have certain service accounts in active directory where the passwords don’t change that often. When you do change them, like when an employee leaves, sometimes you might miss a few on some old servers that you forgot you had, and all of a sudden, that service account is getting locked out.

There are good reasons to leave it that way. For one, it protects your service accounts from brute force/dictionary password attacks. Also, if a service account gets locked out, you usually know right away because an application server will stop working.

The problem with it though is although it may protect you from guessing password attacks, it could potentially leave you at risk for a DoS attack. Think about it, all an attacker would have to di is keep running a brute force attack on a service account, and it would lock out keeping your service from working. That last reason is a good reason too in itself… The service stops working!

This used to be a pain in the arse in Windows 2000 and 2003. According to Windows Architecture:

In Windows Server 2000 and Windows Server 2003 applying password policy was restricted to Default Domain Policy. With this approach if organization has to plan for different set of password policy for their users spread across the globe , it was not possible.

Lucky for us, Microsoft fixed this limitation in Windows Server 2008 and 2008 R2. Instead of applying password policy in the default domain policy, you can create multiple PSO’s (Password Settings Objects). Just make sure to leave the password policy settings in the default domain policy as undefined. In order to make this work though, YOU HAVE TO RAISE THE FUNCTIONAL LEVEL OF YOUR DOMAIN TO 2008 OR BETTER! That means if you still have 2003 DC’s in your domain, it is finally time to upgrade! Instead of applying the PSO at an OU level, now you do it with security groups. Pretty slick right?

Before creating your PSO’s, first plan it out. We only needed two in my domain. One for regular user accounts, and the other for service accounts. Now, since we don’t want service accounts to lock out, but we don’t want bad guys guessing our passwords either, we set the accounts to not lock out, and also set a minimum password length to be really long (like 40 characters).

Also it is important to note that when running the wizard to create the PSO’s there are four different kinds of fields:

  1. Unicode String – This can be anything. Generally used to name your PSO
  2. Boolean – For this it is looking for True or False
  3. Integer – For this it is looking for a single number
  4. Duration – For this is is looking for a time frame (I.E. 90:00:00:00 = 90 days, and 00:00:30:00 = 30 minutes)

Now we have a basic idea of what we want, we are ready to create our PSO’s. You have to do this using ADSI EDIT doing the following:

  • Open ADSI EDIT, right click on ADSI Edit at the top of the root and select Connect To
  • In the Name field type in the FQDN of your domain
  • Expand down to CN=System> CN=Password Settings Container
  • Click on CN=Password Settings Container
  • On the right side if there are any PSO’s, they will be there. If this is the first time you are doing this, it will be blank
  • Right click on CN=Password Settings Container and select New>Object
  • For Select Class, you should only have one option which is msDS-PasswordSettings, click Next

     Create-object
  • On the next page, give your new PSO a name (I.E. ServiceAccounts) and click Next

serviceaccounts

  • On the next page is the Password Settings Precedence. The lower the number, the higher the precedence. For example, a precedence of 1 will override a precedence of 2. See the diagram below

Prcedence

  • Follow the prompts for the rest to fit your environment. Remember what I wrote above for the four different value types
  • Also note that for the msDS-LockouTThreshold field, if you set that to 0, then lockouts will be disabled. Otherwise the Integer value represents the number of attempts

Repeat the above process for all the PSO’s you want to create. Make sure you set important ones with higher precedence. For example, I set our Regular Users to a precedence of 2, and the Service Accounts PSO to a precedence of 1.

Once you have your PSO’s created, now you will want to create security groups to apply the PSO’s to. In my environment I applied the Regular Users PSO to the Domain Users group because that is the default group for all users. Then I created a second group for Security Users that I applied the Security Users PSO to. When I assign a service account to the Security Users group, the Security Users PSO takes priority over the Regular Users PSO, and boom! No more lock outs!

To assign a group to a PSO do the following:

  • Open Active Directory Users and Computers, and make sure view Advanced Features is enabled
  • In Active Directory Users and Computers expand down to Services>Password Settings Container
  • In Password Settings Container, find your newly created PSO’s. Right click on one and select Properties
  • Click on the Attribute Editor tab
  • Scroll down to msDS-PSOAppliesTo, click on it and select the Edit button

appliesto

  • Click the Add Windows Account Button, and enter the name of the security group you want to apply the PSO to and click OK
  • Click OK, then Apply
  • Now you’re done!

It seems complicated at first, but once you look at it, it’s actually pretty simple and ingenious. Makes me wonder why Microsoft hadn’t done this before!

Have any questions or comments? Hit us up below!

[Via TechNet]



Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | stopping spam